Package: os-prober Severity: normal Tags: security To mount a /boot partition, os-prober uses the mount binary from the linux system it is probing. There's a possible security risk here. Imagine if a compromised system is being reinstalled using a new drive, and the compromised drive is still connected. An attacker who wanted to target d-i could arrange for mount to copy itself over to /target when run. Or a virus, not targeting d-i at all, could infect /target. ------------------------------------------------------------------------ r50221 | cjwatson | 2007-11-22 13:16:50 -0500 (Thu, 22 Nov 2007) | 2 lines * Try finding a LABEL/UUID-capable /bin/mount in $tmpmnt as well as in /target. ------------------------------------------------------------------------ I'm wondering what was the rationalle for needing to do that, and why does the code use the mount from the system being probed, in *preference* to the one in /target? Perhaps the idea was that a distribution's fstab might use special features that are only available with its version of mount, if so I hope that Debian's mount has caught up..? Also, since we have a udeb containing libblkid, perhaps it's time to spend the 100k of ram to have os-prober-udeb depend on a mount-udeb and remove this hack. IIRC this is the last place where d-i runs binraries from /target or elsewhere w/o chrooting, which has caused other problems before. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.31-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- see shy jo
Attachment:
signature.asc
Description: Digital signature