Dev411 Blog

This article was initially focused on the T61p's fingerprint reader and IronKey; however, I've expanded it to cover other options as well. Since the fingerprint reader has turned out to have little value in the way of security, I've turned my attention to the bulk encryption hard drives and encrypting file systems.

I've been discussing IronKey; however, other hardware crypto tokens such as smart cards and USB tokens may also be solutions.

Fingerprint Reader

After playing with the ThinkPad T61p fingerprint reader, I got thinking whether it would be useful to tie an IronKey USB key to the laptop fingerprint reader and/or require the IronKey to be present for the ThinkPad to boot. Furthermore, the laptop's hard drive could be encrypted by a key stored on the IronKey. Some interesting things to think about.

Does anyone know how secure the ThinkPad fingerprint reader actually is? The NotebookReview Forum has a thread fingerprint readers.

A couple of people have blogged about their use of the "elite hacking tool diff -r" to identify the problem solved by the Rails 1.1.5 Mandatory Mystery Patch. The problem is that Rails accepted LOAD_PATH as a HTTP request header with any file upload so a hacker could upload ruby controllers and then execute them by accessing the newly exposed URIs. This is discussed by Kristian Köhntopp and Evan Weaver.

People are reporting a Rails 1.1.5 routing vulerability where accessing certain URIs will crash Rails. The problem has been reported on Mongrel, WeBrick and FastCGI. Piers Cawley is working on an explicit routes fix for Typo and discusses the issue on his blog. This has not been mentioned on the RoR blog yet. Good thing for public forums.

It was recently announced that Rails 1.1.0, 1.1.1, 1.1.2, and 1.1.4. have a very serious security hole. Although the RoR blog hasn't discussed exactly what the hole is, it has been rumored to involve uploading of .rb files to execute arbitrary code on the server (UPDATE: now confirmed). Typo only allows file uploads by administrators so certain applications may be somewhat safer. (UPDATE: Running arbitrary code was fixed in 1.1.5 however you could still crash it. 1.1.6 has been released to fix these lingering bugs. Just change 1.1.5 to 1.1.6 below).

Jim Ley reports on the Google JSON XSS exploit with example code and screen shots of stealing information from the AdSense site. The moral of the story is don't use text/html for the MIME type when returning JSON, use application/json which is an IETF standard (RFC 4627) now. Most browsers should handle application/json fine, however Opera may have problems and you may want to use application/x-javascript for that. Something to remember even if your AJAX code/library doesn't care about the MIME type returned by the server, e.g. Dojo.

If you are using Catalyst and Catalyst::View::JSON, your JSON response will automatically be set to application/json for all user agents except Opera (which gets application/x-javascript) so you're already safe(r).