Microsoft releases v1.02 of Enhanced Mitigation Evaluation Toolkit (EMET)

Published: 2009-11-02
Last Updated: 2009-11-03 15:13:09 UTC
by Rob VandenBrink (Version: 3)
1 comment(s)

 


EMET has a bunch of neat features to help harden bad code (usually old bad code).  These include:

Structured Exception Handler Overwrite Protection
An SEH overwrite attack generally succeeds by overwriting a function pointer, as opposed to a buffer overflow attack which attempts to overwite a return pointer.

Heap Protection
This offers some protection from "heap spraying" attacks.  It's a good start, but the EMET docs admit that it's not a complete solution

Null Page allocation protection

So far this is a theoretical vulnerability in Windows, but a function pointer to virtual address 0 will execute in user space, and could possibly be made to execute with kernel priviledges.  This issue has been seen in Linux and FreeBSD, but nothing (yet) in the wild to exploit this approach for Windows.  If anyone has seen this attack succeed on Windows, we'd be happy to hear about it !

Dynamic DEP (Data Execution Protection)
DEP is a feature that's caused some consternation in the developer community over the last while.  Some less savvy developers see that it causes a problem with their code, and simply deactivate it for their entire application at compile-time.  DDEP allows DEP to be enabled at an individual process level

This is not a substitute for having good code in the first place, but if you're stuck with a 10 year old business app from a vendor that's killed the product or gone under, it's better than nothing.

As a final note, given what these tools do, Microsoft of course warns that any of these features can cause problems for applications that you apply them to.  Thorough testing is certainly in order before using this toolkit.

Full details, and the download, are here ==> http://blogs.technet.com/srd/archive/2009/10/27/announcing-the-release-of-the-enhanced-mitigation-evaluation-toolkit.aspx

If anyone has any good / bad experiences with this toolkit, please drop us a comment !

The developers would like to stress that this tool set may break applications. ALWAYS TEST BEFORE DEPLOYING ANYTHING! - Andre L


=========== Reader Comments ================

We've had a number of our readers indicate that the Null Pointer protections in EMET might still need some work.

Edi and David have both pointed us to this link ==> http://www.ivanlef0u.tuxfamily.org/?p=355

Thanks again to our readers for providing "the rest of the story" !

1 comment(s)

Password rules: Change them every 25 years

Published: 2009-11-02
Last Updated: 2009-11-02 11:31:30 UTC
by Daniel Wesemann (Version: 1)
26 comment(s)

While there certainly are parts of the password rules - like length, complex syntax, special characters, etc - that indeed may contribute to improving password security, the often stated requirement to change passwords every 90 days has far less obvious benefits.

There are four basic ways for a bad guy to get your password:
(a) Ask for it. So-called "Phishing" and "Social Engineering" attacks still work, and always will
(b) Try dictionary words at the login prompt in the hope to get lucky ("Brute Force")
(c) Obtain the encryped/hashed password somehow, and crack it
(d) Leech the password off your computer with keylogger malware

None of these four scenarios becomes less likely if you change your password every 90 days. If the bad guy can't break the password hash (c) within a couple days, he'll likely just look for an easier target. Attack (b) is also out for quick wins - either it works within the first couple dozen passwords tried, or the bad guy moves on to easier prey. If (b) or (c) are successful, or the attacker already has the password through (a) or (d), 45 days on average is more than enough to empty out your bank account or use your email address for a big spam run.

The concept of password expiry remained the same for the last 25 years or so. Infosec professionals, auditors, PCI, ISO27002, COBIT, etc all keep requiring it, unchanged, even though the threats have changed quite a bit. Forcing a user who had a weak password to change it will just make him pick another weak one. Forcing a user who had a very strong password to change it will eventually annoy the user into using simpler passwords.

So what gives? There is one practical benefit. If someone has your password, and all they want is to read your email and remain undetected, they can do so forever, unless you eventually change your sign-in secret. Thus, regularly changing the password doesn't help much against someone breaking in and making it off with your goods, but it DOES give you a chance to shake off any stalkers or snoopers you might have accessing your account. Yes, this is good. But whether this benefit alone is worth the hassle and mentioned disadvantages of forcing users to change their password every 90 days, I have my doubts.

Infosec risk management is about identifying threats and vulnerabilities, and then picking a countermeasure. But if the chosen countermeasure doesn't in fact make the identified threats less likely, all we do is play security theater, and the countermeasure is one that we don't need.

Unless, of course, "best practice standards" and audits force us to have it.

 

Keywords: password
26 comment(s)

IDN ccTLDs

Published: 2009-11-02
Last Updated: 2009-11-02 01:11:04 UTC
by Daniel Wesemann (Version: 1)
3 comment(s)

Two days ago, the ICANN authorized the introduction of country code top level domains (ccTLDs) using character sets other than the latin a-z alphabet. This is no earth shattering change - we had Internationalized Domain Names (IDNs) using greek, cyrillic, chinese, etc character sets for several years. The only change is that now also the top level domain (the rightmost portion of a domain name) can be written in characters other than A-Z.

From a security point of view, things might still get "interesting". Back when the IDNs were originally introduced, look-alike domain names and even SSL connections could be credibly faked. Some web servers, firewalls and IDS products also had huge gaping holes as a result of applying their security checks only in ASCII-Land, and ignoring Unicode completely. The past ten years of experience with IDNs have brought the problem reasonably under control, and expanding the IDNs to include top level domains shouldn't be a big deal. But since we all know how software gets "fixed", chances are still that history will repeat itself, and we will soon read of a web server that readily divulges application source code when hit with a TLD in cyrillic...

Keywords: dns icann
3 comment(s)

Comments


Diary Archives