Red Hat 'Piranha' Security Risk - And Fix 153
patrixmyth writes "A default password of "Q" in the standard Red Hat 6.2 installation of the Piranha module opens a Web server to intrusion, according to Internet Security Systems. The problem was discovered during a review of Open Source code, and the fix is already available. Another victory for Open Source!
The MSNBC article is here.
The fix is here, or you could just reset the password yourself for the Piranha module."
Re:Patch the user? (Score:1)
I have no idea how Piranha is installed, never having done it myself, but I'd be willing to bet that it's either done with RPM or you compile it from scratch. Either way, I think it would be a much better idea if the program had an actual installation program. It would be nice to have an actual program that asks the users what the password should be and forces them to choose one. RPM is great and all, but it's not the most user friendly of beasts and it encourages people to do stupid things like leave default passwords in their software and assume that the user will change them at a later date. Why don't we address the larger problem and do something to improve program installation under Linux?
Hypocritical (Score:1)
Now
Forget Perens and the OSS folks who are simply a bunch of spin doctors and FUD generators as bad as MS is. They aren't doing you favors. Ignore stock prices, because they aren't indicators of quality code. Forget the hype, because it's hurting you, overlooking or making you indifferent to obvious weaknesses in your OS's quality.
Oh, and thank you for supporting security through obscurity Redhat through your lack of auditing abilities. MS's product has been out far longer than yours, yet was discovered later. Both shouldn't have happened, but open source makes it easier to spot and exploit.
Take a clue factor from the BSDs, esp. Open and Free, and review your code, train your coders, and keep your nose clean.
Re:Many eyes? (Score:1)
Commercial code is usually tested by the programmer then peer reviewed then formally tested by internal testers and then opened for a beta test to catch hardware specific bugs.
Open source is supposed to make up for the lack of formal internal testing by a really, really good peer review. Looks like that only happens sometimes if at all.
Re:This is all getting out of hand. (Score:1)
+1, Insightful-intelligent-well-spoken.
It's nice to see more and more people realizing (and speaking up) that Open Source itself is just a better means to an end, but not itself the better end -- just because code is Open Source doesn't mean it IS superior (except arguably in the political/philosophical sense), just that it's easier to get there.
--
This is a Victory? (Score:1)
If you want *real* security, check out OpenBSD [openbsd.org]. OpenBSD's code is always being audited and problems are fixed before the code makes it out the door. If I remember correctly, OpenBSD has not had a security vulnerability posted to BUGTRAQ in over 2 years -- but every day I see a new eMail for a security problem in some GNU software or OS. OpenBSD, as with most of the other free BSD's, has a combined code-base -- all the software for the base system is integrated into one big release, so that it can all be checked for proper interoperability and security. GNU/Linux, however, seems to spread farther apart every day. The kernel, each piece of software, each driver, everything - all of them are 'Open Source' but none of them play nicely with eachother. The distribution vendors then download the software and try to wedge it all into the software box without anything getting out...
Another victory for Open Source?
Try 'Another stumbling block for Open Source'
(note - I've got nothing against GNU/Linux systems. but I know that this will be moderated and I'll have linux lovers eMailing me for a week because the views in here are not those shared by most Slashdot readers...)
-- jason
Redhat makes this worse in rc.local... (Score:1)
Don't give them this info - comment out the line in rc.local that reads "cp -f /etc/issue /etc/issue.net" and put some uninformative welcome text into /etc/issue.net.
Re: SUID [ Slack ] (Score:1)
After reading the su manpage (again!) it does make sense. My apologies for the dumb post.
However, This is the actual output on my slack 3.4 box:
# su -c "/usr/bin/id" nobodyuid=65534(nobody) gid=100(users) groups=100(users)
And on my slack7 box:
# su -c "/usr/bin/id" nobodyuid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(d
So it appears that the older versions of su worked a little different. And again, after comparing the two man pages, they are indeed different. *grumble*
# su --versionsu (GNU sh-utils) 1.16
... allows the su -c "command" username, and
# su --versionGNU bash, version 2.03.0(1)-release (i386-slackware-linux-gnu)
Copyright 1998 Free Software Foundation, Inc.
... doesn't. Seems like it is part of bash now, even though it is running as /bin/su. Curious. Thank you for the reply though, at least now I know why I'm an idiot. :-)
Re: SUID [ Slack ] (Score:1)
Slackware 7 does something even weirder. As root, do this on a slack version (anything but 7):
# su -c "/usr/bin/id" nobodyYou should get an id string for nobody. On slack7, you get root's. No man page explains why, only that the -c should work as shown. And it does on other systems.
For some reason, you must use the shell:
# su - nobody -c "/usr/bin/id"Can anyone explain this??
Re:Happens all too often (Score:1)
Re:Another Victory (Score:1)
It appears from this article that having the source was most definitely relevant in this case.
Re:I browse at 0 (Score:1)
Moderators don't have to browse at any particular level, but they aren't doing the job properly unless they browse at -1.
Re:Another Victory (Score:1)
I'd think that even worse than being cracked would be being cracked by somebody who stays to do as much damage as possible.
The Amazing Disappearing DUPE (Score:1)
I do think that the
That's why... (Score:1)
Re:c'mon... (Score:1)
I'm sure you'll go far with an attitude like that...
BTW, how do you know they "took it aprat"? A thorough security audit of a large application is not something that Redhat does regularly (join the Linux Security mailing list for that sort of thing), so I suspect that someone doing a quick check found it. I mean, anything like a default password is going to scream "security hole!!!!" to even the most cursory examination, while buffer overruns can be much more subtle (many of which are fencepost errors - very hard to catch unless you're looking for them).
Re:c'mon... (Score:1)
Hello? Did you read my post? I was talking about how if the password check section of Piranha has a similar buffer overrun, then it doesn't matter whether or not you've changed the default password - the very act of authentification (whether successful or not) could be a security hole.
Re:Hrm... (Score:1)
DOS 6.2->6.21 $10 (for an upgrade that removed disk compression) (or was it 6.2->6.22?) (I think this update might have been made freely available at one point)
OS/2 2.1 Service Pack $20 (granted very few people actually needed it). I think with this one you could download it (even though at the time you would probably pay more for the time online downloading it)
Win98 -> Win98SE $80 IIRC (and it seemed to cause more bugs than it fixed).
Re:Default Passwords (Score:1)
Anyone that does not set administrator and superuser passwords is a security risk himself, not the software itself. Now, recognizing that a majority of users are inept at best it is a smart thing if the software forces setting passwords.
Re:Another Victory (Score:1)
Not at all a software problem!!! (Score:1)
I agree that it is a nice feature when the software will not let me go on without setting a new password. However, far from every software does that so the security risk is in fact the user.
The day that all and every program requires password setting on install it becomes a software problem.
Re:Don't blame the user - but I must... (Score:1)
I agree that the day when most programs require setting of passwords, one not doing so is a software defect. Until that day, it is a nice feature if the package requires password setting, but not doing so is not a bug.
Re:beta quality code (Score:1)
But then you would be with out Linux wouldnt you?
Definition of Distro: Unstable beta software bundled in a package.
Who made the calls? (Score:1)
The person who made the call to include a prototype in a distrobution.... ohhh bad call dude..
Thies two people will not hear the end of it for a very long time to come...
While Slashdot IS spinning the positive with "Everything is ok we found the bugs" the people who made thies mistakes will be suffering for a long time to come...
"Oh yeah your the Piranha bug person..."
RedHats fault? (Score:1)
Dangerous defaults are insidous bugs. For one they don't look like bugs at all. There is no accual defect of code the program preforms exactly as expected. The danger is the default setting not the code and most people don't even consider this when writing code as they think the user will change it for his/her own benifit.
This isn't automaticly the case. Any given user isn't going to be aware of all the options and may not be aware of a default set to "Let the crackers storm the gates.. send out a becon pulse to let them know your open and even post how valuable your information is"
How can it be a bug? I mean you can change it with out recompiling the code.. what bug?
Thats the addatude of many...
Thats why a bug like this is very likely to go unchecked. But in open source that's not a problem for very long.
RedHat made a mistake that is very easy to make.
So lets blame RedHat for doing what happends every day at every software company and software project.
In fact.. now that I think about it..... ohhh $#!+... I think I may have this bug in ZenToe...
Bugs happen... we can reduce them to a very small amount but they still exist. In the mean time we are fixing them with breakneck speed....
Why make a fuss over this? With closed source companys trying to clame open source is buggy they themselfs have known issues that have yet to be addressed.. Defects that will be with us for years to come. With open source even the insidiosly deceptive dangerous defaults are cought and fixed.
Yes there is very good reason to prase open source for catching a bug that would otherwise be an issue for our childrens children...
Re:This is all getting out of hand. (Score:1)
This means the bug will be know to cracker and admin alike.
This being a default setting could be fixed just by changing the default. However that dose not remove the bug...
Many closed source companys wouldn't see a need to issue a bugfix...
Re:Default Passwords (Score:1)
Re:Does the door swing both ways? (Score:1)
For the hundreth time this morning:
This IS a victory in a sense for OSS because:
1) The hole/bug/problem was found, publicized and a fix/patch for it was put out immediately. Elapse time - a few hours to a few days. The MS bug was around for 4 years! 4 YEARS! Conclusion - software isn't perfect but OSS flaws are found and fixed much quicker than CSS, often before the "Black Hats" find out about it. How many other MS/CSS exploits are out there have we NOT heard of that have been known by the Black Hats for 4 years?
2) This was mainly a problem of adminstration and configuration rather than a deliberate, secret backdoor or bug. The installation left a modules password at a default. Technically, this is not a problem if you are a good sys admin and secure your box properly by changing all the default passwords when you set software up. If you don't, why are you hooked up to the Internet (or any other network for that matter since most "cracking" is an inside job)? Why are you employed as or acting as a sys admin? My Oracle has username
Is this bad PR? Sure it is but not nearly as bad as having a security hole around for 4 years!
My guess is that you and the other negative posters have not read the story, work fro MS or both.
Try thinking before you post..
It's how it should be done. (Score:1)
OSS shines. Let the world review the code (I do look at the source, not exactly everything, but I do look for the obvious buffer problems and other bug-prone parts of code). This way everyone wins. and patches get released much faster.
Re:definately a little spin on this one (Score:1)
Damn this ticks me off.
You didn't even follow the IIS security issue did you? The phrase you use is NOT A FREAKING BACKDOOR. It's a keyphrase used to encode file names as they are transferred betwen client and server.
Re:c'mon... (Score:1)
But anyway. In this case, I retract my last comment, and reply with 'duh'. You can "what if" every application in existence and say the same thing as you did (and not bring a whole lot to the conversation). Presumably the same people that took piranha apart to find any issues, only found the hard coded default.
c'mon... (Score:1)
This is exactly like the "Hack Linux box" contest that was run a while ago. Everyone blamed Linux for it (an exploit in bind or named or one of those was exploited). Never mind the fact that the ONLY way the exploiter was able to get to it was to use a POORLY written THIRD PARTY/COMMERCIAL perl cgi script the people that run the contest had installed.
That being said, this is no excuse for this RedHat blunder. Just when everyone was giving microsoft a hard time for hard coding a password in one of their dlls, someone at RedHat did the same...
That "buffer overrun" should be fixed too, but RedHat's reply was correct: you should have changed the password on install and the problem would not even exist. That's a basic of sys admin (for any application! including oracle, etc.)
Then MS shouldn't play well either with the PHBs (Score:1)
"Hrm, our massive e-commerce system has been taken down because the password is 'Q'? You never thought to change it from the default that everyone else knows? Here's a slip of paper, although it's white, think of it as pink."
As I understand it, the 'overrun' bug doesn't show until you've breached the password. In light of that, this isn't a case against Open Source, it a case against lax security measures. MS has the same type of problem with defaut passwords in SQL.
And the title of the MSNBC article (Score:1)
From a technical perspective, Linux is great. Many programmers, many distro makers, all (mostly) independent. This mean much "natural selection" at both levels.
From a marketing perspective, though, this sucks (for us). Sure, only the Piranha package of the RedHat distro was broken. But what does the public hear: "Linux has security problems". Doh! (we got half-lucky with the above headline--only but all of RedHat is implicated
Two possible solutions:
1) Make the public understand how Linux development/distros work. This is unlikely to happen in the short term, especially while only Linux works this way. We properly blame "Microsoft" for FrontPage security problems and wonder about NT. This doesn't translate to blaming RedHat for Piranha, yet it will inevitably happen.
2) Have all the major Linux vendors get a security audit project started and keep it going (many have started, few have kept it up). Create this list as a public list anyone can consult. Then each distro maker can choose only from this list OR create a separate "server" or "secure server" distro chosen only from the list. Then (and this step, as ugly and painful as it is, is absolutely necessary) when a claimed-secure distro is found to have a security problem because it didn't follow the list denounce that distro in a very public way. They did a bad thing and they need to be punished.
--
Re:Hrm... (Score:1)
That's not a bug patch. You could have downloaded the Windows 98 Service Pack which would have given you all of the fixes in Win98SE and none of the new features. FOR FREE.
Simon
Re:DON"T JUST RESET THE PASSWORD (Score:1)
Incidentally, this also means that the remarks in the system(3) manpage are not visible enough (there is a warning about security issues), and that some explicit advice has to be put in the libc info page (there is none). Volunteers?
My 0.02 Euro.
Re:FIRST SPIC POST!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (Score:1)
This kinda rhymes with hack
Racist poetry he'd write
For which we all wish him blight
I hope someone give him a smack.
Re:Another Victory (Score:1)
What a joke. You Linux fanatics are nothing but propaganda lovers.
There won't be lawsuits (Score:1)
The second reason is the reason why a company such as Microsoft isn't sued for security. It's not open-source so someone could not review the code themselves. It also doesn't have the kind of warning that distros have. It is especially such that Microsoft has been shown to know about such problems in their software and not done anything, sometimes before the software is even released. Consequently, from a legal standpoint (as opposed to how much money the sides have) Microsoft is much more vulnerable to a lawsuit than any little distro- or package-maker.
Chris Hagar
Not a backdoor (Score:1)
Chris Hagar
Lesson of the day, kiddies: (Score:2)
DON'T RUN A WEBSITE.
If you admin your box like a mushroom, expect to be owned by some packet monkey or script kiddie.
Re:Where is the problem ? (Score:2)
Re:Another Victory (Score:2)
--
Re:development environment bug (Score:2)
Homogeneity in the field leads to a _very_ large damage radius if anyone ever discovers the slightest hole in the "secure" way of doing things. If everyone implements it slightly differently, no single problem can expose the widest audience to risk. Remember the Windows "Ping of Death" problem? Homogeneity in the field made it worse than it might otherwise have been...
Although it seems like co-ordinated anarchy, it's important that there is no single point of failure.
Just ask the Death Star... =-)
More like a defeat than a victory (Score:2)
Maybe large vendors/distributions should start some sort of certification/verification protocol to provide standard quality of at least part of the products.
Jeroen
Lawsuits? (Score:2)
I don't anticipate many lawsuits against companies like Red Hat (at least not in response to things like this), and any lawsuits that do occur are not going to go very far.
The reasonably-sized print on a Mandrake 6.0 package:
Other distributors also tend to include disclaimers such as this.
How do they get away with this disclaimer? Why is this alright, but it'd be horrendous for Microsoft to disclaim any liability on their software, and put a back door in it?
Well, even if there is a back door put into a piece of free or open-source software, you can take it out.
The Collision of Open Source and Capitalism. (Score:2)
Re:DON"T JUST RESET THE PASSWORD (Score:2)
Don't bet on it. Buffer overflows are insidious lttle beasts, and they generally pop up because of bad coding habits, which means a program that has one buffer overflow found almost never has only one buffer overflow.
FOr example, in the case of Piranha, what if there's a buffer overflow not only in the password change portion of the code, but also the password check part? You then have a hole that anyone can utilize. Just think of the number of buffer overflows found in programs like Sendmail, and even ssh, and you get an idea of the scale of the problem.
Re:Funny, funny (Score:2)
Well, I'm cheering for Open Source for two reasons.
One, the bug was found within weeks of the release of the software in question, not years.
Two, the bug was nearly instantly fixed and a patch available that doesn't involve deleting things to reduce the functionality of Pirahna.
So yeah, Hurray for Open Source in both instances.
Yes, RedHat should've caught this one before it made it out the door, but they didn't. Stuff like that shouldn't happen, and you should do what you can to prevent it, but no matter what you do, it always will. It's very easy to prove software has a bug, very hard to prove that it doesn't.
Re:Another Victory (Score:2)
The security problem is not the software but the administrator of a WEB site that installs software without setting administrator passwords that only he knows.
Re:Many eyes? (Score:2)
Eric
Re:There's no such thing as a safe default passwor (Score:2)
Good point.
> That, however, requires a genuine installation routine, so that the source can't be installed without the defaults being changed. That, in turn, makes it impossible to have a truly secure open source solution.
I don't think that follows. Clearly, RH didn't do it here, but is it truly impossible for OSS?
--
Re:There's no such thing as a safe default passwor (Score:2)
If the restriction you have in mind is that privileged software that uses a password must be given a new password during the installation process, I would think it was only good sense, and appreciate you for looking after my interests.
VMS used to do this with system or application installations that create accounts. Even Red Hat does it for root, during a new installation. The only disappointment is that they did not also do it in this case.
As for your assertions about users hacking on offensive code, I am not aware of any users who have modified the Red Hat installer to take out the offensive code requiring entry of a root password. I haven't even heard any complaints about it.
--
Re:There's no such thing as a safe default passwor (Score:2)
I like to think of such cases as evolution in action.
--
Re:Double standard (Score:2)
Like we've been saying all along... with OSS a white hat finds it pretty quickly; with CSS the black hats potentially know about it for years before the white hats stumble across it. This is an illustration of the first half of that claim.
--
Re:Security and Open Source (Score:2)
All this proves to me that the "Open Source review" worked. How long was the RedHat bug around for? Now How long for the MS bug?
Now how many independant code reviews has MS had? Did their bug show up because of a careful QA review by peers? No, It was discovered through reverse engineering 4 years after the fact...
Could the MS bug be changed simply by having the admin alter the coniguation? Now how about the RedHat "bug"?
Try answering these questions before you post silly, insulting commnets.
No code is perfect, but OSS is much faster in the bug discovery bug fix patch cycle than any CSS could hope to be.
Re:Double standard (Score:2)
Oh, come on, be realistic. We're talking about default passwords. Things that are mentioned in an installation guide. Some people manage to read English instead of C.
I used to be a Sybase DBA. When you install Sybase, by default there's no password for the SA. That isn't an obscure fact only known to black hats because Sybase is closed source. Anyone with the ability to read simple English words knows. And I've yet to hear someone argueing it's a backdoor.
-- Abigail
The info from Red Hat (Score:2)
And no, this is not redundant, as this has not been posted on the Red Hat errata web site [redhat.com], or elsewhere on the web, yet as of this writing. I couldn't find it at least.
Begin letter. ;
----------------------------------------
Subject: SECURITY: [RHSA-2000:014-10] Updated piranha packages available
Resent-Date: 24 Apr 2000 20:33:43 -0000
Resent-From: redhat-watch-list@redhat.com
Resent-CC: recipient list not shown:
Date: Mon, 24 Apr 2000 16:33:32 -0400 (EDT)
From: Cristian Gafton (gafton@redhat.com)
Reply-To: redhat-watch-list@redhat.com
To: redhat-watch-list@redhat.com
CC: Linux Security , BUGTRAQ@SECURITYFOCUS.COM
-----BEGIN PGP SIGNED MESSAGE----- - -------------------------------------------------- -------------------
Red Hat, Inc. Security Advisory
Synopsis: Piranha web GUI exposure
Advisory ID: RHSA-2000:014-10
Issue date: 2000-04-18
Updated on: 2000-04-24
Product: Red Hat Linux
Keywords: piranha remote CGI command
Cross references: php
-------------------------------------------------- -------------------
1. Topic:
The GUI portion of Piranha may allow any remote attacker to execute commands on the server. This may lead to remote compromise of the server, as well as exposure or defacement of the website.
2. Relevant releases/architectures:
Red Hat Linux 6.2 - i386 alpha sparc
3. Problem description:
Piranha when it is installed generates a 'secure' web interface ID using the HTML .htaccess method. The information for the account is placed in /home/httpd/html/piranha/secure/passwords which was supposed to be
released with a blank password. In fact the password that is actually on
the CD is either 'q' or 'piranha'. It was intended that when the
administrator loaded the piranha package onto their box, that it was their
resonsibility to change that password. This is not a hidden account. It is
meerly used to protect the web pages from unauthorized access. The
security problem arises from the /home/httpd/html/piranha/secure/passwd.php3 file from which it is possible
to execute commands by inserting them into the change password option eg
entering 'blah;/bin/command to execute' into the field, and again to
verify, everything after the semicolon is executed with the same privilege
as the webserver. It is possible at this point to compromise the webserver
or do serious damage to the site.
4. Solution:
For each RPM for your particular architecture, run:
rpm -Fvh [filename]
where filename is the name of the RPM.
Temporarily, you should set a password on the web pages as should be done when you first install the package for the sake of speed you can issue the following command htpasswd -c -b /home/httpd/html/piranha/secure/passwords
piranha 'password of choice' In theory, this means only you have access to
that area and you are hardly likely to try and exploit the problem
yourself.
When you install the update for the piranha-gui, please take a moment to login into the gui frontend and set a password on the account (http://localhost/piranha)
5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info):
N/A
6. Obsoleted by:
N/A
7. Conflicts with:
N/A
8. RPMs required:
Red Hat Linux 6.2:
intel:1 .i386.rpm4 .13-1.i386.rpm. 13-1.i386.rpm
ftp://updates.redhat.com/6.2/i386/piranha-0.4.13-
ftp://updates.redhat.com/6.2/i386/piranha-docs-0.
ftp://updates.redhat.com/6.2/i386/piranha-gui-0.4
alpha:
And a little self promotion (Score:2)
It's really more of a badly thought out installation procedure. However discovering a "back door" is a bit more of a PR feather in the cap of a would be security honcho than discovering a way that brain dead admins can shoot themselves in the foot.
That said, it also appears that there is a buffer overrun problem, which is very serious, but again really a garden variety bug, serious, but common enough.
All in all this is nothing compared to the named bind hole that is still being exploited.
Red Hat needs to get their act together. Why do all these servers have to run as root? Of course, you end up with a proliferation of pseudouser accounts, but so what?
Aren't they going to add capabilities in ext3? Wouldn't this clear up a lot of the root access mess ups?
There are two issues here (Score:2)
Secondly, there is the way that the MSNBC article is worded. Basically seems to be saying, "forget about the IIS problem, look, look, Red Hat has it too! See! Red Hat has a huge, I mean really really really huge, big security hole!! And they don't care! They're downplaying it!"
That was what the big bold bit before the rest of the story said. Of course, the actual story with real facts in it makes a little more sense.
Double standard (Score:2)
definately a little spin on this one (Score:2)
I always thought of a backdoor as something that was intentionally left there by the developers to get in--as was the case with the "netscape engineers are weenies" backdoor that Microsoft developers put into their software.
It seems that there may have been a buffer overrun on piranha, but they make it sound like having a default password of 'Q' is Redhat's fault--It doesn't really matter what the default password is for something if the user doesn't set their own. That's pretty obvious.
And that last part sounds a bit like they are trying to make open source sound like an inherent flaw. Not like I'd expect them to compare and contrast with Microsoft's intentional backdoor that was there for months or years which no one except a few select Microsoft developers and friends knew about. That compared to a buffer overrun in a Redhat product discovered weeks later and quickly fixed doesn't make open source look like a security risk to me. Who'd be running an e-commerce site on a product that's only a couple weeks old anyway (earlier in the article the author alludes to the fact that the so-called backdoor would have allowed an intruder to "access customer databases.")
I wouldn't get too upset over this though. The spin gets more obvious everytime. Anyone with a clue about security won't be fooled. It'll just make Microsoft and the author of the article look more like idiots than they did last week.
numb
Re:Many eyes? (Score:2)
---
Re:This is all getting out of hand. (Score:2)
Brave words: the commercial damage may well have been done already or, failing that, be done in the interlude between the news becoming available and sysadmins fixing their RH installations. The damage to RH and, by extension, open source is inestimable: even when closed-source companies have embedded backdoor passwords in their executables, they haven't concurrently published the source with the passwords embedded. This isn't going to play well with the PHBs for whom Open Source == Linux == Red Hat.
--
Cheers
Many eyes? (Score:2)
And Microsoft thought Netscape engineers were weenies... coming next, the Red Hat Shoot Yourself In The Foot awards
--
Cheers
out to lunch, dining in the Amazon (Score:2)
Tsk Tsk... (Score:2)
I've yet to find a Linux distribution that doesn't just slap in any setuid program whose author felt it needed root privs without so much as a raised eyebrow. Of the ones I've tried, Debian seems to be the most secure right out of the box. I'd be surprised if the more expensive "Server" distributions of Linux were any better than most other distributions, security-wise.
Security is going to become more and more important as more people get connected. I expect that eventually some lawsuits will be filed. I wonder how long that will take and what the outcomes will be...
Re:Funny, funny (Score:2)
(Its looking like the 'password' was not really a backdoor password in a classic sense. It is used, but not as orignally reported.)
And yes, declaring this black-eye for Red Hat a victory IS a total biasing. But remember this forum is Linux-biased.
There was no backdoor in MS Product (Score:2)
While reports focused on a phrase -- "!seineew era sreenigne epacsteN" or the backwards spelling of "Netscape engineers are weenies!" -- which was present in the DLL, that's a red herring, said Cooper, adding that the phrase is not a password, but a cypher key used to scramble the address of Web pages requested by users..
Re:Default Passwords (Score:2)
Of course in general you are right, it would be best for ISS or any other company not to publish such passwords. But in this case, anyone who had enough knowledge to exploit the password could easily install Piranha and get the default password (considering that it's standard with RH6.2). Publishing the password didn't really put anyone at risk in this case.
-rt-
Re:This is all getting out of hand. (Score:2)
You have a point. Open Source created the bug as well as fixed it. How much damage OSS itself deserves for the potential damage depends, to my mind, on where the backdoor was and how long it's been around.
I confess ignorance with respect to this. If the backdoor was part of some relatively new and experimental software, RedHat is to blame for putting it in a box and distributing it worldwide. If the it was in some code that's been around a long time and could also have propagated "naturally," then it is a problem for Open Sourcce that the insecurity was able to survive.
As an analogy, consider the difference between private and public speech. If you go on
I hope someone can clarify which situation pertains regarding this security hole.
- Michael Cohn
The bad do bad because the bad is rewarded. The good do good because the good is rewarded.
Re:MS Spin (Score:2)
The MSNBC article starts off with in gonzo-type with the words:
A team of Internet security researchers say they've found a serious security hole in the most popular distribution of the Linux operating system. According to Internet Security Systems Inc., there's a backdoor account in Red Hat's Linux that would let a computer intruder access and alter files on some computers running Red Hat's most recent version of Linux. But a spokesperson for Red Hat downplayed the flaw, saying few Red Hat users had been exposed to it.
This is absolutely sensationalist spin.
I agree with the views expressed elsewhere
Re:Another Victory (Score:2)
Never forget what the MS in MSNBC means.
Re:Don't blame the user - but I must... (Score:2)
Re:Don't blame the user - but I must... (Score:2)
Don't blame the user (Score:2)
Default passwords are a security hole. Users will forget to change them and when you are installing a system with 5 bazillion different software packages on them (not a good idea in it'self but people will do that) you'll never find all of the default passwords lieing around.
Blaming the user won't help. Like it or not not everyone using Linux is a expert. And the experts will still make mistakes anyway, why tempt fate?
MS Spin (Score:2)
Read the MSNBC artical. If want a look at MS spin-doctoring this is a perfect example of it! Many of MS's apps have default passwords too. Recently a bunch of ecommerce sites were found to have not reset the default passwords on all of their MS software. If a default password is called a backdoor then MS has 5 times as many!
Re:Bullshit (Score:2)
Look at the source maybe?
Molog
So Linus, what are we doing tonight?
Too much spin - see MS SQL Server 7.0 defaults (Score:2)
Given that setting up MS SQL server 7.0 comes with a whole raft of default passwords for system administrator and related positions, I don't think that MS could even come close to complaining about the Piranha system having a default password. Like this excerpt from http://www.microsoft.com/t echnet/SQL/Technote/secure.asp [microsoft.com]
If the sa password is blank (as per a default installation), an intruder (or the Windows NT Administrator) would be able to gain access to the server. For information on ways to reduce the chance of such an attack, see "Registry."
I mean, it's not as if the database is an essential part of the Web E-commerce revolution... :-)
Cheers,
Toby Haynes
The default password is unimportant (Score:2)
Nevertheless, I don't think this is an important aspect of the story. What worries me is that it is possible to run code at the webserver user level from the web. This is very NOT good. Even if you set the password, someone could still potentially guess it using a program.
Also, it is somewhat interesting how MSNBC has handled this story.
True Security (Score:2)
I browse at 0 (Score:2)
I would be interested to know what the percentages are for the various default browsing levels. After that comment that most people browse at at least 1.
As I understand it the moderators themselves don't have to moderate at 0 (I've never moderated so don't know for sure). So only logged in users who normally browse at 0 (unless they set their browse level specifically down to 0 when moderating) are seeing these posts to moderate them.
I would say that your comment about how you meta moderate shows that you have a poor grasp of the function of the 0 and the -1 levels. After all if -1 weren't there to collect the dross it would always appear. Do you maybe not approve of the -1 level at all?
It's interesting that you posted this as AC because if you are posting at 0 simply to make a visiblity point then why didn't you include your ID?
Decreasing number of eyes per file (Score:2)
As more and more software is released as Open Source, the ratio of eyes to SLOC will decrease.
Also, as the software that is released as Open Source becomes more complex and specialized, the odds of the eyes looking at the source code being knowledgable enough to identify bugs decreases as well.
What does this mean? At some point, for certain software packages, it will make more sense for a company to keep it closed source as the cons of releasing it as Open Source (basically, giving it away) will outway the pros (find bugs).
Easy Target (Score:2)
Re:Another Victory (Score:2)
Re:This is all getting out of hand. (Score:3)
Even if it had been 2048 characters of line noise, the fact that it was the default password means that anyone else using the same software knows what it is.
Safety does not lie in more difficult default passwords; safety lies in changing default passwords after you install the software.
--
Patch the user? (Score:3)
Re:This is all getting out of hand. (Score:3)
1) The victory is that the problem was found. It was found quickly, before any damage was done, and it was found expressly because a member of the community had free and easy access to the code.
The gentleman who found the flaw frets that "Anybody else who's viewed the source code could have found the vulnerability and been exploiting it all along," but this ignores the community-spiritedness of opensource as well as the loose lips of most crackers. Things like this go public. And. . .
2) The problem can be fixed, in a variety of ways, by anyone. No waiting for patches from The Source.
3) This reflects very well on open source. But it is a blow to Redhat.
If a Linux for serious hackers shipped with a few holes, the make-rs might reasonably claim that their product wasn't meant to be polished and perfect (they'd be asses not to abase themselves and offer a fix, though).
But Redhat,, which even more than other distros claims to make Linux easy and user-friendly, desperately needs to be just that. They're the ones who should be allowing users to trade up-to-the-minute kewlness for reliability and security. There's no shame in that, but there is shame in doing it badly.
Summary:
Redhat screwed up. Open source fixed it.
- Michael Cohn
The bad do bad because the bad is rewarded. The good do good because the good is rewarded.
beta quality code (Score:3)
Would any good sysadmin allow beta (0.4) code on a production box? ...
Which brings up another point ... If RedHat or any of the other distros want to avoid this type of hype, include only production-quality code in the distro.
Porco RossoAnother Red Hat password to try (Score:4)
Hrm... (Score:4)
Now weary traveller, rest your head. For just like me, you're utterly dead.
This is all getting out of hand. (Score:4)
So what do we have now?
Instead of kicking Rhat's but for slack in Quality Control we sing praises to open source. This is getting fscking out of hand. Slashdot has to get some bias control after all.
Does the door swing both ways? (Score:4)
Redhat backdoor: Hurray for open source!
Now the question is, will ESR write an article about the dangers of Open Source? Or will the open source community set another wonderful hypocritical example?
development environment bug (Score:4)
A great example of this is if an application needs to create a temporary file. Temp directories are publically accessible, they need to be. But this means more than one user has access to them (if your OS can handle multiple users :) and this provides a place where malicious users can interfere. There's a lot of bending over backwards you can do to detect or avoid the problem, but the so-called experts seem to think that everybody should learn every trick and apply it manually. Why not provide API calls that allow a programmer to SecureFileOpen() and get a secure open file?
So, I haven't read the source for this Piranha web admin package to see why the default password Q was in there, but I suspect the coder working on it put it in as a convenience to herself for development purposes, so she could test things without having to create accounts every time. But, every app with passwords needs to do this because it is just as tedious as for every programmer. So why not build pseudo test accounts into the platform just for this purpose, rather than into the app?
Default Passwords (Score:5)
Anyone that doesnt change a non-unique, default password, that is documented 8 ways from sunday, deserves whatever he gets.
-=Bob
Happens all too often (Score:5)
Two notable examples are Oracle's database (I've been told that it's set to change_this by default - my apologies if that is no longer the case), and MS SQL Server (the admin account has no password set by default - we were using it like that for at least the first 6 months that I was at the company before someone thought to change it...)
There is absolutely no reason whatsoever for creating an account with either no password or a default one. To not prompt the user to enter a password smacks of laziness and/or thoughtlessness. Someone at RedHat needs to have a good, long talk to whoever there is responsible about good security practice. Unfortunately, the same can be said of a good few other companies, too.
As for the second flaw, that you can cause arbitrary commands to be executed by the user running the web server when using piranha to change the password, that is utterly inexcusable. Assuming that the server is not running as root, then it is not too serious, (as long as you don't mind your website being deleted/defaced), but it displays an almost breathtaking lack of thought on the part of the person responsible.
I assume that the password is changed by way of a call to passwd, and that the "hack" is to append a "; arbitrary commands go here" to the end of the password field. If this is the case, then why on earth isn't the string checked for that sort of thing?
This has to be the oldest way of attacking a web site in the book; ever since the concept of CGIs was invented, people have been trying to get arbitrary commands run on servers in this way. (Another common first attack is to do a similar thing to any input field that looks like it'll be used to construct an SQL query - just end the field with '; (single-quote semi-colon) and insert your own commands. A coleague and I very nearly had one of our SQL servers play ball when we did it to one of the sites that he'd developed using SiteServer Commerce edition - the code being executed was in a SiteServer module, not something that he'd written. IIRC it was only the max length being set on the field that stopped us, and we couldn't be bothered to write a perl script to bypass the html page...)
I know that everyone makes mistakes, but this really is very basic stuff indeed. I'm no security expert, and even I know about it
In this day and age of entire businesses depending on the security of machines that are open to attack 24/7 (and have to be up 24/7, too), people really do need to be more security conscious.
Okay, rant over - I just needed to get that off my chest
Cheers,
Tim
DON"T JUST RESET THE PASSWORD (Score:5)
This is the serious part of the security issue, obviously. Just resetting the password, as is suggested above, is not going to solve the problem.
========
Funny, funny (Score:5)
So this "backdoor" comes up, minor also, but it would apppear quite a bit more serious then MS's. And what do we get? That's a victory! We found the bug! That's why open source is king! Jeez people, that's one big way of making open source look bad, and I mean really bad. Is it all just the hype and total biasing?
If we want to bring more respect to the Open Source initiative, then we have to treat these things the same way another OS is treated. If we don't, then it just helps to convince the world that it's just all hype.
You know, there should be a contest. I'd love to stick in a mischievious backdoor and see if people could find it in thousands/millions of lines of code.
Re:Default Passwords (Score:5)
As to Pirahna, it was audited. I can attest to that because I'm the guy who audited it and Im the one who missed the quoting error that let the ; thing work.
Real Lesson 1: Never write secure code in languages with unclear evaluation semantics.
Real Lesson 2: Nobody is infallible
Alan
Re:This is all getting out of hand. (Score:5)
Is there really a difference between this and a company coder finding the bug? There is something to be said for a constant number of eyeballs being paid to stare at and stress the code all day long. A million open source developers won't help much if any one of them doesn't analyse the code for more than say, 30 minutes, or whatever their personal interest level or attention span is. The difference is purely philosophical.
Well thank god crackers have such big mouths. That really saved us. Again, how does this differ from a cracker finding it in a proprietary product and blabbing about it? The only difference in this case is that, while we all agree that security through obscurity is EVIL and anyone who relies solely on it should be ashamed and flogged with wet noodles, it DOES have the effect of slightly lowering the chance it would be found by black hats in the first place. Thus technically the closed-source product has an edge here. No, put down the flame thrower, I STILL agree that there are fundamental philosophical virtues of open source, but I think technically the closed source product has the slight edge at this point. (the sin of the closed source product being that maybe you don't WANT to rely on them to find and fix it before the crackers do something bad...I'm talking about an ideal universe here)
This is a concrete benefit of Open Source. While a company coder can probably whip up a fix and distribute very fast, it most probably will not be as fast as the person who just found the bug. But again, Open Source puts the burden on the user (user in whatever sense the person is using the product...could be a developer) to have the knowledge and skills (and time!) to actually fix the bug.
I think this reflects ambiguously on open source. It just proves what we thought all along. YES, bugs are easier to find and exploit. YES, bugs are easier to find and fix. Net gain: 0 Net loss: 0
Yes it is a blow to Redhat. Distros are basically for packaging/quality assurance/testing. So they better damn well be sure there are no glaring, Microsoft-sized, holes in their distros. That's just plain careless.
I don't think this is such a glowing testimony to open source as it is a lukewarm observation of fact. They staple-gunned themselves in the foot and someone bandaged them. *applause*
There is room for both cathedrals and bazaars.
Where is the problem ? (Score:5)
I use 'Q' as password really often, it is a FAR better password that 'E' or 'W'. Trust me, with 'Q' you are secure, don't be afraid.