Oracle Exec: Stop Sending Vulnerability Reports
florin writes: Oracle chief security officer Mary Ann Davidson published a most curious rant on the company's corporate blog yesterday, addressing and reprimanding some pesky customers that just will not stop bothering her. As Mary put it: "Recently, I have seen a large-ish uptick in customers reverse engineering our code to attempt to find security vulnerabilities in it." She goes on to describe how the company deals with such shameful activities, namely that "We send a letter to the sinning customer, and a different letter to the sinning consultant-acting-on-customer's behalf — reminding them of the terms of the Oracle license agreement that preclude reverse engineering, So Please Stop It Already."
Later on, in a section intended to highlight how great a job Oracle itself was doing at finding vulnerabilities, the CSO accidentally revealed that customers are in fact contributing a rather significant 1 out of every 10 vulnerabilities: "Ah, well, we find 87 percent of security vulnerabilities ourselves, security researchers find about 3 percent and the rest are found by customers." Unsurprisingly, this revealing insight into the company's regard for its customers was removed later. But not before being saved for posterity.
Later on, in a section intended to highlight how great a job Oracle itself was doing at finding vulnerabilities, the CSO accidentally revealed that customers are in fact contributing a rather significant 1 out of every 10 vulnerabilities: "Ah, well, we find 87 percent of security vulnerabilities ourselves, security researchers find about 3 percent and the rest are found by customers." Unsurprisingly, this revealing insight into the company's regard for its customers was removed later. But not before being saved for posterity.
We and the blackhat hacker network can find our own vulnerabilities. We will protect you on our own schedule. If you are stabbed, control the bleeding as best you can; if you are shot, try to walk it off.
Support my political activism on Patreon.
I did not realise that this was available for free use to Oracle executives to help them reduce the stress induced by pesky customers who are trying to obtain a good service.
As it's been taken down: http://www.scribd.com/doc/2741...
"Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
The masses are so much more compliant when you convince them that crime is a sin.
Fuck you, Oracle.
It's interesting that Mary Ann Davidson was an accountant and then became the CSO at Oracle.
Mod me down, my New Earth Global Warmingist friends!
Aside from Java (which has it's own issues), Oracle's products are imo, craptastic. Horrid UIs, constantly crashing, slow, design decisions that make no sense, not modernizing, barely follow modern standards if at all, insanely overpriced (the least of the problems).
ORACLE is in the news they confirm yet again that quitting was the single best career decision I ever made.
The greatest thing about being an ex-oracle engineer is not working for Oracle anymore. I very much doubt anybody who has ever resigned from Oracle regrets it.
Worst company I've ever had the misery to work for.
Unicode killed the ASCII-art *
And the irony is ...
https://twitter.com/addelindh/status/631040188010131456
Oracle has been reportedly working hard in Washington trying to make security research illegal.
Of course, malicious hackers will always be finding exploits, and using them.
"First they came for the slanderers and i said nothing."
If I find myself in the position to report a flaw in Oracle products, do so through a responsible disclosure site (e.g. cert.org) and request anonymity.
CEO (on phone): Hey, I want to promote Mary Ann Davidson for her years of excellent service in our accounting department. We're going to make her CFO!
HR Director: Wow, you're making Mary Ann CSO?
CEO: Yes, CFO! Congratulate her for me.
HR Director: Are you sure, sir? I mean... Mary Ann... CSO?
CEO: Yes, of course! She'll make a great CFO!
HR Director: Do you think she's qualified to be CSO?
CEO: What do you mean? Of course she's more than qualified to be CFO!
HR Director: Wait, you're saying CSO, right?
CEO: Yeah, CFO!
HR Director: CSO?
CEO: CFO.
HR Director: CSO?
CEO: CFO!
HR Director: Okay, I think we're on the same page here.
I know many security professionals may be alarmed at this practice but i can assure you other examples exist where this tactic proves effective. For example, by ignoring or forbidding climate change discussion we actually prevent it from ever happening (clapping your hands helps too.) prior to abstinence only education, teenage pregnancy was ridiculously prevalent in the US. now that most sex-education courses in america are unstandardized and avoid covering things like condoms, birth control even simple intercourse, kids are a model of puritanical living.
im also told that the nuanced and layered complexity of immigration reform and homeless war veterans can be tackled by a large wall, and simply not looking at homeless people.
Good people go to bed earlier.
While the tone of the piece is more than a little condescending, there's an actual issue here, and she's not wrong about it.
Most customers would only reach out to a vendor with a bug report when they've actually found a real problem. Those bug reports are always welcome by any reputable vendor. They might be performance, or integrity bugs, or security bugs. Real bugs are good. They're welcome.
However, there's a second category of people (and she's write that bug bounty programs have somewhat encouraged them) that are the security equivalent of script kiddies - they downloaded a "sploits!" kit off the the internet (in this case, often a combination of a decomplier and static analyzer). They don't really understand how the kit works or what it does, but ZOMG I ran it against your code and it found issues! Your software is insecure! See? It says so right here! Now pay me something for all my hard work! I may not understand exactly what it's telling me, but it's telling me you have a bug! This group of people adds very little in the way of new bug discovery (again, most of their output really is known or false positive).
That second category of people (especially the ones who demand to be welcomed as liberating heroes) can in many cases get annoying. Because vendors really do run these kits against their code, so most of the time anything that isn't a false positive is a known issue. The back and forth with the customer really can sap time and energy (especially for customers who get strident and demand a "patch" right away or they'll go to the press and tell everyone how bad your code is).
I don't really blame someone who works in security for feeling frustrated that this small subgroup of customers continues to flood inboxes with "bug reports" that often they themselves don't understand, and which are often not useful.
That said, this is an absolutely idiotic tone to take in a blogpost directed at your customers. The problem can certainly be expressed in a way that doesn't sound childish, or scolding. This is a seriously dumb way for a company to semi-officially communicate with its customers.
Disclaimer: I do not and have never worked for Oracle. I don't even particularly like Oracle after the SSO suit against Google.
Mary Ann Davidson Blog
 Is Your Shellshocked... | Main
No, You Really Canâ(TM)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 the nom-de-plume Maddi Davidson. Recently, weâ(TM)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â(TM)ve been doing. Recently, I have seen a large-ish uptick in customers reverse engineering our code to attempt to find security vulnerabilities in it. This is why Iâ(TM)ve been writing a lot of letters to customers that start with âoehi, howzit, alohaâ but end with âoeplease comply with your license agreement and stop reverse engineering our 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 to unnamed 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â(TM)ve identified their critical systems, encrypted sensitive data, applied all relevant patches, be on a supported product release, use tools to ensure configurations are locked down â" in short, the usual security hygiene â" before they attempt to find zero day vulnerabilities in the products they 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 show or 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 much more to assurance than running a scanning tool - there are a lot of things a customer can do like, gosh, actually talking to suppliers about their assurance programs or checking certifications for products for which there are Good Housekeeping seals for (or âoegood codeâ seals) like Common Criteria certifications or FIPS-140 certifications. Most vendors â" at least, most of the large-ish ones I know â" have fairly robust assurance programs now (we know this because we all compare notes at conferences). Thatâ(TM)s all well and good, is appropriate customer due diligence and stops well short of âoehey, I think I will do the vendorâ(TM)s job for him/her/it and look for problems in source code myself,â even though:
A customer canâ(TM)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â(TM)t produce a patch for the problem â" only the vendor can do that
A customer is almost certainly violating the license agreement by using a tool that does static analysis (which operates against source code)
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 the customer, who then sends it to us. Now, I should note that we donâ(TM)t just accept scan reports as âoeproof 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 much more than a pile of steaming ⦠FUD. (That is what
Wow, Java and Oracle's DB are built on Flash, that explains much.
In Oracle's defense, if you're still using their cash cow database it's fair to say that it will do more financial damage to your company than most hackers could ever do.
Not sending reports to Oracle is a good idea: use open source alternatives and submit the reports there.
I'd love to, but Python is kind of slow. Has some implementation of the Python language recently become remotely comparable to Oracle HotSpot JVM in execution speed of equivalent programs? If so, which?
If I remember correctly, reverse-engineering to fix bugs that prevent software from working as intended and to secure systems is always legal in Europe, no matter what the contract says. But it is nice that Oracle confirmed that they do not care about their customers at all except as cash-cows. Not that this is a surprises to anybody.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
How cute that they think they can prevent people from finding flaws in their product with a licensing agreement. Why didn't I think of securing out network via legal agreements? The Bad Guys would never dream of doing something I told them not to do.
That actually sounds pretty sensible. It seems like much of her frustration is from people blindly running static analysis tools on their code, finding false-positive vulns, and wasting Oracle's time and making it more difficult to identify legitimate security vulnerabilities.
Much more reasonable than the summary made it out to be, thanks.
No, many of these tools are decompiling the code and then running static analysis on them. When hundreds or thousands of alleged "vulnerabilities" are found, they send the full report to Oracle. Naturally, most of these are false flags, as you'd expect from such a system. So, the frustration is somewhat understandable.
What's not understandable is how she could possibly imagine such a childish rant should be made in public.
Irony: Agile development has too much intertia to be abandoned now.
She's not happy about the true positives either - don't look at our stuff if it bugs out is the message she is sending here.
If the vendors I buy stupidly expensive stuff from starting acting that way I would inform them where they could put their lawyers and go looking for another vendor. I've had to reverse engineer some buggy commercial software on several occasions to find workarounds so that users can get stuff done, and have informed the vendor, who then informed their other customers (known problems list), fixed it or both.
No, it does not. A question "What does Oracle do if there is an actual security vulnerability?" is answered with "you found this because you reverse-engineered our code". That does not have to be true. On the other hand if I perform operation X and the product crashes, then they won't accept a submission unless you "provide a test case to verify that the alleged vulnerability is exploitable"
I read that clearly as "we do not want you to report any problems" and that makes their vulnerability reporting system just a PR thing.
Bingo bango bongo. People get set in their ways. And changing databases is... treated with the same trepidation that a man goes through when offered open heart surgery. I mean... you have to NEED to go in there before you even consider touching that shit.
And so businesses that don't need to change anything will often not change aspects of their core infrastructure for... decades. Again, IRS and a few banks have mainframes running software from the 70s. No really.
But new companies are going to be able to start from scratch and that means choosing what makes sense "today"... and that's not Oracle in most cases.
And for the big legacy institutions... eventually the patching and juryrigging and spaghettifying becomes unmanageable... and an upgrade becomes inevitable... and that's when the likes of Oracle have to justify themselves.
And none of that is made better by the generally shitty way they treat customers. I mean... people WANT to leave them if only out of spite. Oracle keeps copping this attitude of "make my day"... who the fuck do they think they are? Their software hasn't change remarkably in awhile and they think no one hasn't been able to copy the functionality? Come the fuck on, Oracle.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
static analysis of Oracle XXXXXX
Somebody should explain the idiot that the advanced tools for the code analysis are capable of checking (and instrumenting) the binary compiled code already for at least a decade.
When in the past I used the Rational Purify on the applications linked against the Oracle client, there were more that 200 Purify warnings coming from the Oracle libraries, and that before the main() was even reached. Draw conclusions yourself.
P.S. A global public variable - by all indications `int count;` - in the Oracle client libraries for Linux was just topping on the cake.
All hope abandon ye who enter here.