Category Archives: Meta

About the blog itself

With a single bound it was free!

My book on Security Engineering is now available online for free download here.

I have two main reasons. First, I want to reach the widest possible audience, especially among poor students. Second, I am a pragmatic libertarian on free culture and free software issues; I believe many publishers (especially of music and software) are too defensive of copyright. I don’t expect to lose money by making this book available for free: more people will read it, and those of you who find it useful will hopefully buy a copy. After all, a proper book is half the size and weight of 300-odd sheets of laser-printed paper in a ring binder.

I’d been discussing this with my publishers for a while. They have been persuaded by the experience of authors like David MacKay, who found that putting his excellent book on coding theory online actually helped its sales. So book publishers are now learning that freedom and profit are not really in conflict; how long will it take the music industry?


Light Blue Touchpaper will be inaccessible for around 19 hours due to building maintenance. The server will be powered off at 22:00 UTC, Saturday 15 July and should be restarted at 17:00 UTC, Sunday 16 July. However, potential problems with the server or networking equipment on restoration of power may prevent access to the site until Monday.

Update: 17:30 UTC, Sunday 16 July
The power is on, the electronic locks let me in, network connectivity, DHCP and DNS works and the coffee machine is up and running. So that is the Computer Lab critical infrastructure in operation and LBT is back online.

Update: Tuesday 25 July
There will be another downtime for the Light Blue Touchpaper server on Wednesday 26 July, 7:00–10:00 UTC, due to work on our electricity supply.

Oracle attack on WordPress

This post describes the second of two vulnerabilities I found in WordPress. The first, a XSS vulnerability, was described last week. While the vulnerability discussed here is applicable in fewer cases than the previous one, it is an example of a comparatively rare class, oracle attacks, so I think merits further exposition.

An oracle attack is where an attacker can abuse a facility provided by a system to gain unauthorized access to protected information. The term originates from cryptology, and such attacks still crop up regularly; for example in banking security devices and protocols. The occurrence of an oracle attack in WordPress illustrates the need for a better understanding of cryptography, even by the authors of applications not conventionally considered to be cryptographic software. Also more forgiving primitives and better robustness principles could reduce the risk of future weaknesses.

The vulnerability is a variant of the ‘cache’ shell injection bug reported by rgodm. This is caused by an unfortunate series of design choices by the WordPress team, leading to arbitrary PHP execution. The WordPress cache stores commonly accessed information from the database, such as user profile data, in files for faster retrieval. Despite them being needed only by the server, they are still accessible from the web, which is commonly considered bad practice. To prevent the content being read remotely, the data is placed in .php files, commented out with //. Thus when executed by the web server, in response to a remote query, they return an empty file.

However, putting user controlled data in executable files is inherently a risky choice. If the attacker can escape from the comment then arbitrary PHP can be executed. rgodm’s shell injection bug does this by inserting a newline into the display name. Now all the attacker must do is guess the name of the .php file which stores his cached profile information, and invoke it to run the injected PHP. WordPress puts an index.php in the cache directory to suppress directory indexing, and filenames are generated as MD5(username || DB_PASSWORD) || “.php”, which creates hard to guess name. The original bug report suggested brute forcing DB_PASSWORD, the MySQL authentication password, but the oracle attack described here will succeed even if a strong password is chosen.

Continue reading Oracle attack on WordPress

Anatomy of an XSS exploit

Last week I promised to follow up on a few XSS bugs that I found in WordPress. The vulnerabilities are fixed in WordPress 2.0.3, even though the release notes do not mention their existence. I think there are a number of useful lessons that can be drawn from them, so in this post I will describe some more details.

The goal of a classic XSS exploit is to run arbitrary Javascript, in the context of a another webpage, which retrieves the user’s cookies. With WordPress I will concentrate on the comment management interface. Here, the deletion button has a Javascript onclick event handler to display a confirmation dialog, which includes the comment author’s name. If malicious input can break out of the dialog box text, then when an administrator activates the button, the attacker’s Javascript is run, allowing access to the admin user’s cookies. I found two classes of bugs which allowed me to do this.

Continue reading Anatomy of an XSS exploit

XSS vulnerabilities fixed in WordPress 2.0.3

Users are strongly urged to upgrade their version of WordPress to 2.0.3 (as you will see that we have already!) This release fixes two XSS vulnerabilities that I reported to WordPress on 14 Apr 2006 and 4 May 2006, although they are not mentioned in the release announcement. These are exploitable in the default installation and can readily lead to arbitrary PHP code execution.

I think there a number of interesting lessons to learn from these vulnerabilities, so I plan to post more details in 10 days time (thereby giving users a chance to upgrade). The nature of the problem can probably be deduced from the code changes, so there is limited value in waiting much longer.

I will also discuss a refinement of the ‘cache’ shell injection bug reported by rgodm, which is also fixed by WordPress 2.0.3. The new attack variant I discovered no longer relies on a guessable database password, but only applies when the Subscribe To Comments plugin is also activated. The latest version of the plugin (2.0.4) mitigates this attack, but upgrading WordPress is still recommended.