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

Simulation?

[SirTwitchALot]

This doesn't sound like a shell simulation to me, this sounds like another interface to an actual shell. I doubt your hosting company would be very pleased if you installed this.

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.

To Paraphrase Jurrassic Park...

[MidKnight]

... some developer got so excited about what they can do, they forgot to think about if they should.

Just imaging Jeff Goldblum doing his bug-eyed, the-sky-is-falling scientist bit :)

--Mid

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.

just use xterm.

[Anonymous Coward]

Why bother with this when you can just execute an xterm from the CGI program, setting $DISPLAY to your desktop machine? This has been available since day 0 of CGI. Really.

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?

Not to be stupid

[Bob Abooey]

But now that's it 2003 and you can get FREE (as in mp3) *nix pretty why would this or getting a shell account for that matter, even be relevant? I can understand why trying to get a shell account was of value in 1990 but today when you can run *nix at home for FREE I don't get it.

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.

Re:Backdoors

[mobiGeek]

% rm -f -r /

The only thing that should be affected by this is your own web account. If not, then you are paying your hosting service too much!

If you misconfigure this thing, or leave it lying around, or make the password guessable...well, how's this different from having a buggy CGI-script [slashdot.org] or otherwise?

Re:Backdoors

[telecaster]

On your servers and mine...

But...

I once worked on a machine that had "nobody" with write permissions.

I had to explain to the client that because the web server was working fine, that it didn't mean that the security and permissions were in tact.

The admin (a windows guy) decided that since he kept getting the "permission denied" when any web page was displayed, the best thing to do was to give "all access" permissions to "nobody".

Once again, I explained to him that unlike Windows, permissions on Linux and Unix is a bit more flexible and clearly something that shouldn't be taken lightly -- I got this glazed look, and simply fixed it all for him and told him to leave that box alone "and stick with NT".

A CGI to do shell commands. Another thing to worry about on your customer machines...
no thanks

Its only a problem if your web host is a moron...

[bteeter]

Speaking as a Web Host [assortedinternet.com] - I wouldn't mind this one bit. We run suEXEC on our servers, so any commands that they execute under this CGI-Shell would run under their own permissions anyhow.

They can do no worse running this script than they can already do on the command line. Since we use fairly tight permissions on the server, there isn't a lot they can do to disrupt things anyways.

A PHP Shell script [gimpster.com] has been around for a while - THAT version can cause some security issues since typically PHP runs as nobody. Then the trick is making sure nobody doesn't have any special permissions that could cause a server issue.

Basically, if your diligent, this script shouldn't cause any more problems than any other CGI script.

Take care,

Brian
--
http://www.assortedinternet.com/ [assortedinternet.com]

Re:Backdoors

[Anonymous Coward]

Because it allows anyone to run arbitrary code on the server. Yes! Perhaps the "permissions" can be set to forbid certain things from happening, but has that stopped a hacker?

I highly recommend against anyone setting this up on their servers. BAD IDEA!!!

GREAT! Now people will install these stupid CGI's and then we'll REALLY have an epidemic on our hands. It's bad enough having to deal with Micro$lop and their idiotic security policy.

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.

Re:Backdoors

[gl4ss]

so?

the user has already the right to run serverside stuff to run this, so what's the problem?

it's not like you should as a webhoster trust the individual users of you to be competent enough to write secure cgi scripts.

i would kinda think that people would be putting passwords on their cgi-shells, otherwise they could just as well give their ftp passes on their page as well.

Violation of principles

[babbage]

This is a bad idea for the same reasons that routing all traffic through port 80 to get past firewalls is a bad idea. There is a great benefit in knowing that a given port or protocol will have certain properties & not others, and piggybacking other protocols through that channel disrupts & diminishes that benefit. If you want to allow your users access to service X, then give it to them plainly rather than screwing around with things like this. If your ISP prohibits shell access, they aren't just doing it to be mean -- they're trying to protect both themselves & you from negligent or malicious users (and if you yourself happen to be negligent or malicious then this is all the more important, but I know that you're a skilled & benevolent hacker -- this kind of policy is aimed at those other people *wink*).

As others have said, there are so many ways this could be abused, either willfully or by accident. You can make the situation a little bit better by restricting this service to HTTPS sites, certain users or IPs, etc -- but why bother reinventing the wheel when, in the form of SSH (or even Telnet), this is a more or less solved problem?

I do not see this as a good idea for general Geocities styled simple CGI site hosting. It might be useful in certain restricted environments -- your server's co-location facility only allows port 80, but you have VPN access & can usefully tunnel in this way -- but any example I can think of (like the one I just wrote) is pretty contrived & probably full of holes. It is a pretty clever engineering hack, but not one that should probably be released into the wild -- it addresses the wrong problem in the wrong way, albeit cleverly.

No change to the level of security

[DunbarTheInept]

Okay, on order for this program to work, you need to have an ISP that lets you upload any arbitrary CGI script you feel like. So really, how is this a change in the security level??

Before this program, you had to write a script like this (for example):

#!/usr/bin/perl
print "Content-Type: text/html\n";
print "\n";
system( "someEvilCommand -arg1 -arg2" );

Versus using the cgi shell program and typing "someEvilCommand -arg1 -arg2" at it's prompt?

Security VS Convenience

[cornice]

All I'm seeing is posts about how insecure this is. Although I think this could open some holes it really isn't that much worse than some other CGI script. What people fail to realize is that the rights of this script are likely to be near zero. If you don't have shell access then you don't have rights to do much of anything. Thus there really isn't much that you can do with it. For some reason people seem to be thinking "full shell access" and "CGI" at the same time and this really isn't the case. I think this will be useful primarily in situations where you already have shell access, cgi-wrap or suexec, an SSL connection and no access to SSH. For when you're at your new girlfriend's house and you just haven't installed CygWin yet.

Actually what I _really_ wish I could find is a nice, free, secure file transfer program. I use scp but our designer doesn't seem to get it or ssh. I just want a nice gui that he can run on his Mac that is a bit more secure than ftp.

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

Re:Backdoors

[drive]

i'm also a UNIX user but i have to agree with some other posters that ACL's are a good thing. it's one of the MS things (yes, there aren't many) that i like.