Bug#569222: risky use of mount from a random partition
On Wed, Feb 10, 2010 at 04:01:00PM -0500, Joey Hess wrote:
> 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..?
Good question. I've been trying to dig out the history and it doesn't
seem especially clear even to me. I think I must have reasoned that (a)
using $tmpmnt wasn't significantly worse than using /target (I hadn't
thought of the security risk) and (b) it would be more reliable to hunt
for a mount that understands $tmpmnt's fstab in $tmpmnt than in /target.
I agree that this situation is bad, and that we should fix this in other
ways. The fstab format is not really that unstable! The main problem
is fancy filesystems, e.g. ntfs-3g with FUSE, but those are supportable
in d-i by the time os-prober runs and we often need to do so anyway.
> 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.
Or just set CONFIG_FEATURE_MOUNT_LABEL=y in busybox, which adds LABEL
and UUID support.
Frankly, every time I've tried to add a feature to d-i of late that
involved using some non-trivial amount of extra space, I've had to wade
through so many objections about breaking floppy support or old
architectures that I simply gave up. Perhaps that's why I didn't have
much will to try in this case; I've been trying on and off to get enough
busybox features for Kickstart to work for four years ...
--
Colin Watson [cjwatson@debian.org]
Reply to: