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. "

Comments

Give me a break

[Anonymous Coward]

This is such old news, these types of CGIs have been around a while. And for those worried about the security of this - give me a break. All CGIs are potentially dangerous. Just because this one happens to offer an interface that's familiar doesn't make it more dangerous than a CGI with a hidden back door or security hole.

I had the opposite

[infiniti99]

This 'cgi shell' trick is not new. If you have cgi access, then you pretty much have system access. I don't even see the point of providers restricting shell access. Between that and cgi, there's no difference in power, only in convenience.

I once had the opposite problem. About 10 years ago, my ISP gave shell accounts and a web folder, but did not offer cgi. Again, why bother? I got around it rather easily by running my own http server on a non-standard port from my shell account. Then if I wanted to link to a cgi from my web page, I just had to include the ":port" in the URL.

This is news?

[Kryptolus]

Isn't something like this obvious?

Such "shell" CGIs have been around for a while.

I don't see why this ad...i mean...story deserves to be posted.

Re:Backdoors

[CaseyB]

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?

Re:I've used something exatly like this for months

[acroyear]

Doesn't need to run vi. An experienced Unix user (with a malicious streak) could easily come up with some sed and awk to muck around with just about anything... keep in mind, if a file can be read by "anybody" (/etc/passwd is one of these), it can be read (via /bin/cat) by "nobody". No they can't get passwords, but it allows them to get the list of users on the box and quickly reduce the # of options when it comes to running passwd dictionary scripts for login attempts.

Is it worse than CGI?

[Zeinfeld]

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.

This is what perl's safe mode is for

[addikt10]

Perl's safe mode prevents this from executing on the server. Now, if they aren't running Perl in safe mode for their users' CGI scripts, then they have no business having a server on the net.

They do, however.

Front Doors, not Back Doors. Admin work!

[billstewart]

It's not a back door, it's a front door. The question is where you are once you walk in the door - chrooted jail, or do you have the run of the house? CGI always offered the possibility of doing lots of things that might be unsafe, and requires administration of systems in a way that restricts the options available to the browser to things that are either relatively safe to the system as a whole or only able to bother the user who installed this in his own directory. You should have done this anyway! And of course, if you're a user, you probably shouldn't install this application on a server you actually care much about until the security features get upgraded a bit.

(Obviously if your hosting provider uses a Windows system instead of Unix, the answer to "where are you" is "Probably nowhere interesting", though it can probably be adapted to support Windows command line services as well.)