Posted
by
Hemos
on Monday February 03, 2003 @05:22PM
from the playing-around dept.

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

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

I'm as much of a unix nut as the next guy.. but NT's ACL system is far more robust and flexible than the traditional unix system... hands down.

Example: Can the standard unix permissions give access to everyone in group a,b, and c, except for user x who is also a member of groups b and c, and y, as well as ensuring that z has full access to everything? No, you can't.

If you allow your customers to upload their own cgis, this is merely a tool.

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.

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

I give the hosted users of my server [frob.us] ssh access for the sole reason that it keeps them from running shit like this.

/etc/security/ contains all the settings needed to keep them from fucking stuff up. Before I configured process restrictions a user's chat server spun out of control, eventually spawning so many processes that the mouse didn't get enough processor time to move and there wasn't enough ram to start another login shell or http connection!

Despite the BOFH myths, which I am guilty of perpetuating, not all sysadmins are jackasses. So long as the sysadmin knows you and you promise not to abuse priveledges you can get everything short of root and/dev/dsp access.

If you really need shell access and don't want to risk losing your account just send your sysadmin a thinkgeek caffeine sampler and some shirts. Massive capacity SCSI disks are a great substitute.

I wrote something that does this (win32 only) way back when. Here [theperlguru.com] it is, complete with source code. It doesn't do much anymore, as the security holes exploited by the worms have by and large been patched, without removing the worm.

As I recall, this was covered here on/. before, under vigilantism, relating to Code Red.

Yeah it works--I got some pretty upset phone calls last year at my university, when my box had shut down an NT "corridor" machine to the scripted, dynamic "student accounts pages"... They pulled my internet connection for 3 days (it happened over a weekend) with an order to fix it before they restored my connection.

They also threatened to bill me for their damages--an estimated $700. (I have no idea where they dreamed up that number.)

I'm just too lazy to go find a link--there has been declared today a "low brain activity advisory" by the National Weather Service.:)

Actually I'm pretty sure this from a NIMBDA virus or some other variant. I was really paranoid at first when I set up my apache server because lines like that were pretty much the only thing I saw in the access logs. Now that I know what it is I'm not too worried. I wish ISP's would do more to inform their customers that they have viruses on their systems, but imagine how that would go?

Friends of mine once used a cheapo ISP who did not offer shell access, but who made the mistake of running Apache with root priviledges. They used a similar script years ago to do remote administration of their site on that mis-configured server. They never exploited the security hole, but they always thought it was funny that they had a "limited web account" yet full access to everything on the server.

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?

It's not quite that bad, if you're running Apache either chroot'ed or as 'nobody:nogroup'. Even then, all they need is a small hole in the armor of some other server (sshd? sendmail? gack!)
to knock that out or trojan it.

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.

How secure is this? My web host gave me ssh access, but they put my account on a separate server (with all the users who want ssh), and they warned me that they won't honor their uptime guarantee because having ssh reduces the security of the server. It seems like ssh would be a lot more secure than this script.

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.

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.

Oh yeah. You can upload a CGI script to start an xterm running on the web server displaying on your own workstation. Most people don't block outbound connections on their firewall, and the X11 connection is initiated from within. Nothing's tcp_wrapper'd from localhost, so now you can r00t fingerd, or one of the CDE daemons. You got 5 minutes to do as you please before the CGI times out and the httpd kills you.

This is a cracking tool, plain and simple. I don't understand why Slashdot is promoting it as the greatest thing since sliced bread.

This would be useful on my server and desktop, when trying to access a shell from my university's computer labs. They essentially block everything to the internet but http traffic.

Seeing as how I use my boxen as my development environment, it would be nice to be able to retrieve my assignments from my computer, while in the lab. It'd also be nice to be able to do my assignments on my box while in the lab, but it seems to me that I'd be reloading the page a lot which would become cumbersome.

I had emailed the network admin about this, and his reply was that he had no idea what I was talking about. Which may be good, or may be bad, when I go to talk to him about it.

In the mean time (or if outward ssh access is never granted) this might prove to be a half decent solution.

CGI-Shell allows the execution of any application and any command on the web-server. Various "comfort-features", such as a history and auto-completion with the tabulator are included - CGI-Shell offers in principle the same comfort as any other shell does. Unfortunately, applications interacting with the user (those that ask for input from the user), e.g. passwd are still a problem.

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.

That's the case right now - at most providers you can only run a few preselected scripts. For custom scripts and php you have to pay more. And it's not that insecure either since it'll probably just work with https.

I wasn't particularly refering to interception of password information in terms of security. Although a concern, looking at it from an ISP's POV, it doesn't matter much if the user who pays me is trying to leverage to root access on my box or if it's some Man in the Middle who sniffed his password or (more likely then a MitM attack in my estimation) it's some sqript kidd13 who has managed to put a backdoor on my users's windows box. My concern is that if you can run arbitary binaries from anywhere in the path it opens up a whole new realm of local security exploits that many SA's currently just say "Oh well it's not remotely exploitable."

Not saying its a GOOD security position to ignore exploits that aren't remotely exploitable, just that it appears to be the attitude put forward by the vast majority of sysadmins.

Notice the past tense in "ran"... If I'm paying for hosting, it better damn well include CGI. Otherwise, it's like renting a house that doesn't include windows, and closets, yeah, you can live without them, but would you really want to?

Banning CGI may not be good for business -- so many people these days are getting websites so they can set up weblogs with Moveable Type or Greymatter -- if CGI weren't allowed there would be no point. And since it seems that everyone and his brother is running a hosting company, the market is probably really competitive right now.

It would be cool if there were a way to run each site on a virtual OS, so that rooting one virtual server would have no effect upon the other virtual servers, or the real physical server. Could user-mode Linux be used for this? VMware?

Perl's backticks do the same thing as PHP's backticks and shell_exec do. Note that there's a little more to the above script than just the backticks -- it also prints out a form for command input as well and a couple other things.

You obviously know very little about security. Granted, any sysadmin who lets anyone upload any CGI script is asking for trouble, however the ability to execute commands as the CGI user opens up a whole new can of security worms. Do you not remember all the free shell providers that used to exist? Wonder why they don't anymore? Because it is nigh impossible to secure up a box with shell access. Instead of having to secure your internet facing services you have to secure every single possible hole. You'd have to change root even the most basic system services.

I agree that this is a good thing. I could really use this, But your comment about this only creating security problems on web servers with poor configuration is absolutely inane. If you think you're such a security badass, why don't you let me install and use it on your webserver and see if it creates security issues for you?

And just for your own education, why don't you check out all the application specific non-network related exploits that are posted in droves on bugtraq. All these become network exploitable when you have a shell.

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.

Only if every single webmaster with CGI access installs the !#$$#@&@! thing....

If I were running an ISP, I'd ban this CGI. I would also allow shell access via secure shell, though. If you just run a decently secure OS (OpenBSD, for example), keep on top of security information and patches, and perhaps require an additional small fee for shell access and put the accounts with shell access on a separate server, the security issues with shell access should be manageable.

1) commands run with as much permissions as the perl script itself, including umask. If there just happens to be a local r00t expl0it, well that's too bad. Perhaps it would motivate the server owner to apply some patches. Any damage would be limited to that which can be done with shell access otherwise (which this is supposed to provide). Moreover, it would behoove the owner of said script to make a few simple changes and use a white list of allowed commands or a blacklist of dubious things to prevent shenanigans (IE no eval, command interpolation, or exec, and limiting PATH)

2) htaccess is as secure as telnet (perhaps moreso). I have telnet open to untrusted accounts, and I've not been rooted. The only thing I would complain about is how browsers manage basic auth permissions. I would encourage users to modify the script to remove any weird html and write a user-interface shell script (using curl or something) to provide a pseudo-terminal session. This would prevent the session from being hijacked by browser bugs or by just not closing out of Moz or IE.

3) Finally, there is nothing about this that would prevent you from using SSL... a feature that some sites might provide as a side effect of having a management, ecommerce, or sign-up site hosted on the same machine.

One thing I don't like is the lack of simple console i/o. It would be nice to provide simple console support via HTTP/1.1 streaming and javascript on the client side; it wouldn't be interactive but it could at least emulate things like no-echo with a "password" textbox vs. a normal textbox.It sounds like a lot of work though.

Let's examine some problems, shall we:
-Most servers (if not all) run CGI scripts as a given user (ie: nobody, www, cgi, apache). If that user is a crippled or limited user, then CGI-Shell is useless for running commands other than "ls". If not, then that user could potentially kill things like the server process, which is also bad.
-If all CGI scripts are run as the same user (see above), then anyone has access to files or directories created by another cgi-shell process. After all, they're owned by the same user.
-Cleartext passwords via htpasswd. They didn't even _try_ to use SSL - it's so not hard.
-Man-in-the-middle attack? Anyone could hijack your "shell" session.
-Can anyone say backdoor?

Sure, this is cool to play around with and install on your home machine, but if anyone lets this into a production environment they're on crack. Either install sshd, or don't. But don't try to implement it over CGI.

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.

A more common problem for me is this: I'm at a public terminal somewhere and want to telnet or ssh to my home machine (or some other machine), only to find that the terminal doesn't have a telnet or ssh client on it, only a web browser.

What I'd really like to find is a Java applet installed somewhere (ideally my home machine, but it could really be anywhere) that emulates a telnet/ssh client. That would allow me (and anyone I give htaccess to) to telnet/ssh to anywhere I want, from any terminal that's capable of running Java applets. Such an applet would be so mindbogglingly useful, I'm surprised I've never seen an instance of it yet.

A very quick and dirty Google search [google.com] produced numberous promising links. I tried the mindterm java app on a whim, and it worked quite well. If you are not completely paranoid, you can even use the link on their site to d/l the java applet, rather than taking up space on your web account.

They've been avalible for quite a few years, type "java ssh" into google for a whole mess of them...TightVNC also includes a java client if you want to have a graphical remote connection.I carry a business card size cd with putty and tightVNC and such on it to use most of the time though...

Seriously, this isn't exactly something which hasn't been done before. I remember, back in the day when I had no shell access, finding cgi scripts that did this. A quick check of cgi-resources.com shows one (webrsh [geocities.com]) dating from 1998 which looks to do a lot more than this can.
As for security, as long as your webserver can't access/execute anything potentially malicious, then I doubt you have much to fear from this.

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.

This clearly doesn't open up any new security holes that weren't already there.

Its worse use would be making cracking a box a little more convienient by allowing the hacker to run commands faster. It's best use would be making administering your site a little more convienient if you aren't allowed shell access. There's nothing to get up in arms about.

Isn't slashdot supposed to be an audience that understands both the legitimate and illegitimate uses of technologies. Every tool is a weapon if ya hold it right. Right?

I made a script like this a few years back that I called "Telweb". It was mainly an experiment to see if I could make it work (and for use briefly on a server where I didn't have a shell account). I only ever told one person about it, and hesitated even to do that, because the results if it every got into the wild were "too terrible to imagine."

All my webclients run chrooted in their own environment and these telnet perl scripts can't touch the system.
All that is required is a proper user environment for every client, so that they can be jailed effectively by apache, then a modified suexec wrapper compiled into apache.
Bing. Perl scripties can have all the shell access they want, but they can only damge their own subsytem and they can't even see the rest of the system. Live a jail should be.
cgi-telnet has been around quite a while now, so this isn't really news. One just has to keep one foot ahead of them if shell access restriction is needed.
You can download the suexec apache patches here:
http://www.yenne.net/ensim/suexec.c.patch
http://www.yenne.net/ensim/suexec.h.patch
or you can get a precompiled suexec binary here:
http://www.yenne.net/ensim/suexec.bin
(sum suexec.bin = 44508 12 )
Either route will jail you webclients properly with perl scripts. Wave bye bye to cgi-telnet problems:)

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.

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.

Scripts like this for both perl and PHP have existed for quite some time. They basically rely on one command like exec or system. In essence they just run whatever you pass them and spit out the output.

Since this got so much publicity I was expecting something new, such as the ability to interact with interactive programs. But it seems this one lacks that feature aswell, in essence making it a poor substitute for a real shell. Pico, micq, bitchx, su, passwd, any interactive program is UNUSABLE.

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.

I'm not too familiar with CGI-Shell.. so.. take what I say lightly...
Potential security problems:
-Transmission of your user/pass in clear text (unless the script is ran via HTTPS)
-Bad admins (there are a lot out there) run http as root.. which means root runs the cgi script. Unless the admin digs through the script to make sure it's free of exploits.. (which very few of the admins who run http as root do) it could do something like.. execute the shell as root or execute a priviledged shell (/sbin/sh on sun)
-Even if http is running as it's own user, unless it's started in a chrooted jail, the script will have access to modify stuff the http user owns.. this means the http binaries, logs, etc..
I'm sure there are more things that can be exploited... I'm by far not a security expert.. I do know that reguardless of what kinda CGI script you put in place, it's always opening that much more of your box to a possible exploit.

Oldest IRC channel control bot. The bot logs in, sits in a channel and manages ownership of the channel and protects the channel from take over. A bot of some sort is pretty important if some one plans to run a large channel for any length of time.

The overhead of invoking a CGI script in in the
ballpark of a tenth of a second on a oldish PII-based server. It's much much less if Apache is built with mod_perl. Can you type a command line in less than a tenth of a second? If not, you won't notice.

I don't believe this is any more harmful than a one-line PHP script. As long as the web admins have their servers setup the way they are supposed to, they have nothing to worry about. If the server this script runs on is hackable, it would've been easy to do without this tool already.

This tool is meant to be installed by someone who wants shell access to an account that they already have read and execute access to. If their web account is set up correctly (which it should be if the ISP is worth a damn), then the worst that happens is that the account of the web customer gets compromised...and that is the web customer's fault for installing the script when they don't know what they are doing.

I, for one, am considering using this on a couple of my customers' sites. They are hosted on systems where I can't get shell access. This will let me configure some things on the system without having an identical setup on my own box (or running a bunch of "echo `env | sort`" type CGI scripts)

I won't keep this script around in the account. When I need it I can upload it, do my deeds, and then remove it. I can change passwd each time I re-install.

BTW: I don't consider this any less secure than the (clear-text) FTP access I have to the account. The fact that this program exists means that anyone could have written it (or a similar proggy) and uploaded it to the CGI-BIN directory.

if you click on the "(#5217998 [slashdot.org])" in the header, you'll see that it has 50% flaimbait, 50% moderator (personally, I'd prefer the old absolute count method). This implies 1 flaimbait moderation followed by 1 funny moderation... Net moderation: 0