binfmt allows breaking out of chroots due to not respecting namespaces

Bug #427863 reported by Oliver Grawert
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

in ubuntu and debian using the binfmt-support tool, it is possible to register
interpreters based on file magic with the binfmt module, so a mono file gets
executed by the proper mono interpreter, java by the java interpreter etc.

we recently added a qemu-arm-static package that allows executing armel
binaries under x86 systems. this package also registers with binfmt. it also
comes with a script that builds armel specific chroots (and copies the static
binary into the chroot).

now chrooting into such an armel chroot and trying to execute something another
binfmt handler is available for in the kernel (i.e. installing mono
applications in this armel chroot on a x86 system) ends up in the situation
that $interpreter of the host system gets executed instead of

the module should determine from which namespace ($chroot) the binary wanting
to execute the interpreter comes and act accordingly by executing the binary
from inside the chroot instead of the one from the host system.

given that i now could use an x86 mono or java binary from inside the chroot to
access the actual host system with them appears like a (even not actually
major) security issue.

Kees Cook (kees)
Changed in linux (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
milestone: none → ubuntu-9.10-beta
Kees Cook (kees)
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Kees Cook (kees) wrote :

I cannot reproduce this issue. For example, I have /tmp/test.pyc which is the python-compiled version of 'os.system("lsb_release -a"); time.sleep(30);'. Running it directly should trigger binfmt since the magic matches:

$ hexdump -C /tmp/test.pyc | head -n1
00000000 d1 f2 0d 0a fd 34 ad 4a 63 00 00 00 00 00 00 00 |.....4.Jc.......|
$ cat /proc/sys/fs/binfmt_misc/python2.6
interpreter /usr/bin/python2.6
offset 0
magic d1f20d0a

It does run, but it's running in the chroot (reports "jaunty" not "karmic"), and the executable launched is inside the chroot too:

$ ps auwwx | grep test
kees 10858 0.1 0.0 19028 3508 pts/9 S+ 11:13 0:00 /usr/bin/python2.6 ./test.pyc
$ ls -la /proc/10858/exe
lrwxrwxrwx 1 kees kees 0 2009-09-13 11:13 /proc/10858/exe -> /var/lib/schroot/mount/jaunty-3f106f9a-a37c-4a3f-b413-76b63fc51f79/usr/bin/python2.6

Revision history for this message
Oliver Grawert (ogra) wrote :

well, my chroot is run inside qemu userspace emulation and it tries to execute a mono binary, i wonder if either influences this.

could you try with qemu-arm-static and using the build-arm-chroot to create your chroot env ?
it might not be binfmt itself being at fault but the mono interpreter or the detector ...

ogra@osiris:~$ cat /usr/share/binfmts/cli
package mono-common
detector /usr/lib/cli/binfmt-detector-cli
interpreter /usr/bin/cli
magic MZ

Changed in linux:
status: Unknown → Confirmed
Kees Cook (kees)
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
milestone: ubuntu-9.10-beta → none
Revision history for this message
Kees Cook (kees) wrote :

Inside the ARM chroot:

# ./hello.exe
bash: ./hello.exe: No such file or directory
# file ./hello.exe
./hello.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit Mono/.Net assembly

Can you please provide a step-by-step example of the flaw?

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: kj-expired
Changed in linux (Ubuntu):
status: Incomplete → Invalid
Changed in linux:
importance: Unknown → Medium
Changed in linux:
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.