Fernando J. Pereda’s blag

May 23, 2008

Security trivia

Filed under: blag — Tags: , — Fernando J. Pereda @ 2:37 pm

Apparently, this kind of issues are difficult to understand. Sometimes, you can pretend they don’t exist, but you want to get rid of them. Security is often about small mistakes here and there that lead to big holes when used together.

So:

  • What’s wrong with this code?
  • What environment do you need to exploit it?
  • Given such an environment, how can you exploit it?
  • How would you fix the code?
[...]
if(-l $statefile) {
        die("$statefile is a symbolic link, refusing to touch it.");
}                               
open (OUT, ">$statefile") or exit 4;
print OUT "$pos:$delivered\n";
[...]

A couple of days ago, I reported a similar issue (which I suspect it can be exploitable) and couldn’t get upstream to fix it (I can’t be bothered with a patch because I don’t use the software anyway). I’m not sure why they didn’t fix it, probably they don’t care about security, or they don’t understand the issue at hand.

I’ll post the answer in a couple of days or whenever someone gets it right.

— ferdy

Advertisements

8 Comments »

  1. ehm… unless the program doesn’t run as the user who uses that program, i can’t really see any problem. the only thing i can spot is the fact that the program doesn’t die on hard links… i’m not very proficient with perl though. looking at perl’s open() documentation, a user could decide to make the file modifications appending, instead of overwriting the file, but that doesn’t really seem exploitable without other exploitable code to me. maybe if the file would not be readable YET, but copied to a (for user of the app) readable file later by the app. that could result in the user getting info he’s not supposed to get. again, i don’t know the specifics of if(-l bla) htough.
    the easiest and dirtiest fix i can see is to refuse a starting “>”, a better one would be to mask out all special chars which are not allowed in file names (> is one of those)

    Comment by tulcod — May 23, 2008 @ 3:44 pm

  2. I’m not sure how close you are, but whatever environment you’d need to exploit it. Just describe it. That’s part of the trivia.

    — ferdy

    Comment by Fernando J. Pereda — May 23, 2008 @ 3:50 pm

  3. any environment in which the running application has more rights than a user, and those rights can be.
    okay, so i just googled around a bit more adn discovered that the open() function also opens pipes and such. in that case, the user can actually get a shell this way, as if he were the user running this application. let’s say the app runs as root (which would be stupid, but still). then the user could get a shell as root by giving the right input to the app. scary.

    Comment by tulcod — May 23, 2008 @ 4:36 pm

  4. s/and those rights can be/an those rights can be exploited for more access/

    Comment by tulcod — May 23, 2008 @ 4:37 pm

  5. It’s a fairly straightforward race-condition file-write bug, AFAICT.

    If an attacker can create the symlink at just the right time (i.e. after the -l, but before the open()), the attacker can get the process to overwrite any file so desired.

    Comment by Andrew Flegg — May 23, 2008 @ 4:38 pm

  6. That’s it. This kind of vulnerabilities are also called TOCTOUs (Time-Of-Check-Time-Of-Use) and, unfortunately, are extremely common and sometimes difficult to get right. I’ll update the post soon.

    — ferdy

    Comment by Fernando J. Pereda — May 23, 2008 @ 7:17 pm

  7. Hm, okay then. But imo, it wasn’t exactly clear that there could have been more tests on the filename (in which case it’s really unclear what really is happening). A user could simply enter some path and have it written to by this script as far as you can tell from the code. imo, my vuln was more scary (if it is a vuln ;-)).
    So in one sentence: it wasn’t clear that this should have been impossible in the first place.

    Comment by tulcod — May 23, 2008 @ 9:27 pm

  8. Somehow i missed the point. Probably lost in translation :) Anyway … nice blog to visit.

    cheers, Sequestrate!!!

    Comment by Sequestrate — June 19, 2008 @ 8:15 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: