Eee PC security or lack thereof

The Eee PC has garnered a lot of press for its small form factor, low weight, and solid-state disk, but it has also made a poor showing with security researchers. RISE Security released a report on the security of the Eee last week, showing that it can be subverted ("rooted") right out of the box from ASUS. Unfortunately, it is even worse than that as, even after updating an Eee using the standard mechanism, the hole is not patched.

The vulnerability identified by RISE is in the Samba daemon (smbd), version 3.0.24, which is installed and runs on stock Eee PCs. The vulnerability, CVE-2007-2446 was identified and patched last May, so the Eee is shipping with a version of Samba known to be vulnerable to an arbitrary code execution flaw for nine months or so. In itself, that is not completely surprising.

When hardware vendors install a distribution—or commercial OS like Windows—they tend to install the latest released version, which is likely to be out of date with respect to security issues. A vendor installing Fedora 8 or Debian etch today will be behind on countless security updates. But, unlike the Samba problem discovered on the Eee, updates do exist in the standard places. If the new user updates their system immediately, there is a fairly small window of vulnerability.

Unfortunately for Eee owners, the modified Xandros distribution that comes with it does not yet have an update for Samba. This leaves all Eee PCs vulnerable to being rooted by anyone on the same network. Since the Eee is meant as a mobile device, it likely spends a lot of its time connected to various public networks, especially wireless networks. The Eee makes an interesting target for attackers because it very well might have authentication information for banks or brokerages as well as other private or confidential files.

Some have seriously downplayed the threat but it is clear they don't understand it:

Sales of the Eee last year was around 300,000 units; large enough to be an attractive target for the malicious. Because there is not an update to close the hole, Eee users have to rely on other means to protect themselves. This eeeuser.com comment thread provides some of the better advice for dealing with the problem. Removing the Samba package seems to be the simplest, but fairly heavy handed, way to avoid the hole—but many folks need a working Samba. There is no way to disable Samba from the Eee GUI which is the way most owners plan to interact with the machine. This whole incident makes it seem like ASUS (and perhaps Xandros) are not terribly interested in the security of the machines that they sell.

There is a larger issue here. When the normal means of getting security patches comes from the same medium that is also the biggest security threat, there will always be windows of vulnerability. Even if hardware vendors diligently update the distribution they install, there is still some shelf-life and shipping time where security updates can be released. Various studies have shown that there may not be enough time to download patches before an unpatched system succumbs to an attack.

It is a difficult problem to solve completely. Any solution must be very straightforward and consistent so that unsophisticated users can be trained to do it as a matter of course. News about security issues needs to get more widespread attention as well, so that those same users know when the procedure needs to be followed. Firewalls and other network protections only go so far if the machine needs to reach out to the internet to pick up its updates.

If distributions provided some kind of blob (tar file, .deb, .rpm, etc.) that contained all of the security updates since the release, users could grab that from a different (presumably patched or not vulnerable) machine, put it on a USB stick or some other removable media and get it to the new machine. A utility provided by the distribution could then process that blob to apply all the relevant patches—all while the vulnerable machine stayed off the net. As the world domination plan continues, threats against Linux will become more commonplace; we need to try and ensure that users, especially the unsophisticated ones, can be secure in their choice of Linux.

Update-notifier is a useful part of the solution.

I like your suggestion of requiring security updates upon first boot.

Of course there would have to be a small button that says "No thanks, I know what I'm doing"
for when the update server is unreachable.

One major part of this problem is that Samba was enabled out of the box - I would have
expected the eee PC to be set up as a pure client, like Ubuntu Desktop is, i.e. absolutely no
open ports for servers.  Of course, if ASUS had simply used Ubuntu with minimal customizations
on top, they would have had updates for free, as with most other non-embedded distros.

It would also be sensible to have a simple firewall installed with a GUI to configure it, to
ensure that Samba could only be used (say) within a home LAN.

Some sort of safe-mode in which no server ports are allowed would be a good idea as well.

However, there also needs to be some awareness on the part of eee PC users that this is a
powerful device that must be security updated - more like a full PC than an appliance, but the
same is true of any device with a web browser, e.g. most mobile phones these days.

Doesn't Ubuntu ship with avahi enabled by default?

I thought most attacks these days were on clients (especially mail and web clients), not
servers?

But that would at least address the "how do you get security updates on first boot"
problem--just get them installed before starting the web browser....

Most people I heard of either:

* removed the preinstalled OS (since they're hardcore geeks) and 
installed Ubuntu/Debian
* removed the preinstalled OS and installed Windows

I'm a *recovering* hardcore geek.

I bought my eee (partly) because it's the first machine I've ever seen that I could buy off
the shelf, retail, and have *everything* 'just work' (on Linux) without having to reinstall or
tweak a thing.

I'd never have run Xandros in a fit before, but having paid for it, I saw no particular reason
to change -- as long as it wasn't broken.  I now realise it always was.

For the moment (until such time as I feel a geekish urge to build Gentoo on it, for instance),
I've disabled Samba.  I might upgrade the package if I find I need to use it.

I had to comment out the lines that start the daemon in usr/sbin/services.sh; removing the
rc.d entries doesn't work.

Just checking before I blow money on an eee: does the hardware have any 
components that require closed-source anything? I'd be annoyed to replace 
the OS with Debian or something like that only to find that, say, the 
wireless stopped working or the video card needed a closed-source kernel 
module (to name the two most likely villains).

Etch definitely won't support wifi and 3D out of the box, it might not even  handle the
ethernet.  Sid will probably support it perfectly in a few months, if it doesn't already.

Ethernet and wireless are Atheros; ASUS/Xandros support 802.11a/g using 'legacy' madwifi
(which taints the kernel with a closed-source glue layer) but a fully GPL port (ath5k) is in
Linus' tree for the 2.6.25 release:

http://lwn.net/Articles/266529/
http://lwn.net/Articles/269241/

Googling indicates people have had mixed results trying ath5k on the eee, but since the
successful reports seem to be more recent (and the driver has seen considerable hacking since
it hit -mm a few months ago), I'd expect it to be fine by now.

There's a bare-bones GPL-only debian 'port' called EeeOS specifically targeting the Eee, but
they too are using madwifi.  Apparently they needed a patch for the atl2 wired Ethernet driver
too, haven't checked why.

*Everything* else in LSPCI is Intel, straight down the line.  Graphics is GMA915; xrandr works
perfectly.

Wow. Excellent response.

I have taken note and will be taking delivery of an eee fairly soon :)

Hm. <http://www.ussg.iu.edu/hypermail/linux/kernel/0802.2/0476...> states that the eee has
an ath5007; <http://madwifi.org/wiki/About/OpenHAL> doesn't list it as supported, and
<http://gentoo-wiki.com/Asus_Eee_PC_701> confirms that it's not exactly functional yet (having
to reboot to turn the wireless off/on is hardly a killer but not very nice either).

Has this changed very recently or something?

I see my initial response wasn't so excellent after all :-(

Sorry.

I guess my googling was insufficiently thorough, or I misread something.  I certainly didn't
think to double-check chipset revision numbers.

On seeing these links, my initial feeling is that I should *help* fill the gap in OpenHAL, but
I don't know the first thing about wifi internals ... by the time I get up to speed (in the
meantime trashing my 100% working toy), someone else will likely have finished the job.

So the real question is, how hardcore a geek do I want to be, today?  Is this a challenge I'm
inexorably called to?

And the answer is ... not much.  I like my eee as it is.  I have no call to hassle LKML with
dmesgs from my tainted kernel :-/

My attitude is, hey, it's not very expensive, and this gives me an excuse 
to learn enough kernel hacking/reverse-engineering fu to help :)

What doesn't help is that the iptables module is not available on the default Eee PC kernel,
so without a firewall the various services ASUS have enabled (samba, portmap, cups, ... ) are
open to the local network.

On a laptop though, it's unlikely that you have a multi-homed network scenario, so surely
"open to the local network" is basically only the alternative to "disabled". So in general
users who don't want services accessible to "the local network" should just switch those
services off altogether.

One thing I don't much care for (including in Red Hat's offerings) is adding a service,
enabling it by default, and then firewalling it so that no-one can use it. This is pointless.
Just disable the service by default, and eliminate whole classes of vulnerabilities at once.

I dropped a note to Asus about the Samba vulnerability on 19th Dec 2007.
 
And mentioned:-
"But I think this type of serious security vulnerability ought to have an official security
release for everyone. Ditto for updates to Firefox and Thunderbird.
I would not want the reputation of the Eee PC to be spoiled due to security problems, and with
Linux it should be easy to get an excellent automatic update process in place."

So far, all I've heard is that the correct department have been informed. Not the speedy
respose I would have liked to see. 

> A vendor installing Fedora 8 or Debian etch today will be behind on
> countless security updates. 

Debian releases regular point releases of it's stable and oldstable release, which incorporate
all previous security updates.

Similarly the Fedora Unity Project produce "re-spins" which are installation media based on
the originals but with the most recent updates included. Very handy for avoiding the need to
do network updates after installation.

  http://fedoraunity.org/re-spins

I'm pretty sure it comes with Firefox 2.0.0.7 as well which is somewhat out of date. No update
in the repos either that I saw.

It seems a shame to suggest this as Microsoft have had the idea first, but  it seems to me the
best answer is for the O/S as installed to have a firewall that is in a locked down mode (with
all incoming connections blocked) until after the first update has been done.  MS have
implemented this in the latest revisions of Windows Server 2003....

Of course Ubuntu's option is not bad either (no open ports out of box and none until you
actually share somthing)  [Though the newest versions softened that with the network discovery
stuff...]

Is updated Samba .deb from Debian/Ubuntu installable on these Xandros systems ? Or we are in
.deb-hell this time ?