Oracle Tells Customers To Stop Trying To Find Vulnerabilities In Oracle Products... Because 'Intellectual Property'

from the huh? dept

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?



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

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.

Q. Hey, I’ve got an idea, why not do a bug bounty? Pay third parties to find this stuff!



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.

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?



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.

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.

Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community. Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis. While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.

–The Techdirt Team

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.The full post needs to be read to be fully appreciated, but the core argument is that (1) reverse engineering is bad because "intellectual property!" and (2) Oracle discovers most of its own bugs itself, so go away you annoying security researchers, Oracle doesn't need you. I'm not joking. Here's just some of the text around point (1) as part of an "FAQ" part of the post: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.On to point (2).And then down in the FAQ section: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. Of course a company should discover most of its own security vulnerabilities, but that doesn't lessen the need forlooking for, because some of those holes may be quite big and quite problematic -- and whyOracle want to encourage its own customers and the security researchers they hire to do more work to help improve Oracle's products?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:But, uh, this is not anything like "but everybody else is cheating on his or her spouse." This is. 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 tomake a better, more secure product. How is that anything like cheating on your spouse?Or this one:But that's not what's happening either. As the rest of the post makes clear, Davidson is talking about(i.e., thosefor 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.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