Shell Simulation Via CGI 337
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.
"
Backdoors (Score:5, Interesting)
Surprised... (Score:2, Interesting)
Kudos to these guys who developed this, but I hate to see how this is going to be exploited
UID issues (Score:5, Interesting)
I've used something exatly like this for months (Score:4, Interesting)
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?
Stop whinging - this is a good thing (Score:5, Interesting)
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 ;-)
You people are so negative! (Score:4, Interesting)
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.
shellinabox (Score:2, Interesting)
sellinabox.com [shellinabox.com]
A pretty neat idea, actually. (Score:3, Interesting)
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.
Been there, done that (Score:2, Interesting)
run modified suexec to jail them (Score:4, Interesting)
Re:Surprised... (Score:4, Interesting)
I'm surprised this is considered news, since it's an age-old idea.
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.
Re:Doesn't IIS Already Have This? (Score:3, Interesting)
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. :)
Re:Backdoors (Score:2, Interesting)
Re:Doesn't IIS Already Have This? (Score:3, Interesting)
Re:Backdoors (Score:3, Interesting)
Directory X:
Group A has read
Group B has read/write
Group C has write
Group D (not owner) can assign permissions
User Z (A member of C) needs read/write