mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #1158] Root priv esc via tmpfs TOCTOU #797
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#797
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mcarpenter on GitHub (Mar 25, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1158
There's a TOCTOU attack possible using
--tmpfsnow that it can be used on a user-controlled directory under$HOME(commit22414adf2a). I have a working exploit for this that I can share with committers but the essence is:--tmpfspointing to a subdirectory of$HOME.tmpfsdirectory is checked early./etc).tmpfsis mounted over this target location. From inside the jail this is empty and writable by the non-privileged attacker. Targetting eg/etcone can easily obtain a root shell and escape with it from the jail. (nosuidon the mounted file systems was a good attempted mitigation for this scenario but there are ways around it).I have tested against the most recent commit.
@netblue30 commented on GitHub (Mar 25, 2017):
Big thanks! Reverted back - tmpfs allowed only to superuser.
Question: would this be even possible to implement? Something like a link check before, mount, and another link check? I put something here:
1375682920@mcarpenter commented on GitHub (Mar 27, 2017):
Thanks for reverting. I misread
git tag -lon Friday (lexicographic ordering, meh, and the tag for 9.44.9 is missing?) so I think22414admade it into 9.44.10? I will request a CVE.Given there is no atomic "check then mount" option this is always going to be racy (unsafe). I'd advise against it. You can't even
open()the mount point, check that and then pass the FD tofmount()(doesn't exist...), and the mount point is hidden when mount succeeds. You might be able to minimize the exposure (eg checkISDIRusinglstat()rather thanstat()) but not in a way that is 100% bullet proof. There will always be some gap (race) in pre-check/mount/post-check.There's a nice comment on a similar problem from @solardiz that I happened to read last week that covers some other issues (eg information leak). I can't link directly to that comment but look for "fix this issue" at https://hackerone.com/reports/204802#activity-1478225 .
@mcarpenter commented on GitHub (Mar 27, 2017):
Change was in dev branch only -- CVE not requested.
@netblue30 commented on GitHub (Mar 27, 2017):
Yes, this tmpfs thing is something new. I gave up on it, it will create too many problems. I also cleaned up my attempt to put a tmpfs on ~/.cache directory. Thank you for your input and let me know if you run in something else.