ESAPI and the Padding Oracle Attack

From Kevin Wall.

I originally noticed that the ESAPI symmetric encryption provided no authenticity way back in August 2009 and argued for a very long time with Jim Manico that what was present in ESAPI 1.4 and 2.0rc3 (or maybe it was rc2?) needed to be burned to the ground and replaced, and he agreed. All I remembered was some type of an attack against cipher padding that caused by one tweaking IVs in a certain way and then looking for errors. I remembered that IPSec at one time had been vulnerable to this same vulnerability, but I just couldn't remember the name of the attack or who or when he wrote about it (S. Vaudenay in 2002) so unfortunately couldn't easily search for it. Fortunately, I knew that I had to use a MAC or an authenticated cipher mode to fix it.

After a few months of arguing on the ESAPI developer list that this was something that needed to be addressed, I finally was able to convince people convince the ESAPI community and I volunteered to make the code changes. Had I been able to find Vaudenay's paper and site it, I probably would have been able to convince folks that changing ESAPI's encryption was necessary...especially that Jim Manico guy. ;-) [Aside: Ironically it was this weakness in ESAPI's crypto that caused me to get involved with ESAPI development. I really liked what it presented and wanted to introduce it at Qwest once it was GA, but I was concerned that Qwest developers that would use the broken ESAPI crypto rather then the encryption library we had developed in-house.]

Anyway, subsequent to the the Rizzo / Duong paper appearing, there was probably at least 4-6 sman months of re-design and recoding effort that had taken place.

In fact, at one point I had things just right (apart from using a timing side-channel as padding oracle), but then *in a moment of clear stupidity*, I went in and changed a few of the exception messages intended for end users "to clarify things a bit". My (faulty) reasoning was that if a user got an encryption error and called a help desk, s/he could only report what s/he could see as he error message. But since the error message could be caused by two very different things I decided to make them slightly different so help desk personnel could distinguish between the two cases and act accordingly. (I know, the *logged* error messages were different, but I figured very few tier 1 help desk people ever have access to log files.)

Anyway, this was a *BIG* mistake and reintroduced the padding oracle attack, although not in the same way that earlier versions of ESAPI had, as they did not support authenticity at all.

So the bottom line is the *reason* that "we fixed padding oracle in ESAPI *very* quickly after the paper came out" is all I really had to do to fix it was to go back and change it so that the user intended exception messages were identical in each case. (I also put in some protection against using timing as a side-channel attack as the padding oracle, but that was pretty straightforward.)

Had the NSA completed their crypto review and mentioned this (they didn't and it's not entirely clear that they ever would have!), then this would have been have been fixed without drawing so much attention. But in a way, I consider it serendipitous that it came out in the Duong & Rizzo paper that ESAPI was somewhat vulnerable. By comparison, ESAPI faired well against the others described their paper. I think had ESAPI not been vulnerable, it likely would not have been mentioned at all in their paper and the conclusion of Rizzo's and Duong's readers would have been that they had not evaluated ESAPI's symmetric encryption at all.  As it was, it allowed us a platform to be transparent to the OWASP community, tell them how we were addressing the problem, and (IMO) most importantly brought home the seriousness of what I had been saying all along about ESAPI 1.4 encryption being badly broken which motivated getting people off of it.

The reason we were so quick to get it fixed is because we had it 95% right in the first place. (Unfortunately, 95% right is 5% wrong and with vulnerabilities, that's all it takes.)

Thanks for your time,
-kevin