[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240715234059.ThiJfcS3@steffen%sdaoden.eu>
Date: Tue, 16 Jul 2024 01:40:59 +0200
From: Steffen Nurpmeso <steffen@...oden.eu>
To: oss-security@...ts.openwall.com
Subject: Re: ASLRn't is still alive and well on x86
kernels, despite CVE-2024-26621 patch
Jacob Bachmeyer wrote in
<66946BDB.4070709@...il.com>:
|Steffen Nurpmeso wrote:
|> [...]
|>
|> Some findings:
|> . I note that the mentioned files are writable by only root (and
|> i would assume MAP_DENYWRITE to only work if i could do so
|> myself).
|>
|
|I believe that most executables are writable only by root, but available
|to unprivileged users. Since the purpose of MAP_DENYWRITE seems to have
|been ensuring that executables cannot change out from underneath running
|programs, it would need to work when unprivileged users map the file;
|thus the DoS problem.
I have to reread mandatory-locking.txt and locks.txt from Linux
src. I just realized that lslocks(1) aka /proc/locks shows me
locks held by PID 1130 which "i" cannot see due to
$ findmnt /proc
TARGET SOURCE FSTYPE OPTIONS
/proc none proc rw,nosuid,nodev,noexec,relatime,gid=10,hidepid=invisible
$ cat /proc/locks
1: FLOCK ADVISORY WRITE 1130 00:15:354719 0 EOF
2: FLOCK ADVISORY WRITE 1130 00:15:354609 0 EOF
I have the gut feeling in the end there will be nothing in /proc
nor /sys.
|> . Capabilities have become more fine-grained.
|> . I always whimper when i have to rm(1) a running executable before
|> placing an updated variant on Linux, on BSDs i simply over-cp(1)
|> (and i do not understand as long as one gets either the one or
|> the other when executing the path).
|>
|Simple solution:
| - write the new executable under a temporary name
| - use link(2) to create a new name for the existing executable
| - use rename(2) to atomically replace the existing executable
| - use unlink(2) to remove the old version after any needed checks
|
|You can dispense with link(2) and unlink(2) if you do not want to
|preserve a backup of the old executable. Using this method will change
|the executable's inode number (meaning that it really is a different
|file) and that means that the old version can remain on disk for as long
|as it remains in use, even after its last name has been removed.
Thank you. Whimpering is not that bad, The Cure boys were crying.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
