-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Security issue with no check for potential use of dupilcate UUID #3547
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
Comments
I don't think anyone using "user,exec,suid" cares about security and assumes that the system will be protected against anything. |
I'm not sure if it matters if they "care" about security, but since you made that point, most people do not care about security, or really have much knowledge of security beyond thinking they need 3 or 4 different virus scans installed on top of each other. My thinking is that if someone sets up a mount point in /etc/fstab, only a couple of them will even know what those options mean in practice, and many people just turn everything on at once thinking it will make it better, or easier to use. In this case, in their naivety, they may be right, but they also open this gaping security hole. Being why this scenario is relevant. Aside from that, the duplicate UUID being loadable on an existing mount point is the real bug here that's being abused in mount. |
The default is to mount devices for non-root users with "nosuid,noexec,nodev," and this default is there for a good reason. Your scenario would be relevant if we were discussing default behavior. The use case you describe is when an administrator explicitly configures the system to allow non-root users to introduce suid binaries to the system via a vaguely defined filesystem. Note that UUID/LABEL can also be used for removable I do not see a reliable way to protect systems against duplicate UUIDs. It would require introducing a lock for the whole mount operation; otherwise, there will be a race condition between checking for a unique UUID and the actual mount operation. In my opinion, real protection involves configuring the system carefully; nothing will protect you against real mistakes. What I suggest is to highlight this possible issue in the man page to ensure administrators do not do insane things. There are many other things you can do to make your system insecure ... |
If the user has rights to mount the UUID unprivileged then I guess they can also unmount it. |
If a filesystem is generated and a shell's binary is moved to the filesystem, and its permissions are altered to setuid, and it's owned by root, then mounted by a user (this requires the options user,exec,suid all to be set for the UUID in question in
/etc/fstab
), you can pop root by running the shell. Normally you wouldn't be able to make the shell suid(0) on the filesystem because you don't already have root, but if you were to dismount the filesystem, and edit it's containing file by hand, flip the bits, then remount, or generate the filesystem on another machine where you DO have root, then transfer the file over... you can have a filesystem with this scenario without already having root.This also demonstrates the obvious security issues associated with letting a user mount a filesystem that can contain suid binaries. Let it be noted that while this is NOT the default config for mounting a filesystem via
/etc/fstab
, and this is a good thing... the suid/exec options are not usually inherited from anywhere, when people setup their custom mounts in fstab they often create this scenario unknowingly.I think around line ~1065 there should be some sort of check in mount's code to see if a UUID has been duplicated, if it's already mounted at the time of trying to mount another, etc, and this may mitigate this issue. The UUID can be duplicated at time of creation of the filesystem, or even possibly edited in place on the file containing the filesystem (as it can be owned by a user and still work). On running mount, it pulls the evil filesystem via the duplicated UUID in
/etc/fstab
, and mounts over it at the existing mountpoint. Note, this works even if it is already mounted.I have edited the last paragraph about the duplicated UUID vuln for clairity.(29/4/25)
I have written a demo PoC of the scenario:
Some warnings about this code are it temporarily makes the attacking machine ALSO vulnerable to an LPE in the process of making the filesystem! I also tried to do a bit of cleanup, but it's not perfect, don't run this in a production environment (either on the attacking or victim machines). You were warned.
The text was updated successfully, but these errors were encountered: