Microsoft releases v1.02 of Enhanced Mitigation Evaluation Toolkit (EMET)
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" !
Password rules: Change them every 25 years
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.
IDN ccTLDs
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...
Comments
www
Nov 17th 2022
6 months ago
EEW
Nov 17th 2022
6 months ago
qwq
Nov 17th 2022
6 months ago
mashood
Nov 17th 2022
6 months ago
isc.sans.edu
Nov 23rd 2022
6 months ago
isc.sans.edu
Nov 23rd 2022
6 months ago
isc.sans.edu
Dec 3rd 2022
5 months ago
isc.sans.edu
Dec 3rd 2022
5 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
isc.sans.edu
Dec 26th 2022
5 months ago
isc.sans.edu
Dec 26th 2022
5 months ago