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.
Like the subject header says!
(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.
Tell this in comp.lang.perl.misc and get flamed to the moon and back.Yes there is rpm under debian, just type "apt-get install rpm" and debian will install the rpm deb, so you can install rpms on your debian box, but the prefered method is to use alien to convert rpm's to deb's so the dependancies can be seen and the package will be listed as installed.
The first hole was with CGI.
The fact that PCWeek had an insecure installation is a really good point. PCWeek is just like the "linux buzz" people who go to CompUSA and buy the $80 RedHat box. Lazy Windows-like folks don't read errata, and don't run bug fixes -- not unless it's on the 6 o'clock news (like 'Melissa') or it was sent to them in an email titled "Fwd: Fwd: Fwd: Fwd: Fwd: Fwd: VIRUS ALERT!!!!"
:)
Another point in the "Linux is not ready for Joe America" arguement. When's that LinuxLite coming out?
Do have a license to troll for all those flames?
I recently did a security audit for a company (several days ago) and got in to their system through the IIS4 overrun problem.
They were shocked as I'd previously advised them of this and they had applied service pack 5 as a result.
I tried this on the NT at hackpcweek and it failed. Can we have a answer yes or no whether this fix is in service pack 5? If not then PCweek are not being truthful in their statement that no other fixes were applied.
I went to CompUSA last night and noticed that they have FreeBSD available from Walnut Creek, I thought that was cool.
RPM packages can be signed with PGP, which would make this hard to exploit (assuming AutoRPM can check these signatures).
I recall those days... breaking into BBS's, cracking software, sucking down password lists...
programming 486's with "copy con: program.com"... fixing bugs in commercial software with Norton DiskEdit... multitasking on a C-64...
Memories...
The vixie-cron exploit shouldn't be blamed on Linux, it should be blamed on vixie-cron (or the admin who didn't install the updates). Other operating systems running vixie-cron would be just as vulnerable. It shouldn't have been suid-root on a web server anyway.
I still havn't seen the LinuxPPC box cracked... so SHUT UP AND GET TO WORK...
I have to agree here. When we hear about some new security hole in any Microsoft product, it gets all the press attention(wired, yahoo, PC Magazine, Ranger Rick, Highlights, Playboy, Penthouse), and people bash MS openly for having such a hole.
But when there's a security hole in Linux, it seems to get no further press attention than bugtraq. Hmm..
Yep. Open source really sucks. After all, look at the greatest closed-source systems (MS-Windows, MacOS, etc) and you will see stable, robust systems that are not vulnerable to exploits. And we want everyone to re-invent every little feature every time someone develops a new program. We don't want people using other people's code! That whole code-reuse idea sucks. If hackers were meant to use other code, Microsoft would put it in the Win32 API, damnit! The only thing worse than code re-use and distributed collaboration is the word "ussage" (sic). God, I hate that. Name one instance where people use "usage" that "use" wouldn't work better.
it seems nobody else mentioned it, so I thought I should... dselect is not the easiest/best packaging tool debian has for this kind of thing. since the last version, debian has a new packaging tool called apt. applying patches with this tool, once it is configured (very easy) - works like this: be root, have internet connection open, open shell and type "apt-get update" and then "apt-get upgrade".
all packages which are more updated on the mirror for your installed version of debian are fetched and installed (all dependencies are taken care of by apt). the only thing you have to do is answer the configuration questions for these packages (for those packages that ask question, most don't).
this is very easy, it can be done by a sysadmin once per week and solve the security patch problem.
my 2 cents...
ps. try debian, they do neat things
These are the actions of an admin who is somewhat inexperienced in dealing with Linux, and therefore typical of a great many people who have just started working with Linux recently.
It comes down to this: A trained monkey could install an NT service pack. Last time I cracked open a box of MS software, they threw the latest service pack CD IN THE BOX and included a postcard with info where I could check for even more up-to-date changes. So, it is even more likely that a novice NT admin would have the most up-to-date patches available.
With Linux, I have to read through obscure documentation (HOW-TOs, etc), figure out the non-obvious mechanics of rpm, figure out WHERE I have to go look for security holes, plug configuration based security problems THAT THE PUBLISHER KNEW WHERE THERE BEFORE THEY PACKAGED THE PRODUCT, and then hope that I've a) managed to figure out the installs for all the rpms right b) found all the places where the patches have been posted and chosen the right versions of those patches.
While linux may be able to be made MORE secure than NT, I think that NT is much EASIER to be made more secure than Linux for a novice admin. Security is only as good as your competence and experience allows for. NT leverages very little knowledge and experience for a LOT more security than Linux does.
Here's another thing to stick in your craws.... In my experience, the Linux community has been one where simple questions beget rude, obnoxious responses from arrogant people, often in the form of obscurities that any base novice would have NO IDEA how to handle.
With Windows, I've never had that kind of response when I've had to get answers for questions.
Flame away, but your experience as linux advocates/zealots/gurus/whatever is blinding you to the reality of what it is like for someone either forced to use or interested in using this stuff who hasn't a clue.
Uh... I don't think he used a buffer overrun at all.
Golly gee, I sure am impressed.
Ya, but Debian is a pain to use, you know? I wouldn't use Linux without RPM now that I'm used to it.
Okay, great. Except there *are* fewer exploits for Windows than Linux.
RPM also provides for "hot patches" by just downloading all the patches then do an rpm -Fvh * to freshen all installed packages. However the Debian solution sounds more elegant. There is HTTP/FTP support in rpm, but I don't think you can use it to fetch while directories, otherwise it would be similar to Debian.
Okay, flaming back to a flame, because both of those two distros are poor. No RPMs, old software, unimpressive. No reason to use. Dropping Linux market share. Whee.
Secure, huh?
Put a guest account on your system. Post it on Slashdot. See how many hours until someone cracks it.
I'd put auto-updating right at rank-beginner skill level; and if it's beyond anybody's ability to master this then they sure as hell shouldn't be allowed near an NT/IIS or any other webserver.
The fact that PCWeek allowed this to happen speaks only to their incompetence and/or mendacity, and not to any flaw in Linux, RedHat or the Unix way, m'kay?
The updates have been on the updates.redhat.com server since before the "contest" began. As was known to both the cracker and --who doubts this?--the crackees as well.
Mindcraft redux ---& that's the real deal.
Don't know how the companies any of you work for, but the one I'm at would have my ass in a second if I dumped This Week's Update on one of our production servers. In the case of an update that resolves some critical exposure, there is significantly more leeway, of course. But, even that would have to have some sort of short term testing before it could be applied.
Updates packaged together make testing and rolling out changes to the system configuration much easier. If these updates could be backed out in a similiar fashion, this again would be a big help.
NT has its own set of issues, but having a packaged service pack to apply to a test server and beat on for a while before doing a scheduled rollout, does have it's advantages.
Linux would do well to have a simplified means of encapsulating multiple updates. Distributions should provide a single update to bring new installs up to speed quickly and then encapsulate additional changes at regular intervals.
Providing some means of automatically polling the distro maker would be a big help too.
Linux maybe cheap, but it is expensive when it comes to the amount of time needed to come up to speed, the ease at which mistakes can be made, and the amount of time it takes to keep current.
We all know Redhat is insecure, why not let Debian or Slackware have a chance to proof itself?
As many exploits as I see on BugTraq, it makes me wonder how many more are out there and known only to Crackers. Scary really.
Open source is great because it allows peer review but what if the people who review the code do not reveal the holes they find?
According to you (and, it seems, a lot of people on slashdot), if someone cracks an M$-based system, no matter how they do it, then that is excellent news and proves how crap M$ are.
But if someone cracks a Linux system, then it is nothing to do with Linux, just the installer of the Linux box sux, and they are all part of a conspiracy.
Hmmm.
Can you say "hypocracy"?
I looked over his explanation of the hack. I don't know much about programming, but it seems to me like he pulled off one hell of a complex hack (not the crond exploit, but the PHOTOTAD stuff). This person really knows his stuff. I would say that what he pulled off was worth a great deal more than the prize he won.
Which is the whole problem I have with this thing. Why would this person waste his time with this hack? For $1,000? To prove that Linux is not secure? It seems dubious to me, to say the least. Within 20 hours? That seems really quick.
There were also some pretty odd little coincidences and synchronicities that allowed him to get into the system. It seems odd that the security patches weren't implemented, but that this insecure, commercial, Open Source CGI PHOTOAD banner system was put as a CGI script on the system. They also managed to setup the firewall, right? Why would you setup the firewall if you did not implement the security patches.
I may be wrong, but it all seems orchestrated to me.
Linux lost this one...
It is still a good hobbyist OS.
If you read what they wrote, they said that it was easier to install fixes with NT that with RH. For the most part install updates on NT is a lot easier than RH, that is what they are talking about.
We seem to have people saying "Linux is going to break the Microsoft hegemony!" and in the next breath, saying "damn brain dead windoze users, don't know how to blah blah blah..." The fact is, Linux will remain marginalized until people feel it is as "easy" (I know, I know.) as MS products.
The "Linux install" doesn't run a braindead cgi. My Redhat install has no default cgi's.
PCWeek installed the photoad software, which had the cgi. If I put an insecure cgi on NT it would go the same route.
Linux DOES have vendor distributed patches. Distributions maintain security advisories, and they're quite easy to install.
You had a valid point but it had FUD trimmings. Yes, NT and Linux just running "out of the box" is not a good idea, they should be secured. But before spewing out what YOU think are facts, get them right!
Well, it actually makes a lot of sense. Wouldn't you want to keep notes so that you could live to tell of your exploits! Next thing you know this guy is going to be writing a best seller, he'll be appearing on all the major talk shows, and he'll be a guest of President Clinton. Ok. A bit exaggerated but I think you get my drift... Just think of all the network security companies that will want to hire him!
Not fair! Not fair! Whinge, whine, complain...
Had it occurred to you that if RH and co. made their updates available as a single easy-to-install service pack, sysadmins might find it a lot easier to find & install them?
Score 1 for MS for usability. Again.
Depends who sponsored the test. If the test was not sponsored depends on the inexistent value usually referred as corporate IT intelligence...
Hey. while this is sort of a troll, the issue is valid and keeping our heads in the sand absolutely will not help, and seriously hurts credability. The availability of the source code in THIS CASE did help him, and denying that is simply not being honest.
Nope, it wasn't. The portion the original poster was referring to was probably the effort to make rename() bomb out. This isn't a buffer overrun, just a clever way to prevent the file from being renamed... and besides, buffer overruns don't happen in Perl. :)
Was it a "'closed-source' CGI" or a commercial 'open-source' CGI? Else how did they know the whole was in the CGI in the first place? To say it was not a conspiracy is also a bit over done. It may not have been a conspiracy by "PC Week" but that does not mean that "Microsoft" could not have been involved in some way. I mean how on earth could they do an extensive update of NT (that us normal people don't have access to) and not even begin to think to do the same for RHL or even to contact RH? Just think about that, there has to be something being skewed here, although the possibility of this test being run by a few morons is still there, how likely is it? I would think it unlikely at this point that someone would not have done or said something. The other thing to think about, now that they know what the problem was, are they going to redo this test with correct administration, if they do not then it is even more likely that this tests purpose was to skew the facts. hmm, just some jibblets to rollover in your mind, until we can find out if they even will consider retesting.
Are you insane ? Unix might be securable against external attacks, but once you are logged as an user on the system, it is full of security holes. On my machine, I have no less than 67 setuid programs, and it is obvious that if someone really wanted to it would gain root access. Just review the source code of the 56 programs, preferably starting from the one which is written less cleanly. You have probably much less setuid programs but the problem is still the same (only longer to crack).
However, I plan to take a long hard look at all cgi scripts on my system to look for any obvoius holes.
It should be the OS job to check that the apache daemon and its CGI scripts don't access things they aren't supposed to access. Unix security is crap. Unix admins are paying the price every day.
Further, RedHat will engineer themselves out of business if they do too good a job on their distributions.
Heh, your just exagerating right? I mean if they do too good a job (they're doing a good job now, I must say), then they are just selling support, so that if something goes wrong they will work on it. At least support seems to be what they are selling now, so even if something is very good, businesses will still want the guarantee that if something does go wrong (what can go wrong will go wrong), they will have the support to fix it.
They took time to patch the NT box, why didn't they patch Linux?
Unless you are willing to pay for your OS vendor to create a custom version of their software for you when you purchase, you will almost always have out of date software.
As others have said, this is not a Linux (or any other OS) problem, but a sys admin problem. And despite their excuses, any sys admin who does not look for and apply security patches on a machine used for business on the net deserves to lose their job.
(and as a site note, how did the message I have replied to get a rating of 4 for being insightful when all the person was doing was ranting and raving because Red Hat doesn't recall and reissue their CD's for each errata fix??)
Then why isnt there $1000 in your pocket?
The OS should do this, not every single program written for Linux.
I would expect they would probably wait until the next release came out for their Distribution (I would assume Red Hat will include that fix in their next distro.. That is a bit inconsistent from what you said earlier. You say they extensively test a fix, and would not install fixs on a weekly basis and that they recently installed SP5, that is not a big deal, but then you say you suspect they would not install any fixs for their LinuxServers? I suppose its dedication, they sound like they are probably more of an NT network then a Linux Network I take it, so LinuxServers don't get as high priority. But as for the rest of it, they do not have to do it on a weekly basis, they could break it down into priority, and update on their own schedule or as need be. Anyway I'm sure that your "typical" corp would update Linux just as well as they would NT, if they were primarily Linux based.
I'm not sure standards is the correct word to use. We are talking about a community here, not one voice. Some people may feel that linux should be for the elite only, and others think linux should be for the masses, so obviously you'll get 2 diffrent messages... My personal influence is something inbetween, I think linux should be for the elite and for the normal user.
There are "people" who do "feel" Linux is as "easy" to use as MS Products, and for them and their usage it really is as "easy", for other people and their usage of an OS, it probably is not as easy but also not necesarily difficult/hard though.
[...]The only "loser" in this case is Microsoft.
You're hilarious. I've never seen such a blatant attempt to put a positive spin on a smashing defeat.
> 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.
Then you should be fired for not performing your job. Companies *DON'T* need deadwood like you in positions like yours. In fact this may be an unexepected benefit of the move to adopt linux. You can expect to see people with the PC Week staff mentality seem to have get fired over making outright stupid blunders like this. Does anyone think that the idoits who set this "test" up for PC Week would be working for a company 24 hours later after this kind of major fuckup on their part? Especally when they tell the bosses, "Well we were too lazy to bother with actually doing what you hired us for"?
Sounds like the exploit used on cron has already been addressed (well before the PC Week "test").. if anything it proves that a secure Linux/UNIX server first requires a competent System Administrator.. something PC Week doesn't seem to have or cared to seek the advise of when setting this system up. At anyrate the "test" proves nothing other than default settings aren't secure on old (RH 6.0) distro's..
-vE ten.xeh@dloc
"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
>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).
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.
Well, not exactly open source. But the hacker was able to find exploits partially because he discovered the computer was running a program "photoad", which has source code available. He could look at the source code and find exploits from it.
What i meant by the "Linux install" was the particular server installation used in the competition including all software, even non-distribution stuff.
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.
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.
If you can automatically update your RH distribution automatically, have it email you, etc,etc. Why the hell doesn't it do it automatically out of the box?
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?
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
John_Chalisque
I put the response to this on another message -- basically it needs to be considered that source availability also contributed to the problem.
John
John_Chalisque
I knew about that bug via BugTrak a long time ago. And for Red Hat admins, Red Hat's errata page is hardly "obscure."
--
Ben Kosse
Remember Ed Curry!
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.
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).
In the stock release, yes. There was on update to these packages over a month ago to fix this problem.
-- I'm the root of all that's evil, but you can call me cookie..
I can fake your autoselect into upgrading packages from me. It is not impossible to do. auto RPM is a huge security hole in any environment with public access. It is useful for internal use, but dangerous in general.
Mike Mangino
mmangino@acm.org
All I need to be able to do is to sniff a network and look at traffic. This is especially easy if I am on the same network as the mirror you use. It would be much harder to find out a specific users mirror than to snoop a mirror and find out who uses it.
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.
Mike Mangino
mmangino@acm.org
| Gotta hate it when people don't keep up on
...
| 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
-- Rick
| 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.
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).
-- Rick
Ahh, but now what's to stop somebody from spoofing the RH update site and installing a job that unlocks your machine just as effectively as it would if the updates were never applied?
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.
P.S. Any misspellings or faults of grammar you think you detect are mearly transmition errors, and probably your fault a
On the contrary, Windows 95 boxes are broken into ALL THE TIME. The people using those boxes just never know generally. In response to your points:
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?
P.S. Any misspellings or faults of grammar you think you detect are mearly transmition errors, and probably your fault a
Thing is... there are thousands of rh6.0 installs that were not made from official rh 6.0 cds. It is IMPOSSIBLE for rh to recall all 6.0 versions out there for each problem like this one. They have done it the only way that they can... have the information availible in the errata pages so that any COMPETANT sysadmin would know to check the errata for important updates.
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.
..
..
--
Time is on my side
The problem is what if there is an exploit found within those six months?
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...
--
Time is on my side
The idea behind the analogy is that a two-edged sword, while it has the ability to cut on the way in and on the way out, it can cut both the enemy and the guy holding the sword. That's exactly what open source is like -- yes, security through obscurity is a bad idea in that it keeps holes secret from the good guys, but open source makes holes easier for the bad guys to find.
.001 seconds or .00011 seconds to process a file?
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
it's quite simple - did the nt box have an service packs applied? if so, then the redhat box should have had it's errata applied. and there's no need to read bugtraq for this, just ftp to the redhat site and snarf all the files.
US Citizen living abroad? Register to vote!
This was _very_ enlightening. I'm a web programmer, but I've never been a cracker. I know basic web security, but it is really interesting to find out
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.
Engineering and the Ultimate
No I am saying it's RedHat Linux not just Linux.
"Think of it as evolution in action."
Umm... no you can't. .debs from?
Where am I getting my
Good luck finding out.... Gee did you know that spoofing a debian package tree might be difficult?
"Think of it as evolution in action."
Wrong. :) try sniffing a switched network.
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?
"Think of it as evolution in action."
Why oh why was it possible for the user nobody to have write permission on a CGI script? THAT is the real hole in that setup. The only time that I can think of data that needs to be owned by nobody is a web data file, in a contained directory. Certainly CGI scripts should not be writeable by nobody! An even better solution is to use a sql database, and make it so that absolutely no file is writeable by the web server.
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?
"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."
aaaahh! this is pathetic! exactly what do they think an NT service pack is? in the descrip tion 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.
Keyboard not found.
Press F1 to continue.
If the install has the net set up and working, then yes, I'd love to see "The following updates are currently available. Would you like to install them.?"
:)
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.
You're right - you can't pass wildcards to rpm when you're doing an FTP install. Is there a way this could be done? I was disappointed to find that it's not currently possible.
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?
Then you should be $1000 richer right now.
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.
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
staying up to date with the security holes found in the OSs you use is a very important part of the sysadmin job. that is true for RedHat Linux, for NT and for every other OS out there except possibly CP/M. companies will release versions (distributions, service packs, whatever) only once or twice per year, and in between people will find holes and they will be plugged. so in this case I'd say it's PCWeek's fault for installing a RH Linux server without looking around RedHat's "errata" section. and I'd say the same thing about it if it was a known bug getting exploited under NT, or Solaris, or whatever. no vendor can make a release a week.
you can't make sysadmins, or people in general, do anything. Red Hat says "There is a hole in our product" via the industry-accepted channels (bugtraq, the web, etc) and then leaves it up to the individual to actually go and fix. This is different from a standard product recall (ie, "Levis issues a product recall for its 501 jeans. Your pants may explode under certain circumstances.) but the environment of computers is far different than, say, cars or clothes.
Your disclaimer should go without saying, IHMO. I have been thinking that way since i first got into Linux/Unix.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
Here's what I do:
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.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
sure there is always someone better but I don't think a month-old exploit counts as "better".
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
I don't think you are wrong, that exploit shouldn't be there, but it was the default install. If the default NT install was used, it wouldn't have lasted 10 minutes. MS suggest _300_ security checks to do before an NT box is secure. PCWeek went through this checklist to lock down the NT box, but Redhat was left to stand in it's default condition. We should learn from this experience and improve Linux, to be sure; but also keep in mind that this does not indicate that Linux is less secure that NT, or vice-versa. The crontab exploit was only used to gain root, after JFS had already comprimised a local user account by exploiting the CGI. This would have been even easier on the NT box, because there is a program out there that still works called get_admin. It elevates any user to Administrator.
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,
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.
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.
> (3) There was the vixie-cron exploit. This is the only part that could blamed on Linux.
Except that the hole had been patched, just not applied to this site...
(4) Letting "nobody" have a shell at all.
-- Don't Tase me, bro!
Yeah, I've looked around MS's site, and the only central location which lists current hotfixes that I've found is the FT P directory!
Business. Numbers. Money. People. Computer World.
Service packs require much more testing than a hotfix or Redhat update. the reason is that Service packs fix a whole slew of different componants of the OS. A hotfix or Redhat update fixes one thing. I will go even farther saying that Redhat updates are still even easier to test than a hotfix. A hotfix can involve several different applications to fix one bug. A Redhat update fixes one application, that is all, much easier to test just one application than several.
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.
Q.
I don't know RedHat's FTP directory structure but if it is anything like Caldera's all updates are in a single directory. Having a cron script update them isn't hard. Personally I use KPackage for managing RPM updates. It supportes URLs in its search path for new/updated RPMS, by default it is preconfigured to point it to the Caldera FTP server. It tells me if there are any updates, I just click and install. Simple.
-- Remember: Wherever you go, there you are!
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.
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 sig has been temporarily disconnected or is no longer in service
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".
Has PC Week coughed up the cash? And, if you're listening, how does a geek spend this well earned money?
It reads like a "Buffer overrun HOWTO". I was curious to see exactly how this sort of thing can be achived-I had heard about this type of exploit but had never actually seen one. I certainly have to hand it to the guy for the meticulusness (sp?) of his work. This should be manditory reading for all UNIX webmasters, IMHO.
Okay, here's where it all stands:
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".
---
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
link to original bugtraq messages archieved at www.securityfocus.com
I think the point is that a redhat doesn't know if there _are_ updates, unless (a) they look, or (b) they have autorpm, a tool I'd never heard of. Windows 98's autoupdate feature is actually very useful and helpful to keep users up to date. Is there a friendly GNOME tool that checks for updates? Does gnorpm do that?
He could have NEVER gotten to the cron exploit if the CGI didn't let him. There is one line of code in the CGI that allowed all this to happen. The CGI does a 'rename' at some point but does not check that it was successful, and the exploit relies on the rename to fail.
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.
Anybody?
Open Source. Closed Minds. We are Slashdot.
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 the article again ... what *new* security hole was found in *Linux*??? Err, none!
... as was a bug in a program for which the source was available, but not subject to peer review.
A moderately old bug in crontab, which was already know about and a fix available was exploited
Can we set up an NT4.0/SP0 machine and see how long it takes to get that hacked??? Seems like a fair comparison to me!
Gotta hate it when people don't keep up on security on the machines... THings like this are all too common. I know someone who recently got bit by the wu-ftpd exploit.
Do you Gentoo!?
I have read through this in depth, and there a 3 points of failure.
Firstly the CGI perl scripts had difficult to spot exploitable bugs in them, particularly not checking that the file move completed without error. Also the binary files were not thoroughly checked as being valid. Purely a perl programming issue, and only exploitable with the source.
Secondly the CGI directory was writable by the exploited CGI script, allowing scripts to be replaced by any sufficiently small binary. Purely a sysadmin education matter.
Lastly, there was the cron exploit. Having looked at the cron exploit carefully, it uses a buffer overflow to force pre-compiled code to be exploited.
However for any binary code to be executed, the hacker needs to know the precise processor being used, and also assumes that the C-library was standard.
AFAIK a working example the cron exploit has not been published for the Alpha, and our hero here had to use some others work to implement the exploit. Assuming he was able to compile Alpha versions of the binaries he uploaded, he still would have come to a halt when trying find a root exploit.
Therefore if this machine had been an Alpha (or other stable processor), the crack would have not occurred.
The moral - the less common the system, the more secure it becomes.
FUD? What the hell are you talking about?
Look, it may be a "well known bug", but it's still a gaping security hole that got installed with the default RedHat distro.
That is simply not true. If you read an exploit, the (primary) problem was with add-on closed-source CGI script. Without it, it would not happen (until someone manages to prove otherwise)
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.
If you don't keep up on the latest bug reports, then why do you wonder if you get cracked? You should _AT LEAST_ reguallary follow your distributor announce/errata list and that of all add-on software. Otherwise, you deserve to get fired.
To the best of our knowledge, no known exploits exist at this time.
Whoops. I think there's a known exploit now. :-)
Seriously though, a vendor can't be expected to release anything that is bug free, but they are expected to respond quickly to problems and provide what is needed to keep their products running securely. They also can't be expected to install patches for their customers. It wasn't RedHat who dropped the ball here.
I'm speaking from experience. I patched up the mountd exploit (a while back) on all of the servers I was responsible for, but woke one morning to find my workstation hosed up. I had forgotten to patch my own box. Some nice person had "rm -rf /" on my machine.
Nothing left to do except beat my head against a wall and reinstall. I didn't blame RedHat. It was completely my fault.
Does GM/Ford/etc. come to your house and fix your car for you when there is a recall?
Here's how I see it. You have Linux which has only gained popular use within the last couple of years. How many admins have more than a couple of years or less experience with Linux or *NIX in general? With the number of jobs available and the lack of people to fill them all it takes to be a *NIX admin is to have used PINE or something and you're in!
Now, even assuming the admin DID go look at bugtraq, the exploit is listed as a LOCAL exploit. So, the admin who does not have source to the CGI of the AD program figures, "well I have to use it and trust it to be secure." Is an admin going to think that local buffer overflows could be remotely exploitable? I don't think so, at least not without more than a couple years experience. It just reinforces the fact that you need to plug every hole, regardless of the way it can be exploited. Also, how much time was given to the admin to set the box up? A month, a week, 3 days? I guess its hard to be careful if you don't really understand how careful you need to be. Everyone that wants to blame the admin needs to deal with the fact that Linux popularity is a dual edged sword. The more popular it is, the more people use it. The more people use it, the more people who don't understand it use it. This leads to security problems. NT is the same way.
Finally, the person who did the exploit is more than just a script-kiddie. This took in depth understanding of Perl, the OS, and how to get from A to B through C, D, and J.
I still don't think this excuses RH from sending out 6.0 without being fixed if they knew about it in a previous release.
Do really dense people warp space more than others?
What an amazing quote! The more things change, the more they stay the same.
You subscribe to the NT security list at www.microsoft.com/security (I think, I'm at home with flu!), and notifications get emailed to you, or you check that page as often as you check the redhat page. Exactly the same.
I keep up to date on known exploits, and so far as I know, I have no holes, so I'm pretty safe from the script kiddies. But what this test has shown is that someone who is intellegent and meticulous.
:)
However, there were multiple holes involved here, any of which could have prevented the crack if they had been patched. The first allowed the cracker to determine the directory structure. The second allowed him to write an executable file with contents of his choice, allowing him to run any program as a local user, and the third was the crontab exploit, which required a local user to exploit.
The only one that is even remotely linux related is the contrab exploit, and it was a KNOWN exploit, so it should have been patched if this was going to be a valid test of the operating system.
I feel confident (as confident as I can anyways) that my suid programs are all known exploit free. I host MANY users on my system, and occasional use of crack shows that many of their passwords are frequently all to easy to guess. The possibility of someone accessing AN account on my system is somewhat likely, so I have to be sure that there are no open holes that a local user could exploit.
However, I plan to take a long hard look at all cgi scripts on my system to look for any obvoius holes.
As much of a PR stunt as these cracking contests might be, I personally don't see a big problem with them. I feel I've learned something from it, especially with that detailed explaination. I know a few more potential holes I have to watch out for. And you can be sure that every redhat user who read slashdot today will be making sure that crontab is patched. I see no losses. I hope they do it again.
-Restil
Play with my webcams and lights here
Hey, what are you saying here?!
I set up a mail server this summer and _I_ _think_ it's pretty secure.
Oh, never mind.
Debian all the way!
--
Weasel
The long path wouldn't have worked if the rename() return value had been checked - lazy programming.
Of course the real problem here was the open() holes, which could have been avoided by the slightly more security conscious approach of validating the generated files names before actually doing the open (file overwrite!).
not too long ago, rootshell.com was cracked. even with the most skilled admins, there's always someone better.
A year spent in artificial intelligence is enough to make one believe in God.
I think PC Week really blew it. If you read their configuration page They list the steps that they took to secure Linux.
So we know that they at least know about the Linux security howto. They should have at least been tipped off by this section in chapter 8:
And if they would have read chapter 9
The thing the really gets to me was the post someone quoted where someone from PCWeek stated that they applied Fixpack 5 for NT because it was only one file. Come on. Did anyone else see all the keys they edited in the NT registry? To the eye untrained in NT administration, it looks like PCWeek spent at least three to four times the effort jumping through hoops to make certain that NT machine has secure. It is inexcusable for them to go through such effort to secure one box and not the other
There is no excuse for anyone putting up the Linux box they did in the state it was, but especially not for a crack this box contest. I'm just pissed they aren't losing more money on this. $1000 is a pittance for stupidity. And just for their record, I'd be just as pissed if the table had been turned and they put NT out there without the latest security patchesr
Ok,
...list-request of course for all those 100K idiotic sys admins out there!
All RedHat users should subscribe to redhat-announce-list@redhat.com. Requests to subscribe go to
When something like this happens, in this case a month or more ago, you get to get an email from RedHat and a link you can click on to download the damned patch!
They also have full instructions on how to type rpm -Uvh (how the hell did you install it first time?)
Now, if you people have problems with that, I think you should resign from your jobs and go play nintendo gameboy (not N64).
Also to all the crappy folks out there, run portsentry with commands like 'sentry -atcp', 'sentry -audp'.
As a good sysadmin you could also get nessus and run it once a month on a heavily changed site!
Finally, write those damned cgi scripts correctly!
Ciao bambinis
Kill Microsoft? No! Just hire their GUI guys!
You mean autorpm? It does all this if you want it to. I'm running it on some of our `Corporate' workstations in `scan and report' mode. I do NOT use the `autoupdate' feature, since I like to keep a tab on what gets installed/updated. It has given me warning within a (/etc/cron.daily) moment of updated packages ever since.
--frank[at]unternet.org
On a quick scan of both Microsoft's and Red Hat's site, it becomes apparent that there are about as many NT4-PostSP5 hotfixes as there are software errata listed at Red Hat's site. When you add in the errata for Exchange, IIS, Word, and other MS apps, Microsoft's burying themselves (and their customers) in bug fixes much faster than Red Hat is. Moreover, Red Hat has an easy method of obtaining info about errata *before*they*become*an*issue*. Microsoft's method basically consists of - if you've got a problem, search Knowledge Base - there might be a fix.
Come on. Everybody has bugs. What matters is how you deal with the bugs. Do you sweep them under the carpet like Microsoft? Or should you stand up point them out, and point to the fixes?
By the time most Linux vulnerabilities could hit the press, they've been fixed. This is an example of that. The crond hole has been fixed. By the time a Windows exploit hits the press, they're determining how much to charge us for the fix. Put simply, bugs get fixed faster with open source. You don't have to wait on a corporate timetable to get fixes that you _need_.
Would cgi-wrap have "contained" the problem?
For more details see last times story. I replied to a message with a more detailed version of the crack..see the first couple of oldest posts and their replies..its the 3rd post to the story which i replied to and posted the crack.
This guys writeup of what he did is very good. It gives a very good description of how one goes about gaining information about a system and thus exploiting it.
Definitely required reading for sysadmins. Just so you know what people might be attempting so you can take steps to protect yourself.
Well, I found this one filed under "Linux is not ready for Joe America if Joe America wants to set up his own web server and invite people to crack it for $1000."
The problem was a not entirely clufeul sysadmin (I won't say clueless, because they did take some security steps, just not enough).
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
err, stop me if I'm wrong, but couldn't you just run cron job every night to get the latest upgrades and install them? Or, if you can't do that because you might be installing all sorts of updates not related to security, get RH to put security-related updates into a particular directory and do it that way.
I don't think you'd need more than 50 lines of Perl to do the job ...
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
I'll tell you why this is called FUD. The server was set up to test how secure Linux is as an OS. The guy got local access through a closed-source application that has no connection with Linux apart from the fact that it runs on it. It's like saying MS-Windows is insecure if somebody found a bug in, say, SimCity.
After that, he gained root priveledges by exploiting a hole that was not only old, but also fixed and documented. Neither of these problems are related to the OS at all. Yet the basic information that is floating around is that a Linux box got cracked. FUD.
Redhat's errata page is hardly "obscure." And there *is* a utility that checks for updates. It's called Netscape, and only idiot admins miss out this step of the installation.
>needs to be F*I*R*E*D.
Agreed, but unfortunately as web servers/corporate internal systems become more common more inexperienced people will be in charge of them. ("Get the summer student to set up the web server")
It was a good read on how far some people will go in cracking a system (editing a binary...sheehh.) and how determined they are.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
OK, so you know and I know that PC-Week got hoisted by its own petard, but the marketing spin received by the PHB's is "Linux was cracked, NT is secure". Or indeed the not so PHB's - on the strength of this and otehr similar articles I was told by the highly experienced CTO of a local internet startup that "Linux is less secure than NT is less secure than Unix".
The same startup is running their web site in three tier mode, with NT4 web and app servers, and a Solaris/Oracle back end database. All configured for 100% hot failover to guarantee uptime.
They have one DNS server.
Hi,
>[...]issue is valid[...]
Hardly, cause this script was not open source -
it was commercial product provided as source code. Ditto, it was not available to the open source community. He got it from friend, you could get it
for $150. I could get for the same price, although I'd rather eat my army boots for a lunch.
Imagine the things you could do, having source code of some product from Redmont.
Point is that NT machine was checked by some competent admin, and didn't run any CGI crap. Why couldn't they find someone like that for Linux?
--
kovi
Anyone else use dselect/apt that comes with Debian?
--------
"I already have all the latest software."
I generally agree. I am a home user and updated my cron daemon after being notified about this vulnerability - I am on the Red Hat "watch-list"
and "announce-list."
However, _many_ Red Hat users are not aware of these issues and the Mailing List.
I suggest that Red Hat incorporate an update daemon that will periodically dial-up an update server and download/install all necessary fixes.
My main point was that we all know that off-the-shelf, Linux would run NT into the ground in such a contest. In this case, it wasn't. The only person to blame here is the sysadmin that set up the boxes.
"There is no surer way to ruin a good discussion than to contaminate it with the facts."
Ahh, but now what's to stop somebody from spoofing the RH update site and installing a job that unlocks your machine just as effectively as it would if the updates were never applied?
One of the hidden problems with things like Apple's QuickTime 4 installer or Windows 98's Windows Update is that there's no way to really be sure where your data's coming from. After all, just because you're paranoid doesn't mean nobody's trying to screw you...
I use Macs for work, Linux for education, and Windows for cardplaying.
The Previous poster is mistaking. AFAIK sniffing is restricted to a single subnet, so if the sniffer was on my own subnet or the mirrors he could potentially find me. What a headache with all the other traffic.
A more workable idea would be to:
Have a good day.
It's an elegant hack and worthy of the prize. It goes to show that perseverance and bad systems administration always are the worst side of systems security.
I have to agree with this. THIS is peer review. I thought this was what made Linux so much better than MS, someone found a hole, how we can fix it!
That's the whole point of having open source software, isn't it? How can you complain about this exploit being the fault of PCweek and still advocate peer review and testing? People should be yelling at Red Hat for letting this kind of thing stay in their out of the box install. Admitted they did release the fix for it long before it was used... But as long as the hole is fixed in the next versions default install then the process is working, right?
Kintanon
Check out JoshJitsu.info for Brazilian Ji
...his explanation of the perl regex was completely wrong. He hasn't been doing enough sed programming.
\1 in a perl regexp means the same as $1 -- it's a backwards-compatibility hack for old-school sed hackers like me.
If anything, the filename portion of the hack might have been easier if he understood what \1 really does. Doesn't make much difference, though, except to gauge his amount of prior experience and therefore the 'difficulty' of the crack.
In my mind, this is clearly a CGI bug. The other holes aided and abetted, but nothing would have been possibly without the gaping CGI security flaws. Whoever wrote the script had clue-zero about security.
And anyone who claims that if would have been 'impossible' with a closed-source CGI has obviously not been computing long enough to remember the game-cracking leagues of the C64 and Apple II days. 100% closed source binaries; 100% crackable. Heck, there are even tools to allow you to decompile code quickly and efficiently, and in this case the cracker knew exactly what he was looking for. String-searching a binary for exploitable method calls is trivial.
And (at the risk of overly belaboring my point) -- it's pretty tough to 'closed-source' a script written in an interpreted language.
[
I should have amended that to also say that this is more a testimonial to the power of a good administrator, as opposed to a testmional to the security of an OS.
rpm to be much MUCH nicer, one should be able to do this:
rpm -Uv --upgrade-only -p ftp://updates.redhat.com/pub/redhat-6.0/i386/
rpm would get the directory listing of .../i386/ and then upgrade all packages which older version is _already_ installed in the system. Its really a full time job to keep up with everything coming from redhat-announce list.
Other usefull options would be --compress-docs and --use-compress-program=BLAH, which would i.e. bzip2 -9 all files going to /usr/man/ or /usr/doc. Now if one does bzip2 -9r /usr/man, rpm -e failes to remove the compressed files.
OK, here's the deal:
America is currently in one of its longest periods of prosperity ever. The labor market is tight. Companies can't find or afford enough highly qualified system administrators. Why do several of us (who say they are highly-trained UNIX admins, for instance) get paid WAY too much money for what we do??
I'll tell you simply: because there aren't enough of us out there! There aren't enough people that know how to install, user, administer, and fix UNIX machines.
So while i agree that a company that doens't have a highly trained UNIX Admin at their beck and call (or for that matter a good MCSE in an MS world) is just ASKING to to cracked, I would also say that to say it is their fault is BS.
If computers were only used by people that 100% could administer them, there would be about 1/100th the computers out there.
The point is that given a default install, then the platform should be relatively secure. Instead of making the defaults wide open, it should be closed. Or maybe give a setting in install to make it more secure. I don't know what the solution is, but the problem is not in the EU here. To say that NT is secure would be a joke, but that means we have to be better than them and make a simple solution for semi-trained sysadmins to have a secure box.
All that said (shew!), I think that the whole 'crack an X box' idea is stupid, as well as the benchmarks and 'how hard is it to install' junk. It is funny, but even something objective like that can be incredibly subjective, based on a million factors.
I believe the company I used to work for (and now consult for) is a pretty "typical" corp (and outside the tech industry)
They would NEVER take that approach. They require extensive in-house testing before they apply any fix. They would never consider putting patches in weekly - and no way in hell would they have patches going on automatically from an ftp server. They will install a "hot-fix" type thing for a "known" problem - os if this test was a "real-life" type problem - it would be in response to the "actual" hack.
[This is pretty hypothetical of course - because they use a third-party to host their public (outside-of-the-firewall) web servers (GTE I think). Security of course becomes the vendor's responsiblity.]
They just recently put SP5 on the development servers migrating them soon.
I'm not sure how they are patching their Linux Servers (they have a few - formerly used a LOT of AIX boxes - but after a recent merger are going Sun) - I would expect they would probably wait until the next release came out for their Distribution (I would assume Red Hat will include that fix in their next distro..
First rule of system security - No system is ever 100% secure. It's easier to find a fault in something than to prevent it, because you have to find it first. The only way to find the holes is to have competitions like this where people have to tell you how they did the crack. This is what OSS is all about, having an army of people looking for problems.
While I do agree that Red Hat is anything but the best Linux distribution, the system obviously would have not been cracked as easily if the sysadmins had did their job and upgraded their packages. People should take this as a hint to fix security problems quickly, even if it is only your personal Linux box.
emufreak
www.kontek.net/pp
--snip---
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.
---snip----
So, in essence, your saying debian is linux.
I don't understand your logic. They picked
the most popular distribution. You can't
make everybody happy. Would you have
rather they built there own distro?
Or maybe picked Jesux??
I can't see this as a conspiracy theory anymore than someone putting up a contest and NT gets hacked first would be a conspiracy theory. But I also don't think it proves much of anything either, other than the fact there are holes in ANY OS (for how long has UNIX been hacked successfully?). What I think this whole thing proves is that neither OS is completely untouchable, which for a lot of people is an affront to their senses, since there are so many anti-MS people who feel Linux is the next big thing and MS can't do anything right. There may be more whole in NT, but that doesn't mean there aren't any in Linux.
"Information wants to be expensive" - Stewart Brand, the same guy who said "Information wants to be free"
My 2 cents go like this
Instead of thinking that this is a consipracy against linux think of it as this !
The guy who won had to give himself a challenge so he went for the linux box and *20 hours* later he had done it
He obviously wasnt on his lunch break from burger king and decided to hack the nt box
Someday, we'll look back on this, laugh nervously and change the subject.
No, this was not a bug in the default RedHat install. Did you not read the actual article? This was a bug in a CGI called "Photoads" that had to be purchased (for $149, much more than the OS cost). Next time, read the facts!
Brad Johnson
Advisory Editor
Brad Johnson
Didn't PPL toke teh machine to antionline to continue the test?
This is totaly new. This guy knows what he was doing. His account of how he did it made it look like he actually wrote notes while cracking the test machine. That's something i have never heard of s-kiddies do. Also this guy didn't rant to the world about how great a person he is and why we should all say he's so great etc... etc... What an interesting case he is!
Let's try this again...
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.
The weakest point in *any* system is the administrator. If they don't know what they're doing, forget it! Give some bozo (say, an admin at PC Weak) a freshly installed box. If they don't know/care how to maintain it properly, then it's their fault the box gets hacked.
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.
Let me give you a hand - from www.hackpcweek.com...
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.
We used the latest distribution from Redhat, along with Apache. Much thanks to the open source community for help in securing the server.
Boy, I guess it's nice to be able to have M$ at your beck and call. And I'll tell you what, if I was one of the 'open source community' that helped PC Weak set up the box, I'd make sure they didn't publish my name!
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...
Gee, from the comments here, I'd say that PC Weak is ignorant about security. How else can you explain them putting SP's on NT, but not even checking for updated rpm's? Too difficult did they say?? Sheesh! This 'test' is about a rag trying to generate interest. To me, it lessens their credibility (what little they have left).
Maybe they should change their logo to: "The Failure of Interactive Testing... PC WEEK Labs ONLINE"
So now what do all the people who insisted that it was purely a CGI hack have to say?
Is the crontab exploit still possible even in the current release?
Not impressive, folks.
The "typical" corporate type would apply the service Packs to the NT install. Don't forget how old NT 4.0 is now.
I'm not so sure that the "typical" corporate type is going to be enthusiastic about having to check the RedHat website regularly for updates that might come in on a weekly or daily basis. I know his boss isn't going to be happy about having to let the person maintaining the server spend two hours a day crusing Usenet to keep up with the exploit-of-the-hour as it's announced to all the companies friends and foes.
In some ways, running an OpenSource system is like riding a Harley. If you like taking the engine apart, futzing around with it, and knowing that you'll be able to do so forever (the Harley scene is just like that, with swapmeets, etc.) then you'll enjoy owning the Harley. Better take along a toolkit on any long road trips, of course.
Many people don't run a server because they enjoy maintaining it. Only true Linux enthusiasts are going to want to do day-to-day maintanence of their servers. And even a Linux enthusiast is going to demand top dollar for maintaining a commercial server.
The coralary is: If it was necessary pay commercial shop rates for all repairs and maintanence done to a Harley, nobody could afford to own one.
Indeed. The Open Source community isn't just giving away the software for free. They're warning the people who use the Open Source packages that they'd darn well better hire someone from the Open Source community to babysit their server. Or use a hired-gun business like RedHat to do it for them.
I strongly suspect RedHat isn't going to perform such a task for free. Thus, the true cost of a "Linux server solution" is rather difficult to determine, and probably at least as great, if not greater, than buying a similar server platform and maintanence from Microsoft and their mob of MSCEs. Further, RedHat will engineer themselves out of business if they do too good a job on their distributions. Makes for an interesting bunch of conflicting interests, huh? (Microsoft, of course, has the same conflict with their product)
However, the fact of the matter would still be that Chevrolet produced a car with a faulty ABS computer. You might choose not to buy your next car from Chevrolet, if the inconvenience of having to bring the last one in for recalls clued you into quality problems at the manufacturer.
Needless to say if there were as many vehicle recalls as there are "Bugfixes" issued for RedHat Linux, we'd all have given up and started riding the bus ages ago.
How many people are actually running Win95 (original release) with no security patches installed and get hacked on a regular basis?
Tweeks don't hack into Win95 boxes because:
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.
2. Win95 boxes don't contain much of value to a hacker, they are end-user, not server machines.
While this is a troll, I believe people are
forgetting a point when they reply to it, namely
is that keeping things obscure tends only to help
those who already have the knowledge.
Administrators need to know these things, and
that means keeping the source open. Closing the
source means that only a select few know about
the problems. (Usually those in black hats).
Ref: "Cuckoo's egg", Dr Stoll, Cliff.
----
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!
"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!
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."
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
--