'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

[Jerry Leichter]

On Oct 1, 2010, at 11:34 PM, Richard Outerbridge wrote:
>> Any implementation that returns distinguishable error conditions  
>> for invalid padding is vulnerable...
> Oh come on.  This is really just a sophisticated variant of the old  
> "never say which was wrong" - login ID or password - attack.  In  
> this case it's padding or MACing.  If either fails the result should  
> be the same: something went wrong, sorry for you.  The POET Oracle  
> depends upon the server taking a shortcut and signaling which went  
> wrong first.
I wouldn't call that a shortcut - one has to actually define two  
failure returns and choose which one to send.  More code, more  
complexity.  But ... there's a reason for doing this, in virtually all  
situations:  Manageability, Without some detail as to exactly what  
went wrong, it's very hard to know what to correct or even where to  
look.

Cryptographic protocols are outliers here, because here you really  
can't afford to make the system "manageable" if the cost is that it  
can then serve as an oracle.  This is one reason it's so hard for most  
developers to produce correct crypto implementations:  So much of what  
is good practice almost everywhere else ends up being hazardous when  
it comes to cryptography.

It's not that there are *no* other situations where better error  
messages are a potential liability.  The classic example is error  
messages that leak information about directory configurations or  
database tables, thus enabling other attacks.  The difference is that  
such information, in most cases, is only problematic if the actual  
system *has some other vulnerability*.  We may not be at all good at  
producing systems without such vulnerabilities, but at least we know  
in general principle how to do so.  (If there are no SQL injection  
attacks, knowing what tables exist probably isn't useful to an  
attacker.)  One might argue that a cryptosystem that is vulnerable to  
a "what failed" attack is also buggy - but we really have no general  
idea how to fix them.  So we have to avoid them by accepting hard-to- 
manage protocols.

By the way, the "don't acknowledge whether it was the login ID or the  
password that was wrong" example is one of those things "everyone  
knows" - along with "change your password frequently" - that have long  
passed their "use by" date.  Just what attack on a modern system does  
revealing that a guessed login ID is correct actually allow?  It can  
only be used in on-line attacks, and it's been years since any decent  
system didn't protect against high rates of failures in on-line  
authentication.  Besides, valid - or highly-probably-valid - login  
ID's are typically cheaply available for most systems anyway.

I'm really tired of using up my on-line password tries, only to  
discover that I accidentally erased the last character on the login  
name, or added a trailing \ when I went for the RETURN key!  Systems  
are *so* nice to keep re-prompting with the bogus username.

Really, most systems these days reveal valid usernames quite easily.   
Both Windows boxes and Macs typically give you a pull-down list of  
accounts to log into.  Web logins have ways to recover passwords for  
lost accounts that usually reveal if you get the account name wrong -  
and then give you a way to recover the account name.  Can you think of  
an example in, say, the last 20 years of an attack that would not have  
been possible if the system had made it difficult to determine valid  
usernames?
                                                         -- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com