Ubuntu

The kernel is no longer readable by non-root users

Reported by Richard W.M. Jones on 2011-04-13
104
This bug affects 20 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned

Bug Description

The mode of the latest kernel has changed so it is no longer readable
by non-root users:

-rw-r--r-- 1 root root 4336016 2010-10-17 01:37 /boot/vmlinuz-2.6.35-22-generic
-rw-r--r-- 1 root root 4336912 2010-11-24 12:46 /boot/vmlinuz-2.6.35-23-generic
-rw-r--r-- 1 root root 4523072 2011-03-08 18:47 /boot/vmlinuz-2.6.38-6-generic
-rw------- 1 root root 4523936 2011-04-11 05:24 /boot/vmlinuz-2.6.38-8-generic

This prevents people from using this kernel to boot qemu
virtual machines as non-root.

Please change the mode back to make the kernel readable.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: linux-image-2.6.38-8-generic 2.6.38-8.42
Regression: Yes
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.35-22.35-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic x86_64
AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access /dev/snd/: No such file or directory
AplayDevices: aplay: device_list:240: no soundcards found...
Architecture: amd64
ArecordDevices: arecord: device_list:240: no soundcards found...
CRDA: Error: [Errno 2] No such file or directory
Date: Wed Apr 13 13:05:01 2011
HibernationDevice: RESUME=UUID=112bf9c4-620e-441f-abb3-aeac6aa15294
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
IwConfig:
 lo no wireless extensions.

 eth0 no wireless extensions.
Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Red Hat KVM
PciMultimedia:

ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-22-generic root=UUID=1efa0b67-17df-484e-980c-8544fa2149fe ro quiet splash
RelatedPackageVersions:
 linux-restricted-modules-2.6.35-22-generic N/A
 linux-backports-modules-2.6.35-22-generic N/A
 linux-firmware 1.50
RfKill:

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/01/2007
dmi.bios.vendor: Seabios
dmi.bios.version: 0.5.1
dmi.chassis.type: 1
dmi.chassis.vendor: Red Hat
dmi.modalias: dmi:bvnSeabios:bvr0.5.1:bd01/01/2007:svnRedHat:pnKVM:pvrRHEL6.0.0PC:cvnRedHat:ct1:cvr:
dmi.product.name: KVM
dmi.product.version: RHEL 6.0.0 PC
dmi.sys.vendor: Red Hat

Scott Moser (smoser) wrote :

I'm confirming this, and marking marking it as medium.

It is fairly common practice to boot kvm or qemu with something like:
 kvm -kernel /boot/vmlinuz-$(uname -r)

There are easy workarounds (downloading the kernel and extracting and using it), but they're less than idea.

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Kees Cook (kees) wrote :

This mode change is "by design". For local admins that what to relax this restriction, you can use dpkg-statoverride:

  sudo dpkg-statoverride --add root root 0644 /boot/vmlinux-$(uname -r) --update

To have this automatically happen with each new kernel, create /etc/kernel/postinst.d/statoverride:

  #!/bin/sh
  version="$1"
  # passing the kernel version is required
  [ -z "${version}" ] && exit 0
  dpkg-statoverride --add root root 0644 /boot/vmlinux-${version} --update

Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
Kees Cook (kees) wrote :

Sorry, that should be "vmlinuz" not "vmlinux" in the above examples. :)

What is being protected by this mode change? This kernel is distributed
on hundreds of mirrors -- there is no secret in here.

When we install libguestfs, we need to boot using this kernel. What change
do I need to make to libguestfs so that when a sysadmin installs it, it will
change the permissions back to 0644 automatically?

On Tue, Apr 26, 2011 at 11:21:38AM -0000, Richard W.M. Jones wrote:
> What is being protected by this mode change? This kernel is distributed
> on hundreds of mirrors -- there is no secret in here.

The mode changes do not protect a system from any dedicated attacker (for
the reason you state), but it does have real-world benefits against
simplistic kernel exploitation (keeping kernel symbols away from non-root
users). It is absolutely a trade-off.

> When we install libguestfs, we need to boot using this kernel. What change
> do I need to make to libguestfs so that when a sysadmin installs it, it will
> change the permissions back to 0644 automatically?

Shipping a pair of files in /etc/kernel/postinst.d/ and
/etc/kernel/postrm.d/ to call dpkg-statoverride --add and --remove
respectively is likely the cleanest approach to handling this.

--
Kees Cook
Ubuntu Security Team

On Tue, Apr 26, 2011 at 05:25:33PM -0000, Kees Cook wrote:
> On Tue, Apr 26, 2011 at 11:21:38AM -0000, Richard W.M. Jones wrote:
> > What is being protected by this mode change? This kernel is distributed
> > on hundreds of mirrors -- there is no secret in here.
>
> The mode changes do not protect a system from any dedicated attacker (for
> the reason you state), but it does have real-world benefits against
> simplistic kernel exploitation (keeping kernel symbols away from non-root
> users). It is absolutely a trade-off.

This non-root user that we imagine has no access to the world
wide web? This is absolutely nuts, sorry.

Rich.

--
Richard Jones
Red Hat

By the way, I myself actually wrote code that walks through the kernel memory
finding the location of the symbols. You're not gaining any extra security by
making this change, but you are making Ubuntu less useful.

http://git.annexia.org/?p=virt-mem.git;a=blob;f=lib/virt_mem_kallsyms.ml;h=9e6eccb6629a2ea067ee46a7c690aea17e44c0d2;hb=HEAD#l39
http://git.annexia.org/?p=virt-mem.git;a=blob;f=lib/virt_mem_ksyms.ml;h=8a38caec5b9fa05904c3b9e8b5fcdb76871f27ae;hb=HEAD#l29

Kees Cook (kees) wrote :

I recognize this can get in some people's way, which is why I've tried to demonstrate how to adjust the local system to retain the more open permissions.

I am not saying they're hidden from being looked up externally (just fetching the kernel package's System.map file is easiest). But because the symbols can be extracted in the way you point out is why the kernel image itself needs to be unreadable. This change is to block the class of attacks carried out by script kiddies and automated systems that expect to be able to look up symbols locally and make exploits totally portable to all kernel versions. It changes the nature of future attacks, at least forcing attackers to take additional steps.

The postinst.d and prerm.d solution should provide a reasonable work-around for the small number of systems that need it.

On Tue, Apr 26, 2011 at 09:49:25PM -0000, Kees Cook wrote:
> But because the symbols can be extracted in the way you point out is
> why the kernel image itself needs to be unreadable. This change is
> to block the class of attacks carried out by script kiddies and
> automated systems that expect to be able to look up symbols locally
> and make exploits totally portable to all kernel versions.

You didn't appear to understand the code that I wrote: it gets out the
symbols from any version of the kernel by simply reading the kernel
*runtime memory*.

So the attacker now has two alternative methods: (a) fire up a web
browser or (b) inject shell code into the kernel which greps through
physical memory to find the symbol tables, and note method (b) works
with any kernel version without reference to the original vmlinuz
file.

> It changes the nature of future attacks, at least forcing attackers
> to take additional steps.

Yes, firing up a web browser or injecting an extra small piece of
shell code into the kernel.

Joel Whitehouse (me-t) wrote :

I need to mount a binary file that contains a filesystem so I can copy files onto it.

I could already do this using /dev/loop but I need to automate this without requiring root privileges for a build system.

To solve this problem, the guestmount folks pulled together TONS of code. They are creating a custom minimized kernel, emulating it with QEMU, booting it with the binary file attached, attaching FUSE to the mount point and connecting to it at the application layer. All to avoid needing /dev/loop and root access.

Guestmount used to work out of the box. And you just broke it "by-design" with a change that provides zero security or protection from anyone with a brain or an internet connection. I agree with Rich W. M. Jones. You are making ubuntu less useful.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers