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.
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.
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
Was it really necessary to type it like that?
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.
Someone once told me that Larry Ellison is the biggest asshole in Silicon Valley, and also the richest, so he must be doing something right. The same could be said for John D Rockefeller and Standard Oil. Is the world we have the world we want?
http://www.cio.com/article/2439102/enterprise-resource-plann...
Founded 1870, antitrust 1911:
https://en.wikipedia.org/wiki/Standard_Oil
Crude prices in that time frame (and beyond):
https://commons.wikimedia.org/wiki/File:Oil_Prices_Since_186...
Production in that time frame (having trouble finding a nice long time-series chart):
https://en.wikipedia.org/wiki/History_of_the_petroleum_indus...
If we want to make a strong claim of harmful monopoly[0], we should not expect to see a massive surge in production combined with an impressive decrease in price.
[0]Here I use the term "harmful monopoly" to refer to a firm that has both market power (can influence prices by controlling supply) and uses it to increase its own profits. What we see instead is a time period where we do indeed have a dominant firm, but one behaving as if it were in a competitive market.
The important characteristics of a competitive market here are low barriers to entry/exit, and a commodity product. There were incredibly low barriers to entry/exit, and oil has, for nearly its entire existence as a product in the modern age, been a commodity.
This weekend I learned that Larry Ellison purchased ~90% of an island in Hawaii.
> "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"
--Dad
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.
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.
Read the other blog posts. Holy cow crackers.
But: this is authentic. This is what we (i.e. hackers) are always claiming we want. Someone speaking her mind, shooting from the hip, etc. Not an anodyne blob of corporate-speak: this is an opinion, stated pretty clearly, and backed up with fighting words.
You'd expect: "Our legal team has advised us to remind consultants that they are bound by any and all terms and conditions to which their clients have ... etc. etc. etc."
You get: "Otherwise everyone would hire a consultant to say (legal terms follow) “Nanny, nanny boo boo, big bad consultant can do X even if the customer can’t!”"
Here we have someone who clearly loves the company and the product with a passion, defending both against what she sees (very wrongly, in my opinion) as criminal misuse and waste of resources.
I'll take one of these posts and argue its merits any day, over a block of mealy-mouthed corporate crap.
In terms of tone, I wouldn't hold this up as a good example - it distracts from any legitimate argument the writer may or may not have.
If I was an Oracle customer (which I will never, ever be) I would appreciate the honesty. This honesty enables me to make purchase decisions as well, better than megabytes of legalese would have. In this case it's not a really surprising attitude given the company, but I really wish more vendors would be as open about the nature of their intended relationship with their customers.
If you are by nature arrogant, insulting, and condescending, then no, you can't.
Interesting that all the reasons she cites for why she thinks trying to reverse-engineer Oracle products is a bad idea are the same exact reasons why more and more administrators with any sense in security are switching to open-source software and have been for the last decade or so. Being able to inspect the code yourself (or hire someone to do it for you) is apparently important enough to a sufficiently-large population for Oracle to whine about it.
I'm honestly curious about this.
I don't think it's an unreasonable fairy tail to say this is a person who is frustrated, who has drunk the corporate kool-aid in a big way, who is dealing with the detritus of a rather nasty security confidence scam industry, and is putting their views out there. Even if you or I don't like the message, I believe she meant it. I believe it. Maybe I'm gullible.
We also want intelligence and clear thinking along with it. We don't, as a rule, want loud and dumb as a bag of rocks. That way lies Donald Trump.
At the same time, this is a huge improvement over corporate doublespeak. It helps the stupidity and arrogance shine through clearly, which is one reason that I like it when people talk this way.
I just don't understand the hatred directed towards someone who's writing without the usual corporate brain-mouth filter ...
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?
> Art. 21 Decoding of computer programs
> 1 Any person who has the right to use a computer program may obtain, either personally or through a third party, necessary information on the interfaces by decoding the program code using independently developed programs.
> 2 The interface information obtained by decoding the program code may only be used for the development, maintenance and use of interoperable computer programs insofar as neither the normal exploitation of the program nor the legitimate interests of the owner of the rights are unreasonably prejudiced.
https://www.admin.ch/opc/en/classified-compilation/19920251/...
Source: by logical extension of: the "no refund" portion of game EULAs is nullified in EU. I'm no lawyer, though.
It doesn't matter though. Even if Oracle can legally stop customers and researchers from reverse-engineering their software world-wide, they can't stop malicious elements because the malicious elements never disclose that they have done it: Oracle only find out after they have been pwnd. I would say "serves them right," but the sad truth is that their customers are going to get hurt the most.
Edit to add: I don't think this[1] warrants an entirely new post.
> Oracle has told people to stop using @Veracode to test their AppSec. They already got AppSec covered [picture of JS injection attack in the blog post]
UhrG Paragraph 95 and 69
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).
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.
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.
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.
Her statement gains 1% truth because Oracle might already have picked the low-hanging fruit, and any more reports they get really are full of chaff. I find this unlikely, but it's possible. She gets another 1% for this.
> A customer can’t analyze the code to see whether there is a control that prevents the attack
That's actually a pretty decent point. Anyone who has actually studied static-analysis reports for any length of time has probably encountered this phenomenon. For example, you might find a potential buffer overflow that's real in the context of the code you analyzed, but the index involved can't actually be produced because of other code that you didn't. Or maybe a certain combination of conditions is impossible for reasons related to a mathematical property that has been thoroughly vetted but that the analysis software couldn't reasonably be expected to "know" about. Ironically, these kinds of "reasonable false positives" tend to show up more in good programmers' code, because they're diligent about adding defensive code handling every condition - including conditions that aren't (currently) possible. In any case, while it's a good point, it's applicable rarely enough that it doesn't really support the author's broader position.
I think the impedance mismatch here might be that you're a software developer, and we're talking about security teams.
I don't know that anyone is arguing that static analysis is useless for developers. If you're intimately familiar with the code you're working on, there are probably a lot of ways to make static analysis results both valuable in every edit/compile/debug cycle, and an important part of your team's release process.
But when you're close to the code, it's easy to forget how much of the tool's output you're ignoring (either literally, by just skimming past findings you know don't matter, or implicitly, by configuring the tool to match your environment or subtly changing your coding style to conform to Coverity's expectations).
Security teams can't generally do this. They're stuck with the raw output of the barely-configured tool. The results of static analysis in these circumstances is nonsensical: memory leaks, uninitialized variables, race conditions, tainted inputs reaching SQL queries, improper cleanup of sensitive variables, 99.9% of which aren't valid findings, but all of which look super important, especially if you're consultant with 6 months of experience charging $150/hr to run Fortify on someone else's code, then petulantly demanding a response for every fucking issue the scanner generates.
They're fine dev tools, but they are terrible tools for adversarial inspection, which is what Davidson is talking about.
The problem here is:
1) She might be a writer but boy did she not convey the message I think she wanted to, which is kind of a shame. 2) She doesn't apparently much understand "reverse engineering" with more nuance than "my legal team says you can't do it so there", which is much more of a shame for someone who carries a CSO bag.
1) the answer should usually be either "fixed in this patch, install it" or "it's a false positive, try developing an actual exploit if you don't believe us". Not expensive, provided Oracle actually runs static analysis tools against their software and addresses the findings before releasing updates.
2) If Oracle actually runs static analysis tools against their software and addresses the findings before releasing updates, there should be very few tickets of this type to begin with, often from the debut of new tools or from naive user mistakes. Finding something, and worse finding something over and over again, means that Oracle QA is inadequate.
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)
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.
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.
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.
and it's not helpful because of the near 100% false positive rate.
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.
But in all seriousness, if the Chief Security Officer of Oracle sounds like the letters to the editor of my University Paper, why doesn't a company that big have someone from PR edit or co-write her posts?
https://web.archive.org/web/20140313161522/https://blogs.ora...
There was another post in much the same vein on that blog:
https://blogs.oracle.com/maryanndavidson/entry/those_who_can...
I've seen this institutional hubris first-hand. The unshakable belief (typically by nontechnical management) that all of the smartest people in the world are employed here, working for me.
It always ends badly.
Then, if it turns out that it's a security issue, of course they are going to notify Oracle of the fact, both as a moral duty, and because it makes it more likely that Oracle will get a patch out faster.
Oracle whinging about people finding bugs in their code would be better off trying to improve their processes so that there are less bugs to find, rather than complaining that they've been found out for shipping buggy code.
I literally can't touch a Government project without an Oracle license. When I talk to a salesman, the attitude is "I know you can't do this without me", contrary to salesmen for any other product in any other industry.
When I talk to a project manager, they don't ask how it will be hosted, or what the platform will be, or anything else obvious. The first question, often before a project is fined, is "how many Oracle licenses can I buy?".
In industry, all I've ever seen is Sybase, SQL Server, and MySQL (ok, technically Oracle). (My background is finance and technology.)
In that sense I don't see why people do not moan about having to pay a rent because your tenancy contract that you signed says so...
Long story short, its a right of a SOFTWARE mostly company to protect its software, open source is not always the solution and reverse engineering something, consumes way more energy for the problems it actually solves.
You think customers are reverse engineering Oracle products for fun? They're doing it because there's a problem somewhere, they've filed a bug report and not got a satisfactory result, and so they have to go pay an expensive consultant to try and track down the problem for them with no source code.
Even if none of the other arguments for open source were persuasive, this situation with Oracle alone would be enough to convince many people of the wisdom of choosing an open source vendor.
So, she's telling legal bullshit just to provoke a fear in people that stops a totally legal practice.
They also have a duty of care to their clients
> open source is not always the solution
No one saying it is. Plenty of other proprietary software vendors protect their softwaqre in customer-friendly ways.
> reverse engineering something, consumes way more energy for the problems it actually solves
When a vendor like Oracle gives you no other option to solve the very real problems that your company has with the software, the "energy consumption" can be more than worth it, even it wasn't the ideal path in the first place.
And so are you. Not paying is inherently wrong. This is an arbitrary rule more akin to "no looking out the east window".
Trying to sell something to be used but not understood is a fool's errand.
In terms of a rental agreement, a "no reverse engineering" clause is not equivalent to "you must pay rent." It's more like a clause that says you're not allowed to consume meat while you live there because the landlord is a vegetarian.
Perhaps, but this article appears to be very strong evidence to the contrary.
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.
But the big difference is that it's realistic, allowed and in many cases warmly welcomed if you submit actual problems.
Sun had an open bug database, it was glorious. That got snapped shut after purchase.
That's just the crappy Oracle blog platform presentation. Many of the Oracle blogs have that there, presumably a username.
Pedantic: not illegal, but invalid.
Did someone at Oracle actually think that this was the best way to make this point?
I'd blame the CMS before the author on that point though.
> A. I actually heard this from a customer. It was ironic because in order for them to buy more products from us (or use a cloud service offering), they’d have to sign – a license agreement! With the same terms that the customer had already admitted violating. “Honey, if you won’t let me cheat on you again, our marriage is through.” “Ah, er, you already violated the ‘forsaking all others’ part of the marriage vow so I think the marriage is already over.”
What a thoroughly nasty comment. She is comparing her customer with someone who is cheating on their spouse. Disgusting.
Because her text will probably only infuriate people that will arguably never be Oracle customers?
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.
One zero day in 2 years. Not quite the disaster area it's made out to be on HN.
"91% of web exploits are targeting Java"
If so, then somebody at Oracle realized that post reflected poorly on their organization. Perhaps there is some hope for Oracle yet.
No matter how interpersonal she puts it. It makes me not ever want my system to rely on a company that threatens and belittle customers for protecting themselves.
If I bought a fridge for my house, I found a listening device and a pinhole camera in the fridge. Just because the company has a clause I am not allowed to open up the fridge, it doesn't mean I shouldn't.
Well, the company might have found the devices. Indeed maybe nothing customers can do until the company fixes it. Keep telling customers they are not allow to look for flaws it just ridiculous. Yes, it's your product, but this is my home!
My stance is that EULAs are bullshit, period. If you purchase a product, it is yours, and no one should be able to dictate how you use it.
"(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!)"
(We're in the midst of an Oracle->Postgres conversion right now. It's going wonderfully. I strongly advise you to look into it, bet you'll find it way easier than you think.)
(One of the nicest things about it: we give every app its own cluster of two PG boxes, because you can just do that instead of running a centralised monster box with an expensive license. It turns out that just everything not having to play nice with others makes stuff stupendously easier to manage.)
This was all cobbled together following the docs. There are almost certainly better ways to do everything we've done so far.
The Postgres is just 9.3 out of the Ubuntu 14.04 repo. Oracle was STUPENDOUS overkill for what it was actually being used for, but MySQL wasn't up to the job.
The heavy lifting for the conversion is done using ora2pg http://ora2pg.darold.net/ Then there's a pile of faff and twiddling and unit tests and so forth. See also https://wiki.postgresql.org/wiki/Oracle_to_Postgres_Conversi...
Aren't the issues not found by Oracle the problem? I'm amazed that stil 23% of the externally found security issues are reported by researchers, the incentive to responsibly disclose security issues to Oracle isn't really big. It sounds like a cumbersome process with potential legal consequences.
There also are researchers(, maybe after a first bad experience about an EULA,) that sell security issues to the grey/black market. Is there any data on how many Java zero days are exploited in the wild before being fixed?
Changing your stance and being grateful for responsible disclosures and only using your EULA to threaten and sue the bad people can potentially save everyone with java installed from a few zero days at zero cost.
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.
http://webcache.googleusercontent.com/search?q=cache:ntXM0Rl...
a) is bad, and the users should just be turned away. b) is good and far better than selling them on the black market. c) is... who cares it's a license agreement.
(b) is good, but her point that them spending their time doing static analysis of oracle's software is a monumental waste of time is perfectly valid, if their root password is password and the firewall is just some sheetrock in the basement.
Well, Apple does (for jailbreak exploits).
>I am not dissing bug bounties, just noting that on a strictly economic basis, why would I throw a lot of money at 3% of the problem
Uh ... You don't think that percentage will increase if you offer bounties?
And if it doesn't, well, they don't pay out much. It's not like bug bounties consist of just throwing money at random people and hoping they find vulns; you pay for results. That's sort of the point.
Though saying to your client that they cannot reverse engineer to look for security problems, is totally not done! What is next? "Exploits will not be fixed, because the users has signed an agreement that they will not hack?"
Your JDBC driver IP isn't that valuable, just give me the damned source code so I can figure out why my Postgres copy out stream is blocking when I insert it into your copy in stream.
/rant
They admit more security vulnerabilities are found by customers than security researchers and still they release this smug "fuck off" toned blog.
RMS would have a field day.
And in any product that uses LGPL code, for example, it's actually a license violation to forbid customer modification and reverse engineering for the purpose of debugging those modifications.
(Though, admittedly, everyone always violates this term)
If I'd read this last night... I still would've argued the same thing, but I would've been really unhappy about it.
While I don't endorse breaking the agreement (which was properly signed and "celebrated", as lawyers say), I find it funny in the first place that they're selling a glass container and say "you can't look into it, just use it".
I prefer the honesty of free software/open source projects that sell customer support to this business model (which is also adopted by others, not just Oracle). However, if I were already bound to it, and couldn't pay the cost of migration, I understand I'd have to stick with it.
It's also amusing that people/organizations seriously believe they can reverse engineer something as complex as a database engine and "fix it" without acces to the diagramas, docs, tests, source code, build environment, etc.
Yes we did not reverse engineer that code even though I feel it would have done lot of good for us. Not to mention the tool set provided by Oracle is utter crap as in it barely works on its own.
So I am not at all surprised that Oracle have that kind of mentality here. In all our communications with Oracle I felt they never really actually cared for what we the customers really want. All they actually care about it protecting their investments.
JRE CVEs: http://www.cvedetails.com/vulnerability-list/vendor_id-93/pr...
It's been 5 years since Oracle took over Java, so they can't claim it was left over.
Oracle's security record is terrible by all accounts, so how can their CSO justify anything in this blog post?
ORACLE product list CVEs: http://www.cvedetails.com/product-list/product_type-/firstch...
This makes me want to climb the empire state building, beat my chest like a gorrilla, and yell "Let me do what I know best!"
Any subsequent valid points she makes - and there aren't many - are undermined by this bitterness.
Heightened emotion so often enables effective communication, but it doesn't do any favors in this post.
I wonder if Oracle would send one of those reminders to a customer who analyzed an attack by an attacker who "broke the license agreement" by reversing the customer's copy of some Oracle software.
Really? What if no money changes hands?
BTW, the post is gone.
Q. But one of the issues I found was an actual security vulnerability so that justifies reverse engineering, right?
A. Sigh. At the risk of being repetitive, no, it doesn’t, just like you can’t break into a house because someone left a window or door unlocked. I’d like to tell you that we run every tool ever developed against every line of code we ever wrote, but that’s not true. We do require development teams (on premises, cloud and internal development organizations) to use security vulnerability-finding tools, we’ve had a significant uptick in tools usage over the last few years (our metrics show this) and we do track tools usage as part of Oracle Software Security Assurance program. We beat up – I mean, “require” – development teams to use tools because it is very much in our interests (and customers’ interests) to find and fix problems earlier rather than later.
That said, no tool finds everything. No two tools find everything. We don’t claim to find everything. That fact still doesn’t justify a customer reverse engineering our code to attempt to find vulnerabilities, especially when the key to whether a suspected vulnerability is an actual vulnerability is the capability to analyze the actual source code, which – frankly – hardly any third party will be able to do, another reason not to accept random scan reports that resulted from reverse engineering at face value, as if we needed one.
Q. Hey, I’ve got an idea, why not do a bug bounty? Pay third parties to find this stuff!
A. <Bigger sigh.> Bug bounties are the new boy band (nicely alliterative, no?) Many companies are screaming, fainting, and throwing underwear at security researchers to find problems in their code and insisting that This Is The Way, Walk In It: if you are not doing bug bounties, your code isn’t secure. Ah, well, we find 87% of security vulnerabilities ourselves, security researchers find about 3% and the rest are found by customers. (Small digression: I was busting my buttons today when I found out that a well-known security researcher in a particular area of technology reported a bunch of alleged security issues to us except – we had already found all of them and we were already working on or had fixes. Woo hoo!)
I am not dissing bug bounties, just noting that on a strictly economic basis, why would I throw a lot of money at 3% of the problem (and without learning lessons from what you find, it really is “whack a code mole”) when I could spend that money on better prevention like, oh, hiring another employee to do ethical hacking, who could develop a really good tool we use to automate finding certain types of issues, and so on. This is one of those “full immersion baptism” or “sprinkle water over the forehead” issues – we will allow for different religious traditions and do it OUR way – and others can do it THEIR way. Pax vobiscum.
