Bugtraq mailing list archives
[rootshell] Security Bulletin #24 (fwd)
From: kiwi () OAV NET (Xavier Beaudouin)
Date: Tue, 22 Sep 1998 14:10:53 +0200
---------- Forwarded message ---------- Date: 22 Sep 1998 02:27:04 -0000 From: announce-outgoing () rootshell com Cc: recipient list not shown: ; Subject: [rootshell] Security Bulletin #24 www.rootshell.com Security Bulletin #24 September 21st, 1998 [ http://www.rootshell.com/ ] ---------------------------------------------------------------------- To unsubscribe from this mailing list send e-mail to majordomo () rootshell com with "unsubscribe announce" in the BODY of the message. Send submissions to info () rootshell com. Messages sent will not be sent to other members on this list unless it is featured in a security bulletin. An archive of this list is available at : http://www.rootshell.com/mailinglist-archive ---------------------------------------------------------------------- 01. DoS attack in the latest version of SLMail (3.1) ----------------------------------------------------
From mnemonix () globalnet co uk Mon Sep 21 18:56:12 1998
Date: Tue, 22 Sep 1998 02:11:32 +0100 From: Mnemonix <mnemonix () globalnet co uk> To: submission () rootshell com Subject: DoS attack in the latest version of SLMail (3.1) Dear All, The latest version of SLMail is susceptible to a denial of service attack whereby if the encrypted password of the user account is the default 24 characters in length plus another 177 charcters (making 201 characters all in all) and the user, whose account it is, attempts to authenticate to the POP3 service (slmail.exe) the process dies needing an administrator to restart the service. When the slmail.exe process is studied in NTRegMon you can see what's happening: The USER command causes a spill when slmail.exe checks the registry for the user account's existence but it is only after it checks a second time, after the PASS command, that the process actually dies. The previous issue I had with earlier version whereby the Everyone group has "set value" permissions to the relevant registry keys still applies. It makes you wonder if any other NT services may be susceptible to a similar problem. Cheers, Mnemonix http://www.infowar.co.uk/mnemonix http://www.diligence.co.uk ---------------------------------------------------------------------- To unsubscribe from this mailing list send e-mail to majordomo () rootshell com with "unsubscribe announce" in the BODY of the message. Send submissions to info () rootshell com. Messages sent will not be sent to other members on this list unless it is featured in a security bulletin. An archive of this list is available at : http://www.rootshell.com/mailinglist-archive ----------------------------------------------------------------------
Current thread:
- Re: Buffer overflows in Minicom 1.80.1 M.C.Mar (Aug 31)
- <Possible follow-ups>
- Re: Buffer overflows in Minicom 1.80.1 M.C.Mar (Sep 02)
- Re: Buffer overflows in Minicom 1.80.1 Patrick J. Volkerding (Sep 02)
- Re: Buffer overflows in Minicom 1.80.1 Patrick J. Volkerding (Sep 02)
- Re: Buffer overflows in Minicom 1.80.1 Patrick J. Volkerding (Sep 02)
