This and similar horror scenarios for the freedom and privacy of the people are nothing unusual these days.
A more general (and more paranoid) question:
How do we know whether our software or hardware is backdoored/wiretapped? We all know that using a certain OS from Redmond opens a lot of security holes in itself. Add to that all the now-public attempts of agencies and companies ranging from the FBI, NSA, Sony to antivirus-software vendors who install backdoors on your PC, and you've got some very good reasons to never trust any closed-source software again.
This is not a problem for most of us using Free Software and free operating systems (Linux, *BSD, etc.). Theoretically, we can read the source code of almost every single instruction being executed on our hardware, and verify that the software doesn't do any funny things like phoning home, logging keystrokes, opening backdoors and so on.
However, how can we know whether or not our hardware has been backdoored/wiretapped/trojaned (or whatever you want to call it)? Given that almost all devices we own nowadays (PDA, iPod, cell phone, hardware VOIP phone, and all the other gadgets) as well as most parts of our PCs and laptops have some sort of microcontrollers on them, how can we be sure that there is no secret code hidden in there which spies on us or provides hidden backdoors to them (whoever that may be)?
With some devices you can dump the firmware and analyze that, but most parts are probably not easily analyzable by mere mortals. Think network cards, builtin wireless cards, sound cards, bluetooth chips and so on. IMHO, a good first step in the right direction are things like OpenBIOS (Free Software firmware/BIOS) and OpenEZX (Free Software GSM phones). Alas, I think DRM will pose a major threat here in future, as we probably cannot easily replace custom firmware/software anymore if DRM in the worst form becomes reality.
So, how would you go about to ensure that your hardware has not been backdoored? How can we detect such things? How can we defend against such things? How can we remove backdoors if we find any? Do you know of any relevant research, papers, documents, HOWTOs? Any cases you know of where such things happened? Any practical tips or advice?
Yet another thing that has been on my TODO list for quite a while: encrypted USB thumb drives and/or encrypted external USB hard drives.
I have finally tried this over the weekend using loop-AES. This is very useful for securing your USB thumb drive contents in case you lose it or it gets stolen. Also, I use an external USB hard drive for backups (previously unencrypted). This is encryped now, too.
Here's a quick HOWTO:
AES encrypted loop device support" in "
Device Drivers -> Block Devices -> Loopback device support", and recompile the kernel.
loop encryption key scrubbing support" as it seems to promise higher security (can anybody confirm that?).
apt-get install loop-aes-2.6-686(or a similar package) should suffice.
apt-get install loop-aes-utils
shred -n 1 -v /dev/sda3.
-n 25or higher if you want more security and have a few days time to wait for the thing to finish...
losetup -e aes256 -C 3 -S 'seed' /dev/loop0 /dev/sda3.
-C 3means "run hashed password through 3000 iterations of AES-256 before using it for loop encryption. This consumes lots of CPU cycles at loop setup/mount time but not thereafter." (see
losetup(8)). This is supposed to be more secure.
-S 'seed'(replace "
seed" with a secret string like "
g7sN4" or something) should make brute force attacks a bit harder. Don't forget the seed!
mke2fs -j /dev/loop0
losetup -d /dev/loop0
/dev/sda3 /mnt/crypted_sda3 ext3 noauto,loop=/dev/loop0,encryption=AES256,itercountk=3 0 0
mount -o pseed=seed /mnt/crypted_sda3
/mnt/crypted_sda3which will be encrypted automatically.
For a more detailed guide read the Encrypted-Root-Filesystem-HOWTO. A performance comparison of different ciphers is available, but in general I didn't notice too much of a slow-down because of the encryption...
He states very clearly a huge number of (unlawful, illegal, or immoral) things the current US president Bush and/or his administration have done. For example:
A quote of Al Gore, from a small Reuters summary of the speech:
We still have much to learn about the NSA's domestic surveillance. What we do know about this pervasive wiretapping virtually compels the conclusion that the president of the United States has been breaking the law repeatedly and insistently.
Although I'm not very political usually (or at least I don't write too much about it), this is really something I highly recommend listening to. I cannot imagine why a president of a democratic country can still be in charge, after all these things have become publically known...
(via Tim Pritlove)
Bruce Schneier asked for more suggestions, and he received. Plenty.
(via Bruce Schneier)
This is old news by now, but still interesting IMHO. Jonathan Brossard has posted an article on BugTraq which gives a pretty good introduction to the inner workings of the BIOS (with lots of links to more detailed resources) as well as known vulnerabilities of the BIOS password mechanism.
The most interesting part is when he explains that the BIOS doesn't seem to erase its own keyboard buffer before it hands over control to the operating system. Also, current OSes (Linux, Windows, *BSD, etc.) don't seem to clear that buffer either.
This may not sound dangerous, but it actually allows anyone who can read the contents of your RAM, starting from address 0x041e, to view the keyboard buffer contents. And this buffer contains the BIOS password you type in when booting your machine (if you set/use a BIOS password, of course).
This one-liner (executed as root) should let you view your password as plain text:
dd if=/dev/mem bs=512 skip=2 count=1 | hexdump -C | head
(Only every second character belongs to the password, the rest are key scan codes, I think).
Yes, reading this part of the RAM usually requires root privileges in Unix-like OSes, but as the security problem is OS-independant other OSes (e.g. DOS, or older Windows versions) might be directly affected.
But even on more secure OSes this plain-text storage of the BIOS/boot loader passwords might be a problem. Combine this with some Firewire insecurities and attackers with physical access to your machine (e.g. your unattended laptop, while you are on the toilet) might be able to read your BIOS/LILO passwords even though you locked your machine. I haven't yet tried this, but I'm pretty sure it's possible. Please post the results here if you try this.
(via Stefan 'Sec' Zehl)
Update 2006-01-09: It seems that when you use software suspend (swsuspend2) the RAM area can/will also contain your root password! Thanks nelson for reporting.