Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re: Re: Hacking CGI - security and exploitation

by cjf (Parson)
on Jun 25, 2002 at 02:41 UTC ( #177006=note: print w/replies, xml ) Need Help??

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); }

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.

      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"; }

      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'}?

        You are correct. Hence again he demonstrated how to get security wrong. :-)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://177006]
[erix]: ah! Those germans again! ... they have a lot to answer for ;-)

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (8)
As of 2018-06-19 09:10 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (111 votes). Check out past polls.