Re: CGI THREAT: Malicious data injection into Perl modules.

From: jon schatz (jon@divisionbyzero.com)
Date: 01/24/02


From: jon schatz <jon@divisionbyzero.com>
To: Onesphorf hass <onesphorf@yahoo.se>
Date: 24 Jan 2002 14:47:38 -0800


On Thu, 2002-01-24 at 06:30, Onesphorf hass wrote:
> Feedback is wanted, I don't consider it done yet :)

Ok.

>If we can trick the CGI
> script to add code into the module, chances are that
> we will be able to execute commands.

Um, if you could actually (remotely) insert code into a perl module,
then the site you speak of has many problems. 99% of admins install perl
modules as root, which should make the files writable only by root. To
insert code into them would imply that your webserver process is also
running as root. Bad idea.

> % nc localhost 80
> GET /cgi-bin/xXXx.pl?user=0nesphorf;'touch /tmp/test'
> HTTP/1.0
> What I did was to include a command with backticks in
> a context
> that the CGI did not expect, which fooled it into
> writing the data
> into the CGI.pm module, which also made it execute the
> command
> due to the backticks which has a special meaning to
> Perl.

I'm not exactly sure what this particular script you speak of does, but
anyone using CGI.pm would most likely use the built-in param() method to
get name:value pairs. And Lincoln Stein is a lot smarter than this.
param() returns the following for your example:

        user = 0nesphorf
        `touch /tmp/test` = undef

Furthermore, in order for this code to execute, it would have to be
eval()'d . And experienced (and even not-so experienced) perl
programmers stay away from eval()ing unverified values.

Even furthermore, taint checking (ie, perl -T) will refuse to execute
this code in an eval block until it has been validated. Experienced perl
coders use taint checking.

So this "new method of CGI exploitation" is nothing more than sloppy
coding on the vendor's side. All data recieved from the network should
be verified by the cgi on the other end. You yourself said this only
works with data that "the CGI did not expect"; it is a programmer's job
to expect everything.

-jon

-- 
jon@divisionbyzero.com || www.divisionbyzero.com
gpg key: www.divisionbyzero.com/pubkey.asc
think i have a virus?: www.divisionbyzero.com/pgp.html
"You are in a twisty little maze of Sendmail rules, all confusing." 




Relevant Pages

  • FAQ 9.1 What is the correct form of response from a CGI script?
    ... This message is one of several periodic postings to comp.lang.perl.misc ... from the documentation provided with Perl. ... What is the correct form of response from a CGI script? ... The Common Gateway Interface (CGI) specifies a software interface ...
    (comp.lang.perl.misc)
  • FAQ 9.1 What is the correct form of response from a CGI script?
    ... This message is one of several periodic postings to comp.lang.perl.misc ... from the documentation provided with Perl. ... What is the correct form of response from a CGI script? ... The Common Gateway Interface (CGI) specifies a software interface ...
    (comp.lang.perl.misc)
  • Re: Help with a stragegy for diagnosis
    ... I have a Perl CGI that has work for years. ... first failure and before the second. ... A strategy would be to write tests for the script until you get the same ...
    (comp.lang.perl.moderated)
  • Re: fail running an external C program into a Perl CGI script
    ... I 'm trying to execute a small C program into the Perl CGI working ... socket lib. ...
    (comp.lang.perl.misc)
  • Re: Need help with CGI/ DBI error (permissions?)
    ... >> My other Perl CGI scripts that don't use DBI run OK, ... > able to telepathically decipher your web server configuration, ... problems with serving up *Perl* pages. ... you just said that your other CGI scripts run fine. ...
    (comp.lang.perl.misc)