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

Comments

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

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

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