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
So if you're wondering why I've not bloged in a while it's because we're just back from holiday, the first in a few years. It was pretty eventful; I got engaged to Tracy at Shoshone Point at the Grand Canyon, we saw Spamalot in Vegas, and went to see Rocco Deluca play live in LA (Tracy even managed to get a photo with her favourite actor Kiefer Sutherland who turned up to watch).
I'm out on holiday soon to Arizona, so we've been looking for ways to geocode the photos we'll be taking and get a record of our route. I use a Mio A701 phone which has built-in GPS, and this time we'll be using Tom Tom in the USA rather than Mapopolis. The problem with Tom Tom Navigator is that it doesn't keep a track log, and there doesn't seem to be any plugins to allow it to do so. So here is the solution I've been experimenting with over the weekend.
On the PocketPC:
- Make sure the GPS Intermediate Driver is enabled, on the MIO there is a built-in "GPS Settings" utility where I have it set to COM4 and "Manage GPS automatically"
- Use the GPS2Blue utility. Make sure it's set to GPS on COM4, 4800 baud, with logging only of GGA/GLL/RMC/VTG NMEA, and select 'Log processed raw data...'. You don't need to enable the "2blue" bit, we're just using it to write the tracklog.
- Make sure your camera has a date and time that is close to the one being shown by GPS2Blue from the satellites
- Start TomTom. Make sure it's also set to COM4, 4800 baud. This will work because the GPS Intermediate Driver is opened by GPS2Blue. You can't start TomTom first, but you can exit GPS2Blue and leave TomTom running.
- After finishing you end up with a NMEA track log with an hour of logging taking up about 1.6Mb. Transfer it to your Fedora machine.
On my Fedora machine:
- Use gpsbabel to convert the NMEA
track log and clean it up a bit. I used:
gpsbabel -i nmea -f GPS_2008-03-03_122630.log -x discard,hdop=10,sat=5 -o gpx -F out.gpx
- Use gps2photo.pl to
add the geocoding to your images. This script looks at the time and date the
photo was taken and tries to match it up to an entry in the tracklog, so you
may need to play with the timeoffset to
deal with timezone differences. Although we have snow, being in the UK in the Winter has
it's advantages as we're UTC+0, so I just used:
gpsPhoto.pl --geoinfo=osm --dir ./ --gpsfile out.gpx --timeoffset 0 \ --city=auto --sublocation=auto --state auto --country auto --kml out.kml
The exif metadata inside each jpeg now contains the approximate co-ordinates of where you were when you took the photo along with a guess of the location (city, country, etc). You can load out.kml into GoogleEarth to see the tracklog and photos on a map. If you've allowed Flickr to read the location data from exif then uploading a geotagged photo will automatically place it on a map. (Make sure you consider the consequences before enabling that option or you may end up unintentionally leaking information like the location of your friends houses or parties you've been to). Here's a quick pic taken in the snow today to test it out:
| output from exiftool:
GPS Position : 55 deg 46' 58.21" N, 4 deg 0' 5.50" W City : Motherwell Province-State : Scotland Country-Primary Location Name : United Kingdom |
It sometimes seems like the Security Response Team at Red Hat are pushing security updates every day, but actually a default installation of Enterprise Linux 4 AS was vulnerable to only 7 critical security issues in the first three years since release. But to get a picture of the risk you need to do more than count vulnerabilities.
My full risk report was published yesterday in Red Hat Magazine and reveals the state of security since the release of Red Hat Enterprise Linux 4 including metrics, key vulnerabilities, and the most common ways users were affected by security issues.
"Red Hat knew about 49% of the security vulnerabilities that we fixed in advance of them being publicly disclosed. For those issues, the average notice was 21 calendar days, although the median was much lower, with half the private issues having advance notice of 8 days or less."
Last Friday, just as I was finishing work for the day, an email appeared in my mailbox from the UK CPNI announcing a public remote code execution flaw in Apache on HP-UX. As Chair of the Apache Software Foundation Security Team I knew there were no outstanding remote code execution flaws in Apache HTTP server (in fact we've not had a remote code execution flaw for many years) so I was expecting to invoke the Red Hat Critical Action Plan which would have meant a rather long weekend for me, my team, and various development and quality engineering staff.
First thing to do was to find the original source of the advisory, as co-ordination centres and research firms are known to often play the Telephone game, with advisory texts mangled beyond recognition. Following the links led to the actual advisory on the HP site. This describes the vulnerability as follows:
But then they give the CVE name for the flaw, CVE-2007-6388, which is a known public flaw fixed last month in various Apache versions from the ASF and in updates from various vendors that ship Apache (including Red Hat).
This flaw is a cross-site scripting flaw in the mod_status module. Note that the server-status page is not enabled by default and it is best practice to not make this publicly available. I wrote mod_status over 12 years ago and so I know that this flaw is exactly how the ASF describes it; it definitely can't let a remote attacker execute arbitrary code on your Apache HTTP server, under any circumstances.
I fired off a quick email to a couple of contacts in the HP security team and they confirmed that the flaw they fixed is just the cross-site scripting flaw, not a remote code flaw. The CVSS ratings they give in their advisory are consistent with it being a cross-site scripting flaw too.
So happy with a false alarm we cancelled our Critical Action Plan and I went off and had a nice weekend practicing taking panoramas without a tripod ready for an upcoming holiday. My first attempt came out better than I expected:
Secunia released a security summary report for 2007 and surprisingly gave a count for Red Hat for the year at over 600 vulnerabilities. I had no idea how they got to this number, it certainly doesn't match our own publicly available metrics at http://www.redhat.com/security/data/metrics
Using our public tool, for every Red Hat product and service, for 2007 we issued 306 advisories to fix 404 vulnerabilities. Of those 404 vulnerabilities 41 were critical (on the scale used by Microsoft and Red Hat).
Most people are not going to be using every Red Hat product, so taking just Enterprise Linux product you find 348 vulnerabilities, of which 27 were critical. A given user is going to only be vulnerable to the issues that affect the products and packages they have installed. Using the scripts on our pages you can figure it out for your own circumstances. But as an example, the default installation of Red Hat Enterprise Linux 4 AS had 172 vulnerabilities of which 4 were critical.
The Secunia report does actually make it clear you can't use their vulnerability count as a method of comparing platforms, in part due to the differences in methodology of the vendors, but I'm sure this won't stop some press from jumping to conclusions if they don't read the actual report.
I've asked Secunia how they got to their number of vulnerabilities, but in the meantime, a raw count of vulnerabilities is only a small part of the overall risk exposure in using a product. I've got some more reports that go into this in more detail for two years of Enterprise Linux 4 and Enterprise Linux 5.0 to 5.1.
Update: Coverage of this: ZDNet
Update: Secunia told me that they treat each advisory separately; so for example yesterday we issued updates for some moderate severity issues in the Apache Web server, but we did separate advisories for each affected product: Red Hat Enterprise Linux 2.1, 3, 4, 5, Red Hat Application Stack v1, v2. So in this case the same Apache vulnerability would be counted 6 times.
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 | |||||||||
| 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 | ||||||||||
Red Hat Enterprise Linux 5.1 was released today, around 8 months since the release of 5.0 in March 2007. 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.
The graph below shows the total number of security updates issued for Red Hat Enterprise Linux 5 Server up to and including the 5.1 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). So, for a given installation, the number of packages and vulnerabilities will be somewhere between the two extremes.
So for all packages, from release up to and including 5.1, we shipped 94 updates to address 218 vulnerabilities. 7 advisories were rated critical, 36 were important, and the remaining 51 were moderate and low.
For a default install, from release up to and including 5.1, we shipped 60 updates to address 135 vulnerabilities. 7 advisories were rated critical, 26 were important, and the remaining 27 were moderate and low.
- These figures include ten updates we released on the day we shipped 5.0. This was because we froze package updates some months before releasing the product. Only one of those updates was rated critical, an update to Firefox.
- The six other critical updates were:
- Three more updates to Firefox (May, July, October) where a malicious web site could potentially run arbitrary code as the user running Firefox. Given the nature of the flaws, ExecShield protections in RHEL5 should make exploiting these memory flaws harder.
- An update to the Kerberos telnet deamon (April) A remote attacker who can access the telnet port of a target machine could log in as root without requiring a password. None of the standard protection mechanisms help prevent exploitation of this issue, however the krb5 telnet daemon is not enabled by default in Enterprise Linux 5 and the default firewall rules block remote access to the telnet port. This flaw did not affect the more common telnet daemon distributed in the telnet-server package.
- An update to Samba (May) where a remote attacker could cause a heap overflow. In addition to ExecShield making this harder to exploit, the impact of any sucessful exploit would be reduced as Samba is constrained by an SELinux targeted policy (enabled by default).
- An update to the PCRE library (November). This was labelled critical because the Konqueror web browser uses PCRE to handle regular expressions in JavaScript, and therefore a user browsing a malicious site in Konqueror could trigger this issue. (Konqueror is not part of a default install, but I've left this issue as critical in the results).
- Updates to correct all of these critical issues were available via Red Hat Network within a day of the issues being public.
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. For the period of this study there were two flaws blocked that would otherwise have required critical updates:
- A stack buffer overflow flaw in the RPC library in Kerberos. This flaw was blocked by FORTIFY_SOURCE which removed the possibility of remote code execution. We still issued an update, as a remote attacker could trigger this flaw and cause Kerberos to crash.
- Another flaw in Kerberos, this time due to the free of an invalid pointer. This flaw was blocked by glibc, although a remote attacker could still cause a crash, so we issued an update.
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 or distributions -- for example, a default install of Red Hat Enterprise 4AS did not include Firefox. You can get the results I presented above for yourself by using our public security measurement data and tools, and run your own metrics for any given Red Hat product, package set, timescales, and severities.
Back in August I found that many of the Common Vulnerability Scoring System (CVSS) scores that the National Vulnerability Database (NVD) assigned to vulnerabilities affecting open source software were incorrect.
Since then I've been sending in corrections on a monthly basis, taking into account the worst possible score across all affected platforms (and not how Red Hat products were affected specifically).
For the five months May to September 2007 I looked at 178 vulnerabilities (across all Red Hat products and services). Only 80 were accurate. Corrections were submitted to NVD and they fixed the incorrect CVSS scores on the remaining 98 vulnerabilities.
So, before the corrections, there were 65 issues rated "High" out of 178. After the corrections there are actually only 17 rated "High".
Fortunately the number of corrections needed each month seems to be decreasing, but we'll continue to send in corrections every month. Even with the corrections, the severity rating for a given vulnerability may well vary for the version each vendor ships; so you need to be careful if you are basing your risk assesments soley on the accuracy of third-party severity ratings.
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.
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.confThen 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
