Arch Linux

Has this already been applied upstream? I can't find anything in the Git logs...

They didn't applied it upstream ... and I can't get any response about that subject on their IRC chan ...

Anyway, if you want to ensure that these patch doesn't introduce other problems or bugs, please know that Debian uses these patch [0] for Squeeze and Wheezy since a few month, and at least openSuse does too ;)

[0] http://patch-tracker.debian.org/package/tinyproxy/1.8.2-1squeeze3

The patch is not secure. It's still vulnerable to key-independent collisions. It's really sad to see this kind of security by obscurity adopted by Debian/Fedora instead of using a hash secure against these attacks (like SipHash) or another data structure.

small update on this issue:

Patches pushed to master and 1.8.
With some additions:
- better hash algorithm (by daniel bernstein), patch by Peter Fröhlich.
- raised number of hash buckets to 256.

This will be in 1.8.4 which will be released very soon!

The new hash function is still vulnerable to key independent collisions, so it's not really solved.

Oh and `srand(time(NULL))` / `rand()` certainly aren't usable in this context for security.

i agree kind of stupid, seeding with srand(time(NULL)); is ridiculous. also its still definitively not "secure", but i would say it will still resolve this CVE as the DoS is (kind of) mitigated by the limited about of headers (which result in less entries in the hashmap), an extended bucketsize for hash entropy (which reduces collision count) and a different hash function.
To sum it up: i agree its not "really solved" but in my opinion from reading the 4 patch files its kind of "mitigated good enough to maybe consider CVE-2012-3505 mitigated, do you agree?)

A broken exploit mitigation is considered a vulnerability, so there's going to be another CVE or two for this even if it's somewhat mitigated by the header limit.

@thestinger: don't get me wrong, I'm totally on your side... but i don't think it makes sense to keep this ticket (stating CVE-2012-3505 explicit) open after 1.8.4 got released to our repos (in the near future).

The header limit is arguably a fix, but the hash table is still no better than a linked list from a DoS point of view.

@thestinger: Please don't feel offended. I never said so and as i already pointed out the last comment i fully agree that it *should* be done in a sane way, some "cryptographic secure prng" like SipHash and other data structures not affected by this kind of issue... neither did i ever say that you are wrong at all...
but to be honest the limit to 10000 entries and the bit of (re)seeding in the (per child) loop is however (in my opinion) "good enough" that this issue can't be exploited as trivial and effective as before.
Even if the way to seed is "stupid" and definitively not "cryptographic secure" it still helps a lot to work around the described issue especially because its not application unique but done in the (per child) loop (making guessing the PRNG seed (and/or reconstructing the PRNG-state) a lot more difficulty and *may* require some kind of side-channel attack to be able to do so).

MITRE has no problems marking CVEs as incomplete and re-issue new identifiers (with adjusted scores) if needed but in my personal honest opinion this (lets call it a work-around) is currently "good enough" to transform a very trivial and effective to exploit DoS vulnerability into something that is much much harder to exploit.

From our own point of view i really see no "gain" or "advantage" in keeping this open (after 1.8.4), but maybe it sounds like a nice topic to discuss at oss-security mailinglist? :-)
Sincerely, anthraxx

Yeah, it can be closed here. I'm just pointing out that upstream is silly.