in reply to Re: Hacking CGI - security and exploitation
in thread Hacking CGI - security and exploitation

Well, he at least appears to be trying to use imaginary variables. If you change some of them around, you can eventually get a script that works (if you can call it that), you'll also have to run it from the 'accounts' directory, I didn't fix that:

$FORM{'user'} = "cjf";
$FORM{'pass'} = "1234";

# why was the following line there?
# if($FORM{'path'} =~ m/\0|\r|\n/ig){ die "illegal characters"; }

#check for .htaccess file in /home/user/accounts/$FORM{path}
$htaccess = "/home/cjf/accounts/$FORM{user}/.htaccess";

if (-e $htaccess){
    open(HTACCESS, "<", $htaccess) or  die "could not open .htaccess f
+ile";
    # added chomp
    chomp(@lines = <HTACCESS>);
    close(HTACCESS);

    ($correctuser,$correctpassword) = split(/:/,$lines[0]);

    if ($FORM{'user'} eq $correctuser && $FORM{'pass'} eq $correctpass
+word){
        print "access granted";
        access();
    } else {   print "access denied"; }
}
else {
    mkdir($FORM{'user'},0755) or die "error accessing user directory" 
+unless (-d $FORM{user});

    $accessfile = $FORM{'user'} . "/.htaccess";

    # changed $useraccess to $accessfile
    # changed $username to $FORM{'user'}
    # changed $password to $FORM{'pass'}

    open(USERACCESS, ">", $accessfile) or die "could not create user f
+ile";
    print USERACCESS "$FORM{'user'}:$FORM{'pass'}";
    close(USERACCESS);
}

[download]

Now I'm still not sure what he's saying about filename/variable limits in Perl and how they could result in a vulnerability. It certainly doesn't sound accurate. Can someone clarify this?

Replies are listed 'Best First'.
Re: Re: Re: Hacking CGI - security and exploitation
by Anonymous Monk on Jun 25, 2002 at 03:40 UTC
    Any time the system does something the programmer doesn't expect, you have potential problems.

    In this case the programmer is using apparently equivalent file names - one for testing existence of a file and one for creating it. They are not equivalent though because the filesystem limit means that one name is invalid and the other is a file that already exists. So the code thought it was creating a new file to represent a new permission - but instead was replacing an existing access file.

    So yes. The code presented makes the mistake described. But it would be a non-issue without a whole series of supporting mistakes - first and foremost of which is testing a different filename than you are creating!

    Oh, to answer your other question? The "following line" was there because disagreements between Perl and system calls on the meaning of a null byte can cause all sorts of fun. Also shell scripts being confused by returns can cause other fun and games. Those characters were therefore known to be dangerous, and therefore were eliminated.

[reply]

      Thanks for the reply. As for the following:

      # why was the following line there?
# if($FORM{'path'} =~ m/\0|\r|\n/ig){ die "illegal characters"; }

      [download]

      I was wondering why he bothers removing those characters from a variable that is never used. Perhaps he meant $FORM{'user'} in the $htaccess assignment to be $FORM{'path'}?

[reply]
[d/l]
[select]
        You are correct. Hence again he demonstrated how to get security wrong. :-)
[reply]

In Section Meditations