Possible security bug with unmount

[Cédric Picard]

Hi,

I find that DIR_unmount_device in wine/dlls/ntdll/directory.c (latest
git) is looking like an unsafe use of system().

If a device was mounted to a point such as ";ls" I think it would be
passed to system and cause a command injection.

I didn't open a bug because I wasn't able to really test it due to my
lack of knowledge of wine and because I can't think of a real world
attack based on this as it needs to mount a device first but I think
it's worth at least a thorough check.

Cédric Picard

[Marcus Meissner]

On Wed, Mar 23, 2016 at 04:57:29PM +0100, Cédric Picard wrote:
> Hi,
>
> I find that DIR_unmount_device in wine/dlls/ntdll/directory.c (latest
> git) is looking like an unsafe use of system().
>
> If a device was mounted to a point such as ";ls" I think it would be
> passed to system and cause a command injection.
>
> I didn't open a bug because I wasn't able to really test it due to my
> lack of knowledge of wine and because I can't think of a real world
> attack based on this as it needs to mount a device first but I think
> it's worth at least a thorough check.

Question is how to reach it... It is determined out of

mount_point = get_device_mount_point ( st.st_rdev )

and not user supplied, but read out of mtab or /proc/mounts .

Ciao, Marcus

[Michael Müller]

Am 23.03.2016 um 17:18 schrieb Marcus Meissner:
> Question is how to reach it... It is determined out of
>
> mount_point = get_device_mount_point ( st.st_rdev )
>
> and not user supplied, but read out of mtab or /proc/mounts .

Not sure if you can consider this a security risk since the windows
application can execute arbitrary opcodes anyway, but constructing such
a case is not difficult:

mkdir "a;xterm"
mount ... "a;xterm"

You will get "/dev/loop0 /home/michael/test/a;xterm iso9660 ro,relatime
0 0" in /etc/mtab or /proc/mounts.

I just tried it out using this code
(https://jon.limedaley.com/code/windows/eject/eject.c) and it will start
xterm.

[Marcus Meissner]

On Wed, Mar 23, 2016 at 05:43:51PM +0100, Michael Müller wrote:
> Am 23.03.2016 um 17:18 schrieb Marcus Meissner:
> > Question is how to reach it... It is determined out of
> >
> > mount_point = get_device_mount_point ( st.st_rdev )
> >
> > and not user supplied, but read out of mtab or /proc/mounts .
>
> Not sure if you can consider this a security risk since the windows
> application can execute arbitrary opcodes anyway, but constructing such
> a case is not difficult:
>
> mkdir "a;xterm"
> mount ... "a;xterm"
>
> You will get "/dev/loop0 /home/michael/test/a;xterm iso9660 ro,relatime
> 0 0" in /etc/mtab or /proc/mounts.
>
> I just tried it out using this code
> (https://jon.limedaley.com/code/windows/eject/eject.c) and it will start
> xterm.

well, as you write ... if you can do such mounts or even execute windows binary code,
then the system() call is harmless.  ;)

Ciao, Marcus

[Vincent Povirk]

It's a potential issue in a situation when you have multiple users on
one machine that are allowed to mount discs or disc images without
root access, or if you have a CD with a malicious label that gets
copied into the mount point (though maybe automounters will escape the
label).

I don't know that this can be turned into a real attack on its own,
but lack of imagination is not a good argument for something not being
a security risk.

[Cédric Picard]

On Wed, Mar 23, 2016 at 12:53:43PM -0500, Vincent Povirk wrote:
> It's a potential issue in a situation when you have multiple users on
> one machine that are allowed to mount discs or disc images without
> root access, or if you have a CD with a malicious label that gets
> copied into the mount point (though maybe automounters will escape the
> label).
>
> I don't know that this can be turned into a real attack on its own,
> but lack of imagination is not a good argument for something not being
> a security risk.

Thanks for your input,

I opened a bug quoting Michael Müller's test-case:

https://bugs.winehq.org/show_bug.cgi?id=40347

Cédric Picard

[Lauri Kenttä]

While security is a good concern, it's not the only concern.

If "mountpoint-with-;ls" would indeed execute ls, it would also
fail to unmount "mountpoint-with-;ls" and instead try to unmount
only "mountpoint-with-". If that's true, the code should be fixed
in any case.

Actually mounting stuff with that kind of names happens easily
with USB drives and udisks2. Like this:

$ ntfslabel /dev/sdb1 "USB;echo foo"
$ udisksctl mount --block-device /dev/sdb1
Mounted /dev/sdb1 at /run/media/user/USB;echo foo.
$ ls /run/media/user
'USB;echo foo'