[24499] in bugtraq
Re: mod_ssl Buffer Overflow Condition (Update Available)
daemon@ATHENA.MIT.EDU (Ben Laurie)
Fri Mar 1 15:12:17 2002
Message-ID: <3C7F4FE1.B5C16B1A@algroup.co.uk>
Date: Fri, 01 Mar 2002 09:54:41 +0000
From: Ben Laurie <ben@algroup.co.uk>
MIME-Version: 1.0
To: Ed Moyle <emoyle@scsnet.csc.com>
Cc: bugtraq@securityfocus.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ed Moyle wrote:
> MITIGATING FACTORS
>
> This vulnerability is unlikely to be exploitable in a production
> environment. Since the buffer in question is the contents of the
> SSL session, exploitability of this scenario would be tied to
> increasing the size of the session. The most obvious way of doing
> this would be through the use of client certificates. Therefore,
> generating a really big client cert would overflow the buffer, and
> could potentially be used to run arbitrary code. HOWEVER, these
> routines are only called AFTER SUCCESSFUL VERIFICATION of the client
> cert, which would mean that a CA *TRUSTED BY THE WEB SERVER* would have
> to issue the certificate in question. In addition, both client cert
> auth and the dbm or shared memory session caching functionality would
> need to be enabled.
This analysis is flawed: although the certificate would have to be
issued by a trusted CA, some parts of the certificate are under control
of the owner of the certificate, who could therefore get a certificate
of arbitrary size by, for example, requesting a very large DN. I can see
no reason that a CA would vet CSRs for size - why should they? So, the
fact that a trusted CA produced the certificate has no bearing on its
size.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
