Monday, March 15, 2010

Bookmark and Share

Archive for the ‘Oracle’ Category

Litchfield plays Nathan to Oracle’s David

The Greeks believed that the Oracle at Delphi was the center of the universe (the “navel of world” they called it.) People throughout the Hellenistic (Greek) world would travel to the Oracle to ask all sorts of questions and the Oracle (specifically the priestess within the Oracle) would provide a (usually ambiguous) answer.

Like most ancient cultures, the role of the Oracle was not just to predict the future. There was that too, but like most ancient cultures, the Oracle also had a social role as well. It’s true – the Oracle was the one place where kings and queens, emperors and priests could hear the “damning truth” about their policies and actions. If you examine what we know about the Oracle at Delphi or we examine what we know about the Old Testament prophets, we find a surprising amount of social and political commentary within their pronouncements. From a social perspective, this makes sense. For example, consider the case of King David and Uriah the Hittite; who was right there to condemn David for his actions? Nathan the prophet, sure enough. He was right there to tell David where his actions fell short. And he could – the King would be hard pressed politically if there were negative repercussions against a prophet (the prophets were seen as speaking with God’s voice, so how could the King retaliate?)

So… where am I going with this? Well, recently I came across a report from David Litchfield about the “resiliency” (resistance to vulnerabilities) of Microsoft’s SQL server compared with that of Oracle’s database. Interestingly, Microsoft came out on top. This is particularly interesting to me for two reasons – first, I find it ironic that David Litchfield is fulfilling the traditional “Oracular” role of pointing out where the emperor has no clothes, and I find it interesting as well for what it says about the efficacy of the secure coding measures in place at both firms. As you probably know, Oracle uses automated analysis of their code to attempt to reduce vulnerabilities while Microsoft uses an “ingrained process” approach (the SDL). Over the short term, Oracle’s approach of using a code-scanning tool is probably cheaper and less intrusive to the development process… but it is not self-reinforcing, so there are no efficiency gains over time – in other words, it requires continued investment: today it costs X to scan the code and tomorrow it costs the same (or more.) Contrast this with Microsoft’s approach. While more expensive in the short term, the SDL has the advantage of reinforcing itself over time; in other words, the investment made today will continue to pay off over the long term becoming cheaper and more effective over the long haul. An interesting strategy, and one that I think these results bear out…

Bookmark and Share

Oracle Vulnerabilities and the CVSS

In the past, I’ve jumped all over Oracle about their vulnerabilty issues. So when I saw folks alleging that Oracle is potentially downplaying vulnerabilities in their software by under-weighing them (in other words, deliberately misrepresenting the seriousness of the vulnerabilities when coming up with the CVSS score), I was very interested.

Here’s the background story: this month, Oracle updated how it represents the seriousness of it’s vulnerabilities; instead of using their own proprietary method, they’ve decided to use the CVSS in their risk profile for these vulnerabilities. They’ve actually even been so open as to expose the underlying weights that they’ve plugged in to the CVSS calculations so that customers can see exactly why a certain issue has a particular severity (for example. using the CVSS score calculator here.) Now, the argument is that the numbers are too low; for example, on a 10-point scale, the vast majority are 4 or lower. Sounds pretty damning, right? There are over 100 vulnerabilities including buffer overflows, SQL injection, and a host of other “biggies.” But if you drill down on how they’re coming up with the numbers, it gets harder and harder to find fault with it (believe me, I’ve tried.)

For example, the CVSS is a ten-point scale, that’s true. But the CVSS is designed such that a vulnerability is weighted according to the impact that it has on the system; a vulnerability that only partially discloses data, for example, is scored less than a vulnerability that fully discloses data. This makes sense, right? What oracle did, in the majority of cases, was use “partial” as the value for “confidentiality impact”, “integrity impact” and “availability impact” when some say a “complete” would have been more appropriate. But is that really what they should have done?

Let’s take Integrity as an example. Take a look for a minute at the CVSS guide to see what these values are supposed to mean; here’s the straight dope on “Integrity” according to the guide (section 1.1.5):

None: No impact on integrity.

Partial: Considerable breach in integrity. Modification of critical system files or information is possible, but the attacker does not have control over what can be modified, or the scope of what the attacker can affect is constrained. For example, key system or program files may be overwritten or modified, but at random or in a limited context or scope.

Complete: A total compromise of system integrity. There is a complete loss of system protection resulting in the entire system being compromised. The attacker has sovereign control to modify any system files.

Now, somebody could make the argument (like Oracle appears to have done) that a buffer overflow in the Oracle software has “partial” impact because it only exposes files accessible to the Oracle account – not the root account. Granted, somebody could escalate privledges after hacking in through the vulnerability, but that’s not related to the vulnerability – it’s another issue entirely. This interpretation (favorable to Oracle though it might be) seems to be in line with the intent of the CVSS; take a look at the Apache exmaple llaid out in the CVSS guide (section 3.1):

In other conditions, however, the attacker would be able to execute code with the permissions of the web user, thereby altering web content and possibly viewing local user or configuration information (including connection settings and passwords to back-end databases). Therefore, Confidentiality and Integrity Impact metrics are set to “Partial”…

In other words, a literal-minded person, looking at the examples in the CVSS guide, would probably conclude that an application running in a non-root account (e.g. the Oracle database) would have only partial impact to Integrity in the event of a buffer overflow much like was the case with the Apache account in the example. Applying the same logic to all three of confidentiality, integrity, and confidentiality means a difference of three points total for “partial”s rather than “complete”s.

So, if we assume the literal-minded argument, the maximum value for that any Oracle vulnerability could possibly have would be a 10-3=7: or a seven point scale. Is that accurate? Is that the intention of the CVSS? Maybe not. But I don’t think Oracle’s out of line for interpreting it that way. Sure, the numbers are smaller than you’d expect. And they’re probably not reflective of the actual severity of the issue – at least when taken at face value. But is it Oracle’s fault? They’re applying the criteria as the example; they’ve been pretty open about “showing their work” so that folks can make their own determinations on risk; and they’re using the standard rather than the previous opaque risk value… Maybe they’re not in the wrong. Or if they are, somebody should really clarify the intent of the CVSS to make it impossible to mistakenly use the weighting methodology that Oracle did. But that’s just my two cents.

Bookmark and Share

Evidence that Mary Ann Doesn’t Read the Michael Howard blog

In his entry “Security Analogies are Usually Wrong, Michael Howard does a bit of delving into the “software security by analogy” poing of view:

I usually roll my eyes when I hear statements like,

Bookmark and Share

Oracle on Software Security

Oracle has (probably wisely) been keeping their head down the past few months, so imagine my excitement when I saw that IDG put out this where Oracle discusses their approach to software security. And there’s some choice stuff in there – the article starts with Mary Ann Davidson commenting on the “unbreakable” campaign. Talking about her reaction when she first heard it, she said “my response was ‘What idiot dreamed this up?” What idiot, indeed. I’m not going to fault her for this criticism, since I happen to share her opinion. However, a stickler could make the point that she saw things as a little less black-and-white back in the day:

“We believe the market effect of the ‘Unbreakable’ campaign raises the security bar and therefore improves security overall, both in forcing us to live up to the statement, and forcing others in the industry to begin to do the same. If our security today is imperfect but better than the competition, and if customers make a buying decision based on that criteria, than in the long term you will see all products in the market improve.”

Oh well, not that it matters now. The article then moves on to discuss internal Oracle development security efforts. Given Oracle’s track-record in security, I’m surprised that they’re running with this message. For example:

Davidson said the record for fixing one defect was 78 patches, which cost the company around $1 million.

If this were you, would you broadcast having to issue 78 patches to fix one bug? Yeah, I probably wouldn’t either. As to whether or not they are getting better, I think it’s too early to tell. However, I guess we’ll find out in time…

Bookmark and Share

Whipping Boy Update: Oracle

Just when you thought there was nary a peep about Oracle in the industry press, along comes Information Week with a four-page take on Oracle’s patching process. The piece highlights some of the criticism that Oracle’s had from David Litchfield, Red-Database-Security, etc. The article’s long, but well worth the read.

There’s some great stuff here, and the fact that a major outlet like Information Week is covering this means that people are starting to take notice…

Bookmark and Share

Oracle’s Hubris: Punishment is Coming

In case you missed it, Oracle has put the world on notice to “turn security rhetoric into action”. That was the theme of Evelyn Sell’s (Senior Program Manager with Oracle) presentation last week at SECURECon; basically she took the stage to tell all of us security practitioners and developers that there is no excuse for security rhetoric that isn’t backed up by action. Wow. Do I even need to say it? Does “unbreakable” ring a bell? Or when Larry Ellison said “we haven’t had a vulnerability in twenty years”? Clearly they aren’t and clearly they have. Once again, I am flabbergasted by the hubris and hypocrisy coming out of that firm.

Now I thought I was about as irritated at Oracle’s as I was going to get – but clearly I was wrong. For anybody who hasn’t been paying attention, Oracle is not a the standard for software security – despite what their marketing department might tell you. I remember studying Attic Greek at one point in the distant past, and there are a few things I remember about Hubris: first, I remember that the quality of hubris (‛′Υβρις) is the principal downfall of characters in the tragedies. I also remember that it was one of the worst personality characteristics that the Greeks could imagine a person having. Almost any time that a character demonstrated the trait in tragedy, they were struck down (usually by the gods). To illustrate how much the Greeks hated this quality, the word can mean either “insolence” (akin to the sense we use it in today) or “violent crime” and was punishable by death under Athenian law. The Greeks loved to see those people on a “high horse” get their lumps.

I think the Greeks were on to something; I think the security community is starting to react to Oracle’s bull. Gartner has said they are no longer a “bastion of security”, researchers are working overtime to poke holes in their products, and they’re spending increasing amounts of money to bolster their image. The stage is set, and I think we’re there’s some major divine wrath on the horizon.

Bookmark and Share

Oracle to World: “Security Mission Accomplished…”

Oracle has responded to the charges from Gartner and others that it is the new security whipping-boy by sending out the message that “it’s totally handled”. This time it’s Hasan Rizvi, VP of security products who’s sending the message:

Our customers are so used to high security that when there is a vulnerability they don’t apply the fix because they are not used to it, which is an interesting position to be in. People have to apply them and we can’t do too much about that.

So Oracle’s position is that they are so secure that people are confused about the need to apply patches. So, in the unlikely event that they do need to patch, the customers don’t know they need to apply it. No seriously, that’s the message…

I think some of the problems are, ironically, because of our strong track record and [customers] don’t take some of the processes [sic] to fix them seriously.

So, to paraphrase; “Oracle’s security is the best in the industry, and our customers (recognizing our prowess) keep dropping the ball because we’re so damn good.” Is it just me or does anyone else find this message to be somewhat “out of touch?”

Bookmark and Share

Dave Litchfield Tells It Like It Is

Ever see two dogs fight? I don’t mean the “oooh, let’s roll around and get dirty” play-fighting – I mean the snarling, snapping, frothy-mouthed, “kujo” kind of fighting. For those of you that have seen that in action, concentrate on that image, and you’ll have a succinct description of the current relationship between Dave Litchfield and Oracle’s security organization.

Think I’m overstating the case? Take a look at this article, where Dave faces off against Duncan Harris. The original post by David is sarcastic and inflamatory; needless to say, I personally loved it. Oracle’s response, via Duncan Harris was equally heated; take this quote, for example:

“By just revealing what he has in this workaround, it definitely is a very strong starting point for any malicious hacker…to try and understand the vulnerability and produce an exploit. Yes, we are clearly disappointed that he felt the need to say anything about this vulnerability before we had a patch available”

My thought on this is that neither of them are right. David’s wrong for (albeit sarcastically) recommending a vendor-unsupported security fix. Just as I said when SANS starting touting the unofficial wmf patch, I don’t think installing any fix/workaround that isn’t supported by the vendor is a good idea. On the other hand, one might well wonder why Oracle hasn’t fixed this vulnerability. Everyone (even Oracle) seems to agree that this bug allows untrusted parties to gain DBA access to a database remotely – since this bug is in the PLSQL-gateway component which is often installed on Internet-facing servers, that’s a pretty dangerous proposition. Since they had four months to fix it, one wonders why they didn’t do so.

So, neither of them are right – clearly. But they are wrong to varying degrees. Dave is guilty of (at best) encouraging users to void the Oracle warranty, Oracle is guilty of (at best) misrepresenting their security posture. In other words, David’s message could have been phrased better, whereas Oracle’s message was (in my opinion) dangerous and disingenuous. It’s dangerous because this is a publicly-known high-risk bug that Oracle intends to leave unpatched until April (when the next quarterly bug fix comes out.) It’s disingenuous because it contradicts statements made last week by Duncan in his Q&A. Last week, Duncan told us all about the Oracle traige process; he said how important it was that fixes were prioritized according to criticality. He had a whole paragraph about it:

It absolutely depends on their severity. The Critical Patch Update that we [just] issued — one of the vulnerabilities there was reported to Oracle in November. There is another that was reported to Oracle 800-plus days ago by external researchers. That is not something we are proud of, [but] it points to the fact that we fix vulnerabilities in order of severity.

How can that be accurate? Is it really the case that this bug (which in a typical configuration permits DBA-level access to a database from the Internet) was analyzed, prioritized, and judged to be less dangerous than the other 82 fixes included in last week’s patch bundle? Occam’s Razor would seem to indicate that one of the two messages he put out this week is fiction – either this bug wasn’t prioritized according to severity (as per the Q&A) or the vulnerability process over there doesn’t work the way he said it does as per today’s response to Dave.

Bookmark and Share

Gartner goes “Jean Claude” on Oracle

Rob over at Googgun always comes through with the good information.

This time, he sent me a great link to this article describing how Gartner hammered Oracle’s security practices like when Dux landed the “Dim Mak” in Bloodsport. Granted, Gartner’s a bit late to the party on this one – a number of analysts have been critical of Oracle for a while now – but Gartner’s big, so people listen when they say stuff.

Check out all the meaty derision for Oracle in their research:

Oracle provides only very limited information about vulnerabilities

Bookmark and Share

Inside Oracle’s Patch Kimono

Computerworld just ran a down and dirty discussion with Duncan Harris, vulnerability and patch guy over at Oracle. In the past, I’ve been critical of Oracle’s approach to patching their applications – particularly in light of opinions published by David Litchfield and others. After reading this, I’m even more critical. Take a look at some of the responses, like here where Duncan explains how well they do (or do not) work with security researchers; note the thinly-veiled attack on publicly-minded researchers:

In terms of working with the security community, we work very well with those that are happy to abide by the security vulnerability handling processes, which we have published on our Web site for anyone to see. There are others who for their own good reasons choose to pressure us and put our customers at risk by a partial or early or zero-day disclosure of vulnerabilities in Oracle products. I assume that is part of their marketing method to potentially increase their consulting business.

Interesting. Just for the record, the published process (found here) does not specify a time window for when vulnerabilities will be addressed by Oracle. The process does not specify what communication (if any) will take place between Oracle and the researcher. The process does not define any mechanism for testing fixes with the researcher, for putting developers in touch with the researcher, for notifying the researcher of the priority of the vulnerability, for providing the researcher with updates on the process, or even for tipping the researcher off when the patch is ultimately released. In fact, the only thing the process does say is that Oracle will fix the problem – eventually per its own timetable – and that the researcher should basically shut up about it in the meantime. From what we are told by researchers who work with Oracle, the “cone of silence” that is the vulnerability reporting process at Oracle can leave a vulnerability researcher scratching their head for months or even years.

Let’s walk through a hypothetical scenario. If a researcher were to identify dozens of critical security flaws in Oracle products and report them to Oracle, they would write them up and submit them into the Oracle process. Oracle will assign each issue a priority – which they do not have to apprise the researcher of (in fact, it is in Oracle’s best interest not to apprise the researcher of the priority.) At this point, the researcher has no guarantee of when those problems might get fixed. Since Oracle acknowledges that patches can take up to 800 days (Duncan mentioned the “three year bug” in his second response on page 2) and since the Oracle process does not include provisions for notification to the researcher, it could be years before the researcher hears anything one way or the other about what they reported. A publicly-minded researcher might grow frustrated with the process after a long period of time – say 6 months or so – where Oracle has not acted; particularly so when patches are published that do not address the problem in the interim. A well-meaning researcher might want to put pressure on Oracle to take action and remove the security risk from Oracle customers; they might see Oracle’s failure to act as directly putting individuals in danger as well: increasing their risk of being victims of identity theft, fraud, or embarassment. What (if any) recourse does a researcher have? Only one – notification to the public.

Look, I’m not saying that Dave’s a bastion of truth and justice or anything like that. However, I do think it takes a sackfull of Chutzpah to make the claim that his motivation is “increasing his consulting business”. Despite what Duncan would have you believe, most vulnerability research pays nothing – in the case of David Litchfield specifically, he does have services that he offers, but do those services increase in value the more bugs he finds in Oracle products? I personally doubt it, and the assertion isn’t something I would accept without evidence (especially from an Oracle mouthpiece) anyway.

What concerns me is that between these comments and Mary Ann’s previous rant stating that security researchers are a problematic bunch, I think there’s a cultural problem at Oracle; specifically, I think there is evidence of a culture of resistance against external security researchers. Just for comparison, take a look at Oracle’s vulnerability process, compare it with Microsoft’s , and tell me again why Microsoft is the security pariah?

Bookmark and Share
“Cut through the confusion to increase your agility and decrease your response time.”
Blog Cloud

The Law: Fear It Administrative Cruft (16)
Analysts (31)
Apple (25)
AppSec (12)
Assessments (2)
Auditors (2)
Biometrics (4)
Blogs (13)
Breaches (21)
Buzzwords (2)
By Grabthar's Hammer!! (1)
Certifications (1)
Change Management (1)
Cheezburger Network (1)
Chupacabra (1)
Cloud Computing Security (4)
Collaborative Strategy Guild (2)
Compliance (4)
Copyright (9)
Credit Cards (3)
Crypto (11)
CXO Summit 2010 (1)
Cyberterrorism (2)
Data Protection (1)
DHS (25)
eBay (1)
Emergence (1)
End-to-End Encryption (1)
England (1)
Financial Fraud (1)
FISAP (1)
Forensics (5)
FTC Red Flad Rules (1)
FUD (12)
gnisreveR (2)
Google (2)
Holidays! (3)
Humor (16)
Identity Theft (4)
James Bond Shiz (1)
Legal Shiz (13)
Linux (3)
Malware (35)
Marketing and PR (9)
Messaging Security (1)
Microsoft (26)
Monoculture (3)
Mouth-Frothing (2)
Musings (17)
Open Source (3)
Oracle (21)
Outsourcing (4)
Paris Hilton (1)
Passwords (1)
PCI (4)
Phish-Eye (8)
Phones (5)
Planes (1)
Privacy (1)
Programming (1)
QDSP Blues (15)
Research (30)
Resources (6)
Rhesus Monkeys (2)
Risk Management (18)
RSA 2009 (1)
RSA 2010 (1)
SAML (1)
SAN (1)
SC Mag Blues (1)
SCADA (1)
Security Curve (8)
SecurityCurve Speaking (2)
SIEM and Log Management (5)
Social Networking (1)
SOX (1)
Speaking (2)
Spinach (1)
Spy Stuff (1)
Stealing Stuff (8)
Storage (1)
Symantec (7)
Tarot (1)
Teleological suspension of the ethical (3)
The Great Borack (1)
The Law: Fear It (10)
The Old Man of the Mountain (1)
The Regs (5)
Tokenization (1)
Useless Shizz (13)
Vendors (37)
Virtual Worlds (2)
Voting (2)
Vulnerabilities (40)
Walt Disney (2)
Wi-Fi (16)

WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.

Archives