tags: all,

apache, apachecon, apacheweek, bryce, cve, fedora, fudcon, geocaching, gps, ha, jabber, metrics, microsoft, nashville, north carolina, oscon, red hat summit, security, trips

CVSS v2 Base Score 6.5 (AV:N/AC:L/Au:S/C:P/I:P/A:P)

This is really a moderate severity flaw because you need a remote attacker who has the ability to start/stop/control ZoneMinder, and you really should protect your ZoneMinder installation so you don't allow arbitrary people to control your security system. (Although I think at least one distributor package of ZoneMinder doesn't protect it by default, and you can find a few unprotected ZoneMinder consoles using a web search).

I discovered this because when we went on holiday early in April I forgot to turn down the heating in the house. Our heating system is controlled by computer and you can change the settings locally by talking to a Jabber heating bot (Figure 1). But remotely over the internet it's pretty locked down and the only thing we can access is the installation of ZoneMinder. So without remote shell access, and with an hour to spare at Heathrow waiting for the connecting flight to Phoenix, I figured the easiest way to correct the temperature was to find a security flaw in ZoneMinder and exploit it. The fallback plan was to explain to our house-minder how to change it locally, but that didn't seem as much fun.

So I downloaded ZoneMinder and took a look at the source. ZoneMinder is a mixture of C and PHP, and a few years ago I found a buffer overflow in one of the C CGI scripts, but as I use Red Hat Enterprise Linux exploiting any new buffer overflow with my ZoneMinder compiled as PIE definately wouldn't be feasible with just an hours work. My PHP and Apache were up to date too. So I focussed on the PHP scripts.

A quick grep of the PHP scripts packaged with ZoneMinder found a few cases where the arguments passed to PHP exec() were not escaped. One of them was really straightforward to exploit, and with a carefully crafted URL (and if you have authorization to a ZoneMinder installation) you can run arbitrary shell code as the Apache httpd user. So with the help of an inserted semicolon and one reverse shell I had the ability to remotely turn down the heating, and was happy.

I notified the ZoneMinder author and the various vendors shortly after and updates were released today (a patch is also available)

Figure 1: Local heating control

Between releases there are lots of changes made to improve security and I've not listed everything; just a high-level overview of the things I think are most interesting that help mitigate security risk. We could go into much more detail, breaking out the number of daemons covered by the SELinux default policy, the number of binaries compiled PIE, and so on.

	Fedora Core						Fedora		Red Hat Enterprise Linux
	1	2	3	4	5	6	7	8	3	4	5
	2003Nov	2004May	2004Nov	2005Jun	2006Mar	2006Oct	2007May	2007Nov	2003Oct	2005Feb	2007Mar
Firewall by default	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
Signed updates required by default	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
NX emulation using segment limits by default	Y	Y	Y	Y	Y	Y	Y	Y	Y2	Y	Y
Support for Position Independent Executables (PIE)	Y	Y	Y	Y	Y	Y	Y	Y	Y2	Y	Y
Address Randomization (ASLR) for Stack/mmap by default3	Y	Y	Y	Y	Y	Y	Y	Y	Y2	Y	Y
ASLR for vDSO (if vDSO enabled)3	no vDSO	Y	Y	Y	Y	Y	Y	Y	no vDSO	Y	Y
Restricted access to kernel memory by default		Y	Y	Y	Y	Y	Y	Y		Y	Y
NX for supported processors/kernels by default		Y1	Y	Y	Y	Y	Y	Y	Y2	Y	Y
Support for SELinux		Y	Y	Y	Y	Y	Y	Y		Y	Y
SELinux enabled with targeted policy by default			Y	Y	Y	Y	Y	Y		Y	Y
glibc heap/memory checks by default			Y	Y	Y	Y	Y	Y		Y	Y
Support for FORTIFY_SOURCE, used on selected packages			Y	Y	Y	Y	Y	Y		Y	Y
All packages compiled using FORTIFY_SOURCE				Y	Y	Y	Y	Y			Y
Support for ELF Data Hardening				Y	Y	Y	Y	Y		Y	Y
All packages compiled with stack smashing protection					Y	Y	Y	Y			Y
SELinux Executable Memory Protection						Y	Y	Y			Y
glibc pointer encryption by default						Y	Y	Y			Y
FORTIFY_SOURCE extensions including C++ coverage								Y

¹ Since June 2004, ² Since September 2004, ³ Selected Architectures

So in two days I've scanned just under 2000 pages; some of it into nice fully-searchable PDF files, and some (the stuff I know I want to be able to see in 10+ years time) in jpeg. I've now got an overheated shredder and little shredded bits of paper everywhere.

Although the scanner doesn't work out-of-the-box with current Linux distributions, it just needs a single line adding to a configuration file and then works perfectly with Red Hat Enterprise Linux (I tried RHEL 5 Client as well as Fedora 7). I've sent it to the maintainer so hopefully future updates to Sane will be able to handle the scanner without any editing.

So if you've got a Fujitsu ScanSnap S510 scanner (I keep typing SnapScan for some reason), and you've got sane-backends installed then the following will get it up and running:

# echo "usb 0x04c5 0x1155" >> /etc/sane.d/fujitsu.conf

# scanadf --device fujitsu:libusb:005:004 --source "ADF Duplex" --mode Color -v --resolution 150 --y-resolution 150

The full details broken out by CVE name are available as at GOLD (fixed) or latest status (updated daily)

This issue is technically interesting as the off-by-one only lets you write one pointer to the space immediately after a stack buffer. So the ability to exploit this issue is totally dependent on the stack layout for a particular compiled version of mod_rewrite. If the compiler used has added padding to the stack immediately after the buffer being overwritten, this issue can not be exploited, and Apache httpd will continue operating normally. Many older (up to a year or so ago) versions of gcc pad stack buffers on most architectures.

The Red Hat Security Response Team analysed Red Hat Enterprise Linux 3 and Red Hat Enterprise Linux 4 binaries for all architectures as shipped by Red Hat and determined that these versions cannot be exploited. We therefore do not plan on providing updates for this issue.

In contrast, our Fedora Core 4 and 5 builds are vulnerable as the compiler version used adds no stack padding. For these builds, the pointer being overwritten overwrites a saved register and, unfortunately, one that has possible security consequences. It's still quite unlikely we'll see a worm appear for this issue that affects Fedora though: for one thing, the vulnerability can only be exploited when mod_rewrite is enabled and a specific style of RewriteRule is used. So it's likely to be different on every vulnerable site (unless someone has some third party product that relies on some vulnerable rewrite rules). Even then, you still need to be able to defeat the Fedora Core randomization to be able to reliably do anything interesting with this flaw.

So, as you can probably tell, I spent a few days this week analysing assembler dumps of our Apache binaries on some architectures. It was more fun than expected; mostly because I used to code full-time in assembler, although that was over 15 years ago.

In the past I've posted timelines of when we found out about issues and dealt with them in Apache; so for those who are interested:

20060721-23:29 Mark Dowd forwards details of issue to security@apache.org
20060722-07:42 Initial response from Apache security team
20060722-08:14 Investigation, testing, and patches created
20060724-19:04 Negotiated release date with reporter
20060725-10:00 Notified NISCC and CERT to give vendors heads up
20060727-17:00 Fixes committed publically
20060727-23:30 Updates released to Apache site
20060828       Public announcement from Apache, McAfee, CERT, NISCC

This vulnerability does not affect Red Hat Enterprise Linux 2.1 or 3 as they are based on 2.4 kernels.

Red Hat Enterprise Linux 4, Fedora Core 4, and Fedora Core 5 do not support the a.out binary format, causing the exploit to fail. We are not currently aware of any way to exploit this vulnerability if a.out binary format is not enabled. In addition, a default installation of these OS enables SELinux in enforcing mode. SELinux also completely blocks attempts to exploit this issue.

For more technical details of this issue please see bz#198973

The Red Hat Security response team have therefore rated this as having moderate security severity for Enterprise Linux 4. No asynchronous kernel update for this issue is currently planned; the fix for the flaw will be included in some later scheduled update.

This vulnerability was introduced into the Linux kernel in version 2.6.12 and therefore does not affect users of Red Hat Enterprise Linux 2.1, 3, or 4. An update for Fedora Core 4 was released yesterday.

Red Hat released updates to PHP to correct this vulnerability for Red Hat Enterprise Linux 3 and 4 in July 2005. Red Hat Enterprise Linux 2.1 was not affected by this vulnerability. Fedora Core 4 and Fedora Core 3 also got updates in July.

Our analysis showed that the default SELinux targeted policy on Enterprise Linux 4 would have blocked the specific instances of this worm seen so far, but is not sufficient to block a worm written differently from exploiting this vulnerability if left unpatched. Time to make sure all your servers are up2date!