Dat er geen security update beschikbaar is klopt niet.
Vanuit hun bug tracker op git is het volgende te vinden:


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 log and 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:

the value of either "connection" or "proxy-connection" is retrieved from the key-value store
it is split up in pieces using a number of potential delimiters (the RFC isn't quite clear about how the pieces are separated)
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 issue is fixed in master with commit 12a8484
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.

the code is only triggered after access list checks and authentication have succeeded.
so if you use basic auth with a reasonably secure password or allow only specific trusted hosts you won't have to worry. same if your proxy is only available on a trusted private network, like inside a corporate environment (you gotta trust your employees anyway).
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.

Tuurlijk, iemand moet zijn best doen om een email adres te vinden. Nou ik had het maar naar een adres gestuurd, dat wat het makkelijkst te vinden is. Al die organisaties die zich verbergen achter noreply adressen. TALOS heeft ook niet eens zelf een email address op de home page.