Closed iblech closed 7 months ago
I'm currently bisecting. My computer is busy compiling glibc, hence definitive results will still take some time. But I'm down to 9 revisions to test (roughly 3 steps).
Pinging @Ma27 because all of those remaining 9 revisions pertain to glibc.
Update: Found the commit introducing this bug, it's e86152986c6e6c563ced037c91403318d5a8b447, which bumped glibc from 2.37-39 to 2.38-0.
Reading through the release announcement for 2.38-0, I found the following:
A new configure option, "--enable-fortify-source", can be used to build the GNU C Library with _FORTIFY_SOURCE. The level of fortification can either be provided, or is set to the highest value supported by the compiler. If not explicitly enabled, then fortify source is forcibly disabled so to keep original behavior unchanged.
And e861529 enabled source fortification. It seems likely to me that this may be an issue in privoxy, which is now caught by the new glibc.
Edit: Ah, your backtrace seems to confirm that: #4 0x00007ffff7886749 in __fortify_fail ()
This might be related to #262080. (However, that issue was bisected to glibc: 2.37-8 -> 2.37-39
)
Thank you, that makes sense! I'm currently believing that the issue is caused by this call to strlcpy() in the Privoxy source. But I didn't verify this hypothesis yet and need to run now.
Update: That's confirmed. Removing this call gets rid of the fortify-caused abort. The compiler warning is also interesting:
gateway.c: In function 'socks4_connect':
gateway.c:840:4: warning: 'strlcpy' writing 4988 bytes into a region of size 1 overflows the destination [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=-Wstringop-overflow=8;;]
840 | strlcpy(&(c->userid), socks_userid, sizeof(buf) - sizeof(struct socks_op));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gateway.c:112:9: note: destination object 'userid' of size 1
112 | char userid; /* first byte of userid */
| ^~~~~~
On inspection, the buffer is actually large enough, but this fact is not properly detected.
Update: I intend to change &(c->userid)
into buf + offsetof(struct socks_op, userid)
(in line 840 of the linked gateway.c). This convinces gcc that there is enough space for the strlcpy() operation. It should semantically be the same (note that c
and buf
point to the same location, they just differ in their types). I welcome comments regarding this proposed fix, will then take care of upstream reporting and submitting an interim pull request.
Describe the bug
Even with a minimal one-line config, privoxy runs into a buffer overflow on trying to serve a request. This only happens when privoxy is instructed to use a socks4 or socks4a upstream proxy, not with socks5 or socks5t. This is on current nixpkgs-unstable.
I confirmed that this bug does not occur with the old commit 2f4ea5fab6dda0199cb5e65d85b5af2eed4de14d of nixpkgs, the last time our privoxy build was touched (version-bumped). So the version bump of privoxy it not at fault.
Steps To Reproduce
Steps to reproduce the behavior:
nix-shell -p privoxy --run "privoxy --no-daemon <(echo 'forward-socks4 / 127.0.0.1:9050 .')"
in the background (even if you don't have a socks proxy listening on127.0.0.1:9050
)http_proxy=http://localhost:8118 curl http://google.com/
Expected behavior
Privoxy should not segfault, instead it should properly serve the request (or display an error in case upstream proxy servers were not reachable).
Notify maintainers
No maintainers listed.
Metadata