Frozen Cache is a blog dedicated to a novel way to prevent cold boot attacks. Last year the cold boot team demonstrated that they could extract encryption keys from a machine’s RAM by placing it in another system (or the same machine by doing a quick reboot). Frozen Cache aims to prevent this by storing the encryption key in the CPU’s cache. It copies the key out of RAM into the CPU’s registers and then zeroes it in RAM. It then freezes the cache and attempts to write the key back to RAM. The key is pushed into the cache, but isn’t written back to RAM.

The first major issue with this is the performance hit. You end up kneecapping the processor when you freeze the cache and the author suggests that you’d only do this when the screen is locked. We asked cold boot team member [Jacob Appelbaum] what he thought of the approach. He pointed out that the current cold boot attack reconstructs the key from the full keyschedule, which according to the Frozen Cache blog, still remains in RAM. They aren’t grabbing the specific key bits, but recreating it from all this redundant information in memory. At best, Frozen Cache is attempting to build a ‘ghetto crypto co-processor’.

We stand by our initial response to the cold boot attacks: It’s going to take a fundamental redesign of RAM before this is solved.

[via Slashdot]

This is unfortunately another story we missed out on while we were trying to keep things from burning down. We told you that [Jonathan Zdziarski] was going to demonstrate iPhone lock code bypassing in a webcast. The real surprise came when he pointed out that the iPhone takes a screenshot every time you use the home button. It does this so it can do the scaling animation. The image files are presumably deleted immediately, but as we’ve seen before it’s nearly impossible to guarantee deletion on a solid state device. There’s currently no way to disable this behavior. So, even privacy conscious people have no way to prevent their iPhone from filling up storage with screenshots of all their text message, email, and browsing activities. Hopefully Apple will address this problem just like they did with the previous secure erase issue. O’Reilly promises to publish the full webcast soon.

[via Gizmodo]

UPDATE: Full audio of the webcast is now available

Today Black Hat held a preview webcast with [Dan Kaminsky] about the massive DNS bug he discovered. On July 8th, multiple vendors announced a patch for an undisclosed DNS vulnerability. [Dan Kaminisky] did not release the details of the vulnerability at that time, but encouraged security researchers to not release their work, if they did happen to discover the bug. On the 21st, the full description of the vulnerability was leaked.

In today’s webcast, [Dan] covered how he felt about the handling of the vulnerability and answered a few questions about it. He started out by talking about how he stumbled across the bug; he was working on how to make content distribution faster by using DNS to find the server closest to the client. The new attack works because DNS servers not using port randomization make it easy for the attacker to forge a response. You can read the specifics of the attack here.

Read the rest of this entry »

We’ve been tracking Metasploit commits since Matasano’s premature publication of [Dan Kaminsky]’s DNS cache poisoning flaw on Monday knowing full well that a functional exploit would be coming soon. Only two hours ago [HD Moore] and [I)ruid] added a module to the Metasploit Project that will let anyone test the vulnerability (with comment: “ZOMG. What is this? >:-)“). [HD] told Threat Level that it doesn’t work yet for domains that are already cached by the DNS server, but it will automatically wait for the cached entry to expire and then complete the attack. You can read more about the bailiwicked_host.rb module in CAU’s advisory. For a more detailed description of how the attack works, see this mirror of Matason’s post. You can check if the DNS server you are using is vulnerable by using the tool on [Dan]’s site.

[photo: mattdork]