linux

Google Tech Talks: coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware

coreboot Google Tech Talk 2

Here's a nice opportunity for everyone to learn more about coreboot, a Free Software / Open Source firmware/BIOS for x86 PCs.

Ron Minnich, founder of the LinuxBIOS (now called coreboot) project, Peter Stuge of Stuge Konsult, and Stefan Reinauer of coresystems GmbH have given a presentation for the Google Tech Talks series recently. The topic was (of course) coreboot, its history, goals, features and technical details, surrounding tools and libraries such as flashrom and libpayload, as well as an automated test system for running a hardware test-suite upon every checkin in the coreboot repository.

coreboot Google Tech Talk 1

A video of the talk, aptly named coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware (134 MB), is available from Youtube, get it for instance via:

  $ apt-get install youtube-dl
  $ youtube-dl http://www.youtube.com/watch?v=X72LgcMpM9k

The talk includes various demos of coreboot and various payloads you can use with coreboot. One nice example is the TINT payload, a Tetris-like game for Linux (apt-get install tint for the curious), which has been reworked to be usable as a coreboot payload.

coreboot Google Tech Talk 3

So, yes, you can now put Tetris in your BIOS ROM chip and play it from there (no hard drive required).

Other demos included some cluster nodes with coreboot, and a "normal" x86 desktop board booting coreboot + Linux in a very few seconds (much room left for optimizing there though, if you really want to get into fast booting).

Check out the full talk for more infos, and if you're willing to give it a try (see the list of currently supported boards), contact us on the mailing list or join the #coreboot IRC channel on Freenode.

Physical memory attacks via Firewire/DMA - Part 1: Overview and Mitigation (Update)

Firewire cables

This is part 1 of a series on articles about the Firewire security issues mentioned below.

For many years now, attacks via Firewire / i.LINK / IEEE 1394 have been a known security issue. Basically, if you gain physical access to a PC or laptop which has Firewire ports (or PCMCIA/Cardbus/ExpressCard, more on that later) you can

  • read arbitrary RAM contents from the victim's system,
  • overwrite arbitrary RAM contents with whatever you want,
  • and perform many, many severe attacks based on the two issues above. Examples include grabbing a full RAM dump via Firewire (takes only a few minutes), grabbing ssh-agent keys, grabbing screen contents, modifying screen contents, bypassing login/password screens, and many, many more...

All of this is done by exploiting a "feature" of the Firewire spec (OHCI-1394) (PDF), namely that it allows read/write access to physical memory (via DMA) for external Firewire devices. Worse, as this is DMA, the CPU/OS will not even know what's going on. Even worse, this works regardless of whether you have locked your screen with a password-protected screensaver, or xlock, or vlock, or whatever. As long as the system is running, you're vulnerable.

In this article, I intend to give a fairly complete overview of the available papers published on this issue, tools for testing the attacks, as well as mitigation techniques for various OSes. If I'm missing some important papers or tools, please post a comment!

Papers, Attacks, and Tools

Over the years a number of presentations and papers have been released with information about these Firewire issues.

Maximilian Dornseif et. al.

The first publication that I know of was done by Maximilian Dornseif, Michael Becher, and Christian Klein. They gave a number of talks on various security conferences on this topic:

They also released a number of tools, Firewire libraries for Mac OS X and Linux, as well as small demo scripts which use those libs:

Adam Boileau

In 2006 Adam Boileau (a.k.a. Metlstorm) gave a talk called Hit by a Bus: Physical Access Attacks with Firewire (PDF) at Ruxcon 2006. In 2008 he then released a set of tools:

  • pythonraw1394-1.0.tar.gz: Python bindings for libraw1394 (Linux). Tools: businfo, romtool, 1394memimage
  • winlockpwn: Python script which can circumvent a locked Windows XP screen (an arbitrary password will log you in)
  • bioskbsnarf: Grabs/shows the BIOS keyboard buffer via Firewire (which often contains your BIOS password)

Peter Panholzer

As of early 2008 Peter Panholzer from sec-consult.com published a two-page whitepaper which says they were able to run a winlockpwn-like attack on Windows Vista via Firewire. There's not much information in the PDF unfortunately, and no tools were released, as far as I know.

David R. Piegdon

The most recent toolset and papers I know of are from David R. Piegdon (a.k.a. IosTrace), who gave a number of talks in 2007/2008 about the issue, and also released a toolset called SEAT1394.

I'll go into much more detail on how the tools are used and what they can do in another follow-up article.

Mitigation

There are ways to eliminate or at least mitigate these attack vectors. The simplest and most secure way is to not have any Firewire ports installed (don't put Firewire PCI/PCIe cards in your PC, don't use Firewire PCMCIA/Cardbus/ExpressCard cards). Now, if you have a laptop with built-in Firewire ports, you have a problem, of course. In that case you could still physically destroy the port (by opening the laptop and cutting/desoldering stuff, or by putting glue/epoxy in the port in order to prevent any Firewire cables being attached). These are slightly drastic (but effective!) measures.

Note: Even if you don't have any Firewire ports, you're not automatically safe and secure. If your laptop has a PCMCIA/Cardbus/ExpressCard slot, an attacker can simply insert a PCMCIA Firewire card (for instance) in that slot. Chances are, that your OS will automatically load the driver for that card and also the Firewire drivers you'll need if you want to use the card for attaching Firewire devices. Game over. Your "secure" laptop is now vulnerable...

If you cannot (or don't want to) remove/destroy/disable your Firewire ports, the next best thing is to ensure that nobody except yourself ever gets physical access to your PC/laptop. This is hard to do for a PC, and almost impossible for a laptop, mind you.

Finally, there are some software measures you can use to prevent at least physical DMA access for Firewire devices:

Mitigation: Linux

Pretty much every Linux system with the "old" Firewire drivers loaded (kernel module ohci1394 et. al.) is vulnerable to these issues. Newer kernels now also ship with a new Firewire stack called "juju" (kernel module firewire_ohci et. al.) which may or may not have the same issues (not fully tested by me so far, will report back later).

Per default, all recent kernels, e.g. 2.6.26, are vulnerable, but see below.

Under Linux, simply using a kernel which doesn't have any Firewire support (neither built-in, nor as a module) is the most secure option. If you must have Firewire support you can load the ohci1394 module with the phys_dma=0 parameter to at least disable physical DMA support:

  $ rmmod ohci1394
  $ modprobe ohci1394 phys_dma=0

I have personally tested this on some boxes and I can confirm that it renders the currently published tools useless.

If you don't use Firewire at all, you can simply rmmod ohci1394, and (for a permanent fix) add the following lines in /etc/modprobe.d/blacklist and then (important!) run update-initramfs -u afterwards!

  # Prevent automatic loading of the ohci1394 module.
  blacklist ohci1394
  # Prevent manual loading of the ohci1394 module.
  install ohci1394 false
  # Iff we should ever load the ohci1394 module, force the use of the 'phys_dma=0' option.
  options ohci1394 phys_dma=0

As for the new "juju" Firewire stack, I'm not so sure. A few quick tests showed that the currently available tools don't work with the new stack, but you shouldn't feel too secure! AFAIK the new stack does support (or will support soon) physical DMA for Firewire, so it's probably just a matter of adapting the tools a bit (I'll do some testing/research on this later, as time permits).

Mitigation: Mac OS X

On Mac OS you might also be able to completely remove Firewire support from the kernel (but I don't know if/how that can be done, not sure if you can easily recompile Mac OS kernels, and/or if you even have buildable source code and toolchains for that). However, you can at least remove the Firewire support in the default Mac OS installation by unloading AppleFWOHCI.kext:

  $ sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext

Thanks to a Daniel Reutter for letting me abuse his MacBook via Firewire and for finding the above kextunload command line. We have successfully tested that after unloading AppleFWOHCI.kext the current tools won't work anymore.

The tests were done on a Mac OS X 10.5 (Leopard) with all recent security updates applied. Please leave a comment if you can test other versions of Mac OS X...

Mitigation: Windows

As for Windows, well, I guess you're screwed. While Windows XP does implement sort of "protection" in that it only allows physical DMA access via Firewire to devices which "deserve it", e.g. iPods (or any other Firewire mass storage device, I guess) this can be easily defeated by having your attack PC/laptop pretend to be an iPod (see the romtool Python script by Adam Boileau).

The only remaining option I know of (short of removing/destroying Firewire ports or preventing physical access alltogether) is to disable the Firewire ports/drivers in the device manager (untested by me so far). If you do that, remember to also disable all PCMCIA/Cardbus/ExpressCard controllers, of course (see above).

So far I've tested Windows XP SP2 successfully with Adam Boileau's winlockpwn. Windows XP SP3 doesn't seem to work, though (winlockpwn likely needs tweaking). I haven't yet been able to test Windows 95/98/Vista, if you can verify one of them, please leave a comment.

Mitigation: OpenBSD/FreeBSD/NetBSD/OpenSolaris/...

On OpenBSD you're likely not vulnerable as OpenBSD doesn't have any Firewire drivers at all, as far as I know ;-)

As for FreeBSD, NetBSD, OpenSolaris, and other OSes I don't have any information. I might be able to test one or two of them in the nearer future, but please leave a comment if you have some information about whether they are vulnerable and/or how you can secure your system...

Further Resources

Conclusion

That's it for now. I hope you now have a good overview of these issues and how to protect. I can only urge you to take this problem seriously! Three or four minutes of leaving your laptop unattended are fully sufficient for an attacker to get a full forensic image of all your RAM contents for later analysis. This is at least as critical as the Cold Boot attacks, if not worse.

I will follow-up with more articles about some more interesting details on these Firewire issues, how to use the above tools, and I'll report on some of the stuff I was able to find in RAM dumps gathered via Firewire...

Update 2008-08-15: Added information on how to blacklist the Firewire modules on Linux (for permanent mitigation).
Update 2008-08-16: Added links to further articles. Windows XP SP3 doesn't seem to work with winlockpwn.

Updated DIY Dynamic DNS solution HOWTO

I've just updated my DIY secure pseudo-DDNS setup using ssh article/HOWTO a bit, in order to make it simpler to set up (no more extra scripts required) and a bit more secure (by using command= and no-port-forwarding,no-X11-forwarding,no-agent-forwarding in the /home/user/.ssh/authorized_keys file, for instance).

If you've considered employing such as solution please revisit the article for updated instructions.

DIY secure pseudo-DDNS setup using ssh

Here's a quick HOWTO for setting up your own secure pseudo-dynamic DNS (DDNS) server.

It's not a "real" DDNS service, i.e. you won't be able to use standard DNS tools or protocols to talk to the server, but it covers 98% of all functionality I expect from a service such as DynDNS or similar ones: It tells me the IP address of a certain box which doesn't have a static IP address (e.g. my home-server).

Requirements

You'll need:

  • A Linux box with dynamic IP address (dial-up modem/DSL), I'll call it homeserver from now on. This is the box whose public IP address I want to be able to find out.
  • A public Linux box with static IP address (or known DNS name) where you have a user account and ssh access. I'll call this box publicserver.

Setup

On the homeserver:

  • Add a non-root user account (e.g. user) just for the purpose of this mechanism: adduser user. The user doesn't need any special permissions.
  • Create an ssh key with an empty passphrase for the user: ssh-keygen -t rsa -b 4096. This is required as you'll want to run ssh commands via cronjob later.
  • Add a cronjob which runs a random command such as ls regularly (as user), e.g. once per 10 minutes:

    5,15,25,35,45,55 * * * * user ssh -x user@publicserver ls

    The command to run (e.g. ls) doesn't really matter at all, more on that later.

On the publicserver:

  • Add a non-root user account (e.g. also named user) just for the purpose of this mechanism: adduser user. The user doesn't need any special permissions.
  • Add the public ssh key (/home/user/.ssh/id_rsa.pub) of user@homeserver to the publicserver's /home/user/.ssh/authorized_keys, so that the homeserver user can login on the remote publicserver without password (i.e. non-interactively). We'll also limit which ssh commands this user can run using the command keyword in /home/user/.ssh/authorized_keys file:

    command="echo $SSH_CLIENT | cut -d \" \" -f 1 > /home/user/homeserverip.txt && chmod 644 /home/user/homeserverip.txt",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa AAAAAAAAAA...AAAAAAA user@homeserver

    In the above example AAA...AAA is the public key, command specifies which command should be run if this user "logs in" via ssh, and we use some other options such as no-port-forwarding,no-X11-forwarding,no-agent-forwarding to minimize what this user can do via ssh.

So to summarize: the homeserver's user simply executes the above commands on the remote publicserver, which in turn abuses the $SSH_CLIENT environment variable which contains the public IP the ssh connection was coming from (which is exactly what we're looking for). We store that IP in the homeserverip.txt file, which will always contain the latest-known IP address of the homeserver (because of the cronjob).

Getting the current homeserver IP address

You can now retrieve the current IP address of your homeserver easily from anywhere (e.g. from your laptop when you're in another, possibly hostile network) in order to connect to your homeserver:

  $ ssh -x otheruser@publicserver cat /home/user/homeserverip.txt

To make this a bit more convenient you can add a shell alias (e.g. into ~/.bashrc):

  alias homeserverip='ssh -x otheruser@publicserver cat /home/user/homeserverip.txt'

Or, to conveniently login to your homeserver as johndoe:

  alias homeserverlogin='ssh -x johndoe@`ssh -x otheruser@publicserver cat /home/user/homeserverip.txt`'

Conclusion, advantages

This may not be the most elegant solution, and it has a number of drawbacks when compared to services such as DynDNS, but it's sufficient for me and it also has some advantages:

  • You're not dependent on the DDNS service provider. For instance DynDNS recently changed their policy to only allow one update per 28 days, which totally sucks. They then disabled the service completely until I updated my ddclient config and contacted them, i.e. I wasn't able to connect to my homeserver for quite a while, which also sucks.
  • The ssh-based solution is secure and encrypted, in contrast to some other DDNS services, which only allow unencrypted HTTP-based connections (yes, some do allow https/SSL connections).
  • This solution doesn't require in-depth DNS server config knowledge, neither does it require a DNS server you control. You only need a (non-root) ssh account on a public server (or virtual server).

Personally I'm currently using this mechanism for two things, more might follow:

  • Connect to my homeserver via ssh.
  • Get the homeserver's IP address so I can update my OpenVPN client config file on my laptop (I use my homeserver as OpenVPN server).

So far it works pretty nicely.

Update 2008-06-24: Various fixes and simplifications. SSH key must be password-less. Don't run cronjob once per minute, that's overkill.
Update 2008-07-02: Simplify setup by removing the need for extra scripts. Limit the commands the user can perform via ssh in the authorized_keys file. Make the RSA keys 4096 bits strong.

One A110 mini-laptop with pre-installed Linux for 199.- plus Debian installation HOWTO

One Mini A110 subnotebook

OK, so I've spent my last money on the One Mini A110 subnotebook recently. Yep, yet another ASUS Eee PC clone, but this one has the great benefit of costing only 199.- Euros and has similar specs as the Eee PC 2G Surf (700), I think.

This is really a great little machine as far as I can tell. It's a VIA C7-M ULV 1GHz with 512MB DDR2 RAM and a 2 GB Solid-State-Disk (SSD), 7" screen at supposedly 800x480, VGA out, card reader slot for SD/MMC/MS, 2x USB, wireless, modem, audio. No webcam, no bluetooth.

Yesterday I created a wiki at a110wiki.de (for the A110, but also the A120 from the same vendor, which has a 4 GB SSD), where A110 users can collect information, HOWTOs, photos, etc. There's already quite some content there, especially some early tutorials and photos on the inner workings of the A110.

Today I've installed a stock Debian unstable distro on the SSD with 2.6.25 kernel, and I'm currently checking which parts of the hardware work out of the box, and which need further fixing. There's a a bunch of source code tarballs and patches on the vendor website, but most of it seems to be meant for 2.6.22, we'll see if and/or how much work it'll take to merge all this upstream (if it's not already done)...

My Debian Installation HOWTO is also available from the wiki, of course; I'll add more info and photos during the day.

Now for all interested parties: The vendor of the A110 has (again) announced a special weekend offer (valid until Sunday, June 1, 2008, i.e. tomorrow) where they'll sell the A110 for 199,- Euros again, the regular price will be 229,- Euros after that. So if you're thinking about buying one, now is probably the right time.

Check the wiki for issues which are important to you, some quirks remain at this point (but will probably mostly be figured out sooner or later), e.g. the wifi seems to have issues (the vendor said they'll send a driver update to all affected customers), the RAM is builtin and can't be upgraded, and some other, more or less important issues, depending on what you expect from the laptop.

For real-time communication there's also the #a110 IRC channel on Freenode.

Syndicate content