In modern computer systems, the biggest bottleneck of information tends to be in communicating with the hard disks. High seek times and relatively slow transmission rates when compared to RAM speeds can add up quickly. This was a necessary evil back when RAM space and costs were at a premium, but now it is not uncommon to see 4GB of RAM on laptops, and even 12GB on desktops. For  users whose primary computer use is browsing the internet (either for work, writing articles, or lolcats) and have some extra RAM, moving the browser cache to the RAM from the hard disk is a definite option for increasing speed.

In Linux systems (specifically Fedora and Ubuntu systems), this can be achieved for Chrome and Firefox by creating a larger ramdisk, mounting the ramdisk after boot, and then setting the browser of choice to use that ramdisk as a cache. The necessary commands to do this are readily available on the internet, which makes life easy. Using ramdisks for performance boosts are not exclusive to browsers, and can be used for other software such as Nagios for example.

We have previously covered a tool called Espérance DV for moving cache to RAM in Mac OSX, and for any Windows users feeling left out, there are ways of making Firefox bend to your will. Obviously you will see an increase in RAM use (duh), but this shouldn’t be a problem unless you are running out of free RAM on your system. Remember, free RAM is wasted RAM.

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]

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.

[Dan] talked about the work that had been done since the July 8th announcement. A handful of researchers had contacted him with exact bug in hand, but as requested, did not release the information. When first announced, 86% of all servers voluntarily tested using the checker on doxpara.com were vulnerable. 13 days later, the vulnerability was published and only 52% of the people using the checker are vulnerable. That’s not perfect, but 13 days gave plenty of companies enough time to both test and roll out their patches.

[Jerry Dixon], the former Director of the National Cyber Security Division, pointed out that even though the vulnerability was eventually leaked, the patches had already been out for 13 days; this isn’t a zero day vulnerability with no fix. So, we’re in a fairly good position. That being said, even since our Metasploit announcement yesterday, they’ve pushed new module code that will take over an entire domain. Security researcher [Rich Mogull] has feels that producing this exploit code quickly was “bullshit” and “only helps the bad guys“.

[Dan] pointed out that some related work people have been doing to mitigate DNS cache poisoning using firewalls. [Michael Rash] wrote about using iptables in Linux to randomize outbound requests and [Jon Hart] covered using PF in OpenBSD. The team is actively contacting vulnerable servers to get them to patch. They’ve also advised IDS vendors to look for multiple replies with the same ID as a telltale sign of this attack.

You can check your DNS servers using the tool on doxpara.com. We’ve personally switched our machines to OpenDNS‘s servers 208.67.222.222 and 208.67.220.220. Not only did it give us some piece of mind, but the performance is way better than our ISP’s overloaded DNS.

[photo: mattdork]