Dev411 Blog: Category security

Laptop Security and IronKey?

2008-05-30T02:20:00-05:00

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.

Update: After a bit more reading, it appears that it's impossible to eliminate use of a password for the Administrator user as mentioned in this thread. IBM references include this and this.

Encrypting Hard Drives

Modern hard drives including the Hitachi Travelstar 7K200 and the Momentus® 5400 FDE.2 Hard Drives include built-in bulk-encryption technology. Here is a thread on the ThinkPad's bulk encryption hard drive. Moving the decryption key to a removable device like the IronKey seems to make a lot of sense. This way if the laptop/hard drive was lost, it would be useless without the IronKey and the IronKey password. Is something like this in the future for laptop security? I wasn't able to find this feature on their website but it seems like an interesting option.

Encrypting File Systems

Microsoft has been offering their Encrypting File System (EFS) offering for sometime and has redesigned for Vista. Linux users also have an option with EncFS which is licensed under GPL. PGP Whole Disk Encryption is yet another option. Microsoft EFS can use keys stored in smart cards, and presumably the IronKey. I'm still not sure how popular Microsoft EFS is and whether you need a Microsoft PKI deployment or not.

With the growing number of laptop security solutions, what is the current best option and what would be the ideal option for the future? I have to admit the idea of using a USB crypto token to decrypt a hard drive seems attractive.

Rails 1.1.4 LOAD_PATH vulnerability

2006-08-10T12:20:00-05:00

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.

Brian Hogan reports the 1.1.5 fix does not work with Mongrel and Sander Land's fix is needed. The issue is being discussed on Ruby Forums and here's the latest patch':

--- routing.rb.orig     2006-08-10 12:20:12.830325000 -0500
+++ routing.rb  2006-08-10 12:20:26.043147000 -0500
@@ -273,7 +273,7 @@
             $LOAD_PATH.select do |base|
               base = File.expand_path(base)
               extended_root = File.expand_path(RAILS_ROOT)
-
base.match(/\A#{Regexp.escape(extended_root)}\/*#{file_kinds(:lib) *
'|'}/) || base =~ %r{rails-[\d.]+/builtin}
+
base.match(/\A#{Regexp.escape(extended_root)}\/+(#{file_kinds(:lib) *
'|'})/) || base =~ %r{rails-[\d.]+/builtin}
             end
           else
             $LOAD_PATH

37Signals is getting some flack for keeping this a secret when it's so easy to discover what the issue is. Hopefully they'll learn their lesson. They'd also come across as more professional without things like this: http://www.flickr.com/photos/planetargon/127984254/.

Rails 1.1.5 routing vulnerability

2006-08-10T10:37:00-05:00

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.

While this is being fixed you can take steps to protect your own apps by ensuring only valid urls are allowed to make it to your Rails app.

Some problem URIs that have been mentioned include:

active_support/dependencies
breakpoint_client
builder/blankslate
cgi

I've added some mod_rewrite rules for now but I'm hoping there will be a better solution soon.

If you are using 1.1.5 with Mongrel, see Rails 1.1.4 LOAD_PATH vulernability for a patch to make them work together.

UPDATE:This is now mentioned on the RoR blog with their recommended mod_rewrite fixes for Apache and lighttpd if you can't upgrade to 1.1.6 right away:

Apache:

RewriteRule ^(app|components|config|db|doc|lib|log|public|script|test|tmp|vendor)/ - [F]

lighttpd:

url.rewrite-once = ( "^/(app|components|config|db|doc|lib|log|public|script|test|tmp|vendor)/" => "index.html" )

Upgrading Typo 4.0.0 to Rails 1.1.5/1.1.6

2006-08-10T01:14:00-05:00

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).

Scott Laird is working on releasing Typo 4.0.1 (now released) which will include Rails 1.1.5 but until then, or if you don't want to upgrade Typo, you can simply upgrade the Rails used by Typo by installing the 1.1.5 vendor/rails directory over the existing one. Here are some steps:

$ cd /tmp
$ wget http://rubyforge.org/frs/download.php/12258/rails-1.1.5.tgz
$ tar -zxf rails-1.1.5.tgz
$ cd rails/vendor
$ tar -zcf rails-1.1.5-vendor-rails.tgz rails
$ mv rails-1.1.5-vendor-rails.tgz /path/to/typo/vendor
$ cd /path/to/typo/vendor
$ tar -zxf rails-1.1.5-vendor-rails.tgz

To verify that Rails has been updated you can view the version.rb file which should now give you the following:

$ cat rails/railties/lib/rails/version.rb
module Rails
  module VERSION #:nodoc:
    MAJOR = 1
    MINOR = 1
    TINY  = 5

    STRING = [MAJOR, MINOR, TINY].join('.')
  end
end

You'll probably want to back up the existing vendor/rails directory as this will extract the 1.1.5 files over it. If you simply swap vendor directories, you'll get a lot of missing requirements errors (e.g. redcloth, bluecloth, rubypants, uuidtools, etc.) because rails isn't the only thing installed under vendor for Typo.

JSON XSS exploit: don't use text/html

2006-07-24T20:40:00-05:00

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).