Script stuck (cannot ctrl-C to quit) when DNS resolution fails (using remote())

[tesuji]

Debug Output

Having the extra debug output really helps us, and might help you diagnose the problem yourself.

The command is stuck around 30 seconds before quitting.

> py run.py DEBUG REMOTE
[┤] ] ening connection to chall.lac.tf on port 31174
Traceback (most recent call last):
  File "/home/hacker/venv/lib/python3.12/site-packages/pwnlib/tubes/remote.py", line 111, in _connect
    for res in socket.getaddrinfo(self.rhost, self.rport, fam, typ, 0, socket.AI_PASSIVE):
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/socket.py", line 976, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
socket.gaierror: [Errno -3] Temporary failure in name resolution

Expectaion

I would like to use ctrl-C to quit immediately in these cases.

Verify on Ubuntu

I'm using Debian Sid (Latest) if it worths mentioning.

[tesuji]

@Arusekk said

If you press Ctrl+C and the process still does something, it means the exception handler does too much work, so it might mean there is some except block instead of except IOError. I will try to reproduce your issue.

It's really hard to test, or at least unreliable to test a DNS resolution failure. In the meantime I've just tried
to reproduce the issue again on my system, this time the DNS resolution succeeds.

But I still think the problem is that the socket.getaddrinfo calls get blocked until succeed/fail/timeout.
Some people reports that too:

• https://stackoverflow.com/questions/43765374/socket-getaddrinfo-gets-stuck-blocking-the-process-indefinitely-when-using-requ
• https://emptysqua.re/blog/getaddrinfo-deadlock/

The quirk is this: on some platforms, Python locks around getaddrinfo calls, allowing only one thread to resolve a name at a time.

• https://forum.micropython.org/viewtopic.php?t=6800

[Arusekk]

Maybe we can set SIGINT handler to SIG_DFL as a workaround?

[tesuji]

If you truly want to reproduce the issue, you could setup a fake DNS server that does nothing
but sleeps for 1 minute. And change your system DNS address to your DNS server.

Maybe we can set SIGINT handler to SIG_DFL as a workaround?

You mean to change and restore SIGINT handler before and after resolving DNS?
If that works, I'm happy with it.