Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Shell Simulation Via CGI

Hemos posted more than 11 years ago | from the playing-around dept.

Programming 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. "

cancel ×

337 comments

Sorry! There are no comments related to the filter you selected.

Backdoors (5, Interesting)

TheGreek (2403) | more than 11 years ago | (#5217964)

waiting to happen. Expect to see hosting providers outlaw this quickly, if they haven't done so in their ToSes already.

yes... (1)

intermodal (534361) | more than 11 years ago | (#5218026)

God forbid ISPs actually have to secure their servers, and require that users not cause them to become insecure...how barbaric

I might cum in through YOUR backdoor, Greek! (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5218073)

I know how you like to wrestle.

This has always been possible (0)

Anonymous Coward | more than 11 years ago | (#5218124)

Nothing new on this, parsing through commands to scripts has always been a possibility, and i used it a lot in my (sorry) grey days..
<? passthru($cmd); ?>

http://.../..php?cmd=ls|sed 's/\n/<br>/g'

Re:Backdoors (2, Funny)

telecaster (468063) | more than 11 years ago | (#5218196)

the first command through your web server:

% rm -f -r /

I'll pass...

Re:Backdoors (0)

Anonymous Coward | more than 11 years ago | (#5218264)

Not going to do much, the web server process shouldn't have write access to anything (other than logs)

Re:Backdoors (5, Insightful)

CaseyB (1105) | more than 11 years ago | (#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?

That solves a lot of problems... (0)

meme_police (645420) | more than 11 years ago | (#5217968)

...but may cause the equivalent amount of security problems.

web brower (5, Funny)

Mordac (1009) | more than 11 years ago | (#5217970)

I look forward to the first web brower implimented using this CGI Shell :)

security? (0)

simpl3x (238301) | more than 11 years ago | (#5217971)

sorry, i am ignorant of the security implications... any comments?

Re:security? (5, Informative)

smerritt (61357) | more than 11 years ago | (#5217991)

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.

Re:security? (5, Informative)

Gudlyf (544445) | more than 11 years ago | (#5218148)

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.

Re:security? (2, Funny)

StressedEd (308123) | more than 11 years ago | (#5218190)

So long as the web admins aren't idiots...
Heh heh he... Chortle chortle...... Evil cackle.


I expect this is a big "if".... ;-)

Re:security? (0)

Anonymous Coward | more than 11 years ago | (#5218218)

sorry, i am ignorant of the security implications... any comments?

Yes, you should be working for Microsoft-- well, once you learn that it's okay to BE security-ignorant, as long as you don't ADMIT to it. :-)

Re:security? (2, Informative)

NivenHuH (579871) | more than 11 years ago | (#5218233)

I'm not too familiar with CGI-Shell.. so.. take what I say lightly... Potential security problems: -Transmission of your user/pass in clear text (unless the script is ran via HTTPS) -Bad admins (there are a lot out there) run http as root.. which means root runs the cgi script. Unless the admin digs through the script to make sure it's free of exploits.. (which very few of the admins who run http as root do) it could do something like.. execute the shell as root or execute a priviledged shell (/sbin/sh on sun) -Even if http is running as it's own user, unless it's started in a chrooted jail, the script will have access to modify stuff the http user owns.. this means the http binaries, logs, etc.. I'm sure there are more things that can be exploited... I'm by far not a security expert.. I do know that reguardless of what kinda CGI script you put in place, it's always opening that much more of your box to a possible exploit.

First post (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5217975)

20, 19, 18, 17, 16....

current version: 0.17a (1)

old7 (564621) | more than 11 years ago | (#5217976)

Let me know when it hits 1.1 and maybe it will be safe. I only see problems with hacking right now. Old7

fp (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5217982)

suck it down!

Security? (1)

amigaluvr (644269) | more than 11 years ago | (#5217983)

Oh now this is a big risk just waiting to happen.

How much energy does a sysadmin put into stopping a system from getting shell accessed via cgi?

and now there's users coming along wanting to get it done for free? Scary stuff. Opens a whole new world of 'risk' up

If there is no security with this (0)

Anonymous Coward | more than 11 years ago | (#5218272)

Then it was never there. CGI's which are written by users can do any of the things this "shell" can. What are you worried about specifically?

ok... (0, Redundant)

TerryAtWork (598364) | more than 11 years ago | (#5217984)

Is this not the ultimate cracker tool you ever saw?

What were they thinking?

Re:ok... (1)

Gudlyf (544445) | more than 11 years ago | (#5218175)

I don't believe this is any more harmful than a one-line PHP script. As long as the web admins have their servers setup the way they are supposed to, they have nothing to worry about. If the server this script runs on is hackable, it would've been easy to do without this tool already.

Thanx, yet another potential exploit! (0)

Anonymous Coward | more than 11 years ago | (#5217986)

This just smells unsecure.

Script Kiddie Paradise (1, Redundant)

slagdogg (549983) | more than 11 years ago | (#5217987)

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

Re:Script Kiddie Paradise (1)

Xerithane (13482) | more than 11 years ago | (#5218232)

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

IN SOVIET RUSSIA (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5217993)

the shell simulates CGI!

Not to mention.. (1, Redundant)

antis0c (133550) | more than 11 years ago | (#5217997)

Countless local exploits suddenly made available remotely..

Re:Not to mention.. (1)

random735 (102808) | more than 11 years ago | (#5218177)

umm, presumably you'd still have to log in to the system. No worse than having telnet (or ssh) open.

WHEN WILL IT SIMULATE WINDOWS XP? (0, Funny)

Anonymous Coward | more than 11 years ago | (#5217998)

So It actually does something useful? Im sick and tired of all you idiots who think a shell is better than a GUI.

Re:WHEN WILL IT SIMULATE WINDOWS XP? (0)

Anonymous Coward | more than 11 years ago | (#5218212)

I guess I do not understand the moderation system here. How does one get Score: 0, Funny?

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

Aix (218662) | more than 11 years ago | (#5218005)


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.

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

Gudlyf (544445) | more than 11 years ago | (#5218224)

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

Re:Doesn't IIS Already Have This? (1)

CaseyB (1105) | more than 11 years ago | (#5218273)

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.

Sl0w (0)

SparafucileMan (544171) | more than 11 years ago | (#5218006)

Isn't this too slow of a shell to be useful except for, say, exploiting for backdoors? I mean hell you might as well be running a shell with the Doom3 engine.

Re:Sl0w (1)

shoppa (464619) | more than 11 years ago | (#5218055)

Isn't this too slow of a shell to be useful

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.

Surprised... (2, Interesting)

unborracho (108756) | more than 11 years ago | (#5218007)

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

Is CGI-Shell secure? (0)

Anonymous Coward | more than 11 years ago | (#5218009)

Sounds great, but this part scares me. Is CGI-Shell secure? At the moment, CGI-Shell is more like Telnet than like SSH. The password-protection is realised with htaccess - so username and password fly without encryption through the web. Also all other communication between you and the web-server not encrypted right now. But I will change this soon.

Re:Is CGI-Shell secure? (1)

NivenHuH (579871) | more than 11 years ago | (#5218082)

Ah.. this is all true for HTTP.. but you could be running everything through HTTPS (which is all encrypted.. including .htaccess)

Re:Is CGI-Shell secure? (try SSL) (1)

Black Copter Control (464012) | more than 11 years ago | (#5218271)

You can get a measure of security by running it under https:

Simulation? (2, Insightful)

SirTwitchALot (576315) | more than 11 years ago | (#5218014)

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.

Shell whores. (1)

termos (634980) | more than 11 years ago | (#5218016)

There is lots of there shell-whores on different IRC networks that is always out after somewhere to run their eggdrop bots. I wonder if this CGI invention will have any impact on that, and maybe some webserver will have to "fix" this in some way.
I am not quite sure, but i would not like if anyone were running a program on my server that was intended for web hosting.

Re:Shell whores. (1)

WetCat (558132) | more than 11 years ago | (#5218050)

Just curious: what is the eggdrop bot?

Re:Shell whores. (2, Funny)

The Bungi (221687) | more than 11 years ago | (#5218089)

what is the eggdrop bot

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

Dave2 Wickham (600202) | more than 11 years ago | (#5218125)

It's an IRC bot - see the official site [eggheads.org] ...

Re:Shell whores. (1)

MindStalker (22827) | more than 11 years ago | (#5218144)

An IRC bot is a program that connects to irc and sometimes pretends to be a real person and sometimes not, but most importantly it keeps channels you create open, and gives you and others ops once you join. They can also do a host of other task, eggdrop is a specific bot, I personally don't know what all it can do but its pretty big from what I've heard.

Re:Shell whores. (3, Informative)

Chaswell (222452) | more than 11 years ago | (#5218145)

Oldest IRC channel control bot. The bot logs in, sits in a channel and manages ownership of the channel and protects the channel from take over. A bot of some sort is pretty important if some one plans to run a large channel for any length of time.

You can get more info here [eggheads.org] .

Re:Shell whores. (1)

Ancil (622971) | more than 11 years ago | (#5218254)

..but i would not like if anyone were running a program on my server that was intended for web hosting

But if you gave them access to a CGI directory, that's already happening.

Achtung! (1)

The Bungi (221687) | more than 11 years ago | (#5218017)

Dieses projekten looken a bitt flaken. Das back-dooren nicht poof?

Relax und watch das blinken cursor.

UID issues (5, Interesting)

Ryu2 (89645) | more than 11 years ago | (#5218021)

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?

Re:UID issues (1)

Oculus Habent (562837) | more than 11 years ago | (#5218158)

you might be able to su to your user - not sure about the details, though.

security (1)

skymester (323871) | more than 11 years ago | (#5218024)

this thing makes a webserver not less secure than without this thing, although this shoulnt be installed just for fun by somebody who hasnt got a clue

you really want to use it via https, if thats not yet implemented in the client they should do it

nice idea

Re:security (0)

Anonymous Coward | more than 11 years ago | (#5218174)

> this thing makes a webserver not less secure than without this thing

Exactly. At least for the sysadmins. This is no different than a user writing a bash script sending it up via ftp and running it. Just more convenient.

Problem is when someone other than the webadmin finds out it is installed. Best thing to do is limit it via IP addr.

What it does (1)

Bisifiniti (635115) | more than 11 years ago | (#5218032)

This only EMULATES a shell. So it'd be very convenient to people more accustomed to a command line interface. Therefore, you can easily code it to check as to what it can and can't do (and combined with .htaccess, it should be secure).

would you like root acct with that? (1)

stonebeat.org (562495) | more than 11 years ago | (#5218039)

might as well give you root.

Re:would you like root acct with that? (1)

theefer (467185) | more than 11 years ago | (#5218111)

I guess (hope) not, it runs as a CGI, thus the shell should be run as the user running the webserver, hopefully not root.

This sounds like a nice voluntary security hole to me anyway.

Re:would you like root acct with that? (1)

shoppa (464619) | more than 11 years ago | (#5218122)

It's not quite that bad, if you're running Apache either chroot'ed or as 'nobody:nogroup'. Even then, all they need is a small hole in the armor of some other server (sshd? sendmail? gack!) to knock that out or trojan it.

Re:would you like root acct with that? (1)

Ballsy (104411) | more than 11 years ago | (#5218150)

Yeah...root....cuz the user 'nobody' can easily gain access to that. Or if the webserver is using suExec, the user account more than likely has access to just su - without any problem. Riiiight...

The Cornhole Connection (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5218044)

(Sung to the tune of "The Rainbow Connection")

Why are there so many
Songs about homos?
Why don't they fucking die?

Someday they'll find it,
The Cornhole Connection
The faggots, the homos and meee

CGI-shell (0)

LoneWlf (228331) | more than 11 years ago | (#5218047)

Yeah, um unsecure as all get out. This can't be truly what was intented... CGI-shell, sounds like a problem to me... really people running a server would never install this. Its a basic security issue waiting to happen... there are definately better ways to get to a shell, this not among the best ones.

LW

Give me a break (3, Insightful)

Anonymous Coward | more than 11 years ago | (#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.

Security (1)

NivenHuH (579871) | more than 11 years ago | (#5218051)

Hmm.. I wonder how many people out there run their web servers as root, blindly install cgi scripts that people ask them to install, and will let one slip by that has their default shell has /sbin/sh (on a sun box).. >=)

Security? (1)

Jason1729 (561790) | more than 11 years ago | (#5218054)

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]

Re:Security? (1)

Oculus Habent (562837) | more than 11 years ago | (#5218189)

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.

Re:Security? (0)

jbottero (585319) | more than 11 years ago | (#5218221)

Then, you are with a LAME web host.

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

stratjakt (596332) | more than 11 years ago | (#5218062)

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?

Re:I've used something exatly like this for months (3, Insightful)

acroyear (5882) | more than 11 years ago | (#5218250)

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.

Re:I've used something exatly like this for months (1)

Christianfreak (100697) | more than 11 years ago | (#5218252)

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.

You need to research this story. (1)

Googol (63685) | more than 11 years ago | (#5218067)


Look at the code.

I mean really... (1)

AssFace (118098) | more than 11 years ago | (#5218072)

I see no way at all this could *ever* lead to any sercurity issues.
things connected to the internet rarely have any real problems with people abusing them, so I don't think this will have any issues at all.

and besides, shells don't let you do much anyways.

Re:I mean really... (1)

stratjakt (596332) | more than 11 years ago | (#5218126)

It's not really a shell.

It's a form that has a text box. You type in "ls ~/" in the text box, hit enter, the cgi script checks to see if it can execute ls, if so, it shell()'s the command, and pipes the output back to the web page.

Its pretty easy to make it as secure as you want.

If you let it run as root and issue any command under the sun, then its a problem. If you let a user just manage the files in his own home directory, it's as secure (even more so) than telnet/ssh access.

funny (1)

Boromir son of Faram (645464) | more than 11 years ago | (#5218075)

I see all these people already complaining about how this is a security risk, because they have this idea that shell == danger and they see the word "shell."

News flash, guys, this is still just a CGI script, meaning it will be run by an unprivelaged user. You won't be able to do anything with this that you couldn't have done with a CGI script before, and it's no more susceptible to being hacked than any other CGI script. Sure there's a security risk, but any time you let clients execute server code you're putting yourself out there. Now chill out.

A CGI shell simulation could save our people, if we use it with wisdom.

Re:funny (1)

The Bungi (221687) | more than 11 years ago | (#5218128)

Is there a new troll sweepstakes whereupon one attempts to build a kind of demented haiku in one's posting history [slashdot.org] ?

It's either that or you need to work on your post titles, Boromir.

Re:funny (1)

leviramsey (248057) | more than 11 years ago | (#5218234)

It's just old friend tps12 (look at the posting style...).

What's the use? (1)

stevejsmith (614145) | more than 11 years ago | (#5218076)

But what can you do with CGI-emulated shell that you can't do with a simple FTP client? If the host bans you from shell access, wouldn't they also ban you from all CGI commands that could do anything that you could potentially do with a shell? And I belive that most TOS strictly forbid this (for no reason other than bandwidth and CPU cycles, because I'd imagine they would have already blocked most naughty things). Besides the "Holy shit, I'm l33t, I'm using a keyboard!" factor, why not just use a fucking FTP client to do chmod and copy files?

Notice that... (0)

Anonymous Coward | more than 11 years ago | (#5218077)

...he doesn't allow cgi-shell running on the same documentation and download site for the program. Not willing to eat one's own dogfood, or just doesn't smell like chicken?

may be useful (1)

kidlinux (2550) | more than 11 years ago | (#5218083)

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.

To Paraphrase Jurrassic Park... (2, Insightful)

MidKnight (19766) | more than 11 years ago | (#5218094)

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

lynx? (0)

Anonymous Coward | more than 11 years ago | (#5218095)

Can it run Lynx?

Applications (1)

Autonymous Toaster (646656) | more than 11 years ago | (#5218107)

While this could be very useful in offering finer control of small dedicated servers (especially in ways that were unenvisioned when the server was created, meaning a predetermined command set couldn't encapsulate all possible uses), I have concerns about security, both in access control and also privacy (sniffing).

For example, if a toaster were controllable via HTTP, the user's toast-making preferences should be held private - indeed this is a sacred rite. For now I think it better to use somewhat more client-heavy schemes such as Java SSH applets [isnetworks.net] . Granted this requires the creation of an account for each user instead of just a CGI directory, but this isn't a great deal more effort, and if you value your users enough to offer them a service (let alone toast!) that effort seems justified.

Probable hosting service response. (5, Informative)

Minupla (62455) | more than 11 years ago | (#5218109)

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

Re:Probable hosting service response. (0)

Anonymous Coward | more than 11 years ago | (#5218151)

If the internet routes around failure, why does "www.microsoft.com" resolve?

Because that's a matter of DNS, not routing. You might mean "...why can I still reach www.microsoft.com?".

Old news (1)

Kenrod (188428) | more than 11 years ago | (#5218120)

My hosting provider offered this type of CGI remote shell several years ago. They stopped offering it after they realized what a dumb fucking idea it was.

If You're With A Web Host... (0)

jbottero (585319) | more than 11 years ago | (#5218130)

That does not offer shell, you're with the wrong web host.

Who it runs as (1)

SirCrashALot (614498) | more than 11 years ago | (#5218140)

My host liquidweb [liquidweb.com] , has a wrapper script that allows your cgi-bin to suid as you. Otherwise it runs as nobody. For instance, I want to have a cgi script that makes changes to my home dir, i can use their wrapper to give it access. In the same way I am sure I could set this up to give me a shell. However, I have an ssh account so it doesn't matter.

Stop whinging - this is a good thing (5, Interesting)

cliveholloway (132299) | more than 11 years ago | (#5218146)

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

Re:Stop whinging - this is a good thing (1)

cliveholloway (132299) | more than 11 years ago | (#5218169)

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

clive ;-)

Re:Stop whinging - this is a good thing (0)

Anonymous Coward | more than 11 years ago | (#5218246)

If your web server is so badly configured that this creates security issues for you, you seriously need to read up on security.
I hope you can sysadmin because you sure as fuck don't write code anyone i know would want to maintain.

I had the opposite (4, Insightful)

infiniti99 (219973) | more than 11 years ago | (#5218157)

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.

Webmin (0)

Anonymous Coward | more than 11 years ago | (#5218159)

I am ignorant of theses types of issues but isn't this just like using Webmin [webmin.com] .

in other news (1)

mrpuffypants (444598) | more than 11 years ago | (#5218165)

every single web server on the face of the planet was just hacked

Just wait.. (0, Offtopic)

grub (11606) | more than 11 years ago | (#5218176)


gobbles will be telling the world about how he h4x0r3d OpenBSD's website with this..

just use xterm. (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5218186)

Why bother with this when you can just execute an xterm from the CGI program, setting $DISPLAY to your desktop machine? This has been available since day 0 of CGI. Really.

CGI (0)

Anonymous Coward | more than 11 years ago | (#5218187)

People still use CGI?

Aren't there many more effective solutions to dynamic pages?

Moreover, it won't be long before this is on a blacklist of scripts.

You people are so negative! (3, Interesting)

Ayanami Rei (621112) | more than 11 years ago | (#5218194)

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 (2, Interesting)

idan (98190) | more than 11 years ago | (#5218195)

... has supported this for a long time:


sellinabox.com [shellinabox.com]

This is news? (4, Insightful)

Kryptolus (238444) | more than 11 years ago | (#5218200)

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.

Whose bright idea was this? (1, Redundant)

jdreed1024 (443938) | more than 11 years ago | (#5218201)

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

But... (1)

dze (89612) | more than 11 years ago | (#5218216)

Would this not be reasonably secure if SSL was enabled? It's not like you are getting any extra functionality. If you have CGI access you can always upload a perl script or whatever and run arbitrary system commands.

Not to be stupid (2, Insightful)

Bob Abooey (224634) | more than 11 years ago | (#5218236)

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.

Not a huge deal... (1)

malfunct (120790) | more than 11 years ago | (#5218275)

I was able to write this sort of shell script ages ago (maybe not use a real shell but execute commands just fine) but I never would because it opens your server right up. I doubt many hosts will let you run this script for long.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?