“Stop reverse engineering our code”
blogs.oracle.com
blogs.oracle.com
This single blog post is strong evidence for why you should never, ever buy an Oracle product, and if you are running anything written by them, why you should plan to migrate away.
Now, the culture of consultants in the Oracle sphere of influence is pretty toxic and money-grubbing. I can imagine companies being badgered into paying security weasels big bucks to analyze software with tools that cough up a zillion false positives, whereupon the weasel looks like a hero and is paid a bunch of cash, the customer panics and demands that Oracle fix a pile of non-existent vulns, and some department buried inside Oracle doesn't know how to deal. Whereupon the weasel skates off to another company to run the same scam: rinse, repeat, and this blog post.
In which case Oracle should simply call it out: "Please don't send us crappy automated scanning tool reports from the shitty security weasel consultant you hired because those reports are useless, and the same weasels have been sending identical ones in, monthly, for years, and you are being ripped off." But Oracle never passes up the opportunity to express contempt for its customers, nor can it admit to being wrong.
Better to avoid that whole ecosystem.
Btw: For smaller enterprisey shops, either MS SQL or Postgres are the way to go. Often multiple similar components are needed because different apps have firm requirements that only support one or another; but generally try to avoid this because supporting too many heterogenous components is expensive (laborious)... hence the prevalence of local "standards." Deploying everything with cfengine3 or puppet can help reduce the manualness and nudge vendors into repeatable, idempotent deployments rather than clicking on inane GUI installers like an animal.
ProTip: Don't let consultants "provide" oversight / free-reign for their own projects, budgets, etc., that's like the wolf guarding the henhouse. The client must hire their own project managers, have clear accountability/authority paths to their management and know exactly what they need (avoid endless upselling). Or lots of money will be transferred from idiots to crooks (enterprise caveat emptor).
Edit: fixed grammar
# My mind was more on how to grow the business while simultaneously helping the client fix their deployments. Seriously, the sales guy was dead weight and dumb as a bag of broken rocks but looked good in suit and could talk in nonstop sports metaphors and bizease clichés.
The measure of how a software company values its customers is in the post-sales support... just asking some users how it's going is better than hiding out or DKing them. (About '03/'04, Dell took us out to see the server factory in Round Rock, but went radio silent after a significant purchase.)
In the meeting, I literally had this dude and his presales guys in $5000 suits sitting across the table from me, berating our position and demanding (quote was "You have no fucking business saying no until you provide us with <our numbers> so we can do your ROI") all sort of crap from us. Ended up prodding the salesbot and let him run his mouth for awhile until he said something really stupid that ostracized the business folks on our side.
iSCSI purchase that was promised to be supported on CentOS (it wasn't: RHEL only, despite no deltas), and which Dell itself didn't understand. Ended up getting RHEL just to get a comparison baseline install.
At one point, got cussed out by Dell's support manager in the process (the front-line support team was good). The quote was "I'm not here to support you." Ultimately cost me my job (though we did get the product running).
I'm usually pretty free with sharing my documentation, but in this case made an exception: Dell's support was so fucking crap I refused to provide any assistance for them at all.
(Dell tried to hire me thrice because I could actually use Visio to communicate visually and detail drilling quotes (BOMs) to ferret out upselling and ensure we had supportable configurations (SANs and such). I even had the pleasure to due-diligence several of their solution presentations across the table from 6 of their SE's in Round Rock with the worst hangover of my life, and we still managed to extract maximum intel from that meeting. Dell's client reception secretaries helpfully stocked boxes-upon-boxes of Advil and Tylenol samples and a righteous Keurig binge didn't hurt either. Interestingly, Dell+Redhat had a massive champagne orgy in an adjoining room and we wondered what sort of treatment the several megabucks USD customer level receives, hopefully not just a backpack or stay at the Dell cobranded hotel.)
This so much. Especially the "know exactly what they need" side of things. I speak from the consultant side of the fence, and we've had a number of projects where project management was lacking on the client side; it ends poorly.
We always have our own project manager on projects, and we strongly encourage the client to have their own as well. It really helps to maintain a clear escalation path, and makes everything run much more smoothly.
I don't think that's really the case. We don't try to do anything different for the sake of it, but that's pretty much that.
> EnterpriseDB is one of the official Postgres commercial flavors
There are no 'official Postgres commercial flavors'. EDB is well known and contributes a fair amount to PG development, but that doesn't make them official.
I guess one could say they deliberately resemble Oracle in that both DBs roughly implement the SQL standard, but this is by no means a clone, nor was it a smooth transition.
Was it really necessary to type it like that?
Of course, accuracy is hardly relevant here.
Sorry, I don't usually try to be pedantic, but when the conversation is already about nitpicking, I think it's necessary.
Significant figures are precision, not accuracy. Accuracy is "being in the ballpark". Precision is "tight groups".
is a new value of pi to define.
I think I'll use 3
it's much simpler you see;
than 3.14159
But rivalry says "level-up score".
With competitive drive,
It's yet higher I strive.
The value I'll use shall be four.
_|_ __ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___
/ |_) / )| __) / _ \ / _ \ / _ \ / _ \ / _ \ / _ \ / _ \ / _ \ / _ \
\_| \ )( |__ \( (_) )()( (_) )( (_) )( (_) )()( (_) )( (_) )( (_) ) ( (_) )( (_) )
(_|_/ (__)(___/ \___/ / \___/ \___/ \___/ / \___/ \___/ \___/ () \___/ \___/
|> "what you think of Oracle is even truer than you think it is. There has been no entity in human history with less complexity or nuance to it than Oracle"
> "this company is about one man and his alter ego and what he wants to inflict upon humanity"
Edit:
And how could I forget this: https://www.youtube.com/watch?v=79fvDDPaIoY&t=24m
> "and then, the Nazis invaded"
> "for a while I tried to not go to Nazi allegory when talking about Oracle but I actually think that it does a dis-service to not go to Nazi allegory because if I don't use Nazi allegory when referring to Oracle there's some critical understanding that I have left on the table"
> You need to think of Larry Ellison the way you think of a lawnmower. You don't anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it'll chop it off, the end. You don't think 'oh, the lawnmower hates me' -- lawnmower doesn't give a shit about you, lawnmower can't hate you. Don't anthropomorphize the lawnmower. Don't fall into that trap about Oracle.
--Dad
Someone once told me that Larry Ellison is the biggest asshole in Silicon Valley, and also the richest, so he must be doing something right. The same could be said for John D Rockefeller and Standard Oil. Is the world we have the world we want?
http://www.cio.com/article/2439102/enterprise-resource-plann...
Founded 1870, antitrust 1911:
https://en.wikipedia.org/wiki/Standard_Oil
Crude prices in that time frame (and beyond):
https://commons.wikimedia.org/wiki/File:Oil_Prices_Since_186...
Production in that time frame (having trouble finding a nice long time-series chart):
https://en.wikipedia.org/wiki/History_of_the_petroleum_indus...
If we want to make a strong claim of harmful monopoly[0], we should not expect to see a massive surge in production combined with an impressive decrease in price.
[0]Here I use the term "harmful monopoly" to refer to a firm that has both market power (can influence prices by controlling supply) and uses it to increase its own profits. What we see instead is a time period where we do indeed have a dominant firm, but one behaving as if it were in a competitive market.
The important characteristics of a competitive market here are low barriers to entry/exit, and a commodity product. There were incredibly low barriers to entry/exit, and oil has, for nearly its entire existence as a product in the modern age, been a commodity.
Note that monopolistic behavior does not necessarily imply rising prices. See: Wal-Mart. Also see this quote from that Wikipedia article again:
"The evidence is, in fact, absolutely conclusive that the Standard Oil Co. charges altogether excessive prices where it meets no competition, and particularly where there is little likelihood of competitors entering the field, and that, on the other hand, where competition is active, it frequently cuts prices to a point which leaves even the Standard little or no profit, and which more often leaves no profit to the competitor, whose costs are ordinarily somewhat higher."
In cases where there was little competition, that clearly indicates an area where the costs of the trade were such that the market price would be higher.
The former is strictly competitive and the latter is strictly not anti-competitive.
Arguing the nuances of Standard Oil's behavior is a moot point when the Supreme Court settled that issue in 1911.
No, if profit is close to zero then there would be no point in being in a market. Markets drive profits to the 'standard' risk adjusted ROI for the economy they operate in. In other words if you could run a gas station, a book store, a flower shop, or whatever, then you do whichever one gives the most profits.
Since we are discussing economics, I do not feel the need to preface every use of jargon with disclaimers, though I can.
The relevant portion of Wikipedia's entry on (economics jargon) profit: https://en.wikipedia.org/wiki/Profit_%28economics%29#In_comp...
You can confirm this concept in any economics text. (economics jargon) Profit is driven to zero in a (economics jargon) competitive (economics jargon) market.
For everyone else: https://en.wikipedia.org/wiki/Profit_(economics) "Economic profit is similar to accounting profit but smaller because it subtracts off the total opportunity costs (not just the explicit costs, but also the implicit costs) of a venture to an investor.[1] Normal profit refers to zero economic profit.[2] A concept related to economic profit, and sometimes considered synonymous, is that of economic rent."
You can think of Economic profit as the 'standard' ROI you get in a given economy. Hypothetically Economic profit is also being driven to zero in a static economy, but that's a separate and long term thing.
PS: I am just being this clear because general HN readers are likely to miss the distinction.
We don't see that in any of the information you provided. You gave a graph of oil prices, not of Standard Oil's profits.
Surely you've considered why Standard Oil's decision to do this was found to be anticompetitive, have you not?
This thread has all the markings of one that becomes net negative for all involved and those reading. I'll leave it with this:
I am focusing on the outcome to the consumer of the behavior in question, not on the outcome to competitors of the behavior.
The former is a situation of supply where there was otherwise none, and some is better than none. The latter is a situation of competitive pricing, and competitive pricing is better than non-competitive pricing.
How is this worse off for consumers than the situation without Standard Oil?
That fear disappeared with the East Texas oilfield discovery in 1930. Which so increased the supply of oil relative to demand that prices fell to 13 cents per barrel.
This created a number of problems, including the prospect of damaging oilfields to the point that future extraction would be compromised. It ended up with the governors of both Texas and Oklahoma calling out the state militia, and, in Texas's case, the Texas Rangers, and seizing control of wellheads by force of arms in an effort to constrain extraction and drive oil prices up -- to $1/bbl.
This resulted in the Texas Railroad Commission effectively controlling US oil output (with oversight from the US Department of Interior) from 1931 to 1972, at which point, peak US oil meant that there was no longer any surplus extraction capacity to limit. Shortly afterward the Arabs tried another of their periodic embargos against the US and Europe, and, to everyone's shock, it actually worked.
If you look at the price of oil, from 1931 to 1972 it was remarkably stable. Even WWII and the post-war consumption boom barely moved the needle. Post 1974, everything goes all to hell. We're still there now.
Daniel Yergin's masterpiece work, The Prize, covers this history in great depth.
The rest of the history, though, is quite interesting. I've added that book to my reading list. Thank you!
We live in the oil age.
And the rapidity with which it arrived following Colonel Drake's well is staggering.
https://archive.org/stream/historyofstandar00tarbuoft#page/n...
Particularly chapters 3 "The Oil War of 1872", 4 "An Unholy Alliance", and 5 "Laying the Foundations of a Trust".
The oil industry has almost always been controlled by a small cartel, though that cartel has varied though the years: Standard Oil, the As-Is agreement, the Texas Railroad Commission, the Seven Sisters, the National Producers, and OPEC.
It's not been a competitive market.
Though I'd argue that oil has been tremendously underpriced since 1869.
This weekend I learned that Larry Ellison purchased ~90% of an island in Hawaii.
Most companies that use oracle's services could likely literally, no shit, do it on a single mac mini using sqlite.
Most companies just don't have that much data, and even if they do single servers are giant, massive affairs today where for the price of one month of consulting services (I mean $10K-$70K) you can configure a server with 1TB RAM that will handle your data for the next five years.
There's just not that much data. Laptops can handle it. The reason you pay for an oracle DBA instead of running sqlite on your macbook, is not because oracle is that much better. It's because that way you don't have to admit how much you suck.
Read the other blog posts. Holy cow crackers.
You can find a copy of it here: http://dacut.blogspot.com/2008/03/oracle-poetry.html
Note the copyright statement on the mispelled, 3-line poem with no literary merit whatsoever (which happens to be longer than the poem itself):
"The preceding key is copyrighted by Oracle Corporation. Dupl@ication of this key is not allowed without permission from Oracl1e Corporation. Copyright 2003 Oracle Corporation."
The purpose of this is to abuse the copyright on the above "poem" in order to prevent people from implementing the Oracle DB protocols. I guess they hope that everyone is ignorant of Sega v. Accolade? Even that trick of theirs is copied from elsewhere:
https://en.wikipedia.org/wiki/Sega_v._Accolade
EDIT: Reading that deliberate misspelling makes me wonder if I could start "Oracl1e Corporation" and give people permission to violate this? Sure, it'd be a ridiculous cheat, but so is the sham copyright on their worthless poem.
I mean, given that this is a trivial work with no discernible literary merit, a full quotation is arguably a reasonable step in order to fully demonstrate the triviality of the work.
The sole purpose of this poem, given that it's hidden away deep in the plumbing of the system where almost nobody ever sees it, is to dissuade people from making something that is interoperable with Oracle's DBs, after all.
One normally displays art that they're proud of where people can appreciate it, rather than making it a technical requirement for a machine to recite bad poetry to a database before the database will deign to respond.
It could be worse, though. Just imagine if this was Vogon poetry...
That said, the fact that one can ONLY find copies of the work by looking to 3rd parties (rather than Oracle) should undercut any arguments they try to make against discussing it for the purpose of criticism to be fair use.
Oracle yanks blog post critical of security vendors, customers
http://www.computerworld.com/article/2969378/security/oracle...
Last new I'm aware was Oregon sued Oracle for $200 million.
"Oregon sues Oracle over failed Obamacare website" http://fortune.com/2014/08/22/oregon-oracle-spat-200-million...
Oregon’s suit, filed Friday in state court, alleges that Oracle, the largest tech contractor working on the website, made falsely convinced officials to buy “hundreds of millions of dollars of Oracle products and services that failed to perform as promised.” It is seeking $200 million in damages.
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.
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?
(at least in ~current~ as-it-was form)
Note Oracle's reaction:
"Oracle yanks blog post critical of security vendors, customers"
http://www.computerworld.com/article/2969378/security/oracle...
> 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.
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.
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.
No matter how interpersonal she puts it. It makes me not ever want my system to rely on a company that threatens and belittle customers for protecting themselves.
If I bought a fridge for my house, I found a listening device and a pinhole camera in the fridge. Just because the company has a clause I am not allowed to open up the fridge, it doesn't mean I shouldn't.
Well, the company might have found the devices. Indeed maybe nothing customers can do until the company fixes it. Keep telling customers they are not allow to look for flaws it just ridiculous. Yes, it's your product, but this is my home!
My stance is that EULAs are bullshit, period. If you purchase a product, it is yours, and no one should be able to dictate how you use it.
> 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]
- 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).
A lot of people think open source software is a much better methodology than proprietary, highly-protected source code. That's fine, there are a lot of good arguments there. However, it doesn't make sense to throw a bunch of other, barely related insults at a company when really, all you're upset about is that their code is not open source. Criticize that...that is what you're upset about (at least so far as this specific blog post is concerned)
It doesn't make sense for it to be illegal to forbid reverse engineering in a license agreement, where is that the case? If that is the legal environment anywhere, it would make more sense to just forbid closed source software. It would save a ton of time and effort and achieve the same goal.
And by the way, it has everything to do with open source. If the code was open, you wouldn't need to reverse engineer it. Every security analyst could just review the code directly and search for vulnerabilities. The whole disagreement stems from Oracle (and the author) deciding that they want protected, closed source because they view it as intellectual property, while some of their customers feel they can't depend on that software unless they verify it themselves. Well...you can't fully verify closed source software yourself.
It is really a very simple and fundamental disagreement on this one topic that creates the whole issue. It is completely valid to disagree with Oracle on this, and to tell Oracle you disagree with them. However, rather than violating their agreement, it would make more sense to decide to use an open source solution instead.
How is it so? You cannot find funny vulnerabilities without reverse engineering the binaries.
> It doesn't make sense for it to be illegal to forbid reverse engineering in a license agreement, where is that the case?
France, Switzerland, Russia and many more.
> it would make more sense to just forbid closed source software
How did you make this leap from reverse engineering to closed vs. open source?
> If the code was open, you wouldn't need to reverse engineer it.
Even with the full source available you still have to analyse (read: reverse-engineer) the binaries, especially those widely shipped.
> rather than violating their agreement
Their agreement is void in many countries where reverse engineering is explicitly allowed (when done for the reasons of security and interoperability).
The only definition of "reverse engineering software" that I use is this -- "Using tools and deep binary analysis to take a compiled binary, and convert it back to source code as close to the original as possible".
It is a very specific definition. I do not mean general "analysis" or vulnerability testing or input manipulation, etc... only attempting to discover source code.
Uhm, no, that's far too narrow. Reverse engineering is any kind of introspection into a device in question, designed for obtaining any degree of understanding of its inner functioning.
What you're talking about is called "decompilation", and it's not even among the most useful reverse engineering techniques.
edit: I just wanted to explain to you which definition I was using earlier, so that you could understand what I meant better.
However, this is one of the reasons I disagree with Oracle on the matter. There are tools which actually can and do find issues at this low level (even if there are false positives), and running those tools can be part of many reasonable verification efforts. I think static analysis at the bytecode or assembly code level still counts as analyzing the source code, but I think it makes sense to do that in many scenarios.
Your definition is not what anyone else uses, from what I've seen. You don't have to use the same definition, of course, but be aware that unless you clarify what you mean, you're going to be creating a ton of confusion.
That's the definition of decompiling not reverse engineering. The original IBM BIOS was reverse engineered by two teams: one which read the disassembled binary and wrote a written specification and a second team that took that specification and wrote code.
See the previous reply I made for links to discussion of what is usually meant by (software) "reverse engineering." But, like I said before, there probably is no "universally correct" definition, I am only describing it so that my previous comments can be understood fully.
Even further, if I buy a software, and it does not run on my system, I can turn it back into source, modify it, recompile it, and use it as much as I want.
If the original company tries to prevent me from doing this, they commit a crime that can be punished with multiple months of jail for their CEO or 10% of their profit as long as they have that practice.
So, decompilation in order to check for security vulnerabilities or to modify the function of the software for non-interoperability reasons do not appear to be covered.
disclaimer: I don't live in Europe and am not familiar with the most up-to-date software laws there. This is from the following source: https://en.wikipedia.org/wiki/Decompiler#Legality
This would be one example case. As I posted in my comment.
Integration can also just mean for future possible integration – for example, if someone writes a tool that can read a file format, I may decompile it to implement a tool to read the same file format.
Microsoft, SAP, VMware all have closed source software that is very prevalent in enterprise, often in entrenched positions just like Oracle. Sure they aren't exactly all peaches either but atleast they have a decent way of responding to security problems or plain bugs.
They also don't wield their license agreement as a weapon against their customers, they only use it to make sure they get paid.
But that isn't what it says, at all. It even explicitly says that if you do find a security flaw this way they will still fix it.
But the main point is that you can't do anything by reverse engineering the source code that they aren't already doing, and doing better than you because they have the actual source code.
Oracle thinks it is self-evident that protection of their source code is paramount (i.e. as closed source as possible), other people disagree both with their priorities and the very idea of absolutely forbidding any deep analysis of any kind outside of Oracle itself. It still seems like a debate about the degree to which the source code is "closed." For Oracle, it is absolutely closed, while many of their competitors are more lenient (i.e. slightly less "closed".)
To be clear, I think Oracle is being silly with their over-sanitized and idealistic views regarding their intellectual property. The other companies you mentioned (Microsoft et al) have much more reasonable approaches and agreements.
and it's not helpful because of the near 100% false positive rate.
"(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!)"
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...
Did 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.
http://webcache.googleusercontent.com/search?q=cache:ntXM0Rl...
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
They admit more security vulnerabilities are found by customers than security researchers and still they release this smug "fuck off" toned blog.
(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...
RMS would have a field day.
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.
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.
Well, Apple does (for jailbreak exploits).
>I am not dissing bug bounties, just noting that on a strictly economic basis, why would I throw a lot of money at 3% of the problem
Uh ... You don't think that percentage will increase if you offer bounties?
And if it doesn't, well, they don't pay out much. It's not like bug bounties consist of just throwing money at random people and hoping they find vulns; you pay for results. That's sort of the point.
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...
And in any product that uses LGPL code, for example, it's actually a license violation to forbid customer modification and reverse engineering for the purpose of debugging those modifications.
(Though, admittedly, everyone always violates this term)
Aren't the issues not found by Oracle the problem? I'm amazed that stil 23% of the externally found security issues are reported by researchers, the incentive to responsibly disclose security issues to Oracle isn't really big. It sounds like a cumbersome process with potential legal consequences.
There also are researchers(, maybe after a first bad experience about an EULA,) that sell security issues to the grey/black market. Is there any data on how many Java zero days are exploited in the wild before being fixed?
Changing your stance and being grateful for responsible disclosures and only using your EULA to threaten and sue the bad people can potentially save everyone with java installed from a few zero days at zero cost.
If I'd read this last night... I still would've argued the same thing, but I would've been really unhappy about it.
If so, then somebody at Oracle realized that post reflected poorly on their organization. Perhaps there is some hope for Oracle yet.
While I don't endorse breaking the agreement (which was properly signed and "celebrated", as lawyers say), I find it funny in the first place that they're selling a glass container and say "you can't look into it, just use it".
I prefer the honesty of free software/open source projects that sell customer support to this business model (which is also adopted by others, not just Oracle). However, if I were already bound to it, and couldn't pay the cost of migration, I understand I'd have to stick with it.
It's also amusing that people/organizations seriously believe they can reverse engineer something as complex as a database engine and "fix it" without acces to the diagramas, docs, tests, source code, build environment, etc.
Yes we did not reverse engineer that code even though I feel it would have done lot of good for us. Not to mention the tool set provided by Oracle is utter crap as in it barely works on its own.
So I am not at all surprised that Oracle have that kind of mentality here. In all our communications with Oracle I felt they never really actually cared for what we the customers really want. All they actually care about it protecting their investments.
New pages won't be archived though.
Though saying to your client that they cannot reverse engineer to look for security problems, is totally not done! What is next? "Exploits will not be fixed, because the users has signed an agreement that they will not hack?"
JRE CVEs: http://www.cvedetails.com/vulnerability-list/vendor_id-93/pr...
It's been 5 years since Oracle took over Java, so they can't claim it was left over.
Oracle's security record is terrible by all accounts, so how can their CSO justify anything in this blog post?
ORACLE product list CVEs: http://www.cvedetails.com/product-list/product_type-/firstch...
This makes me want to climb the empire state building, beat my chest like a gorrilla, and yell "Let me do what I know best!"
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.
I wonder if Oracle would send one of those reminders to a customer who analyzed an attack by an attacker who "broke the license agreement" by reversing the customer's copy of some Oracle software.
Really? What if no money changes hands?
BTW, the post is gone.
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. I’d like to tell you that we run every tool ever developed against every line of code we ever wrote, but that’s not true. We do require development teams (on premises, cloud and internal development organizations) to use security vulnerability-finding tools, we’ve had a significant uptick in tools usage over the last few years (our metrics show this) and we do track tools usage as part of Oracle Software Security Assurance program. We beat up – I mean, “require” – development teams to use tools because it is very much in our interests (and customers’ interests) to find and fix problems earlier rather than later.
That said, no tool finds everything. No two tools find everything. We don’t claim to find everything. That fact still doesn’t justify a customer reverse engineering our code to attempt to find vulnerabilities, especially when the key to whether a suspected vulnerability is an actual vulnerability is the capability to analyze the actual source code, which – frankly – hardly any third party will be able to do, another reason not to accept random scan reports that resulted from reverse engineering at face value, as if we needed one.
Q. Hey, I’ve got an idea, why not do a bug bounty? Pay third parties to find this stuff!
A. <Bigger sigh.> Bug bounties are the new boy band (nicely alliterative, no?) Many companies are screaming, fainting, and throwing underwear at security researchers to find problems in their code and insisting that This Is The Way, Walk In It: if you are not doing bug bounties, your code isn’t secure. Ah, well, we find 87% of security vulnerabilities ourselves, security researchers find about 3% and the rest are found by customers. (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!)
I am not dissing bug bounties, just noting that on a strictly economic basis, why would I throw a lot of money at 3% of the problem (and without learning lessons from what you find, it really is “whack a code mole”) when I could spend that money on better prevention like, oh, hiring another employee to do ethical hacking, who could develop a really good tool we use to automate finding certain types of issues, and so on. This is one of those “full immersion baptism” or “sprinkle water over the forehead” issues – we will allow for different religious traditions and do it OUR way – and others can do it THEIR way. Pax vobiscum.
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.