in reply to Shell Simulation via CGI

That all seems like overkill when this will do. Name a CGI script nph-my-shell, and put into it: 
#!/bin/sh
exec sh -i

[download]
Then telnet to your webserver, and "GET" the file. Boom, instant shell.

Or at least, that's how I recall doing it. I might be wrong in a detail or two.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Replies are listed 'Best First'.
Re: •Re: Shell Simulation via CGI
by jryan (Vicar) on Feb 04, 2003 at 21:21 UTC

    I think the point is for users who don't have telnet access to their account to have some sort of simulation for it.

    For instance, JoeUser gets a 20-dollar-a-month account at JoeWebHost, and that account doesn't come with shell access. So, JoeUser then uses CGI-Shell to "simulate" it.

    Of course, its still a massive security hole, and I wouldn't be surprised if most hosts deny it in their service agreements.

[reply]
      Of course, its still a massive security hole, and I wouldn't be surprised if most hosts deny it in their service agreements.
      I'd be surprised if you could distinguish this tool from another CGI script in any legally binding way.

      There's no escalation of privilege for me as the CGI uploader, because I can already write scripts that do what I need, albeit not interactively.

      If you're referring to the insecurity of an unsecured CGI script, that insecurity already exists in many scripts, such as the early Matt Wright attempts.

      So, I don't get this "massive security hole" you speak of.

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

[reply]

        With most secrity-flawed CGI scripts, a cracker might suspect a way to execute arbitrary shell commands, but won't know for sure until he successfully does one. However, with CGI-Shell, it is obvious that it is executing shell commands, which gives a cracker much more knowledge for an attack.

[reply]

In Section Cool Uses for Perl