Researchers penetrate last bastion of Windows security Security researchers have defeated vulnerability protections baked into the latest versions of Internet Explorer, demonstrating that it's possible to poke holes in a safety net that's widely relied on to keep end users safe from drive-by exploits. By exploiting weaknesses in Adobe Systems' Flash Player, researchers have devised …
Back when XP only just has SP2 out, and when a good whack of machines - even in businesses - were running user accounts with admin rights the security advice was:
1. Never run, download or even vist anything you don't trust
2. Repeat 1 and rinse
3. Firewall and AV - kept up to date
4. Don't run any day-to-day stuff as an administrator
Now none of these things have changed. The new technologies MS introduced into Vista and 7 have - and the author admits this - been compromised with a HUGE amount of effort and the chances of anything like this in the wild is slim.
Additionally, .Net / Silverlight or Java won't do this - as you can't just fuck around with memory however you want. Flash is a piss poor pile of shite which allows this to take place. (Ignore the massive holes in flash anyway)
Also, could someone who knows a little more than me confirm something - UAC would need to be turned off? (Or at least protected mode in IE)
I was under the impression that under protected mode the processes that run IE are in a very low security context - lower than the user (yes, user - not admin), and therefore cannot access anything much outside of a couple of small registry hives and a folder or two that does nothing othe than IE stuff....?
Protected mode aside, surely the flash interpreter runs under the logged on users context and not under system - therefore limited to the user environment? (therefore can delete some gormless users data or change the wallpaper but about feck all else...?)
If hack is taking place through the flash process loaded into then it really is flash being shite rather than IE - in fact IE has fuck all to do with it as it's code being processed by the flash process straight onto the stack... IE is just a vessel that fire's up flash which demands to run JIT code outside of the browser process and security context.
Flash sucks - use Sliverlight instead. Bit of managed code and it all goes away you know...
Silverlight could be used as well, because it also has a JIT compiler. The issue is that DEP *has* to allow *any* JIT compiler to write blocks of memory with execute permission. The researcher just happened to select the ActionScript compiler.
So now you have memory full of malicious x86 instructions. Again, the x86 part doesn't matter, it could be native code on any processor.
Next you need to execute that code somehow. In this case the researcher has managed to find one of doubtlessly hundreds of buffer overflows resulting from IE being written in C(++). *Any* browser written in C or C++ is likely to have a high number of these vulnerabilities as well. And as far as I know, that means every browser.
Now that you've overflowed memory, you just need to put a pointer on the stack containing a memory location to jump to. But where? Due to address randomization you don't know where you're exploit code lives in memory. Fortunately due to the "spraying" bit mentioned above, the answer is *everywhere*. Just pick a random segment aligned pointer and there is a 90% chance some copy of your code is there.
This works on any JIT compiler, on any browser written in a native language, on any processor that would allow JIT compilers to run in the first place.
What is the solution? I don't know, I'm no expert. It seems like browsers should be rewritten in managed languages, or perhaps we should all move to a processor which that used a separate (non-accessible) stack for return function pointers?
Good luck with either of those two options. I think due to the wide variety of hardware platofrms appearing, that the managed code thing will happen, but only over many years.
ASLR is just basic security through obscurity, in other words - its not really security. That's not to say it doesn't have its place as an additional layer in a multilayered approach but it should never be depended upon as a primary defense.
The real problem here is trusting third party software, especially when that software is Adobe. Adobe has a long history of creating bloated, bug ridden code that is insecure by default and by design. I suspect their codebase is nearly as bad as Microsoft's where they've lost the ability (or at least the will) to clean it up properly. They are in a constant reactiobnary mode slapping Bandaid on top of Bandaid month after month.
The current Windows security model is a giant pile of schizophrenic shit.
Any program can call virtually any API and access virtually any file. Okay, recent "improvements" re: administrator vs. user accounts mean that a program probably can't ruin your system to the point where it won't boot, but acting as a botnet or searching your files for credit card numbers and emailing them to the Russian mafia is considered completely valid behavior.
Apps on the iPhone can't access any files outside of their little sandboxes, nor can they launch other apps (other than e.g. safari or email via a URL), etc. etc. It's almost impossible for a "rogue" iPhone app to do anything other than mess itself up.
Why can't Microsoft get the ball rolling on a similar security model for Windows? It doesn't have to be an all-or-nothing thing, just phase it in, maybe with a snappy name. "Firefox is now a LockBox app!" or whatever.
Now that Apple has shown us the way, there is no reason we should be running OSs that allow us to get worms, viruses, trojan horses, etc.
Fine thing to block the execution of data when Flash does it readily. Any scripting language is data right up to the point when it's "executed" by the interpreter. That's why sandboxes were invented, and why Adobe should be forcibly shut down (kill -9 and pick up the pieces later) - they aren't making it any better by allowing machine code to execute and breach the sandbox...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
