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.
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
This 'contest' was obviously a sham. It may not have been a conspiracy, but there certainly was a shameful display of cluelessness involved here. Why wasn't the NT machine set up without the recommended Service Packs?
--
Interested in XFMail? New XFMail home page
Yeah, and I run autorpm and so I get my RedHat security fixes installed automatically the very night the fix hits the mirror sites. So what's your point about how wonderful dselect is?
The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
it's still a gaping security hole that got installed with the default RedHat distro. :-P
The crontab exploit, perhaps, but 90% of the breakin was conducted by exploiting sloppy programming in a commercial ad-banner package. The crontab explot was just the last step; in fact, I missed the crontab on the first read because I stopped paying attention once he got an arbitrary executable to run!
Which isn't to say that there aren't bugs, but this sounds like a problem with commercial software and default RedHat. Personally I'm impressed that both of them held up for as long as they did
Daniel
Hurry up and jump on the individualist bandwagon!
-- Slashdot sucks.
"We didn't apply the 21 service patches for Red hat.... we did however install SP5 because it was easier."
/pub/updates/6.0/i386/*.rpm (or wherever)
ftp updates.redhat.com
prompt off
mget
rpm -Fvh *.rpm
*done*
So much for "too hard!" Maybe Red Hat should ball up all of the current updates into one smart installer to make it even EASIER...?
I found the writeup a bit hard to follow at times, but I generally got the gist of it, especially the "let's go on down to the local exploit list and pick our method of getting root."
This makes me feel that security under Linux would really benefit from an automated update system of some sort. For a Red Hat install, especially one on a server, how hard would it be for the install program to go look at some ftp server run by Red Hat for critical updates? Then, at least, you'd be sure that your server was secure from all exploits known up until the time of your install.
You might also have a system that automatically checks these critical updates and alerts the sysadmin, offering to automatically install the update.
Yes, a good sysadmin wouldn't need this. But, the fact is, the number of servers going up out there outnumbers the number of good sysadmins. With people getting high-speed connections in their home, and the ability to set up their own servers, some way of making their setups more secure than a hoping what came in the box doesn't have many exploits would help.
Hey, give the guy credit. Even with a known bug, his work to get there was absolutely top-notch. And, better still, his explanation of his path, including the wrong turns, is first rate. Besides his clear technical skill, his description of how he went about the hack was the best such tale I've ever read.
Steven, Senior Technology Editor, Sm@rt Reseller
> Maybe I'm busy and don't keep up on the latest bug reports.
Than why on Earth are you a system administrator?
> The point is, this isn't something I should have to deal with.
What, exactly, do you think systems administrators should do?
You have the same attitude that ebay had when Sun gave them a patch to keep their database from being corrupted. Your A-number-1 top job is to keep the system up and keep crackers out.
> It used to be that when someone pointed out a flaw, it was put on a TODO
This was not only on a TODO list, it was DONE.
> PCWeek installed a default RedHat system and it got cracked.
They didn't use the default NT though.
> Much like the Mindcraft tests
Where the tests themselves were cooked to show that NT can saturate a T1 line with static content better than Linux.
> These things should be addressed, not spun.
Please tell me how to "address" a security hole that was already plugged?
-- Don't Tase me, bro!
True enough, but remember, the only *real* hole was the CGI one. The other holes had already been fixed, PC Week just failed to apply the patches.
Every OS has patches. If you don't apply the patches, whether it's NT or Linux, you don't have a secure OS. End Of Story.
-Brent--
Yes, think about it this way. PC Week was trying to *prove* whether one OS was more secure then another. Were they successful? No. You can't prove that one OS is more secure then another by just plopping boxes on the web and asking for them to be hacked. All PC Week "proved" was that they weren't competent to administer a Linux box.
Okay, lessons learned. Microsoft is wrong. People aren't born with a copy of Linux in their hand. But they aren't born with an in-depth knowledge of NT either. If you fail to understand how to administer an OS, it's not because it's more difficult, it's because you haven't learned. If you *really* know how to administer NT, it's not because of its alleged "ease of use", it's because *you* took the time to learn it.
This was good for the Linux community. Linux was hacked. But it wasn't *just* hacked, it was a documented hack. We know how it was hacked, and can learn from it. Competition aside, these sorts of things are very good for the Linux community. PC Week basically *paid* to make Linux better. When PC Week (or anyone else) does this again, we'll learn more. And eventually we'll end up with a much stronger OS because of it. Sure, maybe we could set up boxes ourselves and find holes, but sometimes it takes that $1000 as an incentive to doing so.
OTOH, what has Microsoft learned?
-Brent--
Do we know that the NT Server was an "off the shelf" install? Would that be with no service packs?
So, well; let's take it with head high. Linux lost.Did Linux lose? I guess the question is, too what? If it was really a stock install of NT, then we *know* that NT isn't secure. So this just implies basically that no one cared enough to spend 20 hours hacking NT. This is a Linux user, who hacked *his* baby. He didn't hack Linux to prove that it was a failure, but to prove that the box wasn't configured right, had other problems unrelated to Linux, or whatever. Okay, he did it to win the $1000 too.
The point is, I think Linux won. PC Week provided an incentive to find holes in our own OS. This was cause greater awareness of the need to competent administrators, whether it be Linux or NT. And it proved something about security methods.
The only "loser" in this case is Microsoft. They didn't find any new holes in their OS (yet) so it won't be improved. Microsoft is hardly going to be successfully in selling a claim that NT doesn't need to be patch like Linux does. And people will have a greater understanding as to why the Open Source security model is better then the closed source security model.
-Brent--
It would appear that PC week didn't even bother to download all the errata rpm's into a directory and do a "rpm -Uvh *rpm".
:-)
In order for this to be a fair comparison, the NT box should have been installed w/o Service Packs.
Something tells me it wouldn't take 20 hours to crack an NT box without Service Packs applied.
---------------
When a program can crack a *nix box, it's called an exploit.
When a program can crack a windows box...it's called a "malicious program".
> IMHO the test is a valid one - what would the experience by of a "typical" Corporate type user who sets up a web server.
And IMO a "Corporate type user" who sets up machines and doesn't subscribe to the security updates list for the OS and show due diligence at applying announced updates needs to be F*I*R*E*D. With a capital 'F'.
Sheesh, evil *and* a jerk. -- Jade
Of course, that doesn't mean there's a conspiracy afoot. It might just mean that someone on the magazine's staff needs to be F*I*R*E*D.
Sheesh, evil *and* a jerk. -- Jade
In the end, I figured out that the real Lesson Learned is that NT is from Mars, and Linux is from Venus. OK. Maybe not. But they're very different worlds. They foster very different attitudes and outlooks. The illustrating point is in comparing Hot Fixes and Service Packs to Patches.
Instead of "RedHat had lots of security fixes available Real Soon after the exploit was announced", its "RedHat had soooo many fixes! The sheer numbers dazed and confused us!" I suppose the numbers can be a bit daunting. Sun and HP offer tools to bounce your configuration against their patch database and help manage this issue (of course - this is for an added fee). As mentioned, Debian offeres deselect. FreeBSD has had something simular for some time as I understand it. Perhapse RedHat offers a simular option that the PCWeek folks weren't aware of?
Of course, the big issue seems to be in comparing RedHat's fixes to Microsoft's practices with Hotfixes and Serve Packs. First, MS tends to have a slower release schedule with these things. If this is the environment one is used to, comparing 5 Service Packs to the mentioned 20 RedHat patches seems... excessive. This is compounded by PCWeek's statment:
They're right. Service Packs require extensive testing before being implemented in a production environment. Hotfixes even more so. That's not Microsoft-bashing, its simple truth. If one was expecting the same from RedHat, 20 fixes would be monsterous. However, its been my experience that patches don't require the same cautions. Of course, I don't use RedHat. Perhapse someone else with more experience can comment?In all, PCWeek's comments are less insightfull for what they say and more for the points of view they express.
I think it's pretty obvious that if the vendor of the OS you're running releases an advisory describing an exploitable hole in the OS and you fail to follow their instructions to patch it, the blame for getting owned via that hole is yours and yours alone. the vendor followed up on their responsibility to notify you of a defect and you failed to take the suggested steps to repair the problem.
if I buy a car and it has a faulty ABS computer and chevy issues a product recall, I cant blame them for my brakes failing if I haven't brought my car in for the recall.
(well, knowing our legal system, I could probably sue, but logically, its my problem, not theirs.)
So now the comments here will go from "Oh it was a problem with just the 'closed-source' CGI, not the OS" to "oh it's a conspiracy to make Linux look bad". Grow up. There was a problem, it wasn't set up right to begin with, and it got cracked. Cope.
-witz
This article is quite easy to read, and contains a detailed enough description of the juicy details to hold a geek's interest.
I wonder how much information he would have been able to clean from the system if he hadn't been able to look at the source code for the "photoad" package?
Okay, so did PCWeek use a known bug in their system just to make Linux look bad? Did they think that we might not find out that it wasn't a Linux fault? Or did they think that the FUD would be thick enough as to suggest to most of the world that Linux sucks?
To me, this sounds a lot like the Mindcraft tests. What would be interesting would be to have a Linux company (like LinuxPPC, too bad they chickened out) to offer the challenge again. But don't we do that anyway? After all, if a box is out on the net, it has been a challenge to most crackers anyway.
Brad Johnson
Advisory Editor
Brad Johnson
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
Like heck! If a faulty product is distributed, then it is distributed under the assumption that people will use it. Recalls are Good Things, but there is a huge onus on the provider to make best efforts to stop someone from being damaged as a result of their faulty product. It's fundamentally their fault for designing a product with holes in it, and so it's the manufacturer's responsibility to make sure that the mistake is put right.
And I am not aware of Red Hat having carried out anything like the level of effort which GM goes through in product recalls. Just saying "a good network admin would have kept up with this" doesn't make it. Your product, your liability.
Unless the take-over-the-world faction among Linux advocates want to plaster every commercial distribution with disclaimers shouting "THIS PRODUCT MAY HAVE SERIOUS SECURITY HOLES -- IT IS YOUR RESPONSIBILITY AND YOURS ALONE TO KEEP UP TO DATE WITH THEM" (actually, a quite sensible approach), then the commercial distributors have to make a quantum leap in *making* system admins adhere to best practice. Personally, I'd go down the disclaimer route -- the luser sysadmins are more trouble than they're worth as a market.
jsm
(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
--