Is it just me, or is the childish, mocking tone in the OP simultaneously baffling and totally befitting of the point they're trying to make? I understand that they're frustrated by the repeated submission of automated security vulnerability reports, but blanketing it entirely as "reverse engineering" and responding to it like this is... a strange approach.
Did someone at Oracle actually think that this was the best way to make this point?
In my opinion she is being paid for propaganda in support of Oracle. By that I mean the message is not beneficial to the whole population of Oracle Users, but only to Oracle Corporate.
Yeah, it's very poorly written. I always cringe when some exec thinks "oh, it's just a blog so I don't have to write with the same professionalism and attention to detail that I would in other corporate communications".
Well, it's not even 'just a blog', it's a blog hosted by oracle.com about the author's employment at same. The standard of professionalism should be higher given the direct link, methinks. If it were a personal blog on a personal topic, it wouldn't matter as much.
I think if recent history is any guide, a C-level who claims "you can't hold me accountable for stupid shit I say on my personal blog" isn't going to be one much longer.
If you read her previous posts you'll see it's the exact same tone and writing style. I think the claims of hacking are a way for people to express their incredulity and not meant seriously.
I hope you didn't "reverse engineer" her blog post. She's going to call up a judge and say "Nanny Nanny, Boo boo." (her own words).
But in all seriousness, if the Chief Security Officer of Oracle sounds like the letters to the editor of my University Paper, why doesn't a company that big have someone from PR edit or co-write her posts?
...unless the hackers also fabricated those and backdated them. Maybe that's giving them too much credit, but unless a trusted person claims to have read them in the past (and has perfect memory to claim they are unaltered too), or a trusted archive claims to have downloaded them in the past, how can you know?
Wow, she's the Chief Security Officer. I got the impression she was just a hired writer (she prefers writing murder mysteries?). This is looking really bad now, for Oracle's head of security to feel this way.
The arrogance is titanic. And her legal team apparently forgot to explain to her that certain jurisdictions permit reverse engineering and decompilation under certain circumstances irrespective of what Oracles license agreement says.
She has a point here. Static analysis does generate a lot of false positives, and it requires a pretty in-depth understanding of the code to determine whether any given hit is a real issue. Unfortunately, that sort of understanding doesn't usually come from just running a static analysis tool (or fuzzer, OWASP scanner, etc., etc.). The problem comes (and I have personally been on the receiving end of this) when running the tool results in a couple of dozen to a couple of hundred trouble tickets you can't simply ignore that say things like "I found a bug and if you don't respond I'm going to dump Oracle", "I found a bug and if you don't fix it on my schedule I'm going to post to HackerSiteDuJour" or "I found a bug pay me a bounty or I'm gonna make a big stink". And so someone will have to go and look at the report and "prove" that just like 99.999% of the time, it's a false positive, and they will have to do that for every "security" person who cranks up a tool and finds the same "vulnerability".
The problem here is:
1) She might be a writer but boy did she not convey the message I think she wanted to, which is kind of a shame.
2) She doesn't apparently much understand "reverse engineering" with more nuance than "my legal team says you can't do it so there", which is much more of a shame for someone who carries a CSO bag.
Oracle cannot ignore annoying and low-expected-value static analysis tickets, but:
1) the answer should usually be either "fixed in this patch, install it" or "it's a false positive, try developing an actual exploit if you don't believe us". Not expensive, provided Oracle actually runs static analysis tools against their software and addresses the findings before releasing updates.
2) If Oracle actually runs static analysis tools against their software and addresses the findings before releasing updates, there should be very few tickets of this type to begin with, often from the debut of new tools or from naive user mistakes. Finding something, and worse finding something over and over again, means that Oracle QA is inadequate.
Ah...you've never used one of these tools on a large code base. The problem is that when I run the tool in my QA environment, I identify the false positive and configure my tool to account for the false positive (or I create a compensating control). If you run the same tool, you'll see everything I tuned out, and I then have to go back and trace where the finding was tuned out, why it was tuned out and make sure that's still right. It's not inexpensive when multiplied by hundreds of times. And that's if you use the same tool as I am; if you're running different one, we just as well could be starting from scratch.
Finding something, and worse finding something over and over again, means that Oracle QA is inadequate.
By what delusion do you think it's not the tool finding the same false positive over and over that's inadequate. The tools are not perfect, and often their developers are very obstinate in what they consider a finding.
Silencing false positives when one runs static analysis tools is only enough for the purpose of a single bug-finding campaign, not for a sustainable effort.
To deal with false positive reports from customers, Oracle needs to archive what the false positives in each release of their software according to popular tools are. Not the tools they use to find bugs: all tools customers use. It's not like they cannot afford tool licenses or large databases.
Adopting a code style that reduces false positives (along with bugs) and fixing actual problems before release so that no customer sees them would also be good policies.
Even without improving their software development process, educating users about which static analysis tools are discredited and rigorously demanding working test cases in support tickets to weed out false positives are two things Oracle could do without alienating their customers.
Oracle needs to archive what the false positives in each release of their software according to popular tools are.
Oh, wow! How could we be so stupid. All we have to do is build a false positive database of all tools, everywhere. Don't forget for all versions. Not just all versions of the tools, all versions of your code. And whenever a new tool or version comes out, rerun everything. Because inevitably some guy limping along with Oracle 8 is going to download the latest Parasoft release and he's gonna what a word with you because probably Parasoft doesn't even have an Oracle 8 instance laying around any more. No problem!
Adopting a code style that reduces false positives...
Force coders to change their style because "AppScan v6.00.01 patch 10 throws a falsy on this expression in version 11i patch 200". Sure, why not...fuck those guys. People should be slaves to the tools, not the other way around.
rigorously demanding working test cases
Forcing your 400k some odd customers to come up with test cases for your code before you pay attention to the vulnerability reports they genuinely believe are important. That sure won't alienate customers at all.
Proof once again how easy it is to wave ones hand over a complicated subject one doesn't fully understand, assign simple (and wrong) solutions based on limited information and declare others inadequate.
I doubt there is such a flood of false positive reports from customers misusing static analysis tools as the article complains about, but as far as Oracle wants to do something about them minimizing the cost of writing off a report as a false positive is the only rational solution. (Complaining about reverse engineering is not rational.)
Investigating analysis tool reports once and for all is the only way to minimize this cost. You seem to neglect various cost-mitigating factors:
- Reports from different tools are going to hit the exact same spots in code, for the same reasons, making the marginal cost of analyzing the report from yet another tool low and decreasing and making the matching between support tickets and known false positive reports very easy. Closing tickets as vague would also be easy.
- Reports for version N and version N+1 of the product are going to be very similar. Likewise for version N and N+1 of a static analysis tool.
- Only popular (and good) analysis tools deserve up-front usage before releasing products. Others can be run only after someone files reports, and for the most unlikely ones being unprepared is the best choice. There's no value in a strawman like complete coverage of all possible tools.
- Static analysis tools are useful. Using them thoroughly would provide significant value beyond the dubious niche of reverse engineering support tickets.
It wouldn't surprise me. Oracle certainly runs the same static analysis tools against their own stuff, and fixes anything legitimate.
But notice the other comment about a "well-known security researcher" "alleging" vulnerabilities that yee-haw we're already working on fixes for so we're awesome and he's lame and nanny nanny boo boo etc.
Serious cognitive dissonance there. I used to buy a lot of Oracle product. Their value proposition has grossly weakened over the last decade and a half or so, so I don't any more. But if I did, I'd be embarrassed today.
She has no idea what she is talking about. Nobody is running static analysis on source code and sending her results. She's mixed up a lot of concepts here and is just plain wrong.
Somehow this CSO is unaware of binary static analysis, ala Veracode. You can still get plenty of false positives from binary SAST, but it's NOT de-compilation.
My question would be whether binary SAST falls under the prohibition against reverse engineering. I wouldn't think so, but that's one for the lawyers unfortunately.
This is an embarrassing subthread. I'm sorry to spoil an opportunity for people to feel like they're smarter than an executive that just wrote a lot of dumb things in a blog post, but not only does Mary Ann Davidson know about Veracode, she's semi-famous for hating on them.
Meanwhile: a huge portion of everything Oracle ships is Java, and consultants absolutely do run Java security scanners on decompiled jar files from Oracle products.
"A customer is almost certainly violating the license agreement by using a tool that does static analysis (which operates against source code)"
It's a stretch to interpret this as an admission that it's only a license violation when decompilation to source is involved. I read it as "all static analysis operates against source code".
It's hardly embarrassing to point out that important detail, and I don't think it's fair to assume that the motivation for correcting the error is "to feel smarter than" the one who made it.
The statement itself is basically 98% false. I've been a Coverity user since very early days, and have used a few other static-analysis tools as well. Every such tool that I've seen runs multiple separate kinds of checks. Yes, the false positive rate for some of those checks can be alarmingly/annoyingly high. OTOH, any software developer with half a brain can see that other checks are much more accurate. Some are darn near impossible to fool. If you focus on those, you can find and fix a whole bunch of real bugs without too much distraction from false positives.
Her statement gains 1% truth because Oracle might already have picked the low-hanging fruit, and any more reports they get really are full of chaff. I find this unlikely, but it's possible. She gets another 1% for this.
> A customer can’t analyze the code to see whether there is a control that prevents the attack
That's actually a pretty decent point. Anyone who has actually studied static-analysis reports for any length of time has probably encountered this phenomenon. For example, you might find a potential buffer overflow that's real in the context of the code you analyzed, but the index involved can't actually be produced because of other code that you didn't. Or maybe a certain combination of conditions is impossible for reasons related to a mathematical property that has been thoroughly vetted but that the analysis software couldn't reasonably be expected to "know" about. Ironically, these kinds of "reasonable false positives" tend to show up more in good programmers' code, because they're diligent about adding defensive code handling every condition - including conditions that aren't (currently) possible. In any case, while it's a good point, it's applicable rarely enough that it doesn't really support the author's broader position.
This is diametrically the opposite of my experience with source code scanners.
I think the impedance mismatch here might be that you're a software developer, and we're talking about security teams.
I don't know that anyone is arguing that static analysis is useless for developers. If you're intimately familiar with the code you're working on, there are probably a lot of ways to make static analysis results both valuable in every edit/compile/debug cycle, and an important part of your team's release process.
But when you're close to the code, it's easy to forget how much of the tool's output you're ignoring (either literally, by just skimming past findings you know don't matter, or implicitly, by configuring the tool to match your environment or subtly changing your coding style to conform to Coverity's expectations).
Security teams can't generally do this. They're stuck with the raw output of the barely-configured tool. The results of static analysis in these circumstances is nonsensical: memory leaks, uninitialized variables, race conditions, tainted inputs reaching SQL queries, improper cleanup of sensitive variables, 99.9% of which aren't valid findings, but all of which look super important, especially if you're consultant with 6 months of experience charging $150/hr to run Fortify on someone else's code, then petulantly demanding a response for every fucking issue the scanner generates.
They're fine dev tools, but they are terrible tools for adversarial inspection, which is what Davidson is talking about.
If somebody's paying a consultant hundreds of dollars an hour to run a static analysis tool and forward the output, without applying a developer's skills in between, they've been defrauded. Static analyzers are coding tools, much like compilers. Their input is code. Their output is pointers to code. True adversarial analysis, or any other endeavor involving static analysis, requires something extremely close to a coder's skill set. I guess if I believed otherwise then I might be tempted to take Davidson's side too, but that's not the case.
Static analysis probably does generate basically 100% false positives.
Organizations that manage to operationalize code scanners usually spend many months with full-time staff configuring them and tuning their output --- most of which is nonsensical, for instance randomly assuming dynamic memory is leaking, or that a local variable enables a race condition. There is a whole cottage industry of consultants that does nothing but this.
When all that work is done, the team still needs a Rosetta Stone for the issues they actually do investigate, one that is highly context sensitive and dependent on the different components of their application. For instance, a Fortify or Coverity issue might be bogus in 90% of cases, but actually relevant to one particular library.
There is from what I can tell no source code scanner on the market that will take a product sight unseen and produce a report from which real vulnerabilities can be extracted with a reasonable amount of effort.
There are, on the other hand, many consultancies that will do "point assessments" --- ie, not the long-term shepherding and building of a static analysis practice, but just looking at one release of one product for flaws --- that consist mostly of running a "static" tool like Fortify and a "dynamic" tool like WebInspect, and then handing off the report.
Davidson's take on licensing and security inspection is embarrassing, but she is not at all wrong about consultants and security tools.
Wow. Someone's been hitting the Kool-Aid pretty hard.
I've seen this institutional hubris first-hand. The unshakable belief (typically by nontechnical management) that all of the smartest people in the world are employed here, working for me.
Yup. It's not like those customers that are busy reverse engineering Oracle's code are doing it for the kicks. They have their own jobs to do. Much more likely, they are getting weird results out of Oracle's software that they don't understand, so they reverse engineer the code to see why the system is crashing / giving unexpected results so that they can find a workaround without having to wait for the vendor to fix their bug.
Then, if it turns out that it's a security issue, of course they are going to notify Oracle of the fact, both as a moral duty, and because it makes it more likely that Oracle will get a patch out faster.
Oracle whinging about people finding bugs in their code would be better off trying to improve their processes so that there are less bugs to find, rather than complaining that they've been found out for shipping buggy code.
I actually understand how it gets to be this way though.
I literally can't touch a Government project without an Oracle license. When I talk to a salesman, the attitude is "I know you can't do this without me", contrary to salesmen for any other product in any other industry.
When I talk to a project manager, they don't ask how it will be hosted, or what the platform will be, or anything else obvious. The first question, often before a project is fined, is "how many Oracle licenses can I buy?".
Oil/Gas exploration. In my former job, pretty much every major piece of software that we sold to customers had at least an embedded Oracle DB as part of the install.
Oracle is very popular for mission-critical databases in banks. I've seen Sybase used in banks too but it's definitely less popular now than it used to be.
Indeed, it does tend to end badly, and the best example is a company that ended up being bought by Oracle. The arrogant tone of this post reminds me very much of the flurry of blog posts that came out when ZFS and DTrace were first introduced. Remember "The Last Word in File Systems"? That kind of arrogance, complacency, and impatience with interlocutors is mildly annoying to developers elsewhere. It's more than annoying to customers, and to sales people who feel unsafe pushing products whose developers continually undermine them. That's why Sun is no more. Oracle might want to consider that before they start relying on this kind of astroturf to convince anyone of anything.
I don't think the particular kind of arrogance that Oracle has goes away except by being killed. Heck even once the former sales guys are homeless under a bridge I doubt they would see the connection, they'd still be spinning yarns about when they worked for the greatest tech company ever.
Ditto for the engineers. The kind of engineer who contributes to a culture like that in the first place will also be constitutionally incapable of accepting that their own behavior contributed in any way to the demise.
I didn't say it was unremarkable, Mr. Strawman. However, it wasn't the "last word" either. If it had been, there wouldn't have been so many generations of major change to it since then. It's possible for people to be good at what they do but still nowhere near as good as they think, and that pretty accurately described a lot of Sun engineers at that time. The answer to all criticism, including that which history has shown to be completely accurate, was never anything but a sneer. It was the most anti-collegial attitude ever, and the industry is worse off for it.
That's ridiculous. If it had not laid the foundation for all those generations of major changes to be possible at all (without substantial re-architecting), why would they have called it that?
By the way, since you're apparently a subject matter expert, what kernel would you recommend for arrogance-averse users? Certainly not Linux or OpenBSD?
Remember the classic Can't Break It, Can't Break In campaign several years ago. It yielded a bunch of new bunch and exploits in Oracle SW in a few days. They seem not to have learned.
The submitted title ('Oracle CSO: ~“Only we can do security, trust us and do not reverse engineer”') breaks the HN guidelines: it's editorialized (whatever one thinks of the article), and it's a quote-looking-thing that isn't a quote, so misleading.
Please don't do this. The HN guidelines ask you to use the original title. If that's really not suitable, a subtitle or some representative language from the article is ok. But putting your own spin on it is not ok. HN's goal is to let readers make up their own minds, and for that we need accurate, neutral titles.
We've changed the title to a representative phrase from the article, and can change it again if someone suggests something better.
Just today I was arguing for not moving something off of Oracle. No one's really happy the thing in question is on Oracle, but it is live in production and most of the time does what it needs to. It ain't broke. Changing to "something else" carries way too many unknowns for my comfort level.
If I'd read this last night... I still would've argued the same thing, but I would've been really unhappy about it.
There are too many points to discuss... it's really quite insane especially on the backs of Java exploit after Java exploit.
But what I really don't get is this bug bounty hateathon. If it's only 3% of bugs (currently WITHOUT incentives like a bug bounty), then that's really not that much money... and in return you get more cred, something you might use for recruitment, and the off chance that you might increase that 3% versus something going on the black market. Even more so, how much could this really cost!? And Oracle has how much money?! If you can't spend that on a bug bounty when you're security is just so awesome as the post contends, then something is really in trouble.
The repeated Java exploits You're referring to are exposed when using Applets in a browser ... This was conventionally recognized as a bed idea in about 2006. You simply shouldn't allow Applets to run - no matter what. I think you'll find the rest of the Java platform more secure than most, especially since the OpenJDK foundation was formed. I'm not here to defend Oracle in any other way but they've done a reasonable job of advancing the Java platform since it was acquired.
That's only true if Java's signature validation isn't vulnerable (or at least is no more vulnerable than the signature verification for a normal OS).
Searching around, it looks like there was at least one vulnerability like this, in which Java failed to check certificates for revocation, and at least one exploit was found in the wild signed with a stolen, revoked certificate that Java still accepted.
This is especially fun because Java at least tries to sandbox unsigned applets, but signed applets get a lot more privileges.
That doesn't change the facts. Flash has had more zero days than Java. Your browser, regardless of which one you are using, has had more zero days than Java.
Flash has nothing to do with it. The browser doesn't either, which receives updates much more frequently as well and is fundamentally necessary (compared to applets).
My point is that Java keeps having security vulnerabilities some of which are exploitable from the web. There's a reason why Oracle keeps releasing patches. Even more important is my main point that the reasoning given against a bug bounty program is idiotic, especially on the backdrop that they do in fact have security vulnerabilities on a regular basis.
So, I disagree with the poster on a bunch of things here (no surprise, really).
But: this is authentic. This is what we (i.e. hackers) are always claiming we want. Someone speaking her mind, shooting from the hip, etc. Not an anodyne blob of corporate-speak: this is an opinion, stated pretty clearly, and backed up with fighting words.
You'd expect: "Our legal team has advised us to remind consultants that they are bound by any and all terms and conditions to which their clients have ... etc. etc. etc."
You get: "Otherwise everyone would hire a consultant to say (legal terms follow) “Nanny, nanny boo boo, big bad consultant can do X even if the customer can’t!”"
Here we have someone who clearly loves the company and the product with a passion, defending both against what she sees (very wrongly, in my opinion) as criminal misuse and waste of resources.
I'll take one of these posts and argue its merits any day, over a block of mealy-mouthed corporate crap.
I think a lot of blog posts like these get triggered by some acute event which pushed the writer over the edge, and it's expected this will shine through in the text. The rest is probably due to living in an employer-typical bubble.
If I was an Oracle customer (which I will never, ever be) I would appreciate the honesty. This honesty enables me to make purchase decisions as well, better than megabytes of legalese would have. In this case it's not a really surprising attitude given the company, but I really wish more vendors would be as open about the nature of their intended relationship with their customers.
You cannot swear you will never be an Oracle customer. You buy a service from a third party, the company get bought by Oracle, you are a customer now. In many instances in B2B systems, it is a lot more pain to migrate away than sending a check...
Not sure jumping on such a minor point is a productive use of our time, but just for the sake of clarification: sure I can, personally. You have no basis for disputing my intention. I have never in my life made a decision to purchase a service that could only ever be provided by a single company, and with good reason I believe. Over my contracting years, I have also gained enough insight into the dynamics customers have with providers such as Oracle, enough to avoid this kind of lock-in at all costs in my own decisions.
In my honest and not-so-humble opinion, the tendency to attribute arrogance to Oracle is by no means "undue" (which is required for the parent comment to fall victim to FAE).
I think it's an accurate representation of her employer, however.
Interesting that all the reasons she cites for why she thinks trying to reverse-engineer Oracle products is a bad idea are the same exact reasons why more and more administrators with any sense in security are switching to open-source software and have been for the last decade or so. Being able to inspect the code yourself (or hire someone to do it for you) is apparently important enough to a sufficiently-large population for Oracle to whine about it.
The tone obfuscates the message. I don't think it's hatred so much as bewilderment that someone in an executive position at a huge tech company would present an argument about customer behavior this way.
I felt embarrassment for the writer and Oracle. The fact that it was taken down confirms they felt that way as well upon reflection. It wasn't professional. Just my opinion.
The blog post is as authentic as a big pile of rubber dog shit. The faux-folksy patina does nothing to hide the utter contempt Oracle has for their customers.
In those cases, the difference is that the end result of the projects they command - Linux and OpenBSD, respectively - are free software, and therefore ultimately respect the user by providing said user with the various essential freedoms. This is in stark contrast with Oracle's software products, which are not only proprietary, but repressively so.
The hostility is also usually confined to those on the development mailing lists of those respective projects (which are implied to be meant for developers, not end-users). It's also with full understanding that - if someone doesn't like how Torvalds or de Raadt run their respective projects - they're welcome to fork (even if said forking rarely happens in practice).
The reason why I pressed for specifics is because there are some personalities in the FOSS world who - while still not in Oracle realm of dickery - probably would come close if given the ability to. Mark Shuttleworth comes to mind, being outright hostile to user feedback on things like Unity, Mir, the Amazon Shopping Lens, etc. (as opposed to the interdeveloper harshness characteristic of Torvalds and de Raadt).
I very much don't agree, the only time I've seen writing like this is when someone is deeply frustrated about something.
I don't think it's an unreasonable fairy tail to say this is a person who is frustrated, who has drunk the corporate kool-aid in a big way, who is dealing with the detritus of a rather nasty security confidence scam industry, and is putting their views out there. Even if you or I don't like the message, I believe she meant it. I believe it. Maybe I'm gullible.
FWIW, I have no objection to the folksy tone. It's more to the opinions that she's expressing, and worse, to their consequence. The fact that Oracle objects to anyone trying to figure out where the holes are in their software says a lot about why there are so many holes in their software.
> But: this is authentic. This is what we (i.e. hackers) are always claiming we want. Someone speaking her mind, shooting from the hip, etc. Not an anodyne blob of corporate-speak: this is an opinion, stated pretty clearly, and backed up with fighting words.
We also want intelligence and clear thinking along with it. We don't, as a rule, want loud and dumb as a bag of rocks. That way lies Donald Trump.
At the same time, this is a huge improvement over corporate doublespeak. It helps the stupidity and arrogance shine through clearly, which is one reason that I like it when people talk this way.
If someone does one thing you like, among a bunch of other things you don't like, you can still complain about all the other stuff.
It's like if I say I wish people would stop murdering people with guns so much, then I get stabbed in the chest and you say, hey, isn't this what you want, people not using guns?
I laughed at this line where she tries to prove her point by touting that Oracle already found a bug that a security researcher reported to them (but wasn't fixed yet):
"(Small digression: I was busting my buttons today when I found out that a well-known security researcher in a particular area of technology reported a bunch of alleged security issues to us except – we had already found all of them and we were already working on or had fixes. Woo hoo!)"
It sounds like they've confused a) users submitting results from static analysis that wastes time, b) users submitting demonstrable vulnerabilities, and c) license agreements.
a) is bad, and the users should just be turned away. b) is good and far better than selling them on the black market. c) is... who cares it's a license agreement.
She's mostly focussed on (a), it seems, and I can understand the frustration - all too often we get lengthy missives from client consultants along the lines of "Ran scanning tool. Suggests that the version of PHP.net you are using is vulnerable to LSASS and STUXNET vulnerabilities, our client is terrified, pay me off to make the pain go away." We get a genuine vulnerability reported once in a blue moon.
(b) is good, but her point that them spending their time doing static analysis of oracle's software is a monumental waste of time is perfectly valid, if their root password is password and the firewall is just some sheetrock in the basement.
> 1 Any person who has the right to use a computer program may obtain, either personally or through a third party, necessary information on the interfaces by decoding the program code using independently developed programs.
> 2 The interface information obtained by decoding the program code may only be used for the development, maintenance and use of interoperable computer programs insofar as neither the normal exploitation of the program nor the legitimate interests of the owner of the rights are unreasonably prejudiced.
I wonder to what extent "interoperability" (a common exemption for allowing Reverse Engineering in US and EU) might include "security validation" and thus make this generally legal regardless of EULAs.
Are you sure that's an accurate statement about how it actually works in practice? Given you're answering a comment citing the precise law written to affect such private contracts when enacted in France.
AFAIK portions of EULAs can be nullified by local law. For example, imagine if I made some incredibly useful piece of software and placed assassination requests in the EULA.
Source: by logical extension of: the "no refund" portion of game EULAs is nullified in EU. I'm no lawyer, though.
It doesn't matter though. Even if Oracle can legally stop customers and researchers from reverse-engineering their software world-wide, they can't stop malicious elements because the malicious elements never disclose that they have done it: Oracle only find out after they have been pwnd. I would say "serves them right," but the sad truth is that their customers are going to get hurt the most.
Edit to add: I don't think this[1] warrants an entirely new post.
> Oracle has told people to stop using @Veracode to test their AppSec. They already got AppSec covered [picture of JS injection attack in the blog post]
- mandatory (cogent - may be wrong term for English law) - this clause is valid as it is in law and cannot be overridden by contract,
- non-mandatory (dispositive - again, the term may be wrong for English law) - where the clause is a default or baseline that is valid, unless the contract parties agree on something different.
Unfortunately for Oracle, in most countries the law allowing for reverse engineering (for purpose of interoperability and security) is the first kind, not the second.
Don't some types of contract require a CYA clause along the lines of "if any part of this contract is invalid, the contract only covers those parts that are valid", though?
I'm not sure whether this is just voodoo or whether those contracts would otherwise be nullified as soon as you point out any single clause is actually invalid.
Yes, a Salvatorian Clause is normally necessary, but this law was specifically written saying that the clause in the contract just doesn’t apply. The rest of the contract stays valid.
The "Do not break DRM" on Computer Software is equally invalid. (Warning: the "Do not break DRM" on music and video is a criminal offense on the other hand).
DISCLAIMER: I am not a lawyer, this is not legal advice, if you consider to use this as defense in a court, you might want to consider getting an attorney. Details can matter depending on your jurisdiction.
I'm pretty certain that national law takes precedence over what someone put in a contract.
Example: It works like this for tenancy agreements in Germany. Your landlord can say that you're not allowed to change the locks all they want, and even if it's in the tenancy and you signed it, it's still null and void.
Another example for tenancy is that your landlord can not prohibit you from keeping small pets[0] (including cats) even if you sign it.
Another example is that EULAs are prohibited by law from containing any clauses that a customer could not reasonable be expected to assume to be in them. This hit WhatsApp when it tried to ban users who used unofficial clients (which would not violate the EULA of most other messaging services and can therefore not be prohibited simply by adding a clause to the EULA).
[0]: within reason, obviously. The landlord would have to prove that the pets present an unreasonable nuisance to your neighbours or cause unreasonable amounts of damage to the landlord's property.
>I'm pretty certain that national law takes precedence over what someone put in a contract.
Yes but only if the law says that you can't create a contact that signs away that right.
For example, in the USA you can reverse engineer. Totally legal. But you can also sign away your right to reverse engineer. That is what a contract is, signing away your rights.
But the US could also pass a law saying it's illegal for a EULA to prevent reverse engineering.
So just finding a law that says reverse engineering is legal, doesn't mean a court won't hold you to a contract that prevents reverse engineering.
That said, it's probable that some countries have banned contracts that prevent reverse engineering.
Not sure about the laws in your country but I am pretty sure that at least in most EU countries legal contracts between two private entities can not trump laws.
The parts of the contract that do are not valid and thus can not be used as an excuse to break the contract (revoke the license).
They could refuse to do any business with you in the future, but I'm pretty sure they can't revoke your existing license for breaking an unenforceable clause.
This is a marketing layup for any FLOSS ERP company (or the PostgreSQLs of the world). Basically "by all means check our code for any issue you may find. We'll gladly accept any suggestions for code improvements you may have."
This post is an absolute nightmare/facepalm. Basically my takeaway is "I guess I don't want to buy Oracle software". It's really mind blowing that this is the position of a major software company in this day and age. I mean I guess I shouldn't be shocked since it is in the EULA but man I'm kind of speechless (this clause has to be illegal in some countries, too).
Edit: as an aside as a bad guy this would make me very interested in reverse engineering Oracle products. If they disallow it for their customers the reaction times to any security issues will be lower and it will be pretty valuable to find bugs in their products.
Edit2: Seems like the blog was cracked. At least the "About" on the side seems to indicate that.
If you dump a 400 page output dump of some static analysis tool on a FOSS project, not much will happen either. They will probably challenge you to find the actual issues yourself and enter bug reports.
My takeaway is that tone from them (Oracle) is "We're doing a service to you for even letting you buy our stuff". The audacity of high-horsness(!) is overwhelming.
> Q. If you don’t let customers reverse engineer code, they won’t buy anything else from you.
> A. I actually heard this from a customer. It was ironic because in order for them to buy more products from us (or use a cloud service offering), they’d have to sign – a license agreement! With the same terms that the customer had already admitted violating. “Honey, if you won’t let me cheat on you again, our marriage is through.” “Ah, er, you already violated the ‘forsaking all others’ part of the marriage vow so I think the marriage is already over.”
What a thoroughly nasty comment. She is comparing her customer with someone who is cheating on their spouse. Disgusting.
> Because her text will probably only infuriate people that will arguably never be Oracle customers?
As a sysadmin with customers who run oracle, and who put some stock in what I say, I can say I am more likely to warn people away from oracle in the future. While in some companies, tech purchasing decisions are made by suits with little or no input from techies, that's not universal.
If Oracle won't sick the sales people on your upper managers if they even get wind that someone at the company want's to move away, you're just not a large enough customer and Oracle doesn't give a shit if you move.
Could be a ploy like how many scammers use poor spelling and grammar so that they don't waste their time chasing up people too smart to fall for the scam.
Except it is if you are really concerned about security or have a backbone Oracle don't want to waste time on trying to sell to you.
I can only assume you've never dealt with Oracle. This is Oracle. Once your business is reliant on their products, this is how they act, because they can.
She also missed the fact, that there are things called laws. If the non-overridable (cogent) clause in the law says I can do reverse engineering for purpose X, I can do that and what is in license agreement is not relevant at all.
This is one of the finest pieces of Postgres marketing I can recall seeing in recent times. They've made the case for open source better than anyone in 2015.
(We're in the midst of an Oracle->Postgres conversion right now. It's going wonderfully. I strongly advise you to look into it, bet you'll find it way easier than you think.)
(One of the nicest things about it: we give every app its own cluster of two PG boxes, because you can just do that instead of running a centralised monster box with an expensive license. It turns out that just everything not having to play nice with others makes stuff stupendously easier to manage.)
Failover pair with a primary and standby. The primary streams write-ahead log records to standby as they're generated. Some script gaffer-tape to watch for primary failure and fail over. I think we haven't ever yet actually had to invoke this though :-)
This was all cobbled together following the docs. There are almost certainly better ways to do everything we've done so far.
The Postgres is just 9.3 out of the Ubuntu 14.04 repo. Oracle was STUPENDOUS overkill for what it was actually being used for, but MySQL wasn't up to the job.
I like it that Oracle openly publishes this kind of blogs. I would personally never work for a company which expects me to develop anything using Oracle gear. It's simple. I can always find another company that doesn't and that pays the same or better. That is also why I suspect that someone who works in those circumstances really has to, because he has no other options.
I don't understand why everybody is mad about this post, oracle has proprietary software that is bound with a license.
In that sense I don't see why people do not moan about having to pay a rent because your tenancy contract that you signed says so...
Long story short, its a right of a SOFTWARE mostly company to protect its software, open source is not always the solution and reverse engineering something, consumes way more energy for the problems it actually solves.
> open source is not always the solution and reverse engineering something, consumes way more energy for the problems it actually solves.
You think customers are reverse engineering Oracle products for fun? They're doing it because there's a problem somewhere, they've filed a bug report and not got a satisfactory result, and so they have to go pay an expensive consultant to try and track down the problem for them with no source code.
Even if none of the other arguments for open source were persuasive, this situation with Oracle alone would be enough to convince many people of the wisdom of choosing an open source vendor.
Your boss is unlikely to pay you for it. The companies using Oracle software are usually not in software (database) development themselves, so there's no business incentive to pay you for having "fun" with expensive software.
I think reversing for fun is great! But it's pretty unlikely that Oracle customers are doing it for this reason. Instead, I suspect their reversing is borne of desperation.
> its a right of a SOFTWARE mostly company to protect its software
They also have a duty of care to their clients
> open source is not always the solution
No one saying it is. Plenty of other proprietary software vendors protect their softwaqre in customer-friendly ways.
> reverse engineering something, consumes way more energy for the problems it actually solves
When a vendor like Oracle gives you no other option to solve the very real problems that your company has with the software, the "energy consumption" can be more than worth it, even it wasn't the ideal path in the first place.
I'm surprised to see the "no one is saying it is" in this context. You don't have to look far on HN to find considerable numbers of people expressing categorical opposition to proprietary software licensing, although it remains a minority view here.
A software maker has no particular right to control what I do with that software once I have it.
In terms of a rental agreement, a "no reverse engineering" clause is not equivalent to "you must pay rent." It's more like a clause that says you're not allowed to consume meat while you live there because the landlord is a vegetarian.
I don't understand why everybody is mad about this post, oracle has proprietary software that is bound with a license.
In that sense I don't see why people do not moan about having to pay a rent because your tenancy contract that you signed says so...
Long story short, its a right of a SOFTWARE mostly company to protect its software, open source is not always the solution and reverse engineering something consumed way more energy for the problems it actually solves.
> Generally, our code is shipped in compiled (executable) form (yes, I know that some code is interpreted). Customers get code that runs, not the code “as written.” That is for multiple reasons such as users generally only need to run code, not understand how it all gets put together, and the fact that our source code is highly valuable intellectual property (which is why we have a lot of restrictions on who accesses it and protections around it).
Your JDBC driver IP isn't that valuable, just give me the damned source code so I can figure out why my Postgres copy out stream is blocking when I insert it into your copy in stream.
357 comments
[ 4.8 ms ] story [ 135 ms ] threadDid someone at Oracle actually think that this was the best way to make this point?
I'd blame the CMS before the author on that point though.
There was another post in much the same vein on that blog:
https://blogs.oracle.com/maryanndavidson/entry/those_who_can...
Just one of many nuggets in this other arrogant posting. If somebody needs input why FOSS is better than closed source have a look into this one also.
But in all seriousness, if the Chief Security Officer of Oracle sounds like the letters to the editor of my University Paper, why doesn't a company that big have someone from PR edit or co-write her posts?
My guess is that she's senior enough to veto attempts to salvage her prose.
https://web.archive.org/web/20140313161522/https://blogs.ora...
The problem here is:
1) She might be a writer but boy did she not convey the message I think she wanted to, which is kind of a shame. 2) She doesn't apparently much understand "reverse engineering" with more nuance than "my legal team says you can't do it so there", which is much more of a shame for someone who carries a CSO bag.
1) the answer should usually be either "fixed in this patch, install it" or "it's a false positive, try developing an actual exploit if you don't believe us". Not expensive, provided Oracle actually runs static analysis tools against their software and addresses the findings before releasing updates.
2) If Oracle actually runs static analysis tools against their software and addresses the findings before releasing updates, there should be very few tickets of this type to begin with, often from the debut of new tools or from naive user mistakes. Finding something, and worse finding something over and over again, means that Oracle QA is inadequate.
Finding something, and worse finding something over and over again, means that Oracle QA is inadequate.
By what delusion do you think it's not the tool finding the same false positive over and over that's inadequate. The tools are not perfect, and often their developers are very obstinate in what they consider a finding.
To deal with false positive reports from customers, Oracle needs to archive what the false positives in each release of their software according to popular tools are. Not the tools they use to find bugs: all tools customers use. It's not like they cannot afford tool licenses or large databases.
Adopting a code style that reduces false positives (along with bugs) and fixing actual problems before release so that no customer sees them would also be good policies.
Even without improving their software development process, educating users about which static analysis tools are discredited and rigorously demanding working test cases in support tickets to weed out false positives are two things Oracle could do without alienating their customers.
Oh, wow! How could we be so stupid. All we have to do is build a false positive database of all tools, everywhere. Don't forget for all versions. Not just all versions of the tools, all versions of your code. And whenever a new tool or version comes out, rerun everything. Because inevitably some guy limping along with Oracle 8 is going to download the latest Parasoft release and he's gonna what a word with you because probably Parasoft doesn't even have an Oracle 8 instance laying around any more. No problem!
Adopting a code style that reduces false positives...
Force coders to change their style because "AppScan v6.00.01 patch 10 throws a falsy on this expression in version 11i patch 200". Sure, why not...fuck those guys. People should be slaves to the tools, not the other way around.
rigorously demanding working test cases
Forcing your 400k some odd customers to come up with test cases for your code before you pay attention to the vulnerability reports they genuinely believe are important. That sure won't alienate customers at all.
Proof once again how easy it is to wave ones hand over a complicated subject one doesn't fully understand, assign simple (and wrong) solutions based on limited information and declare others inadequate.
Investigating analysis tool reports once and for all is the only way to minimize this cost. You seem to neglect various cost-mitigating factors:
- Reports from different tools are going to hit the exact same spots in code, for the same reasons, making the marginal cost of analyzing the report from yet another tool low and decreasing and making the matching between support tickets and known false positive reports very easy. Closing tickets as vague would also be easy.
- Reports for version N and version N+1 of the product are going to be very similar. Likewise for version N and N+1 of a static analysis tool.
- Only popular (and good) analysis tools deserve up-front usage before releasing products. Others can be run only after someone files reports, and for the most unlikely ones being unprepared is the best choice. There's no value in a strawman like complete coverage of all possible tools.
- Static analysis tools are useful. Using them thoroughly would provide significant value beyond the dubious niche of reverse engineering support tickets.
But notice the other comment about a "well-known security researcher" "alleging" vulnerabilities that yee-haw we're already working on fixes for so we're awesome and he's lame and nanny nanny boo boo etc.
Serious cognitive dissonance there. I used to buy a lot of Oracle product. Their value proposition has grossly weakened over the last decade and a half or so, so I don't any more. But if I did, I'd be embarrassed today.
Somehow this CSO is unaware of binary static analysis, ala Veracode. You can still get plenty of false positives from binary SAST, but it's NOT de-compilation.
My question would be whether binary SAST falls under the prohibition against reverse engineering. I wouldn't think so, but that's one for the lawyers unfortunately.
Meanwhile: a huge portion of everything Oracle ships is Java, and consultants absolutely do run Java security scanners on decompiled jar files from Oracle products.
"A customer is almost certainly violating the license agreement by using a tool that does static analysis (which operates against source code)"
It's a stretch to interpret this as an admission that it's only a license violation when decompilation to source is involved. I read it as "all static analysis operates against source code".
It's hardly embarrassing to point out that important detail, and I don't think it's fair to assume that the motivation for correcting the error is "to feel smarter than" the one who made it.
Her statement gains 1% truth because Oracle might already have picked the low-hanging fruit, and any more reports they get really are full of chaff. I find this unlikely, but it's possible. She gets another 1% for this.
> A customer can’t analyze the code to see whether there is a control that prevents the attack
That's actually a pretty decent point. Anyone who has actually studied static-analysis reports for any length of time has probably encountered this phenomenon. For example, you might find a potential buffer overflow that's real in the context of the code you analyzed, but the index involved can't actually be produced because of other code that you didn't. Or maybe a certain combination of conditions is impossible for reasons related to a mathematical property that has been thoroughly vetted but that the analysis software couldn't reasonably be expected to "know" about. Ironically, these kinds of "reasonable false positives" tend to show up more in good programmers' code, because they're diligent about adding defensive code handling every condition - including conditions that aren't (currently) possible. In any case, while it's a good point, it's applicable rarely enough that it doesn't really support the author's broader position.
I think the impedance mismatch here might be that you're a software developer, and we're talking about security teams.
I don't know that anyone is arguing that static analysis is useless for developers. If you're intimately familiar with the code you're working on, there are probably a lot of ways to make static analysis results both valuable in every edit/compile/debug cycle, and an important part of your team's release process.
But when you're close to the code, it's easy to forget how much of the tool's output you're ignoring (either literally, by just skimming past findings you know don't matter, or implicitly, by configuring the tool to match your environment or subtly changing your coding style to conform to Coverity's expectations).
Security teams can't generally do this. They're stuck with the raw output of the barely-configured tool. The results of static analysis in these circumstances is nonsensical: memory leaks, uninitialized variables, race conditions, tainted inputs reaching SQL queries, improper cleanup of sensitive variables, 99.9% of which aren't valid findings, but all of which look super important, especially if you're consultant with 6 months of experience charging $150/hr to run Fortify on someone else's code, then petulantly demanding a response for every fucking issue the scanner generates.
They're fine dev tools, but they are terrible tools for adversarial inspection, which is what Davidson is talking about.
Organizations that manage to operationalize code scanners usually spend many months with full-time staff configuring them and tuning their output --- most of which is nonsensical, for instance randomly assuming dynamic memory is leaking, or that a local variable enables a race condition. There is a whole cottage industry of consultants that does nothing but this.
When all that work is done, the team still needs a Rosetta Stone for the issues they actually do investigate, one that is highly context sensitive and dependent on the different components of their application. For instance, a Fortify or Coverity issue might be bogus in 90% of cases, but actually relevant to one particular library.
There is from what I can tell no source code scanner on the market that will take a product sight unseen and produce a report from which real vulnerabilities can be extracted with a reasonable amount of effort.
There are, on the other hand, many consultancies that will do "point assessments" --- ie, not the long-term shepherding and building of a static analysis practice, but just looking at one release of one product for flaws --- that consist mostly of running a "static" tool like Fortify and a "dynamic" tool like WebInspect, and then handing off the report.
Davidson's take on licensing and security inspection is embarrassing, but she is not at all wrong about consultants and security tools.
I've seen this institutional hubris first-hand. The unshakable belief (typically by nontechnical management) that all of the smartest people in the world are employed here, working for me.
It always ends badly.
Then, if it turns out that it's a security issue, of course they are going to notify Oracle of the fact, both as a moral duty, and because it makes it more likely that Oracle will get a patch out faster.
Oracle whinging about people finding bugs in their code would be better off trying to improve their processes so that there are less bugs to find, rather than complaining that they've been found out for shipping buggy code.
I literally can't touch a Government project without an Oracle license. When I talk to a salesman, the attitude is "I know you can't do this without me", contrary to salesmen for any other product in any other industry.
When I talk to a project manager, they don't ask how it will be hosted, or what the platform will be, or anything else obvious. The first question, often before a project is fined, is "how many Oracle licenses can I buy?".
In industry, all I've ever seen is Sybase, SQL Server, and MySQL (ok, technically Oracle). (My background is finance and technology.)
By the way, since you're apparently a subject matter expert, what kernel would you recommend for arrogance-averse users? Certainly not Linux or OpenBSD?
Please don't do this. The HN guidelines ask you to use the original title. If that's really not suitable, a subtitle or some representative language from the article is ok. But putting your own spin on it is not ok. HN's goal is to let readers make up their own minds, and for that we need accurate, neutral titles.
We've changed the title to a representative phrase from the article, and can change it again if someone suggests something better.
If I'd read this last night... I still would've argued the same thing, but I would've been really unhappy about it.
But what I really don't get is this bug bounty hateathon. If it's only 3% of bugs (currently WITHOUT incentives like a bug bounty), then that's really not that much money... and in return you get more cred, something you might use for recruitment, and the off chance that you might increase that 3% versus something going on the black market. Even more so, how much could this really cost!? And Oracle has how much money?! If you can't spend that on a bug bounty when you're security is just so awesome as the post contends, then something is really in trouble.
Searching around, it looks like there was at least one vulnerability like this, in which Java failed to check certificates for revocation, and at least one exploit was found in the wild signed with a stolen, revoked certificate that Java still accepted.
This is especially fun because Java at least tries to sandbox unsigned applets, but signed applets get a lot more privileges.
One zero day in 2 years. Not quite the disaster area it's made out to be on HN.
"91% of web exploits are targeting Java"
My point is that Java keeps having security vulnerabilities some of which are exploitable from the web. There's a reason why Oracle keeps releasing patches. Even more important is my main point that the reasoning given against a bug bounty program is idiotic, especially on the backdrop that they do in fact have security vulnerabilities on a regular basis.
http://www.oracle.com/technetwork/topics/security/cpujan2015...
But: this is authentic. This is what we (i.e. hackers) are always claiming we want. Someone speaking her mind, shooting from the hip, etc. Not an anodyne blob of corporate-speak: this is an opinion, stated pretty clearly, and backed up with fighting words.
You'd expect: "Our legal team has advised us to remind consultants that they are bound by any and all terms and conditions to which their clients have ... etc. etc. etc."
You get: "Otherwise everyone would hire a consultant to say (legal terms follow) “Nanny, nanny boo boo, big bad consultant can do X even if the customer can’t!”"
Here we have someone who clearly loves the company and the product with a passion, defending both against what she sees (very wrongly, in my opinion) as criminal misuse and waste of resources.
I'll take one of these posts and argue its merits any day, over a block of mealy-mouthed corporate crap.
In terms of tone, I wouldn't hold this up as a good example - it distracts from any legitimate argument the writer may or may not have.
If I was an Oracle customer (which I will never, ever be) I would appreciate the honesty. This honesty enables me to make purchase decisions as well, better than megabytes of legalese would have. In this case it's not a really surprising attitude given the company, but I really wish more vendors would be as open about the nature of their intended relationship with their customers.
Fair point. And a hint to everyone still hanging on to oracle Databases.
One of the best lines is this here:
> Q. What does Oracle do if there is an actual security vulnerability?
> (...) if there is an actual security vulnerability, we will fix it.
Sure, the question is 'when', not so much 'if' customers have payed a hell of a lot money to get this straight.
If you are by nature arrogant, insulting, and condescending, then no, you can't.
Interesting that all the reasons she cites for why she thinks trying to reverse-engineer Oracle products is a bad idea are the same exact reasons why more and more administrators with any sense in security are switching to open-source software and have been for the last decade or so. Being able to inspect the code yourself (or hire someone to do it for you) is apparently important enough to a sufficiently-large population for Oracle to whine about it.
I just don't understand the hatred directed towards someone who's writing without the usual corporate brain-mouth filter ...
I'm honestly curious about this.
If pressed for specifics, Linus Torvalds and Theo de Raadt come to mind as a couple that are often called out for their abusive behavior.
The hostility is also usually confined to those on the development mailing lists of those respective projects (which are implied to be meant for developers, not end-users). It's also with full understanding that - if someone doesn't like how Torvalds or de Raadt run their respective projects - they're welcome to fork (even if said forking rarely happens in practice).
The reason why I pressed for specifics is because there are some personalities in the FOSS world who - while still not in Oracle realm of dickery - probably would come close if given the ability to. Mark Shuttleworth comes to mind, being outright hostile to user feedback on things like Unity, Mir, the Amazon Shopping Lens, etc. (as opposed to the interdeveloper harshness characteristic of Torvalds and de Raadt).
I don't think it's an unreasonable fairy tail to say this is a person who is frustrated, who has drunk the corporate kool-aid in a big way, who is dealing with the detritus of a rather nasty security confidence scam industry, and is putting their views out there. Even if you or I don't like the message, I believe she meant it. I believe it. Maybe I'm gullible.
yeah... right from the hip. give us more money to fix the software that we sold you as a fix to the previous pile of shit we sold you.
you're an idiot.
We also want intelligence and clear thinking along with it. We don't, as a rule, want loud and dumb as a bag of rocks. That way lies Donald Trump.
At the same time, this is a huge improvement over corporate doublespeak. It helps the stupidity and arrogance shine through clearly, which is one reason that I like it when people talk this way.
It's like if I say I wish people would stop murdering people with guns so much, then I get stabbed in the chest and you say, hey, isn't this what you want, people not using guns?
"(Small digression: I was busting my buttons today when I found out that a well-known security researcher in a particular area of technology reported a bunch of alleged security issues to us except – we had already found all of them and we were already working on or had fixes. Woo hoo!)"
a) is bad, and the users should just be turned away. b) is good and far better than selling them on the black market. c) is... who cares it's a license agreement.
(b) is good, but her point that them spending their time doing static analysis of oracle's software is a monumental waste of time is perfectly valid, if their root password is password and the firewall is just some sheetrock in the basement.
> Art. 21 Decoding of computer programs
> 1 Any person who has the right to use a computer program may obtain, either personally or through a third party, necessary information on the interfaces by decoding the program code using independently developed programs.
> 2 The interface information obtained by decoding the program code may only be used for the development, maintenance and use of interoperable computer programs insofar as neither the normal exploitation of the program nor the legitimate interests of the owner of the rights are unreasonably prejudiced.
https://www.admin.ch/opc/en/classified-compilation/19920251/...
Source: by logical extension of: the "no refund" portion of game EULAs is nullified in EU. I'm no lawyer, though.
It doesn't matter though. Even if Oracle can legally stop customers and researchers from reverse-engineering their software world-wide, they can't stop malicious elements because the malicious elements never disclose that they have done it: Oracle only find out after they have been pwnd. I would say "serves them right," but the sad truth is that their customers are going to get hurt the most.
Edit to add: I don't think this[1] warrants an entirely new post.
> Oracle has told people to stop using @Veracode to test their AppSec. They already got AppSec covered [picture of JS injection attack in the blog post]
[1]: https://twitter.com/thegrugq/status/631056841670135808
- mandatory (cogent - may be wrong term for English law) - this clause is valid as it is in law and cannot be overridden by contract,
- non-mandatory (dispositive - again, the term may be wrong for English law) - where the clause is a default or baseline that is valid, unless the contract parties agree on something different.
Unfortunately for Oracle, in most countries the law allowing for reverse engineering (for purpose of interoperability and security) is the first kind, not the second.
UhrG Paragraph 95 and 69
I'm not sure whether this is just voodoo or whether those contracts would otherwise be nullified as soon as you point out any single clause is actually invalid.
The "Do not break DRM" on Computer Software is equally invalid. (Warning: the "Do not break DRM" on music and video is a criminal offense on the other hand).
DISCLAIMER: I am not a lawyer, this is not legal advice, if you consider to use this as defense in a court, you might want to consider getting an attorney. Details can matter depending on your jurisdiction.
Example: It works like this for tenancy agreements in Germany. Your landlord can say that you're not allowed to change the locks all they want, and even if it's in the tenancy and you signed it, it's still null and void.
Another example is that EULAs are prohibited by law from containing any clauses that a customer could not reasonable be expected to assume to be in them. This hit WhatsApp when it tried to ban users who used unofficial clients (which would not violate the EULA of most other messaging services and can therefore not be prohibited simply by adding a clause to the EULA).
[0]: within reason, obviously. The landlord would have to prove that the pets present an unreasonable nuisance to your neighbours or cause unreasonable amounts of damage to the landlord's property.
Yes but only if the law says that you can't create a contact that signs away that right.
For example, in the USA you can reverse engineer. Totally legal. But you can also sign away your right to reverse engineer. That is what a contract is, signing away your rights.
But the US could also pass a law saying it's illegal for a EULA to prevent reverse engineering.
So just finding a law that says reverse engineering is legal, doesn't mean a court won't hold you to a contract that prevents reverse engineering.
That said, it's probable that some countries have banned contracts that prevent reverse engineering.
The parts of the contract that do are not valid and thus can not be used as an excuse to break the contract (revoke the license).
This post is an absolute nightmare/facepalm. Basically my takeaway is "I guess I don't want to buy Oracle software". It's really mind blowing that this is the position of a major software company in this day and age. I mean I guess I shouldn't be shocked since it is in the EULA but man I'm kind of speechless (this clause has to be illegal in some countries, too).
Edit: as an aside as a bad guy this would make me very interested in reverse engineering Oracle products. If they disallow it for their customers the reaction times to any security issues will be lower and it will be pretty valuable to find bugs in their products.
Edit2: Seems like the blog was cracked. At least the "About" on the side seems to indicate that.
Pedantic: not illegal, but invalid.
But the big difference is that it's realistic, allowed and in many cases warmly welcomed if you submit actual problems.
Sun had an open bug database, it was glorious. That got snapped shut after purchase.
That's just the crappy Oracle blog platform presentation. Many of the Oracle blogs have that there, presumably a username.
> A. I actually heard this from a customer. It was ironic because in order for them to buy more products from us (or use a cloud service offering), they’d have to sign – a license agreement! With the same terms that the customer had already admitted violating. “Honey, if you won’t let me cheat on you again, our marriage is through.” “Ah, er, you already violated the ‘forsaking all others’ part of the marriage vow so I think the marriage is already over.”
What a thoroughly nasty comment. She is comparing her customer with someone who is cheating on their spouse. Disgusting.
Because her text will probably only infuriate people that will arguably never be Oracle customers?
As a sysadmin with customers who run oracle, and who put some stock in what I say, I can say I am more likely to warn people away from oracle in the future. While in some companies, tech purchasing decisions are made by suits with little or no input from techies, that's not universal.
Except it is if you are really concerned about security or have a backbone Oracle don't want to waste time on trying to sell to you.
(We're in the midst of an Oracle->Postgres conversion right now. It's going wonderfully. I strongly advise you to look into it, bet you'll find it way easier than you think.)
(One of the nicest things about it: we give every app its own cluster of two PG boxes, because you can just do that instead of running a centralised monster box with an expensive license. It turns out that just everything not having to play nice with others makes stuff stupendously easier to manage.)
This was all cobbled together following the docs. There are almost certainly better ways to do everything we've done so far.
The Postgres is just 9.3 out of the Ubuntu 14.04 repo. Oracle was STUPENDOUS overkill for what it was actually being used for, but MySQL wasn't up to the job.
The heavy lifting for the conversion is done using ora2pg http://ora2pg.darold.net/ Then there's a pile of faff and twiddling and unit tests and so forth. See also https://wiki.postgresql.org/wiki/Oracle_to_Postgres_Conversi...
Any subsequent valid points she makes - and there aren't many - are undermined by this bitterness.
Heightened emotion so often enables effective communication, but it doesn't do any favors in this post.
In that sense I don't see why people do not moan about having to pay a rent because your tenancy contract that you signed says so...
Long story short, its a right of a SOFTWARE mostly company to protect its software, open source is not always the solution and reverse engineering something, consumes way more energy for the problems it actually solves.
You think customers are reverse engineering Oracle products for fun? They're doing it because there's a problem somewhere, they've filed a bug report and not got a satisfactory result, and so they have to go pay an expensive consultant to try and track down the problem for them with no source code.
Even if none of the other arguments for open source were persuasive, this situation with Oracle alone would be enough to convince many people of the wisdom of choosing an open source vendor.
They also have a duty of care to their clients
> open source is not always the solution
No one saying it is. Plenty of other proprietary software vendors protect their softwaqre in customer-friendly ways.
> reverse engineering something, consumes way more energy for the problems it actually solves
When a vendor like Oracle gives you no other option to solve the very real problems that your company has with the software, the "energy consumption" can be more than worth it, even it wasn't the ideal path in the first place.
So, she's telling legal bullshit just to provoke a fear in people that stops a totally legal practice.
And so are you. Not paying is inherently wrong. This is an arbitrary rule more akin to "no looking out the east window".
Trying to sell something to be used but not understood is a fool's errand.
In terms of a rental agreement, a "no reverse engineering" clause is not equivalent to "you must pay rent." It's more like a clause that says you're not allowed to consume meat while you live there because the landlord is a vegetarian.
Perhaps, but this article appears to be very strong evidence to the contrary.
In that sense I don't see why people do not moan about having to pay a rent because your tenancy contract that you signed says so...
Long story short, its a right of a SOFTWARE mostly company to protect its software, open source is not always the solution and reverse engineering something consumed way more energy for the problems it actually solves.
Your JDBC driver IP isn't that valuable, just give me the damned source code so I can figure out why my Postgres copy out stream is blocking when I insert it into your copy in stream.
/rant