[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DE55285.5010405@gmx.de>
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
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
