Slashdot Mirror
Attack Code Found For Recent Windows Bug
CWmike writes "Just a day after downplaying the vulnerability that caused it to issue an out-of-cycle patch last week, Microsoft warned customers late yesterday that exploit code had gone public and was being used in additional attacks. 'We've identified the public availability of exploit code that now shows code execution for the vulnerability addressed by MS08-067,' said Mike Reavey, operations manager of Microsoft's Security Response Center, in a post to the MSRC blog. 'This exploit code has been shown to result in remote code execution on Windows Server 2003, Windows XP, and Windows 2000.'"
Just in case the /. entry seemed as ambiguous to you as it did to me, the linked article states "Our investigation has shown that it does not affect customers who have installed the update."
No, this is the same exploit we talked about before.
If you patched on the 23rd, you should be fine.
[Fuck Beta]
o0t!
Instead they issued an out-of-cycle patch and they gave it a very high severity rating in their bulletins. None of us are Microsoft lovers. But you don't have to lie to us just to be able to pat us on the back. It's disgusting, please stop it.
Be warned; this is already on metasploit. The intrepid can find this for themselves...
Testing it to see if it actually works though.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
Come on, it's dead simple and it's safe. Just install a page fault handler and mark all the pages of the DLL as being unavailable, examine the current thread state of all processes and mark them if they are currently executing in the unavaiable pages, and if so simply return success from the page fault handler until the thread leaves the locked region (essentially single step through the DLL until it finally returns to the caller). If a thread was not originally executing in the protected pages and enters it, just stall it. Once all threads are stalled or not accessing the locked pages, patch the DLL and mark the pages available and uninstall the page fault handler.
What could possibly go wrong? Only if the data structures that the DLL uses internally are modified will this be difficult, in which case the patched DLL will just have to convert its own data during the patch time. If changes to user data structures are required, then the patched DLL would have to burn some space in each new data structure to identify it as a patched version and treat it appropriately, while detecting the old data structures reliably. That might be a little harder than the general case, but not impossible.
Is getting 0wned something you would want to happen on a production server that can't have downtime?
Sure. You don't have a test network to at least smoke patches on or you would've said something
A fifteen user network all running off a cable modem, router/firewall, and Windows 2003 SBS. Sure, let me pitch the sale for them to purchase another SBS box (for testing purposes only) and the billable time required for each test required per monthly patch cycle...
What happens when your SBS box barfs
Rebuild it, add PCs back to the domain, and restore user data and exchange data. I've done it before and it's a lot cheaper alternative to the one above. Funny isn't? Sometimes it's cheaper to let a server crash and burn than spend money on preventive maintenance. It's all in how much the customer wants to spend.
Life is not for the lazy.