.:Computer Defense:.

Let's call this attempt #2. I attempted to blog on this subject earlier this evening but when I published the post, only half of it was there... I've learned to either save frequently... or use an outside text editor to compose my posts.

Anyways, a couple of blogs have been mentioning a new 0-day DoS which is available on milw0rm. FrSIRT has released an advisory on the subject. I spent some time earlier today looking into the exploit...

This is included in the comments of the exploit (which is written in python):

# Tested on Windows 2000 SP4 Polish + All Microsoft Security Bulletins
# Example:
#
# C:\>python spoolss_dos.py 192.168.0.2 512
#
# [*] MS Windows GetPrinterData() 0day Memory Allocation Remote DoS Exploit
# [*] Coded by h07
# [*] Connecting to 192.168.0.2:445
# [+] Connected
# [+] The NETBIOS connection with the remote host timed out.
# [+] 192.168.0.2: Out of memory
# [+] Done
#
# Exploit --> GetPrinterData(handle, value, 1024 * 1024 * 512) --> MS_Windows
# Spooler service(spoolsv.exe) memory usage: 512 MB

I tested the exploit against Windows XP SP2. Both machines that I tested it against returned the message "Return code: Access denied (0x00000005)". This same message was also received when attempting the exploit on a Windows XP SP1 machine.
I moved my testing on to 2K. In the end I ran the exploit about 10 times, using values from 128 to 1024. Every time I ran the DoS the amount of memory in use would increase. If I attempted a value higher than the remaining available memory, I would receive a "Memory Allocation Error". When I reached the end of the available memory, my virtual memory would grow until it finally hit the maximum allowed virtual memory. At this point I received an error message on the system informing me that my Virtual Memory Minimum was too low. I ran the exploit a couple more times after this happened (using 256 as my value) and eventually the UI became unresponsive. I could very slowly move the mouse, however the taskbar clock wasn't updating with the time, and I couldn't click on anything. I was essentially forced to reboot the system. Upon reboot, there was no indication of what had caused the problem, or that there had been a problem.

It is important to remember that this DoS requires the Printer Spooler service to be enabled.  For a previous Printer Spooler vulnerability, Microsoft offered the following advice:

Option 1: Disable the Print Spooler service
( HT's Note: This solution was suggested on Donna's Security Flash (as well as MS Advisory: MS05-043, I suggest option two which is below and was also included in MS05-043 )

Disabling the Print Spooler service will help protect the affected system from attempts to exploit this vulnerability. To disable the Print Spooler service, follow these steps:

1. Click Start, and then click Control Panel. Alternatively, point to Settings, and then click Control Panel.

2. Double-click Administrative Tools.

3. Double-click Services.

4. Double-click Print Spooler.

5. In the Startup type list, click Disabled.

6. Click Stop, and then click OK.

You can also stop and disable the Print Spooler service by using the following command at the command prompt:

sc stop Spooler & sc config Spooler start= disabled

Impact of Workaround: If you disable the Print Spooler service, you cannot print locally or remotely. Therefore, we recommend this workaround only on systems that do not require printing.

------

Option 2: Remove Printer Spooler Service from NullSessionPipes.

On Windows 2000 Server Service Pack 4 remove the Print Spooler service from the NullSessionPipes registry key:

1. Click Start, click Run, type "regedt32" (without the quotation marks), and then click OK.

2. In Registry Editor, locate the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes

3.Edit the registry key and remove the SPOOLSS value.

4. Restart the affected system after performing these actions.

Impact of Workaround: Anonymous connections to the Print Spooler service will not be allowed. This is the default behavior of later operating system versions.

It is also important to note that based on the output we see in the exploit, that it would appear as thought access to port 445 is required. Firewalling this port should prevent remote DoS attempts.

Peace,
HT