Please check the release notes and the feature list for details. Overall more than 139 issues have been fixed since the last 2.x series release. The most notable changes are probably the dropping of xine support upstream (gstreamer is used now for all video/audio on Linux) and the introduction of subtitle support.
I have uploaded a new Miro 3.0 Debian package to unstable recently (which have been a delayed a bit due to Debian server issues), by now it should be available from most mirrors. Let me know if there are any issues...
It's been announced at quite a few places, so you probably already heard about it: Miro 2.0, the new major release of the cross-platform Internet RSS audio/video aggregator and player has been released.
Miro is available for Linux, Windows, and Mac OS X, the new release on Linux now features a "native" GTK+ widgets UI (instead of the Mozilla-based HTML widgets of earlier versions) and supports both a xine, as well as gstreamer renderer (for audio and video).
I won't even attempt to list all the improvements and new features, please check the release notes and the feature list for details. Overall more than 670 issues have been fixed since the last 1.2.x series release.
You can also watch this video (Ogg Theora, 10 MB) for a short introduction in Miro 2.0.
Finally, I have uploaded a new Miro 2.0 Debian package to unstable yesterday, by now it should be available from most mirrors. For Debian we're defaulting to xine at the moment, but please consult README.Debian if you want to switch to the gstreamer backend.
Please test the new release extensively so the few remaining issues (if any) can be ironed out soon...
$ 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-1161.exe $ wine SC-1161.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...
In order to play the Brood War expansion you can follow a similar procedure. Insert the Brood War CD-ROM, then:
$ mount /media/cdrom (as root) $ wine /media/cdrom/setup.exe $ cp /media/cdrom/install.exe ~/.wine/drive_c/Programme/Starcraft/BroodWar.mpq $ wget http://ftp.blizzard.com/pub/broodwar/patches/PC/BW-1161.exe $ wine BW-1161.exe
After you've done that, you can start both Starcraft (classic) and Brood War via:
$ wine ~/.wine/drive_c/Programme/Starcraft/StarCraft.exe
You will be asked in the game whether you want to actually play the Starcraft or Brood War variant.
As of version 1161 for the Starcraft / Brood War patch, there's a new game option which can drastically lower the CPU load while playing Starcraft. First fire up Starcraft and start any game. Then, press F10, select Options / Game speed, and check the "Enable CPU Throttling box". You'll probably need to restart Starcraft afterwards.
Multiplayer LAN games work just fine (didn't try BattleNet that much yet), but if you use a strict firewall rule set as I do (which blocks most ingress as well as egress traffic) you have to open a number of different ports. Here's what I added to my firewall script:
$IPTABLES -A OUTPUT -m state --state NEW -p udp --dport 6111 -j ACCEPT $IPTABLES -A INPUT -m state --state NEW -p udp --dport 6111 -j ACCEPT $IPTABLES -A OUTPUT -m state --state NEW -p udp --dport 6112 -j ACCEPT $IPTABLES -A OUTPUT -m state --state NEW -p tcp --dport 6112 -j ACCEPT # BattleNet
Starcraft works just fine on various netbooks; for instance, I tested it on my One A110 netbook (VIA VX800) with 256 MB of RAM, and the whole .wine directory being on a USB thumb drive (thus slow; but my internal SSD was already full). I bet it'll also work fine on the
Audio works fine, and game speed is quite OK, the only minor "problem" is that you should use an external USB mouse, the touchpad is just too small (and too slow to use) for such a fast-paced game.
The full Wine package (and all dependencies) consume quite a lot of space on the (usually very small) hard drive or SSD of a netbook, but luckily you can get away with only a minimal Wine install for playing Starcraft:
$ apt-get install wine-bin libwine-alsa (as root)
That's sufficient, and a lot smaller than installing the full wine package.
Update 2010-06-23: There's a contributed Hungarian translation now (thanks!)
Update 2009-03-04: Added info about patch 1161 and CPU load reduction.
Update 2008-12-19: Added Starcraft-on-netbooks section.
Update 2008-12-13: Added BroodWar and multiplayer info.
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
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!
Over the years a number of presentations and papers have been released with information about these Firewire issues.
Maximilian Dornseif et. al.
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:
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:
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.
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:
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...
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.
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...
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.
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:
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!).
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.