Security and Engineering

strange ruby syntax issue when using rescue

vetter — Sun, 15 Aug 2010 11:06:44 +0000

irb(main):001:0> x = "value" => "value" irb(main):002:0> x = puts undefined_variable rescue nil => nil irb(main):003:0> x => "value" irb(main):004:0> x = puts(undefined_variable) rescue nil => nil irb(main):005:0> x => nil irb(main):006:0>

You might understand why this happens when you think about it, but it’s rather unintuitive, though.

iphone scribble webapp

vetter — Tue, 20 Jul 2010 10:06:29 +0000

As already mentioned through twitter i’m playing around with the iphone and the canvas element to build a scribble webapp running on the device (and android devices as well). It should be possible to save/upload the scribbled image afterwards. Here’s a first code snippet

Step 1: Drawing

Drawing within the canvas is straight forward. We use mousedown, mouseup and mousemove to recognize the mouse events and draw lines between the coordinates.

Step 2: Upload

Uploading the the scribbled image is straight forward too, thanks canvas.toDataURL. toDataURL encodes the canvas using base64 what allows us to upload the encoded image using ajax or a form.

Of couse we need some server side processing. Using rails this could look like

class ImagesController < ApplicationController
  def upload
    open("#{RAILS_ROOT}/public/images/upload.png", "w") do |stream|
      stream.write decode64(params[:image])
     end 

    render(:update) { |page| page.alert("saved") }
  end
end

Step 3: Iphone

Thanks to this jquery plugin getting this to work on the iphone is as easy as including a javascript file. It translates the iphone’s javascript touch events (touchstart, touchmove, touchend) to mousedown, mouseup, mousemove, … if you addTouch() to the element.

That’s it. Maybe it’s worth to continue working on it and publishing it as a real project, because adding a scribble-webapp (within an iframe maybe?) could be a nice feature for many mobile webapps.

rails plugin testing

admin — Fri, 16 Jul 2010 11:46:02 +0000

I personally think there is not enough written about rails plugin testing, you have to deal with some problems, though, because you don’t have the rails environment on your side. I want to give 2 tips.

Tip 1:

When you extend ActionController::Base within your plugin, put your extensions into a module within a separate file. Then create another file where you extend ActionController::Base like so

require "my_fancy_controller_extension"

class ActionController::Base
  include MyFancyControllerExtension
end

The first advantage of doing it this way is: you can make your extensions protected

class ActionController::Base
  protected

  include MyFancyControllerExtension
end

and you can test your extensions without dealing with permissions: my_fancy_controller_extension_test.rb

class MyFancyControllerExtensionTest < Test::Unit::TestCase
  class DummyController
    include MyFancyControllerExtension
  end

  def test_whatever
    assert DummyController.new....

    # oh yeah, the fancy extensions are not protected within these tests
  end
end

This leads to

Tip 2:

Don’t try to load the whole rails environment within your plugin tests. Loading the whole environment is a lot of work, dependencies, paths, …. Avoid that, where you can. Instead, create dummy controllers, views, models, … to only build the interface neccessary for testing. Use duck typing! One example:

class TestController
  attr_accessor :request, :session, ... # only what your plugin code needs

  class TestRequest
    attr_accessor :host, ...
  end
end

def MyFancyControllerExtensionTest < Test::Unit::TestCase
  def setup
    @controller = TestController.new
  end

  ...
end

This helps a lot when you don’t know where to start your tests.

mobile-fu rjs

admin — Thu, 15 Jul 2010 14:21:26 +0000

hm… hm… hm… hm

I’m a bit unsatisfied with mobile-fu for rails. Sure, it’s great in general, but I want to have different templates for mobile rjs and default rjs and i think it’s a bit clumsy to do it like that:

application.html.erb

def mobile?
  return session[:mobile_view]
end

# distinct between mobile and non-mobile js (mobile-fu)
# only supports :template paramter for mobile-enabled js

def render_mobilized_js(options = nil)
  # if we’re not mobile => render like there is no mobile

  unless mobile?
    return render options if options
    return render
  end

  # render mobilized rjs template

  ops = (options || {}).dup

  ops[:template] ||= “#{controller_name}/#{action_name}”
  ops[:template] += “.mobile_js.rjs”

  return render ops
end

but now I’m able to do this

respond_to do |format|
  format.html
  format.js { render_mobilized_js }
end

But in an ideal world i don’t want to call render at all. I want rails or mobile-fu to do it for me:

respond_to do |format|
  format.html
  format.js
  format.mobile_js
end

Not yet possible - and if it would be possible it would break dependencies. Therefore i keep using my method - unless anyone points me a step towards the elegant solution… anyone?

ruby spreadsheet library

vetter — Wed, 05 May 2010 10:07:44 +0000

Thumbs up for http://spreadsheet.rubyforge.org/ A ruby library for accessing .xls files. Really comfortable. Just missing a way to access columns by excel-like captions

sheet.row(0)["AA"]

Maybe i just didn’t find it, but nevertheless you can of course extend String, though

class String
  def to_excel_index
    each_char.collect{ |c| ("A".."Z").to_a.index(c) }.
      inject { |sum, n| sum + (sum + 1) * 25 + n + 1 }
  end
end

and use

sheet.row(0)["AA".to_excel_index]

My article for linux technical review

vetter — Wed, 31 Mar 2010 17:25:18 +0000

A few weeks ago I wrote an article on virtualization security. See here http://www.linuxtechnicalreview.de/Vorschau/%28show%29/Themen/Virtualisierung/Sicherheit-in-virtuellen-Umgebungen

17th dfn cert workshop

vetter — Wed, 31 Mar 2010 17:20:37 +0000

I was speaking on the 17th dfn cert workshop on virtualization security. It was quite cool to speak in front of such a large audience. There was quite a good response. Here is the link to the workshop website: http://www.dfn-cert.de/veranstaltungen/workshop.html

Here is the conference room when i arrived in the morning before it was full.

hping2 for the nokia n900

vetter — Sun, 10 Jan 2010 12:19:01 +0000

I recently played with the “sdk” for my nokia n900. The “sdk” is a cross compilation platform built on scratchbox. The n900 runs maemo, a debian based linux for the arm architecture. I wanted to compile netcat for the phone until i found this, which perfectly runs on the phone. Then i decided to compile hping2 - and you can download my package and install it on your n900. I’ll upload it to the maemo garage, too.

https://garage.maemo.org/projects/hping2/

Webbased Password Managers

vetter — Tue, 08 Sep 2009 11:36:24 +0000

In this post I’ll describe problems that arise when you try to develop a webbased password safe.

Imagine an arbitrary company with lots of employees, each using many passwords for many different authentication purposes. Imagine different employees using different operating systems. To avoid them having bad cleartext passwords on their disk, you would like to have a central and universal password manager running on a server keeping the passwords of different users, each having a strong master password to access all his passwords via his browser. You want the password manager to be as secure as possible, beause you have to keep passwords for company related systems and you want it to be as secure as any existing client-wise password manager, of course.

A naive approach, at first. Any attempt to access passwords has to be encrypted, of course, especially when we send passwords over an (insecure) network. Therefore we have to use SSL and the password manager has to enforce HTTPS. If we are trusting the server (that means: we have to ensure that the server won’t get compromised), we won’t have to encrypt the passwords on the server and we can store them in simple text files. But if the server ever gets compromised, all passwords are lost. To avoid cleartext passwords saved permanently on disk we have to encrypt them like every password safe does. We decrypt them when a user is authorized and wants us to and we store them within the server’s memory, but if someone can access the RAM the passwords are lost, too.

A password safe typically only stores passwords of a single user. In contrast, our webbased password safe stores passwords for the whole enterprise. Therefore, a server-compromise is more critical and imagine employees interested into reading other employee’s private mails, social network accounts and so on (aka insider attacks). We can solve this problem by never keeping a password in cleartext on the server, neither RAM, nor HDD. The encryption has to happen on the client. Therefore, we have to encrypt them on the client (within a browser). The guy compromising the server will get the encrypted files, but he won’t get the clear text passwords easily. Of course, he can bruteforce the master password, use cryptanalytical methods or just stay behind another employee’s neck while he is typing the master password, but every password manager has to deal with that possibility (but we have a central login now) and we can enforce strong master passwords and encryption centerally. This paradigm is related to Host-Proof-Hosting (”Host sensitive data in encrypted form, so that clients can only access and manipulate it by providing a pass-phrase which is never transmitted to the server“).

The encryption and decryption on the client could be done with javascript (ecma-262 and clipperz), but how secure could, for example, an AES javascript-implementation be (not from a cryptanalytical point)? Is it guaranteed that passwords won’t be stored for long time within the client’s RAM, because we have to wait for javascript’s garbage collector? Usual password safes are written in C and they can manipulate memory directly. A javascript implementation is not able to do that. To show that, lets take a look into our memory while executing this with firefox 3.0.6 in a virtual machine running Debian Lenny and using the KVM - virtual machine monitor:

var key = "";

for(var i = 0; i < 3; i++) key += "M";
for(var i = 0; i < 3; i++) key += "1";
for(var i = 0; i < 3; i++) key += "K";
for(var i = 0; i < 3; i++) key += "Y";
for(var i = 0; i < 3; i++) key += "9";

key = "";

Suppose, ‘key’ is a cryptographic key. We concat the key to be sure that we don’t have it as a complete string before we’re using it within the javascript code. We execute it and dump the memory using the kvm monitor mode:

pmemsave 0 134217728 memory.dmp

If we search for the key MMM111KKKYYY999 within memory.dmp we’ll find it. No surprise, javascript uses reference semantics, but the garbage collector doesn’t free the (now) unreferenced string. There is no way we can overwrite the portion of memory ‘key’ was using. There are good reasons to let us not do that, because direct memory manipulation with javascript would be a very bad idea.

After we’ve left the website we dump memory again and this time we won’t find the key. Firefox 3.0.6, Chrome 2.0.172.43, Internet Explorer 6 and Opera 10 all show this behaviour. Therefore, a webbased password manager should force users to leave the page after a certain amount of time and - maybe - the password manager should only work with approved browser versions (versions that show this behaviour), because it is possible other browser (versions) store it even longer. But that will result in less flexibility.

Some huge problems remain, though. The largest: injecting malicious javascript code into the client. The javascript code is responsible for encryption and decryption on the client, but the code is loaded from the server dynamically. A server compromise is therefore still the biggest issue, because an attacker could inject malicious code into all clients and steal all passwords. Therefore, the code itself has to approved in some way. Clipperz, for example, is of course aware of this problem and agrees: “there are no perfect solutions to avoid this problem“.

In a nutshell, a webbased password manager could have different levels of security.

Security only lies within secure transportation (HTTPS) of passwords to the client to avoid sniffing passwords. Cleartext passwords exist on clients and on the server hosting the passwords, both for an (nearly) arbitrary amount of time.
Cleartext passwords only exist on clients, but for an (nearly) arbitrarty amount of time.
Cleartext passwords only exist on clients for a predefined period of time.

Option 3 is the most inflexilible one, because we have to use approved components only (Browser, Javascript implementation, Operating System’s clipboard implementation, Javascript-Code and so on) and whether we decrypt passwords only on the client or not, we have to trust into the server, because we have to trust into the application and if the server is compromised, an attacker could inject malicious code.

Consolidating Servers securely?

vetter — Thu, 20 Aug 2009 18:47:25 +0000

My previous posts showed how virtualization could lower your system’s security potentially. Virtualization introduces higher risks by means of

Management of virtual environments, like Mobility and Identity of Virtual Machines
How Virtual Machines connect to your physical network
Virtualization-Technology specific Issues, like DMA (see IO-Virtualization) and Complexity (see CPU-Virtualization)
Typical Vulnerabilities, like DoS (see KVM-Thrashing), VM-Escape and Privilege Escalation

Therefore, if an enterprise wants to introduce Virtualization into its systems, it has to enforce measures to enhance security aspects of virtualization technologies and to avoid the pitfalls. As a result of my posts and work, these measures have to be taken:

Don’t consolidate Guests with different security-needs on the same Host-Machine.

An intrusion into systems with low security-needs is more likely. After this first step, it would be easier for an Intruder to attack sytems with higher security-needs if these systems are located upon the same VMM. This measure is taken to keep isolation between systems of different needs for security. If you have multiple Demilitarized Zones, keep them physically isolated: don’t consolidate hosts of different DMZs upon the same VMM and don’t try to create virtual DMZs instead of physical ones.

Choose a low-complexity-VMM as a base for your virtual environment

The more complex a VMM, the more likely it’ll contain vulnerabilities. Different Virtualization-Technologies differ very much in complexity as well. Your important systems require low-complexity-VMMs. Such a VMM should be a Bare-Metal VMM. It should use Virtualization-Extensions of modern CPUs or Paravirtualization instead of more complex technologies, like dynamic Binary Rewriting techniques. It should use an IOMMU to avoid DMA-Issues (see Security and IO-Virtualization) and it should focus on Virtualization-Purposes only, because the more you put into the VMM-Layer, the more complex it’ll get. Static allocation of ressources (like RAM) is another way to lower complexity.

Maximize VMM/Host-Security

If an intruder gains access to a VMM, all Guests of this particular VMM have to be considered as compromised. A VMM is an Operating System. Therefore, you have to apply Best-Practices for this OS to protect it from usual attacks (Remove services you don’t need, …) and you have to patch your OS and all applications running upon it. You have to enhance Isolation and lower sharing of ressources.

Lower your VMM’s consolidation-potential

A VMM is a Single Point of Failure. Utilization of your VMM’s Server-Hardware will be much higher, because that is what we want virtualization for: higher utilization. Therefore, we have to prepare for a defect by redundancy, because more systems will be effected by this defect. In addition, to lower the risk of attacks on availability (DoS), we could set a limit for the number of guests a VMM should run, because otherwise the Denial of Service of a single VMM leads to a Denial of Service of an arbitrary number of Systems. If you want to take this measure to the next level, don’t consolidate Guests, which don’t need each other to operate, on the same VMM. Indepent systems are no longer independent in terms of VMM-Availability, if they run on the same VMM. But you have to choose measures appropiate for your purposes, of course.

Don’t lower/remove your already established security measures

Virtual Machines contain the same vulnerabilities like physical machines. Therefore, you have to enforce your existing security measures in virtualized environments as well (patch, harden, monitor them …).

Less People to administer a VMM

A VMM’s admin has privileged access to every guest running upon it. Therefore, a VMM’s admin has to be considered as trustworthy and you have to lower the number of people to administer a VMM. This measure will lower the risk of insider attacks primarily.

Less Mobility of Virtual Machines

Deny arbitrary relocation of virtual machines, because a VMM’s admin has privileged access to every Guest. Moving Guests should only be possible where the admin of the source VMM is the admin of the destination VMM as well - or if the admins belong to the same group. In addition, the destination VMM has to enforce a same set of security-measures as the source VMM.

Define processes for deployment and maintainance of Guests

These processes avoid sporadically used guests, without any associated patch cycle. Every guest has to be registered centerally, to be able to clean them if they get infected by malware. Before you’re using a Roll-Back-Mechanism you have to check for consequences and document such steps (see Management of Virtual Machines - Security Concerns).

In a nutshell and from a management perspective: the more flexibility and consolidation-potential you are willing to loose, the more secure your virtual environments could get. But, flexibility and consolidation-potential is what we want virtualization for. Therefore, our gains of virtualization are up to a point contrary to our system’s security-needs and the steps you have to take depend on your systems and their needs - and to which degree you are willing to loose the benefits of virtualization.