in case of an error condition, both start_chain() and chain_step()
were closing the fd to be acted upon, without setting it to -1,
and the function calling them would close them again.
this could affect multi-threaded applications that opened new fds
between the first and the second close, invalidating those fds
in the targeted app.
patch loosely based on report and PR by @jhfrontz.
closes#542
closes#497
in order to make this work, also the change in 2d265582a2
was required; otherwise the sendto() call from rdns lookup would
cause the init code to be called from within the init code and
ultimately hanging on pthread_once().
before we started to use the gcc constructor attribute to load our
initialization code, each function hook used to check whether the
initialization was already done, and if not, do it at that point.
this workaround is quite ugly, and creates a circular reference
if the startup code calls any of the hooked functions.
now we only do the lazy init if the compiler used is not GCC
compatible.
according to research done by @malash, the proxychains4 binary
itself isn't allowed to use system-internal arm64e mode; but
it's possible to add it as a 3rd architecture to the shared
library (.dylib), and then even inject it into system binaries
like /usr/bin/curl, which didn't work since the introduction
of SIP.
therefore, we now create the dylib with all 3 archs, but the
launcher only with arm64 and x86_64.
closes#453
even though the preload library was built correctly, the LDFLAGS set
weren't passed to the main proxychains4 binary, resulting in link
errors against the fat object files.
closes#452
- glibc < 2.14 uses "unsigned" instead of "int" for flags
- openbsd and freebsd use "size_t" instead of socklen_t for servlen
and nodelen, while still using socklen_t for salen.
closes#430
If the application specifies a protocol but not a socket type,
normally getaddrinfo will select a corresponding protocol.
Mimic this behavior in our implementation of the function as well.
We only care about the case we're actually able to proxify
(SOCK_STREAM / IPPROTO_TCP).
Fixes proxifying pssh.
there's currently no build system support yet. after ./configure
was executed, add -DMONTEREY_HOOKING to CFLAGS/CPPFLAGS in config.mak
to activate this.
addressing #409
special thanks go to @yicong2007 and @YangshengLu for helping to
figure out this new technique.
this is currently a NO-OP, but it's already useful in that it
clearly marks our hook functions that override libc.
this in preparation of adding support for MacOS 12.0.1 "Monterey",
which apparently requires a new dynlinker hooking method.
in ce655fdac8 the getnameinfo function
was factored into a separate TU to prevent its POSIX signature from
colliding with GLIBC's wrong prototype. since this has been fixed
in GLIBC 10 years ago, it should be safe by now.
undoing the workaround has the advantage that all hooked functions
are now available in the same place, which is a prerequisite for
a change i'm about to commit.
if it turns out there's still systems in use that use the old GLIBC
version with the wrong prototype, we can add a configure check
dealing with it.
introduced in 83bfa0b61d, the check_link_silent
option always returned the result from the rm -f command rather than
the result from the compiler.
fixes#400
Replace -o /dev/null by -o "$tmpc".out in check_link_silent and
check_compile otherwise test will fail with some bugged binutils
(https://sourceware.org/bugzilla/show_bug.cgi?id=19526) since version
4.13 and
35a674bdbc:
checking what's the option to use in linker to set library name ...
cannot find an option to set library name
package/pkg-generic.mk:249: recipe for target '/home/buildroot/autobuild/instance-2/output-1/build/proxychains-ng-4.14/.stamp_configured' failed
Fixes:
- http://autobuild.buildroot.org/results/9320d9b2c69882e23bbe7b30057eb8bee0c9d2e5
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
in scenarios where one is to spin up several processes with the same
proxy list in random mode, all processes started in the same second
would pick the same proxy due to using the same srand() seed.
closes#380
localnet with hostnames/DNS is not compatible with remote dns - if remote dns
is activated we get an ip from the remote dns resolver in the connect() call,
so we don't know whether the destination would match any localnet - except
from the ANY localnet 0.0.0.0 - in which case we would need to do a real DNS
lookup with the remote DNS ip involving both the rdns resolver to get the
original hostname back and then call the native DNS resolver function - for
which there is only getaddrinfo() when we don't want to support the 5
different gethostbyname_r() variants in existence, or using getaddrinfo(),
which in turn requires memory allocation/free() - in other words a huge mess.
we also can't easily check in the resolver whether an ANY-destination localnet
is enabled and the port matches, because the resolver might only resolve the
hostname at this stage, but not the destination port.
addressing #358
