eServ Memory Leak Solution

["mattmurphy () kc rr com" <mattmurphy () kc rr com>]

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