Recently we came across a little problem where one of our customers had a dedicated mailserver (courier, exim4) but had no ability to change their own passwords.

So I came up with two scripts, one bash (to do the actual password reset) and one php (as a front-end to the bash script). These two scripts are designed to be used in tandem to provide adequate input validation and security.

You can find these two scripts here: chpasswd.sh (backend bash script) and chpasswd.txt (frontend php script).

Please note these are simple scripts, in both the lack of error reporting and lack of styling / CSS however they should be functional and with the use of su’ing to the user and avoidance of a setuid root script they should be secure.

If you implement these you are strongly advised to also implement some anti-bruteforce code or in the very least restrict access to internal use only.

mount.crypt fails to mount the partition because when it calls cryptsetup it fails to pass the keysize parameter so cryptsetup uses the default (256), which is fine if you used a 256 bit encryption key, but unfortunately I’d used a 128-bit encryption key so therefore cryptsetup fails to setup the encrypted volume correctly thus causing the subsequent call to mount to fail.

The Solution
Fortunately I don’t let little things like that stop me from getting things working. Firstly I created a patched libpam-mount package (LP: #367577) that does pass the -s option through to cryptsetup, this then allows mount.crypt to successfully mount the encrypted volume.

However, pam_mount was still not able to mount the volume when I logged in, thankfully it only required a config tweak to match the new options that are now passed to mount.crypt, so my new pam_mount.conf.xml config block now looks like this:-

<volume
    user="kenny"
    fstype="crypt"
    path="/dev/sda3"
    mountpoint="/home/kenny"
    options="cipher=aes,hash=ripemd160,fsk_cipher=aes-128-ecb,fsk_hash=md5,
keyfile=/home/kenny.key"
/>

(Annoyingly hash=ripemd160 has to be passed because cryptsetup defaults to that but mount.crypt defaults to and passes through “plain” unless told otherwise.)

Once this change was made (and the fixed packages installed), pam_mount was once again able to mount my encrypted home directory when I log in.

Notice: Please note in preparing these lirc 0.8.5pre1 packages I’ve dropped a fair few of the Ubuntu specific enhancements to lirc since this is intended as a fix solely for adding support for this device. Debdiffs welcome.

Firstly add my repository key to apt so that the packages authenticate:

$ wget -O - http://packages.kennynet.co.uk/repository.key | sudo apt-key
add -

(note: trailing dash)

Next grab the sources.list entries for my repository so you can download the 0.8.5pre1 packages:

$ sudo wget -O /etc/apt/sources.list.d/kennynet-testing.list
 http://packages.kennynet.co.uk/intrepid-testing.list

Now we’re ready to install the packages as follows:

$ sudo apt-get update
$ sudo apt-get install lirc lirc-modules-source

With these packages installed, you only need the following line in /etc/lircd.conf:-

include "/usr/share/lirc/remotes/imon/lircd.conf.imon-antec-veris"

I’ve also made a custom (somewhat hacky) startup script which’ll launch the required two lircd daemons for the two lirc devices created under /dev.

You can download the script here, just put it in /etc/init.d/: lirc-imon

Now make it executable and set it to run on startup:

$ sudo chmod +x /etc/init.d/lirc-imon
$ sudo update-rc.d -f lirc remove
$ sudo update-rc.d lirc-imon defaults 51

This’ll disable the default lirc init.d script and enable the lirc-imon one that I’ve created.

From then on I’d make sure it’s loaded the new modules / started lirc as follows then test it out using irw:-

$ sudo /etc/init.d/lirc stop
$ sudo modprobe -r lirc_dev lirc_imon
$ sudo /etc/init.d/lirc-imon start
$ irw

Press some buttons, they should now show up.

All works for me, let me know how it goes… there are numerous debug steps at each stage if it doesn’t work but I’ve left these out to try and keep the e-mail relatively short. We can go through those if you still experience problems. Please leave comments if you have any questions.

I’ll package the very latest imonlcd patch for lcdproc and upload that to my testing repositories soon and make another quick post.

Firstly boot off the live CD and once you have your live CD desktop open up a terminal window, we now need access to the system drive on the NAS box which we can acquire as follows:-

$ sudo apt-get install mdadm
$ sudo mdadm --assemble --scan
$ sudo mount /dev/md3 /mnt

Next we need to make sure we’re working on the NAS system drive for all our commands so let’s chroot into it:-

$ sudo chroot /mnt

To reset the root password we need to run:-

 # passwd

To enable SSH (which is already installed) on startup we need to run:-

# update-rc.d ssh defaults 16

Finally we cleanup and reboot the NAS server:-

# exit
$ sudo umount /mnt
$ sudo reboot

Don’t forget to remove/eject the CD when the Ubuntu live CD prompts you to.

Now once the NAS reboots into its native OS (which happens to be Debian) you’ll find you’ll be able to login to the box as root with all the power that comes with it.

We recently restructured our network and changed the ip address thus causing the app to complain the license was invalid, deleting the licensing file caused it to talk with the licensing server again but it was no use the licensing server still held the old ip address which was no longer correct. At this point I sent an e-mail off to their customer support team to get the information changed.

However, I couldn’t resist  taking a quick peek under the hood. To their credit the app is largely open source and readable except for the code that manages the license which is encrypted.  I removed the license file, fired up wireshark which logged the following conversation to their license server (anonymised to protect the guilty):-

GET /XXXXXX.php?license_key=Base64String&host_name=?Base64String&
host_ip=Base64String

Which generated the following reply:-

license-key|host-name|old-ip-address

On the face of it this seems quite easy to attack given it sends the current hostname/ip to the licensing server it’d be a trivial PHP script to send back what we assume the app would want to see:-

$key = base64_decode(urldecode($_GET['license_key']));
$host = base64_decode(urldecode($_GET['host_name']));
$ip = base64_decode(urldecode($_GET['host_ip']));

echo "$key|$host|$ip";

All that remains to do is set the script up on our server, and add an entry into our /etc/hosts file so that the licensing server domain name now points at our server. Once done after removing the license file I hit refresh and surprise surprise the app accepted the license response and things continued as normal.

This is particularly weak scheme since it doesn’t even run over SSL so capturing with wireshark is trivial. The other fundamental problem is that the class which converses with the licensing server is not encrypted so that would represent another point of attack which wouldn’t require setting up a fake licensing server – just hijack the response methods.

To their credit the license key itself is validated using a hash to determine what level of features you have access to but once you’ve bought one key you are then able to apply the methods above to copy the key to as many different locations as you wish.

Any comments identifying the application in question will be removed or censored, this is not an aid to bypassing licensing requirements more a discussion of the security implications of how this particular method was implemented.

This isn’t ideal so the first obvious thing to do is to move the config file out of the web application directory to somewhere else (for example: /etc/webapp.conf). Now when a version of the web app is released you simply just have to untar the web app tarball into the correct place and everything will just work without any post-install manual tweaking.

The problem with this approach is that it doesn’t work for multi-developer environments where a developer might need to tweak the config file for a new feature they’re testing, but the web app is now looking at the /etc/webapp.conf file no matter what developer it is.

The solution I then came up with was another config file, say called .dev-config.inc.php which is (optionally) kept in the same directory as the web app but excluded from your version control software so it’s never checked in. Then you simple change the web app to check for this file and if it doesn’t exist load the main config file so now a developer can create a config file for just their tree. For example:-

if(file_exists(dirname(__FILE__)."/.dev-config.inc.php")) {
    require_once(dirname(__FILE__)."/.dev-config.inc.php);
} else {
    require("/etc/webapp.conf");
}

Now once we have this setup everything works and developers can change the config files if they need too (e.g. database dsn’s) and the live system can be deployed by simply untar’ing a tarball.

The next thing I noticed was if I need to add a new config file option I need to add it in all the config files, even if it’s just a system config option that won’t change no matter what environment it’s in. This is a bit of chore given I’m just a lazy developer…

So the next change I make to the config file system is to reinstate the config.inc.php in the web app directory with one key difference, it now has the following design pattern and it is responsible for including our main config file:-

if(file_exists(dirname(__FILE__)."/.dev-config.inc.php")) {
    require_once(dirname(__FILE__)."/.dev-config.inc.php);
} else {
    require("/etc/webapp.conf");
}

$config = array(
    "A_CONFIG_OPTION"=>TRUE,
    "IS_THIS_OVERKILL"=>"MAYBE"
);

foreach($config as $const=>$value)
    if(!defined($const))
        DEFINE($const, $value);

Now this config file will first load our main web app config file (either /etc/webapp.conf or .dev-config.inc.php) and fill in all the missing (default/system) config options that weren’t needed to be changed in the per-environment config settings. Should that need change, simply just define them and this config file will not set them.

Questions
1. Is this over the top?
2. How does everyone else handle config files?
3. Do their methods solve the issues presented above?

Dead Space with Arrow Keys

Having received Dead Space for my Birthday I was disappointed to find that there was no way to use the arrow keys to play especially since I’m left handed and that is far more natural to me.

However, not being one to give up at the first hurdle Google lead me this page which gives instructions for playing Dead Space with arrow keys using GlovePIE to remap the keys as you press them. It’s a good workaround but it’s simply not ideal.

The file responsible for storing your key mappings is controls.rmp located under “C:\Documents and Settings\<your username>\Local Settings\Application Data\Electronic Arts\Dead Space”, so I began examing this file, how it changed depending what the keys were set to and after an hour or two of playing about I discovered not only the offsets storing the Up/Down/Left/Right key mappings but also the correct values for the arrow keys – AND THEY WORK.

To make these changes for yourself you’ll need a hex editor like XVI32, set the following values at the following offsets in the controls.rmp file (OFFSET:VALUE):-

5C: CB
AC: D0
14C: C8
23C: CD

Now save the file and load up Dead Space, you should find you’re now able to use the arrow keys to move around. Alternatively if that’s too much like hard work you can download my pre-modified controls.rmp file below which is set to use the arrow keys – simply customise the other keys how you would like.

Download: controls.rmp.

Update:
If you’d like to use the Enter/Return key as your reload key, make the following change using XVI32:-

E8: 1C

The problem is they seem to be exclusively targeting wikipedia with this block since the image is easily available from other locations not to mention peoples’ homes.

The result of the block is that due most of UK’s traffic going via the Cleanfeed content blocking system wikipedia has been forced to prevent editing articles to UK contributors because they now effectively share a few IP addresses and do not pass on the real IP address as most proxies should.

The other problem is that they have only blocked the article text and not the actual image which is still accessible from wikipedia’s servers. Infact, had they blocked the actual image to start with the editing problem may never have existed. It’s still possible to view the article text without resorting to technology like tor by using the https:// version of the site instead which ofcourse cannot be transparently filtered. The irony here is that that site renders the full article + the actual image since the actual image hasn’t been blocked.

Far more people have now seen this image on the wikipedia page than would have if this block was never attempted, this block has attracted alot of media attention causing the views to that wikipedia page to sky rocket in the past 24-48 hours.

All in all I don’t think they’ve accomplished a great deal besides drawing attention to the very image they tried to prevent people seeing by raising the profile of that image.

Update: It appears that the image on Amazon (linked above) has now been removed.

Update 2: The IWF have now decided to remove this page from their block list:-

Following representations from Wikipedia, IWF invoked its Appeals Procedure and has given careful consideration to the issues involved in this case. The procedure is now complete and has confirmed that the image in question is potentially in breach of the Protection of Children Act 1978. However, the IWF Board has today (9 December 2008) considered these findings and the contextual issues involved in this specific case and, in light of the length of time the image has existed and its wide availability, the decision has been taken to remove this webpage from our list.

IWF’s overriding objective is to minimise the availability of indecent images of children on the internet, however, on this occasion our efforts have had the opposite effect. We regret the unintended consequences for Wikipedia and its users. Wikipedia have been informed of the outcome of this procedure and IWF Board’s subsequent decision.

- http://www.iwf.org.uk/media/news.251.htm

I suppose that’s one way to backtrack without entirely admitting you were wrong in the first place, may they carefully consider their blocks in the future lest they repeat the same mistake.

Unfortunately after some simple testing it seems that cdr_mysql in the asterisk-mysql package has not been compiled to log this important ID.Fortunately we can fix this ourselves using the Ubuntu packaging tools. Firstly we need to install the packages needed to edit the package:-

sudo apt-get install devscripts debhelper fakeroot pbuilder dpatch

Next we should download the source package:-

apt-get source asterisk-mysql

Now we can set about editing the package, a quick look in debian/patches tells us that this package uses dpatch to maintain its patches – so we should too:-

cd asterisk-addons-1.4.5/
dpatch-edit-patch loguniqueid

This will drop us into a sub-shell where we can make our code changes for dpatch to record for us in a patch file. All we need to do is edit the file cdr_addon_mysql.c and at around line 52 near the #define DATE_FORMAT line we should add:-

#define MYSQL_LOGUNIQUEID 1

Save the file and quit out of the sub-shell created by dpatch, dpatch will now create our patch file under debian/patches/. All that’s left for us to do is edit debian/patches/00list and insert our new patch file into the list of patch files, I put mine first so the 00list file now looks like this:-

loguniqueid.dpatch
nomarch.dpatch
include_asterisk

With that done we should bump the changelog to reflect our changes:-

dch -i

Add a description after the top blank * indent like “Added logging of uniqueid”, also, it’s advisable to append ~uniqueid1 (or anything you like really, the ~ is important) so that our package doesn’t conflict with any new package versions Ubuntu might release in future (Make sure that the Ubuntu codename still says “hardy” and not “intrepid” or indeed “jaunty” too). Save the changelog.

We are now ready to build our new package:-

debuild -S -uc -us

If all went well our new dsc file has been created in the parent directory, so all that remains is to get pbuilder building the package. If you’ve never used pbuilder before you need to run:-

sudo pbuilder create

If you have run pbuilder before you should check everything is up to date by running:-

sudo pbuilder update

With pbuilder up to date, let’s build our new package:-

sudo pbuilder build ../asterisk-addons_1.4.5~uniqueid1.dsc

After a bit of compiling if all was successful pbuilder will report it has successfully built the package, so let’s install it:-

sudo dpkg -i /var/cache/pbuilder/result/asterisk-mysql*.deb

Once the package is installed all that remains is to restart asterisk to pickup the new module:-

sudo asterisk -rx 'restart when convenient'

Now test your cdr_mysql logging again, you should find the uniqueid is being logged.

Unfortunately PDO does not support nested transactions although PostgreSQL and MySQL do. I decided to extend the PDO class to support nested transactions while also using PDO to keep track of the first transaction. I came up with the following class (released under the GNU General Public License, Version 3):-

class MyPDO extends PDO {
    // Database drivers that support SAVEPOINTs.
    protected static $savepointTransactions = array("pgsql", "mysql");

    // The current transaction level.
    protected $transLevel = 0;

    protected function nestable() {
        return in_array($this->getAttribute(PDO::ATTR_DRIVER_NAME),
                        self::$savepointTransactions);
    }

    public function beginTransaction() {
        if(!$this->nestable() || $this->transLevel == 0) {
            parent::beginTransaction();
        } else {
            $this->exec("SAVEPOINT LEVEL{$this->transLevel}");
        }

        $this->transLevel++;
    }

    public function commit() {
        $this->transLevel--;

        if(!$this->nestable() || $this->transLevel == 0) {
            parent::commit();
        } else {
            $this->exec("RELEASE SAVEPOINT LEVEL{$this->transLevel}");
        }
    }

    public function rollBack() {
        $this->transLevel--;

        if(!$this->nestable() || $this->transLevel == 0) {
            parent::rollBack();
        } else {
            $this->exec("ROLLBACK TO SAVEPOINT LEVEL{$this->transLevel}");
        }
    }
}

This code will only attempt to use the SAVEPOINT code if you’re using a database driver that supports it (it should probably version check the database server) this then means that in your code you can do things like:-

$pdo = new MyPDO(DB_DSN, DB_USER, DB_PASS);
$pdo->beginTransaction();
try {
    $pdo->exec(...);
    $pdo->exec(...);

    $pdo->beginTransaction();
    try {
        $pdo->exec(...);
        $pdo->exec(...);
        $pdo->exec(...);
        $pdo->commit();
    } catch(PDOException $e) {
        // If this statement fails, rollback...
        // NOTE: This will only rollback statements made in the
        //       inner try { block and not the outer one.
        $pdo->rollBack();
    }

    $pdo->commit();
} catch (PDOException $e) {
    $pdo->rollBack();
}

NB: I’ve tweaked the code slightly when transferring it to my blog and I haven’t tested it, so there could be some minor errors – please leave comments if you spot any. Thanks!