MITM program breaks socketpair, causes getaddrinfo() thread fail to start

[SerusDev]

I did this

curl https://www.google.com/

I expected the following

Instead of a success, curl always returns:
curl: (6) getaddrinfo() thread failed to start

curl/libcurl version

curl 7.83.1 (Windows) libcurl/7.83.1 Schannel
Release-Date: 2022-05-13
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
Features: AsynchDNS HSTS IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI UnixSockets

operating system

Windows 10 x64

possible cause

I was able to trace this problem to https://github.com/curl/curl/blob/master/lib/socketpair.c#L126

Apparently, curl on Windows simulates unix socket pair with a pair of regular TCP sockets on 127.0.0.1.
If the system (like in my case) runs a program that works as a proxy for this connection, socket addresses (ports) mismatch and Curl_socketpair fails.

I guess, the problem is widespread and cryptic. There is a number of antiviruses, firewalls, tunneling and monitoring software that proxy 127.0.0.1 connections and can cause this problem. At the same time, Curl_socketpair call does not provide any error messages. The top level getaddrinfo() error is very hard to track to this.
I experienced this problem when using git for Windows (curl based) together with Proxifier tool.

I propose to remove a.inaddr.sin_port != a2.inaddr.sin_port condition or perform peer validation with a chunk of a random data transmitted over the socket (recv/send calls).

[bagder]

You could of course also argue that Proxifier is the one breaking curl here...

[SerusDev]

You could of course also argue that Proxifier is the one breaking curl here...

There is no program to blame. :)
The problem is not Proxifier specific. As you correctly stated any MITM tool including some antiviruses can cause this. The problem is that it is almost impossible to track the original error with the MITM tool.

The fix for this is very easy. Socketpair code should not check the source port. Honestly, I do not see any security or stability issues here because everything happens within loopback IP.
As far as I know, many other Windows programs (e.g., Firefox and VMWare) use the same loopback approach to emulate unix socketpair, but they do not check source port and work fine with a MITM program.

[bagder]

There is no program to blame. :)

I disagree, but that doesn't help much.

Someone needs to adjust the code so that users can keep running intrusive programs that MITM localhost connections.