Oracle’s license agreement as it pertains to reverse engineering

As Mary Ann said: "Nanny, nanny boo boo..."

This is why I sometimes wish HN had an ::irony:: tag. :)

Don't worry, there are other blog posts there by the same person, many of which provide the same sense of mission and customer focus.

(popcorn)

> developing a lot of fun new ideas for dispatching people

They probably felt it got off on the wrong foot with personal anecdotes. Better to keep it all business, IMHO.

I'm pretty sure there are a lot of enterprise software vendors who want their products to be inscrutable so that after you buy it you need to hire their consultants to tune it to perform acceptably for you. If you understand how it works, you might be able to stop being a part of those extra revenue streams.

> against someone reversing their source is because they're afraid someone will steal their ideas

I was once at a startup and another company in Texas released a product with identical typos as found in our object code.

Selling that software was how I got money to pay rent and buy food to put into my food-hole, so I'm going to feel a little more sympathy for people who want to stop others from reverse-engineering their stuff.

>customers Should Not and Must Not reverse engineer our code. However, if there is an actual security vulnerability, we will fix it. We may not like how it was found but we aren’t going to ignore a real problem...We will also not provide credit in any advisories we might issue. You can’t really expect us to say “thank you for breaking the license agreement.”

Until I read this, I didn't think it was possible for me to hate Oracle more, because I'm forced to work with their software and that makes me already hate them quite a bit.

Sure, but what else could they say publicly? Of course the most reasonable thing would be not to say anything at all and work together with the credible sources and provide something better than a threatening legal letter.

Lets just hope the black hat hackers read this and comply so we can continue to have "safe" Oracle software.

> the points were well made, at least from the perspective of a closed source, enterprise software vendor

I understand the sarcasm, on the other hand it really confuses me that those points are mostly what makes closed-source unattractive and exactly what a closed source, enterprise software vendor would not want to discuss openly. At least that's what I thought before reading the article. I find it more likely that the blog was (maybe still is) compromised.

"Stop using overzealous static analysis tools" is a fine point.

"Reverse engineering kills babies^Wmarriages and the contract says not to look closely at the software you paid for so you're a bad person" is a terrible point.

Yeah, I don't think this is really about anyone being surprised by anything they read in that post. It's more... what's a good analogy... like someone wrote a long post about the ethics and social conventions of pay phone use ten years after it became clear there would no longer be any pay phones. It's partly enjoyment of a spectacle, and partly pity, because it's so painfully clear how disconnected they are internally from what is actually happening in the world.

> Secondly, the reverse engineering is prohibited for ages - it's not that it was added to the license agreement yesterday.

That one is hugely dependent on jurisdiction. In place I live the right to reverse engineer is codified into law and can't be waived by an EULA.

> the reverse engineering is prohibited for ages

Not in some countries. Oracle would be against the law in that case, that's why people are unhappy.

I agree. I think (or at least hope!) that the juvenile style is rubbing a lot of people the wrong way, and thus inspiring them to be less charitable to the content than they otherwise might be.

Every programmer (myself included) who has had to discard bullshit reports about vulnerabilities agrees with the main idea -- that these things should be treated carefully, many of them are false positives and they may be borderline illegal, too.

The correct way to treat these reports is to review them (after all, who knows...) and try to educate those customers who send you bogus reports: explain why they're bogus, why reverse engineering doesn't usually provide good leads, explain them what easier steps they can take for additional security, and maybe remind them about that EULA. This can be done on an individual basis, politely, and Oracle, who seems to employ half the salespeople in this world, certainly has the resources to do so. If they can call me every two months to remind me about their great offers, they can write the standard answer that almost every such report warrants.

But no, instead they chose to dump a load of shit in the form of this blogpost:

1. It's written in the kind of condescending tone that makes you want to punch your interlocutor in the face. Such as: " That said, you would think that before gearing up to run that extra mile, customers would already have ensured they’ve identified their critical systems, encrypted sensitive data, applied all relevant patches, be on a supported product release, use tools to ensure configurations are locked down – in short, the usual security hygiene – before they attempt to find zero day vulnerabilities in the products they are using.". Surprise, surprise: a lot of people who start reverse-engineering binaries are either a) extremely security-conscious people, who, yes, already do those things, or b) extremely good programmers who work for people who -- again -- already do those things! There are exceptions, of course, but assuming that everyone who submits such a report is one of those imbeciles who dreams of Matrix hackers but runs a company where no computer has an antivirus installed is naive.

Or: "there are a lot of things a customer can do like, gosh, actually talking to suppliers about their assurance programs etc.". This sort of crap belongs on a cocky teenager's blog, not on a serious company's website.

2. It's all the more insulting to whine about it when the subtle message you're trying to convey is that zero-day threats aren't that a big deal: "And in fact, there are a lot of data breaches that would be prevented by doing all that stuff, as unsexy as it is, instead of hyperventilating that the Big Bad Advanced Persistent Threat using a zero-day is out to get me!". Yes, it's no problem to state this when you're some random blogger. It is a problem to state this when you're CSO of the company famous for producing the one plugin that's recommended to be disabled by default.

3. Because the argument about the license agreement is childish. After explaining in detail how, even if you were right, you're getting a threatening letter about the license agreement, a requirement to destroy all proof of reverse engineering and so on, she goes on to throw this gem:

"The main reason is that, when I see a spike in X, I try to get ahead of it. I don’t want more rounds of “you broke the license agreement,” “no, we didn’t,” yes, you did,” “no, we didn’t.” I’d rather spend my time, and my team’s time, working on helping development improve our code than argue with people about where the license agreement lines are. "

Well how about skipping that debate and fixing your fucking code, eh?

To put it in the same line as her argument, there are a lot of things Oracle can do in order to reduce the amount of false positives they get, such as fixing their disastrous security track record, improving their communication with the security community (no, blog posts like these don't count as communication for the same reason why hanging out a "fuck you" banner outside your office doesn't exactly count as better communicating with your colleagues, either) and so on. If people had better reasons to trust Oracle, there would be a lot less effort of this kind, too.

4. The analogies being used are demeaning to anyone who doesn't work in sales. Like this:

> Q. But one of the issues I found was an actual security vulnerability so that justifies reverse engineering, right?

> A. Sigh. At the risk of being repetitive, no, it doesn’t, just like you can’t break into a house because someone left a window or door unlocked.

Someone missed their first tech evangelism class, where they use that analogy for exploting, not reporting vulnerabilities.

Is it also wrong to call someone and tell them they left their door unlocked because their dog ran into it and it opened?

The whole things reads like "you guys are like the worst customers ever. We're smarter than you, we have lawyers and we knowz securitiez. Now shut the fuck up."

Oracle's, not Cisco's.

So the original popped up earlier on HN - was it resubmitted because Oracle have decided to delete it?

Original, pre-deletion discussion: https://news.ycombinator.com/item?id=10039202

I'm just waiting for the day some physical product manufacturer has the chutzpah to try to apply the "licensed, not sold" paradigm to a tangible product.

Let's wait and see if the Streisand Effect takes hold.

If it's a legal requirement, they can just sue you for breach of contract whenever they eventually find out that you didn't delete it.

Many large organizations log shell commands for audits. Those logs can be stored offsite by a third party to prevent alteration. See, for instance, the Goldman Sachs programmer arrested for stealing code. If the consulting group is professional, it will take these things seriously.

Not "prove". "Confirm". If you ask somebody to do something, they might do it, or they might not, whether out of passive malice or carelessness. Saying you have done something which you haven't done requires active malice, which is much less common.

That's pretty much the level of advice in the blog.

Astounding the author considers themselves a security professional.

Nice rant about Keynes at the end as well. I always find ranting about Keynes is an excellent way to keep hackers out.

I wonder how many customers Oracle is going to lose because of that piece?

It means that an HN moderator squashed its appearance on the top list. Why? They felt it wasn't constructive perhaps, considering the other thread against the original article is still live.

IMHO you are not. People from your company that weren't making you read EULA and promise to comply with it (in writing) will be responsible for your behaviour that breaks the EULA.

Its more like selling someone a meal in a restaurant, and refusing to let them see the kitchen. You can, if you are skilled, infer how the ingredients became your meal, but you won't ever know if it was done in a clean an safe way unless you can look at the environment where it was created. You could hire an investigator to figure this out, but there is a good chance that they know that there is more money in bad news than good. So they take photos of the dirtiest 'chef' who turns out to be the dishwasher, and show you the pictures of deliveries from Walmart, but choose not to show you the pictures of the chef getting up at 4am after finishing at 1am to drive to the fish market to hand pick the best of the catch.

I understand the risks of eating in places with closed kitchens, but ultimately they make better food than I can, that requires less of my time. It may be more expensive for unjustifiable reasons, and maybe I don't want to know how the black pudding is made, I just want to focus on what is important to me: making my wife happy.

Do I prefer to eat in restaurants with open kitchens, where the ingredient list and their source is available on demand? Sure. Am I a zealot about it..? It depends how hungry I am.

Oracle vs Oregon. Go check it out to see levels of arrogance that you would assume must be chemically driven.

Oracle is unbreakable, silly.

The crux of the article is that Oracle is getting so many unsolicited false positive security threat vulnerabilities that it's a distraction to their core business. They don't want "I found a hole in Oracle" to be an achievement like "I have my name on a patent."

Investigating security vulnerabilities takes a lot of time; and it's very easy to quickly get overwhelmed by false positives. I've seen quite a few analyses of code that I write; and most of them are warnings with no context or exploitability.

If every customer expected an engineer to respond to these, my team would spend all of its time in a "PR role," and wouldn't spend any time improving our products.

That is the web archive. It has nothing to do with HN.