Oracle Tells Customers To Stop Trying To Find Vulnerabilities In Oracle Products... Because 'Intellectual Property'
from the huh? dept
Update: After writing this, but before I had a chance to publish, it appears that someone at Oracle realized how terrible this looked and deleted the original post, though you can see an archived copy here.Computer security guru Matt Blaze called our attention to a bizarre (and bizarrely written) blog post by Oracle's Chief Security Officer, Mary Ann Davidson, telling people to stop reverse engineering Oracle products in search of security vulnerabilities. As Blaze points out, the article is so bizarre that he thought that Oracle must have been hacked and the story posted as a parody.
My first assumption after reading this was that Oracle's web server was hacked and this article is a parody. https://t.co/ODpT4L76TE
— matt blaze (@mattblaze) August 11, 2015
Q. But the tools that decompile products are getting better and easier to use, so reverse engineering will be OK in the future, right?But this makes no sense. There's no reason to "protect intellectual property" solely for the sake of protecting intellectual property. Davidson seems to clearly admit that the security researchers doing this reverse engineering aren't doing it to "copy" the code or to leak it/resell it/post it to The Pirate Bay or whatever. They're just doing it to look for security vulnerabilities. What does that have to do with "intellectual property" at all? Absolutely nothing. It's just one of those things that people yell when they have no other argument. "But intellectual property!" It just seems nonsensical, because nothing about this has anything to do with intellectual property other than as an excuse for why Oracle doesn't want to hear from security researchers.
A. Ah, no. The point of our prohibition against reverse engineering is intellectual property protection, not “how can we cleverly prevent customers from finding security vulnerabilities – bwahahahaha – so we never have to fix them – bwahahahaha.” Customers are welcome to use tools that operate on executable code but that do not reverse engineer code. To that point, customers using a third party tool or service offering would be well-served by asking questions of the tool (or tool service) provider as to a) how their tool works and b) whether they perform reverse engineering to “do what they do.” An ounce of discussion is worth a pound of “no we didn’t,” “yes you did,” “didn’t,” “did” arguments. *
On to point (2).
Now is a good time to reiterate that I’m not beating people up over this merely because of the license agreement. More like, “I do not need you to analyze the code since we already do that, it’s our job to do that, we are pretty good at it, we can – unlike a third party or a tool – actually analyze the code to determine what’s happening and at any rate most of these tools have a close to 100% false positive rate so please do not waste our time on reporting little green men in our code.” I am not running away from our responsibilities to customers, merely trying to avoid a painful, annoying, and mutually-time wasting exercise.And then down in the FAQ section:
Q. Hey, I’ve got an idea, why not do a bug bounty? Pay third parties to find this stuff!Look, it's actually great that Oracle finds most of its own vulnerabilities. That's kind of what you'd expect. If it were otherwise, then, um, Oracle should be searching for a new Chief Security Officer. But that's really not the point. These things are not mutually exclusive. Of course a company should discover most of its own security vulnerabilities, but that doesn't lessen the need for more eyes looking for more vulnerabilities, because some of those holes may be quite big and quite problematic -- and why wouldn't Oracle want to encourage its own customers and the security researchers they hire to do more work to help improve Oracle's products?
A.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.
So, no, Oracle doesn't need to do a bug bounty. That's obviously a choice that each company can make for itself -- but it's difficult to see why Oracle seems to be so actively trying to piss off security researchers and its own paying customers.
The post is also chock full of just ridiculous analogies:
Q. Surely the bad guys and some nations do reverse engineer Oracle’s code and don’t care about your licensing agreement, so why would you try to restrict the behavior of customers with good motives?But, uh, this is not anything like "but everybody else is cheating on his or her spouse." This is your argument makes no sense. The point raised by that "question" is that this whole thing about "protecting intellectual property" makes no sense, because the people who are actually looking to violate your intellectual property rights don't care about your license agreement in the first place. The issue here are customers and their security researchers who aren't looking to do anything nefarious but are actually looking to help Oracle make a better, more secure product. How is that anything like cheating on your spouse?
A. Oracle’s license agreement exists to protect our intellectual property. “Good motives” – and given the errata of third party attempts to scan code the quotation marks are quite apropos – are not an acceptable excuse for violating an agreement willingly entered into. Any more than “but everybody else is cheating on his or her spouse” is an acceptable excuse for violating “forsaking all others” if you said it in front of witnesses.
At this point, I think I am beating a dead – or should I say, decompiled – horse. We ask that customers not reverse engineer our code to find suspected security issues: we have source code, we run tools against the source code (as well as against executable code), it’s actually our job to do that, we don’t need or want a customer or random third party to reverse engineer our code to find security vulnerabilities. And last, but really first, the Oracle license agreement prohibits it. Please don’t go there.
Or this one:
Q. But one of the issues I found was an actual security vulnerability so that justifies reverse engineering, right?But that's not what's happening either. As the rest of the post makes clear, Davidson is talking about Oracle customers (i.e., those paying for Oracle licenses) doing some vulnerability testing themselves to make sure that the systems are really secure. So it's not the bizarre analogy of breaking into a house. It's more like renting a house and checking to make sure that the doors are actually secure, and then pointing out to the landlord if they're not and that they should be fixed.
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.
Oracle obviously has every right to determine how it handles its security efforts and how it relates to its own customers and security researchers, but this post seems incredibly tone deaf and designed to piss off Oracle's own customers in the name of "protecting intellectual property" for no reason other than "that's our intellectual property, which you paid for, and how dare you want to make sure it's safe."
Filed Under: intellectual property, mary ann davidson, reverse engineering, security, security research
Companies: oracle