A traffic sign with the Oracle logo is displayed outside of the Oracle headquarters on December 16, 2014 in Redwood City, California.
Photograph by Justin Sullivan — Getty Images
By Robert Hackett
August 11, 2015

Take note: If your job is to protect software, it’s probably not a good idea to tick off hackers.

Mary Ann Davidson, the chief security officer of Oracle (ORCL), the world’s second-largest software maker, has said she’s been irritated by how often she’s had to have a particular conversation with computer crackers. While the hackers like to point out what they deem to be security flaws in Oracle software—in the hopes of winning compensation and credit—she has to keep telling them that they’re violating their licenses by engaging in such research.

The volume and generally poor quality of the findings have been distracting and frustrating for her team, she has said.

So to hell with it, she decided on Monday. In a state of apparent exasperation, she penned a long, ranting tirade against vulnerability-hunting security researchers. The post didn’t last long on the company’s corporate blog, however, before Oracle pulled it down. (You can read an archived version here.)

Rather than welcoming a helping hand from the hacker community (or even politely demurring), Davidson smacked the living bejesus out of it. “Please Stop It Already,” Davidson wrote, exhorting computer bug hunters who reverse engineer Oracle source code in the hopes of finding flaws to quit the practice. In so doing, researchers often break the terms of the company’s end user license agreements, she noted. “Please don’t go there,” she said. “Don’t. Just—don’t.”

 

“I’m not beating people up over this merely because of the license agreement,” she continued, citing a prevalence of false positives turned up by security consultants and scanning tools as an unwelcome nuisance. “(P)lease 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.”

To paraphrase: We can handle our security ourselves, thank you very much.

Oracle deleted the blog post shortly after it appeared. “We removed the post as it does not reflect our beliefs or our relationship with our customer,” read a statement provided to Fortune by a company spokesperson, attributed to Edward Screven, Oracle executive vice president and chief corporate architect.

But Davidson’s screed had already struck a nerve in the security community. (Search the hashtag #oraclefanfic on Twitter, for instance.)

“I understand what Mary Ann was trying to achieve with this post, but what they really need is a way to control the flow of information without simply saying ‘Don’t… Just don’t,'” commented the co-founder and CEO of bug bounty startup BugCrowd, via email. “All that being said, I’m really glad that they took the post down. This means, in spite of the tone of the email, she’s listening to the community (who had a unanimously bad reaction).”

Chris Wysopal, chief technology and information security officer at the application security firm Veracode, weighed in via email, too. He described Davidson’s “discouraging” remarks as “an attempt to turn back the progress made to improve software security.”

In a mock Q&A, Davidson explained what would happen in the event that a researcher did find a true bug. In short: her team would fix it quietly, begrudgingly, without thanks, and move on.

Q. What does Oracle do if there is an actual security vulnerability?

A. I almost hate to answer this question because I want to reiterate that customers Should Not and Must Not reverse engineer our code. However, if there is an actual security vulnerability, we will fix it. We may not like how it was found but we aren’t going to ignore a real problem – that would be a disservice to our customers. We will, however, fix it to protect all our customers, meaning everybody will get the fix at the same time. However, we will not give a customer reporting such an issue (that they found through reverse engineering) a special (one-off) patch for the problem. We will also not provide credit in any advisories we might issue. You can’t really expect us to say “thank you for breaking the license agreement.”

There is, of course, a danger in alienating bug hunters. Code has flaws. And laying down a prohibition against finding them will not stop security researchers from continuing to poke around. Without an alternative option, those researchers might simply choose sell their findings to the highest bidder. Say, an unfriendly nation state.

Perhaps Oracle might benefit from a policy update, one that does not forbid vulnerability-seeking and one that clearly delineates what counts as a valid bug and what does not. Already, big tech companies ranging from Google (GOOG) to Microsoft (MSFT) sponsor bug bounty programs. More recently, United Airlines (UAL) and Tesla (TSLA) have hopped on board with programs of their own.

According to Josh Corman, founder of the security advocacy group I am the Cavalry, not attacking bug hunters and those that approach companies with vulnerabilities is a best practice.

There might be fewer erroneous submissions and ticked off hackers that way—and more importantly, better security.

SPONSORED FINANCIAL CONTENT

You May Like

EDIT POST