Heartbleed and ASLR misconceptions

TL;DR: Someone was wrong on the Internet and I just couldn’t help myself. If you already know how memory allocation works you’ll find this post boring and you can skip it. But if you don’t, read on… 🙂

I was just reading an article called “A look at Heartbleed and why it really isn’t that bad” and, while I usually tend to agree with anyone who tries to fight against FUD, in this case it happens to be dangerously wrong. I’d write this as a blog comment rather than an entry on my own, but Tumblr seems firmly stuck in the 90’s and won’t even give me that option so here it goes…

In a nutshell, the article downplays the severity of the Heartbleed attack based on the Address Space Layout Randomization (ASLR) feature of most modern operating systems, that causes memory allocations to be randomized as a mitigation for buffer overflows. The reasoning goes: since memory allocations are random, and the Heartbleed bug allows you to read memory at random as well, the odds of reading important data are pretty much close to zero – therefore the Heartbleed attack is useless and you shouldn’t change your passwords.

Ouch.

The forgotten bug: silently patched vulnerabilities

Last month, Microsoft released the security bulletin MS10-024 with a patch for a denial of service vulnerability in Exchange and the Windows SMTP service:

“This security update resolves one publicly disclosed vulnerability and one privately reported vulnerability in Microsoft Exchange and Windows SMTP Service. The more severe of these vulnerabilities could allow denial of service if an attacker sent a specially crafted DNS response to a computer running the SMTP service.”

However, researcher Nicolás Economou found an interesting surprise in this patch: two additional, undisclosed vulnerabilities had also been patched… and they were far more severe than the ones reported! From the Core Security advisory:

“Nicolas found that the Windows SMTP Service does its own DNS resolution of MX records rather that use the DNS resolver from the operating system while investigating CVE-2010-0024.

Furthermore, he found that the patch referenced in MS10-024 fixed two severe bugs that were not disclosed as such in the bulletin and had no CVE identifiers assigned to them. Basic analysis of the vulnerabilities disclosed in this advisory indicates that the threat of DNS spoofing attacks against Windows SMTP service and Microsoft Exchange or of exploitation of CVE-2010-0024 was underestimated in MS10-024.

An attacker may leverage the two previously undisclosed vulnerabilities fixed by MS10-014 to spoof responses to any DNS query sent by the Windows SMTP service trivially. DNS response spoofing and cache poisoning attacks are well known to have a variety of security implications with impact beyond just Denial of Service and Information Disclosure as originally stated in MS10-024.”

In fact, the two “new” vulnerabilities were quite crass. Both Exchange and the SMTP service were doing their own manually crafted DNS queries using incremental transaction IDs, which is a big no-no when implementing DNS because it makes it real easy for attackers to guess the transaction ID and spoof replies, as is a well known fact for… say… the last 16 years or so? But as it turns out, attackers didn’t even need to guess the transaction IDs… because they weren’t even being used when parsing the DNS responses! 😯

This omission may be easily attributed to the “embarrasment factor” 🙂 but it’s still a terrible idea to patch vulnerabilities silently: IT administrators, unaware of the real danger of the problem, may give the patch a lower priority. A denial of service just means having the mail server down for a while until it restarts, so the patch can wait – it’d be worse if the server didn’t work at all because patching went wrong. On the other hand, a DNS poison vulnerability means having an attacker browse through everyone’s emails and taking over all other services you may have on the same machine – patching becomes much more worth the risk.

Of course, this isn’t the first time this happens. Practically every vendor did this at one time or another. A quick Google search for “silently patched vulnerability” shows some 1.400.000 hits at the time I’m writing this, showing this is neither new or uncommon – and that even small software vendors may easily get caught. Especially thanks to the rise of binary diffing tools that can pinpoint precisely where and how the code was patched.

Thanks Alfredo Ortega for pointing out this advisory and providing such a cool sounding title. 😉

New remote authentication vulnerability in Windows

A new security advisory has been published today on a new remote vulnerability (MS10-012, CVE-2010-0231) in the SMB protocol on many Windows versions, ranging from the now ancient Windows NT to the latest Windows 7. This would allow an attacker to authenticate to almost any Windows box, read and write any files, or alternatively upload an executable file and run it. Just let me quote the following, it’s what caught my eye the most:

Given that Windows NT 4 was relased in ~1996 this vulnerability has been
present for ~14 years. If it is confirmed this vulnerablity is also
present in older systems such as Windows NT 3.1, released in ~1993,
Windows NTLMv1 authentication mechanism could have been vulnerable for
~17+ years.

 

Whoa. That’s kind of scary.

Kudos to Hernan Ochoa and Agustin Azubel for this great find! 🙂

Below is the complete text of the advisory, except for the source code to the scripts, which were removed for brevity. The original advisory can be downloaded from: http://www.hexale.org/advisories/OCHOA-2010-0209.txt.

Update: Hernan Ochoa has also written an article regarding the risk assesment for this vulnerability.