Slashdot Mirror
Root Password Readable in Clear Text with Ubuntu
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."
What's the problem? Open source passwords make it more secure.
Oh PLEASE, what a joke of a comment. The fact is, they fucked up BIG TIME. Yeah, it's a nice distro, but so is windows, and had microsoft made this error you'd be on their ass about how crappy windows is.
The bias here on slashdot sometimes makes me sick.
Grow up people!
Invariably, a lot of the comments to this story are going to commend the team on the incredibly speed with which they've released a patch, and there'll probably be some comments comparing it to closed software. Yet another victory for the open source model!
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.
Read the article. The Slashdot summary is incorrect; the password is for the account you create during installation, which has sudo rights and therefore is just as effective as a root account.
Karma: Terrifying (mostly affected by atrocities you've committed)
Information wants to be free
Fuuuuck.
I knew I never should have trusted those badgers.
Smiling at me with their big cartoon teeth, eating up all the aspen, wanting to admin their own machines.
I've been a sap, and it's going to cost me.
And now I'm worried about the hedgehogs.
Any programmer who doesn't stop themselves and think that writing something like fprintf(logfile, "root password entered is: %s\n", password); is not the best idea should not be writing code for a secure operating system.
Contribute to Open Password comunity - release your passwords under the GPP (General Public Password) license! Because closed passwords are just series of * symbols - it's hard to use, share and modify them freely. :-)
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.
The road to tyranny has always been paved with claims of necessity.
If Microsoft had made the error, we'd have to wait until the second Tuesday of the month for the fix. If this bug wasn't caught by tomorrow for me, then I'd have to wait an entire month for a fix. Ubuntu put out the patch as soon as it was discovered. There is no bias here, I use Windows just as much as Linux. However, Microsoft's patching cycles simply suck.
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.
I find it very interesting that the severity of this bug is identical to the severity of the security hole found in OSX last week... yet the difference in attitudes is remarkable.
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.
Nevertheless, AC is right. If it was relvealed that the local Administrator account or the domain Administrator account was stored anywhere as plain text in Windows 2000, XP, or 2003, then MS would be reamed endlessly and very harshly here.
i n/MS00-035.mspx
Interestingly enough Microsoft did make pretty much the same mistake, with Microsoft SQL 7, both servicepack 1 & 2. They wrote the SQL administrator password to the installation log file, which would give you full access to any SQL database on the server. Written to a logfile in the TEMP folder, which by default has full read/write access for any user on the system.
Security bulletin: https://www.microsoft.com/technet/security/bullet
(The 'non-recommended' mode mentioned is using SQL authentication instead of windows NTLM authentication, which much more common then they try to make it sound)
Actually slightly more elaborate: SQL 7 SP3 was also affected, plus they wrote the password to not one, but two files:
Summary
On May 30, 2000, Microsoft released the original version of this bulletin, to announce the availability of a patch that eliminates a security vulnerability in Microsoft® SQL Server® 7.0 Service Packs 1 and 2 installation routine. When run on a machine that is configured in a non-recommended mode, the routines record the administrator password in a log file, where it could be read by any user who could log onto the server at the keyboard.
On June 15, 2000, the bulletin was updated to note that, under the same conditions as originally reported, the password also is recorded in a second file. A new version of the patch is available that prevents the password from being recorded in either file.
On May 10, 2001, the bulletin was updated to note that Service Pack 3 is also affected by this vulnerability. A new patch is available for SP3 and we are also providing a command line utility (post Service Pack deployment) to remove all instances of the SA password written in either file via Q263968.
So not only did they have a similar problem, it persisted for over a year after initially being found & alledgedly fixed.
Many people know how to generate these special characters but I'll mention anyway: using the ALT/META key and the NUMPAD keys. Having a character map printout handy so you know the DEC (decimal) values of these special characters is a good idea if you decide to implement one of these passwords. Punch in ALT-DecimalValue with number lock on.
They may not work in some situations if special characters and not allowed, but you'd be surprised that they do work most often.
I bet most dictionary attacks don't run through many special characters. The cracker is lazy too and will probably not even consider that you chose a funny character which does not even exist on the keyboard.
Remember not to use NULL (#0) though, for crying out loud.
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.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
Don't use a bleeding edge home desktop OS if you want a secure multi-user server.
I'll probably be modded down for this...
Since long before MS-DOS had them:
Look..
Every bloody emperor has his hand up history's skirt [Peter Hammill/VdGG]
Why the hell is everyone trying to downplay the severity of this? This is a serious issue, its worse than most security problems I've seen with *any* operating system, stop the hand waving, and spread the word instead. This *is* serious and shows poorly on the Ubuntu developers. I mean, how many people have set up linux for their parents or family, chosen Ubuntu and now they have to make sure they go in and change that. Updating won't always work (for reasons listed elsewhere), the only sure thing to do is to physically change it (if ssh access is enabled than its easier).
/. or digg and if they don't update then they are screwed more than they were before. I don't like knowing that a local user vulnerability will can give out root access
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
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.
I have never made but one prayer to God, a very short one: "O Lord, make my enemies ridiculous." And God granted it.