oss-sec mailing list archives
Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch
From: Steffen Nurpmeso <steffen () sdaoden eu>
Date: Tue, 16 Jul 2024 01:40:59 +0200
Jacob Bachmeyer wrote in <66946BDB.4070709 () gmail 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)
Current thread:
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch, (continued)
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch Yves-Alexis Perez (Jul 11)
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch Yves-Alexis Perez (Jul 11)
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch Steffen Nurpmeso (Jul 10)
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch David A. Wheeler (Jul 11)
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch Steffen Nurpmeso (Jul 12)
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch Jacob Bachmeyer (Jul 13)
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch Steffen Nurpmeso (Jul 13)
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch Demi Marie Obenour (Jul 14)
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch Steffen Nurpmeso (Jul 15)
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch Jacob Bachmeyer (Jul 14)
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch Steffen Nurpmeso (Jul 15)
- Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch Will Dormann (Jul 30)
