Hacker News new | past | comments | ask | show | jobs | submit login
“Stop reverse engineering our code” (oracle.com)
613 points by hughstephens on Aug 11, 2015 | hide | past | web | favorite | 344 comments



Wow. Really?

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.


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.

You can find a copy of it here: http://dacut.blogspot.com/2008/03/oracle-poetry.html

Note the copyright statement on the mispelled, 3-line poem with no literary merit whatsoever (which happens to be longer than the poem itself):

"The preceding key is copyrighted by Oracle Corporation. Dupl@ication of this key is not allowed without permission from Oracl1e Corporation. Copyright 2003 Oracle Corporation."

The purpose of this is to abuse the copyright on the above "poem" in order to prevent people from implementing the Oracle DB protocols. I guess they hope that everyone is ignorant of Sega v. Accolade? Even that trick of theirs is copied from elsewhere:

https://en.wikipedia.org/wiki/Sega_v._Accolade

EDIT: Reading that deliberate misspelling makes me wonder if I could start "Oracl1e Corporation" and give people permission to violate this? Sure, it'd be a ridiculous cheat, but so is the sham copyright on their worthless poem.


I 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.


Isn't the blogpost violating copyright by posting the whole poem?


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.


You can make a very strong argument for fair use in this case. Oracle knows this; if anything, their lawyers are not idiots.


Oracle reacted:

Oracle yanks blog post critical of security vendors, customers

http://www.computerworld.com/article/2969378/security/oracle...


Why didn't Sega just require games to be digitally signed with their key?


At the time, I'd guess that not many people knew anything about cryptography.


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).

Edit: fixed grammar


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é.

0. https://en.wikipedia.org/wiki/Escalation_of_commitment


"Sunk cost fallacy" is what my college "Engineering methods" course called it, but we are talking about the same concept.


makes for good examples that everyone can learn from


easier said than done.


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.


> Postgres deliberately resembles Oracle.

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.


[citation needed]

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 the tune of $1.5 x 10^8 USD

Was it really necessary to type it like that?


     _|_    __  ___   ___      ___    ___    ___      ___    ___    ___      ___    ___  
    / |_)  /  )| __) / _ \    / _ \  / _ \  / _ \    / _ \  / _ \  / _ \    / _ \  / _ \ 
    \_| \   )( |__ \( (_) )()( (_) )( (_) )( (_) )()( (_) )( (_) )( (_) )  ( (_) )( (_) )
    (_|_/  (__)(___/ \___/ /  \___/  \___/  \___/ /  \___/  \___/  \___/ () \___/  \___/ 
      |


For general sanity: $150,000,000


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.

Of course, accuracy is hardly relevant here.


s/accuracy/precision

Sorry, I don't usually try to be pedantic, but when the conversation is already about nitpicking, I think it's necessary.

Significant figures are precision, not accuracy. Accuracy is "being in the ballpark". Precision is "tight groups".


I'm sorry for the confusion. English is not my first language, and I resorted to https://en.wikipedia.org/wiki/Accuracy_and_precision to pick between "accuracy" and "precision".


To put it another way: "pi is exactly 3" is extremely precise, but not very accurate.


The very next task of mine

is a new value of pi to define.

I think I'll use 3

it's much simpler you see;

than 3.14159


You've simpified pi, that's fo' shore.

But rivalry says "level-up score".

With competitive drive,

It's yet higher I strive.

The value I'll use shall be four.


Well played


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.


Damn, and here I thought I needed to build a gigantic rocket.


My statement was accurate, just lacking in precision on the details :P


Or, the usual and shorter $150M.


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.


I don't think that they mean , one hundred and fifty times ten to the sixth factorial


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.


Dell Hell.

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.

http://www.cio.com/article/2439102/enterprise-resource-plann...


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.


ok you are a hair away from my favorite oracle acronym. One Rich Asshole Called Larry Ellison.


You might want to fact check yourself on Rockefeller:

Founded 1870, antitrust 1911:

https://en.wikipedia.org/wiki/Standard_Oil

Crude prices in that time frame (and beyond):

https://commons.wikimedia.org/wiki/File:Oil_Prices_Since_186...

Production in that time frame (having trouble finding a nice long time-series chart):

https://en.wikipedia.org/wiki/History_of_the_petroleum_indus...

If we want to make a strong claim of harmful monopoly[0], we should not expect to see a massive surge in production combined with an impressive decrease in price.

[0]Here I use the term "harmful monopoly" to refer to a firm that has both market power (can influence prices by controlling supply) and uses it to increase its own profits. What we see instead is a time period where we do indeed have a dominant firm, but one behaving as if it were in a competitive market.

The important characteristics of a competitive market here are low barriers to entry/exit, and a commodity product. There were incredibly low barriers to entry/exit, and oil has, for nearly its entire existence as a product in the modern age, been a commodity.


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'll go out on a limb here and assume that you agree just as vehemently with the ruling in Citizens United?


Apples and oranges - I'm not getting into this.


"We expect to see profit driven to zero in a competitive market, and that is what we saw in Standard Oil's pricing."

We don't see that in any of the information you provided. You gave a graph of oil prices, not of Standard Oil's profits.


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.


You're choosing to laser focus in on a specific aspect of the story and cut the bigger picture out of the frame in a very telling way.

Surely you've considered why Standard Oil's decision to do this was found to be anticompetitive, have you not?


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?


profit driven to zero in a competitive market

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.


If we're going to get into definitions, we can do that.

Since we are discussing economics, I do not feel the need to preface every use of jargon with disclaimers, though I can.

The relevant portion of Wikipedia's entry on (economics jargon) profit: https://en.wikipedia.org/wiki/Profit_%28economics%29#In_comp...

You can confirm this concept in any economics text. (economics jargon) Profit is driven to zero in a (economics jargon) competitive (economics jargon) market.


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!


It rocked my world. We don't live in the Atomic Age, or Computer Age, or the Age of Democracy.

We live in the oil age.

And the rapidity with which it arrived following Colonel Drake's well is staggering.


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.


And you might want to consult a contemporary account of Rockefeller, Ida Tarbell's The History of the Standard Oil Company.

https://archive.org/stream/historyofstandar00tarbuoft#page/n...

Particularly chapters 3 "The Oil War of 1872", 4 "An Unholy Alliance", and 5 "Laying the Foundations of a Trust".

The oil industry has almost always been controlled by a small cartel, though that cartel has varied though the years: Standard Oil, the As-Is agreement, the Texas Railroad Commission, the Seven Sisters, the National Producers, and OPEC.

It's not been a competitive market.

Though I'd argue that oil has been tremendously underpriced since 1869.


You’re ignoring opportunity costs. Standard Oil maintained high margins though monopoly pricing.


> Larry Ellison is the biggest asshole in Silicon Valley, and also the richest, so he must be doing something right.

This weekend I learned that Larry Ellison purchased ~90% of an island in Hawaii.


Bordering on Bond villain status at this point.


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.


You might enjoy this talk by Bryan Cantrill, where he describes the Oracle acquisition of Sun: https://www.youtube.com/watch?v=-zRN7XLCRhc&t=34m7s

> "what you think of Oracle is even truer than you think it is. There has been no entity in human history with less complexity or nuance to it than Oracle"

> "this company is about one man and his alter ego and what he wants to inflict upon humanity"

Edit:

And how could I forget this: https://www.youtube.com/watch?v=79fvDDPaIoY&t=24m

> "and then, the Nazis invaded"

> "for a while I tried to not go to Nazi allegory when talking about Oracle but I actually think that it does a dis-service to not go to Nazi allegory because if I don't use Nazi allegory when referring to Oracle there's some critical understanding that I have left on the table"


My favorite quote from that talk has always been:

> 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.


You forgot the bit about "The Larry Ellison Institute for the Prolonging of Life: <stage pause> namely his"


Hadn't seen the second talk, which is (no surprise) technically interesting as well as highly entertaining. Thanks!


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.


Hah, awesome. The sentiment he puts into portraying Oracle truely tells something about the company.


But I don't understand - why wouldn't Larry Ellison think he's Larry Ellison?

--Dad


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.


Look up the story of the State of Oregon's failed healthcare exchange. Set up by Oracle.

Last new I'm aware was Oregon sued Oracle for $200 million.

"Oregon sues Oracle over failed Obamacare website" http://fortune.com/2014/08/22/oregon-oracle-spat-200-million...

Oregon’s suit, filed Friday in state court, alleges that Oracle, the largest tech contractor working on the website, made falsely convinced officials to buy “hundreds of millions of dollars of Oracle products and services that failed to perform as promised.” It is seeking $200 million in damages.


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.


Turns out to be Oracle's chief security officer.

Read the other blog posts. Holy cow crackers.


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.


You can be authentic and speak your mind without being arrogant, insulting, and condescending.

In terms of tone, I wouldn't hold this up as a good example - it distracts from any legitimate argument the writer may or may not have.


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.


> This honesty enables me to make purchase decisions as well.

Fair point. And a hint to everyone still hanging on to oracle Databases.

One of the best lines is this here:

> Q. What does Oracle do if there is an actual security vulnerability?

> (...) if there is an actual security vulnerability, we will fix it.

Sure, the question is 'when', not so much 'if' customers have payed a hell of a lot money to get this straight.


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.


You can be authentic and speak your mind without being arrogant, insulting, and condescending

If you are by nature arrogant, insulting, and condescending, then no, you can't.



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.


Tell that to Pottering or de Raadt or Torvalds.


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.


Is this so different than the accusations of contempt often levied at several large personalities in the open source world?

I'm honestly curious about this.


Depends on which "several large personalities" you're referring to. Perhaps if you specify, your curiosity will be sated.


I am curious in general, as it is often noted that there is a trend in open source development communities to be hostile to end-users.

If pressed for specifics, Linus Torvalds and Theo de Raadt come to mind as a couple that are often called out for their abusive behavior.


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.


Opening up with the gambit about inventing unique ways of killing people was a genius way to set the tone for the piece.


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.


Ten out of ten for authenticity, minus several million for authentically saying something that's a good idea.


Agreed. The author is clearly wrong on a bunch of fronts; I don't think anyone here would argue otherwise.

I just don't understand the hatred directed towards someone who's writing without the usual corporate brain-mouth filter ...


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.


I see a few objections in this HN thread to the tone, but the primary objection (and my objection) is to the content.


Authentic shit is still shit?


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?


Seems like the original blog post was deleted, here is the archive - https://web.archive.org/web/20150811052336/https://blogs.ora...


Glorious. Somewhat surprised it was taken down, though.


I'm more surprised it was posted!

(at least in ~current~ as-it-was form)


I am not at all surprised that oracle would memory hole something that escapes PR control.


"Stop reverse engineering our blogs!"


Thanks for the mirror!


Thank you for using the word, "mirror" so that I could find it quickly.


Thanks, same here, I needed the mirror.

Note Oracle's reaction:

"Oracle yanks blog post critical of security vendors, customers"

http://www.computerworld.com/article/2969378/security/oracle...


> 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.


The scorn for customers in general is palpable. Why is Oracle even allowing this person to be a voice for their brand?


> Why is Oracle even allowing this person to be a voice for their brand?

Because her text will probably only infuriate people that will arguably never be Oracle customers?


> 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.


As if Oracle's practices shouldn't have already warned you away. If this is what set you off...


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 this rather be a reply to https://news.ycombinator.com/item?id=10040366 ?


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.


Considering the post is down, maybe they've "done something about it" already.


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.


Yes, agreed. Especially if, after checking out the first 100 or so, all of them are false positives.

But the big difference is that it's realistic, allowed and in many cases warmly welcomed if you submit actual problems.


Yes, but all other things equal, wouldn't you rather know what's in there?

Sun had an open bug database, it was glorious. That got snapped shut after purchase.


> Edit2: Seems like the blog was cracked. At least the "About" on the side seems to indicate that.

That's just the crappy Oracle blog platform presentation. Many of the Oracle blogs have that there, presumably a username.


> (this clause has to be illegal in some countries, too)

Pedantic: not illegal, but invalid.


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.

It always ends badly.


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?".


Interesting. In what industries is Oracle so dominant? You say government is one, but where else?

In industry, all I've ever seen is Sybase, SQL Server, and MySQL (ok, technically Oracle). (My background is finance and technology.)


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.


The same file system that the Linux developers have tried (and failed) to clone for almost 10 years now? Yeah, must be totally unremarkable.


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.


apologies, my fault.


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!


> Yes, it's your product, but this is my home!

My stance is that EULAs are bullshit, period. If you purchase a product, it is yours, and no one should be able to dictate how you use it.


Unfortunately courts seem to not share your stance, it seems.


Courts of which country? There are a lot of countries out there, some of them allowing reverse engineering (especially in Europe for example).


I read up on some of DCMA stuff, it does seem to allow some degree of reverse engineering in U.S..


Reverse engineering is legal in France for research and computer security (http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTE...).


Also in Switzerland:

> Art. 21 Decoding of computer programs

> 1 Any person who has the right to use a computer program may obtain, either personally or through a third party, necessary information on the interfaces by decoding the program code using independently developed programs.

> 2 The interface information obtained by decoding the program code may only be used for the development, maintenance and use of interoperable computer programs insofar as neither the normal exploitation of the program nor the legitimate interests of the owner of the rights are unreasonably prejudiced.

https://www.admin.ch/opc/en/classified-compilation/19920251/...


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.


Sure, but this is a contract matter between two private entities. Oracle can still revoke your license for doing it.


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]

[1]: https://twitter.com/thegrugq/status/631056841670135808


In German law, clauses that forbid reverse engineering are invalid, the contract itself still stays valid, though.

UhrG Paragraph 95 and 69


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.


Constitution > Law > Contract.


The clauses in laws can be of two kinds:

- 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).


Many static analysis tools are working on JVM bytecode level, and there are quite a few for even the raw x86.


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.

disclaimer: I don't live in Europe and am not familiar with the most up-to-date software laws there. This is from the following source: https://en.wikipedia.org/wiki/Decompiler#Legality


> 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!)"


heh, 'alleged'...


"They weren't real vulnerabilities, because we knew about them!"


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.


There is nothing wrong with signed java applets. There is no difference between that and downloading and running (a signed) application.


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.


> Java exploit after Java exploit

One zero day in 2 years. Not quite the disaster area it's made out to be on HN.


http://www.cisco.com/web/offers/lp/2014-annual-security-repo...

"91% of web exploits are targeting Java"


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.

http://www.oracle.com/technetwork/topics/security/cpujan2015...


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?


The previous post on the blog has a similar tone too https://blogs.oracle.com/maryanndavidson/entry/is_your_shell...


The formatting in that post is... interesting.

I'd blame the CMS before the author on that point though.


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.


Original has been deleted, cached version available:

http://webcache.googleusercontent.com/search?q=cache:ntXM0Rl...



> 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.

/rant


>Ah, well, we find 87% of security vulnerabilities ourselves, security researchers find about 3% and the rest are found by customers.

They admit more security vulnerabilities are found by customers than security researchers and still they release this smug "fuck off" toned blog.


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.)


How do you arrange your PG clusters, are you using streaming replication?


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.

The heavy lifting for the conversion is done using ora2pg http://ora2pg.darold.net/ Then there's a pile of faff and twiddling and unit tests and so forth. See also https://wiki.postgresql.org/wiki/Oracle_to_Postgres_Conversi...


Sorry for late reply, thanks for the info! Interesting to see what others are doing.


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.

RMS would have a field day.


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.


Can some infosec person speak to her strongest claim, that static analysis gives "basically 100% false positives" and wastes the team's time?


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.


Now you see where she's coming from.


A major point for a well-maintained product is that you run all the same tools yourselves, fix the real issues, and only the false positives remain.


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.


You can statically analyze a binary as well. "Static analysis" is just a technique for deducing the properties of a system without running it.


You and lawnchair are exactly right!

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.


The quote:

"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 know what static analysis is.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: