Amichai Shulman: August 2008 Archives

My last post discussed responsible disclosure focusing on the Oracle 0-day exploit. When the exploit was published, Oracle was quick to release an advisory with an unusual (probably the first in a decade) recommendation for a workaround. Now, a few days later, Oracle is issuing (its first in a very long time) out-of-cycle patch to protect against this vulnerability. In its updated advisory Oracle is urging customers to immediately install the patch, rather than use the workaround.

My (eternal) question is WHY?

If I can apply (a convenient) workaround, outside of the server why should I mess with the server software? Especially when the said patch was evidently compiled in a rush? To help me prove my point Oracle just sent a letter to its customers, notifying them that some of the patch sets released in July were incorrectly compiled and do not solve all the problems that they were supposed to. Why is Oracle not providing enough information to its customers that would allow them to make an educated, conscious, decision as to whether to use the work around or immediately install the patch?

Actually, I already know Oracle's response to my question - "We do not divulge any technical details to avoid hackers from quickly exploiting it." Which in this particular case is completely ridiculous as exploit code has already been published.

Oracle is not alone in its "patch and don't ask questions" paradigm. Most major software vendors resort to this same behavior. One vendor that is trying to improve on its disclosure policy is Microsoft who recently announced its Microsoft Active Protections Program (MAPP).  This is the company's initiative of an early disclosure program shared with its affiliates in order for these partners to make the relevant preparations. We cannot evaluate yet the effectiveness of such a program but I do think that other large vendors should join in with a similar approach, allowing standalone security solutions to provide timely workarounds while enterprises plan their patching cycles in an orderly manner.

- Amichai

A couple of weeks ago, a hacker published a 0-day exploit for a critical buffer overflow vulnerability in one of Oracle's web server products (formerly a BEA product). As a security researcher, every so often I address the topic of full disclosure and responsible disclosure and how they co-relate.

The above mentioned buffer overflow exploit is one of those ugly examples of irresponsible full disclosure where an individual publishes to the public an exploit before the vendor has a chance to review the information and release an advisory suggesting work arounds or patches. Timing seems to me not coincidental, since the Oracle quarterly CPU was released only days before the exploit became public.

I object to any such kind of irresponsible behavior. And yet, as the security community knows only too well, such actions are inevitable. Which is why we need to stress that application security should not be based solely on patching and infrastructure hardening but also on dedicated security solutions. In particular, this recently exploited vulnerability is mitigated, by default by most web application firewalls. Therefore, organizations relying on this type of security technology find themselves protected long before any vendor patch is available.

I cannot discuss disclosure policies and behavior without mentioned the much hyped DNS vulnerability found by Dan Kaminsky. I find all these frenzies surrounding the bug (media, the security community, and practically the whole world...) quite strange. Kaminsky attempted to disclose the flaw in a responsible manner, and in fact he worked with the major IT providers in this regard. However, the fact that he proceeded to make claims in public about the existence of a flaw, effectively brought the early announcement of the vulnerability and ultimately its full disclosure by another researcher.

- Amichai

Proper disclosure: I had to choose between writing this blog entry and shaving my head.

We gave our ADC monthly webinar a couple of days ago and had a record attendance of over 350 people. Did we promise to disclose a 0-day vulnerability in everybody's favorite name resolution protocol? No! Did we claim to reveal a new and devastating attack technique? No! Did we describe how to break the AES cipher? No again.

We talked about SQL Injection!

When choosing the the topic for July's webinar we had an internal company debate and when our marketing team (Mark and Steve) suggested that we revisit SQL injection, the technical team (well, myself) gave them the crooked eye with the compelling argument "BORING!"

However, when starting to pile up the content, the outcome was surprising even for us. While we are talking about the most ancient trick in the book we are still talking about the #1 threat to web applications today. Moreover, we are seeing actual shifts and trends with respect to the use of SQL injection in the past 12-18 months:

- Automation either through desktop applications or through search engines is becoming prevalant

- SQL injection attacks are used much more for data integrity compromise rather than the traditional data confidentiality breach.

- SQL Injection attacks are combined with other attack techniques (such as Google Hacking, HTML Injection and traditional malware) to launch devastating attacks of unprecedented scale, effectiveness and effect.

- Direct SQL Injection vulnerabilities (those that lie within database stored procedures) are becoming prevalant.

While compiling the content a disturbing question came to my mind: How come we are still experiencing so much trouble from this kind of an old attack technique? Didn't we invest all that money in programmer education in order to make SQL injection extinct? Well, to me the answer is clear, and while I'm not going to elaborate on this topic today (see http://blog.imperva.com/2008/06/we-can-write-secure-code-not.html) I'll say that it reinforces my stand with respect to the false promise of secure coding.

So, all in all this has been a very educational episode for myself, and hopefully for those who attended the webinar. For those who didn't the recorded version can be found here.

and, Mark, you told me so!

- Amichai