After discussion with Andrey Cherezov, the cause and solution of the eServ memory "leak" has been identified. Delayed de-allocation associated with thread creation and destruction caused the issue. eServ 2.9x was vulnerable to my attacks because during the delay (up to a few minutes), it continued spawning threads, resulting in a denial of service. eServ 3.0 uses a new acTCP kernel to improve service. Specifically, it does not create new threads beyond its maximum connection queue. The delay condition still exists, but cannot be exploited to cause major memory loss. I recommend that eServ 2.9x users contact the vendor about upgrading as appropriate. eServ has had one other vulnerability, a buffer overrun in its virtual host support. Stating that eServ has a "horrible security record" was perhaps a horrible overstatement on my part. :-) There have been other vulnerabilities in products un-related to eServ, which were developed on the same kernel. Specifically, acFTP's authentication logging bug, and the acFreeProxy XSS, which I have been informed was the result of a configuration error. I was also informed during discussions with the developer that the reason my e-mail was not replied to immediately was because of Russia's day of victory celebrations, and not due to negligence. -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .
This archive was generated by hypermail 2b30 : Tue May 13 2003 - 11:25:17 PDT