|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:exec: Fix ToCToU between perm check and set-uid/gid usageWhen opening a file for exec via do_filp_open(), permission checking isdone against the file's metadata at that moment, and on success, a filepointer is passed back. Much later in the execve() code path, the filemetadata (specifically mode, uid, and gid) is used to determine if/howto set the uid and gid. However, those values may have changed since thepermissions check, meaning the execution may gain unintended privileges.For example, if a file could change permissions from executable and notset-id:---------x 1 root root 16048 Aug 7 13:16 targetto set-id and non-executable:---S------ 1 root root 16048 Aug 7 13:16 targetit is possible to gain root privileges when execution should have beendisallowed.While this race condition is rare in real-world scenarios, it has beenobserved (and proven exploitable) when package managers are updatingthe setuid bits of installed programs. Such files start with beingworld-executable but then are adjusted to be group-exec with a set-uidbit. For example, "chmod o-x,u+s target" makes "target" executable onlyby uid "root" and gid "cdrom", while also becoming setuid-root:-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 targetbecomes:-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 targetBut racing the chmod means users without group "cdrom" membership canget the permission to execute "target" just before the chmod, and whenthe chmod finishes, the exec reaches brpm_fill_uid(), and performs thesetuid to root, violating the expressed authorization of "only cdromgroup members can setuid to root".Re-check that we still have execute permissions in case the metadatahas changed. It would be better to keep a copy from the perm-check time,but until we can do that refactoring, the least-bad option is to do afull inode_permission() call (under inode lock). It is understood thatthis is safe against dead-locks, but hardly optimal.
|
