Worms! (a public service message)
Aug. 12th, 2003 10:38 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Noticed any of the following symptoms?
* Windowsupdate.com is phenomenally, incredibly slow!
* For that matter, the whole Internet is pretty slow!
* My computer keeps telling me I have 60 seconds before it shuts down!
They're all the worm's fault! The MSBLAST.EXE/W32.Blaster worm is currently hammering the crap out of most of the Internet.
A few weeks back (may have been months by now, I don't recall), a security vulnerability in the RPC service was found; now, this worm has been written to take advantage of that known vulnerability. The vulnerability being exploited is a buffer overflow. The worm sends a specially malformed packet to the RPC service, which tries to put the data in a buffer too small for it, thus overflowing past the end and over the stack frame pointer. The result is that the packet, rather than just being used as data, is actually executed by the RPC service. This packet, of course, contains code to download and install the worm on your machine.
All the worm does is spread itself through the buffer overflow, then launch a DDoS attack on August 16th (so that part, at least, hasn’t happened yet). However, a side effect of a buffer overflow attack is that after the attack code has finished, the stack is corrupted, so the program (in this case the RPC service) will start jumping wildly to other places in memory. Sooner or later (usually sooner), it will try to jump out of its own process space, which causes an access violation (error 0xc0000005, what UNIX users call a segmentation fault). An access violation is fatal if unhandled, so the process crashes. Normally, you’d get an error dialog when a process crashes this way (as an access violation counts as a general protection fault), but since RPC is a Windows service, it fails silently in the background. If you look in Event Viewer, though, you’ll see a fatal error logged from SVCHOST.EXE when it crashed.
However, while you’re looking in Event Viewer, you’ll also notice a second event at the exact same time as the crash. USER32.EXE notices that the RPC service is no longer running, and takes corrective action. RPC, remote procedure call, is a critical Windows service – large portions of Windows will not function properly without RPC. The only way to get RPC back after it’s gone down is… to reboot. So USER32.EXE, upon noticing that RPC is gone and thus many applications will probably no longer work correctly, schedules an emergency system shutdown in 60 seconds, with the machine set to restart after shutdown. The worm actually has nothing to do with this – the worm just crashed RPC, and Windows is trying to clean up the damage. If you just killed RPC in task manager, or stopped the service with a net stop, you’d get the same countdown.
You can actually stop this shutdown if you want – executing the command “shutdown /a” will abort the countdown and return control to you. However, you may or may not want to do this… because about half the apps you run will probably not work without RPC. However, if your network is so hammered by worm traffic that you’re having trouble staying up long enough to download and apply the patch, a good “shutdown /a” can give you more time to work. Also, once USER32.EXE has scheduled one shutdown for RPC crashing, it won’t schedule another until you reboot (or manually restart RPC, which is not advisable) – so you don’t have to sit there aborting countdowns over and over again.
How can you protect yourself? Four ways:
* Use a personal firewall that blocks RPC ports. If you have XP, turning on the Internet Connection Firewall will do it. If not, download ZoneAlarm.
* Go to windowsupdate.com and download and install all Critical Updates. You should do this routinely anyway.
* Directly download the patch for Windows XP or Windows 2000. This is the same patch you'd get from windowsupdate.com. But right now windowsupdate.com is really slow... because of people getting this patch. :)
* Run Linux, Mac OS X, or any Microsoft OS made before 1995, when RPC was introduced. Yeah, I'd go for one of the first three ways, too. Alternately, if you're running Windows 95, 98, or ME, the worm will crash RPC, necessitating a reboot, but will not be able to actually infect your computer. The infection code it uses is structured for NT operating systems (Windows NT 4, 2000, XP, and Server 2003)
Finally, if you've been infected by the worm (i.e. you've seen that 60-second countdown at least once), you need to deworm your computer. There are instructions on doing it here, along with the tools you need. It is not a trivial process; you have to disable system restore to do it, so it'll take some time. However, if you don't go through this process, your computer a.) will continue spreading the worm to others, and b.) on August 16th, will launch an attack on windowsupdate.com and will continue this attack until you perform this procedure. Chances are your ISP will not consider b.) to be a kind action on your part, and will take steps to stop the attack from your computer (such as cutting off your Internet access).
* Windowsupdate.com is phenomenally, incredibly slow!
* For that matter, the whole Internet is pretty slow!
* My computer keeps telling me I have 60 seconds before it shuts down!
They're all the worm's fault! The MSBLAST.EXE/W32.Blaster worm is currently hammering the crap out of most of the Internet.
A few weeks back (may have been months by now, I don't recall), a security vulnerability in the RPC service was found; now, this worm has been written to take advantage of that known vulnerability. The vulnerability being exploited is a buffer overflow. The worm sends a specially malformed packet to the RPC service, which tries to put the data in a buffer too small for it, thus overflowing past the end and over the stack frame pointer. The result is that the packet, rather than just being used as data, is actually executed by the RPC service. This packet, of course, contains code to download and install the worm on your machine.
All the worm does is spread itself through the buffer overflow, then launch a DDoS attack on August 16th (so that part, at least, hasn’t happened yet). However, a side effect of a buffer overflow attack is that after the attack code has finished, the stack is corrupted, so the program (in this case the RPC service) will start jumping wildly to other places in memory. Sooner or later (usually sooner), it will try to jump out of its own process space, which causes an access violation (error 0xc0000005, what UNIX users call a segmentation fault). An access violation is fatal if unhandled, so the process crashes. Normally, you’d get an error dialog when a process crashes this way (as an access violation counts as a general protection fault), but since RPC is a Windows service, it fails silently in the background. If you look in Event Viewer, though, you’ll see a fatal error logged from SVCHOST.EXE when it crashed.
However, while you’re looking in Event Viewer, you’ll also notice a second event at the exact same time as the crash. USER32.EXE notices that the RPC service is no longer running, and takes corrective action. RPC, remote procedure call, is a critical Windows service – large portions of Windows will not function properly without RPC. The only way to get RPC back after it’s gone down is… to reboot. So USER32.EXE, upon noticing that RPC is gone and thus many applications will probably no longer work correctly, schedules an emergency system shutdown in 60 seconds, with the machine set to restart after shutdown. The worm actually has nothing to do with this – the worm just crashed RPC, and Windows is trying to clean up the damage. If you just killed RPC in task manager, or stopped the service with a net stop, you’d get the same countdown.
You can actually stop this shutdown if you want – executing the command “shutdown /a” will abort the countdown and return control to you. However, you may or may not want to do this… because about half the apps you run will probably not work without RPC. However, if your network is so hammered by worm traffic that you’re having trouble staying up long enough to download and apply the patch, a good “shutdown /a” can give you more time to work. Also, once USER32.EXE has scheduled one shutdown for RPC crashing, it won’t schedule another until you reboot (or manually restart RPC, which is not advisable) – so you don’t have to sit there aborting countdowns over and over again.
How can you protect yourself? Four ways:
* Use a personal firewall that blocks RPC ports. If you have XP, turning on the Internet Connection Firewall will do it. If not, download ZoneAlarm.
* Go to windowsupdate.com and download and install all Critical Updates. You should do this routinely anyway.
* Directly download the patch for Windows XP or Windows 2000. This is the same patch you'd get from windowsupdate.com. But right now windowsupdate.com is really slow... because of people getting this patch. :)
* Run Linux, Mac OS X, or any Microsoft OS made before 1995, when RPC was introduced. Yeah, I'd go for one of the first three ways, too. Alternately, if you're running Windows 95, 98, or ME, the worm will crash RPC, necessitating a reboot, but will not be able to actually infect your computer. The infection code it uses is structured for NT operating systems (Windows NT 4, 2000, XP, and Server 2003)
Finally, if you've been infected by the worm (i.e. you've seen that 60-second countdown at least once), you need to deworm your computer. There are instructions on doing it here, along with the tools you need. It is not a trivial process; you have to disable system restore to do it, so it'll take some time. However, if you don't go through this process, your computer a.) will continue spreading the worm to others, and b.) on August 16th, will launch an attack on windowsupdate.com and will continue this attack until you perform this procedure. Chances are your ISP will not consider b.) to be a kind action on your part, and will take steps to stop the attack from your computer (such as cutting off your Internet access).
no subject
Date: 2003-08-12 11:21 am (UTC)