In proxychains, we create pipes and use them internally.
If exec() is called by the program we run, the pipes opened
previously are never closed, causing a file descriptor leak
may eventually crash the program.
This commit calls fcntl() to set FD_CLOEXEC flags on pipes.
AFAIK there's no race condition on pipe creation, but we still
prefer to call the newer pipe2() with O_CLOEXEC if it's supported
by the system, due to its advantage of atomic operation, which
prevents potential race conditions in the future.
Signed-off-by: Tom Li <tomli@tomli.me>
this should make it work automatically on any new platform without
having to add yet another ifdef hack.
should fix issues with android (#265).
additionally the code for the systems lacking GNU-compatible getservbyname_r()
is now guarded with a mutex, which prevents possible races, therefore
resolving the ancient "TODO" item.
Fix issue #147.
If all proxies are in DOWN_STATE or BUSY_STATE state, select_proxy will run
forever in an infinite loop. When all proxies are not available, we wait some
intervals and retry. The wait time starts with 10 milliseconds and is
increased by 10 milliiseconds in each loop. 14 loops sums up with 1.05 second.
this was wrongly fixed in 06c20ed394
instead of reverting we now accept the correct version
(version field containing 1) plus the incorrect version (5) given by some
proxyservers in the wild. curl accepts both forms too.
closing #224
addressing #221
calling uname in a configure script is entirely bogus, as it will return
wrong results in crosscompilation scenarios. the only sensible way to
detect the target platform's peculiarities is to test the preprocessor
for macros defining the target.
it turns out that those macros are not portable at all. rather than
adding workarounds to make it work for every single platform, just
use plain s6_addr instead.
in order to prevent future bugs like the one fixed in cc7bc891ff
we need to assure that the response is of the same type as the request -
if not, some unexpected race condition happened.
it was reported that weechat 2.0 on ubuntu 16.04 LTS x86_64 segfaulted like this:
4 0x00007f6bf0e7e0c0 in __stack_chk_fail () at stack_chk_fail.c:28
5 0x00007f6bf2536bce in at_get_ip_for_host (host=0x339c4d0 "abcdefghijklmnop.onion", len=22) at src/allocator_thread.c:290
readbuf = {octet = "irc.", as_int = 778269289} msg = {msgtype = ATM_GETNAME, datalen = 13}
what happened was that weechat forked, thus got its own private copy of the VM
and thus a private copy of the mutex which should prevent parallel use of
at_get_ip_for_host() & friends. therefore the following race was possible:
- process A writes a message of type ATM_GETIP into the server pipe
- process B writes a message of type ATM_GETNAME into the server pipe
- process A write transaction is finished, and goes into receive mode
- server thread reads process B's message and responds with a ATM_GETNAME msg
- process A reads the response which was intended for process B into the 4 byte
ip address buffer, but ATM_GETNAME are much larger than ATM_GETIP responses,
resulting in stack corruption.
to prevent this issue, the storage of the mutex must reside in shared memory,
which we achieve via mmap. alternatively, shm_open() or sysvipc shm stuff could
be used. the former requires the mmap call to happen before the fork, the latter
not, however the shm would require a named object in /dev/shm (which requires
generating a unique name per proxychains instance, and subsequent cleanup).
so in the end, the mmap is easier to deal with, and we can be reasonably
certain that our constructor is being run before the hooked application forks.
unlike one would expect, setting `CC?=gcc -m32` in config.mak did not actually
lead to `gcc -m32` being used as compiler when running make, even though CC
was not declared anywhere else.
it appears as if the CC variable is implicitly defined by GNU make, so using
the ?= assignment (meaning "assign only if not already assigned") did not have
an effect.
when this configure script and Makefile here were written, they were modeled
after the interface provided by GNU autoconf (so there are no surprises for the
user). the assumption was that environment variables passed during configure
are usually stored and used for the compile, but can be overridden when running
make by exporting the variables again.
in reality though they can not be overridden by environment when running make,
as tests showed.
because of that, the other user-supplied variables will now be hard-assigned as
well.
closes#152
commit message by @rofl0r.
we temporarily store all buildsystem-set conditionals into
OUR_CPPFLAGS and write it into config.mak as an addition to eventually
user-supplied CPPFLAGS. this should prevent crucial things we set from
being overwritten by a user that has CPPFLAGS exported.
fixes#142
apparently mktemp on OSX 10.9.5 requires a parameter.
instead of playing whack-a-mole with apple we now use the portable
code from musl's configure script which should work everywhere.
adresses #142
When hardening flags are set by Debian's auto build system,
the project fails to build due to usage of -pie, which tells the linker
to build a PIE binary, and since the user LDFLAGS are deliberately put
later in the command line to override things, this overrides -shared.
work around by putting it directly in the last position of the linker
command line.
closes#124
Commit message authored by commiter.
it turned out that calling dlsym() may call malloc() in turn,
so we end up with the same deadlock described in the latest commit.
we thus now put all the fds passed to close pre-init into a list
and close them at init time.
this may finally fix#119.
it was observed that it is a bad idea to initialize the entire
infrastructure used by proxychains from the close hook,
because the following scenario will lead to a deadlock:
- it is possible that the dynlinker executes the initializer code of
other shared libs first
- if that code directly or indirectly calls malloc()
- which calls close() if it decided to use an mmap based allocation
- will now call our close(), which does
- call pthread_once which requires a lock
- creates a thread which calls malloc()
- which in turn calls our close() another time
- and our close is still in locked state.
so it seems the only save thing to do is to just get the address
of the original close function, and call that when we're in a
pre-init state.
this may hold for other functions that do lazy initialization as well,
however for those just calling the original function is probably
undesired since that could result in unproxified connections.
it will be needed to analyze on a per-function basis what the best
thing to do is, and finally rely only on the execution of the init
function from the gcc initializer.
should fix#119
