Yes, I know that. Perhaps my last post was a little bit unclear. From the IPC::Run documentation:
IPC::Run - system() and background procs w/ piping, redirs, ptys (Unix, Win32)
This are all machine-local tasks. Using INADDR_ANY instead of 127.0.0.1 (that's what I meant with "But why does IPC::Run::Win32IO try to open a socket accepting connections from everywhere?") on the server socket opens that socket for unexpected connections from other machines, perhaps on the local network, perhaps from the internet. There is at least a race condition in IPC::Run::Win32IO between opening the listening socket and connecting the client socket to it (via the loopback address 127.0.0.1 stored in $loopback). The socket address is relatively predictable, usually TCP port 2048 on the victim host, or one of the next ports, increased by one for each run, wrapping back to 2048 after 65535.
Imagine someone runs a Perl CGI on a Windows machine connected directly to the internet, and uses IPC::Run to execute a helper program. Connecting to TCP port 2048 immediately after issuing the request could allow you to fake all I/O that would normally go to the helper program.
OK, connecting Windows directly to the internet is already a bad idea. Newer Windows versions have a "firewall" that, when properly configurated, would not allow the connection. But it can be disabled and older Windows versions don't have a "firewall" at all. Still, INADDR_ANY is too wide open.
Alexander
In reply to Re^4: Firewall complaining about IPC::Run
by afoken
in thread Firewall complaining about IPC::Run
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |