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
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.
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!!!!
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
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.
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.
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/
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.