Security Curve Weblog

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.

OpenSSL FIPS 140 Certified!

You know when you're expecting something, and you know it's going to be really cool - but it seems so far away that you think that it will never happen? Well, that was the case for me with OpenSSL's FIPS 140-2 certification. It's been a long time coming, but it's finally here. The cert is in place, opening up a world of opportunity for engineers working in the federal space.

Good news for the security community, but probably bad news for us since it slightly outdates the FIPS "selecting a library" portion of our book. :-(

Want to get blown away?

I came across Geoff Huston's IPv6 discussion today by way of the Hack the Planet Weblog. Totally a must-read.

One from the vaults

You know how some people tout Apple's OS X platform as being completely free from security issues? I'm sure you've seen the rhetoric:

"Mac OS X... untouched by the ocean of security issues, threats, virus and worms epidemic which have become instead Windows-users daily worry and preoccupation." -Robin Good

etc. Anyway, there's a short but harsh article that came out today from a researcher saying that Apple has serious security problems; what's interesting to me is not the article per se which is frankly somewhat terse, but the fact that this appeared on ZDNet, and the fact that it is hyper critical of Apple's software review process. Interesting.

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 — far less than is industry-standard — making it difficult for enterprises to evaluate the risk. The company sometimes patches internally discovered vulnerabilities without releasing details.

Ouch... I love it. And:

The quality and ease of use of Oracle patches still require improvement, because of reported installation and stability problems.

I'm not a Gartner-zombie or anything, but they're on-target with this one.

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?

Saturday Evening Humor

Now this is funny:

countered Mary Ann Davidson, CSO at Oracle. “These hackers providing us with free security testing and showing their impatience after a mere 880 days are what causes problems..."

Totally a must read...

Visa: Not where I wanted to be

Visa claims to be everywhere I want to be. I'm highly suspicious of this claim, since most of the time that they get involved in something, I usually wind up learning the hard way that I really don't want to be there. This happened to me once again, as I just went through the training and accredidation required to become a Visa QDSP (Qualified Data Security Professional.)

Before I get into this, let me say that it was the content of the class that bothered me, not the format; in other words, the instructor was friendly and presented well, the food was relatively atkins-friendly, and the class got out early both days. In short, most of the things that would usually be a source of major concern in a class were not a problem in this one. But the experience was painful nevertheless.

So why am I so down on the PCI data security standards? Because the claims that it makes are not what it delivers; take an example - early on in the class, the claim was made that the "goal of PCI was to make non-members equal in security posture to members". In other words, Visa members (issuing and acquiring banks) - which don't have to be certified under PCI - already have rigorous security controls. The goal is to make processors, gateways, merchants, etc. equal in posture to members. Sounds like a good goal to me. However, take a look at some of the requirements:

6.3.4 Production data (real credit card numbers) are not used for testing or development
6.5 Review custom application code to identify coding
vulnerabilities.

So, members don't use production data in test? They always review source code in custom applications? Guess again; ask anybody who works in FS and they'll tell you that it's the rare institution that does either of these things. Here's the issue - PCI holds non-members accountable to the standard that banks can't meet for themselves. Holding merchants and processors to a higher standard than banks (the reality of PCI) seems to me to be misplaced energy.

SYMC Mixed Messages

Has anybody else noticed that the Symantec ThreatCon on the Enterprise page is green and the ThreatCon on the main site is yellow? Looks like someone over there forgot to update the link...

New Whitepaper about Malware Evolution

Dancho Danchev (you may or may not know him from his blog) has put together a new whitepaper about the evolution of malware.

There is, by no means, a shortage of opinion on how malware will evolve - it is a topic of considerable interest in the security community and there are tons of predictions about how malware authors will (or will not) continue to incorporate new distribution vectors and new types of payloads into the software that they write. Most of the time, these predictions (particularly the ones from the AV community) are either biased or patently inaccurate. Given that, I found this paper to be a interesting viewpoint and free of the bias that typically peppers this type of report. Although some of the early supporting research is interesting too, I recommend skipping to the end for the time-challenged reader: particularly the last 3-4 pages where he lays out the trends that he feels are significant going forward.

Although I don't agree with everything in the paper (e.g. malware on mobile devices), he lays out some really interesting data on localization/regionality, interoperability, and the economics of malware authorship. All in all, the last 3 pages are well worth the security researcher's time.

Government Roundup

It's been quite a week for government information security. For the fellow connoisseurs of human folly, here's the recap.

First and foremost, the NSA's website was down for reasons unspecified. Since officials at the NSA would not comment on whether or not it was the work of attackers, we're left to assume that it probably was.

Next, the GSA has shut down a web page used by contractors due to application security issues - basically, there wasn't any authentication on the site; sure, you had to type a username and password in, but the website had two states: authenticated and not-authenticated. By manipulating the URL parameters, one could call up documents belonging to other companies or submit document on their behalf. Ouch.

The IG (Inspector General) continues to get it done; he's continued the tradition of past reports and said that the DoD's security posture continues to be below par. From the report:

“Specifically, 120 of 148 IT systems (81 percent) reported in the fiscal year 2006 President’s Budget Capital Investment Reports did not match to reports on the same systems in the IT Registry, and 87 of 148 IT Registry reports (59 percent) were not internally consistent between the system mission criticality and the mission assurance category data elements...”

Burning brightly against the backdrop of incompetence are the certification of the DoD defence crime lab and the publication of the 2006 IG audit plan - the IG, getting it done once again...

My apologies for the long quiet period

Well folks, I think I've finally gotten back on track from the holidays, and my apologies for the long delay the past few weeks with blog entries. This marks the end of the long period of cloister.

Phone Malware (again)

I'm getting sick of the whole "malware on the phone" propaganda; I've been saying that phone-borne malware is not "brewing like bird flu" for years now. However, every few weeks, the press picks up and runs with some story about how huge a problem it is. The stories typically have quotes from certain AV vendors spinning a tale of woe about how phones are a ticking time-bomb of infestation - a veritable petri dish of scum. I would like to (once again) attempt to put this into proper perspective.

For example, this week BusinessWeek is running a story called If Not Now, Soon about how Mobile Viruses are going to be a huge issue in 2006 - or if not in 2006, then at least by 2009. The thing about making predictions four years out is that nobody remembers (or cares by that point) whether or not they come true.

I'm not saying that the article is in the wrong - I am saying, however, to read between the lines of who says what. First and foremost, who is the loudest voice in the phone-borne malware camp? In this article, the sources most quoted are Trend Micro and Symantec; in other articles, you'll see names like F-Secure, McAfee, Sophos, etc. These are all vendors who have some interest in selling phone-borne malware products; these vendors are not dishonest - they just believe that malware is the most important thing (hence why they are in the AV business.) From their point of view, of course phones will run malware - why wouldn't they?

Look, it's going to take a lot more than smarter phones to make malware a problem on these platforms. There are a number of reasons that phone-borne malware isn't huge over and above smarter phones: phone models and brands are diverse, there's not a ubiquitous population of smart-phones, inter-phone application sharing is rare, etc. In other words, we don't just need a change in how many smart-phones are out there to see the malware rate increase, we need a fundamental change in the way that people use their phones. Take, for example, mass-mailers; on the PC, these spread because we are used to opening executable content from friends. When was the last time you exchanged executable content with a friend via your phone? Never? Once? Until how we use the phone changes, mass-mailers are unlikely to work.

Look, my point isn't that phone-borne malware is a non-issue - it's important to keep your head out of the sand. All I'm saying is to use discretion when reading articles like this. Right now, the generally-recognized "malware experts" are the AV folks - and the AV folks are predisposed to see stuff like this as a huge issue (when maybe it isn't all that big after all) because of the business they're in.

SANS Says Microsoft is "Negligent and Irresponsible"

Hard language from Alan Paller today:

Microsoft's delay is inexcusable," said Alan Paller, director of research at computer security group SANS Institute. "There's no excuse other than incompetence and negligence."

This language was so harsh that I figured I had to put it up. As a quick aside though, why is Microsoft "negligent and incompetent" for not fixing this during the three days it's been public whereas Oracle has left critical security bugs unpatched for years and nobody cares?

Anyway, as I said yesterday, there's a reason that patches go through a QA process and that most enterprises don't replace pieces of the operating system in vendor-unsupported ways. It's a question of reliability vs. security - SANS assumes, since security's their purview, that security is the number 1 priority. If that's true - that security is the most important thing, then Microsoft's failure to release a patch is, as they said, "incompetent and negligent". However, if stability and reproducability are the top priorities (with security perhaps a close second), then releasing a patch without appropriate QA or ability to support it is the negligent action. I'm with Microsoft on this one - security should support stability, not vice versa.

Security is not an end. The goal of security is to protect assets, reduce downtime, and save money. Things that increase downtime and cost money (through extra administrative overhead) while providing some small benefit in the area of asset protection are more "insecure" in my opinion than being vulnerable to the "sploit du jour". Trust me, installing an unsupported operating system component against the advice of the vendor is asking for trouble.

The "install the patch now" folks are right - there could be hell to pay from staying vulnerable. On the other hand, if you're the typical enterprise you'll have tons of vulnerabilities from yesteryear that still aren't fixed in the nooks and crannies of your systems; is it worth "leaping into the fire" by pushing out unsupported software globally in order to guard against what *could* happen?

Panic like it's 1938

Back in the day, we all got whipped into a frenzy when Orson Welles read the novel "The War of the Worlds" from the CBS 20th floor studios on Madison Avenue. People were so frightened - they were so convinced that aliens were really on the march - that they took extreme actions to keep themselves from being victims of the upcoming martian attack: people left their homes, hallucinated poison gas or lights from death rays, broke out the ordinance, etc. In short, people took measures way out of proportion to what was really going on - had they but relaxed and waited for the real threat to materialize, they would have saved themselves a lot of heartache.

This situation, in my opinion, is very much akin to what's going on the past few days in and around the Windows image library vulnerability. Don't get me wrong, I said it was an issue - even a significant one - and I still believe that. However, in looking through the advice today, I'm a bit surprised about just how much panic there is out there; I'm even more surprised at the number of people who are recommending that we install the "unofficial patch." SANS is suggesting one of two unofficial patches, F-Secure is recommending that people install it, the Washington Post says not to wait and to "do it now", etc., etc. Practically, the only outlet not recommending the unofficial patch is Microsoft, although they do recommend unregistering the impacted dll's in the official advisory.

Here's my advice: keep in mind that the unofficial patch has its own downside. I'm sure that the patch works, I'm sure it's probably bug-free, and I'm sure it fixes the problem; however, neither Microsoft nor any other application vendor is going to support it. You are going to support it. The onus is going to be on you to make sure that you "roll back" the unofficial patch to apply the real fix, the onus is on you to make sure that your applications work, the onus is on you to make sure that the unofficial patch works the way it's supposed to. Sounds like work to me... Not to mention that in the enterprise, system admins will need to support the patch, somebody will have to test all the apps, and then test them *again* when the real patch is released.

On the other hand, what does the unofficial patch buy you? There's no malware of any significance that uses this bug yet (F-Secure has a few examples of email-borne malware but nothing with a distribution of more than a few individuals), and (as Pete said the other day) current attacks do require user intervention. Right now, it's just hype; the danger is potential rather than real... Look, I'm not saying that you shouldn't be safe, I'm just saying wait until there's a problem before applying drastic measures. Rather than being like the folks who loaded up their cars with guns and headed for the woods when "War of the Worlds" started, be like the people who listened alertly until the end of the program when Orson told us that it was just fiction.