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>] [day] [month] [year] [list]
Date: 1 Oct 2007 12:07:00 -0000
Subject: Re: OpenSSL SSL_get_shared_ciphers() off-by-one buffer overflow

> OpenSSL 0.9.7l and 0.9.8d fixed a buffer overflow found in
> the SSL_get_shared_ciphers() function reported by Tavis
> Ormandy and Will Drewry of the Google Security Team.

> Although this fix prevented the unlimited overflow of the
> buffer, it still allowed an off-by-one buffer overflow to
> happen, which could potentially still result in remote code
> execution.

Both these bugs of course exist, and have been fixed. However, it is unclear if they could actually be exploited in the real world.

In fact, in order to exploit that function you need:
1) an application which explicitly calls it (i.e. it's not used, as far
as I can tell, in the regular handshake)
2) you should pass the ciphers with the malformed names to BOTH client and server (always as far as I can tell), because cipher setting handshake occurs and it doesn't call the function, so if I'm correct on this, this means:
3) you should have an SSL-enabled application where you can run and/or supply with a configuration file both the client and the server, and which is suid or ran with higher privileges than yours for this to be exploitable.

Unless I spectacularly missed something which enables to jump through point 2... which is quite possible, this looks like a very unlikely exploitation vector.

So - where am I wrong ? :)


Powered by blists - more mailing lists