rofl0r
commented
1 month ago after some more reflection about the bug, i came to the conclusion that it's almost certainly not exploitable for RCE, since the freed memory is never written to.
if you want to prove me wrong, feel free to attach or link to an RCE poc.
meanwhile, 1.11.2 was released for your pleasure. i postponed the polishing i planned to do before the release to get this out ASAP. though it's no big deal as master is always in a pretty good shape - we never merge half-baked features etc.
https://github.com/tinyproxy/tinyproxy/releases/tag/1.11.2
oh, and it seems we also made it to the start page of bleepingcomputer. https://www.bleepingcomputer.com/news/security/over-50-000-tinyproxy-servers-vulnerable-to-critical-rce-flaw/ having read it, i think the numbers mentioned refer to servers running the potentially vulnerable version (although for example distros that backported the fix would still be using "1.11.1" on paper), not discriminating whether they use ACL/authentication or not.
the bad news
a security researcher from TALOS intelligence found a use-after-free vulnerability in tinyproxy in december 2023, claiming to have contacted upstream and waited 6 months for publication. whatever he did to contact upstream, it wasn't effective and not what was described on either the tinyproxy homepage nor in README.md. he certainly didn't try hard to find a responsive contact, and probably pulled a random email address out of
git logand sent a mail there.the vulnerability was made public on may 01 2024, and it took a full 5 days until i was notified on IRC by a distro package maintainer. here's the official write-up: https://talosintelligence.com/vulnerability_reports/TALOS-2023-1889 don't spend too much time reading it, as it goes into a lot of quite useless details, while not focusing on the actual bug.
the gist is the following: in src/reqs.c,
remove_connection_headers(), there's code to remove the "connection" and "proxy-connection" headers from the list of headers received, and a particularly arcane piece of code that deals with RFC 7230, section 6.1's requirement that the connection header may include a list of headers to be removed from those that will be forwarded to the next HTTP server/proxy in the chain. that code was written in 2002, and when tinyproxy was refactored to use the new orderedmap implementation, it was basically left untouched in its essence.what happens is basically: 1) the value of either "connection" or "proxy-connection" is retrieved from the key-value store 2) it is split up in pieces using a number of potential delimiters (the RFC isn't quite clear about how the pieces are separated) 3) each piece is removed from the kv store
the bug is that if one of those pieces is either "connection" or proxy-connection" (case-insensitive) and the same as the key used earlier to retrieve the value, it will be deleted (freed) from the kv store, but the code continues accessing the value pointer it retrieved earlier.
this is a quite nasty bug, and could potentially lead to RCE - though i haven't seen a working exploit yet. what it certainly allows is a DOS attack on the server if tinyproxy is either using musl libc 1.2+ - whose hardened memory allocator automatically detects UAF, or built with an address sanitizer.
as a side note, the researcher from TALOS also basically copy/pasted the bug report for CVE-2022-40468 (which is almost a non-issue, so it was only fixed in git master 1.5 years ago, without creating a new release with that fix) and had a new CVE number for it assigned! the new CVE number is CVE-2023-40533. see also the corresponding issue on github #457 . great job, Dimitrios.
another "funny" circumstance is that i wasn't notified by github either, because the 2 CVEs aren't assigned to the tinyproxy repo, despite having tinyproxy in the title. maybe they could train an AI to do what the security team is supposed to do ?
the good news
the code may appear naive, but it allows to circumvent the allocation of more memory which could fail again. the straight-forward fix would be to strdup the value retrieved from the key/value store, and then work on that and free it later.
so it seems most tinyproxy users won't have to worry - because who runs an entirely open proxy on the open internet these days ?
that said, i'm currently looking into creating a tinyproxy 1.11.2 release, so a release without known bugs exists. until then, it's advisable to pull latest master from git or manually apply the mentioned commit as a patch on the 1.11.1 tarball.