Mohammed Sameer's Online Aggregator

Uwe Hermann - Sun, 21/12/2008 - 6:56pm

Yes, it's that time of the year again... it's almost Christmas, which means that I once again updated my 10 + 100 Creative Commons Christmas Songs blog article I originally wrote in 2005. That's a collection of a lot of freely downloadable, Creative Commons licensed Christmas music.

Some of the older entries in the list are no longer available unfortunately, some only needed a URL update, and I also added more than 30 new songs this year.

This currently makes a total of 256 CC Christmas songs (more will probably be added over the next few days), so head over to the full song list and get those downloads started...

(Photo: Wikipedia. Author: Malene Thyssen. License: GFDL 1.2 / CC-BY-SA 2.5)

Uwe Hermann - Sat, 20/12/2008 - 1:04am

Just FYI, I've updated my Playing Starcraft on Linux using Wine article from a few days ago, adding some more info about:

• Brood War installation.
• Multiplayer LAN games, firewall settings for network gaming.
• Playing Starcraft on netbooks (which works astonishingly well), tested on my One A110 VIA VX800 netbook.

Please read the updated article for details.

Uwe Hermann - Fri, 05/12/2008 - 5:10pm

Here's a quick intro to what I'm hacking on at university. This is a new omnidirectional robot platform we got in the lab. It's controlled via CanOpen-over-EtherCAT (which is a realtime Ethernet protocol "extension", more or less). As we don't want to deal with any of the Windows software that's usually used for such stuff, we're employing the IGH EtherCAT Master (r1549) implementation (GPL/LGPL) on Linux and it works quite nicely.

I hacked together a few shell scripts that invoke the ethercat command line tool with certain parameters to control the motor velocities "by hand", which then soon turned into a "dancing" demo of the robot ;-)

See http://www.youtube.com/watch?v=n_vF4NK26fM for the YouTube video of the dancing bot. It's just a quick (hardcoded) hack for now, there's lots of room for improvements, of course (e.g. detect baselines of random music you throw at it). The demo in the background is the fantastic Masagin by Farbrausch.

I've also hacked up a small Python script to control the robot with a Wiimote (using cwiid on Linux), which also works quite nicely. I further plan to make a small program for controlling it via a 3D mouse or the like in the future...

The longer-term plan for the robot platform is that it'll get a "backbone" and two very nice robot arms for grabbing stuff etc.

Uwe Hermann - Wed, 03/12/2008 - 8:20pm

Here's a quick HOWTO for using Wine to play Starcraft on a Linux machine.

  $ apt-get install wine (as root)
  $ winecfg

The winecfg (graphical) utility will setup some config file defaults in your ~/.wine directory. Click on Graphics and activate Allow DirectX apps to stop the mouse leaving their window. Also, click on Audio (a dialog will pop up, just click OK). This will autodect your soundcard and setup Wine to use it. Under Drives click Add (this will add D:) and change the path to /media/cdrom, so that Wine knows about your CD-ROM drive. Finally click OK to close winecfg and save the settings.

The next step is to insert the Starcraft CD-ROM into the drive and start the installer using Wine:

  $ mount /media/cdrom (as root)
  $ wine /media/cdrom/setup.exe

Follow the instructions in the installer until the Starcraft install is finished (you'll need your CD key number), then exit the installer (don't start playing Starcraft right away).

The next step is to get the latest patch and get rid of the need to insert the CD-ROM every time.

  $ wget http://ftp.blizzard.com/pub/starcraft/patches/PC/SC-116.exe
  $ wine SC-116.exe

After the patch is installed click OK and Starcraft will be started (very annoying). Leave the game again. We'll get rid of the CD-ROM requirement now:

  $ cp /media/cdrom/install.exe ~/.wine/drive_c/Programme/Starcraft/StarCraft.mpq

That's a pretty big file, it may take a while. You might have to change "Programme" in the path (I have the German Starcraft version). That's it. You can now play Starcraft (without needing the CD-ROM) using:

  $ wine ~/.wine/drive_c/Programme/Starcraft/StarCraft.exe

A good thing is, it even works nice and fast with the open-source nv NVIDIA driver (no need to install the proprietary driver).

I noticed one very annoying "bug" with the mouse behaviour at first. The mouse would sometimes just get stuck during the game (which is a total disaster of course, if you're in the middle of a fast-paced game). Left-clicking somewhere would "unstuck" the mouse, but it's still very bad. After many, many hours of reading bugreports and trying various patches I finally found out the root cause for the problem.

It's somehow related to my window manager (IceWM); whenever you move the mouse to the bottom of the Starcraft screen (where the IceWM status bar is, even though it's not on top or even visible, and even though Wine/Starcraft runs in full-screen mode!), something funny happens with X11/IceWM and the mouse gets stuck. I haven't yet found out if/which IceWM option could fix this behavior, but I have a small work-around. Just start Wine directly on a second X11 server with Starcraft (without any window manager being involved):

  $ xinit -e '/usr/bin/wine ~/.wine/drive_c/Programme/Starcraft/StarCraft.exe' -- :1

No patches needed (stock Wine from Debian unstable works fine, that's version 1.0.1 right now). I hope this saves other people some debugging time...

Uwe Hermann - Thu, 27/11/2008 - 12:07am

jhead is a very nice and very powerful command line utility to mess with JPEG headers (esp. EXIF fields).

  $ apt-get install jhead

It can display/extract a great amount of metadata fields from JPEG files and also extract the thumbnails stored in JPEG files (if any). The following will list all known metadata fields from a sample photo:

  $ wget http://farm4.static.flickr.com/3173/3061542361_60acb0904b_o.jpg
  $ jhead *.jpg
  File name    : 3061542361_60acb0904b_o.jpg
  File size    : 1074172 bytes
  File date    : 2008:11:26 23:38:04
  Camera make  : Panasonic
  Camera model : DMC-FZ18
  Date/Time    : 2008:03:05 15:45:52
  Resolution   : 3264 x 2448
  Flash used   : No
  Focal length : 4.6mm  (35mm equivalent: 28mm)
  Exposure time: 0.0100 s  (1/100)
  Aperture     : f/3.6
  ISO equiv.   : 100
  Whitebalance : Auto
  Metering Mode: matrix
  Exposure     : program (auto)
  GPS Latitude : N %:.7fd %;.8fm %;.8fs
  GPS Longitude: E %;.8fd %:.7fm %;.8fs
  GPS Altitude : 174.00m
  Comment      : Aufgenommen auf dem <a href="http://www.froutes.de/TT00000014_Ars_Natura">Kunstweg Ars Natura</a>.
  ======= IPTC data: =======
  Record vers.  : 4
  Headline      : Felsburg auf dem Felsberg
  (C)Notice     : www.froutes.de
  Caption       : Aufgenommen auf dem <a href="http://www.froutes.de/TT00000014_Ars_Natura">Kunstweg Ars Natura</a>.

As you can see there's a huge amount of potentially privacy-sensitive metadata in your typical JPEG as generated by your camera (including camera type, settings, date/time, maybe even GPS coordinates of your location, etc).

You can extract the thumbnail stored in all JPEGs in the current directory with:

  $ jhead -st "&i_t.jpg" *.jpg
  Created: '3061542361_60acb0904b_o.jpg_t.jpg'

Note that the JPEG thumbnail does not necessarily show the same picture as the JPEG itself. Depending on the image manipulation software that was used to create the edited/fixed/cropped JPEG, the thumbnail may still reflect the original JPEG contents (see sample image on the right-hand side). This is a huge potential privacy issue. There have been a number of articles about this some years ago, in case you missed them:

• disLEXia: Hidden data in Document Formats
• disLEXia: EXIF Thumbnail in JPEG images (many sample JPEGs and their differing thumbnails)
• Kevin Cohen: Digital Still Camera Forensics (PDF)

Thus, an important jhead command line to know is the following, which removes all metadata (including any thumbnails) from all JPEG images in the current directory:

  $ jhead -purejpg *.jpg
  Modified: 3061542361_60acb0904b_o.jpg

As you can see the result is that only very basic information can be gathered from the file afterwards:

  $ jhead *.jpg
  File name    : 3061542361_60acb0904b_o.jpg
  File size    : 1052506 bytes
  File date    : 2008:11:26 23:38:04
  Resolution   : 3264 x 2448
  $ jhead -st "&i_t.jpg" *.jpg
  Image contains no thumbnail

I recommend doing this for most photos you make publically available on sites like flickr etc. (unless you have a good reason not to). Finally, see the jhead(1) manpage for lots more options that the tool supports.

Uwe Hermann - Tue, 18/11/2008 - 10:07pm

Today I had to work with a really old svn repository again, which was still in the old bdb format (not in the newer and recommended fsfs one). This caused quite some problems, like, um... you cannot checkout, update, or commit anything.

$ svn co file:///path/to/myrepo
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///path/to/myrepo'
svn: Berkeley DB error for filesystem '/path/to/myrepo/db' while opening environment:
svn: DB_VERSION_MISMATCH: Database environment version mismatch
svn: bdb: Program version 4.6 doesn't match environment version 4.4

A quick search revealed that this is bug #342508, a solution is/was supposedly mentioned in /usr/share/doc/subversion/README.db4.3 (which does no longer exist in the Debian unstable package). Luckily this blogpost has some details.

So, the short HOWTO for upgrading an svn repository of one Berkeley DB version to another one is:

$ cd /path/to/myrepo/db
$ db4.4_checkpoint -1
$ db4.4_recover
$ db4.4_archive
$ svnlook youngest ..
$ db4.6_archive -d

In this case I upgraded from 4.4 to 4.6 (do "apt-get install db4.4-util db4.6-util" if necessary).

While I was at it, I also switched the repository to the fsfs format then:

$ svnadmin dump /path/to/myrepo > myrepo.dump
$ mv /path/to/myrepo /path/to/myrepo.bak
$ svnadmin create --fs-type fsfs /path/to/myrepo
$ svnadmin load /path/to/myrepo < myrepo.dump

Maybe this is helpful for some other people out there.

Uwe Hermann - Mon, 10/11/2008 - 10:23pm

Just FYI, I've recently updated the OpenOCD Debian package in unstable. OpenOCD is a Free Software JTAG utility which currently supports quite a large number of JTAG adapters and various CPUs/targets (many ARM and now also some MIPS ones). It's being used by a number of Free Software related projects such as OpenMoko and many others.

Here's an example of how you usually use the (new) OpenOCD with a cheapo parallel port JTAG device. First, start the OpenOCD server, providing it an interface config file and a target config file (you can copy/adapt them from /usr/lib/openocd/{interface,target}/*.cfg, or use those files directly if they work for your target, of course).

  $ openocd -f parport.cfg -f lpc2148.cfg

Then, in another xterm for example, connect to the now-running OpenOCD telnet server. Here you can now run various commands to probe, control and program the JTAG device(s). Try help for a list of commands. As an example, for flashing a binary onto some LPC2148 eval board you would do something like this:

  $ telnet localhost 4444
  Trying 127.0.0.1...
  Connected to localhost.
  Escape character is '^]'.
  Open On-Chip Debugger
  > reset init
  JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
  srst pulls trst - can not reset into halted mode. Issuing halt after reset.
  target state: halted
  target halted in Thumb state due to debug-request, current mode: Supervisor
  cpsr: 0x800000f3 pc: 0x7fffd2a2
  requesting target halt and executing a soft reset
  target state: halted
  target halted in ARM state due to debug-request, current mode: Supervisor
  cpsr: 0x800000d3 pc: 0x00000000
  > flash write_image /home/foo/program.bin 0
  wrote 1236 byte from file /home/foo/program.bin in 0.533683s (2.261701 kb/s)
  > resume 0

The final resume 0 will start to execute your program on the ARM LPC2148 microcontroller.

Check out the openocd info page (info openocd on the command line) for lots more documentation.

Uwe Hermann - Sat, 01/11/2008 - 3:35pm

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.

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.

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.

Uwe Hermann - Sun, 19/10/2008 - 11:31pm

Fun stuff I just stumbled over: a personal/human airbag from Japan, supposedly meant for elderly people who might fall and injure themselves.

Watch a video of the airbag in action on Youtube (no need for crappy Flash player, you can use youtube-dl for instance). Such a device could be a lot of fun I imagine; make it cheap enough and lots of people will buy it just for fun falling-on-your-back experiments :-)

Uwe Hermann - Sat, 16/08/2008 - 7:39pm

...next time you write such a piece of malware, how about making it do something useful (instead of nefarious) for a change, say, have your botnet zombies become Tor exit nodes? kthxbye.

Uwe Hermann - Thu, 14/08/2008 - 12:55pm

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:

• Pacsec 2004: 0wned by an iPod (PDF)
• 21C3: Hacking with Fire / Feuriges Hacken - Spaß mit Firewire (PDF)
• Cansecwest 2005: Firewire: all your memory are belong to us (PDF)

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:

• pyfw-20041111.tar.gz: Mac OS X Firewire bindings for Python, various demos
• http://c0re.23.nu/c0de/pyfw/: Other versions of the above code
• pyfw_linux.tar.gz: Linux Firewire bindings for Python (can be used with above demo code on Linux)
• ipod-linux-pyfw.tar.bz2: Instructions (+ disk image) on how to turn your iPod into a Firewire attack tool

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.

• Whitepaper: Physical Security Attacks on Windows Vista (PDF)
• Bugtraq Thread about the whitepaper

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.

• 2007: OpenChaos: hacking in physically addressable memory (no extra slides)
• Easterhegg 2008: FireWire Hacking: paper (PDF), slides (PDF)
• More papers here...
• http://0null.net/software/SEAT1394/: tools and libraries for pyhsical memory access via Firewire/DMA: 1394csrtool, liblinear, libphysical, debug-sshkey, dump-memory, remote-ps, show-stack, snarf-sshkey, test-all-pagedirs, dmashell, ...

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:

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

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

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/SP3 successfully with Adam Boileau's tools. 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...

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

Uwe Hermann - Mon, 04/08/2008 - 12:45pm

Have you ever wondered how long it would take to create a 32768 bit RSA key with ssh-keygen? Well, I did.

   $ time ssh-keygen -t rsa -b 32768 -f ~/.ssh/tmp32768 -N foobar -q
   real    244m31.259s
   user    244m15.664s
   sys     0m4.736s

In other words, on my test system (AMD X2 CPU with 1.8 GHz per core) it took ca. 4 hours. This is likely very dependent on how much entropy you can get (and how fast), so take the numbers with a grain of salt. A second key with 32767 bits (one less) took 16 hours, for instance.

The resulting tmp32768 (private key) file is ca. 25 KB big, the tmp32768.pub (public key) file is 5 KB big.

There's likely no noticeable performance hit for ssh or scp AFAICS, as all data transfers are done with a symmetrical session key, not the RSA key itself. Only the initial connection "handshake" will take ca. 40 seconds longer...

And yes, 32768 is the maximum RSA key size you can currently create with OpenSSH, go file a bug report if that's not enough for you ;-) However, as I then noticed, this key will not actually work. When you put it in some authorized_keys file and try to login, the handshake will fail and the server-side will see the following error in /var/log/auth.log:

  sshd[xxxxxx]: error: RSA_public_decrypt failed: error:04067069:lib(4):func(103):reason(105)

I first thought I found an off-by-one error, but the 32767 bit key (one bit less) didn't work either. After looking through the OpenSSH and OpenSSL code as well as the RSA_private_decrypt(3SSL) manpage a bit, I saw that OpenSSH uses the RSA_PKCS1_PADDING parameter. My current theory is thus that some padding is making the key not work. I'm now creating a key with 11 bits less bits than 32768, let's see what happens. For the record, a key with 16384 bits does work just fine.

Anyway, I'll probably report this as "bug" (more a theoretical than a practical problem, though) as ssh-keygen let's you generate RSA keys which will never work in practice...

Uwe Hermann - Sat, 02/08/2008 - 5:40pm

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.

Uwe Hermann - Fri, 25/07/2008 - 11:56am

Yay, finally! After many, many months Miro, a video/audio podcast downloading/viewing application, has entered Debian testing again yesterday. For a very long time one issue after the other kept Miro out of testing, partly serious application bugs, partly autobuilder issues and other stuff. I had almost given up hope, but luckily my 1.2.3-2 upload has now finally entered testing, just in time for the freeze...

Uwe Hermann - Sun, 06/07/2008 - 11:59pm

This year's Underhanded C Contest has been announced. If you haven't yet heard of the contest (which is pretty much the opposite of the International Obfuscated C Code Contest) here's a quick intro:

The Underhanded C Contest is an annual contest to write innocent-looking C code implementing malicious behavior. In this contest you must write C code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.

This year's topic is Leaky Redaction:

Write a short, simple C program that redacts (blocks out) rectangles in an image. The user feeds the program a PPM image and some rectangles, and the output should have those rectangles blocked out.
[...]
Your challenge: write the code so that the redacted data is not really gone. Ideally the image would appear blocked-out, but somehow the redacted blocks can be resurrected.

The deadline for submissions is September 30th, 2008. Winners will get a $100 ThinkGeek gift certificate (plus eternal fame, of course).

In 2005 I took part in this contest together with Daniel Reutter which was really great fun. See underhanded2005.tar for our entry (the topic was "covert fingerprinting" in 2005) and the comments from the judges for our entry (as well as the other entries).

Uwe Hermann - Thu, 26/06/2008 - 4:32pm

Today seems to be Firefox/Iceweasel 3 Bashing Day on Planet Debian, so let me join the fun :)

I agree with most other people that the default Firefox/Iceweasel 3 config is not ideal, so here's what I did to fix it. Some of these items improve performance, some remove annoyances, some remove privacy issues, some remove security issues. Not everything here may be desirable for people other than me.

General

• Disable the bookmarks toolbar via "View / Toolbars / Bookmarks Toolbar", nobody needs that and we save some screen space. Remove all pre-defined bookmarks while we're at it.
• Select "View / Toolbars / Customize".
  • Add the "New Tab" button/icon right after the "Home" button. This is probably the most-used button (for me at least) and it's not available per default...
  • Click "Use Small Icons", there's no reason to waste screen space.
  • Remove the Google search bar (useless).
  • Now move all icons and the URL bar into the menu bar (I'm not kidding). After that you can disable the nagivation toolbar via "View / Toolbars / Navigation Toolbar" and save even more screen space.

Preferences

Select "Edit / Preferences".

Main:

• Select "When Iceweasel starts: Show a blank page".
• Set "Home Page" to whatever you see fit.

Tabs:

• Enable "Always show the tab bar".

Content:

• At the right-hand side of "Enable JavaScript" click "Advanced" and uncheck all checkboxes. JavaScript stuff shouldn't need to do any of those operations.
• Uncheck "Enable Java". Nobody needs this crap and it's a huge security risk.

Privacy:

• Disable "Keep my history for xyz days" completely. Huge privacy risks.
• Disable "Remember what I enter in forms and the search bar". Huge security and privacy risks, almost no gain.
• Disable "Remember what I've downloaded". Huge privacy risks.
• Uncheck "Accept third-party cookies".
• Choose "Keep until: I close Iceweasel".
• Click "Show Cookies" and remove all of them.
• Enable "Always clear my private data when I close Iceweasel". Click "Settings" and check all items. You want to purge everything when closing Iceweasel.

Security:

• On the right-hand side of "Warn me when sites try to install add-ons" click "Exceptions" and remove all exceptions.
• Disable "Tell me if the site I'm visiting is a suspected attack site". Useless crap, possibly a privacy issue.
• Disable "Tell me if the site I'm visiting is a suspected forgery". Useless crap, possibly a privacy issue.
• Disable "Remember passwords for sites". This is a huge security risk, never ever enable it!

Advanced:

• "General" tab:

  • Enable "Warn me when web sites try to redirect or reload the page".
  • Disable "Check my spelling as I type". Useless, annoying crap, which probably even impacts performance.

• "Update" tab:

  • Disable "Automatically check for updates to: Installed Add-ons".
  • Disable "Automatically check for updates to: Search Engines".
  • Select "When updates to Iceweasel are found: Ask me what I want to do".
about:config



Open a new tab, enter "about:config" as URL and hit ENTER. Click the annoying "I'll be careful, I promise!" button. Uncheck "Show this warning next time" while we're at it.

• Set browser.urlbar.matchOnlyTyped = true to disable the new, annoying "AwesomeBar" URL bar feature (which is also a huge privacy risk).
• Browser tabs are way too huge for my taste (thus only very few fit on the screen). Fix it with browser.tabs.tabMinWidth = 60 and browser.tabs.tabMaxWidth = 60 (needs a browser restart). You can even use less than 60 if you don't need any text and an icon per tab is enough for you.
• Disable the annoying, flashing auto-search stuff when you select "Tools / Add-ons / Get Add-ons": Set extentions.getAddons.showPane = false.
• Set bidi.support = 0. You'll probably never need it, so reduce the number of potential bugs and security issues by disabling it.
• Self-signed certificate handling is annoying, so fix it with: browser.ssl_override_behavior = 2 and browser.xul.error_pages.expert_bad_cert = true (thanks Pierre Habouzit).
• Set browser.tabs.closeButtons = 3 in order to prevent accidental closing of tabs (no more Close buttons on each tab, only one global Close button on the right). Yes, CTRL+Shift+T helps in case it still happens.
• Set network.prefetch-next = false to prevent random prefetching of webpages which means wasting CPU cycles and bandwidth, as well as subtle privacy and security issues.
Plugins

None. Don't even think about installing crap like the closed-source Flash player if stability or security are important to you. If you absolutely must watch YouTube videos, I recommend youtube-dl.

Extensions

Use as few as possible. Every extention may have security problems or bugs, and can negatively affect performance etc.

Pretty much the only one I use is NoScript to selectively enable JavaScript for some trusted websites (and disable it for all other sites).

Uwe Hermann - Tue, 24/06/2008 - 1:56pm

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 (private) 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. The user doesn't need any special permissions.
• Create an ssh key for the user: ssh-keygen -t rsa -b 2048. Depending on your paranoia level you can use a key passphrase or not.
• Put the uploadip script (see below) into /home/user.
• Add a cron-job which runs the uploadip script (as user) regularly, e.g. once per minute:
  
  * * * * * user /home/user/uploadip
  

On the publicserver:

• Add a non-root user account (e.g. also named user) just for the purpose of this mechanism. The user doesn't need any special permissions.
• Add the public ssh key (~/.ssh/id_rsa.pub) of user@homeserver to the publicserver's /home/user/.ssh/authorized_keys, so that the homeserver user can login.
• Put the updateip script (see below) into /home/user.

The scripts

Finally, here's the contents of the uploadip and updateip scripts:

uploadip:

  #!/bin/sh
  # Store the IP in a file on the server.
  ssh -x user@publicserver /home/user/updateip

updateip:

  #!/bin/sh
  # Update IP address.
  echo $SSH_CLIENT | cut -d " " -f 1 > /home/user/homeserverip.txt

So to summarize: the homeserver's user simply executes the updateip script 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 (i.e. from your laptop when you're in another, possibly hostile network) in order to connect to your homeserver:

  $ ssh -x user@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 user@publicserver cat /home/user/homeserverip.txt'

Or, to conveniently login to your homeserver:

  alias homeserverlogin='ssh -x user@`ssh -x user@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.
• 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).
• Doesn't require in-depth DNS server config knowledge, or even 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.

Uwe Hermann - Mon, 16/06/2008 - 2:08pm

OK, so I've been hacking on and testing my shiny new One A110 mini-laptop during the last few days and I must say I'm very happy with it. I'll write up some more details later (check the wiki if you're impatient), but today I want to highlight a very nice feature of this laptop (compared to, for instance, the Eee PC): The VIA C7-M ULV CPU in the laptop has VIA Padlock support.

VIA Padlock is a hardware feature in recent VIA CPUs which provides hardware-accelerated AES and SHA-1/SHA-256 support, among other things. This can be used in Linux (with the proper drivers and patches) to improve performance of dm-crypt, OpenSSL (and all programs using it), scp, sha1sum, OpenVPN, etc. etc.

I have written a quite extensive VIA Padlock HOWTO and benchmarks in the A110 wiki (but all of this will work on other systems which have VIA Padlock, too). To summarize, here are the most important benchmarks:

dm-crypt (256bit AES, cbc-essiv:sha256)

Without VIA Padlock support:

$ hdparm -tT /dev/mapper/hdc2_crypt
/dev/mapper/hdc2_crypt:
 Timing cached reads:   448 MB in  2.00 seconds = 223.47 MB/sec
 Timing buffered disk reads:   22 MB in  3.07 seconds =   7.17 MB/sec

With VIA Padlock support:

$ hdparm -tT /dev/mapper/hdc2_crypt
/dev/mapper/hdc2_crypt:
 Timing cached reads:   502 MB in  2.00 seconds = 250.41 MB/sec
 Timing buffered disk reads:   90 MB in  3.07 seconds =  29.36 MB/sec

The native speed of the SSD in the laptop is 31.01 MB/sec, so there is almost no performance penalty when using VIA Padlock.

OpenSSL

OpenSSL speed benchmark, first line without Padlock, second line with Padlock enabled:

$ openssl speed -evp aes-256-cbc [-engine padlock]
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc       9187.18k    10572.28k    11054.32k    11179.36k    11218.02k
aes-256-cbc      47955.92k   150619.73k   325730.73k   458320.11k   520520.79k

ssh/scp

Without VIA Padlock support:

$ scp -c aes256-cbc bigfile.dat localhost:/dev/null
bigfile.dat                100%  159MB   5.9MB/s   00:27

With VIA Padlock support:

$ scp -c aes256-cbc bigfile.dat localhost:/dev/null
bigfile.dat                100%  159MB  14.5MB/s   00:11

OpenVPN

A real speed benchmark is pending (not measurable easily on 100MBit LAN, will try on a slower link), but as OpenVPN uses OpenSSL it should have roughly the same speedup iff you tell OpenVPN to use AES (it uses Blowfish per default).

Also, there's a measurable difference in CPU load while tranferring large files over OpenVPN: 8% CPU load with VIA Padlock (vs. 20% CPU load without VIA Padlock).

sha1sum / phe_sum

phe_sum is a small C program which can be used as drop-in replacement for sha1sum (which doesn't support VIA Padlock yet). Quick benchmark:

sha1sum, without VIA Padlock:

$ time sha1sum bigfile.dat
real    0m6.511s
user    0m5.864s
sys     0m0.412s

phe_sum (with VIA Padlock support):

$ time ./phe_sum bigfile.dat
real    0m1.149s
user    0m0.704s
sys     0m0.424s

All in all VIA Padlock gives you a pretty impressive speedup for many crypto-using applications on Linux, which is especially useful on the A110 mini-laptop (think OpenVPN or scp for mobile usage, and dm-crypt for an encrypted SSD, of course).

Uwe Hermann - Fri, 13/06/2008 - 11:41pm

Just in case you haven't yet watched it: Big Buck Bunny.

Great animated video created mainly using Blender, released under the Creative Commons Attribution 3.0 license.

The soundtrack/score is now also available under a CC license (as is lots of other "raw" material for the movie).

Uwe Hermann - Sat, 31/05/2008 - 12:36pm

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.

Uwe Hermann - Mon, 26/05/2008 - 4:25pm

FYI, if you're not using xdm/kdm/gdm but are instead starting the X11 server manually with startx (which is what I usually do) you might have experienced brokenness in Debian unstable recently:

Fatal server error:
Unrecognized option: /etc/X11/xinit/xserverrc

This is already reported as bug #482425 and #482527 and should hopefully be fixed soon, but in the meantime this patch against /usr/bin/startx should work around the issue:

--- /usr/bin/startx.orig 2008-05-26 18:21:26.000000000 +0200
+++ /usr/bin/startx     2008-05-26 18:21:36.000000000 +0200
@@ -107,9 +107,7 @@
 if [ x"$server" = x ]; then
     # if no server arguments or display either, use rc file instead
     if [ x"$serverargs" = x -a x"$display" = x ]; then
-       server=$defaultserver
        serverargs=$defaultserverargs
-       display=$defaultdisplay
     else
        server=$defaultserver
     fi

Hope that saves some people out there lengthy investigations and hassle.

Uwe Hermann - Wed, 21/05/2008 - 3:11pm

Quick newsworthy item related to coreboot, which I wanted to mention a lot earlier, but then forgot about it: Silicon Mechanics is shipping their Rackform nServ A236 with coreboot pre-installed if so desired by the customer.

From the coreboot News page:

Chris Watson at Silicon Mechanics says: "We will commit to offering coreboot preinstallation on the Rackform nServ A236 with a specific set of hardware and software. In the future, we may expand the program to additional platforms based on customer interest."

The A236 is a nice 1U server with 4 drive bays and a dual Opteron board (Supermicro H8DMR), which is supported in coreboot v2.

Nice to see more and more vendors shipping their products with coreboot pre-installed...

Uwe Hermann - Sat, 17/05/2008 - 5:16pm

You might remember that I wrote a blog entry about my switch to the green electric utility "Lichblick" (Germany) a while ago. I did that purely out of environmental reasons, I didn't want to continue to waste money on polluting and/or dangerous crap such as fossil or nuclear power. Yes, even if that meant a slightly higher price (but I really didn't compare prices much before switching — I was after an environmentally clean solution, not the cheapest solution).

Quick status update: the switch went really nice and easy, no downtimes, no hassle. I've been a happy customer for more than 8 months now.

Today in my snail mail inbox: a letter from Lichtblick that they're going to reduce the price per kWh from 20.25 to 19.99 (Euro) cents starting July 1st and they give you a guarantee that there won't be any price raises before the end of 2009 (more details also here). Now, that's a positive surprise there.

Compare that to 98% of all other energy providers in Germany who have lately increased prices quite a lot for very obscure or non-existant reasons.

Yes, I do realize that the reduced costs are not that dramatic, and Lichtblick is using this as a means to impress people and gain new customers. But I fully support them in doing so, the more people are switching to a green energy provider the better, if you ask me. I encourage everyone to consider switching, either to Lichtblick, or some of their competitors (in Germany) e.g. Greenpeace energy, Elektrizitätswerke Schönau, or Naturstrom AG. There are various alternatives in other countries too, of course.

Uwe Hermann - Sat, 10/05/2008 - 10:59pm

You might have already heard of it — the new Nine Inch Nails album "The Slip" has been released by them under the Creative Commons BY-NC-SA 3.0 US license. Yep, that's right, it's totally legal to download it from the web — and use it for any non-commercial purposes!

It's a bit annoying that they want your email address, though. Nothing that bugmenot.com (or similar) cannot fix, but still. Luckily, the files are now also available from archive.org! This, and the fact that the music is CC-licensed allowed me to "play" one of the songs in my Creative Commons music podcast (RSS), and more will likely follow.

Uwe Hermann - Thu, 01/05/2008 - 1:03am

There are situations where you might want to redirect some audio you're playing on your local computer to another computer's speakers, potentially in a different room, or even anywhere on the Internet.

One of many possibilities to do that is to use the Enlightened Sound Daemon (EsoundD, or esd). It ships with a program called esddsp (apt-get install esound-clients) which can redirect various audio sources.

First, you have to start the esd daemon on a console on the remote host (the one which should output the audio on some speaker, for example 192.168.0.xxx) e.g. like this:

  $ esd -public -nobeeps -tcp

You can do this as regular user (no need to be root) if you have the proper permissions. You also need to allow connections on port 16001 in your firewall settings. Then you can redirect audio to that daemon from another computer. In this example I'm redirecting some music using various players:

  $ esddsp -s 192.168.0.xxx:16001 mpg321 -o esd foo.mp3
  $ esddsp -s 192.168.0.xxx:16001 mplayer -ao esd foo.mp3
  $ esddsp -s 192.168.0.xxx:16001 ogg123 -d esd foo.ogg

This also works fine for videos, in which case you can redirect the audio (but not video):

  $ esddsp -s 192.168.0.xxx:16001 mplayer -ao esd foo.mp4

For the video player Miro, I've recently documented this in the Debian package's README.Debian file. Basically you have to edit ~/.xine/config and enable audio.driver:esd there, then start Miro with

  $ esddsp -s 192.168.0.xxx:16001 miro

Audio will be emitted on the remote host, video remains on your local PC.

Some programs may also support esd natively, in which case esddsp is not required, e.g.

  $ ogg123 -d esd -o host:192.168.0.14:16001 foo.ogg

Uwe Hermann - Tue, 22/04/2008 - 8:09pm

The coreboot project (previously known as LinuxBIOS) is taking part in the Google Summer of Code™ 2008 program. This year, the project has been assigned two slots/students who will work on the following projects:

• All Virtual All The Time (AVATT):

  This project aims to integrate into the coreboot BIOS a payload consisting of a minimalist KVM-aware Linux kernel along with an initrd image that contains the tools needed for creating and starting guest virtual machines installed on top of it. The resulting system could host any x86(or x86-64) OS that can run over KVM (almost any major OS does), and there is a great challenge to make it as small as possible, so that it can fit in a 2MB flash image.

• SCSI booting in coreboot:

  Currently coreboot can not boot from an arbitrary SCSI controller. There are two solutions for the problem: (1) Use Linux and Kexec. This requires to keep the SCSI driver in the flash chip. (2) Use x86emu/vm86/ADLO and the int13 method. This would allow to use the PCI option rom available on all modern SCSI controllers. So we obviously need a solution based on the latter. This could as well be implemented as a Linux program, as an intermediate payload, or as a shared library. At this point of time, I would like to implemente it as a daemon program. The program needs to catch the int13 interrupt vector that the SCSI option rom installs and make it available to arbitrary (firmware/payload) code trying to load something from disk.

This should make for an interesting summer with nice improvements for coreboot.

Uwe Hermann - Mon, 14/04/2008 - 3:32pm

I've bought a new hard drive for my laptop recently, because I finally got fed up with my constantly-full disk. Having to browse around in $HOME looking for stuff which can be safely deleted just because I want to run fetchmail (and that would fill up my disk) just sucks. So, after getting a cheapo 160 GB 2.5" disk (the old one was 80 GB), I had to move all my data to the new disk.

As I didn't want to re-install from scratch I started with dd'ing the whole disk over to the new one (using a live CD and an external USB hard-drive enclosure). This took pretty long, but went fine otherwise.

The new disk then contained all my partitions (hda1-hda3) and also GRUB in the MBR etc., as expected, but was still only 80 GB in size, of course. So the first step is to enlarge the hda3 partition, which is a dm-crypt volume that contains various LVM logical volumes (for /home, /usr, /var, swap, etc.), each of them using the ext3 filesystem (except for the swap volume, of course).

0. Perform backups, boot from a live CD

Important: If you plan to perform any of these steps, make sure you have recent backups! I take no responsibility for any data loss you might experience. You have been warned!

First off, you should boot from a live CD which has all the tools you'll need, including cryptsetup, LVM tools, resize2fs, etc. You can use the nice grml live CD for instance.

1. Resize partition

This sounds scary (and it is!), but the way I enlarged the encrypted hda3 partition was by first deleting it via fdisk. First, issue the "p" command in fdisk, write down the exact start cylinder of hda3. Then delete hda3. Now create a new hda3 partition which starts at exactly the same cylinder as the old hda3 but is larger, i.e. in my case it has ca. 80 GB additional space.

Your data will still be there if you don't screw up, and the partition is bigger now. Using something like gparted will likely not work as expected, as the partition is encrypted!

2. Resize dm-crypt volume

Nothing to be done, it seems dm-crypt automatically adapts and notices that the partition is bigger. Just "open" the encrypted volume using cryptsetup now:

  $ cryptsetup luksOpen /dev/hda3 foo

3. Resize LVM physical volume

Next step is to tell LVM about the new space. We first resize the LVM physical volume on the foo "partition" to use up all newly-available space.

  $ pvresize /dev/mapper/foo

4. Resize LVM logical volume

Now we can pump the new space into any of the logical volumes (or into multiple ones). I only increased one logical volume, my /home:

  $ lvresize -L +74 GB /dev/vg-whole/lv-home

5. Resize ext3 filesystem

The final step is to resize the ext3 filesystem on the lv-home logical volume (after running the obligatory fsck -n). I first used ext2resize, but that failed horribly:

  $ fsck -n /dev/vg-whole/lv-home
  $ ext2resize /dev/vg-whole/lv-home
  error: Invalid argument: seeking to 3258921205760

This seems to be a known bug, ext2resize apparently cannot handle large disks or something, and as I found out a few minutes later it's pretty much deprecated anyway. The better solution is to use resize2fs:

  $ fsck -n /dev/vg-whole/lv-home
  $ resize2fs /dev/vg-whole/lv-home

That's it. We can now reboot the system from disk and enjoy ca. 80 GB of additional hard drive space. Yay!

Uwe Hermann - Sun, 13/04/2008 - 5:31pm

If you want to generate a custom Debian live CD, including only the tools you want (and maybe additional tools you don't find in other live CDs) there's a really simple solution: live-helper.

Creating a basic bootable Debian live CD ISO image in the current directory is as simple as:

  $ lh_config
  $ lh_build

That's it. The result will be a file called binary.iso, which you can either burn on a CD-ROM via

  $ wodim binary.iso

or test in QEMU using a command line like this:

  $ qemu -boot d -cdrom binary.iso

Of course there are many possibilities to customize the generated image to your likings, see the documentation in the Debian wiki, or the lh_config/lh_build manpages.

Please note that live-helper can not only generate CD ISOs, but also bootable DVDs, images for USB thumb drives, or netboot images.

There's also a nice GUI called live-magic which will make the process a bit easier if you don't like doing things on the command line.

Uwe Hermann - Fri, 04/04/2008 - 3:54pm

Just FYI: The student application deadline for this year's Google Summer of Code has been postponsed to Monday, April 7, 2008.

So, if you've been thinking about applying as a student for one of the many, many accepted open source projects (Debian, Linux, NetBSD, subversion, vim, or coreboot — just to name a few) you still have a few days left...

Uwe Hermann - Mon, 25/02/2008 - 2:55pm

Just in case you haven't already read about this... Some researchers from Princeton have published a paper about methods which can be used to attack full-disk-encryption (FDE) schemes.

They have demonstrated that at least BitLocker (Windows Vista), FileVault (MacOS X) and dm-crypt (Linux) are vulnerable to this type of (partly hardware-based) attack scenarios. Quite likely lots of similar other solutions are vulnerable as well.

The main problem is that (contrary to popular belief) RAM does indeed retain its data for a non-trivial amount of time after power is cut (seconds, even minutes or hours if it's cooled down enough), so you can mount some new attacks such as:

• Get physical access to laptop/computer, cut power to it (the hard way), reboot with a special live CD or USB thumb drive and some special software which dumps the RAM contents to an external disk (or sends it via network). As RAM contents are still there a few seconds after the power is cut, this works astonishingly well.
• Get physical access to laptop/computer, open it, remove RAM DIMMs while the computer is running, insert them into your own prepared computer and read the RAM contents using some special software.

Yes, all attacks assume that the attacker has physical access to your PC/RAM, in which case you already have several other problems. Still, the new thing about this is that even full-disk-encryption doesn't help much in some cases. You probably shouldn't depend too much on it (but you shouldn't stop using disk encryption either, of course!).

Full paper: coldboot.pdf. There are also some demo videos and pictures.

More coverage at Boing Boing, Bruce Schneier's weblog, Freedom to Tinker, Slashdot, Heise (German), and many more...

Make sure to read the comments of the various articles for more scenarios and possible ideas for how to prevent such attacks. Some ideas include enabling the BIOS RAM checks (which might explicitly erase RAM contents on reboot; that doesn't help in all cases, though) or using coreboot (previously LinuxBIOS) to erase RAM contents at boot-up and/or shutdown.

It's a highly non-trivial issue, though, there's no easy and complete fix so far. The only sure way is to not have your laptop or PC stolen and to not give attackers physical access to your computers.

Uwe Hermann - Wed, 06/02/2008 - 6:46pm

Public Service Announcement: The LinuxBIOS project, a Free Software project which intends to replace the proprietary BIOS found in most computers these days, has been renamed to coreboot.

The old name has become quite a misnomer in recent years; the name LinuxBIOS created the impression that it's a drop-in BIOS-replacement and that it's using Linux or is Linux-specific in any way. Neither is the case.

• coreboot is not a BIOS in the sense that it provides the legacy BIOS callbacks / interrupt routines. Instead, coreboot is just a small hardware initialization firmware. It does some basic hardware init, then hands over control to one of many possible payloads. This can be a boot loader such as FILO (or GRUB2, which shall ultimately replace FILO) if you want to boot from disk, or Plan 9, or memtest86, or a Linux kernel, or OpenBIOS/OpenFirmware/SmartFirmware, or...
• coreboot is not Linux or Linux-specific. Yes, it can indeed use Linux kernels as payload (i.e., you put the Linux kernel in your flash ROM chip together with coreboot) or boot a Linux kernel indirectly using FILO/GRUB2. But as mentioned above it can also be used (together with the fitting payload) to boot other OSes or systems such as Plan 9, Windows, FreeBSD, and others.

The initial author and project leader of LinuxBIOS/coreboot, Ron Minnich, explains in more detail why the renaming was done in his original announcement on the coreboot mailing list.

Uwe Hermann - Mon, 14/01/2008 - 3:13pm

Hm, time for some nostalgia. The original Sim City game is now GPL'd under the new name Micropolis, and currently being packaged for Debian. There goes my 3.7 minutes of spare time per day...

If you're into such games, the Lincity clone has been around for some time now, too. And, as I found out yesterday, there's also Lincity-NG, which is a more recent clone with better (3D/isometric) graphics, sound, etc.

$ apt-get install lincity-ng

(run it as lincity-ng --sdl if you don't have 3D-accelerated drivers)

Have fun!

Uwe Hermann - Wed, 12/12/2007 - 1:59am

Very nice tool I recently discovered: ink, a small tool using libinklevel, used to query the ink level of your printer (USB or parallel). In my case this is an Epson Stylus DX4200 (which works very nicely and out of the box btw).

Installation:

$ apt-get install ink

Usage:

$ ink -p usb
ink v0.4.1 © 2007 Markus Heinz

EPSON Stylus DX4200

Cyan:                          76%
Magenta:                       76%
Yellow:                        76%
Photoblack:                    72%

Graphical ink level display:

$ apt-get install qink

Another nice tool built upon libinklevel is called qink, which is a QT-based GUI which displays the same information graphically (see screenshot).

A list of printers supported by libinklevel is available.

Uwe Hermann - Mon, 05/11/2007 - 10:24am

Since the "World's First Motherboard Using LinuxBIOS Released" hype at the beginning of this year (which was incorrect btw; it was not the first supported desktop board, there were many others before), LinuxBIOS hasn't been in the news very much. That doesn't mean that there was no progress, however. We've been working hard behind the scenes to improve the LinuxBIOS code, add support for new chipsets and boards, and advance the upcoming next-generation LinuxBIOSv3 version which will brings lots of great improvements in various areas.

Here's a random collection of stuff that happened in the last few months.

New chipsets:

• AMD K8 / NVIDIA MCP55, contributed by Yinghai Lu of AMD
• VIA VT82C686A/B southbridge, contributed by Corey Osgood
• AMD Geode LX / CS5536, contributed by Marc Jones and Jordan Crouse of AMD
• Intel 810 northbridge, contributed by Corey Osgood
• AMD K8 / VIA K8T890 / VT8237R, contributed by Rudolf Marek / Corey Osgood
• AMD K8 / SiS761GX / SiS966(L), contributed by Morgan Tsai of SiS

New mainboards:

• Sun Ultra40, contributed by Ronald G. Minnich (LinuxBIOS project founder)
• K9SD Master-S2R (MS-9185), contributed by Bingxun Shi of MSI
• K9SD Master Series (MS-9282), contributed by Bingxun Shi of MSI
• GIGABYTE GA-M57SLI-S4, contributed by Yinghai Lu of AMD
• NVIDIA l1_2pvv, contributed by Yinghai Lu of AMD
• Supermicro H8DMR, contributed by Yinghai Lu of AMD
• Tyan S2912, contributed by Yinghai Lu of AMD
• Tyan S1846, contributed by myself
• AMD Norwich (AMD Geode LX reference platform), contributed by Marc Jones and Jordan Crouse of AMD
• IGEL Winnet III thin client, contributed by myself
• ASUS A8N-E, contributed by Phillip Degler
• IEI JUKI-511P, contributed by Nikolay Petukhov
• IEI ROCKY-512, contributed by Nikolay Petukhov
• AMD DB800 (a.k.a. Salsa), contributed by Marc Jones and Jordan Crouse of AMD
• ASUS MEW-VM, contributed by Corey Osgood
• Artec Group DBE61, contributed by Marc Jones and Jordan Crouse of AMD
• PC Engines ALIX.1C, contributed by Ronald G. Minnich
• MSI MS-6178, contributed by myself
• MSI MS-7260 (K9N Neo), contributed by myself
• IGEL-316 thin client, contributed by Jürgen Beisert
• AXUS TC320 thin client, contributed by Jürgen Beisert
• GIGABYTE GA-2761GXDK (Churchill), contributed by Morgan Tsai of SiS
• And a bunch of older Intel 440BX based boards, contributed by myself with some help by testers via IRC: ASUS P2B/P2B-F/P3B-F, A-Trend ATC-6220, AZZA PT-6IBD, Biostar M6TBA, Compaq Deskpro EN SFF P600, GIGABYTE GA-6BXC
• ASUS A8V-E SE, contributed by Rudolf Marek

Note that not all of these may be 100% supported, some may still be work in progress with some TODO items left... Check the LinuxBIOS wiki or ask on the mailing list for details.

The future

Most work will probably go into LinuxBIOSv3 in the future, in order to make it suitable for productive use.
Of course, work on new chipsets and boards will continue, too. For example the VIA CN700 chipset (plus Jetway J7F2WE board using it) is being worked on right now, probably also several others I don't know about.

Call for board testers

If you're interesting in trying out LinuxBIOS, please check the list of supported motherboards. If your board is not listed there, but the chipset is already supported we can probably add support for your board relatively easy with some testing help from you.

Please contact us on IRC or preferrably on the mailing list if you want to help get your board supported!

An (incomplete) list of good candidate boards for future support is available in the wiki.

Thanks!

We're very grateful for the many contributors who have helped us with testing and fixing existing code, or who even contributed code for new chipsets and motherboards. Thanks a lot!

Many thanks especially to all hardware vendors who have been supporting us or even actively contributed by submitting code for their chipsets or boards (recently or in the past), including AMD, SiS, VIA, MSI, Tyan, Artec Group, and many others. Your efforts are very appreciated. Thanks!

Uwe Hermann - Sun, 16/09/2007 - 4:28pm

FYI, my new Miro packages (formerly known as Democracy Player) have now reached unstable.

After lots of ugly, ugly trouble with even getting a successful build (boost/python/dbus related, you don't want to know) the packages are back in shape now, with tons of fixed (or no longer reproducible) bugs and lots of upstream impovements and new features.

If you reported a bug against Democracy Player, please try the latest Miro package and check if it still occurs, thanks!

The upgrade should be seamless, your existing config and videos will be migrated from ~/.democracyplayer to ~/.miro automatically upon the first start of Miro.

Some of the new/fixed things in this release include:

• HTTP proxy support (uses the GNOME proxy settings, use gconf-editor to change them).
• Flash videos now play fine (non-jerky) and with sound!
• You can search various video sites (Youtube, Google video, etc.) online, and even save searches as channels.
• You can export your channel list into an OPML file (and also import OPML files, of course). I've been waiting for this for a very long time (it's a good way to backup your channel list, or move it to another machine)...
• Lots and lots of bugfixes and small enhancements, as usual.

Uwe Hermann - Wed, 12/09/2007 - 1:25pm

Since a few days I'm a