After discussion with Andrey Cherezov, the cause and solution of the eServ=

memory "leak" has been identified=2E  Delayed de-allocation associated wit=
h
thread creation and destruction caused the issue=2E  eServ 2=2E9x was
vulnerable to my attacks because during the delay (up to a few minutes), i=
t
continued spawning threads, resulting in a denial of service=2E  eServ 3=2E=
0
uses a new acTCP kernel to improve service=2E  Specifically, it does not
create new threads beyond its maximum connection queue=2E  The delay
condition still exists, but cannot be exploited to cause major memory loss=
=2E
I recommend that eServ 2=2E9x users contact the vendor about upgrading as
appropriate=2E =20

eServ has had one other vulnerability, a buffer overrun in its virtual hos=
t
support=2E  Stating that eServ has a "horrible security record" was perhap=
s a
horrible overstatement on my part=2E :-)

There have been other vulnerabilities in products un-related to eServ,
which were developed on the same kernel=2E  Specifically, acFTP's
authentication logging bug, and the acFreeProxy XSS, which I have been
informed was the result of a configuration error=2E

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=2E

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web=2Ecom/ =2E