mailing list archives
Re: newest category of security bugs considered elite ?
From: Nick FitzGerald <nick () virus-l demon co uk>
Date: Sun, 02 May 2010 14:25:10 +1200
Dan Kaminsky to me to him:
I really like the hash length declaration bugs, where the client can
tell the server how many bytes of a hash need to be validated. (Yep,
you just say "one byte is plenty")
SNMPv3 and XML-DSIG both fell to this, catastrophically.
I thought Georgi asked for the newest class of elite vulns?
Does (at least) ten years old count as new?
Ooh, SMB's old Hollywood OS bug -- one character at a time attacks.
Well, you could use it for char-at-a-time extraction of the actual
password, if that was what you wanted (and utilities to do just that
were written based on the original PoC code for the vuln -- see URL
below for that POC code), BUT you could simply say (as the client)
"here is the one char password" and, so long as it matched the first
char of the actual server-side view of the correct password, you were
given access to the resource, reducing the difficulty of gaining access
to something like a 36 char (maybe plus a few punctuation chars?) space
and thus 18 (or a few more) attempts on average (or were these
passwords case-senstive? Doesn't seem likely for non-NT Windows...).
I don't recall now if you could just say "here is the zero char
password" -- I have an idea I saw that claim made but was not able to
reproduce it in my tests...
The advisory from the original (well, credited) discoverers tends to
support this explanation (moved from its original URL, which is widely
broken-linked around the web):
This bug class is different, and as far as I know unseen from the 80's
and 90's. In this one, you tell the remote system, 'sure, I can match
your stored hash -- but it's only one byte long.'. So you try an
average of 128 passwords, and off you go.
Sounds just like the above if your only concern was breaking access to
the specific resource, rather than recovering the actual password (the
massive speeding up of which was a handy side-effect of the actual MS00-
It's basically a problem where the client is trusted to provide
excessive metadata about server state. ...
As I said, that sounds just like the real problem at the core of MS00-
072. The client tells the server how long of a password it is going to
supply and instead of the server failing the supplied password because
it's too short (relative to the configured one) it accepts it so long
as it matches the configured password up to the client-specified
You're talking about hashes and MS00-072 is about cleartext passwords,
but I don't see that that is relevant to the class of vuln here.
... If you've got other examples in
this family, it'd be cool to hear them.
This is the only one that immediately comes to mind...
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/