You could regard this as another pointless entry to go alongside the webcam. But hey - so what.
I had cause to check the uptime on my slugs a little while ago now that they are largely stable and providing the services I want. After doing so I thought it would be good to be able to check this from a web page and a short search later came across Matthew Trent’s UD daemon. I’ve now made my webcam slug uptime public. Let’s see how high this will get.
Any half decent sysadmin will routinely test the security of his or her own systems. A good, and sensible, sysadmin will follow up those tests with an independent security audit by a professional company - preferably one which is a member of a recognised industry body (such as CREST). Finding the holes in your security mechanisms (and there will be some - probably more than you will be happy about) before the bad guys do is essential if you want to sleep at night (and keep your job).
There are a huge number of security testing tools available for free if you know where to look. Most sysadmins keep a toolbox of their favourites (nmap, nessus, ettercap, dsniff et al.) to hand ready for testing any new build. But it can sometimes be difficult to know just which tool to use, and where to get it. Enter backtack. I first came across this collection of tools as recently as february 2006 and found it an excellent resource. Essentially backtrack is a collection of all the security testing tools you are likely to need packaged into one linux distribution. Think of it as a knoppix for security testing. A complete list of all the tools in the collection can be seen here.
Bactktrack Version 3 has just hit the streets. Get it here.
(Oh, and don’t think that using a toolset like this makes you a pen-tester. It doesn’t. What it might do is make you more security aware, and a better sysadmin.)
On Tuesday 17 June, Craig Wriight, supposedly “Manager of Risk Advisory Services” in an Australian Company called “BDO Kendalls”, posted a rather odd note to Bugtraq and a few other security related lists titled “Hacking Coffee Makers”. In that posting he said that the Jura F90 Coffee maker (which can apparently be networked) was vulnerable to remote attack. His post said that the vulnerabilities allowed the attacker to:
“- Change the preset coffee settings (make weak or strong coffee);
- Change the amount of water per cup (say 300ml for a short black) and make a puddle;
- Break it by engineering settings that are not compatible (and making it require a service);”
but worse
“the software allows a remote attacker to gain access to the Windows XP system it is running on at the level of the user”.
Now I’ve been a subscriber to bugtraq for longer than I care to remember and I’ve seen some odd posts in the past - particularly around the beginning of April, but in June? I initially dismissed this as just one more nut trying to raise his profile in the security community, but since tuesday the story has been picked up by a range of commentators. Some have found the story simply amusing (slashdot - “All Your Coffee Are Belong To Us”), others such as CNET seem to have taken it only slightly more seriously. OK, the bits about attacking the coffee maker itself may be amusing, but there is a serious point here if Wright is correct in his statement that attacking the coffe jug gets you access to the windows system its management software runs on. Certainly Thor of Hammerofgod has taken the post seriously enough to question Wright’s professional judgement in posting details of a vulnerability before alerting the manufacturer.
The point to note is that as more and more consumer devices become networkable (and networked) then the attack surface gets larger and larger. And it is a fairly good bet that the manufacturer of (say) a networked microwave oven is not going to take network security as seriously as would the manufacturer of a router, NAS, or mainframe.
Oh and Wright has done it again today. His latest post to bugtraq is titled “Oral B SmartMonitor Information Disclosure Vulnerability and DoS”. It’s about a “remote exploitation of an information disclosure vulnerability in Oral B’s SmartGuide management system [that] allows attackers to obtain sensitive information.”
That’s right, he’s talking about a toothbrush.
Some people have way too much time on their hands.
I’ve had my attention drawn to Randall Munroe’s take on the openssl coding change problem.
Beautiful.
Ben Laurie wrote about the Debian SSL problem a couple of weeks ago. That particular post has attracted a huge response which is well worth reading if you care about free open source software and/or privacy/security issues (or even if you don’t). The key point to take from the discussion is that about two years ago the Debian development team “fixed” a perceived problem in openssl and in so doing actually introduced a fairly serious vulnerability. The net result of this change was that anyone using Debian or a related distribution such as Ubuntu to generate a cryptographic key based on the “fixed” opensssl libraries actually left themselves open to compromise. To quote from the Debian advisory “the random number generator in Debian’s openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable…….. affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections.”
Fortunately, it seems that GPG keys are not affected (and in any case, my own key was generated some time ago and not on a Debian based system) but this is pretty serious nonetheless and means that a great many people (myself included) have been relying on keys which it turns out are vulnerable to attack. I have now regenerated all the keys I suspect were vulnerable, but that does not leave me feeling very comfortable about past usage.
I don’t want to denigrate the Debian team in any way, but I can’t help but agree with Ben Laurie’s view that the proper place to fix any perceived flaw in an open source product, particularly one as important as a security critical component, is in the upstream package - not in the distribution.
I have written about how I use one of my slugs to backup my internal files via rsync over ssh. Well it turns out I made a pretty silly mistake in my rsync options. I thought I’d been careful in specifying the files I specifically wanted excluded from the backup (ephemeral stuff, thumbnail images, some caches such as my browser cache etc.) but I missed one crucial directory and it bit me - and sent the slug’s load average through the roof.
GNOME 2.22 introduced GVFS, a new network-transparent virtual filesystem layer. GVFS is a userspace virtual file system with backends for protocols like SFTP and FTP. GVFS creates a (hidden) directory called .gvfs in your home directory and uses this as a mount point when you open a connection via SSH, FTP, SMB, WebDAV etc from the “Places -> Connect to Server” menu option. So if you open an SFTP connection to a server called “slug”, it will mount that connection in .gvfs. Try it yourself.
Now guess what I had mounted on my desktop at the time my rsync cron job ran. The slug spent some frantic time copying itself to itself until I noticed that it seemed to be inordinately busy, diagnosed the problem and managed to kill the rsync and clear up the mess.
Sadly it appears that the once useful linuxdoc.org website has been hijacked by one of those awful domain squatters who seem to want to sell mortgages, holidays and houses. I tried today to check out an old “howto” I had bookmarked and was greeted by a completely new site - as below:
At first I thought that they had simply redesigned the site because most of the links appeared to be in place. Unfortunately, none of the old LDP documents appear to be there. I also noticed that all the links are referred to a new site on www.kolmic.com. So, none of my old linuxdoc bookmarks are any use now. RIP friend.
Fortunately, however, the original and best TLDP site is still up and running as is the (similarly named) linuxdocs.org site. So, update your bookmarks and stay away from the hijacker. Such a shame that so many printed references in places like the O’Reilly books are no longer valid.
According to some dubious stats from a web company, this site now ranks at number 4,880,077 (on a scale of usage where Yahoo, Google and YouTube are apparently first second and third). But I shouldn’t really complain. The same stats say that the position is “up 16,958,547 ranks over the last three months”.
Now that is some rise.
A recent email exchange with the friend who originally suggested that I take a look at the NSLU2 got me thinking about the machines we currently take for granted. In his email he outlined that he had consolidated a set of services previously run on a couple of old desktops (a Dell and a Shuttle) onto his slug - thereby making a big saving in power consumption. His slug now runs ssh, DNS, IMAP and SMTP mail and a couple of other services - a typical slug user’s profile. The phrase that got me thinking however, was his statement that “I’m quite amazed that it can do all this within 32MB memory”.
Now, not so long ago, 32 Meg of RAM was considered quite a lot. We seem to have become so used to desktop home machines equipped with multi GHz CPUs, 2 or 3 Gig of RAM and anywhere from 160 Gig to three quarters of a terabyte of disk that we are surprised that an apparently humble 266 MHz, 32 Mb RAM machine can do so much. But why? As recently as 10 years ago I was running a large public facing network on which the main DNS/mail and syslog server was a single processor Sun SPARC5 with only 32Mb of RAM. And I recall only 15 years ago (OK, so I’m old) running a network of ICL DRS 6000s providing full office system functions to over 1200 users. So I dug out the specs of the machines I was running at that time for comparison. It made interesting reading.
The smallest (in capacity terms) machine on my network 15 years ago was a DRS6000 L440 - which had a single 40 MHz CPU, 32 Mb of RAM and 2 x 660 Mb disks. That machine served 30 users. I also had a mixture of DRS6000s with older 25Mhz and 33MHz CPUs but with more RAM and disk store (typically 96 Mb and 4 x 660 Mb disks) each of those would support around a hundred users (the office application was memory not CPU dependent). The really interesting point is the pricing. I found a note with the following on it:
Item — Price (UKP)
DRS6000 L440 40MHz CPU — 15,000
(inc. 1 * 660 Mb disk)
64 Mb memory board — 11,000
32 Mb memory board — 6.550
SCSI daughter board — 800
(to support additional disks)
3 * 660 MB disks — 8,850
16 port asynch controller board — 1,500
ethernet LAN controller board — 2,660
external exabyte tape drive — 4,000
console and keyboard — 500
sundry cables — 200
hardware sub-total — 51,060
to which I had to add
128 user licence for Unix 6, TCP and OSLAN — 11,000
(Thankfully, we had a site licence for the application software…)
So, for just over 62,000 UKP I had a 40 MHz machine with 96Mb of RAM and 2.6 Gig of disk. Not bad.
Oh, I forgot VAT.
I bought myself another slug recently so that I could have one dedicated to internal work and the other used for public facing webs. I wasn’t really comfortable with having my network backup and apt-get mirror on the same beast as a public web. I know from experience that public facing systems are vulnerable and I have to assume that my webcam slug is disposable.
However, it seems that I picked exactly the wrong time to build a new slug because I fell foul of a previously undocumented bug in the new initramfs-tools (version 0.92) in Debian testing. This version generated a ramdisk that made the slug unbootable. This bug was particularly irritating because it only manifested itself at the end of the complete Debian install - i.e at the point when the installer had flashed the new initramfs and rebooted. Because I had been so successful with the earlier slug only weeks before, I thought at first that either I had made a mistake, or, worse, I had bought a problem slug which I could not return having voided the warranty. So I wasted some more time reflashing first with unslung and later with the original Linksys image - just to satify myself that I had a working beast. Then I checked the debian-arm mailing list. A couple of other users reported similar problems and the cuplprit - initramfs-tools - was quickly identified and rapidly fixed (see bug #478236).
When researching the problem, I picked up a useful tip from the mail list on a quick way of backing up a working slug image which is not documented in the how-to section of the slug website. This tip enabled me to take a copy of the image from the known good working slug and flash it to the non-working new slug at the end of (yet another) complete Debian install.
On a working system, do “cat /dev/mtdblock* > backup.img”, and copy that backup image off to a safe place. Use that image with upslug2 to flash to a non-working (or corrupted) slug thus: “upslug2 -i backup.img”.
The problem I encountered is now fixed with the release of 0.92a of initramfs-tools which is now in the Lenny tree.
