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!
Just switch to Linux servers instead. :)
The ability to not require rebooting for years comes as standard.
Downtime due to upgrades is limited to how fast you can restart the app.
You can swap the files while its still running, then just restart it.
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.
You've always been able to automatically update even cracked copies of Windows automatically, you just can't do it via update.microsoft.com.
I'm not sure where you've got your information from.
"It does not do to leave a live dragon out of your calculations, if you live near him." - Tolkien
LOL! Yea... especially considering that doing some SIMPLE things like these:
1.) Stopping "File & Print Sharing", via your local connection, removing it as a Client/Protocol there (if you're not on a Lan Manager based OR Active Directory IP based LAN/WAN, or home network? Who cares! It's slowing you down just broadcasting extra packets anyhow OR listening for them too, wasting IO + resources) & the SYSTEM ICON in Control Panel (as to options &/or quick tasks to perform for that) make it a snap to stop it from being effective
----
2.) Removing ALL shares, hidden or otherwise via say, a batchfile (or even DOS command prompt) like:
C: /DELETE /DELETE /DELETE /DELETE /DELETE /DELETE /DELETE /DELETE /DELETE
NET SHARE C$
NET SHARE ADMIN$
NET SHARE IPC$
NET SHARE DFS$
NET SHARE COMCFG$
NET SHARE FAX$
NET SHARE NETLOGON
NET SHARE PRINT$
NET USE *
----
3.) Stopping the SERVER SERVICE (which allows sharing, & if you're not part of a LAN/WAN (like a single user system online on the internet only), you also save Memory, CPU Cycles, & Other I/O by cutting said service (via service.msc & setting its default startup type to DISABLED, & stopping it there also, once you doubleclick on it in the list)
That also, can stop this exploit from being effective - as IT is what permits shares & file + print sharing...
----
See - Technically, afaik, @ this point (haven't read the EXACT details of this thing's coding & methods though, via this RECENT CURRENT news on it)?
Each/ALL/ANY of those measures SHOULD work, just fine, in mitigating this prior to applying this patch (especially if you're a standalone machine on the internet @ home, with no home LAN present)...
(AND PLEASE - Feel free to correct me if I am off/wrong here fellas... thanks, as again, I have not "RTFA" (/. badge of honor, lol), yet as I noted above...)
APK
P.S.=> Afaik? That's more than adequate to stop this being exploitable, because if there are no SHARED DISKS present? How can you get to anything to execute anything?? File ACL's also being set (to stop remote NETWORK SERVICE, or other remote capable services &/or user-entities, except that which YOU use) helps moreso than the above, maybe overkill, but worth doing & should be by everyone anyhow, imo @ least... apk
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.
So you mean giving it permission, right? Thought so.
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?
That plus the wireless network card drops randomly. The message in dmesg is that it can't find the AP so it assumes it is gone. Restarting the networking fixes it.
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.
I don't know where you work, but unstable servers are usually a result of poor planning by system architects, insufficient funding, or inexperienced sysadmins. If I had any servers that were continuously unstable for the reasons you listed, I would lose my job. Sometimes you do have to support a system that has been outgrown by its users and applications, but there is no funding to get an upgrade and so you have to make do. This would be a valid reason for system instability. But to say that the server is crashing all the time because you installed all kinds of garbage on it without first doing the necessary checking and testing - just because some software vendor released a patch - is simply an admission of incompetence or just plain laziness. Most servers I work with are high-performance computing boxes used for CFD, FEM and other HPC tasks. Believe me, these systems run at full capacity most of the time. This is why you need these operating systems and this is why these machines cost so much. And your point of view is a perfect illustration of what I wrote in the previous post.