[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] CVE request for fetchmail STARTTLS hang (Denial
From:       Matthias Andree <matthias.andree () gmx ! de>
Date:       2011-05-31 20:41:41
Message-ID: 4DE55285.5010405 () gmx ! de
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]