Details of the PCWeek Securelinux Crack 216
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.
Re:Posted bugs for crackers! (Score:1)
"A commercial, and in some respects a social, doubt has been started within the
last year or two, whether or not it is right to discuss so openly the security
or insecurity of locks. Many well-meaning persons suppose that the discus-
sion respecting the means for baffling the supposed safety of locks offers a
premium for dishonesty, by showing others how to be dishonest. This is a fal-
lacy. Rogues are very keen in their profession, and already know much more
than we can teach them respecting their several kinds of roguery. Rogues knew
a good deal about lockpicking long before locksmiths discussed it among them-
selves, as they have lately done. If a lock -- let it have been made in what-
ever country, or by whatever maker -- is not so inviolable as it has hitherto
been deemed to be, surely it is in the interest of *honest* persons to know
this fact, because the *dishonest* are tolerably certain to be the first to
apply the knowledge practically; and the spread of knowledge is necessary to
give fair play to those who might suffer by ignorance. It cannot be too ear-
nestly urged, that an acquaintance with real facts will, in the end, be better
for all parties."
-- Charles Tomlinson's Rudimentary Treatise on the Construction of Locks,
published around 1850
stock linux vs. custom nt + extra features (Score:1)
>got cracked. No matter how many times you yell
>"FUD", this is still a Very Bad Thing(tm).
if they had used a default install of NT, it would have gotten cracked too
"Microsoft pitched in by modifying their guestbook application to a classified ad application. They also helped with the myriad configurations of NT, IIS, SQLServer, and MTS"
How many people installing NT out of the box get help from MS securing their machine? Exactly.
Another thing to consider is the capabilities of the different systems. Did you see the MS's supposed 'classified ad system'? It looked terrible and had no features. The Linux ad system was much more professional and had many useful options. In fact, the only reason it was cracked was because it allowed people to upload pictures. If that capability didn't exist (like in the MS version), the exploit would not have been possible.
In summary, they got professional help from MS configuring their system, which mere mortals can't even dream of, and their system had so few features there was nothing to exploit. Hardly a fair comparison.
Interesting how open source hurt (Score:1)
Clarification (Score:1)
PCWeek installed the braindead cgi, I don't debate this. If it shipped with Linux, I wouldn't have been defending Linux as it would've been a distribution defect.
Next time please consider logging in, or perhaps even dropping me an e-mail (my email address may look fake, but it works) before you flame me. This was a miscommunication based on terminology.
Thank you for reminding me why I browse at +1 and why I'm against no-account AC posting.
The facts of the case (Score:1)
There's a lot of arguing about whether or not updating is fair. Here's the facts of the case.
If we're going to argue about whether or not it's fair to have skipped a patch on the RedHat machine, then you are also arguing that the NT machine should be at whatever SP level their installation disk uses. Thus, according to this argument NT should probably be a "properly configured" NT4SP1 machine while the RedHat machine should probably be a "properly configured" RH6.0 machine.
This argument has gone far enough. If you want to defend the test, you have to apply the same standards of due diligence to BOTH servers. Unfamiliarity with one operating system is not an acceptable reason to skip updates. Finding out update procedures is a very basic and elementary step in a procedure of proper due diligence.
An improperly installed version of Linux got cracked due to a combination of an unpatched bug and a braindead cgi script. This proves to me that Linux is worse about as much as the 'Linux runs on a 386 with 2 megs of RAM' argument proves to me that it's better.
Why is this so difficult? (Score:1)
Why should I have to read bucket loads of documentation, figure out another wierd package and spend ages testing it? Surely that's the whole point of a distribution?
Watch for spin from 'closed source' people. (Score:1)
The hack was worked out because JFS had the source to hand -- that's how he was able to find the hole
What this makes obvious is two things --
The actual hole was found in the source of the ADS software -- I hope that the people writing it have taken heed of this (and fixed the hole).
John
Re:reverse FUD (Score:1)
John
What, pray tell, are you smoking? (Score:1)
Re:Open Source Security (Score:1)
If they had not applied the service packs to the NT box then this would be a valid test. Evidently they did. That means that it was a NT box with all vendor supplied updates installed versus a RedHat box with no vendor supplied updates installed. Hardly a valid test.
WAKE UP NT BASHERS!! (Score:1)
IIRC, NT 4.0 was released in 1996. RedHat 4.0 was released in 1996 as well.
So let's see.. let's run NT 4.0 with no service packs against unmodified RedHat 4.0.. Now let's run the contest again.
You *can't* compare a stock version of NT 4.0 with a stock version RedHat 6.0.. There's at least a 3 year age difference between the products. You can, however, compare NT 4.0 with SP4 (1999) to RedHat 6.0 (1999).
Re:Not just a CGI Hack. (Score:1)
Re:RedHat is NOT Linux! (Score:1)
Re:RedHat is NOT Linux! (Score:1)
All I would need to do is mirror the mirror and replace a package with my trojan version. Then I spoof the DNS replies and redirect your connection attempts to me.
Granted, this is not easy, but is doable.
Re:So it was an exploit that was already known? (Score:1)
| security on the machines
And if it's the one I'm thinking about, didn't this have a fix RPM up on the RH errata site (www.redhat.com/errata) well in advance of the hacking contest? I don't know about PC Week, but when I install a box, I try to make sure I've at least put on the latest security fixes available from the vendor. Doing othersise is just *asking* for it.
| I know someone who recently got bit by the
| wu-ftpd exploit.
It's getting so you can't have an "incoming" directory any more without people trying that exploit that relies on creating a long path
Re:For Christ's sake (Score:1)
| 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.
The point you're missing is that it *was* addressed. Is it "spinning" to suggest that the person installing the Linux box go to the vendor's errata page to get the latest updates when he installed the box? Like some others have said, this is basically the equivalent crime to doing their best to armor Linux to withstand attack but using a straight NT install (no service packs or tweaks as illustrated on the PC Week page).
Re:Open Source Security (Score:1)
Nothing currently, however a bit of integration with Asymetric encryption and digital signatures would render this point mooter than it is already. Since the machine being updated initiates the connection, the task of the cracker spoofing Redhat's update site is non-trivial. It would require access to the routers or networks along the path, and assurance all traffic will go over the same route.
Re:crontab (Score:1)
1) There's not much they can do there when they've broken in- there isn't a single-point-of-vulnerabilty root account that gives away the whole store once access has been gained
Everybody is root on a Windows 95 box. Can we say "single user system with multi-user functionality bolted on"? I knew you could.
2) Win95 boxes don't contain much of value to a hacker, they are end-user, not server machines.
This is iffy. Most 95 break-ins I would have to guess occur because of file and print services are enabled on boxes that have direct connections to the Internet. Let's not forget nice things like BO and BO2K, always fun. There is definitely useful information SOMEWHERE residing on a Windows 95 machine, but do you really have the time to search the millions that are out there and vulnerable?
Re:For Christ's sake (Score:1)
let alone bugtraq archives, usenet newsgroups, etc...
[I help admin several RH based boxes, and as a result I am on over 10 mailing lists, check several newsgroups daily, follow the bugtraq stuff, and check the errata pages AT LEAST ONCE EVERY COUPLE OF DAYS, and look at some of the "hacker d00d" web pages]; note that this is not required to admin a RH box, but ANY box that is on a network of any kind, be it linux, windows, macos,etc.. there are certain places an admin has to keep track of and follow; if not for the simple reason that the "black hats" probably already know of them by the time it hits those avenues....
The problem here was with the "Admin" not knowing how to secure his box; not just with the CGI or OS used.
..
..
Re:We Need Inclusive Updates (Score:1)
It would be good to have such a meta rpm, but only as "base reference"; ie: install 6.0, then "6.021", but still check regularly for updates and install those as well... esp those that came afeter "6.021" was released...
Open source == two-edged sword (Score:1)
The solution is to use open-source code, and write using an environment that keeps exploits to a minimum. The trade-off here is that bounds checking and stripping bad characters takes processing power, and so you need a bigger machine. But who really cares if it takes
Re:For Christ's sake (Score:1)
We need to do this more often (Score:1)
1) How someone determines what your system is like
2) How someone uses that information to crack your system
This is very useful information. I hope that people continue to hold contests like this, and publish the results, so we can all make our systems (and our web scripts) more secure.
Re:RedHat is NOT Linux! (Score:1)
Re:RedHat is NOT Linux! (Score:1)
Where am I getting my
Good luck finding out.... Gee did you know that spoofing a debian package tree might be difficult?
Re:RedHat is NOT Linux! (Score:1)
heheh would not get you very far.
Hmm how about a firewall too?
Umm you forget that I might not be using anonymous ftp..
What do you think that all admins are stupid?
Write permissions for nobody? (Score:1)
The cron hole was a local hole, and should not have been exploitable remotely, as it in fact was not. The local cgi-bin hole took care of that.
Nevertheless, it does seem like an unfair test, if the NT box had SP5 installed. Hey, if they can fix the security on one, why not the other?
and another thing (Score:1)
aaaahh! this is pathetic! exactly what do they think an NT service pack is? in the descrip tion [microsoft.com] of the service pack there are no less than 10 fixes listed under security, not to mention at least one DoS i saw just skimming the networking section. basically what theyre saying is they didnt update their redhat box to be fully secure even though redhat has all the updates nicely laid out, just because it wasnt all packed up into a single file. what laziness!
if i owned a company and my sysadmins refused to update a server with multiple known security issues just because he/she would have to play with more than one file theyd be looking for another job. basically this paragraph admits (in my interpretation anyway) that they were biased towards NT because it was easier to use.
sad...
--Siva
Keyboard not found.
Good idea (Score:1)
Also, perhaps a daily crontab that checks for new updates and mails root. Assuming that a root that doesn't look for updates would ever check mail.
rpm -Fvh *.rpm doesn't work with ftp (Score:1)
Re:crontab (Score:1)
For a standard end-user installation, wether it's Windows or Linux, security patches are a minor issue. If you're on a dial-up link like most of those folks the chances of actually being "hacked into" are not that high. Most corporate installations should be protected (at least in some ways) by a firewall. How many people are actually running Win95 (original release) with no security patches installed and get hacked on a regular basis?
Re:nothing new here (Score:1)
Re:Open Source Security (Score:1)
Well, I tend to agree. However, I wonder: Would that '"typical" Corporate type user' also not apply any service packs to NT? If so, was NT installed "out-of-the-box" in that test or with service packs applied? What would be a "comparable patchlevel" for both systems in such a test?
Any thoughts?
Thomas
Re:For Christ's sake (Score:1)
Re:cope? (Score:1)
Your disclaimer should go without saying, IHMO. I have been thinking that way since i first got into Linux/Unix.
It *is* that simple (Score:1)
1)Subscribe to BUGTRAQ
2)Actually read it
3)check the errata page - which is not obscure, its only about 2 levels deep off the "support" link on the home page, and broken up by distro version from time to time
4)Download the updates - all of them - and burn them onto a CD, so that after I install, I reboot, log in, pop in the CD, and run a script that patches everything.
Keep in mind that in the grand scale of Linux skill, I am strictly a lightweight - but I can tell you, looking at my logs, people bounce off my boxes all the time _because I patch my stuff up_ and because I follow the simplest security stuff around (tcpwrappers and all that). Its not friggin rocket science.
Making a secure machine is the job of the admin. Its not the job of a piece of software. After all, isn't a software problem the root? Humans drive software, and always know better than what a machine tells them.
Re:perhaps you're forgetting... (Score:1)
I agree, but... (Score:1)
The point is that the biggest hole in the Linux box was not in the Open-Source OS, it was in the one closed-source application it was running. People will argue about the difference in quality of Open-Source vs. closed-source from now until the end of time, but there is so much scrutiny applied to security right now, that Open-Source products have more than proven their superiority in the information security world. Open-BSD allows anyone to look at the source at will, yet an up-to-date Open-BSD install has never been comprimised in it's default configuration.
We all know these things, and it's time that we stop whining about analyses, complaining about FUD; and prove it. We've made our point; everyone knows that the Linux community doesn't agree with any result that shows a deficiency in our work, but it doesn't help our cause. Make Source, not war.
If you need to point-and-click to administer a machine,
Re:cope? (Score:1)
It is not that simple.
If a software vendor knows about a problem, and there's an obscure web page that documents it, and most peoples' attention is not drawn to that web page, it is the vendor's fault. I'm not saying things are this bad in this case, but I am saying the mere existence of knowledge about a bug and the mere availability of a fix are not sufficient.
There ought to be an "update wizard" that, at the end of the install process once the network has been brought up, checks a central repository for security updates and downloads them. It would probably be good if there were a cron job that re-ran this utility from time to time and sent mail to root when uninstalled updates were available. Then any such failures would clearly be the fault of the folks doing the install.
Re:the 3 vulnerabilities exploited (Score:1)
Except that the hole had been patched, just not applied to this site...
(4) Letting "nobody" have a shell at all.
Re:crontab (Score:1)
Re:Lessons We Don't Get (Score:1)
Furthermore, there was no reason for PCWeek to even install all 20 patches. They needed 3, yes 3, the cron update, the net-tools update and the kernel update, that is the extent of the security fixes they needed for their configuration. Now if we look at what they installed with the NT server, uh well, they start with SP3, then install IE4, then Option pack4, then install SP5. Well, that is 4 updates, more than the RH install. So which one is going to take more to beta test for their production server??
The PCWeek Lessons Learned is one giant page of FUD.
Re:Open Source Security (Score:1)
Oh yes you can compare (Score:1)
If I will put up two servers, one running RedHat Linux and one running NT, I get the latest versions of both. With RedHat it's 6.0 from 1999 and with NT it's NT4.0 from 1996. That's where updating starts regardless of release dates.
If I'm an ignorant newbie, I don't update any service packs or patches. So the cracker gets to crack a vanilla NT4.0 or a vanilla RedHat 6.0.
If I'm doing my work well, I update SP5 for NT5.0 and all the updated rpm:s for RedHat Linux. PCWeek didn't do that in a security shootout so it just classifies them as class 1 morons who are desperately trying to shift the blame.
Unpatched==Unsecure (Score:1)
I'm sure that an unpatched NT, or other Unix flavor is just as susceptible to problems, but there is less likelyhood that you'll know about it and be able to fix it. Of course it means that others are more likely to know about it and exploit you, but that's the trade off. You have a greater opportunity for security if you maintain your system, but a greater opportunity for problems if you don't.
Lessons learned:
1) Make sure you've got good secure CGI's on your system.
2) Make sure you have all the latest patches.
---
This wasn't a fair comparison. (Score:1)
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".
Did he get the cash? (Score:1)
This is an interesting/useful read (Score:1)
Lets drag this all out and let the cat pick at it. (Score:1)
Box was cracked using:
Security hole in commercial package
Known crontab exploit in RH box install.
Firstly, we can't yell at Redhat because of the exploit out of the box. Why? Well, NT has a lot of exploits out of the box too. Did they install the NT Service Pack and Hotfixes? If so, then they should, to be fair, apply the fixes for RH6 as well. If they applied Service Pack 5 and not the fixes for Redhat 6.0, then it's their fault, obviously.
Secondly, we can't blame Linux for having a problem because of a commercial third-party product. Would you blame Microsoft because someone got in the NT box via a third party product that was installed on it? I wouldn't, I'd blame the vendor of said product.
We also cannot blame RH or MS for having a bad default box install. This is why they release patches. When MS releases Win2k, it most likely won't have the same bugs that the box NT4 install has. Likewise, when RH releases 6.1, it won't have the same bugs that the box 6.0 has. Simple. They'll both have SOME exploits, which again will be fixed by freely available updates. This is how the update system works, people.
These are not in dispute, excepting that PCWeek has yet to say anything about it either way, AFAIK. If they'd acknowledge anything, no one would be bitching (maybe, as I know how some people just like to bitch).
Some people say that the Open Source model makes it easier to find an exploit for a system. I agree. It truly is a lot simpler to crack a system where you know all the code it is running.
HOWEVER, they forget the flip side of the coin. A system with exploits that can be easily found are found much, much quicker. Also, repairs (patches) to this system can be made by anyone, and distributed freely, and quickly. A problem found on a Linux system is found and a patch is usually out and about the same day. Most of the time, they are simultaneous, since the person that found it, fixed it, and told everyone else how t do so. For proof of this, just go browse the bugtraq list.
Conversely, a problem with a closed source system usually takes an annoyingly long time to fix. Fewer programmers working on the problem means that fewer people know the system, which means the longer it will probably (not always) take longer to fix. The power of parallelism that is at work on an Open Source system is amazing. Plus, with a closed source system, a bug may go unreported for a lot longer. Note the 49.7 day crash bug that was present in all of Win9x for over three YEARS before anyone spotted it. This is not an exploit per se, but it proves my point.
The problem I have with this contest is that information about it is not being dispursed. The linux box went down. Fine. Great. This is a testament to Open Source, in that we found out why, and realized that any boxes out there that are in a "real-world" environment are not susceptible to the same problem. What, you ask?
Let's define "real-world". A SysAdmin is running a server like this. What sysadmin in his right mind doesn't apply the latest patches? Even on NT you apply service packs and hotfixes! By not applying these, you are no longer "real-world". Instead, you are an idiot who shouldn't be running a web server.
Now the nay-sayers say that some home user running this Linux site would be susceptible to an attack, since he may not know that this kind of thing exists. He might not apply patches, service packs, hotfixes. I agree. But the same thing it true if he is running an NT site. Either way, he may not apply patches. But, then his box goes down from a crack. Guess what? He knows now, doesn't he? Learning is hard, and most people learn the hard way. Welcome to the "real-world".
---
here's the beast (Score:1)
Re:crontab (Score:1)
Re:rpm -Fvh *.rpm doesn't work with ftp (Score:1)
#!/bin/csh
#setenv RHUPDATE updates.redhat.com
setenv RHUPDATE ftp.lame.org
setenv RHUPDATEDIR
ftp -in EOF | awk '{print $9}' | grep "\.rpm"
open $RHUPDATE
user anonymous drunk@www.istar.ca
ls $RHUPDATEDIR
EOF
Re:rpm -Fvh *.rpm doesn't work with ftp (Score:1)
#!/bin/csh
#setenv RHUPDATE updates.redhat.com
setenv RHUPDATE ftp.lame.org
setenv RHUPDATEDIR
ftp -in <<EOF | awk '{print $9}' | grep "\.rpm"
open $RHUPDATE
user anonymous drunk@www.istar.ca
ls $RHUPDATEDIR
EOF
It was a CGI hack (Score:1)
Furthermore, he could not have done anything if he didn't obtain the actual CGI application from a friend. He basically analyzed the CGI, found a potential open door and exploited it.
This is in no way implying that the bug in the crond daemon is ok, and didn't have a cause in this, just merely that a better written CGI would have prevented _ANY_ of this to happen.
The CGI was not written by _ANYONE_ related to Linux, merely a third party (commercial?). So to blame this exploit on bugs in Linux or Apache is not quite right.
Confused (Score:1)
Anybody?
Re:Interesting how open source hurt (Score:1)
We Need Inclusive Updates (Score:1)
Instead, I think Red Hat should have something of a hierarchical RPM file, that itself contains several RPMs. Then, every update issued would contain all prior updates. So, for example, if I install update 6.021, say, I'm sure that all prior updates are installed with it. Kind of like the NT service updates. This makes it much easier to apply the updates, and is not much difficult to implement. Instead of grabbing 21 separate updates, I would download the latest update every six months or so and install it. That's it. Now, that is something I could live with.
Read it yourself. (Score:2)
----
Unbelievable! (Score:2)
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 [slappy.org]
Re:RedHat is NOT Linux! (Score:2)
Re:For Christ's sake (Score:2)
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
Re:The moral is... (Score:2)
Argh (Score:2)
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...?
How about automatical critical updates? (Score:2)
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.
Give credit where it's due (Score:2)
Steven, Senior Technology Editor, Sm@rt Reseller
Re:For Christ's sake (Score:2)
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?
Re:Argh (Score:2)
Security holes are a fact of life, and 'critical' patches are a routine event. It's time that all OS vendors start treating them as such, as opposed to the the current strategy of putting the burden on each and every administrator out there.
Re:It was a CGI hack. (Score:2)
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--
Re:Conspiracy Theory (Score:2)
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--
Re:Nice exploit! (Score:2)
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--
This wasn't a fair comparison. (Score:2)
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".
Re:Open Source Security (Score:2)
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'.
Re:Open Source Security (Score:2)
Lessons We Don't Get (Score:2)
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.
Re:crontab (Score:2)
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.)
reverse FUD (Score:2)
-witz
Nice description! (Score:2)
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?
Conspiracy Theory (Score:2)
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
Re:cope? (Score:2)
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
the 3 vulnerabilities exploited (Score:3)
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.
--
Crontab not the risk - PC Week the risk (Score:3)
Was the test fair? Ask yourself why PC Week set up the Linux box with a $150 CGI script [hackpcweek.com] 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 [hackpcweek.com].
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 [hoffice.com] has questions like "What if I don't have 'telnet' access to my web site?"
Jamie McCarthy
PCWeek had responsibility (not that it matters) (Score:3)
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.
cope? (Score:3)
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.
Once again - admins who should be flipping burgers (Score:3)
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 [freshmeat.net] 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
Re:Open Source Security (Score:3)
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 [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 [lsl.com] for example.
I don't know about you, but I'll take keeping Red Hat up to date over NT any day.
-Brent--
Re:Open Source Security (Score:3)
"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.
Posted bugs for crackers! (Score:3)
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
Nice exploit! (Score:3)
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."
Re:Interesting how open source hurt (Score:3)
The open source model allows for this type of code review, which leads to products with better security.
Re:crontab (Score:3)
How available was this information? (Score:3)
Open Source Security (Score:3)
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."
For Christ's sake (Score:4)
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.
----
You are all right... And you are all wrong... (Score:4)
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
Re:For Christ's sake (Score:4)
You don't do much work with NT, do you? If you did, you'd realize that patches were an important part of the Administrative Responsibilities. You see, it's just not Linux where vulnerabilities are found and have to be patched. And it's not just OS's. Come ON! I now had to apply a patch to fix a vulnerability in Office 97.
These things should be addressed, not spun.They were addressed. And the page to keep up to date with these issues is well documented.
-Brent--
Re:cope? (Score:4)
Red Hat has an Errata page [redhat.com], they have 2 mailing lists, and for registered users, they have a priority access site. They seem to have the level of effort needed in their case. Now, you show me where I can get on Microsoft's e-mail lists, where their web page is listing their patches, and where they put the patches on their FTP server, and how do I get priority service? They *probably* have all that, but I looked for about 10 minutes and didn't find it. Only took me about 2 minutes to find all I needed on Red Hat's site.
Second, if Red Hat's effort *isn't* enough, then *you* tell me what it is you are looking for.
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"That's Microsoft license agreement, isn't it? I *knew* it looked familiar.
-Brent--
Re:How available was this information? (Score:4)
Real available if you subscribe to Red Hat's update announcement list.
> How easy is this to fix?
RH 6.0:
ncftpget ftp://url/whatever.rpm
rpm -Uhv whatever.rpm
/etc/rc.d/init.d/crond restart
> Is there an updated package to fix this exploit, and where can we get it?
Visit http://www.redhat.com/corp/support/errata/index.h
Other distributions have similar arrangements.
Re:How available was this information? (Score:4)
Package vixie-cron
Synopsis Buffer overflow in cron daemon
Advisory ID RHSA-1999:030-02
Issue Date 1999-08-25
Updated on 1999-08-27
Keywords vixie-cron crond MAILTO
Chron buffer overflow errata page at RedHat [redhat.com]
RedHat is NOT Linux! (Score:5)
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.
crontab (Score:5)
-----------------------------------------------
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
--