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.
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
if an ipv4-mapped ipv6 address is detected, the ip is converted
into v4 format because it may actually be one of our remote dns ips.
it was reported that a program called "maven", when getting handed our
fake ips in the remote dns subnet, converts the ip to v6 prior to calling
connect():
[proxychains] Strict chain ... 127.0.0.1:1080 ... ::ffff:224.0.0.1:443
<--socket error or timeout!
fixes#77
only basic testing was done (with 2 socks5 proxies listening on ::1)
but seems to work as intended.
ipv6 support for the hostsreader (/etc/hosts) is not implemented so far.
the allocatorthread got pointers to RAM which were reallocated
behind the back, and if realloc() couldn't grow in-place, lead
to segfaults in applications that do a lot of DNS-lookups such
as webbrowsers.
closes#66closes#31
thanks to @ravomavain for tracking down the issue.
it is generally invalid to use a DNS name since DNS subsystem
is only available once connected to the proxy; because
DNS is done server-side.
closes#19
if a configuration file can be accessed by proxychains but there is a
mandatory access control (or other) block on the target appication's
ability to read that file, fopen() creates a NULL pointer that will
cause a segfault in fgets().
closes#17
Signed-off-by: mancha <mancha1@hush.com>
this bug was fixed shortly before 2.14 release, so we checked for that.
however some distros decided to backport this fix to earlier versions,
breaking our compiletime check.
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e4ecafe004b3d4270b3a9dace8f970047400ed38
the portable solution is to stick the function into a separate comilation
unit that does not see the glibc prototype.
closes#7
the central dns resolver function proxy_gethostbyname() used
to iterate over the gethostent() db (/etc/hosts) on each dns
request.
since this is not threadsafe, we synchronized access to it
previously using mutexes. the parsing of this file is slow,
and blocking all threads to do it even moreso.
since gethostent_r() is only available on a few platforms,
i decided to read the hostent db once and then use a quick
in-memory lookup on further usage.
+ some further refactoring.
instead of allocating memory in the child, we now use the allocator
thread to do all the necessary allocations himself.
additionally we provide a clean API to query the ip <-> dns mapping.
these functions connect via a pipe to the allocator thread, and
exchange messages.
further cleanup is needed, but it seems to work so far.
thread-safety is not yet guaranteed.
closes#1
this is in order to get irssi, which forks for DNS lookups,
and similar programs, to work as intended.
in a previous attempt i learned that shared memory created in a
child process is not visible to the parent;
in this attempt i spin off a thread from the parent which listens
on a pipe and manages the shared memory allocation from the parent
address-space. however this doesnt work as expected:
memory allocated in the parent after the child forked is not visi-
ble to the child as well.
so what happens is: irssi starts a child process, the thread allocs
memory and hands it to the child, the child attempts to write and
segfaults. however irssi doesnt crash. since now the memory is
already allocated, doing the dns lookup again will succeed.
i.e. the dns lookup works now in irssi by luck.
all but the first dns lookups will suceed.
however this is not good enough for me to be satisfied, i commit
this only for documentation purposes.
