Root Password Readable in Clear Text with Ubuntu 520
BBitmaster writes "An extremely critical bug and security threat was discovered in Ubuntu Breezy Badger 5.10 earlier today by a visitor on the Ubuntu Forums that allows anyone to read the root password simply by opening an installer log file. Apparently the installer fails to clean its log files and leaves them readable to all users. The bug has been fixed, and only affects The 5.10 Breezy Badger release. Ubuntu users, be sure to get the patch right away."
Saw this on Digg (Score:3, Insightful)
Re:Saw this on Digg (Score:5, Insightful)
The bias here on slashdot sometimes makes me sick.
Grow up people!
Time From Discovery to Patch (Score:5, Insightful)
Yet how long has this massive fault been sitting there waiting for the first person to discover it? How do we know that the public acknowledgement of it was the first actual discovery of it?
I believe Breezy was released in October, so for five months install logs have been sitting, world-readable, often with the root password. Surely in that time someone well less savoury motives did a simple grep of an install looking for the most trivial of faults.
Feeling confident in the speed of the patch relies upon the belief that no one with nefarious motives discovered it before a benevolent bug submitter did.
Awesome (Score:2, Insightful)
Within the same 30 seconds a post appeared following mine comparing the fix (which has the massive complexity of deleting some log files) with Microsoft's WMF fix, exactly as predicted. Beautiful, and so predictable.
Place it in context of surroundings (Score:2, Insightful)
So what if this was fixed quickly. (Score:5, Insightful)
Re:Time From Discovery to Patch (Score:5, Insightful)
Anybody with an ounce of common sense should know that you never leave a critical password floating around in plain text. Not in memory, not in swap and you never print it to a bloody log file. Who's going to want to check it?
Passwords are supposed to be non-reversable. The NetBSD installer seems to run the passwd command directly during installation, so the installer never sees the password. Did somebody get the bright idea of prompting for the password in their own UI when the graphical installer was done? This should have been caught. The design of the installer is at fault. Not the log file. I wouldn't count this one as fixed until the installer never sees the password. Sorry for the rant.
Re:okay (Score:3, Insightful)
Re:Saw this on Digg (Score:5, Insightful)
Re:Saw this on Digg (Score:5, Insightful)
Be honest. Everyone here knows that storing the root password as plain text is a clear program error. And since GNU/Linux is a rather secure OS that doesn't have this vulerability in any other distro, this code was added by the Ubuntu team. If this is the quality of code that the Ubuntu team is developing for it's distro, though, I do have to question why it is so popular. Why was such an obvious mistake missed? Who forgot to check how the root password is stored? Who forgets that kind of thing? Not the kind of developer I'd want to trust with my security, I'll tell you what.
Despite this little pasword issue... (Score:2, Insightful)
Now, let the script kiddies who have nothing better to do flame me for saying Ubuntu is cool. These same script kiddies who think they're 1337 because they have to manually set up their Slackware box. These same wanna-be geeks who are still bootstrapping their Gentoo systems for 12 hours to extract a extra 5 milliseconds of speed from their CPUs. I've done all that and now that I'm almost 40 years old, I just want a quick, stable system to work from.
Re:Saw this on Digg (Score:5, Insightful)
Patching is quite frankly irrelivent with this bug. While it certainly has to be done to close the hole in the future, there are already hundreds of thousands of Ubuntu systems out there with the password sitting on the disk. How are you to be sure as an administrator that the password has not been compromised already? What about backup copies that might have the password?
The fix is to change the administrator/root password. The bug only affects a system at install-time, and it will continue to affect new installs so long as the broken installer is floating around. Patching it today is hardly more effective than patching it on April 6.
Re:okay (Score:4, Insightful)
Interesting juxtaposition (Score:5, Insightful)
Look at the slashdot summary. "An extremely critical bug and security threat". Compare with the OSX bug which was written off because it's not remotely exploitable.
Apple hasn't even acknowledged that the OSX privilege escalation exists, let alone patched it.
What does patch help? (Score:4, Insightful)
What does this patch fix? The installer? Sorry, but the installer is burned in the installation media, and a patch can be applied only after the installer has been run. So updating the system or even upgrading to Dapper (where it has been fixed) doesn't help. So....patch whAt???
No really, the installation ISO images should be fixed immediately and redistributed.
Also saying that it "only affects The 5.10 Breezy Badger release" may be a bit belittling, as probably most people have installed exactly that release.
Re:Place it in context of surroundings (Score:5, Insightful)
WTF are you smoking? No modern OS sets up an unpassworded root account by default, especially on a multiuser system. And if they did, there would be no expectation of security. Here, there is the expectation of security, and it is violated.
In fact, this attack is even worse than the average privilege escalation vulnerability, because a) it's amazingly stupid on the part of the programmer and b) the attacker gains not just root priveleges but the root password, which is often reused by less-paranoid users for other purposes.
Use the right tool... (Score:5, Insightful)
Re:So what if this was fixed quickly. (Score:4, Insightful)
The problem here is that the main user password (Ubuntu doesn't have a root password) is asked through the questions dialogue in the installer. Everything here is automatic and the questions dialogue just simply records everything down in a file called "questions.dat". It's a serious error for a programmer sure, but it's just a lack of thinking of everything when programming, which is what every single security hole is caused by, lets face it. You could just as easily say everyone who doesn't check their arrays every single time no matter what shouldn't be let within ten feet of gcc, but alas even the best make mistakes. Not only this, but someone who doesn't check every array may be letting through a remote exploit, which is much much more serious than this bug.
The mantra of course applies here: Unless you've programmed a totally secure operating system, keep your mouth shut.
Re:Root password should never be recorded, ever (Score:2, Insightful)
Insecure memory? Unless I'm missing something huge here, one process can't read another's memory. Can you give an example of how something can end up in "insecure" memory?. Maybe if you have access to /dev/(k)mem. Same goes for swap afaik. If those problems haven't been solved long ago, any Linux distro is swiss cheese.
Which means it's as simple as a GUI prompt for the password, and a pipe to passwd, no writing to disk necessary at all.
Patch mirror (Score:3, Insightful)
PASS="my_root_password"
echo "Why would anyone log a password in the installer?\n"
find
echo "Why would anyone have
chown -R root:root
chmod -R o-rwx
echo "All done, thanks for using Atomic-Penguin\'s unofficial ubutnu patch!\n"
Re:Legal before security-the openssl vs netatalk m (Score:5, Insightful)
This has been discussed at length, and OpenSSL's license is GPL incompatible. Everyone else may simply think it's ok to bend the rules, and that they won't ever get sued for it. That's not a safe assumption for a volunteer-based distribution.
This doesn't stop every other distribution on the planet from compiling netatalk with openssl, and hence supporting encrypted passwords.
"Everyone else breaks the rules, so its ok." That doesn't work for speeding tickets, and it doesn't work in contract/license disputes.
They politely suggested that GnuTLS, which isn't even remotely drop-in, be used instead. That was back in 2002...and the issue still hasn't been addressed. I filed a bug on it and the bug was simply ignored.
Maybe you and any other users of appletalk on unsecure networks ought to band together and fix it. Alternatively you can just switch distributions or upgrade your networking from appletalk (a 1980s protocol, since you were talking about being 10-years backwards).
Does it suck? Yes. It sucks that the OpenSSL people won't change their license, and upstream netatalk doesn't care either. However Debian would risk legal action against ALL users if they break the law, even though 1% of the users use this package. They chose the solution for 99% of their users, which is the best you can hope for in an esoteric case like this.
Re:Solution (Score:5, Insightful)
(Only passwords used during the install are written to the file in question.)
Re:Saw this on Digg (Score:5, Insightful)
One of Ubuntu's big things is giving out free cd's, in particular targeted to people who don't know what linux is. Me and my roommates actually had a 100 or so Ubuntu CDs, most of which we've given away. We both run Fedora, it fits our needs as "powerusers" better, but give out Ubuntu simply out of convenience and to help the "cause". They are both nice distros, but security is definitely one area where Fedora surpasses all of the other distros.
Fedora makes security transparent to the user, you're running SELinux but would never know it unless you needed to, you're running exec-shield but you'd never know it unless you needed to, all the major services are compiled to randomize memory mappings, but the user is none-the-wiser. That goes for advanced and beginning users. I can install Fedora and be fairly certain that even if somehow my system stopped updating, that any vulnerabilities found would be stopped by these additional measures anyway. The measures in place make most buffer overflows useless and even if you somehow got passed all of the measures to prevent overflows and you got root through an exploit in a vulnerable service (despite that the services don't run as root), SELiux would probably still make your entry pretty pointless.
The point I'm making is, the differece between a secure OS a non-secure OS are ones where even without updates, the security measures in place are foward looking and work to prevent current unknown attacks. Fedora has damn near perfected this, but if any of the users of the Ubuntu CDs I've given out somehow managed to disable updates, they are screwed now. There should never be a situation like that. Bravo on the response time, but seriously the users most likely to be affected don't read
Regards,
Steve
Re:So what if this was fixed quickly. (Score:3, Insightful)
Real Solution: CHANGE YOUR PASSWORD (Score:4, Insightful)
The patch (unless it goes out and deletes the offending files) is only going to patch the installer (which you're probably never going to run again). You're still going to have a cleartext copy of your original admin password sitting on the box in a file with read-other permissions.
Even if the files get deleted (or have their permissions changed), you still have no idea as to whether somebody has read the files since October.
BTW: Are they re-burning the installation CDs?
Dude, if you have to... (Score:2, Insightful)
Re:Saw this on Digg (Score:5, Insightful)
This is a consequence of Ubuntu's different security model. You can't be root in Ubuntu; you have to consciously make the decision to run software as root by typing 'sudo' before it. (Actually you can run a shell under sudo, but still.) The idea was that since you can't login as root, the system is more secure and resists exploits that try to gain root access. This vulnerability is the kind of stupid mistake people make sometimes. A brain fart. Nothing really malicious, and not the sign of an incompetent programmer. Something you could've done.
Most Windows vulnerabilities are that, too. There's just more of them. And the system is inherently less secure, so it doesn't resist those quite as well. And it's harder to update because it's a monolithic kludge. Of course, some Windows vulnerabilities are just the product of poor design.
And another thing, if this happened, /. would bash Microsoft insanely. True. There is a bias. But still, I highly doubt the issue would be fixed in the same day, on a Sunday, and the update would be availiable quickly and painlessly.
Ubuntu updates and why I don't install them (Score:1, Insightful)
I need my linux install to work all the time because I rely on it to do my school work (computer science). An ubuntu update has never broken my system before, but it's a concern for me nonetheless. Every linux system is configured differently, and I'm not willing to bet my academic success on the hope that my exact set of installed packages and config files on my hardware won't have any problems that weren't caught in some kind of non-commercial open-source testing phase (or perhaps weren't tested at all).
Call me paranoid, but I always wait until a break to install my updates. I've chosen to effectively have the same security update frequency as Windows even though I can plainly see when new updates are available. Hopefully I won't get p0wned because of it.
Re:Root Passwords should never be stored ANYWHERE. (Score:2, Insightful)
Re:Saw this on Digg (Score:2, Insightful)
And that fresh install will be gentoo. This is really embarrassing for Ubunutu. Iam just so happy my work servers all run solaris.
Re:Saw this on Digg (Score:2, Insightful)
Re:So what if this was fixed quickly. (Score:3, Insightful)
Joking aside, if you apply that little mantra of yours to other scenarios, you'll see how silly it is. How about "Don't criticise Gigli unless you've produced the perfect film"? How about "Don't criticise your plumber for not fixing your leak and flooding your basement until you've laid the perfect pipe"? How about "Don't criticise your goverment until you've ruled over the perfect society"?
You do not need to be an expert to see when an expert is doing a crap job of it.
"you should fix it" is elitist bullshit (Score:3, Insightful)
Secure password authentication in AFP was introduced at least 10 years ago. We're talking about AppleSHARE here, Mr. Genius. A protocol fully maintained and used extensively on current hardware. I'll switch to SMB when it offers the same level of performance as AFP (it doesn't, not even close, in raw transfer speed or directory operations) and the same filename compatibility.
Maybe you and any other users of appletalk on unsecure networks ought to band together and fix it.
So let's get this straight.
Like many a faithful geek, I was led down the path of "enlightenment" offered. I helped give open-source software market share. I helped sell open-source to my boss, and my boss's boss. I redirected my career to support open-source software.
And what do I get in return? "Fix it yourself, you dumb user."
To think I still get asked why I'm not running Linux on my Powerbook. Because IT JUST WORKS; no politics, no "nobody cares about that bug so it won't be fixed". Because I don't have to deal with arrogant blowhard grad students telling me to fix software myself. I have neither the time, ability, knowledge nor inclination necessary to run around fixing complex software. 99.999% of the rest of the world doesn't either. Sad reality of life is that there is an extremely small segment of the population of linux users that have even the slightest qualifications to know how to go about fixing bugs or adding features.
Like most academics, you have zero comprehension of what matters in the real world. Joe Sixpack doesn't go into Firefox and add features. Jane Officeuser doesn't fix GnuTLS so it works with netatalk. Users don't give a damn about theoretical lawsuit possiblities. They don't give a shit about the finer points of licensing. Nothing impresses a CIO or a Director of IT less than "oh, we have to transmit passwords in clear-text because the license for a system library isn't compatible with the license for the server software."
Oh, and if you believe the whole Debian kool-aide line about "we have to protect this because we'd ALL BE SUED", I have two bridges in NY I'd just LOVE to sell you. PS: It says "gullible sheep" on the ceiling.
Re:"you should fix it" is elitist bullshit (Score:3, Insightful)
And anyway, you may find in this post-SOX world that administrators care a bit more about the legality of their software than you may think.
Re:Solution (Score:4, Insightful)
Make sure you remove permissions for users to change the root password though. On a default Ubuntu install all a user need do is sudo passwd and enter root's new password (no need to enter the old one).
Re:Solution (Score:1, Insightful)
Re:Root account not activated during installation (Score:3, Insightful)
Re:So what if this was fixed quickly. (Score:1, Insightful)
> Let's check your facts...
*Ahem*
The sky is blue, water is wet, Ubuntu evangelists are pedantic blowhards who can't recognize a common English phrase when they see one...
And don't bother flaming-- I use Ubuntu myself. It's just that It's just that I miss the times when Linux evangelists were, you know, nice people. These days all we seem to get is shrill "$foo_distribution r0x0rs!!" shills.
Besides, flaming a user, especially when your distro is caught with your pants down, is never a good idea.