mark :: blog :: fedora

<< prev [ 1 | 2 | 3 | 4 ] next >>


ZoneMinder is an amazing Linux video camera security and surveillance application I use as part of my home automation system. ZoneMinder prior to version 1.23.3 contains unescaped PHP exec() calls which can allow an authorised remote user the ability to run arbitrary code as the Apache httpd user (CVE-2008-1381)

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


A year ago I published a table of Security Features in Red Hat Enterprise Linux and Fedora Core. Since then we've released two more Fedora versions, and a Red Hat Enterprise Linux, so it's time to update the table.

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
123456 78 345
2003Nov2004May2004Nov2005Jun2006Mar2006Oct 2007May2007Nov 2003Oct2005Feb2007Mar
Firewall by default YYYYYY YY YY Y
Signed updates required by default YYYYYY YY YY Y
NX emulation using segment limits by default YYYYYY YY Y2Y Y
Support for Position Independent Executables (PIE) YYYYYYYY Y2YY
Address Randomization (ASLR) for Stack/mmap by default3 YYYYYYYY Y2YY
ASLR for vDSO (if vDSO enabled)3 no vDSOYYYYYYY no vDSOYY
Restricted access to kernel memory by default  YYYYYYY  YY
NX for supported processors/kernels by default  Y1YYYYYY Y2YY
Support for SELinux  YYYYYYY  YY
SELinux enabled with targeted policy by default   YYYYYY  YY
glibc heap/memory checks by default   YYYYYY  YY
Support for FORTIFY_SOURCE, used on selected packages   YYYYYY  YY
All packages compiled using FORTIFY_SOURCE    YYYYY   Y
Support for ELF Data Hardening    YYYYY  YY
All packages compiled with stack smashing protection     YYYY   Y
SELinux Executable Memory Protection      YYY   Y
glibc pointer encryption by default      YYY   Y
FORTIFY_SOURCE extensions including C++ coverage        Y    
1 Since June 2004, 2 Since September 2004, 3 Selected Architectures


Favourite purchase of 2007: A Fujitsu ScanSnap S510 scanner with auto-document feed. It's not a cheap scanner, but I've been drowning recently under a sea of paperwork and clipped articles, and it sounded pretty neat: scanning both sides of A4 and quickly. The scanner comes with a ton of Windows software: a driver, some OCR stuff, a full version of Acrobat, business card scanner, organisers, and a gadzillion menu entries for all those things. But it is pretty amazing to watch as you feed in a few hundred pages of A4 and within minutes you have a fully-searchable PDF file out.

scansnap

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
Then you can use any scanning front-end, or from the command line say you wanted to scan at 150dpi colour, double-sided, then use "scanimage -L" to figure out where your scanner is, and replace the 005:004 below with the location:
# scanadf --device fujitsu:libusb:005:004 --source "ADF Duplex" --mode Color -v --resolution 150 --y-resolution 150


Our usual security audit for Fedora Core 6 is now available. For 20020101 to 20061023 there are a potential 1758 CVE named vulnerabilities that could have affected FC6 packages. 93% of those are fixed because FC6 includes an upstream version that includes a fix, 1% are still outstanding, and 6% are fixed with a backported patch. Most of those outstanding issues are for low or moderate severity flaws that are not fixed upstream.

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


There's a new Apache HTTP Server security issue out today, an off-by-one bug that affects the Rewrite module, mod_rewrite. We've not had many serious Apache bugs in some time, in fact the last one of note was four years ago, the Chunked Encoding Vulnerability.

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
Here is the patch against 2.0, the patch against 1.3 or 2.2 is almost identical.


On Friday 14th July an exploit was widely posted for a vulnerability in the Linux 2.6 kernel, CVE-2006-3626, which attempts to allow a local user to gain root privileges. The exploit relies on the kernel supporting the a.out binary format.

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.


Just finished the security audit for FC5 - For 20030101-20060320 there are a potential 1361 CVE named vulnerabilities that could have affected FC5 packages. 90% of those are fixed because FC5 includes an upstream version that includes a fix, 1% are still outstanding, and 9% are fixed with a backported patch. Many of the outstanding and backported entries are for issues still not dealt with upstream. For comparison FC4 had 88% by version, 1% outstanding, 11% backported.


On Monday a vulnerability was announced affecting the Linux kernel that could allow a remote attacker who can send a carefully crafted IP packet to cause a denial of service (machine crash). This issue was discovered by Dave Jones and allocated CVE CVE-2006-0454. As Dave notes it's so far proved difficult to reliably trigger (my attempts so far succeed in logging dst badness messages and messing up future ICMP packet receipts, but haven't triggered a crash).

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.


At FudCon I talked about the lack of any recent Linux worms, the last being a couple of years ago - but as of this weekend I've a new Linux worm to talk about, Lupii. This Linux worm was detected around the 5th November 2005 and is designed to exploit a flaw CVE-2005-1921 in the PHP PEAR XML-RPC Server package through a number of third party PHP scripts.

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!


On Friday we read about the Firefox security issue, CAN-2005-2871. This issue looked like it could well be a 'critical' issue potentially allowing a malicious web page to control a heap buffer overflow. We know that various technologies in Red Hat Enterprise Linux and Fedora Core are likely to reduce the chances of this being actually exploitable by an attacker -- checks foil the most usual way of exploiting heap overflows by messing with malloc control structures, and on x86 at least heap randomization makes an exploit harder. But this issue was already public and so we didn't have the luxury of time to be able to test the mitigation. So we initiated our emergency response process to get the packages through development and QA and got Firefox and Mozilla packages out via Red Hat Network within 20 hours of this issue being public (due to the awesome work from engineering folks, QA folks, and the security response team who worked late into Friday night to get this done).

<< prev [ 1 | 2 | 3 | 4 ] next >>

Hi! I'm Mark Cox. This blog gives my thoughts and opinions on my security work, open source, fedora, home automation, and other topics.