Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Announcements IT Technology

Shell Simulation Via CGI 337

Posted by Hemos from the playing-around dept.
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. "
This discussion has been archived. No new comments can be posted.

Shell Simulation Via CGI More

Shell Simulation Via CGI

Comments Filter:

  • Backdoors (Score:5, Interesting)

    by TheGreek ( 2403 ) on Monday February 03, 2003 @05:23PM (#5217964)
    waiting to happen. Expect to see hosting providers outlaw this quickly, if they haven't done so in their ToSes already.
    • God forbid ISPs actually have to secure their servers, and require that users not cause them to become insecure...how barbaric
    • the first command through your web server:

      % rm -f -r /

      I'll pass...

      • Re:Backdoors (Score:3, Insightful)

        by mobiGeek ( 201274 )
        % rm -f -r /
        The only thing that should be affected by this is your own web account. If not, then you are paying your hosting service too much!

        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:5, Insightful)

      by CaseyB ( 1105 ) on Monday February 03, 2003 @05:45PM (#5218214)
      If the users currently have the ability to FTP CGI scripts to the server and run them, then how is this is any less secure?

    • Is it worse than CGI? (Score:5, Insightful)

      by Zeinfeld ( 263942 ) on Monday February 03, 2003 @06:27PM (#5218552) Homepage
      When Rob and ARI hacked up CGI it was done as an overnight hack in about 18 hours total. It was not a protocol change so it got no security review.

      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)

      by billstewart ( 78916 ) on Monday February 03, 2003 @09:30PM (#5219868) Journal
      It's not a back door, it's a front door. The question is where you are once you walk in the door - chrooted jail, or do you have the run of the house? CGI always offered the possibility of doing lots of things that might be unsafe, and requires administration of systems in a way that restricts the options available to the browser to things that are either relatively safe to the system as a whole or only able to bother the user who installed this in his own directory. You should have done this anyway! And of course, if you're a user, you probably shouldn't install this application on a server you actually care much about until the security features get upgraded a bit.

      (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)

    by Mordac ( 1009 ) on Monday February 03, 2003 @05:24PM (#5217970)
    I look forward to the first web brower implimented using this CGI Shell :)

    • lynx!? (Score:3, Informative)

      by SHEENmaster ( 581283 )
      if lynx and links won't work then screw this!

      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.

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

      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 /dev/dsp access.

      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.
  • We have enough issues with hacking when the kiddies need to exploit buffer overruns to gain shell access ... this is going to make life even more fun :P
    • We have enough issues with hacking when the kiddies need to exploit buffer overruns to gain shell access ... this is going to make life even more fun :P

      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)

    by antis0c ( 133550 )
    Countless local exploits suddenly made available remotely..

  • Doesn't IIS Already Have This? (Score:5, Funny)

    by Aix ( 218662 ) on Monday February 03, 2003 @05:27PM (#5218005) Homepage

    GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+ dir

    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.

    • Put this in your .htaccess file and you might get lucky and give them a taste of their own medicine:

      RedirectMatch permanent (.*)c+dir http://127.0.0.1/scripts/..%255c..%255cwinnt/syste m32/cmd.exe?/c+rundll32.exe+shell32.dll,SHExitWind owsEx%201

      • Does that really work? Is there a way you could make it pop-up a message that says "Your system has a virus" or something like that? That's usually the cause.
      • That's cool and all... but what exactly does it do? Before I stick in my httpd.conf file, I'd like to know what it does...
      • Seeing as the computer causing the log entries in the first place is almost certainly compromised itself, this is probably not a good idea.

        Fun though, thanks.

      • How's about this one:

        RedirectMatch permanent (.*)c+dir http://www.microsoft.com/scripts/..%255c..%255cwin nt/syste m32/cmd.exe?/c+rundll32.exe+shell32.dll,SHExitWind owsEx%201
    • Seriously, though, this is the most hideously insecure thing I have ever heard of.

      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.

    • Actually I'm pretty sure this from a NIMBDA virus or some other variant. I was really paranoid at first when I set up my apache server because lines like that were pretty much the only thing I saw in the access logs. Now that I know what it is I'm not too worried. I wish ISP's would do more to inform their customers that they have viruses on their systems, but imagine how that would go?

  • Surprised... (Score:2, Interesting)

    by unborracho ( 108756 )
    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

    • Re:Surprised... (Score:4, Interesting)

      by Hanno ( 11981 ) on Monday February 03, 2003 @06:24PM (#5218534) Homepage
      I'm surprised we haven't seen this come out earlier..

      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)

    by SirTwitchALot ( 576315 )
    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.
  • Dieses projekten looken a bitt flaken. Das back-dooren nicht poof?

    Relax und watch das blinken cursor.

  • UID issues (Score:5, Interesting)

    by Ryu2 ( 89645 ) on Monday February 03, 2003 @05:29PM (#5218021) Homepage Journal
    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?
  • might as well give you root.

  • Give me a break (Score:3, Insightful)

    by Anonymous Coward on Monday February 03, 2003 @05:31PM (#5218048)
    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.
  • How secure is this? My web host gave me ssh access, but they put my account on a separate server (with all the users who want ssh), and they warned me that they won't honor their uptime guarantee because having ssh reduces the security of the server. It seems like ssh would be a lot more secure than this script.

    Jason
    ProfQuotes [profquotes.com]
    • It's not that ssh itself is the security issue. It's the users. With ssh access, you could do all sorts of things to bring down the server that you couldn't do from the browser.

  • I've used something exatly like this for months (Score:4, Interesting)

    by stratjakt ( 596332 ) on Monday February 03, 2003 @05:32PM (#5218062) Journal
    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?
    • Doesn't need to run vi. An experienced Unix user (with a malicious streak) could easily come up with some sed and awk to muck around with just about anything... keep in mind, if a file can be read by "anybody" (/etc/passwd is one of these), it can be read (via /bin/cat) by "nobody". No they can't get passwords, but it allows them to get the list of users on the box and quickly reduce the # of options when it comes to running passwd dictionary scripts for login attempts.
      • What I use has a list of commands it's allowed to run.

        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 /.'s low standards.
      • Doesn't need to run vi. An experienced Unix user (with a malicious streak) could easily come up with some sed and awk to muck around with just about anything... keep in mind, if a file can be read by "anybody" (/etc/passwd is one of these), it can be read (via /bin/cat) by "nobody". No they can't get passwords, but it allows them to get the list of users on the box and quickly reduce the # of options when it comes to running passwd dictionary scripts for login attempts.

        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.
    • Apparently not very hard [appgate.com].

      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.

  • This would be useful on my server and desktop, when trying to access a shell from my university's computer labs. They essentially block everything to the internet but http traffic.

    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.
    • From the docs:

      • What can CGI-Shell do, what can't it do?

        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.

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

  • Probable hosting service response. (Score:5, Informative)

    by Minupla ( 62455 ) <`moc.liamg' `ta' `alpunim'> on Monday February 03, 2003 @05:36PM (#5218109) Homepage Journal
    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
    • That's the case right now - at most providers you can only run a few preselected scripts. For custom scripts and php you have to pay more. And it's not that insecure either since it'll probably just work with https.
      • I wasn't particularly refering to interception of password information in terms of security. Although a concern, looking at it from an ISP's POV, it doesn't matter much if the user who pays me is trying to leverage to root access on my box or if it's some Man in the Middle who sniffed his password or (more likely then a MitM attack in my estimation) it's some sqript kidd13 who has managed to put a backdoor on my users's windows box. My concern is that if you can run arbitary binaries from anywhere in the path it opens up a whole new realm of local security exploits that many SA's currently just say "Oh well it's not remotely exploitable."

        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
    • Notice the past tense in "ran"... If I'm paying for hosting, it better damn well include CGI. Otherwise, it's like renting a house that doesn't include windows, and closets, yeah, you can live without them, but would you really want to?

    • Banning CGI may not be good for business -- so many people these days are getting websites so they can set up weblogs with Moveable Type or Greymatter -- if CGI weren't allowed there would be no point. And since it seems that everyone and his brother is running a hosting company, the market is probably really competitive right now.

      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)

    by cliveholloway ( 132299 ) on Monday February 03, 2003 @05:39PM (#5218146) Homepage Journal

    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:

    use CGI;
    my $q=CGI->new();
    my $command = $q->param('command')
    $command and print $q->header('text/plain').`$command`."\n" and exit;
    print $q->header.$q->start_html.$q->start_form.$q->textf ield('command').$q->end_form.$q->end_html;

    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 ;-)

    • oops - missed a semicolon after "$q->param('command')"

      clive ;-)

    • shell_exec() [php.net] will do what you want in one line of PHP.
      • Perl's backticks do the same thing as PHP's backticks and shell_exec do. Note that there's a little more to the above script than just the backticks -- it also prints out a form for command input as well and a couple other things.
    • thus proviong that cLive ;-) is a "Perl programmer with half a brain ". ;)
    • You obviously know very little about security. Granted, any sysadmin who lets anyone upload any CGI script is asking for trouble, however the ability to execute commands as the CGI user opens up a whole new can of security worms. Do you not remember all the free shell providers that used to exist? Wonder why they don't anymore? Because it is nigh impossible to secure up a box with shell access. Instead of having to secure your internet facing services you have to secure every single possible hole. You'd have to change root even the most basic system services.

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

  • I had the opposite (Score:5, Insightful)

    by infiniti99 ( 219973 ) <justin@affinix.com> on Monday February 03, 2003 @05:40PM (#5218157) Homepage
    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.
  • every single web server on the face of the planet was just hacked
    • every single web server on the face of the planet was just hacked

      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)

    by Ayanami Rei ( 621112 ) <rayanami AT gmail DOT com> on Monday February 03, 2003 @05:43PM (#5218194) Journal
    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.

  • shellinabox (Score:2, Interesting)

    by idan ( 98190 )
    ... has supported this for a long time:


    sellinabox.com [shellinabox.com]

  • This is news? (Score:4, Insightful)

    by Kryptolus ( 238444 ) on Monday February 03, 2003 @05:44PM (#5218200) Homepage
    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.
  • This seems like a Really Bad Idea(TM).

    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)

    by Bob Abooey ( 224634 )
    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.
  • A more common problem for me is this: I'm at a public terminal somewhere and want to telnet or ssh to my home machine (or some other machine), only to find that the terminal doesn't have a telnet or ssh client on it, only a web browser.

    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.

  • Go figure... (Score:4, Funny)

    by foxtrot ( 14140 ) on Monday February 03, 2003 @05:56PM (#5218310)
    Crackers've been getting shells via poorly written CGI for years, but now it's news?
  • Seriously, this isn't exactly something which hasn't been done before. I remember, back in the day when I had no shell access, finding cgi scripts that did this. A quick check of cgi-resources.com shows one (webrsh [geocities.com]) dating from 1998 which looks to do a lot more than this can. As for security, as long as your webserver can't access/execute anything potentially malicious, then I doubt you have much to fear from this.

  • 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]

  • This clearly doesn't open up any new security holes that weren't already there.

    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?
  • 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."

  • run modified suexec to jail them (Score:4, Interesting)

    by inputsprocket ( 585963 ) on Monday February 03, 2003 @06:13PM (#5218448)
    All my webclients run chrooted in their own environment and these telnet perl scripts can't touch the system. All that is required is a proper user environment for every client, so that they can be jailed effectively by apache, then a modified suexec wrapper compiled into apache. Bing. Perl scripties can have all the shell access they want, but they can only damge their own subsytem and they can't even see the rest of the system. Live a jail should be. cgi-telnet has been around quite a while now, so this isn't really news. One just has to keep one foot ahead of them if shell access restriction is needed. You can download the suexec apache patches here: http://www.yenne.net/ensim/suexec.c.patch http://www.yenne.net/ensim/suexec.h.patch or you can get a precompiled suexec binary here: http://www.yenne.net/ensim/suexec.bin (sum suexec.bin = 44508 12 ) Either route will jail you webclients properly with perl scripts. Wave bye bye to cgi-telnet problems :)

  • Even better; use the Java Telnet Application (Score:3, Informative)

    by macemoneta ( 154740 ) on Monday February 03, 2003 @06:17PM (#5218477) Homepage
    The Java Telnet Application [javassh.org] 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.

  • Violation of principles (Score:3, Insightful)

    by babbage ( 61057 ) <cdeversNO@SPAMcis.usouthal.edu> on Monday February 03, 2003 @06:48PM (#5218718) Homepage Journal
    This is a bad idea for the same reasons that routing all traffic through port 80 to get past firewalls is a bad idea. There is a great benefit in knowing that a given port or protocol will have certain properties & not others, and piggybacking other protocols through that channel disrupts & diminishes that benefit. If you want to allow your users access to service X, then give it to them plainly rather than screwing around with things like this. If your ISP prohibits shell access, they aren't just doing it to be mean -- they're trying to protect both themselves & you from negligent or malicious users (and if you yourself happen to be negligent or malicious then this is all the more important, but I know that you're a skilled & benevolent hacker -- this kind of policy is aimed at those other people *wink*).

    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)

    by DunbarTheInept ( 764 ) on Monday February 03, 2003 @06:52PM (#5218755) Homepage
    Okay, on order for this program to work, you need to have an ISP that lets you upload any arbitrary CGI script you feel like. So really, how is this a change in the security level??


    Before this program, you had to write a script like this (for example):

    #!/usr/bin/perl
    print "Content-Type: text/html\n";
    print "\n";
    system( "someEvilCommand -arg1 -arg2" );
    Versus using the cgi shell program and typing "someEvilCommand -arg1 -arg2" at it's prompt?

  • Security VS Convenience (Score:3, Insightful)

    by cornice ( 9801 ) on Monday February 03, 2003 @06:54PM (#5218771)
    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.

  • Shell != ability to run one command at a time (Score:3, Informative)

    by Colz Grigor ( 126123 ) on Monday February 03, 2003 @09:30PM (#5219863) Homepage
    This CGI program that runs a command via back-ticks (i.e. `ls`) is not a shell by my standards.

    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?

    ::Colz Grigor

  • This is new? (Score:4, Informative)

    by Zone-MR ( 631588 ) <slashdot AT zone-mr DOT net> on Monday February 03, 2003 @10:24PM (#5220100) Homepage
    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.

Slashdot Top Deals

Love may laugh at locksmiths, but he has a profound respect for money bags. -- Sidney Paternoster, "The Folly of the Wise"

Close