full-disclosure - Re: newest category of security bugs considered elite ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <4BDCE286.26612.95EB7A12@nick.virus-l.demon.co.uk>
Date: Sun, 02 May 2010 14:25:10 +1200
From: Nick FitzGerald <nick@...us-l.demon.co.uk>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: newest category of security bugs considered
 elite ?

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):

   http://www.nsfocus.com/en/advisories/0005.html

<<snip>>
> 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-
072 bug).

> 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 
length...

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...

Regards,

Nick FitzGerald

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/