Microsoft hardens EMET security tool: OK, it's not invulnerable, but it's free Microsoft has beefed up its Enhanced Mitigation Experience Toolkit (EMET), adding features designed to block more exploits. The release of the technical review (beta) version of the tool, EMET 5.0, follows the discovery of new attacks against earlier versions of the technology. EMET 5.0 beta comes with a feature called Attack …
" it isn't perfect "
No, it isn't. At this stage of the security game to be offering add on tools like this rather than having an OS that is suitably hardened against attacks seems extremely poor to me. And to be releasing such a tool and declaring it unready for enterprise-wide deployment compounds the crime.
MS have two decades of form here. They have NEVER taken security seriously in the past, they are NOT doing so now, and I'll wager that the WILL CONTINUE to regard security as somebody else's problem in future.
Was that enough rabid spittle for you? I'm afraid I don't do beards.
A lot of the functionality in EMET is already built in to Windows 7, the toolkit is there either to allow you to configure it on a more granular basis or to add that functionality in to XP or Vista.
Also this is a technical preview of version 5.0 of the tool. Version 4.1 (the current release version) is fully ready for the enterprise.
Correct, most of the stuff in EMET isn't new.
However, as I have mentioned before, if MS enabled all the features by default in a normal Windows security update then all the improperly written software (current or legacy) in the world would stop working overnight.
Then MS would get a tidal wave of criticism for having too much security and stopping people using their badly written software.
Damned if they do...
"At this stage of the security game to be offering add on tools like this rather than having an OS that is suitably hardened against attacks seems extremely poor to me."
At least they have this sort of technology. With say Linux all you get is the afterthought of SEL bolted on - and the native security capabilities of Widows already exceed that by quite a long way.
EMET will likely be included in the out of the box Windows OS soon too.
How can you "suitably harden" an OS that computer-illiterates need to be able to install and use software on without training or hassle? Oh, I know, Linux is 100% secure, and just as accessible as Windows 8.
Slamming the tech preview because they admit it's not ready for enterprise-wide deployment? How does that make sense, exactly? They're releasing it while explicitly and clearly indicating that it is beta software. Should they keep it under wraps until they think it is ready to go? And then, because no one installed it and helped test it--because you didn't want them making it available--it will have lots of bugs.
No one wins with an attitude like yours. You don't even try to make sense. You slam them for releasing a security product, slam them for wanting to get a product tested before wide release, and somehow expect everything to magically work, perfectly.
Like ... Apple products?
@Ledswinger: "At this stage of the security game to be offering add on tools like this rather than having an OS that is suitably hardened against attacks seems extremely poor to me"
To be really effective, such mitigation tools need be in the hardware, operating transparently to the OS ..
This post has been deleted by its author
"Unfortunately, I can already hear the bearded, rabid masses of commentards flinging their spittle at this article"
Why ? I'd not criticize MS for getting their act together. In fact if you look at my posting history I rarely criticize their software at all. In fact I don't think about them at all unless I'm reminded on the Register.
(Also non-bearded and non-sandal wearing, non-basement dwelling, saliva-retaining, married scientist without Lyssavirus infection)
When I look at the given examples in this article I can't help wonder..
"Using the tool, Java, for example, could be enabled for intranet applications but blocked when it comes to sourcing anything from the wilds of the worldwide web."
That's a poor example to start with ("Java" being what? Java webstart, Java applications which use the network?) but wouldn't a properly set up firewall make more sense here? It'll have no problems with separating network streams which go out onto a (trusted) Intranet or into the Internet.
But when taking closer look at the actual explanation it becomes even more bothersome. For starters this thing is for i386 (32bit) environments only, that doesn't sound too reassuring to me. I also don't quite grasp the potential of this still being a userland process.
Maybe I'm spoiled or have been brainwashed but when I think about security the first thing popping up in my mind is kernelspace. Can't be easily touched from userland, and can basically dictate just about everything.
# sysctl security.bsd.see_other_uids=0
After issuing this on my FreeBSD box you're going to have a good time trying to poke around using ps, procstat, pstat or even by trying to access procfs directly (mount it on /proc for example). Not gonna work; after that my kernel won't let you. It won't simply block you from accessing processes to which you have no access too (think PID 1 (init)); it'll simply tell you that those processes don't even exist at all :-)
THAT is a display of security for me. And but one example of the extensive things I can pull off with this stuff. And process accounting (which seems to be related to all this) has been around for quite some time on Unix(-like) environments. But the thing is; the actions taken based on that are always actions after the fact. I think the best thing is to be one step ahead.
""Java" being what? Java webstart, Java applications which use the network?"
Java being the plugin in Internet Explorer.
"For starters this thing is for i386 (32bit) environments only"
That particular feature may only work on 32bit at the moment but the tool is definetly not 32bit only.
"But when taking closer look at the actual explanation it becomes even more bothersome. For starters this thing is for i386 (32bit) environments only, that doesn't sound too reassuring to me. I also don't quite grasp the potential of this still being a userland process."
Where to start with this?
First up EMET runs fine on 64bit systems, some of the mitigations are only available for 32bit processes. The ASR mitigation (the one that deals with java in the browser) is available for both 32bit and 64bit processes. However modern versions of IE don't have 32bit and 64bit versions, they run as 64bit and spawn 32bit processes as required to run plugins.
The article you linked to concerns EMET 4.1 and includes a paragraph at the bottom thanking Microsoft for working with with them and I would expect the new release 5.0 to include fixes for the workarounds Bromium labs presented.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
