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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ