Red Hat 'Piranha' Security Risk - And Fix

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:This is all getting out of hand.

Pray tell, what default password would have been safe?

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?

As far as I can understand that, "Piranha" is not installed by default and you have it only if you *want* it; and once you took the pain to install it, the least thing would be to change the default password.. is it really a backdoor or a lazy user? If s/he's got enough insight to install the thing in the first place, that seems quite unprobable to me that s/he would leave it at that.

Re:This is all getting out of hand.

There have been a few responses to this, which I'd like to draw together:

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

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 Rosso

Another Red Hat password to try

!seineew era sreenigne erawkcalS

Hrm...

Another victory maybe... but what stupid arse done that in the first place? Yes, I know, people make mistakes all the time. However, if we want open source to be taken seriously, we at least need to try. Look at how many people laughed at the Microsoft Web Server backdoor not long ago. Isn't this error just as idiotic?

Now weary traveller, rest your head. For just like me, you're utterly dead.

This is all getting out of hand.

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?

Microsoft "backdoor": Hurray for open source!
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

I subscribe to BugTraq, a mailing list devoted to security. (you can find archives buried in the horrible security focused [securityfocus.com] website.) After a while you get a good idea of the range of security holes and mistakes that allow them. But, IMO many of them could be avoided if the fix was put in the development environment, and not in the app. Then, other apps could benefit from it as well and not repeat the error.

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

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

Okay, hands up anyone that's never used software that creates an account with a dumb password when it's intsalled?

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

Quote from the story: A second flaw, also discovered by Internet Security Systems, could then allow a user to gain full control of the computer. In this second flaw, an intruder working inside the Piranha console can select the "change password" option, then tack a line of computer instructions on the end of the new password. The code, which can do anything the Web server itself can do, will then be executed by the computer, according to researcher Allen Wilson, who discovered both flaws.
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

I just read the article on ZDNN, and knew that something like that would come up here at Slashdot. Oh man, this is a victory for open source??!?! Just a few days ago tons of people were bashing Microsoft for a very minor security hole. And I mean really bashing Microsoft.

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

Accidentally shipping a default password is not good. A 'security' company that blasts that password around rather than saying 'there is a default password that can be cracked' is even more foolish.

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.

Let me play devil's advocate:

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.

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.

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. . .

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)

2) The problem can be fixed, in a variety of ways, by anyone. No waiting for patches from The Source.

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.

3) This reflects very well on open source. But it is a blow to Redhat.

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 ?

I do not understand where the security hole is.

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.