“Meltdown” and “Spectre”: Every modern processor has unfixable security flaws

Spectre

Windows, Linux, and macOS have all received security patches that significantly alter how the operating systems handle virtual memory in order to protect against a hitherto undisclosed flaw. This is more than a little notable; it’s be…

Windows, Linux, and macOS have all received security patches that significantly alter how the operating systems handle virtual memory in order to protect against a hitherto undisclosed flaw. This is more than a little notable; it's been clear that Microsoft and the Linux kernel developers have been informed of some non-public security issue and have been rushing to fix it. But nobody knew quite what the problem was, leading to lots of speculation and experimentation based on pre-releases of the patches.

Now we know what the flaw is. And it's not great news, because there are in fact two related families of flaws with similar impact, and only one of them has any easy fix.

The flaws have been named Meltdown and Spectre. Meltdown was independently discovered by three groups—researchers from the Technical University of Graz in Austria, German security firm Cerberus Security, and Google's Project Zero. Spectre was discovered independently by Project Zero and independent researcher Paul Kocher.

Read 14 remaining paragraphs | Comments

Google’s own researchers challenge key Android security talking point

No, address randomization defense does not protect against stagefright exploits.

Ron Amadeo

Members of Google's Project Zero vulnerability research team have challenged a key talking point surrounding the security of Google's Android mobile operating system. To wit, a key exploit mitigation known as address space layout randomization does much less than the company's overworked public relations people say in blocking attacks targeting critical weaknesses in Android's stagefright media library.

As Ars reported beginning in July, a series of vulnerabilities in the libstagefright library made it possible for attackers to remotely execute malicious code on close to one billion Android phones. In the following seven weeks, Google has released updates that either lessen the severity of attacks or directly fix the underlying cause, although many users have yet to receive the fixes, and some probably never will.

Throughout the resulting media storm, Google PR people have repeatedly held up the assurance that the raft of stagefright vulnerabilities is difficult to exploit in practice on phones running recent Android versions. The reason, they said: address space layout randomization, which came to maturity in Android 4.1, neutralizes such attacks. Generally speaking, ASLR does nothing to fix a buffer overflow or similar software bug that causes the vulnerability in the first place. Instead, the defense vastly decreases the chances that a remote-code-execution attack exploiting such bugs will succeed. ASLR does this by loading downloaded scripts in a different memory location each time the operating system is rebooted. If the attacker can't locate the malicious code, the exploit results in a simple crash, rather than a game-over hack.

Read 7 remaining paragraphs | Comments

Major Adobe Hack – Acrobat & ColdFusion Source Code Leaked

So earlier this month there was a major Adobe hack and the source code for a couple of it’s mainstream products (Acrobat Reader, ColdFusion and ColdFusion Builder) was leaked and downloaded, most likely in it’s entirety. There was a bit of a panic surrounding this as the software is used by a lot of major […]
The post Major Adobe…

Read the full post at darknet.org.uk

So earlier this month there was a major Adobe hack and the source code for a couple of it’s mainstream products (Acrobat Reader, ColdFusion and ColdFusion Builder) was leaked and downloaded, most likely in it’s entirety. There was a bit of a panic surrounding this as the software is used by a lot of major [...] The post Major Adobe...

Read the full post at darknet.org.uk

New Zero-Day Attack Copies Earlier Flash Exploitation

Late on July 10, Microsoft released a blog post disclosing that they were aware of a zero-day attack in the wild. This attack exploits a previously unpatched Internet Explorer vulnerability (CVE-2013-3163). It’s interesting that the vulnerability was just patched in this month’s Patch Tuesday (July 9), which is perhaps only a coincidence. Although we do Read more…

Late on July 10, Microsoft released a blog post disclosing that they were aware of a zero-day attack in the wild. This attack exploits a previously unpatched Internet Explorer vulnerability (CVE-2013-3163). It’s interesting that the vulnerability was just patched in this month’s Patch Tuesday (July 9), which is perhaps only a coincidence. Although we do not know how long ago the attack began, we do have the official solution right now. (Apply the Microsoft patch if you haven’t done so.)

McAfee Labs rapidly responded to the threat. While digging into the exploitation process, we realized that this attack leverages the same exploitation technology that we were first to identify in an Adobe Flash zero-day attack in February. We call the new exploitation technology the Flash Vector exploitation. As highlighted in our blog post from February, we made a fairly accurate prediction:

More important, the technique looks like a common exploitation approach to Flash Player. The vulnerability actually doesn’t help much–just overwriting few bytes that are considered as a field of “element number” for a specific ActionScript object. These traits show that the exploitation technique is not limited to this particular Flash vulnerability; it may apply to other Flash or non-Flash vulnerabilities.

Both of these attacks leverage a weakness inside Flash Player’s custom heap management, especially, for the heap management of ActionScript “Vector.<>” objects. During our analysis, we also found some minor differences between these two attacks:

  • Because the trigger of the previous attack is a Flash vulnerability, the exploitation contains a step that frees the heap block (“leaving the hole”). In the second case, this step is not necessary because the trigger is an IE vulnerability. IE and Flash use different heap managements; thus IE can overwrite the memory bytes managed by Flash.
  • In the earlier exploitation, the zero day leveraged the “Vector.<Number>()” object and corrupted its length field. In the current case, the exploit leverages the “Vector.<uint>()” object (corrupting its length field as well). For example, the following code sprays a lot of “Vector.<uint>()” objects in the memory:

vector_spraying1

McAfee Labs has released a couple of UDS signatures to protect customers of our Network Security Platform against the IE vulnerability as well as the exploitation. Signature “UDS-HTTP: Microsoft Internet Explorer CBlockElement bdo element tag Use After Free Vulnerability I” addresses the vulnerability, and “UDS-HTTP: Microsoft Internet Explorer CVE-2013-3163 Flash Exploitation” handles the exploitation. Also, the generic buffer overflow prevention feature on our HIPS products will stop the related attacks.

The author would like to thank Bing Sun, Chong Xu, and Xiaoning Li (Intel Labs) for their help with the analysis.