Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 31 May 2011 22:41:41 +0200
From: Matthias Andree <matthias.andree@....de>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request for fetchmail STARTTLS hang (Denial
 of Service)

Am 31.05.2011 22:01, schrieb Josh Bressers:
> 
> 
> ----- Original Message -----
>> Could I get a CVE name for the issue in
>> <http://gitorious.org/fetchmail/fetchmail/blobs/legacy_63/fetchmail-SA-2011-01.txt>?
>>
> 
> Please use CVE-2011-1947.

Thanks.

> I can't help but wonder what else could be vulnerable to a similar flaw.
> Has anyone looked?

I seriously considered not asking for a CVE in the first place because
it's rather close to a resource-hogging-through-slowdowns attack vector,
if you send at a very slow pace just avoiding the timeout by a notch,
you hog your peer's resources for extended amounts of time -- and I
can't think of good heuristics to tell abuse from legit use by those on
slow links apart, and it's pointless listing CVEs for the unfixable
situations.


Anecdotal story from the fix: I've been particularly disappointed that
Solaris 10 doesn't support setsockopt(n, SOL_SOCKET, SO_RCVTIMEO, &foo,
sizeof foo); (returns -1 with errno == EAFNOSUPPORT), which would have
been the thorough and easy way out.  I've had the code in place and
released as candidate, but umm, no, didn't work. I do set SO_KEEPALIVE
now, but that's not anywhere close of defending against malice.

Rewriting the whole socket stuff as non-blocking code with
poll()/select() which is supposed to be the canonical portable way was
too intrusive, hence, a no-go for a stable release update.

Best regards
Matthias Andree

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ