Again: this bug means that a malicious user could easily steal response packets from any mIRC UDP server script simply by flooding it with garbage packets while other clients interact with the server normally.
I doubt it could be done "easily," but it certainly sounds like it could be exploited. The reason these UDP packets arrive so closely together is because the source and destination are the same machine for both packets. Introducing any amount of latency through a network would probably make it considerably harder to replicate but it definitely is possible.
Honestly, I think the way mIRC relies on a
$sock() call to retrieve things like the remote IP and port is flawed from the beginning. Instead of simply trying to patch this bug (especially if it ends up being a convoluted bug to fix), I think it would be far more appropriate if mIRC delivered the information directly to the event as locally-scoped identifiers. For example, a UDP packet's source IP ought to be passed to the event in the form of something like
$saddr instead of having to use
$sock($sockname).saddr. I'd like to see this extended to all of the relevant
$sock() calls (for TCP connections, too), but
at the very least, to
.saddr and
.sport.
