Saints or sinners?

Oracle customers who scan its code to find vulnerabilities were branded ‘sinners' by an Oracle executive. But should the vendor be encouraging the practice, asks Doug Woodburn?

In May this year, Oracle was picked as enterprises' least favourite software vendor in a survey conducted by IDC, finishing last in all categories covering areas such as licensing complexity, ease of management and perceived ROI.

But if the ERP and database giant is aiming to build bridges with its seemingly alienated user base, its chief security officer Mary Ann Davidson clearly didn't get the memo.

In a caustic blog post earlier this month, Davidson compared customers and consultants who "reverse engineer" its code in an effort to uncover vulnerabilities to "sinners" and adulterers.

The practice breaches Oracle's licensing terms and conditions, Davidson said, adding that Oracle is "pretty good" at finding vulnerabilities in its code itself.

The missive (some of the choice cuts of which you can read at the bottom) was met with a storm of criticism, including from Bob Tarzey, a director at analyst Quocirca, who argued Oracle should be encouraging rather than sanctioning customers and researchers who scan its code for flaws at a time when ERP systems are increasingly coming under attack.

The now infamous post, entitled "No, you really can't", was taken down by Oracle within 24 hours of its publication, after the vendor concluded Davidson's colourful views were not in keeping with its corporate image.

But that does not change the fact that Oracle is clamping down not only on customers but also consultants who reverse engineer its code, something it doesn't want them to do partly because it breaches its licensing terms and conditions.

Davidson revealed the extent of the crackdown: "Recently, I have seen a large-ish uptick in customers reverse 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 licence agreement and stop reverse engineering our code, already'," she said.

Much of the time, the reverse engineering is done not by the customer but a third-party consultant, who runs a tool that reverse engineers the code and produces a scan report that is often "not much more than a pile of steaming FUD", Davidson said.

She stressed that if Oracle determines from analysing such scans that they could have come only from reverse engineering, it will take action.

But Tarzey said Oracle should not only be condoning end users and channel partners who find vulnerabilities in its code, but encouraging the practice.

"There are good reasons for cracking down on reverse engineering but stopping customers checking for vulnerabilities is not one of them," he said.

"I would say Oracle should at least turn a blind eye to it, but to proactively go out and target customers in this way, when all they are trying to do is uncover security vulnerabilities Oracle has failed to find itself, that's pretty unsympathetic towards customers."

There is an increasing focus on ERP systems as weak points to hack into firms' supply chains, meaning the onus is on channel partners to help protect end users in this area, Tarzey (pictured) added.

"I spoke to two companies last week that were focused on finding and protecting customers from vulnerabilities in ERP applications, because they are being increasingly targeted," he said.

"Increasingly, the onus is on the VARs who support those systems to ensure their security - it's part of their job. Oracle should be actively encouraging it."
Alexander Polyakov, chief technology officer of ERPScan, one of the two firms Tarzey referenced above, was also critical of the sentiments Davidson expressed.

ERPScan specialises in helping customers find vulnerabilities in SAP and Oracle and Polyakov said he has personally found more than 30 issues in Oracle applications.

"Oracle is not just a vendor, it's the vendor whose software is installed in almost every Fortune 2000 company, and our lives depend on their solutions' security," he said. "Nuclear power plants, manufacturing, banking - name anything and you will find either Oracle or SAP or both systems, which manage mission-critical processes. When this kind of vendor is saying they don't need any help from external researchers, in terms of vulnerability findings, well, this world is too dangerous."

Polyakov called into question how secure Oracle's code is, saying it is "much easier [to find a vulnerability in it] than you think".

"For most issues, I did not use any reverse-engineering tools and just tried to enter data in the field where nobody expected this type of data," he revealed.

"Simple? Yes. And that works. What does it mean? It means that to find most of the vulnerabilities in Oracle products (and there are about 3,000, by the way) you don't need to be a hacker, you just need to have good testing skills. In scientific terms, it is a boundary testing, and if such types of tests are failed, it means even worse than a software with vulnerabilities. It's a software without proper quality assurance. OK, big vendor, if you don't care about security, is QA also unimportant?"

Kevin Bland, EMEA channel director at open source software management and security vendor Black Duck Software, said Davidson's blog reflects the fact customers have woken up to the threat of security vulnerabilities within applications.

"Why would companies collectively spend millions of dollars on reverse engineering third-party applications to understand if they contain vulnerabilities that could blow a hole in their security? Quite simply because they are right," Bland said.

"While IT departments and CISOs focus their time and efforts tirelessly on securing the perimeter and encrypting the packets, security vulnerabilities are finding their way into the infrastructure via applications."

Davidson's blog post was greeted with disbelief on social media, with some even speculating Oracle had been hacked and it was a hoax.

But in a statement, Oracle executive vice president and chief corporate architect Edward Screven moved to clarify that it took the blog down because it did not chime with the Oracle party line.

"The security of our products and services has always been critically important to Oracle," Screven said.

"Oracle has a robust programme of product security assurance and works with third-party researchers and customers to jointly ensure that applications built with Oracle technology are secure. We removed the post as it does not reflect our beliefs or our relationship with our customers."

‘Please stop it already'

During the course of her now infamous, 3,036-word blog post, Oracle CSO Mary Ann Davidson touched on a startling range of topics, including her hatred of British economist John Maynard Keynes, boy bands and the murder mystery novels she has written with her sister. But she also compared Oracle customers to sinners and adulterers, as the below excerpts demonstrate.

"..We send a letter to the sinning customer, and a different letter to the sinning consultant acting on [the] customer's behalf - reminding them of the terms of the Oracle licence agreement that preclude reverse engineering, So Please Stop It Already."

"I actually heard this [if you don't let us reverse engineer code, we won't buy anything else from you] 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 licence 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'."

"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. Well, we find 87 per cent of security vulnerabilities ourselves, security researchers find about three per cent and the rest are found by customers... On a strictly economic basis, why would I throw a lot of money at three per cent of the problem?"