Ransomware dodges EMET Infosec biz FireEye has blogged in detail about how new versions of the Angler Exploit Kit – used by malicious webpages to inject ransomware and other software nasties into people's PCs – sidestep Microsoft's EMET protections. Included with Windows, EMET has a whole bundle of features designed to thwart attempts by hackers to …
It is patently obvious that there is a crisis on the winTel platform in regards to security. Endless patching on patching going on patching. These being due to certain original design decisions in regards to the memory architecture. Perhaps they should have adopted the Harvard Memory Architecture, as in having seperate MMUs, one for data and one for instructions. That way you couldn't execute code someone sent you through the E-Mail.
Possibly, but the question is, why is flash so privileged that exploiting it is worthwhile?
Sandbox that whole browser process and its children. No network socket access, chrooted disk, read-only disk except for a stub directory/Object storage, http/s access only via a hardened local OS proxy which logs and can filter.
Read-only OS partition? Read-only installed software partitions?
Browsers don't need privileges. Use repo's or execute by default in a sandbox.
The issue is browsers don't need privilege maybe as long as you play Flash games. As soon as you want to write "useful" web applications to perform actual work, browsers starts to need privileges. And even worse, they are generic platform programmable by code they download...
Anyway, an .ocx is a COM object (an "ActiveX control", the ones introduced by Visual Basic), it's in no way tied to the browser. If used by any application able to use it, it's just Windows code running with the same privileges of the calling process.
It looks you don't know the Intel protected mode architecture. The issue actually is any OS I know running on Intel - Linux included - doesn't use the protections offered fully. Because of porting issues, because of compatibility, because of performance issues, and so on.
You can have data segments which cannot be executed, you can have code segments that can be executed but not written nor even read. Just most OS load CS, DS, ES, GS and whatever segment register they need on application startup with a simple base address, set their limit to the whole address space, and avoid to create and load proper descriptors for each memory segment needed. Why? Because loading a segment descriptor slows down the applications - because of the security checks. And may not be portable to other architectures. Same reason why, of the four privilege rings, only two has ever been used.
From a security point of view, the Intel architectures was fairly advanced compared to competition - just OSes didn't use it, often exactly because it is not portable.
@Anonymous Coward: "It looks you don't know the Intel protected mode architecture."
And neither did the people involved in the original design decisions. Having to switch off security in order to not take a performance hit is not much of a design is it. Putting all the blame on 'Flash' is specious.
Face it: security checks need CPU cycles. You can't have a free lunch. I would prefer an OS that uses CPU cycles to ensure security, instead of one who spends cycles to JIT P-Code or parse and execute Javascript. The world looks to prefer the latter.
Probably today processor are faster enough that the checks overhead is less an issue than it was in 286/386 times. But no one did and will re-design OSes, compilers and applications to ensure better and deeper layers of security. Probably instead Intel will remove them to save blocks on the chip, after all almost nobody used them.
Bad written applications like Flash will still be able to easily pierce a system.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
