Re: Suggestion for clarifications on "man 5 proc" page regarding /proc/[pid]/self race conditions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi ellie,

On Wed, Dec 13, 2023 at 10:31:02AM +0100, Alejandro Colomar wrote:
> I'm going to guess a little bit, from the following script:
> 
> 	$ cat ppe.sh 
> 	#!/home/alx/tmp/bash
> 
> 	f="$(readlink /proc/$$/exe)";
> 
> 	set -x;
> 
> 	mv $f $f.bak;
> 	cp /usr/bin/bash $f;
> 	readlink /proc/$$/exe;
> 
> 	cp /usr/bin/bash $f.bak;
> 	readlink /proc/$$/exe;
> 
> 	rm $f.bak;
> 	readlink /proc/$$/exe;
> 
> 	echo malicious >$f.bak;
> 	readlink /proc/$$/exe;
> 
> 	head -c4 /proc/$$/exe;

On 12/13/23 10:31 AM, Alejandro Colomar wrote:
> There don't seem to be any
> races in open("/proc/[pid]/exe", ...).

ellie wrote:
| Sorry if I'm just confused, but I don't understand how the given test 
| script reproduces or tests anything relevant to a potential open() race.
| 
| The race would work like this:
| 
| 1. Process A issues open("/proc/self/exe")
| 
| 2. Process A's open() on /proc/self/exe heads into whatever libc or 
| kernel path that resolves where that symlink points to a path, if it's 
| treated as one.
| 
| 3. Process scheduler switches to process B.
| 
| 4. Process B switches out process A's binary, such that a different 
| binary is now at the old path.
| 
| 5. Process A's open() code in libc or kernel space resumes and opens the 
| file pointed to by the given path, which is now a new binary.
| 
| I'm pretty sure you can't test that anyway to rule it out, that could 
| only be answered by looking at all the relevant code and whether 
| /proc/self/exe is ever resolved to a path (like I assume an actual 
| symlink usually is) or directly to an inode (which would likely be safe).

I didn't test exactly that, but I proved that it doesn't work like a
symlink.  If it were a simple symlink, my script wouldn't get the new
path of the file after moving or removing it, and the symlink would
become dangling.

Still, the kernel could do the stupid thing: magically update the
symlink when the file changes, but still use a symlink, so open(2) would
still have a race.  I'm assuming the kernel doesn't do that stupid thing.

It must be implemented using the file description, or something like
that, and thus it would be free of races.

Have a lovely day,
Alex

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux