PoC code uses super-critical Windows bug to crash PCs Security watchers have discovered proof-of-concept code that attempts to exploit a high-risk Windows security hole, causing computers to crash. The exploit attacks a RDP (Remote Desktop Protocol) flaw patched by Microsoft on Tuesday. Redmond's security staffers warned at the time that the critical update (MS12-020) was of a …
Allowing remote Internet access to a function that requires enormous amounts of resources and integration (and, thus, high level access) into the system to setup connections is considered a bad idea.
Shock, horror.
RDP always was a horrible bodge, and I hate it being enabled by default. It's embarrassing how many "remote-access" systems I've seen that are designed for use by staff and even school pupils which are nothing more than RDP into a remote system sitting on an internal network.
I barely trust SSH, but that's only because I'm religious in updating the damn thing and I know the initial authentication is very good about not requiring privileges or granting any access until everything is authenticated. RDP has a long history of problems like this. It tries to do too much, too simply for the user and although it works, it's always behind in terms of encryption, security etc. Even back in 2002, the problems with it were as ridiculous as trying to roll-your-own encryption and checksums and not bothering to verify their security.
If you deploy RDP on anything other than an internal network, you should be shot. That's what VPN's are for, and crashing your VPN equipment (pretty unheard of) is nowhere close to crashing your server. If you have something on your internal LAN that attacks your own server, you haven't secured it properly (which is possible in ALL instances, hence things like Ethernet port-based authentication, etc.)
He says, obviously ignoring the thousands of windoze dedicated and VS's hosted across the world, whose owners only access is via RDP from their dynamic IP broadband connections. Most hosts don't provide custom firewall rules to dedi owners at a charge, let alone included in the cost. Most dedi owners probably don't know how to apply an ipsec policy or windows firewall rule, even if they have a static IP that they can manage the server from in the first place.
Bottom line, it's the fault of a lax MS, who cares more for profit than service. The jacking of UK licensing in July might help persuade people that now's a good time to move to OSS.
How many buffer overflows does it take in a system file before MS makes sure _all_ the buffers are defined and have error and bounds checking in a particular file rather than just fixing the _one_ that has just been found.
Microsoft shot itself in the foot with the damage limitation PR speak of '30 days to exploit'. Made researchers want to find an exploit quicker.
At 8am this morning I was reading an english release which had exploit code as PoC: http://aluigi.org/adv/termdd_1-adv.txt
So it is not limited to Chinese circles.
Yes, MS have done everything they can to stress the importance of this.
My TAM has been in touch several times in the week and the Wednesday Security Bulletin conference call was dominated by discussion of this vulnerability and the importance of patching.
It would obviously be better if they didn't write these vulnerabilities in in the first place but I can't fault their efforts since it has been discovered.
Beyond automatically patching their PCs, there's not a lot MS can do about people who just don't care.
The point is that anyone who does know, knows it is important.
If you know people who have turned off the default patching options but then don't ever look for themselves, well, they're in a little PC Darwin Award competition of their own creation.
I'm damn tired of hearing about Microsoft and its Windows security fuck-ups. Clearly, it's Nero's show as there's never-ending fiddling, year after year, whilst Windows security continues to burn.
I wish those truly authoritative and respected in IT would succinctly summarize why there's a never-ending string of vulnerabilities in Windows OSes and why we and MS are continually attempting patching them. Everyone knows that Windows security is like the Dutch boy with his finger in the dyke after the global warming sea rise--a lost cause--but most, including many IT types, actually understand why it is that Windows security in its present form can't be fixed once and for all, and it needs an authoritative industry-wide explanation that even neophytes can understand.
Over the years, in both El Reg and elsewhere, I've tried to point out why this problem continues to exist together with some of the issues that need to be addressed if the problem is to be essentially fixed. ...But then, I'm only an El Reg commentard, thus one wouldn’t expect me to have much influence.
What's truly perplexing is why over the years that the heavies of industry, university IT types etc. haven't broadcast to the world with a megaphone that fundamental design problems exist within Windows (and some other OSes too). To mention a few, for example: user, program and operating system files share the same file structure thus a vulnerability exists; access to the OS directories (\Windows\system32 etc.) is possible and had by all and sundry; that there are no intrinsic Chinese walls between user, program and OS data etc.; and that existing files aren't structured to intrinsically support inbuilt authentication, encryption, encapsulation and extended metadata (owner, last authorised user etc. etc.).
It's a sham that there's no widespread and open debate over these crucial issues. The question remains as to why this high-level debate over design flaws within Windows OSes' security has been thwarted or has never seen the light of day (except in a most superficial and prosaic way). (If it were not so then there'd be widespread ideas together with a few consensuses on how to fix the problem.)
I used to think IT types didn't understand the issues involved or that they had gotten too bogged down in the minutiae of specific Windows security flaws to bother with the grand picture. Nevertheless, Windows' security problems are so monumental and have between with us for so long that one would have thought by now that a few of our brightest minds would have spoken out over the issue.
Whilst mum remains the word with the IT intelligentsia over Windows design flaws, it'll continue to be business as usual for Microsoft Marketing.
Modern Windows has a solid security model, unsolidified for political rather than technical reasons. In the real world ease of use and speed[*] sell, as people don't ask questions. MS cater to this.
It's a people problem, not a technical one and you miss that totally:
> user, program and operating system files share the same file structure thus a vulnerability exists
I don't follow. Even if they were different filesystems they'd still have to have read/write api's, so no win.
> access to the OS directories (\Windows\system32 etc.) is possible and had by all and sundry; that there are no intrinsic Chinese walls between user, program and OS data etc
Not if the person runs as user, so bollox on both counts. If you don't know that you shouldn't be posting here (no offence but do some reading on win security first)
> and that existing files aren't structured to intrinsically support inbuilt authentication, encryption, encapsulation and extended metadata
authentication & encryption are OS features. You can't put them into a file AFAICS. The other 2 I've no idea what they're supposed to be or how they help.
> I used to think IT types didn't understand the issues involved
That's right, we're fucking thick. Fortunately you're here to lead us out of this swamp.
[*] remember that in-kernel font rendering? Now I grant that was avoidable.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
