[nycbug-talk] [Fwd: Kaminsky redux - libspf2 dns parsing bug]

[Max Gribov]

well, I use it, and hotmail/ms seem to like it - they do have their own 
implementation called sender-id
http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

spf requires everyone to use it to be effective, and from running a mail 
server for a while, they only thing that really made a difference in 
spam for me was greylisting - quickly looking through logs, i dont see 
any rejections based on spf

i still use it because it *may* prevent that 1% (arbitrary number alert) 
of spam, and gives me slightly better "reputation" with 
hotmail/live.com/msn



Robin Polak wrote:

 > This may explain why my milter-greylist /w libspf plugin to sendmail
> occasionally decides to kill without any log entries or errors on
> console.  In all reality is it worth at all checking SPF records at
> this point or is it more of a liability.
>
> On Wed, Oct 22, 2008 at 00:19, Max Gribov <max at neuropunks.org> wrote:
>   
>> http://www.doxpara.com/?page_id=1256
>>
>>
>> -------- Original Message --------
>> Subject:        Kaminsky redux - libspf2 dns parsing bug
>> Date:   Wed, 22 Oct 2008 06:55:10 +0530
>> From:   Suresh Ramasubramanian <ops.lists at gmail.com>
>> To:     NANOG list <nanog at nanog.org>
>>
>>
>>
>> For the "mailops is not operational" folks.. it involves parsing dns
>> txt records, so .. well, please grit your teeth and read on, this gets
>> interesting
>>
>> Well, we discarded spf back in 2005 so we arent in any particular
>> danger, but for those few of y'all still deploying and checking spf ..
>> please upgrade asap.
>>
>> srs
>>
>> http://www.doxpara.com/?p=1263
>>
>> I really need to learn to leave DNS alone :)
>>
>> DNS TXT Record Parsing Bug in LibSPF2
>> A relatively common bug parsing TXT records delivered over DNS, dating
>> at least back to 2002 in Sendmail 8.2.0 and almost certainly much
>> earlier, has been found in LibSPF2, a library frequently used to
>> retrieve SPF (Sender Policy Framework) records and apply policy
>> according to those records.  This implementation flaw allows for
>> relatively flexible memory corruption, and should thus be treated as a
>> path to anonymous remote code execution.  Of particular note is that
>> the remote code execution would occur on servers specifically designed
>> to receive E-Mail from the Internet, and that these systems may in
>> fact be high volume mail exchangers.  This creates privacy
>> implications.  It is also the case that a corrupted email server is a
>> useful "jumping off" point for attackers to corrupt desktop machines,
>> since attachments can be corrupted with malware while the containing
>> message stays intact.  So there are internal security implications as
>> well, above and beyond corruption of the mail server on the DMZ.
>>
>> Apparently LibSPF2 is actually used to secure quite a bit of mail
>> traffic – there's a lot of SPAM out there.  Fix is out, see
>> http://www.libspf2.org/index.html or your friendly neighborhood
>> distro.  Thanks to Shevek, CERT (VU#183657), Ken Simpson of
>> MailChannels, Andre Engel, Scott Kitterman, and Hannah Schroeter for
>> their help with this.
>>
>>
>> _______________________________________________
>> talk mailing list
>> talk at lists.nycbug.org
>> http://lists.nycbug.org/mailman/listinfo/talk
>>
>>     
>
>
>
>