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
