Scribd

8/11/2015No, You Really Can’t (Mary Ann Davidson Blog)https://blogs.oracle.com/maryanndavidson/entry/no_you_really_can_t1/11

Oracle

Blogs HomeProducts & ServicesDownloadsSupportPartnersCommunitiesAboutLogin

Oracle Blog

Mary Ann Davidson Blog

« Is Your Shellshocked... | Main

No, You Really Can’t

By User701213-Oracle on Aug 10, 2015

I have been doing a lot of writing recently. Some of my writing has been with my sister, with whom I write murder mysteries using thenom-de-plume Maddi Davidson. Recently, we’ve been working on short stories, developing a lot of fun new ideas for dispatching people (literarily speaking, though I think about practical applications occasionally when someone tailgates me).Writing mysteries is a lot more fun than the other type of writing I’ve been doing. Recently, I have seen a large-ish uptick in customersreverse engineering our code to attempt to find security vulnerabilities in it. <Insert big sigh here.> This is why I’ve been writing a lot of letters to customers that start with “hi, howzit, aloha” but end with “please comply with your license agreement and stop reverse engineeringour code, already.”


I can understand that in a world where it seems almost every day someone else had a data breach and lost umpteen gazillion records tounnamed intruders who may have been working at the behest of a hostile nation-state, people want to go the extra mile to secure their systems. That said, you would think that before gearing up to run that extra mile, customers would already have ensured they’ve identifiedtheir critical systems, encrypted sensitive data, applied all relevant patches, be on a supported product release, use tools to ensureconfigurations are locked down – in short, the usual security hygiene – before they attempt to find zero day vulnerabilities in the productsthey are using. And in fact, there are a lot of data breaches that would be prevented by doing all that stuff, as unsexy as it is, instead of hyperventilating that the Big Bad Advanced Persistent Threat using a zero-day is out to get me! Whether you are running your own IT showor a cloud provider is running it for you, there are a host of good security practices that are well worth doing.Even if you want to have reasonable certainty that suppliers take reasonable care in how they build their products – and there is so muchmore to assurance than running a scanning tool - there are a lot of things a customer can do like, gosh, actually talking to suppliers abouttheir assurance programs or checking certifications for products for which there are Good Housekeeping seals for (or “good code” seals) likeCommon Criteria certifications or FIPS-140 certifications. Most vendors – at least, most of the large-ish ones I know – have fairly robustassurance programs now (we know this because we all compare notes at conferences). That’s all well and good, is appropriate customer duediligence and stops well short of “hey, I think I will do the vendor’s job for him/her/it and look for problems in source code myself,” eventhough:A customer can’t analyze the code to see whether there is a control that prevents the attack the scanning tool is screaming about(which is most likely a false positive)A customer can’t produce a patch for the problem – only the vendor can do thatA customer is almost certainly violating the license agreement by using a tool that does static analysis (which operates against sourcecode)I should state at the outset that in some cases I think the customers doing reverse engineering are not always aware of what is happening because the actual work is being done by a consultant, who runs a tool that reverse engineers the code, gets a big fat printout, drops it on thecustomer, who then sends it to us. Now, I should note that we don’t just accept scan reports as “proof that there is a there, there,” in part because whether you are talking static or dynamic analysis, a scan report is not proof of an actual vulnerability. Often, they are not muchmore than a pile of steaming … FUD. (That

is

what I planned on saying all along: FUD.) This is why we require customers to log a service


request for each alleged issue (not just hand us a report) and provide a proof of concept (which some tools can generate).If we determine as part of our analysis that scan results could

only

have come from reverse engineering (in at least one case, because thereport said, cleverly enough, “static analysis of Oracle XXXXXX”), we send a letter to the sinning customer, and a different letter to thesinning consultant-acting-on-customer’s behalf – reminding them of the terms of the Oracle license agreement that preclude reverseengineering, So Please Stop It Already. (In legalese, of course. The Oracle license agreement has a provision such as: "Customer may notreverse engineer, disassemble, decompile, or otherwise attempt to derive the source code of the Programs..." which we quote in our missiveto the customer.) Oh, and we require customers/consultants to destroy the results of such reverse engineering and confirm they have done so.Why am I bringing this up? The main reason is that, when I see a spike in X, I try to get ahead of it. I don’t want more rounds of “you brokethe license agreement,” “no, we didn’t,” yes, you did,” “no, we didn’t.” I’d rather spend my time, and my team’s time, working on helpingdevelopment improve our code than argue with people about where the license agreement lines are. 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 needyou 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.For this reason, I want to explain what Oracle’s purpose is in enforcing our license agreement (as it pertains to reverse engineering) and, in areasonably precise yet hand-wavy way, explain “where the line is you can’t cross or you will get a strongly-worded letter from us.” Caveat:I am not a lawyer, even if I can use words like

stare decisis

in random conversations. (Except with my dog, because he only understandsHawaiian, not Latin.) Ergo, when in doubt, refer to your Oracle license agreement, which trumps anything I say herein!With that in mind, a few FAQ-ish explanations:Q. What is reverse engineering?