Slashdot Mirror
Details of the PCWeek Securelinux Crack
gleam writes "The guy who cracked the secure Linux box has posted how he did it. It's a rather interesting read, and it does use a crontab exploit that is present in all versions of RH. " Much more detail then the original story had.
(1) There were two separate vulnerabilities in the CGI: insufficient checking on user input, and failure to check the return value of "rename."
These were very subtle programming errors, and it took a great deal of cleverness to exploit them.
(2) There was a serious bit of misconfiguration on the part of the server itself: jfs couldn't overwrite index.html as nobody, but he could overwrite advisory.cgi!
Sorry PC Week, but this is covered in Webmaster 101. Never, ever, have any web-accessible file or directory writable by the user that httpd runs as!
(3) There was the vixie-cron exploit. This is the only part that could blamed on Linux.
--
Was the test fair? Ask yourself why PC Week set up the Linux box with a $150 CGI script that allowed upload of binary files (GIFs) whereas the Windows machine only had a glorified guestbook - no GIFs, no uploads at all - that in any case was customized by Microsoft itself.
How many sysadmins are going to have the resources to call up Bill Gates and say, "Bill, I need a custom app, can you guys write me one?" And are we supposed to believe that the same sysadmins have so little resources that they have to buy their Linux applications from a company whose FAQ has questions like "What if I don't have 'telnet' access to my web site?"
Jamie McCarthy
Jamie McCarthy
jamie.mccarthy.vg
I think PCWeek had the responsibility to apply all the updates that were on the RH site before they put this box online... I mean, what if the NT box had not had any service packs updated on it? Microsoft would be crying bloody murder...
:/ (Well... maybe... )
Geez, I coulda won the box. I never thought to try to exploit the KNOWN, FIXED, UPDATED bugs.
However, pointing all this out makes the Linux crowd look like whiners. Ah well, water under the bridge. Do it again in 6 months.
To all the people saying "just cope", are you reading the same page I was?
Any time, IMHO, something is exploited based on a known, corrected bug, then its the fault of the person driving, not the car (so to speak); if GM issues a recall, and you don't go get your car fixed and then the next day you get in a wreck and something bad happens as a result of the defect, ITS YOUR OWN DAMN FAULT (unless it happened on the way to the dealership, I guess) and not the fault of the car.
How would the page read, had the admin(s) kept it totally up to date and patched? And not used a non-open CGI?
Lets see a "crack this box" challenge run by Linux people, skilled admins.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
There were so many - "An admin can not be expected to read mailing lists for 2 hours or more a day to keep up with security issues with his/her out of the box linux distributions" threads I got sick of it and desided not to respond directly
First off - if your handed even a SINGLE let along HUNDREDS of computers to admin that have a network connection - and your not at least subscribed to the announce mailing list from your respective vendor -- then you deserve to be hacked and then fired to return to your much more realistic job fliping burgers down and your locak fry shack
Secondly - redhat -- or any other rpm based system -- is NOT hard to keep updated to the latest security fixed packages. The first thing you need to do when you install any system is unplug the network cable. You don't need to have it pluged in to set up the network, unless your doing a network install - and you just unplug it once you get finished and have a login prompt. You can then either go download via another system the entire updates dir for your vendor and then use something like a jazz disk or zip drive if your uber paranoid.
Personaly I do almost all my redhat installs via a T1 and the ftp install option, then install autorpm from disk - or if I'm feeling lucky I leave the network cable pluged in and download it from the net. Then I set it to install automaticaly each night any new rpms from the updates dir for my version, save things like the kernel and libc, and you can even set it to check the package sigs.
So by the time I come in and read a bugtrack post - in this case the cron exploit - it's already been patched.
Now the paranoid among you will say that this then could leave you open to spoofing or somone hacking redhat or another vendor and trojoning everyone.
A] That's just as likely as to happen to MS with it's NT service packs. And it's happend before with a few open source packages. But due to the checksums and the sigs on the packages being off - it was discovered after only a few people had downloaded them.
B] You can set it to download, but not install - and it e-mails you a nice little note to read in the morning when you come in that there are updated filesm, and you can then search the bugtrack list for what was wrong with the old version - or hopefuly you already have mail waiting from the announcement e-mail list giving you the details.
This is exactly what happend with all my redhat boxen when this exploit came out, they automagickaly upgraded and e-mailed me about it, read the security e-mail from redhat and finished my coffee and went back to work.
--
James Michael Keller
"Linux is not our destination, it is simply the open road to tommorow"
So Wise Guy, how do I get on Microsoft's program to get their Hot Fixes beamed to me? Right now keeping up with security vulnerabilities on NT requires subscribing to the ntbugtraq.com, list, and searching Microsoft's site. That sure is a pain, but the alternative is waiting around for Service Packs. At least Windows 98 has the Critical Notification Update thingie which helps.
Red Hat has a page that can be monitered, and an e-mail list. And if that's not what you want, you can let someone else bundle the fixes together for you in something like MS' service packs. Try LSL for example.
I don't know about you, but I'll take keeping Red Hat up to date over NT any day.
-Brent--
"Our problems do bring up some of the issues with deploying open source software. We have no doubt that had the hacker that compromised our system not had access to the source of our scripts it would have been impossible for him to get in.
This from their Web page is wrong, unfortunately. It's the same thing mainframe programmers have been saying about their completely closed-source systems since the early 70s. The cracker can find out the package they were using, and can buy it himself. Had the source been completely unavailable to him he would have had to resort to the old method of experimenting with it, poking it to see what happened and using the debugger, but eventually he would have found the hole just as thousands of crackers have found holes in closed-source systems before him.
And I find their use of a stock install without security patches anything but "typical". I had it pounded into me in high school that computer installations should keep up with security patches because of the potential to attack. And yes, this was in a business-related course, not a techie one.
This is funny!
I read other posts about how open source was a cause for finding the CGI "bug". And others who say that the PC Week admin should have read the bug traq and updated their installation.
But no where did I see anyone mention that the posted bug report was used by the cracker!
He said, after finding the exploit in the CGI script, he looked up ways to crack it. Then he found the crontab thingy in the bugtraq report.
So if you don't read the bugtraq, you are very susceptible to attacks because the crackers are reading them!
Food for thought
Steven Rostedt
Steven Rostedt
-- Nevermind
What it does show is that, although Linux is more secure than NT off the shelf, both still require a sysadmin that does his research throughly and keeps up with bug fixes. Still, if this was on Bugtraq a month ago, I consider that someone at PC Week didn't do their homework. I don't think it warrants the conspiracy theories laying around, because the security hole was obscure enough; by this I mean that there was still the matter of replacing a cgi script through a commercial script.
So, well; let's take it with head high. Linux lost. I still think the competition wasn't representative, but in this case, Linux did lose to NT in a cracking race. We'd need to run the test on a thousand different machines to get significance, but still. These things happen, and as so many people have said, a box is only as secure as its sysadmin.
"There is no surer way to ruin a good discussion than to contaminate it with the facts."
Argh, when will people learn that security through obscurity is not security. Had photoad been closed source, the exploit still would have existed, but would have been much harder to find. However, if someone had stumbled across it, they could have exploited it maliciously for a while without people knowing.
The open source model allows for this type of code review, which leads to products with better security.
well, if cars developed at the same rate as computers, today we'd all be driving a 100$ rolls royce that could go from 0-60 in 3 seconds, get 100 miles a gallon, and would explode twice a year killing everyone inside, as the proverb goes.
Is this in the errata? How easy is this to fix? Is there an updated package to fix this exploit, and where can we get it? If someone knows, please list the steps to find and get the fix for this particular exploit. I'd like to think the information wouldn't be hard to find and PCWeek dropped the ball again. They apparently blocked the IIS hack, so any standard RedHat bugfix should have been blocked too. Right?
I found the article and test very intesting. I don't buy the conspiracy theory at all. IMHO the test is a valid one - what would the experience by of a "typical" Corporate type user who sets up a web server.
If you read the article about the test on the box - they go to great lengths to stress that this test doesn't say that NT is better or more secure than Linux.
The article closes with an interesting point - about security through obscurity...
(From their web page)
"Our problems do bring up some of the issues with deploying open source software. We have no doubt that had the hacker that compromised our system not had access to the source of our scripts it would have been impossible for him to get in. However our scripts weren't fully open source and thus not fully open to peer review. However peer review only matters if smart people are looking at the code, and the question of security via obscurity still persists."
Look, it may be a "well known bug", but it's still a gaping security hole that got installed with the default RedHat distro. I can foresee a *lot* of situations where this sort of thing would bite a company on the ass. Maybe I'm a new admin. Maybe I'm busy and don't keep up on the latest bug reports. Maybe I just forgot or didn't know how to work around it. The point is, this isn't something I should have to deal with.
I am so sick of the whining wannabes who seem to be pervading the Linux community lately. It used to be that when someone pointed out a flaw, it was put on a TODO list someplace and fixed; now we just post it up to Slashdot and have everyone yell "This is FUD! PCWeek Sux! I'm 3L337".
The facts stand as they are: PCWeek installed a default RedHat system and it got cracked. No matter how many times you yell "FUD", this is still a Very Bad Thing(tm). Much like the Mindcraft tests (the second round, anyhow), this shows weaknesses in Linux (or in this case, the most popular distro). These things should be addressed, not spun. Spinning probems or denying their existance is not what makes OSS great.
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
1. Somebody pointed out that the Linux distribution used is more secure than the boxed set NT distribution. Paranoid as I am, no system is stronger than it's weakest flaw. NT may have many, but frankly, so does Red Hat. They might not be too many, but they are there.
2. I agree totally with the people saying that PC Week had done more work with the NT box, than with the Linux one. In fact, this kind of press coverage is only looking bad on PC Week. I remember I saw a full page with documentation on how they set up the NT box. Steps on how they applied the service packs and all. I couldn't find one note on how the Linux box was configured. I think that one that knows how to do so much research on NT, should be able to read webpages and mailinglists for Linux issues.
3. The most important issue. What did this teach us? PC Week actually brought to light that too many Linux users are ignorant about their security. I remember reading an article in a major PC magazine about firewalls. They brought up different products. Linux based solutions got good security remarks, just because, they were Linux. And NT based ones got bad, because they were NT based. This is not good journalism. Perhaps it is all time that we do more extensive security auditing on our boxes...
Sincerely,
Alexander
Wealth is the product of man's capacity to think. -Ayn Rand
I posted this originaly on their forum but it should work here too.
Look I am rather upset with this continued premise that "Redhat is Linux". It is not.
I use Debian, it works well and is generally more secure then RedHat.
On http://www.hackpcweek.com/learned.html
You state
"During these tests many people have criticized us for not applying the twenty-one security patches that currently exist for Red Hat 6.0. However, their omission serves to illustrate our
point. We only installed shipping software available from the vendors for this test (other than the applications of course). No hot fixes were applied to the NT server. We did however install
service pack five. This was much easier because it was a single file."
Using Debian and deselect (deselect is the standard package manipulation tool) getting security updates is EASIER than getting and installing a Service Pack, Hell you dont even have to reboot.
This still would of not of fixed the CGI exploit, it just would of made it that much harder to be rooted.
Remember Red Hat is NOT Linux.
"Think of it as evolution in action."
That was posted to bugtraq almost a month ago - complete with fix. Now... who's at fault - Redhat, or the people who put this contest on with a box stock system with known vulnerabilies? Check it out:
- ---------------------
- ---------------------
e -cron-3.0.1-36.4.2.i386.rpm
i e-cron-3.0.1-36.4.2.alpha.rpm
i e-cron-3.0.1-36.4.2.sparc.rpm
i e-cron-3.0.1-36.4.2.src.rpm
e -cron-3.0.1-36.5.2.i386.rpm
i e-cron-3.0.1-36.5.2.alpha.rpm
i e-cron-3.0.1-36.5.2.sparc.rpm
i e-cron-3.0.1-36.5.2.src.rpm
e -cron-3.0.1-37.i386.rpm
i e-cron-3.0.1-37.alpha.rpm
i e-cron-3.0.1-37.sparc.rpm
i e-cron-3.0.1-37.src.rpm
- --------------------------
/dev/null
-----------------------------------------------
Red Hat, Inc. Security Advisory
Synopsis: Buffer overflow in cron daemon
Advisory ID: RHSA-1999:030-01
Issue date: 1999-08-25
Updated on:
Keywords: vixie-cron crond MAILTO
Cross references:
-----------------------------------------------
1. Topic:
A buffer overflow exists in crond, the cron daemon. This
could allow local users to gain privilege.
2. Bug IDs fixed (http://developer.redhat.com/bugzilla/):
4706
3. Relevant releases/architectures:
Red Hat Linux 4.2, 5.2, 6.0, all architectures
4. Obsoleted by:
5. Conflicts with:
6. RPMs required:
Red Hat Linux 4.2:
Intel:
rpm -Uvh ftp://ftp.redhat.com/redhat/updates/4.2/i386/vixi
Alpha:
rpm -Uvh ftp://ftp.redhat.com/redhat/updates/4.2/alpha/vix
Sparc:
rpm -Uvh ftp://ftp.redhat.com/redhat/updates/4.2/sparc/vix
Source packages:
rpm -Uvh ftp://ftp.redhat.com/redhat/updates/4.2/SRPMS/vix
Red Hat Linux 5.2:
Intel:
rpm -Uvh ftp://ftp.redhat.com/redhat/updates/5.2/i386/vixi
Alpha:
rpm -Uvh ftp://ftp.redhat.com/redhat/updates/5.2/alpha/vix
Sparc:
rpm -Uvh ftp://ftp.redhat.com/redhat/updates/5.2/sparc/vix
Source packages:
rpm -Uvh ftp://ftp.redhat.com/redhat/updates/5.2/SRPMS/vix
Red Hat Linux 6.0:
Intel:
rpm -Uvh ftp://ftp.redhat.com/redhat/updates/6.0/i386/vixi
Alpha:
rpm -Uvh ftp://ftp.redhat.com/redhat/updates/6.0/alpha/vix
Sparc:
rpm -Uvh ftp://ftp.redhat.com/redhat/updates/6.0/sparc/vix
Source packages:
rpm -Uvh ftp://ftp.redhat.com/redhat/updates/6.0/SRPMS/vix
7. Problem description:
By creating a crontab that runs with a specially formatted
'MAILTO' environment variable, it is possible for local users
to overflow a fixed-length buffer in the cron daemon's
cron_popen() function. Since the cron daemon runs as root,
it would be theoretcially possible for local users to use
this buffer overflow to gain root privilege.
To the best of our knowledge, no known exploits exist
at this time.
Also, it was possible to use specially formatted 'MAILTO'
environment variables to send commands to sendmail.
8. Solution:
For each RPM for your particular architecture, run:
rpm -Uvh
where filename is the name of the RPM.
9. Verification:
MD5 sum Package Name
-----------------------------------------------
a90bf7adbc719fdb5a8ed335fda32a3c i386/vixie-cron-3.0.1-36.4.2.i386.rpm
2b6b0b00cdeca0381ab2893ddf2f2bd1 alpha/vixie-cron-3.0.1-36.4.2.alpha.rpm
02d183979b594a7e7a9c1bc8566b2f16 sparc/vixie-cron-3.0.1-36.4.2.sparc.rpm
b8ac0c21e108ebd67925c224f7a0b82b SRPMS/vixie-cron-3.0.1-36.4.2.src.rpm
7df6884f0709b078d19f390db2a7e304 i386/vixie-cron-3.0.1-36.5.2.i386.rpm
b51b4ea612c4f5a59c1bb4e76af95eeb alpha/vixie-cron-3.0.1-36.5.2.alpha.rpm
5ceeb614442bd4d4ce8a9680664d77e4 sparc/vixie-cron-3.0.1-36.5.2.sparc.rpm
9f411cb3c7c1c53423eebc9d5f64619a SRPMS/vixie-cron-3.0.1-36.5.2.src.rpm
39bbedeade7dc6da6f0ab5acfb3af6da i386/vixie-cron-3.0.1-37.i386.rpm
addec82afbd131aef14fadf8cfb8ddcf alpha/vixie-cron-3.0.1-37.alpha.rpm
b56db77c411f72825efbffed43780213 sparc/vixie-cron-3.0.1-37.sparc.rpm
243d9099bdb94bd0d075de4da4dbba12 SRPMS/vixie-cron-3.0.1-37.src.rpm
These packages are PGP signed by Red Hat Inc. for security. Our key
is available at:
http://www.redhat.com/corp/contact.html
You can verify each package with the following command:
rpm --checksig
If you only wish to verify that each package has not been corrupted or
tampered with, examine only the md5sum with the following command:
rpm --checksig --nopgp
10. References:
--
To unsubscribe: mail redhat-watch-list-request@redhat.com with
"unsubscribe" as the Subject.
--
To unsubscribe:
mail -s unsubscribe redhat-announce-list-request@redhat.com
--