OpenBSD-current runtime issue with function get_chain_data in libproxychains.c (not working)

[shaxo]

Hi,
I tried to set-up proxychains-ng on OpenBSD-current OS. Compiling is fine, however, there is an abort issue at runtime. I tried to debug a bit, please find below my debug output while trying to proxy /usb/bin/ftp through a socks proxy, and the associated gdb backtrace.

Apparently, the issue comes from the function get_chain_data in libproxychains.c and the ending fclose instruction. Commenting ending fclose(file) causes the program to work. I did not find out why. There is apparently a mutex issue (same lock 0x1d1f03ede200 in the backtrace).

==== DEBUG output with RTHREAD_DEBUG=100

./proxychains4 -f /tmp/proxychains-ng-master/src/proxychains.conf ftp http://192.168.130.5/ip.php
[proxychains] config file found: /tmp/proxychains-ng-master/src/proxychains.conf
[proxychains] preloading ./libproxychains4.so
rthread init
DEBUG:init_lib_wrapper called from gcc_init
0x1d1f5fd44920: mutex_lock 0x1d1f03ede200
DEBUG:pid[29787]:at_init
0x1d1f5fd44920: mutex_lock 0x1d1f03edec40
0x1d1f5fd44920: mutex_unlock 0x1d1f03edec40
0x1d1f5fd44920: mutex_lock 0x1d1f136c0d00
0x1d1f5fd44920: mutex_unlock 0x1d1f136c0d00
0x1d1f5fd44920: mutex_lock 0x1d1f03edec40
0x1d1f5fd44920: mutex_unlock 0x1d1f03edec40
0x1d1f5fd44920: mutex_lock 0x1d1ef1749fc0
0x1d1f5fd44920: mutex_unlock 0x1d1ef1749fc0
DEBUG:init_lib_wrapper called from close
0x1d1f5fd44920: mutex_lock 0x1d1f03ede200
Abort trap (core dumped)

=== gdb Backtrace

1 0x00001cfe732f36a9 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52

2 0x00001cfe1f726f48 in _rthread_mutex_lock (mutexp=0x1cfe76f8d698, trywait=0, abstime=0x0) at /usr/src/lib/librthread/rthread_sync.c:127

3 0x00001cfe1f7230a5 in pthread_once (once_control=0x1cfe76f8d690, init_routine=0x1cfe76b88bbd <do_init>) at /usr/src/lib/librthread/rthread_once.c:24

4 0x00001cfe76b88d3e in init_lib_wrapper (caller=0x1cfe76c8b89e "close") at src/libproxychains.c:130

5 0x00001cfe76b8980b in close (fd=10) at src/libproxychains.c:301

6 0x00001cfe732e9668 in (fp=0x1cfe73720100) at /usr/src/lib/libc/stdio/fclose.c:51

7 0x00001cfe76b8977e in get_chain_data (pd=0x1cfe76f8f7c0, proxy_count=0x1cfe76f8d660, ct=0x1cfe76fd37e0) at src/libproxychains.c:289

8 0x00001cfe76b88bfa in do_init () at src/libproxychains.c:108

9 0x00001cfe1f7230ae in pthread_once (once_control=0x1cfe76f8d690, init_routine=0x1cfe76b88bbd <do_init>) at /usr/src/lib/librthread/rthread_once.c:26

10 0x00001cfe76b88d3e in init_lib_wrapper (caller=0x1cfe76c8b611 "gcc_init") at src/libproxychains.c:130

11 0x00001cfe76b88d54 in gcc_init () at src/libproxychains.c:141

12 0x00001cfe76b8608e in ?? () from /usr/local/lib/libproxychains4.so

13 0x00001cfe76b85a79 in _init () from /usr/local/lib/libproxychains4.so

[rofl0r]

thanks for your research.
the problem is that openbsd's fclose() calls proxychains close() function rather than the libc one (this happens before the hook gets installed).
this behaviour is strange since it breaks dlsym(RTLD_NEXT)-style LD_PRELOAD usage.
i guess this should be reported to the openBSD developers working on the dynamic linker.
meanwhile can you test if this patch against master fixes the issue ?

http://sprunge.us/hDCL

[rofl0r]

btw i was informed that it is a bug that openbsd's fclose() calls close().
close is not defined by ISO C; it's in the application namespace.
int close(int x) { puts("xxx"); } int main(void) { fclose(stdout); }
this is a conforming C program that has no output (close is dead code).
on openBSD it probably blows up. if you're subscribed to the openbsd mailing list it may make sense to report this.

[shaxo]

Hi,
thanks for your reply. The patch provided corrects the faulty behavior.
I'll have a closer look to the reported OpenBSD issue, and will report it if confirmed.

[rofl0r]

hi @shaxo . could you test if current git master (without the previous patch) works (at least with wget, curl oslt) on openbsd ?