Phil Perry |

June 28th, 2009

Over the past six months or so we've been working really hard on - a community Enterprise Linux Repository for hardware drivers.

One of the main strengths of Enterprise Linux is it's stability and long term support. However, this can also lead to a lack of hardware support where the upstream vendor is sometimes slow to backport the latest advancements. Linux in general has made tremendous progress in the last few years in terms of hardware support, to the point where virtually every device conceivable is now supported in the mainline kernel. However, given the nature of an Enterprise release, such advancements can sometimes be slow to filter down the line and this is an area previously lacking any real coordinated effort. If smaller organisations and end users are also to benefit from Enterprise Linux (RHEL) and it's rebuilds (CentOS, Scientific Linux), then it's important we ensure that these products support the latest modern hardware without destablizing their kernel.

One of the great features of the Linux kernel is it's modular nature. This makes it possible to backport virtually any driver as a kernel module (kmod) into the current kernel. For example, if your network card or sound chipset or webcam isn't supported, you can simply load an updated driver into your current kernel thus retaining the stability of your Enterprise product. ELRepo has built an enviable collection of drivers for Enterprise Linux including filesystem, graphics, hardware monitoring, network, sound and webcam drivers. Some are backported directly from upstream projects (e.g, ALSA, Video4Linux), whilst others are backported from the mainline kernel (e.g, coretemp, it87) or direct from the vendor (e.g, Intel and Realtek nic drivers). All are packaged as kABI-tracking kmods so they don't need to be rebuilt against each new kernel.

ELRepo is designed to be compatible with Enterprise Linux (RHEL) and it's rebuilds (CentOS, Scientific Linux) and not to conflict with other 3rd party repositories (e.g, RPMForge).

lm_sensors and coretemp on CentOS 5.3

March 11th, 2009

In a previous entry I talked about the importance of reading release notes. One of the things I wanted to test in the CentOS 5.3 QA was the rebase of lm_sensors to 2.10.7. This is of relevance for my coretemp kmod package as this requires lm_sensors >= 2.10.2 and CentOS 5.2 shipped with 2.10.0 thus requiring an update to work. So I was kind of hoping that with the rebase of lm_sensors to 2.10.7 in CentOS 5.3, kmod-coretemp would Just Work.

So lets look at what the upstream release notes have to say, and I quote:

"lm_sensors needs the kernel module coretemp.ko to sense temperatures of certain Intel processors including the Core 2 Duo processor family and Core 2 Solo processor family. Although drivers to support the temperature sensors of these processors are included in Red Hat Enterprise Linux 5, the supporting kernel module is not included. This means that while the "sensors-detect" command will report that the "Intel Core family thermal sensor" "detects correctly", the "sensors" command will report "No sensors found!" The drivers for the temperature sensors of these Intel processors are being removed until a future kernel update includes the coretemp.ko module (which will also require an update of lm_sensors). With these drivers removed, "sensors-detect" will no longer falsely appear to detect the temperature sensors of these processors."

OK, that doesn't sound too good. The release notes suggest the lm_sensors driver for coretemp has been removed from the upstream package.

However, it's actually not that bad. Examination of the upstream source reveals they haven't actually removed the driver from lm_sensors, only the ability for sensors-detect to detect the presence of the Intel Core thermal sensor. What does this mean? Well, it means that if you already have coretemp set up and working under 5.2 then updating lm_sensors in CentOS 5.3 will be fine and all will contine to work - nothing breaks. On the other hand, if you try to install and configure the coretemp sensor for the first time on CentOS 5.3, sensors-detect will fail to detect the Intel Core thermal sensor. To this end, I've patched lm_sensors to reinstate detection of the Intel Core thermal sensor. Updated packages can be downloaded here.

Now when we run sensors-detect we see the correct detection of the Intel Core family thermal sensor:

[root@Quad]# sensors-detect

Some south bridges, CPUs or memory controllers may also contain
embedded sensors. Do you want to scan for them? (YES/no): yes
Silicon Integrated Systems SIS5595...                     No
VIA VT82C686 Integrated Sensors...                        No
VIA VT8231 Integrated Sensors...                          No
AMD K8 thermal sensors...                                 No
AMD K10 thermal sensors...                                No
Intel Core family thermal sensor...                       Success!
    (driver `coretemp')
Intel AMB FB-DIMM thermal sensor...                       No

and now life is again good...

[phil@Quad ~]$ rpm -q lm_sensors

[phil@Quad ~]$ sensors
Adapter: ISA adapter
Core 0:  +25°C (high = +100°C)

Adapter: ISA adapter
Core 1:  +24°C (high = +100°C)

Adapter: ISA adapter
Core 2:  +21°C (high = +100°C)

Adapter: ISA adapter
Core 3:  +21°C (high = +100°C)

I guess the next thing on the ToDo list is to set up a repo and get the packages signed given that there's little hope of getting these packages into an official (or 3rd party) repo given the dependency on a patched lm_sensors.

Safer remote updates with screen

January 26th, 2009

With CentOS 5.3 due out shortly, many users will be performing the update. For those without physical access to their servers, updates are something that must be performed remotely, normally over an ssh login. However, for an update as large as a point release, where upwards of a couple hundred packages may need updating, this presents some potential dangers. What if your ssh session fails mid update? The exact answer to this will depend at which point in the update process the session failed, but the general gist is that you'll most likely end up with a pretty broken system that needs some major repair work to complete the update.

So here's some tips to ease the potential pain:

  • Read the release notes before updating
  • Use a screen session so you can reattach the session if a remote ssh login should fail
  • Split the update into smaller chunks to minimize damage (and repair time) should anything unforeseen go wrong

First up, read the release notes. There are a few highlighted gotchas that may or may not apply to you.

If you're updating remotely, perform the update from within a screen session so that if the remote ssh session fails you can log back in and reattach the session without losing anything. For those not familiar with screen, simply start 'screen' after logging in, su to root and 'yum update' as normal. Should the ssh connection fail, just log back in again and reattach the screen session with 'screen -d -r'.

[phil@Quad ~]# ssh
[phil ~]# screen
[phil ~]# su -
[root ~]# yum update
#### connection lost! ####
[phil@Quad ~]# ssh
[phil ~]# screen -r -d
#### phew - she's still alive ####
[root ~]# exit
[phil ~]# exit

If you read the release notes in the first part, you will have noticed an issue with glibc that requires this package to be updated first. The release notes suggest:

[root@Quad ~]# yum update glibc
[root@Quad ~]# yum update

However, you can take this concept a stage further and split updates into smaller chunks thus minimizing the potential for damage (and repair time) should anything unforeseen go wrong. For example, we may like to split updates into logical groups such as the kernel, package management components, compiler tools, etc. How you split your updates will depend on what you have installed, but it may look something like this:

[root@Quad ~]# yum update glibc
[root@Quad ~]# yum update kernel\*
[root@Quad ~]# yum update yum\* rpm\* python\*
[root@Quad ~]# yum update gcc\* make\* automake\*
[root@Quad ~]# yum update open\*
[root@Quad ~]# yum update xorg\* gnome\* kde\* arts\*
[root@Quad ~]# yum update lib\*
[root@Quad ~]# yum update

and finally finishing with a 'yum update' to pull in the remaining updates.

Security through obscurity and SSH

January 16th, 2009

Security through obscurity is generally considered to be a bad thing, especially when it relates to bugs in software or encryption methodologies. It is not about making a product or service more secure, but rather hiding some detail or vulnerability in the hope that no one finds it.

However, we can sometimes use the principle to good effect so long as we understand the limitations. Take securing the commonly used SSH service, for example. We often recommend running the SSH service on a non-standard port as a way to prevent the vast majority of brute-force attempts to crack system accounts. Anyone who operates an SSH server on the standard tcp port 22 will be very familiar with the many logged attempts to gain access and simply moving SSH to a non-standard port will eliminate the vast majority of these attempts. Why does this work? Well, the bad guys will typically scan a network segment for IP addresses running SSH services on port 22 and then run automated tools against identified hosts to attempt to gain access using commonly used username/password combinations. How successful are they? If they weren't getting some success then they wouldn't still be doing it. If you think your SSH server won't get detected or noticed amongst the millions of others out there then you are wrong. The average IP address will get probed on port 22 around 3-5 times per day. Interestingly, recent studies estimate that any reasonably sized botnet is capable of scanning the entire IPv4 address space for a single port in a single day so the bad guys have the capability to locate every single SSH server on the Internet running on port 22 in a day. That's scary!

By moving SSH to a non-standard port we are hiding our needle in the proverbial haystack of 65,535 available ports. But it's important to understand that it's still security through obscurity as we haven't improved the inherent security of the service, just made it harder to find. The popular nmap network scanning tool will by default scan about 1600 of those ports. However, if a determined attacker or one launching a targeted attack decides to probe your IP address they will still find the hidden SSH service if they happen to knock on the right port:

[root@Quad ~]# nmap -sS -sV -p 2222 -P0

Starting Nmap 4.11 ( ) at 2009-01-15 23:59 GMT
Interesting ports on (
2222/tcp open ssh OpenSSH 4.3 (protocol 2.0)

Nmap finished: 1 IP address (1 host up) scanned in 0.095 seconds

So picking a non-standard port a little less obvious than port 2222 is probably a good idea!

Taking it a stage further

However, we can take the concept a stage further. Besides hiding our SSH service on a non-standard port we can also run a second instance of the service on the standard port. Why would we possibly want to do that I hear you ask? Well, the second instance running on the standard port can be configured as a dummy service on which it is impossible to log in. The principle here is that we show attackers a door, the wrong door, in the hope that they will then hammer away at it rather than go looking for the real door. An example of how to run a second instance of SSH is detailed here. Once the second instance is set up it should be deliberately (mis-)configured to not allow logins. The simplest way to achieve this is probably with the AllowUsers directive by specifying a non-existant user (you MUST specify something - a blank AllowUsers will allow logins from ALL users):

# /etc/ssd/sshd_dummy_config

Port 22
PermitRootLogin no
AllowUsers none

Here we configure the dummy SSH daemon to run on the standard port 22, to not allow root logins (always a good idea) and to only allow logins from the user 'none' which (presumably) doesn't exist on the system. Now anyone attempting to gain access will be invited to enter their password none the wiser that it is impossible to log in as there are no valid username/password combinations.

Hopefully I have shown how with a little creative thinking we can use security through obscurity to our advantage to trick even the most determined of attackers into hammering away on the wrong door. Show the attacker what they are expecting to see whilst hiding away the real entry point. In addition, we can also use the dummy service for logging failed attempts and gaining valuable insight and information about those trying to gain access to our systems. But of course it's still security through obscurity.

Choosing a webcam for CentOS

December 1st, 2008
QuickCam Pro 9000

Finding a webcam that will work under Linux has always been a bit of a lottery. Sure, things are slowly improving, and drivers for many webcams are finally starting to appear in the mainline kernel, but on an Enterprise-class distro such as CentOS like we use at Pendre, support for webcams isn't top of the priority list - afterall CentOS is primarily a server OS and not that many servers actually need a webcam.

So after doing plenty of research, I finally settled on a Logitech QuickCam Pro 9000. This is a high-end webcam with integrated microphone boasting HD resolution from it's 2 Megapixel sensor, and a high quality Carl Zeiss lens with autofocus. The Logitech QuickCam Pro 9000 can be found for around £45 ($80-100US).

The QuickCam Pro 9000 uses the UVC driver which has recently been introduced into the mainline kernel. Unfortunately this has yet to be backported into CentOS 5, so I built the driver from source. This was relatively easy - just grab the latest tarball from, extract, build and install (make && make install). Once built, the driver can be inserted into the kernel by running modprobe uvcvideo.

I tested the camera out using Skype and although the higher resolutions available with this webcam under Windows are not available to Linux users, the camera produces a very crisp clear picture and is clearly superior to that produced by most entry-level and midrange webcams. Sound is equally impressive from the built in microphone. Overall, highly recommended and you really do get what you pay for.

Building kernel modules: Part 3

July 24th, 2008

Previously we have seen how we can build kernel modules for CentOS (or RHEL) out of tree (Part 1; May 30th, 2008) or as DKMS modules (Part 2; July 18th, 2008). In this final part we will look at building kmod kernel modules packaged in RPM format and again we will use the coretemp module as an example.

The first thing we need to do is make sure we have all the kernel-devel packages installed for the currect kernel, including any xen and PAE variants. Next create a working directory containing the project source code and Makefile and create the Kbuild file by copying the Makefile. Finally, create a bzip2 compressed tarball of the source directory and copy the compressed tarball to the /SOURCES directory within your build environment.

[buildsys@Quad]$ rpm -qa kernel\* | sort
[buildsys@Quad]$ mkdir /usr/src/coretemp-1.0kmod/
[buildsys@Quad]$ cp coretemp.c Makefile /usr/src/coretemp-1.0kmod/
[buildsys@Quad]$ cd /usr/src/coretemp-1.0kmod
[buildsys@Quad]$ cp Makefile Kbuild
[buildsys@Quad]$ cd ..
[buildsys@Quad]$ tar -cf coretemp-1.0kmod.tar coretemp-1.0kmod/
[buildsys@Quad]$ bzip2 coretemp-1.0kmod.tar
[buildsys@Quad]$ cp coretemp-1.0kmod.tar.bz2 /usr/src/buildsys/SOURCES/

Now we make a copy the kmodtool script (located at /usr/lib/rpm/redhat/kmodtool) called kmodtool-coretemp in the SOURCES directory and edit it to include any dependencies for our kmod RPM package (thanks to Johnny Hughes for the tip). Creating a custom kmodtool script isn't strictly needed for building kmod packages if you don't need to specify any dependencies but I was unable to find a convenient way to pass package dependencies from the SPEC file to the kmodtool build script. Below is an excerpt of my kmodtool-coretemp script showing an additional dependency for lm_sensors >= 2.10.2 which may be obtained from ATrpms.

Requires(post): /sbin/depmod
Requires(postun): /sbin/depmod
Requires: lm_sensors >= 2.10.2

Finally we make a SPEC file for the project named coretemp-kmod.spec file in the /SPECS directory of our build environment:

# Sources:
Source0: coretemp-1.0kmod.tar.bz2
Source10: kmodtool-coretemp

# If kversion isn't defined on the rpmbuild line, build against the current kernel.
%{!?kversion: %define kversion %(uname -r)}

%define kmod_name coretemp
%define kmodtool sh %{SOURCE10}
%define kverrel %(%{kmodtool} verrel %{?kversion} 2>/dev/null)
%define kmodrel %(echo %{kverrel} | sed 's/2.6.18-//')

%define basevar ""
%ifarch i686
%define paevar PAE
%ifarch i686 x86_64
%define xenvar xen

%{!?kvariants: %define kvariants %{?basevar} %{?xenvar} %{?paevar}}

Name: %{kmod_name}-kmod
Version: 1.0
Release: 4.%{kmodrel}
Summary: Coretemp 1.0 CentOS-5 module
License: GPL v2
Group: System Environment/Kernel

BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
ExclusiveArch: i686 x86_64

This package provides the coretemp kernel module for monitoring the core temperature
of Intel Core 2 Duo and Quad Core processors with the CentOS 5.2 series kernels.

# Magic hidden here:
%define kmp_version %{version}
%define kmp_release %{release}
%{expand:%(%{kmodtool} rpmtemplate_kmp %{kmod_name} %{kverrel} %{kvariants} 2>/dev/null)}

%setup -q -c -T -a 0
for kvariant in %{kvariants} ; do
cp -a coretemp-1.0kmod _kmod_build_$kvariant

for kvariant in %{kvariants} ; do
pushd _kmod_build_$kvariant
make -C "${ksrc}" modules M=$PWD

export INSTALL_MOD_DIR=extra/%{kmod_name}
for kvariant in %{kvariants} ; do
pushd _kmod_build_$kvariant
make -C "${ksrc}" modules_install M=$PWD


* Tue Jul 15 2008 Alan J Bartlett
- Fixed bugs in spec file. 1.0-

* Sat Jul 12 2008 Philip J Perry
- Fixed dependencies. 1.0-

* Tue Jul 08 2008 Philip J Perry
- Fixed bug in spec file. 1.0-

* Tue Jul 08 2008 Philip J Perry
- Initial RPM build. 1.0-

Now we're ready to build our kmod packages using rpmbuild:

[buildsys@Quad SPECS]$ rpmbuild -bb --target=`uname -m` coretemp-kmod.spec
[buildsys@Quad SPECS]$

which will produce a set of kmod-coretemp RPMs in your /RPMS directory under the appropriate architecture. Additionally, our SPEC file allows us to specify from the command line at build time which kernel version to build against (e.g, --define 'kversion 2.6.18-92.el5') or which kernel-variant kmod packages to build (e.g, --define 'kvariants ""' would only build the base kernel package).

kmod coretemp packages for CentOS 5 may be downloaded below and installed with rpm:

Alan has kindly updated the CentOS Wiki page on building kernel modules and I'd like to thank both Alan Bartlett and Akemi Yagi for helpful discussions, testing and encouragement whilst preparing this series of articles.

Building kernel modules: Part 2

July 18th, 2008

In an earlier article (Part 1; May 30th, 2008) I described how to build kernel modules for CentOS (or RHEL) out of tree and used the coretemp module as an example. My good friend and colleague, Alan Bartlett, had persuaded me to investigate packaging kernel modules, so herein we are going to look at how to package kernel modules in RPM format using the coretemp module as an example. I'd like to thank Alan for his technical assistance and encouragement without which this article wouldn't have been written.

There are two methods we can employ to build kernel module RPMs - DKMS and kmod. In this article we will look at Dynamic Kernel Module Support (DKMS) and in part 3 we will use kmod.

DKMS must be installed from RPMForge together with the necessary development packages.

We start by creating the necessary directory structure and copying the module source code and Makefile to that directory:

[root@Quad]# mkdir /usr/src/coretemp-1.00/
[root@Quad]# cp coretemp.c Makefile /usr/src/coretemp-1.00/

Next create a dkms.conf file for the project and save it to /usr/src/coretemp-1.00/


Now we are ready to invoke DKMS to add the coretemp module to the DKMS tree and build our RPM package:

[root@Quad]# dkms add -m coretemp -v 1.00

Creating symlink /var/lib/dkms/coretemp/1.00/source ->

DKMS: add Completed.
[root@Quad]# dkms mkrpm --source-only -m coretemp -v 1.00

Using /etc/dkms/template-dkms-mkrpm.spec

Wrote: /var/lib/dkms/coretemp/1.00/rpm/coretemp-1.00-1dkms.src.rpm
Wrote: /var/lib/dkms/coretemp/1.00/rpm/coretemp-1.00-1dkms.noarch.rpm

DKMS: mkrpm Completed.

Finally copy the created RPMs to somewhere safe and remove the coretemp module from the DKMS tree:

[root@Quad]# cp /var/lib/dkms/coretemp/1.00/rpm/coretemp*.rpm /usr/src/
[root@Quad]# dkms remove -m coretemp -v 1.00 --all

Deleting module version: 1.00
completely from the DKMS tree.
[root@Quad ~]#

Now we can install our newly created coretemp RPM as normal:

[root@Quad]# cd /usr/src/
[root@Quad]# rpm -Uvh coretemp-1.00-1dkms.noarch.rpm
Preparing...        ########################################### [100%]

In part 3 I will describe how to build coretemp as a kmod kernel module RPM package for CentOS (or RHEL) and will make the RPMs available for download.

Building kernel modules: Part 1

May 30th, 2008

There are a number of reasons why you may wish to build Linux kernel modules. For example, you may need a driver that isn't present in the current kernel, or you may want to apply a patch to an existing driver that adds functionality or fixes an bug. There are a number of ways you can tackle such issues:

  • Build a new kernel based on the upstream vanilla sources that contain the required driver version
  • Rebuild your current distro kernel with a patch applied

Both of these methods require you to build a complete custom kernel which you then become responsible for maintaining. However, many drivers will build out of tree and may be loaded into your currently running kernel. This approach has a number of advantages in that you don't need to compile a complete kernel, you can continue to run your stable distro kernel and you don't have to worry about maintaining your own custom kernel.

Building modules out of tree

As an example, I'm going to build the coretemp module for CentOS 5 used for monitoring the core temperature from inside Intel Core series processors as this driver didn't make it into the 2.6.18 series kernel used in CentOS 5.

First we need to create a project directory and src directory in that:

[phil@Quad ~]$ mkdir coretemp
[phil@Quad ~]$ cd coretemp/
[phil@Quad coretemp]$ mkdir src
[phil@Quad coretemp]$ ls -l
total 4
drwxrwxr-x 2 phil phil 4096 May 30 18:58 src
[phil@Quad coretemp]$

and place your module source file in /src

Next we create a top level Makefile in the project directory ~/coretemp/

all: clean modules install

$(MAKE) -C src/ modules

$(MAKE) -C src/ clean

$(MAKE) -C src/ install

and a Makefile in ~/coretemp/src/

KVER   := $(shell uname -r)
KDIR   := /lib/modules/$(KVER)/build
KMISC  := /lib/modules/$(KVER)/extra/
KEXT   := $(shell echo $(KVER) | sed -ne 's/^2\.[567]\..*/k/p')o
KFLAG  := 2$(shell echo $(KVER) | sed -ne 's/^2\.[4]\..*/4/p')x

$(MAKE) -C $(KDIR) SUBDIRS=$(PWD)/src modules

rm -rf *.o *.ko *~ .dep* .*.d .*.cmd *.mod.c *.a *.s .*.flags .tmp_versions Module.symvers

install -m 644 -c coretemp.$(KEXT) $(KMISC)

obj-m += coretemp.o

Since coretemp isn't a module provided in the CentOS 5 kernel it makes sense to install our newly built module to /lib/modules/{uname -r}/extra.

So now we can build our new kernel module (you can build the module as a regular user, but make install will need root privileges):

[root@Quad coretemp]# make
make -C src/ clean
make[1]: Entering directory `/home/phil/coretemp/src'
rm -rf *.o *.ko *~ .dep* .*.d .*.cmd *.mod.c *.a *.s .*.flags .tmp_versions Module.symvers
make[1]: Leaving directory `/home/phil/coretemp/src'
make -C src/ modules
make[1]: Entering directory `/home/phil/coretemp/src'
make -C /lib/modules/2.6.18-92.el5/build SUBDIRS=/home/phil/coretemp/src modules
make[2]: Entering directory `/usr/src/kernels/2.6.18-92.el5-x86_64'
CC [M] /home/phil/coretemp/src/coretemp.o
Building modules, stage 2.
CC /home/phil/coretemp/src/coretemp.mod.o
LD [M] /home/phil/coretemp/src/coretemp.ko
make[2]: Leaving directory `/usr/src/kernels/2.6.18-92.el5-x86_64'
make[1]: Leaving directory `/home/phil/coretemp/src'
make -C src/ install
make[1]: Entering directory `/home/phil/coretemp/src'
install -m 644 -c coretemp.ko /lib/modules/2.6.18-92.el5/extra/
make[1]: Leaving directory `/home/phil/coretemp/src'
[root@Quad coretemp]#

and finally run depmod, load the module with modprobe and check it's loaded:

[root@Quad coretemp]# depmod -a
[root@Quad coretemp]# modprobe coretemp
[root@Quad coretemp]# lsmod | grep coretemp
coretemp 41344 0
hwmon 36553 2 coretemp,it87
[root@Quad coretemp]#

So let's have a look at coretemp in action, shown here monitoring all 4 cores of an Intel Q6600 quad core processor:

[root@Quad coretemp]# sensors

Adapter: ISA adapter
Core 0: +38°C (high = +100°C)

Adapter: ISA adapter
Core 1: +38°C (high = +100°C)

Adapter: ISA adapter
Core 2: +36°C (high = +100°C)

Adapter: ISA adapter
Core 3: +36°C (high = +100°C)

[phil@Quad coretemp]$

In part 2 I'll describe how to build dkms enabled kernel modules for CentOS/RHEL and package these in RPM format for distribution.

OpenSSL: Predictable PRNG in debian-based systems

May 13th, 2008

A critical bug has been found in the Pseudo Random Number Generator (PRNG) used in OpenSSL in debian Linux and it's derivative (e.g, Ubuntu etc) that renders random numbers predictable. The bug was introduced into debin unstable on September 17th, 2006 and has since propogated into the stable branch. All keys generated on affected systems should be considered compromised.

I don't use debian (or Ubuntu), so how does this affect me?

The impact of this vulnerability is far reaching and goes way beyond debian-based systems. The vulnerability directly affects all debian-based systems using OpenSSL generated keys (OpenSSH, OpenVPN, website and mail server authentication by SSL/TLS, etc) and potentially affects anyone using SSL-based security or encryption.


If you have a Linux server, then you almost certainly have SSH configured by default for remote access. If you use public/private key authentication and users have generated keys on affected systems, then brute-forcing those keys to gain remote access is trivial and there are already scripts available in the wild. The same applies to OpenVPN. The important facor here is the system the keys were generated on, not whether your server is running debian or other affected Linux distribution.

Additionally, all DSA keys that were ever used on a vulnerable debian-based system for signing or authentication should also be considered compromized due to a known attack on DSA keys.

System administrators are advised to conduct a full audit of all key pairs and regenerate new keys where appropriate.

SSL-encrypted websites and mail servers

Users of debian-based systems running SSL encrypted websites or mail servers using SSL/TLS certificates generated on affected systems should generate new certificates immediately. Additionally, if you have had your certificates signed by Root Certificate Authorities (eg, Twarte, VeriSign etc), then you will need to generate new certificates and get these resigned.

By definition, the public key is publicly known, and therefore it is trivial to generate a matching private key. It then becomes trivial to launch man-in-the-middle style attacks against encrypted or secured transactions such as credit card or other banking transactions or to obtain users login credentials. The potential for exploitation is huge and has the potential to affected all users of the Internet.

If you are at all unsure about how to generate new keys or certificates, please do not hesitate to contact us and we will be happy to assist in generating new OpenSSL keys or certificates for you.

vmsplice local privilege escalation in Linux kernel

February 11th, 2008

There is currently a local privilege escalation flaw in the current Linux Kernel, affecting all kernels from 2.6.17 to inclusive.

Exploit code for this vulnerability is available in the wild:

[phil@centos test]$ ls
exploit exploit.c
[phil@centos test]$ uname -a
Linux centos 2.6.18-53.1.6.el5 #1 SMP Wed Jan 23 11:30:20 EST 2008 i686 athlon i386 GNU/Linux
[phil@centos test]$ whoami
[phil@centos test]$ ./exploit
Linux vmsplice Local Root Exploit
By qaaz
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7f0c000 .. 0xb7f3e000
[+] root
[root@centos test]# whoami
[root@centos test]#

This vulnerability is not remotely exploitable so an attacker would first have to gain local access, however this could present significant risks for system administrators in shared environments with multiple system accounts.

Patches should be available shortly from distribution vendors and system administrators are advised to upgrade their kernel as soon as these become available.