Re: CVE request for fetchmail STARTTLS hang (Denial of Service)

[Matthias Andree <matthias.andree () gmx de>]

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