ssh (and thus git) doesn't work anymore with proxydns and latest glibc

[rofl0r]

due to the new close_range syscall
which was added in linux 5.9 and recently activated in glibc:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=456b3c08b6fe78938af5d12b6869dc8c704696d6;hp=e186fc5a31e46f2cbf5ea1a75223b4412907f3d8
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=286286283e9bdc7ef894306e2dbcf4c115b97ba2

this causes our close() hook to become ineffective and ssh closing our pipes to the dns lookup thread behind our back.
until we add a hook for close_range, the issue can be mitigated by either using the new proxydns_daemon mode, or by compiling openssh from source configured as follows:
./configure ac_cv_func_close_range=no

[rofl0r]

closed by 0000000

[NexZhu]

Still happenning on CentOS Stream release 9 (WSL):

> pc ssh git@github.com
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/local/lib/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.16-git-7-g916d2d7
select2: Bad file descriptor
ssh: Could not resolve hostname github.com: Unknown error

[rofl0r]

does it work on "CentOS Stream release 9" without WSL ? WSL isnt explicitly supported and it might do some things differently or even give bogus results for some syscalls.

[recolic]

After some tests, I can reproduce this issue at

centos 9, glibc 2.34-39.el9, OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021

Everything is good at ArchLinux, glibc 2.35-6, OpenSSH_9.0p1, OpenSSL 1.1.1q 5 Jul 2022

I'm not sure what's going wrong.

[rofl0r]

does the problematic binary contain close_range references ? (you can check with objdump, readelf, etc)

[recolic]

@rofl0r Yes. I compiled from source with the latest git repo.

I have a reproduce in my fresh CentOS 9 VM. If you want to connect to my VM and do some debugging, you could share your SSH public key or email address so I can send you login credentials.

[rofl0r]

Yes. I compiled from source with the latest git repo.

i was talking about ssh binary, not proxychains.

share your SSH public key or email address so I can send you login credentials.

let's chat about that on IRC channel mentioned in README

[rardcode]

UPDATE:
if i use IP in ssh command, proxychains work fine.
Problem is with dns resolution?!
with FQDN:

[mypc]:~$ proxychains4 -f /home/mypc/.config/proxychains/1234.conf ssh  root@<remoteFQDN>
[proxychains] config file found: /home/mypc/.config/proxychains/1234.conf
[proxychains] preloading /usr/lib/libproxychains4.so
ssh: Could not resolve hostname <remoteFQDN>: Unknown error

using IP:

[mypc]:~$ proxychains4 -f /home/mypc/.config/proxychains/1234.conf ssh  root@<remoteIP
[proxychains] config file found: /home/mypc/.config/proxychains/1234.conf
[proxychains] preloading /usr/lib/libproxychains4.so
select2: Bad file descriptor
root@<remoteIP>'s password: 
[root@<remoteserver> ~]# 

[rmb122]

Yes. I compiled from source with the latest git repo.

i was talking about ssh binary, not proxychains.

share your SSH public key or email address so I can send you login credentials.

let's chat about that on IRC channel mentioned in README

After some debugging, I found why proxychains can't work in CentOS but work normally in Archlinux.
First, ssh will try to close all fds other than stdin/out/err by calling libc function closefrom [1]. In Centos 9 Stream, libc version is 2.34, closefrom is implemented by __close_nocancel_nostatus with a loop [2], which will close pipe opened by proxychains [3], and makes it fail to resolve DNS. But in Archlinux, libc version is 2.36 [4], in here libc is calling close_range, and it's hooked by proxychains [5] in commit 0000000.
I can prove my point by adding snippets below, which disable closefrom entirely, and now proxychains is working fine in Centos.

HOOKFUNC(void, closefrom, int lowfd) {
}