Slashdot Mirror


Shell Simulation Via CGI

mischi writes "CGI-Shell simulates a shell using CGI. So everybody who has a CGI-directory on a web-server, also has its own shell on it -- comparable with Telnet or SSH. That's really practical, because most webhosters don't offer a shell (for free) -- but do offer CGI. With CGI-Shell you can execute commands, copy files or just explore your webserver. Even a history and auto-completion with tabulator are included. "

11 of 332 comments (clear)

  1. Backdoors by TheGreek · · Score: 5, Interesting

    waiting to happen. Expect to see hosting providers outlaw this quickly, if they haven't done so in their ToSes already.

    1. Re:Backdoors by CaseyB · · Score: 5, Insightful

      If the users currently have the ability to FTP CGI scripts to the server and run them, then how is this is any less secure?

  2. web brower by Mordac · · Score: 5, Funny

    I look forward to the first web brower implimented using this CGI Shell :)

  3. Re:security? by smerritt · · Score: 5, Informative

    Well, most CGIs run as the user ID of the web server, so unless something like Apache's suEXEC is being used, this is no substitute for having genuine shell access.

    If two or more people on a server both install this, they can read and modify each other's files, etc. since the CGIs will be running as the same user.

  4. Doesn't IIS Already Have This? by Aix · · Score: 5, Funny


    GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+ dir

    Someone always seems to be trying to run shell commands on my Apache server. I wish they would realize that Apache doesn't have this "shell" feature.

    Seriously, though, this is the most hideously insecure thing I have ever heard of.

    1. Re:Doesn't IIS Already Have This? by Gudlyf · · Score: 5, Funny
      Put this in your .htaccess file and you might get lucky and give them a taste of their own medicine:

      RedirectMatch permanent (.*)c+dir http://127.0.0.1/scripts/..%255c..%255cwinnt/syste m32/cmd.exe?/c+rundll32.exe+shell32.dll,SHExitWind owsEx%201

      --
      Trolls lurk everywhere. Mod them down.
  5. UID issues by Ryu2 · · Score: 5, Interesting

    Most webserver setups run under a non-priveleged UID of 'nobody' or the like... which means that normally, the web server user would not be able to access files owned by YOUR own UID. Would there be some sort of set-UID involved here?

    --
    There's 10 types of people in this world, those who understand binary and those who don't.
  6. Probable hosting service response. by Minupla · · Score: 5, Informative

    If I were a hosting service, I'd be visiting the creator of that with a LART. The big reason why hosting providers do not generally provide shell accounts is that its much much harder to harden a box against attempts from a non-root user to leverage their access to get root. I predict you'll see a lot of hosting providers move away from allowing CGI because of this and things like it. That was the policy at places I ran. You couldn't put up CGI without paying for one of the sysadmins to do a security check of the script.

    Min

    --
    On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
  7. Stop whinging - this is a good thing by cliveholloway · · Score: 5, Interesting

    Any exploits that this allows idiots/script kiddies to do are exploits that a Perl programmer with half a brain can write in about 6 lines of code:

    use CGI;
    my $q=CGI->new();
    my $command = $q->param('command')
    $command and print $q->header('text/plain').`$command`."\n" and exit;
    print $q->header.$q->start_html.$q->start_form.$q->textf ield('command').$q->end_form.$q->end_html;

    If your web server is so badly configured that this creates security issues for you, you seriously need to read up on security.

    .02

    cLive ;-)

    --
    -- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
  8. Re:security? by Gudlyf · · Score: 5, Informative

    I haven't taken a look at it myself, but my first thought is that this is no more harmful than what any one line PHP script could do. So long as the web admins aren't idiots and have things setup the right way, they should have nothing to worry about.

    --
    Trolls lurk everywhere. Mod them down.
  9. Is it worse than CGI? by Zeinfeld · · Score: 5, Insightful
    When Rob and ARI hacked up CGI it was done as an overnight hack in about 18 hours total. It was not a protocol change so it got no security review.

    My first response was 'you what?'

    Over the next few years we saw countless exploits of the form 'add this to the command line arguments, execute an arbitrary command'.

    This is one reason why I so hate 'its only like what we do before' type security arguments. What you are already doing may be braindamaged.

    People like to complain about IIS security but they fail to acknowledge that the single architectural issue that has led to those exploits is structurally similar to CGI. The game is to persuade a script to execute an arbitrary command.

    Apache has had fewer exploits simply because the bugs are attributed to the braindamaged scripts written by the users.

    If you want to run a secure Web server the thing to do is to turn off all scripting. Compiling the scripts and linking them into the server as a plug in is a lot more satisfactory as an architectural approach, especially if you have ways to reduce the privilleges of that module to least priv.

    --
    Looking for an Information Security student project suggestion?
    Try http://dotcrimeManifesto.com/