I'll just paste the following message to me from Ohio Dude on how to fix this problem. 🙂
Smoke --
On your system(s) that run SetiQueue, search for the "hosts" file using Windows Explorer. Edit it in a text editor (notepad is fine) and add a line at the end like this:
66.28.250.122 shserver2.ssl.berkeley.edu
(The IP and the server name are separated by a space or a tab character.)
If every one of your clients transmits to your setiqueue system, then that is the only one you need to worry about. In other words, any system that transmits directly to Berkeley should have the line above added to the hosts file.
The exploit requires a spoof entry to be added to the DNS cache on the system transmitting wu's to direct requests intended for Berkeley to a different system. TCP/IP always looks to the hosts file before looking at DNS to resolve host names so adding the line to your hosts file will always direct requests to Berkeley's IP regardless of what's in your DNS cache.
_________________
