Szymon Juraszczyk wrote: > > On Mon, 2001-10-01 at 04:02:52, Szymon Juraszczyk wrote: > > > On Sun, 2001-09-30 at 23:30:38, Szymon Juraszczyk wrote: > > > > > On Sun, 2001-09-30 at 17:04:34, Tarjei Huse wrote: > > > > > > > > Are you using PAM/LDAP? If so check the recent archives (about 4 weeks ago) > > > > > for a very long thread regarding a memory allocation problem between > > > > > OpenLDAP and Cyrus. I'm not sure what the resolution was in the end... Using > > > > > saslauthd from the new SASL version would almost certainly fix it though. > > > > Or just using the sasl-ldap patch from cyrus-utils.sf.net. > > > > > > > > Tarjei > > > > > > I use so called 'IP-Plus' patch, which adds a few new authentication > > > methods to SASL (LDAP, PostgreSQL, BerkleyDB). I'll try the patch you > > > mentioned then and post the results of my struggle to the list. > > > > So, as I promised, I'm posting the results of my struggle. The lmtpd > > signal 11 problem seems to be unrelated to LDAP at all. I figured out that > > it crashes, when the header of the e-mail message is bigger than some > > 2,5 KB (!?!?!). It's ridiculous, don't you think !? Is this a normal behaviour > > or is due to some kind of copile-time mishap? I'm investigating the problem > > anyway. > > Sorry guys for replying to my own message twice, but I've got more > exciting news and updated information about the bug. The problem is not big > header in general, but big 'To:' field (and possibly others). Yes, it > happens that e-mail messages have To: field composed of 50 or more lines > (I've got loads of monster-messages like this stuffing my mail queue). There > must be a buffer overrun somewere there, possibly in the code generating > notify (I use notify through a unix socket). Who knows, that might even > be a remotely exploitable hole if that's a classig buffer overrun. > > I'm sending Cc: of this letter to [EMAIL PROTECTED]
If you are using fetchmail look here: Thomas Biege wrote: > > Fetchmail is a tool for retrieving and forwarding mail. Two vulnerabilities > in the code of fetchmail were found in the last weeks. > 1.) By sending a header with a large "To:" line a buffer overflow will > be triggered in the header parsing code. > 2.) By impersonating a pop3 or imap server by using DNS spoofing > or getting control over the pop3/imap server an attacker could > trigger a buffer overflow in the pop3 and imap code of fetchmail. > All the attacker has to do is to fake a LIST response message and > providing two integers. One will used as index for a stack array > and the other one is the value written to this index. > Both vulnerabilities could be used to get remote access to the system with > the privilege of the user running fetchmail. > it' s from 08/17/01 cu Gerald
