Re^3: opening files: link checking and race conditions

Because you're still vulnerable to the race condition, it's just very timing dependent. Here's how the timeline falls out. At first, the file doesn't exist.

unless ( -l "foo" ) { # we get here fine
    #*now* the link is created
    open( FH, ">>foo" ) or die "foo: $!";
    #and now it's removed again
}
die "Link attack detected" if ( -l "foo" );
#too late, the link is gone already, so we didn't die.
[download]

Now, it's really, really hard to get the timing to work perfectly for that, but that doesn't mean that it won't happen sometimes. So if you start a program creating and removing the link very quickly, and at the same time run the other program again and again, sooner or later you're going to get unlucky.

Comment on Re^3: opening files: link checking and race conditions Download Code

Replies are listed 'Best First'.
Re^4: opening files: link checking and race conditions by graff (Chancellor) on Aug 03, 2005 at 17:22 UTC
Thank you. The problem with my approach is now clear -- and in the timing scenario you laid out, the script will have no problem writing to that file handle after the second symlink check passes. Once the "open" has succeeded, FH is pointing directly to the actual target file, and deletion of the symlink has no impact on the ability to write successfully to the file. Well then, here's one last try: `unless ( -l "foo" ) { # we get here fine #now the link is created open( FH, ">>foo" ) or die "foo: $!"; #and now it's removed again } die "Link attack detected" if ( -l "foo" or ! -e _ ); # we have checked for both existence and "type == symlink" on the same + stat call, # so either it's a link, or it's non-existent, or it's safe to write o +utput` [download]	[reply] [d/l]
Re^5: opening files: link checking and race conditions by Eimi Metamorphoumai (Deacon) on Aug 03, 2005 at 17:57 UTC
`# we have checked for both existence and "type == symlink" on the same + stat call, # so either it's a link, or it's non-existent, or it's safe to write o +utput` [download] Or you `open`ed the symlink, someone replaced it with a regular file, and you `stat`ted that. Again, you can make it pretty hard to exploit, but you can't get rid of it entirely without either doing it atomically at the time of the `open` (`O_NOFOLLOW`) or can check on the filehandle you actually have open (and not what that name points to now). What might work (but I'm not at all certain) would be to `stat` the filehandle you have open, `stat` the file you thought you opened, and confirm that they have the same inode and that it isn't a symlink.	[reply] [d/l] [select]