mark :: blog :: fedora

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


Two years ago I published a table of Vulnerability and threat mitigation features in Red Hat Enterprise Linux and Fedora. Now that we've released Red Hat Enterprise Linux 6, it's time to update the table. Thanks to Eugene Teo for collating this information.

Between releases there are lots of changes made to improve security and we've not listed everything; just a high-level overview of the things we 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.

Note that this table is for the most common architectures, x86 and x86_64 only; other supported architectures may vary.

Features Red Hat Enterprise Linux
3456
2003 Oct2005 Feb2007 Mar2010 Nov
Firewall by default YY YY
Signed updates required by default YY YY
NX emulation using segment limits by default Y(since 9/2004)Y Y Y
Support for Position Independent Executables (PIE) Y(since 9/2004)YYY
Address Randomization (ASLR) for Stack/mmap by default Y (since 9/2004)YYY
ASLR for vDSO (if vDSO enabled) no vDSOYYY
Support for NULL pointer dereference protection Y(since 11/2009) Y(since 9/2009) Y(since 5/2008) Y
NX for supported processors/kernels by default Y(since 9/2004)YYY
Support for block module loading via cap-bound sysctl tunable
or /proc/sys/kernel/cap-bound
YY Y no cap-bound
Restricted access to kernel memory by default  YYY
Support for SELinux  YYY
SELinux enabled with targeted policy by default  YYY
glibc heap/memory checks by default  YYY
Support for FORTIFY_SOURCE, used on selected packages  YYY
Support for ELF Data Hardening  YYY
All packages compiled using FORTIFY_SOURCE   YY
All packages compiled with stack smashing protection   YY
SELinux Executable Memory Protection   YY
glibc pointer encryption by default   YY
Enabled NULL pointer dereference protection by default     Y(since 5/2008) Y
Enabled write-protection for kernel read-only data structures
by default
    Y Y
FORTIFY_SOURCE extensions including C++ coverage    Y
Support for block module loading via modules_disabled
sysctl tunable or /proc/sys/kernel/modules_disabled
      Y
Support for SELinux to restrict the loading of kernel modules
by unprivileged processes in confined domains
      Y
Enabled kernel -fstack-protector buffer overflow detection by default       Y
Support for sVirt labelling to provide security over guest instances
      Y
Support for SELinux to confine users' access on a system
      Y
Support for SELinux to test untrusted content via a sandbox
      Y
Support for SELinux X Access Control Extension (XACE)
      Y


keys on a tree

Starting with Red Hat Enterprise Linux 6 we have switched to using SHA-256 signatures on all RPM packages and to a 4096-bit RSA signing key.

We've done this because it is current best practice to migrate away from MD5 and SHA-1 hashes due to various flaws found in them. Those flaws don't yet directly pose a threat to package signing however, and therefore our existing shipped products which used these older hashes will continue to use their existing keys until they reach their end of life.

A similar switch to stronger signing was already made in Fedora 11. This switch involved some changes to the RPM application.

So what this means is that we used new signing keys for both the beta and final release packages for Red Hat Enterprise Linux 6. Those keys were created and are protected by a hardware security module, as we've done with previous keys.

Details and fingerprint of the new key, #fd431d51.


Also in the Red Hat Enterprise Linux 6 distribution we've started to simplify the layout of the key files in the /etc/pki/rpm-gpg/ directory:

The auxiliary key mentioned above is for emergency use. We created it some time ago on a new standalone machine, took a hardcopy printout of the private key and passphrase, stored them separately and securely, and destroyed the software copies. We've planned for many eventualities, but in the unlikely event we lose the ability to sign with the hardware key we could retrieve the printout, type in the key, and continue to sign updates.


mpk-25 with Feodra 13

For our first wedding aniversary this weekend my lovely wife bought me a new gadget, an Akai MPK-25 midi keyboard. The last Sonik gig that I played at we used full-sized midi keyboards hooked to real synth modules, but for our next gig later this year we want to move to lightweight with all soft-syths. Our 140bpm tracks are too hard to play completely live, so a 2-octave keyboard is perfectly fine for playing a lead line, and the keyboard has these great touch pads for triggering samples. We like triggering samples, see the latest video on our facebook page.

We've been setting up our perfect performance environment on a laptop, using Fedora 13 as the base OS, but with a real-time kernel and some prebuilt packages from the Planet CCRMA repository.

Tracy wasn't sure if the keyboard was going to work okay in Linux and didn't find any useful information with Google, even looking for it's USB ID (09e8:0072). Fortunately the Akai MPK-25 is class compliant and works perfectly with Fedora 13 without needing to configure or install anything at all. It's even happy to be powered from just the laptop USB port cutting down on cables and adaptors.

$ aconnect -i
client 0: 'System' [type=kernel]
    0 'Timer           '
    1 'Announce        '
client 14: 'Midi Through' [type=kernel]
    0 'Midi Through Port-0'
client 16: 'Akai MPK25' [type=kernel]
    0 'Akai MPK25 MIDI 1'
    1 'Akai MPK25 MIDI 2'
    2 'Akai MPK25 MIDI 3'
$ aconnect -o
client 14: 'Midi Through' [type=kernel]
    0 'Midi Through Port-0'
client 16: 'Akai MPK25' [type=kernel]
    0 'Akai MPK25 MIDI 1'
    1 'Akai MPK25 MIDI 2'

When using USB, the midi in and out connectors on the back become extra interfaces you can use too, those extra ports you can see shown above -- so we can have another keyboard and a sound module connected through the Akai to the laptop and save a midi interface.

I'll cover the software we're using for our live gigs in a later article; aside from the actual synth VST modules we use all open source.


Red Hat Enterprise Linux 5.5 was released at the end of March 2010, just under 7 months since the release of 5.4 in September 2009. So let's use this opportunity to take a quick look back over the vulnerabilities and security updates we've made in that time, specifically for Red Hat Enterprise Linux 5 Server.

Errata count

The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server if you had installed 5.4, up to and including the 5.5 release, broken down by severity. I've split it into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve a bit of manual effort to select every one). For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what you have installed or removed.

missing graph

So for a default install, from release of 5.4 up to and including 5.5, we shipped 52 advisories to address 140 vulnerabilities. 5 advisories were rated critical, 14 were important, and the remaining 33 were moderate and low.

Or, for all packages, from release of 5.4 to and including 5.5, we shipped 75 advisories to address 187 vulnerabilities. 6 advisories were rated critical, 18 were important, and the remaining 51 were moderate and low.

Critical vulnerabilities

The 6 critical advisories were for 3 different packages. Given the nature of the flaws, ExecShield protections in RHEL5 should make exploiting the memory flaws harder.

  1. Four updates to Firefox (September 2009, October 2009, December 2009, February 2010) where a malicious web site could potentially run arbitrary code as the user running Firefox.
  2. An update to kdelibs (November 2009), where a malicious web site could potentially run arbitrary code as the user running the Konqueror browser. kdelibs is not a default installation package.
  3. An update to krb5, the Kerberos network authentication system (January 2010), where a remote KDC client could cause a crash or run arbitrary code as root. This issue only affected users that have configured and enabled krb5.

Updates to correct 24 out of the 25 critical vulnerabilities were available via Red Hat Network either the same day, or up to one calendar day after the issues were public. The update to fix Konqueror took us 4 calendar days.

Overall, for Red Hat Enterprise Linux 5 since release to date, 98% of critical vulnerabilities have had an update available to address them available from the Red Hat Network either the same day or the next calendar day after the issue was public.

Other significant vulnerabilities

Red Hat Enterprise Linux since 5.2 contained backported patches from the upstream Linux kernel to add the ability to restrict unprivileged mapping of low memory, designed to mitigate NULL pointer dereference flaws. In the last risk report we mentioned it was found that this protection was not sufficient, as a system with SELinux enabled was more permissive in allowing local users in the unconfined_t domain to map low memory areas even if the mmap_min_addr restriction is enabled. This is CVE-2009-2695 and was addressed in a kernel update in November 2009.

Previous updates

To compare these statistics with previous update releases we need to take into account that the time between each update is different. So looking at a default installation and calculating the number of advisories per month gives the results illustrated by the following chart:

missing graph

This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other versions, distributions, or operating systems -- for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.

See also: 5.3 to 5.4, 5.2 to 5.3, 5.1 to 5.2, and 5.0 to 5.1 risk reports.


The 2010 CWE/SANS Top 25 Most Dangerous Programming Errors was published today listing the most widespread issues that lead to software vulnerabilities.

During the creation and review of the list we spent some time to see how closely last years list matched the types of flaws we deal with at Red Hat. We first looked at all the issues that Red Hat fixed across our entire product portfolio in the 2009 calendar year and filtered out those that had the highest severity. All our 2009 vulnerabilities have CVSS scores, so we filtered on those that have a CVSS base score of 7.0 or above[1].

There were 22 vulnerabilities that matched, and we mapped each one to the most appropriate CWE. This gives us 11 flaw types which led to the most severe flaws affecting Red Hat in 2009:

CWECWE DescriptionCWE/SANS
top 25?
Number of
Vulnerabilities
CWE-476NULL Pointer DereferenceNo (on cusp)6
CWE-120Buffer Copy without Checking Size of InputYes3
CWE-129Improper Validation of Array Index Yes3
CWE-131Incorrect Calculation of Buffer Size Yes3
CWE-78OS Command InjectionYes1
CWE-285Improper Access Control (Authorization)Yes1
CWE-362Race ConditionYes1
CWE-330 Use of Insufficiently Random Values No (on cusp)1
CWE-590Free of Memory not on the HeapNo1
CWE-672Use of a Resource after Expiration or ReleaseNo (on cusp)1
CWE-772Missing Release of Resource after Effective LifetimeNo (on cusp)1

10 of the 11 CWE are mentioned in the 2010 CWE/SANS document, although 4 of them are on "the cusp" and didn't make it into the top 25.

This quick review shows us that 2009 was the year of the kernel NULL pointer dereference flaw, as they could allow local untrusted users to gain privileges, and several public exploits to do just that were released. For Red Hat, interactions with SELinux prevented them being able to be easily mitigated, until the end of the year when we provided updates. Now, in 2010, the upstream Linux kernel and many vendors ship with protections to prevent kernel NULL pointers leading to privilege escalation. So although 2009 was the year where CWE-476 mattered to Linux administrators, it didn't make the SANS/CWE top 25 as this flaw type should not lead to severe issues (as long as the protections remain sufficient).

Here is a breakdown with the complete data set to show the CVSS scores and packages affected:

CVECWEtop 25?CVSS
base
Fixed in
CVE-2008-5182 CWE-362Yes 7.2Red Hat Enterprise Linux 5 (kernel)
CVE-2009-0065 CWE-129Yes 8.3Red Hat Enterprise Linux 4,5,MRG (kernel)
CVE-2009-0692 CWE-120Yes 8.3Red Hat Enterprise Linux 3,4 (dhcp)
CVE-2009-0778 CWE-772No (on cusp) 7.1Red Hat Enterprise Linux 5 (kernel)
CVE-2009-0846 CWE-590No 9.3Red Hat Enterprise Linux 2.1, 3 (krb5) [2]
CVE-2009-1185 CWE-131Yes 7.2Red Hat Enterprise Linux 5 (udev)
CVE-2009-1385 CWE-129Yes 7.1Red Hat Enterprise Linux 3,4,5,MRG (kernel)
CVE-2009-1439 CWE-131Yes 7.1Red Hat Enterprise Linux 4,5,MRG (kernel)
CVE-2009-1579 CWE-78Yes 7.5Red Hat Enterprise Linux 3,4,5 (squirrelmail)
CVE-2009-1633 CWE-131Yes 7.1Red Hat Enterprise Linux 4,5,MRG (kernel)
CVE-2009-2406 CWE-120Yes 7.2Red Hat Enterprise Linux 5 (kernel)
CVE-2009-2407 CWE-120Yes 7.2Red Hat Enterprise Linux 5 (kernel)
CVE-2009-2692 CWE-476No (on cusp) 7.2Red Hat Enterprise Linux 3,4,5,MRG (kernel)
CVE-2009-2694 CWE-129Yes 7.5Red Hat Enterprise Linux 3,4,5 (pidgin)
CVE-2009-2698 CWE-476No (on cusp) 7.2Red Hat Enterprise Linux 3,4,5 (kernel)
CVE-2009-2848 CWE-672No (on cusp) 7.2Red Hat Enterprise Linux 3,4,5,MRG (kernel)
CVE-2009-2908 CWE-476No (on cusp) 7.2Red Hat Enterprise Linux 5 (kernel)
CVE-2009-3238 CWE-330No (on cusp) 7.8Red Hat Enterprise Linux 4,5,MRG (kernel)
CVE-2009-3290 CWE-285Yes 7.2Red Hat Enterprise Linux 5 (kvm)
CVE-2009-3547 CWE-476No (on cusp) 7.2Red Hat Enterprise Linux 3,4,5,MRG (kernel)
CVE-2009-3620 CWE-476No (on cusp) 7.2Red Hat Enterprise Linux 4,5,MRG (kernel)
CVE-2009-3726 CWE-476No (on cusp) 7.2Red Hat Enterprise Linux 5,MRG (kernel)

[1] NIST NVD rate vulnerabilities as "High" severity if they have a CVSS base score of 7.0-10.0. This ends up excluding flaws in web browsers such as Firefox which can have a maximum CVSS base score of 6.8.

[2] Red Hat Enterprise Linux 4 and 5 were also affected by this vulnerability, but with a lower CVSS base score of 4.3, due to the extra runtime pointer checking.


There have been quite a few stories over the last couple of weeks about the NULL character certificate flaw, such as this one from The Register.

The stories center around how open source software such as Firefox was able to produce updates to correct this issue just a few days after the Blackhat conference, while Microsoft still hasn't fixed it and are "investigating a possible vulnerability in Windows presented during Black Hat".

But the actual timeline is missing from these stories.

The NULL character certificate flaw (CVE-2009-2408) was actually disclosed by two researchers working independantly who both happened to present the work at the same conference, Blackhat, in July this year. Dan Kaminsky mentioned it as part of a series of PKI flaws he disclosed. Marlinspike had found the same flaw, but was able to demonstrate it in practice by managing to get a trusted Certificate Authority to sign such a malicious certificate.

The flaw was no Blackhat surprise; Dan Kaminsky actually found this issue many months ago and responsibly reported the issues to vendors including Red Hat, Microsoft, and Mozilla. We found out about this issue on 25th February 2009 and worked with Dan and some of the upstream projects on these issues in advance, so we had plenty of time to prepare updates and this is why we were able to have them ready to release just after the disclosure.


Red Hat Enterprise Linux 5.4 was released today, just over 7 months since the release of 5.3 in January 2009. So let's use this opportunity to take a quick look back over the vulnerabilities and security updates we've made in that time, specifically for Red Hat Enterprise Linux 5 Server.

Errata count

The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server as if you installed 5.3, up to and including the 5.4 release, broken down by severity. I've split it into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve a bit of manual effort to select every one). For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what you have installed or removed.

missing graph

So for a default install, from release of 5.3 up to and including 5.4, we shipped 51 advisories to address 166 vulnerabilities. 8 advisories were rated critical, 18 were important, and the remaining 25 were moderate and low.

Or, for all packages, from release of 5.3 to and including 5.4, we shipped 78 advisories to address 251 vulnerabilities. 9 advisories were rated critical, 28 were important, and the remaining 41 were moderate and low.

Critical vulnerabilities

The 9 critical advisories were for just 3 different packages. In all the cases below, given the nature of the flaws, ExecShield protections in RHEL5 should make exploiting these memory flaws harder.

  1. Seven updates to Firefox (February, March 4th, March 27th, April 21st, April 27th, June, July ) where a malicious web site could potentially run arbitrary code as the user running Firefox.
  2. An update to kdelibs (June), where a malicious web site could potentially run arbitrary code as the user running the Konqueror browser. kdelibs is not a default installation package.
  3. An update to the NSS library (July), where a service could present a malicious SSL certificate causing a heap overflow which could potentially run arbitrary code as the user running a browser such as Firefox.

Updates to correct all of these critical vulnerabilities were available via Red Hat Network either the same day, or up to one calendar day after the issues were public.

In fact for Red Hat Enterprise Linux 5 since release and to date, every critical vulnerability has had an update available to address it available from the Red Hat Network either the same day or the next calendar day after the issue was public.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest during this period were several NULL pointer dereference kernel issues. NULL pointer dereference flaws in the Linux kernel can often be easily abused by a local unprivileged user to gain root privileges through the mapping of low memory pages and crafting them to contain valid malicious instructions:

Red Hat Enterprise Linux since 5.2 has contained backported patches from the upstream Linux kernel to add the ability to restrict unprivileged mapping of low memory, designed to mitigate NULL pointer dereference flaws. However it was found that this protection was not sufficient, as a system with SELinux enabled is more permissive in allowing local users in the unconfined_t domain to map low memory areas even if the mmap_min_addr restriction is enabled. This is CVE-2009-2695 and will be addressed in a future kernel update.

Mitigations

Red Hat Enterprise Linux 5 shipped with a number of security technologies designed to make it harder to exploit vulnerabilities and in some cases block exploits for certain flaw types completely. From 5.3 to 5.4 there were three flaws blocked that would otherwise have required critical updates:

Previous updates

To compare these statistics with previous update releases we need to take into account that the time between each update is different. So looking at a default installation and calculating the number of advisories per month gives the results illustrated by the following chart:

missing graph

This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other versions, distributions, or operating systems -- for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.

See also: 5.2 to 5.3, 5.1 to 5.2, and 5.0 to 5.1 risk reports.


In his Black Hat paper and presentation yesterday, Dan Kaminsky highlighted some more issues he has found relating to SSL hash collisions and other PKI flaws. The video of the presentationis online now, so I'm sure the PDF paper will follow shortly. Some of these issues affect open source software, and some parts have already been addressed, so here is a quick summary including CVE names of the applicable bits:

MD2 signature verification

The first issue is that many web browsers still accept certificates with MD2 hash signatures, even though MD2 is no longer considered a cryptographically strong algorithm. This could make it easier for an attacker to create a malicious certificate that would be treated as trusted by a browser. It turns out that there are not many valid MD2 hash certificates around any more, and the main one that does exist is at the trusted root level anyway (and there is actually no need for a crypto library to verify the self-signature on a trusted root). So most vendors have chosen to address this issue by disabling MD2 completely for certificate verification. This is allocated CVE name CVE-2009-2409 ( single name for all affected products).

There is no immediate panic to address this issue as a critical security issue, as in order for it to be exploited an attacker still has to create a MD2 collision with this root certificate; something that is as of today still a significant amount of effort.

My CVSS v2 base score for CVE-2009-2409 would be 2.6 (AV:N/AC:H/Au:N/C:N/I:P/A:N)

Differences in Common Name handling

This issue is about how Common Names are checked for validity by applications. For example if a server presents a certificate with two CN entries, how does the app validate those. Does it use the first one, the last one, or all of them?

Leading 0's in Common Name handling

The second issue is all about inconsistencies in the interpretation of subject x509 names in certificates. Specifically "issue 2b, subattack 1" is where a malicious certificate can contain leading 0's in the OID. The idea is that an attacker could add in some OID into a certificate that, when handled by the Certificate Authority, would appear to be some extension and ignored, but when handled by OpenSSL would appear to be the Common Name OID. So the attacker would present the certificate to a client application and it might think that the OID is actually a Common Name, and accept the certificate where it otherwise should not.

OID overflow in Common Name handling

"issue 2b, subattack 2" is where a malicious certificate can have a very large integer in the OID. The idea is that an attacker could add in some OID into a certificate that, when handled by the CA, would appear to be some extension and ignored, but when handled by OpenSSL would overflow and appear to be the Common Name OID. So the attacker would present the certificate to a client application using OpenSSL and it might think that the OID is actually a Common Name, and accept the certificate where it otherwise should not.

NULL bytes in Common Name handling

"issue 2, attack 2c" is regarding NULL terminators in a Common Name field. If an attacker is able to get a carefully-crafted certificate signed by a Certificate Authority trusted by a browser, the attacker could use the certificate during a man-in-the-middle attack and potentially confuse the browser into accepting it by mistake.

My CVSS v2 base score for CVE-2009-2408 would be 4.3 (AV:N/AC:M/Au:N/C:N/I:P/A:N)

OpenSSL 'compat mode' subject name injection

"issue 2d" is how the OpenSSL command line utility will output unescaped subject X509 lines to standard output. So if some utility runs the openssl application from the command line and parses the text output, and if an attacker can craft a malicious certificate in such a way they fool a CA into signing it, they could present it to the utility and possibly fool that utility into thinking fields were different to what they actually are, perhaps allowing the certificate to be accepted as legitimate.

OpenSSL ASN1 printing crash

Also mentioned in the paper is a flaw in the filtering modes when a two or four byte wide character set is asked to be filtered.

My CVSS v2 base score for CVE-2009-0590 would be 2.6 (AV:N/AC:H/Au:N/C:N/I:N/A:P)


Secunia collect some very interesting information about the patch state of Windows systems. Their results from 20,000 machines published yesterday were that over 98% of PCs were insecure, having at least one out-of-date application installed.

Actually this isn't surprising and is exactly what I'd expect; it's all down to third party applications.

Let's say you're browsing the web. It's more than likely that at some point you'll want to view some PDF files, watch some Flash content, or play a Java game. Those tasks are all dealt with by third party applications, although to the end user it's all part of the browser experience. Since your system is only as secure as its weakest link, you need to manage security updates for those third party applications just as carefully as you manage security updates for the rest of your system. That's why Adobe Reader, Java, Flash, and all the myriad of other applications you've installed in order to make your system useful have their own update mechanisms. Some applications on Windows will 'phone home' when they are run and check to see if they need to be updated, others deploy services that sit in the background looking for updates from time to time, others even check every time your system starts. Many don't get automated updates at all.

How do you deal with all that risk? I believe it's possible by providing an OS distribution which includes all the bits you'll likely need to make a useful computing environment, thereby taking away that update uncertainty. Red Hat ship several PDF viewers in our distributions for example, but we also ship (in an Extras channel) Adobe Reader. Our Security Response Team are monitoring for security issues in everything we ship, all the third party applications, and providing a single point of contact, a single notification system, and a single way to get the updates.

If Microsoft knew that say 25% of all their users installed Firefox, wouldn't they be better bundling it and providing their centralised automated updates for it, to reduce their customers overall risk? They do already bundle some third party applications, although it's been with mixed success as we found 3 years ago when they didn't provide security fixes for bundled Flash (ZDNet coverage).

This is, in part, why you've not seen me respond recently to the Vista security reports which compare vulnerability counts. In these reports they use a cut-down minimal Red Hat Enterprise Linux installation in order to make it look more like Windows for the comparisons. But this is completely backwards -- the fact that we're including and fixing the flaws using a common process in so much third party software is actually helping reduce the risk and protect real customers. For example we could easily cut our vulnerability count by shipping only one PDF viewer instead of four. But if we know that these other viewers are going to get installed by the customer anyway all we've done is to hide the vulnerability count elsewhere, and you've made the customers overall risk increase.

So it may seem counter-intuitive but we should ship as much third party applications (that we know people use) as we can, because a single managed security update and notification process will decrease a users overall risk. The fewer third party applications that users have to get from elsewhere and install and manage for themselves the better in my opinion.


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

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

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