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.
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.
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.
rofl0r ·