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.
"
waiting to happen. Expect to see hosting providers outlaw this quickly, if they haven't done so in their ToSes already.
I look forward to the first web brower implimented using this CGI Shell :)
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.
GET
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.
Nonperiodic Central Trajectory
I'm surprised we haven't seen this come out earlier.. it's always been practical to do, given most free ISPs offer a directory that's flagged executable.
Kudos to these guys who developed this, but I hate to see how this is going to be exploited
"You had this look that of an angel, it was such a bad disguise" --Dishwalla
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.
Go away, or I will replace you with a very small shell script.
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.
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 use it to add ipfwd lines to an internal router box around here. Runs in cgi under apache, lets me type sh commands and see the output.
This is just a new version of an old product, and has the same major problem: "applications interacting with the user (those that ask for input from the user), e.g. passwd are still a problem. "
So it's good for doing a chmod or ipfwd line, but you cant run vi or the like.
How hard would it be to get full terminal emulation through a browser applet?
I don't need no instructions to know how to rock!!!!
I'm no 1337 geek, but it sounds like breakfast to me. Maybe it has something to do with the Slashdot omelette?
... 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
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
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.
You can get more info here.
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:
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
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.
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.
Heh heh he... Chortle chortle...... Evil cackle.
I expect this is a big "if"....
Be nice to people on the way up. You will meet them again on your way down!
Whine whine whine script kiddies paradise, whine whine whine backdoor shenanigans
baka.
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.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
sellinabox.com
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.
--
Violators will be prosecuted and prosecutors will be violated.
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.
Just when you make it idiotproof, some idiot builds a better idiot.
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.
All the best,
--Bob
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.
Crackers've been getting shells via poorly written CGI for years, but now it's news?
ssh java applets exist: http://javassh.org/
I like this idea better than a cgi-bin shell which might pass along naughty combinations of characters, and has everything in plain text to risk snooping.
if lynx and links won't work then screw 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!
/dev/dsp access.
I give the hosted users of my server ssh access for the sole reason that it keeps them from running shit like this.
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
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.
You can't judge a book by the way it wears its hair.
Yeah, you sure wouldn't find it by googling java ssh or maybe by going to javassh.org.
I mean... that would just be too easy and too obvious.
I'll have something intelligent to add one of these days...
Speaking as a Web Host - 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 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/
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."
Convert RSS to HTML - integrate webfeeds into your website
A very quick and dirty Google search 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.
"The dinosaurs died because they didn't have a space program." - Niven
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...
Blessed are the pessimists, for they have made backups.
This has already been done, and better (with SSH support, to boot).
if(!toilet_paper) roll.replace(new roll);
The Java Telnet Application supports SSH, and if you require SSL and password access to the directory in your web server, you can be reasonably secure with the login.
Can You Say Linux? I Knew That You Could.
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.
This IS a good tool.
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/
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.
DO NOT LEAVE IT IS NOT REAL
Versus using the cgi shell program and typing "someEvilCommand -arg1 -arg2" at it's prompt?Before this program, you had to write a script like this (for example):
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
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.
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.
A shell is more than the ability to run simple commands; it provides an environment to run commands, maintain a command-line history, spawn processes, store variables, etc.
And any good CGI Shell should also take output from the system command and format it into HTML that will display in a browser the same as it would in the shell.
Am I missing something here, or is this "cgi shell" thing really not newsworthy?
(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.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
That is its biggest limitation.