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.
This is hardly a first. Oracle stuffs a bad, misspelled little poem in their DB protocols, not for any technical reason, but purely to attempt to extend copyright protection by forcing people to violate their copyrights to be compatible with Oracle.
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:
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 was going to post Sega v. Accolade after seeing the first three paragraphs of your post. Yeah. Copyright isn't functional, duplicating the poem to achieve functionality wouldn't violate copyright.
That depends on how the fair use argument goes. The downside of such arguments is that you generally have to argue that in court. I tend to believe that Oracle would prefer to leave this untested, as they'd probably benefit more from leaving it uncertain than to spend a ton of money litigating it with a chance of blowing up the whole scheme.
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...
Someone should just publish that as public domain, and see what happens if Oracle challenges it. How can they prove that a bunch of bytes sent over the network are meant as prior art and so on.
Prior art only applies to patents, not copyrights. The preexisting publication of copies of this poem would also undercut any such attempt.
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.
Stanford was taken to the cleaners to the tune of $1.5 x 10^8 USD in the deployment of Oracle Financials and related products via endless "consultant implementation" charges that didn't really deliver much value, were rarely on schedule or on budget. Oracle's enterprise calendaring program was totally inadequate and had UX that made most point-of-sale systems look effortless by contrast. Also, the assets managing app, Sunflower, was another dud. The only thing Oracle Database had going for it was no crippling license activation (license scofflaws are/were sued or fined into oblivion worse than M$FT), which one could say was equivalent to MS SQL. Unlike MS MSQL, Oracle DBMS has/had bazillions of support patches to apply to run a real production box, analogous to the previously separate Sun's Solaris patchsets.
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).
I worked for a large company which will remain unnamed, who a few years after purchasing a 12-year unlimited support contract, switched to using Postgres. Read: they were already locked in to paying for Oracle's most expensive contract for 12 years, regardless of what services they used. In short, they concluded that due to the cost of developing for Oracle, it was cheaper to migrate to Postgres than to continue using Oracle even when Oracle was free.
It is somewhat rare that companies will recognize the fallacy of sunk costs ("We've already spent so much, we need to do this"). I think the world would be a much different place if we could somehow overcome this cognitive error.
I see this repeated all the time and tend to label it "the investment-bias fallacy" but it's also called commitment bias. [0] Go into any casino where people are trying to win back their lost money is one classic cliché.
In case anyone were wondering: Postgres deliberately resembles Oracle. EnterpriseDB is one of the official Postgres commercial flavors which is an even closer "clone" of Oracle DBMS with support options to make migration from ora easier.
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.
To be pedantic, 1.5e8 carries additional information about accuracy: $150,000,000 ± $5,000,000. By contrast, 1.50e8 would be ten times as accurate, and so on.
On the other hand, if you had said "Pi is 3", you would have been accurate, but not very precise. If you said "Pi is "Pi is 3.14", you would have been so precise that you could have gotten to the moon and back.
At the very least keep it to multiples of three, as in 150e6 or 150 * 10^6! Though a very simple 150 million is easy to think of in terms of erasing past donations that sounded impressive.
The place where I work, regret a decision to use Oracle, our application build with Oracle Form Builder, which is awfully hard to use, broken easily. But I must admit, their pre-sales really good at describing their product, my boss really hooked up by them. "Oh, for that problem we have this, it will cost this much, but for now, you can just use it for free" then some wild invoice came to our office.
The dept I used to work at was mostly ex-B4 people and I later did enterprise consulting later: What happens is that sales people talk to people high enough up on the food chain that they get the run of the place, and so it's nearly impossible to kick them out or refuse their requests without a substantial political cost/justification. It's called "building a beachhead" and involves the engagement team worming their way up to a client's CTO or even CEO, if possible. I've been deployed as a client-facing "technical"# consultant, and I got really good at it (if I do say so myself): creating additional staff roles, developing opportunities and frenimizing other consulting shops... without inventing things that didn't need doing or creating bullsh!t jobs.
# 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.)
I was in a situation where they were selling something to a business leader that my side of the org wasn't in favor of buying (5x cost difference). I drew the short straw and got to meet with them and the business leadership people.
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.
Wow that's wildly aggressive. I know people say 'push for the sale' but that seems counterproductive. It seems like they would have got further if they listened more.
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's academic-facing sales force (sales and support are their core business value) seemed to start sucking around 2007+. For enterprise IT critical boxes, I would today probably shop around IBM, HP, Cisco, Dell but for web I would go the ODM/OEM route if it were a big enough order. For test lab stuff, Unixsurplus FTW.
(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.)
> 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).
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.
Large enterprise account engagement is trickier, than say a solo consultant contract with a startup, because there are way more expectations to manage and moving parts to coordinate. As a client-facing consultant, you're often having to balance multiple masters of client and internal politics without having bleed-through and maintain a unified position regardless of other people's screw-ups, accidents or outright lies.
I went to a prominent tech school that adopted an Oracle platform for student course management in my last few years. I won't mince words: it was a piece of shit, and my school's administrators ate shit by agreeing to a contract that forbid them from making any changes to Oracle's broken system. Now I work in college administration and we have to deal with the very same pile of junk.
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?
UMass Amherst was this side of non-functional for the first three days of the school year in 2005 because of a botched Peoplesoft (at that time recently purchased by Oracle) rollout.
Hah! The guys at SFSU somehow forgot that. They just implemented a Peoplesoft last year, now a part of Oracle since forever, so no excuses for how badly it works.
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.
According to the very Wikipedia article you link, Standard Oil was found guilty of anticompetitive actions.
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."
I believe we are going to be at an impasse here, but the quote you extracted illustrates the point I made, that Standard Oil acted as a competitive firm. We expect to see profit driven to zero in a competitive market, and that is what we saw in Standard Oil's pricing.
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.
I think we're going on the wrong track. What I meant was that Rockefeller and Ellison both show that wealth doesn't always come from producing value, but can also be made by abusing market dominance.
Arguing the nuances of Standard Oil's behavior is a moot point when the Supreme Court settled that issue in 1911.
I was responding specifically to the latter portion of the quote excerpted by the grandparent post, which indicated minimal and zero profits for Standard Oil in areas with competition, in alignment with economic theory which indicates economic profit tends toward zero with increased competition.
I responded to multiple points in the post. You questioned a specific excerpt. I responded regarding that specific excerpt. You are now accusing me of laser focus.
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.
To get a little more insight into the impact to consumers, and the reason why this behavior is illegal, read the two sections of that Wikipedia quote the other way around.
Where there was no competition, Standard Oil provided oil. Where there was competition, Standard Oil provided oil at zero or near-zero profit.
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?
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.
You can confirm this concept in any economics text. (economics jargon) Profit is driven to zero in a (economics jargon) competitive (economics jargon) market.
Economic profit is not the same thing as profit. In a pure economic debate you can drop it, but when talking about specific firms in a general context such as HN you really should clarify.
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.
Without any comment on the business practices of Standard Oil, I do think it's interesting that the price of crude actually increased substantially after the antitrust ruling.
World War I, increased demand, and a period in the 1920s during which there was genuine concern that all the oil that could be found had been.
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.
I should have been more specific - I was more remarking on the period between 1911 and 1914, which saw crude prices rise; that seemed rather interesting, since I'd expect an antitrust ruling to have the opposite effect if Standard had been keeping prices high through elimination of potential competition. The effect of WWI is quite obvious, naturally.
The rest of the history, though, is quite interesting. I've added that book to my reading list. Thank you!
My great-great-grandmother was very interested in news of Rockefeller's philanthropy. My great-great-grandfather had died middle-aged, so she had to raise their children on a tight budget. She noticed that the price of kerosene would always rise shortly after Rockefeller made a major donation.
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.
I've recently read "The Difference Between God and Larry Ellison *God Doesn't Think He's Larry Ellison" and while it was published over 10 years ago, this sounds exactly like a lot of things that happened in the book. The Oracle corporate culture seems to basically be reflection of Larry Ellison's megalomania. Their will to rack sales is just insatiable.
> "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"
> "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.
YouTube should suggest some of his other talks too. There's more oracle stuff in the illumous day and Surge talks, and he also has very humorous segments in the Surge 2013 and 2014 Lighting talks.
but it's not a zero-sum game. Oracle's services could really be "you suck at business, we can write ten lines of code that improve your process 100x, we just call it database management because no way you would pay us to show you how incompetent you are at thinking about and running your own business, that we don't know anything about."
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.
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.
My company is still dealing with a (thankfully) failed move to oracle. Some hotshot (who is long gone now) sold them on the idea and our DB tables/columns names are still all over the place b/c of oracles limits on name lengths. All new (and really old) tables are full length but around when we thought we were going to move all the table/column names are nearly unreadable... We also have a couple hundred thousand dollar boat anchors (read: oracle servers) because apparently they aren't worth shit if you don't run oracle on then and stripping them for parts is almost a zero-sum game. Also Oracle told us they will try to sell them for us (because they won't just buy them bacl) but they have ZERO incentive to do so when they can swindle some other corporation out of more money by selling new servers. We are now in the middle of switching over to MariaDB and I can't wait to leave Oracle behind.
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 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.
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.
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?
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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?".
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.
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.
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.
This is exactly the problem with legality of RE and penetration testing. "You broke the law by wasting our time, violating your license agreement." I understand author's points. Not very good points, disappointingly.
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!
> 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.
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]
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.
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).
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.
>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.
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.
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.
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.
- 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.
I don't really see how a lot of the responses here match with the original blog post. People seem to be airing a lot of long-standing grievances about Oracle rather than responding to the specific post on its own. Viewed on its own, the post can basically be summarized as "Please stop treating our products like they are open source. They're not, and it is against the license agreement to reverse engineer our stuff to find the source code."
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)
I don't think it's the lack of open-source code that is causing the grievances but rather the tone of the blog post and the overall theme of "Our IP is more important then your security concerns, no we don't care if you are a core bank".
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.
The blog post doesn't make me think of license-agreements-as-a-weapon. Oracle's position is probably the strictest I've seen anyone be in favor of software IP protection. They are not adversarial, they are supremely protectionist (presumably because they think their software is so great that other people want to copy it). That protection (possibly over-protection) is the core of the disagreement, and the source of the article's tone and inherent frustration on both sides.
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.
> Our IP is more important then your security concerns, no we don't care if you are a core bank
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.
What was most astonishing to me about the post was the tone, which I found extremely condescending and unprofessional. The content was more or less par for the course, though I of course disagree (as do most tech folk).
That's a fair point, but it is a blog post, which implies that the tone will be more personal and informal. The author stated a few times that these were her personal views. I took it more as frustrated rather than condescending. I don't agree with what she said, but I recognize that the disagreement stems from one fundamental thing: open source vs. closed source.
> be summarized as "Please stop treating our products like they are open source. They're not, and it is against the license agreement to reverse engineer our stuff to find the source code."
and it's not helpful because of the near 100% false positive rate.
No, it got nothing to do with open source. Reverse engineering and pen testing the binary, closed source software is a standard practice and in many countries it is illegal not to allow doing it.
Reverse engineering software is completely different from penetration testing, and it is the reverse engineering bit that Oracle has an issue with. They mostly just don't want anyone/everyone trying to recreate their source code because of copyright/intellectual property concerns (note: I do not agree with those, but that is Oracle's stance).
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.
> Reverse engineering software is completely different from penetration testing
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).
I think there may be a language barrier here. So, this should clear it up:
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.
> The only definition of "reverse engineering software" that I use
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.
People have different understandings of words, so I'm not claiming there is one, universal meaning of "software reverse engineering." However, here is the definition some researchers came up with: "Reverse engineering is the process of analyzing a subject system to create representations of the system at a higher level of abstraction. It can also be seen as "going backwards through the development cycle." (from https://en.wikipedia.org/wiki/Reverse_engineering#Reverse_en... , original publication: http://win.ua.ac.be/~lore/Research/Chikofsky1990-Taxonomy.pd... )
edit: I just wanted to explain to you which definition I was using earlier, so that you could understand what I meant better.
That quote is quite different from the definition you're using.
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.
I don't see how it is different. A "higher level of abstraction" means progressively higher-level versions of source code. Binary->machine/assembly code->C++ code for example. Each step involves reverse engineering. Simply disassembling/decompiling a binary is not really sufficient to be considered "reverse engineered". Someone needs to analyze the output of these tools to create reverse-engineered output which is ready to be modified/extended/investigated.
It does not really matter how we are interpreting the term "reverse engineering". What matters is how it was used in the OP article, in the EULAs and the national laws. In the article it was clearly applied to a binary analysis part of pen testing efforts by the Oracle customers, so this is what we should be discussing here.
I disagree. The author implies several times that the main issue, and the reason for the ban on reverse engineering in the agreement, is protection of intellectual property (source code). People may do other types of vulnerability testing, but the piece that Oracle is concerned about is trying to discover their source code (for example, by using static analysis tools...which analyze some version of source code).
I would consider that "some version of the source code".
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.
> The only definition of "reverse engineering software" that I use is this
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.
What you just described agrees with my definition. The ultimate goal of both teams was to end up with usable source code that is likely to be close or identical to the original used to create the binary. There is a slight difference in the IBM BIOS project in that, I think the goal was to create code which could not be claimed to infringe on the patents/copyrights of IBM. That last bit is an extension of reverse engineering, i.e. they reverse-engineered the binary (which took both decompilation and analysis) in order to create code which matched the same specification and wasn't outright "copied".
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.
You are right, that does agree with your definition. But, in my opinion, the reverse engineering was done only by the first team. They took the binary and constructed an understanding of the code. The second team just did basic software engineering from a spec. Your definition requires both teams and that's where your definition is too narrow.
Under EU law it is illegal to forbid someone to convert a binary back into source code.
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.
This isn't entirely accurate. There are restrictions on the legality of decompilation in Europe. The main one being that "...decompilation must be necessary to achieve interoperability with the target program or other programs. Interoperability information should therefore not be readily available, such as through manuals or API documentation."
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.
> if I buy a software, and it does not run on my system,
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.
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.
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!)"
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.
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.
> 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.
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.
To me, this reads like a post explaining the benefits of free software by demonstrating the disadvantages of using proprietary systems. A bit hyperbolic at that, though.
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.
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.
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.
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.
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.
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.
>>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.
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.
When I read this, I thought for sure it was just a lower-level engineering manager. I can't believe she's the Chief Security Officer, and that someone with a Wharton MBA could write something so unprofessional and full of disdain for your customers.
There is just no upside to this kind of response. Surely for any tech company that has reached a certain size, the only workable approach is to recruit an appropriately sized security team and politely welcome and respond to each and every security report received, triage them as quickly as possible and fix the ones that are found to be real vulnerabilities. Even if you aren't happy with the motives or the methods they employ, they are potentially finding flaws in your products for you.
Is this woman aware that static analysis is a non-negotiable requirement for filing your 510(k) if you do anything vaguely medical the FDA has to look at? Not that I would willingly choose Oracle for medical device applications, but the cognitive dissonance here is amusing. Pax vobsicum indeed.
They do use static analysis. However, they do not let third parties analyze their source code. Which shows even more hubris, because they're all but saying, "only we're smart enough to analyze our code."
Except, uh, in plenty of countries, those anti-reverse engineering clauses are void as a matter of public policy.
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)
> 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
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.
I agree with that point, and think it hits at something bigger. Having a bug bounty doesn't just say 'we give out money for bugs'. It also says 'we have a thought-out programme for handling serious user-reported problems, and we won't reprimand or dismiss you for sharing them'.
Don't worry, if you won't let your paying customers check for security holes, there are plenty of people in China who are going to do it for you instead.
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.
Their IT probably have an automatic preemptive policy of 404'ing any pages that become "popular"--any such content is is pretty much guaranteed to reflect poorly on their organization. False positives can always be waved away by a euphemism for a transient technical error ex post facto.
Whew. I've never read something from a company that was so insulting to it's own customers. I'd wager a bet that they won't be keeping their job for long.
While I admit that I didn't read the whole post (to me it was a wall of text full of complaints going around the same point, always saying the same without too much variation), I really don't get this obsession with reverse engineering. Yes, their license agreement states that it can't be done. But you deploy code, executable code, but still code. Code that people can understand, if they go through the process of analyzing it.
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.
I worked in Oracle SOA product(BPEL) for 2 years. We had to do migration from 10g to 11g because Oracle wasn't supporting 10g version anymore. While migrating we came across a lot of issues that worked fine with 10g but failed in 11g. So we raised a lot of service requests with Oracle. Most of those got rejected by Oracle as they were not high priority meaning there were terrible workarounds existing for them. They only bothered fixing those ones without which we can't work(I guess they had to or my company would have sued Oracle). We ended up writing a lot of horrible work around just to make existing code work.
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.
My understanding is that sites like archive.org honor robots.txt retroactively not because they are required to, but to best honor the wishes of the content provider.
Apart from the legal stuff and a lot off egocentric 'we can do it better', she has one point. There are many companies giving a lot of money for security, manually scrubbing all exploits that come out, create their own patches. While some lack the basic security guidelines. I think this money can be better spend upstream, to create tools so they can test patches for exploits better and create a faster security update release pipeline, so that all downstream and customers can rely on the security releases and that it can be released quicker to everyone. (Controversial: Maybe even adding automatic security updates to the package itself, like wordpress did, so that customer cannot be on a release with exploits)
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?"
What a bully! Reminds of someone at work, especially with this line: "I do not need you to analyze the code since we already do that, it’s our job to do that, we are pretty good at it".
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!"
No matter how valid her points are, the tone is inexcusable in a public-facing blog, especially when discussing customer behavior. I recognize the strong points of Oracle's offerings, but let's not pretend that there is not competition from other, open software.
Some media flack must've clapped eyes on that and had a VERY bad morning. The post has since been taken down, but here's a copy:
http://pastebin.com/RQA90EEb
I'm not sure what the author's argument is here. Is me reversing simply a nuisance and waste of Oracle's time? Is Oracle trying to obtain security via contractual obscurity? I see lots of comments here proposing that Oracle is protecting its IP, but I don't see evidence for that in the article (maybe its elsewhere, though).
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.
> A. The customer signed the Oracle license agreement, and the consultant hired by the customer is thus bound by the customer’s signed license agreement. 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!”
The author must have been undergoing some bad moments so far. The post seems just the outcome of a more complex series of inputs. Most points are not valid from my own personal point of view but still may have been good points if written in a more objective way.
Oracle seems to be like MS in that their reason for existing is that they came to be at the right time at the right place, and has pulled every trick in the book to pull up ladders behind themselves.
It's been deleted. Here's a mirror: https://web.archive.org/web/20150811052336/https://blogs.ora... - and while it's full of cringeworthy analogies, such as breaking a contract is just like cheating on your spouse, there's also, well, "logic" that defies conventional wisdom:
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.
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.
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.
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.
> 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.
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.