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