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

Re:Just in case

[miro f]

no need to give them local access to your system, they can easily read it if you have an ssh server set up for example. And no it doesn't display the root password, but it displays a username/password combination which has access to sudo. So just as bad.

Re:Open Password!

[Brandybuck]

I actually used ***** as a backdoor password for a system I once worked on. Really! The service department demanded a backdoor password to give the service people, so that they wouldn't be calling in all the time for passwords. I fought and fought, but the lure of a continuing paycheck was too much, so I finally relented. My second choice was eight spaces.

Re:Saw this on Digg

[MobileTatsu-NJG]

"It came out, it was fixed. There are going to be problems in any project this large, but it shows how much the Ubuntu team cares to respond to a problem this quickly and on a Sunday of all days. Ubuntu really has become a nice distro. It's completely free and polished around the edges. I hope they continue to do well."

I know this rationale gives everybody the warm fuzzies, but this is still a really bone-headed mistake. You guys really shouldn't be this forgiving about it.

Re:Saw this on Digg

[xlsior]

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.

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/bulleti n/MS00-035.mspx [microsoft.com]

(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)

Choose strong obscure passwords

[L505]

Using special characters not available on the keyboard is another strong security measure..

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.

Re:But Ubuntu has no root account!

[Anonymous Coward]

It DOES have a root account, it's just it sets the root password to some value that you're not trusted enough to be told. I personally fall prey to "bad" sysadmin techniques, and I sudo passwd root first thing. I then log in as root for sysadmin functions. In general, my systems are not intended for multiuser shell access (read - I'm the only user with shell access anyway), and it's a pain to sudo everything. I end up using sudo bash, so I may as well just log in as root to start with. I've never really understood why it's so BAD to log in as root. Yeah, so you can screw stuff up on accident if you're not careful. Typing sudo before the command as a regular user is just as bad. I guess it might make sense if you have multiple sysadmins and want to track who did what. But in my case, I am the only sysadmin, so why bother with the extra "security"?

Legal before security-the openssl vs netatalk mess

[SuperBanana]

Want another example of Debian/Ubuntu idiocy?

The netatalk package, which provides Appletalk services (most commonly used servies are AFP, ie filesharing, and papd, the printing spooler), isn't compiled in with ANY encrypted password support. If you connect to a debian or debian-based appletalk fileserver, you get a warning you are transmitting your password in clear-text. Yes, we're jumping about 10 years BACKWARDS in security.

Why? Because the legal-circle-jerk that is the debian-legal mailing list, decided that it wasn't "legal" to link netatalk (a GPL project) to OpenSSL (license supposedly incompatible with GPL.) This doesn't stop every other distribution on the planet from compiling netatalk with openssl, and hence supporting encrypted passwords.

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.

Re:Root password should never be recorded, ever

[MichaelSmith]

All that the operating system/software need to know is how to verify that the password entered is correct. And that can be done without storing the root password at all (encrypted or not) with a hash.

I assume that the OpenBSD installer runs passwd to set the root password during installation, similar to NetBSD.

But if either of these OS's went to a graphical installer they would need to write a graphical passwd command which makes an effort to keep the plain text out of swap files, insecure memory, etc.

That's a big ask, IMHO. Which doesn't mean its ok to print the thing out, just that doing it properly is very hard.

But in this day and age of development frameworks, etc, there is less of a need for a programmer to think about the meaning of what he is reading from the UI. The backend programmer may assume that the UI guy understands about passwords, but he may not, to.

Does not apply to expert mode installs

[Pausanias]

I didn't find the password in my installer logs. It seems that if you install in expert mode you're OK. See the bug report here:

https://launchpad.net/distros/ubuntu/+bug/34606 [launchpad.net]

Re:Choose strong obscure passwords

[Anonymous Coward]

...still more proof that NUL-terminated strings are the work of the devil. C'mon -- give up two bytes at the front of the string to tell how long the damned thing is. It's not fucking 1974 where the loss of a couple of bytes is gonna crap out the system. Prepend the length -- and reserve a value like 0xFFFF to mean "at the end of this string find another string with its own length encoded there..." -- Yes, I know, there's the potential for collision with a string that's actually 0xFFFF bytes long - but hey, the problem was solved to everyones satisfaction by pretty much every RLE encoding scheme.

Null termination is evil. Every buffer overflow you read about is a side-effect of null termination which could be avoided -- at the cost of two bytes per every sixty-five-thousand bytes of string.

Re:Time From Discovery to Patch

[Anonymous Coward]

> Who's going to want to check it?

Personally, I stumbled on the flaw last month, completely by accident, reading logs on a system to which I have remote (unprivileged) access. Naturally I had to test the (enabled) root account to see if it worked. It did. So strike one for that whole "more eyes" thing. Posting anonymously for obvious reasons.

Re:Open Password!

[dwater]

You should've made the password something with a tab in it...(works on some login methods, but not others).

Re:Saw this on Digg

[wertarbyte]

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.

There is another stupid vulnerability I noticed in Ubuntu, which relates directly to the missing root password: If something goes wrong during system startup (e.g. a failed fsck), usually you are prompted for the root password to open the rescue console and fix the issue. Not so with Ubuntu: Since there is not root password, you will be thrown into a root shell without any hesitation. Kind of strange, is it? One could argue that once you have physical access to the system, you have a lot of possibilities to circumvent the system's security, but I found this issue to be rather harsh.

Re:Place it in context of surroundings

[Anonymous Coward]

When XP (as of SP2) doesn't have a password on an account it doesn't allow network access to the machine with that user, so a blank admin password after setup can be more secure than a simple password.

Re:What does patch help?

[Fallingcow]

I actually picked up the 5.10 disks last week, and was thinking of installing it... glad I didn't.

You think that--within one week of installing--someone who already has a valid login to your machine would have 0wned your box using this security hole? What, was it a server or something?

If it was just your desktop machine, then yeah, this is crappy, but it's hardly a disaster, and the odds are pretty good that not even one person running Ubuntu on a simple desktop machine was harmed by this at all.

If the problem is in the installer which is only run once, am I correct in assuming that using a 'dummy' password during the install and changing it afterwards will leave only the dummy password on disk?

Er, or you could just edit line 2140 (IIRC) of /var/log/installer/cdebconf/questions.dat to remove the password. Or delete the file; I'm pretty sure it's only there in case you want a record of your install, so unless you get a kick out of reviewing your installation process, just rm the damn thing.

Re:Choose strong obscure passwords

[ajs318]

Only two bytes? That's a limitation of 65536 chars -- not that much really when you think about it. For crying out loud, we have 64-bit processors now. Please, let's think of the future, and reserve eight bytes for string length -- just in case somebody ever wants to put the entire addressable space into a scalar.

Re:Does not apply to expert mode installs

[Pausanias]

OK, well folks in the bug report are now saying they have the cleartext password in their logs even with an expert install. So it's not at all clear why some users have the cleartext and other don't. Anybody know why?

Re:Time From Discovery to Patch

[xenocide2]

The design of the installer is naturally at fault. The way it works currently is it stores the answers to a bunch of questions asked during install, and then feeds them into the install system. If the answers list was simply a log, the easy fix would have happened ages ago: simply don't output the password to the file. Clearly the system is using that to send to the create first user script. That script is supposed to remove that entry, but it appears to have temporarily broken. I gather its generally useful for repeated installs, but storing plaintext passwords in a file is still a bad idea, reguardless of how easy it is to access it. I suspect the guys responsible for the installer will be able to provide a better discussion of what went wrong, how to fix it, and how to test for similar errors in the future. Theoretically, you shouldn't have any storage on disk for it, even for the duration of an install. But realistically, the window during which you could convievably attack this temporary storage is very miniscule. The answers list is pretty long and deleting a line from it wouldn't likely result in data getting duplicated on disk. Maybe with a full journaled FS, but I'm not sure on that one. Still, I'd much rather see a fix more along the lines you've described above.

The bigger scare factor here is that the Ubuntu repos are presumably running Ubuntu. You can moan on about md5 security and RSA signatures, but when the private keys are readable all bets are off. Let's hope they run netBSD.

I should point out that while I am using breezy, I don't have this problem in my install log and neither did anyone else I know using Ubuntu. Probably because I installed it long long ago, before this particular vuln existed. Additionally, I've read it doesn't happen in dapper, the next version in testing. Oh, and calling Ubuntu's installer "graphical" would be far too generous.

Re:Solution

[M1FCJ]

Ubuntu crowd again and again told the world that Ubuntu had no root password set up therefore couldn't be cracked in. I asked them (again and again) "surely you are setting this to something?" and they all said no. It is now perfectly clear that the people answering my questions had no clue. With every ubuntu installation the first thing I did was setting a root password, even if you don't have any intention of using it, in my opinion having a password you don't know about is worse than having a password only you know. This SNAFU proves my point.

Re:Use the right tool...

[kestasjk]

True, it's also worth bearing in mind that the server install of Ubuntu 5.10 doesn't suffer from this vulnerability.

Re:Saw this on Digg

[FireFury03]

the only way to protect your machine against attacks by someone with physical access to it is to raise a BIOS password or encrypt your files, not a bad idea in any case.

Encrypting the hard drive is an answer, but then you have the problem of where do you store the key to access it? If it's stored in the bootloader or the kernel then that can be extracted by the attacker if they have physical access to the system. This is basically the same as the DRM problem - you can encrypt the content but you always have to decrypt it to use it so you need the key stored somewhere and that is always a possible attack vector.

Also, you need to think very carefully about the ramifications of encrypting data - if you lose the key you're screwed.

Encrypting the hard drive using keys stored in Palladium is an option but it only protects you from someone removing the drive and installing it in another machine, and again - if you motherboard (with it's Palladium chip) blows up you're buggered.

Elitist is still better than business freeloader

[Anonymous Coward]

Sure, free feel to return all the money you paid for the FREE software.

There is no kool-aid that creates software magically. Either

a) have competence to fix stuff yourself or
b) pay someone to fix them

Yes there is people who do stuff out of goodwill, but like you have found out, they work only on issues they find themsefl interesting, which (this seems to be a suprise for you..) might not be the problem your BUSINESS is seeing.

I have neither the time, ability, knowledge nor inclination necessary to run around fixing complex software.

Yet you have no problem making your LIVING using such software. There are people people who have those skills and would be happy to fix those pieces for your company for modest fees.

You are the only person gullible here, if you really think Free Software is perfect out of box for you specific business needs.

If you did not have that Asshat attitude, you would have noticed funding netatalk to use gnutls instead of being a license violation, would not cost much, and would give the warm fuzzy feeling of improving OSS world for everyone. But sure, use your worktime to whine slashdot to annoy and demotivate people. It might be as effective..

Re:"you should fix it" is elitist bullshit

[Anonymous Coward]

I have neither the time, ability, knowledge nor inclination necessary to run around fixing complex software.

And yet for some reason you think that other people who have bothered to acquire the necessary skills should do the work for you, without being paid.

Where do you get off on expecting to get stuff you want for free?

With free software, the answer to your problem is "Go and pay somebody to fix it for you". That wouldn't be difficult, there are loads of people who will do this kind of work and it won't cost very much for simple bugs.

With proprietary software, the answer to your problem is usually "It is not economically viable for us to fix this bug. Put up with it." - and even if the vendor is willing to fix the bug, it's probably going to cost you a lot more money.

The point of free software is not that people do stuff you want for free. It's that the stuff you want is actually possible (maybe at some cost), where with proprietary software there is a good chance that the stuff you want is not possible.

Of course, like most grad student blowhards, you have zero comprehension of any of this.

Re:Choose strong obscure passwords

[Syberghost]

Those of you who have been doing the online thing a long time might recall an old BBS door game called "Time of Chaos [wwiv.com]". In that game, you could have a base with a passcode for the door, but opponents could buy a piece of gear that allowed them to make an attempt to crack your passcode.

The game would show the passcode as a series of periods ("."), replacing a random number of them with the actual codes. By using several of these devices, you could get several or all of the characters in the passcode by repeating the attempt.

A common defense was to use passcodes that consisted of periods, spaces, and alt-255, which on IBM-compatible systems of the time generated a character that looked onscreen like a space but wasn't.

This was especially effective if the attacker was on a system that couldn't easily generate the alt-255 character.