exim vulnerability

Here’s something I haven’t seen in a while, a remotely exploitable root hole.

Debian and Ubuntu ship exim as their default MTA, so there could potentially be a lot of vulnerable machines out there.

The fixes are detailed here. Both Debian and Ubuntu have since released updated packages that fix (one part of) the vulnerability, so it would be a good idea to do a quick “aptitude dist-upgrade” if you run either of these OSes.

The unstoppable Yamato

There’s been a lull in this blog recently, I’ve had a few draft posts queued up but haven’t quite gotten around to finishing them. So, I thought I’d post a quick capsule review of the new (ish) Space Battleship Yamato : Resurrection movie. This is mostly nicked from a post I made to the “What are you watching…?” thread over on the Eirtakon forum.

sby1

Apparently, this is the first Yamato movie in about 26 years and one of the last things made by the series’ co-creator Yoshinobu Nishizaki before he was killed in a boating accident a few weeks ago. Ironically, after falling overboard from a ship called “Yamato”.

For those who may not know, Nishizaki and Leiji Matsumoto created Space Battleship Yamato in the mid 70s. To say it was a hit would be a huge understatement. The show went on to spawn 2 sequels, 5 (?) feature-length films, a ton of merchandise and a huge cult following outside Japan in the form of Star Blazers, as it was called for the english-dubbed version. Crucially, it inspired a new generation of anime fans who went on to become creators themselves. For a better insight into the whole phenomenon, Corn Pone Flicks have recently produced a fantastic documentary.

sby2

But, back to the film at hand. After Yamato/Star Blazers’ phenomenal success throughout the 70s and into the 80s, at some point Nishizaki and Matsumoto had a falling out, the rights to the show became disputed and several court battles ensued. However, Nishizaki seemed to remain obsessed with the idea of re-making Yamato, for monetary or artistic reasons…or both, sometimes with horrifying results. Things finally came to fruition late last year.

The plot would be familiar to anyone who’s seen either the series or the films – a space-born menace threatens to destroy earth, in this case an oddly purposeful black hole. In the face of the approaching black hole that threatens to gobble up the entire solar system, the citizens of Earth are slowly being evacuated to a friendly planet in gigantic fleets of “emigration ships” that can carry 100s of millions of people. Unfortunately, an alliance of aliens (who look pretty much like humans) aren’t too happy with the prospect of new neighbours and have been ambushing the colony fleets. Which means that the World War II battleship Yamato needs to be pulled out of retirement to guard the emigration ships on their long journey, in order to save mankind. Honestly, you’d think the old crew would throw their hands in the air at this point – it’s about the fifth time this has happened.

Despite the oft-recycled plot, I was very impressed. It’s been in the works, in one form or another, since about 1994. The legal battles may have delayed its completion. But as is sometimes the case with troubled productions, a superior product has been delivered.

sby3

We’ve got gigantic fleets of emigration ships performing slingshot maneuvers around the edge of a black hole, battles with trans-dimensional beings, noble enemies, even nobler deaths and of course the Yamato back on the big screen – one of the most iconic symbols in anime. All this is done in CG that can be a little jarring at times, but certainly not as intrusive as it could have been.

It just goes to show you can’t keep a good series down, even if it takes 26 years.

dwm and swarp

One thing that I really like about dwm is that if you have multiple monitors it treats them somewhat like independent instances of the window manager. So you can keep your mail client open on one monitor and switch between your terminals and web browser on another, and vice-versa.

However this also applies to the mouse pointer, it does not move across when you switch monitors. Of course you may not always want this, but it’s sometimes handy to have the option. I believe that the gottox branch of dwm had this pointer-switching functionality, but dwm-gtx doesn’t seem to be actively maintained these days.

Enter swarp, another tool from the suckless bag of tricks. It’s a simple utility that “warps” the mouse pointer to a given coordinate on your screen.

To get it working with dwm, simply download the tarball, uncompress, compile and install. Like everything else from suckless the dependencies are tiny. Test it out from the command line by specifying different coordinates. Once your happy with the locations that the pointer jumps to, you can add these commands to your dwm config.h to switch from screen to screen:

static const char *warpleft[]  = { "swarp", "100", "500" };
static const char *warpright[]  = { "swarp", "1500", "500" };

Now you need to bind the commands to a key, I use the Windows key as a modifier for a lot of things since it is generally unused:

    { WINKEY,                       XK_w,      spawn,          {.v = warpleft } },
    { WINKEY,                       XK_e,      spawn,          {.v = warpright } },

Because my monitors vaguely face west and east, I chose w & e as the switching keys :)

As usual, compiling, reinstalling and restarting dwm will apply the changes.

Setting up scponly

In the past, if I wanted to create a restricted account for a user, to upload files via scp/sftp for example, I normally setup rbash with a defined set of commands. However, it’s possible to break out of an rbash environment quite easily.

Recently, whilst setting up an account for one of the Eirtakon guys to modify their drupal install, I decided to give scponly a whirl. This is a restricted shell that, as the name implies, only allows access to scp and sftp. It also provides a chroot mode (scponlyc) to lock users into a specified directory hierarchy, which I configured for this particular user.

Installation on Debian is simple:

 aptitude install scponly

To enable the chrooted version of scponly, do:

dpkg-reconfigure -plow scponly

Unzip the chroot setup script and make it executable

cd /usr/share/doc/scponly/setup_chroot
gunzip setup_chroot.sh.gz
chmod 755 setup_chroot.sh

If you are on a 64 bit system, scponly is basically broken out of the box. You need to do a couple of things to make it work, the first is to apply this diff to setup_chroot.sh, it adds /lib/ld-2.7.so to the LDSO_LIST variable.

--- setup_chroot.sh     2010-03-24 18:53:15.000000000 +0000
+++ setup_chroot.sh.busted      2010-03-24 18:52:24.000000000 +0000
@@ -79,7 +79,7 @@
 #
 #      we also need to add some form of ld.so, here are some good guesses.
 #
-LDSO_LIST="/lib/ld-2.7.so /lib/ld.so /libexec/ld-elf.so /libexec/ld-elf.so.1 /usr/libexec/ld.so /lib/ld-linux.so.2 /usr/libexec/ld-elf.so.1"
+LDSO_LIST="/lib/ld.so /libexec/ld-elf.so /libexec/ld-elf.so.1 /usr/libexec/ld.so /lib/ld-linux.so.2 /usr/libexec/ld-elf.so.1"
 for lib in $LDSO_LIST; do
        if [ -f $lib ]; then
                LDSOFOUND=1;

You can now run the setup script

 ./setup_chroot.sh

This creates a chrooted user and sets up the necessary environment.

Now set up /dev/null:

 cd ~scponlyuser
 mkdir dev
 cp -a /dev/null dev/

For a 64 bit system, you need to copy across a few more supporting libraries into the chroot:

 cd ~scponlyuser
 cp -p /lib/libncurses.so.5 lib/
 cp -p /lib/libncurses.so.5 lib/
 cp -p /lib/libdl.so.2 lib/
 cp -p /lib/libc.so.6 lib/
 mkdir lib64
 cp -p /lib64/ld-linux-x86-64.so.2 lib64/

To restrict the user to only the path I want them to see, I set their home directory to /home/scponlyuser//drupal. The // has the effect of dropping them into that particular directory once they get chroot’ed, which is /drupal in the chroot environment.

I also wanted to let them have access to /var/www/eirtakon.com/drupal, but without symlinks or other nonsense. This can be done with the bind option in mount:

 mount -o bind /var/www/eirtakon.com/drupal /home/scponlyuser/drupal

To test it out

 sftp scponlyuser@longcat.spoofedpacket.net

Switching to NSD

Whilst BIND is a nameserver I use nearly every day, it’s somewhat large and unwieldy being a reference implementation of the DNS spec.

Where possible, I always like to split out resolving and authoritative functionality into two seperate pieces of software. Unbound does a great job in the latter role – also from the authors of NSD, NLnetlabs – so I thought I’d give NSD a go on ns.spoofedpacket.net.

This machine serves only handful of zones, so it’s easy enough to migrate. The transition is made even simpler since NSD supports the old bind zonefile format out of the box. I decided to install NSD from source, following the tried and tested method:

 cd /usr/local/src
 wget http://www.nlnetlabs.nl/downloads/nsd/nsd-3.2.4.tar.gz
 tar zxvf nsd-3.2.4.tar.gz
 cd nsd-3.2.4
 ./configure
 make
 make install

The dependencies are very few, it should compile without much fuss on nearly any modern *nix system.

By default, all configuration files and zones go into /etc/nsd. There is also an nsd.conf.sample that you can use as a base config. The config file is extremely simple, for a basic setup you only need to look at the server: and the n-number of zone: sections. In the server: section, I only changed the location of the zone files:

 zonesdir: "/etc/nsd/zones"

At this point, it’s always good practice to organise your zonefiles into directories according to their roles. Here is what I have:

 /etc/nsd/zones/master
 /etc/nsd/zones/slave (nothing here yet)
 /etc/nsd/zones/master/forward
 /etc/nsd/zones/master/reverse
 /etc/nsd/zones/master/reverse/IPv4
 /etc/nsd/zones/master/reverse/IPv6

If you have an old BIND install that you are replacing, it is just a simple matter of copying/moving the existing zonefiles to their new locations. The zones can then be configured in nsd.conf as follows:

# spoofedpacket.net
zone:
        name: "spoofedpacket.net"
        zonefile: "master/forward/spoofedpacket.net.zone"

        notify: 193.1.193.194 NOKEY
        provide-xfr: 193.1.193.194 NOKEY

name and zonefile are pretty self explanatory, just remember that the path to your zonefile is always prefixed with the zonesdir statement from earlier on. notify lists all the nameservers you wish to send DNS notifies to when a zone is updated. provide-xfr controls who can carry out zone transfers (AFXR) from your nameserver. The NOKEY statement tells NSD that no cryptographic keys are required to authenticate the notifies or zone transfers between your nameserver and the secondary nameservers.

Once you’ve finished editing nsd.conf, you must now compile your zonefiles into the binary format that NSD understands. This is one of the main reasons for NSDs speed and low footprint:

 nsdc rebuild
 nsdc reload

Verify that nsd is running and serving zones:

 pgrep -lf nsd

 dig @ns.spoofedpacket.net www.spoofedpacket.net