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:I believe this is a feature

[Anonymous Coward]

try sudo bash

Re:I believe this is a feature

[dtfinch]

The article title isn't entirely correct. There is no root password. But you can set one.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Colin Watson's response was very professional

[zippity8]

He patched it within hours today, and posted to osnews with a description of what happened. He also posted a copy on the ubuntu forums [ubuntuforums.org] page including details of what happened. It affects clean installs of breezy, and dapper upgrades from a breezy install, but not hoary or a clean dapper. hoary = 5.04 breezy = 5.10 dapper = not officially released yet

Re:I believe this is a feature

[killeena]

But you can get the root password, as the default user has sudo access. 'sudo su -', and that is that.

Re:okay

[Aranth Brainfire]

Yeah, because it's approximately an equal effort to delete log files and to change anything about the WMF code, or whatever was causing that bug?

Re:Just in case

[Andrew Tanenbaum]

No, it has -no- root password by default. In Linux, you generally disable an account by removing its password.

The password in the log file was the primary account's password. This account is a member of the sudoers group, so the same password can get you root access.

Re:Just in case

[dtfinch]

If your /etc/shadow has something like "root:*:13039:0:99999:7:::", there's no root password.

Preview of 5.10 Not Affected

[InViViD]

I installed the beta of Breezy 5.10 and /var/log/installer/cdebconf/questions.dat *did not* contain my password. Looks like this only affected the final release.

For Ubuntu 5.10 users:

[dartarrow]

open var/log/installer/cdebconf/questions.dat, check at line 2140. Mine is there, individual results may vary

Solution

[itismike]

1. open a terminal and type:

   sudo apt-get update

2. wait for it to finish
3. click the Red update icon in the upper-right corner
4. click through the update
5. locate the file and verify that it is unreadable by a non-privileged user

Apple did patch the recent OS X holes

[I'm Don Giovanni]

Apple hasn't even acknowledged that the OSX privilege escalation exists, let alone patched it.

I agree with you regarding the different attitudes regarding this hole and the OS X holes. But I believe the recent OS X holes were indeed patched with Apple's March 2006 Security Update (though some websites are questioning whether the patches really fixed the underlying problems or merely placed band-aids on them).
http://docs.info.apple.com/article.html?artnum=303 382 [apple.com]

Re:Saw this on Digg

[xlsior]

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.

Re:Despite this little pasword issue...

[MichaelSmith]

Ubuntu is Debian made easy for the masses. You get the bullet-proof Debian core with a great, easy interface. Nothing touches this at the moment.

I run Ubuntu on my laptop and FC4 on my workstation. Ubuntu is great for office type stuff: word processing and email. A surprising number of printers work out of the box.

But I also want to use the laptop for development and here I have struck a few problems. Development libraries are not installed by default (fair enough) but I got into loops trying to install Motif development libraries thorugh apt. I tried to copmpile motif but hit significant dependency problems in the process.

In general I don't think Ubuntu is suited to development work. I am considering dual booting the laptop with another OS for that purpose. But I do continue to recommend it to non-technical people who need to reinstall their systems.

Re:What does patch help?

[prockcore]

What does this patch fix? The installer?

No, the patch removes that key from the file, and chmod's it 600.

Re:Saw this on Digg

[drsmithy]

However, Microsoft's patching cycles simply suck.

Actually they reflect reality and are the result of customer requests.

In managed environments, patches are almost never applied ad-hoc, as they are released. They are collected together then tested and rolled out on a schedule, usually monthly.

Agreed.

[jd]

If the password needs to be temporarily stored, there are plenty of ways to store a password that are secure and fast. Besides, since you'll only ever actually check the password against a hashed value, it would be more logical to store the hash if you want the speed.

For debugging purposes, you MAY want to print out entered values. However, you don't do this in the main log. For a start, if you're debugging, you don't want to have to search through tonnes of text. You want to find the error fast. You therefore output the "routine" log to one file and the "debug" log to a different file.

Doesn't this just go back to the same problem though? No. First, debug logs don't need to be written to quickly, because debug sessions are going to be slow anyway. Therefore you can encrypt them or otherwise make them unreadable to the casual observer. In general, you want these to be sent to the maintainer as part of a bug report in the event of an install failure, so just pre-encrypt them with the maintainer's public PGP/GPG key.

A more "correct" solution would be to assign different debug levels to different levels of logging, where your maximum level logs absolutely ALL data entered by the user, but where distributed versions are issued with much more basic logging that excludes private information that isn't likely to be useful in debugging the problem anyway.

(The ideal solution is to have maintenance debugging for logging everything as a distinct patch to the basic distribution, so the basic distribution cannot - even accidentally - log everything. That way, users don't even have to put up with obscenely inflated binaries that have lots of debug stuff that will likely never be used, and maintainers don't ever have brown-paper-bag security scares.)

Root Passwords should never be stored ANYWHERE...

[hvatum]

...in any form, even the hash!! Anything less is simply a huge security hole.

Re:UNIX mouse driver released

[Pogue Mahone]

Since when did UNIX have mice.

Since long before MS-DOS had them:

Look. [wikipedia.org].

Re:So what if this was fixed quickly.

[arrrrg]

In the forum, it was mentioned that there was in fact code in the installer to go back and remove the sensitive information from "questions.dat" after the installer finished. A bug was introduced somewhere in this code in the breezy release, so the password never got removed. So, the error was not nearly as obvious as fprintf (password) or even dump(questions); an attempt was made to do the right thing. Of course, the working condition of this code should definately have been verified before releasing breezy, but both the parent and grandparent make the developers seem more negligent than is actually the case.

Re:Solution

[itismike]

Wait, so the fix leaves the cleartext root password on the hard disk?

No, the patch both removes the PW from the log file and chmod's the log file itself to 600.

Not in my logs at all

[Philip K Dickhead]

less /etc/issue
Ubuntu 5.10 "Breezy Badger" \n \l

I upgraded from Warty - with dist-upgrade - maybe thats my deal... apt-get update && apt-get upgrade, anyway.

Re:What does patch help?

[identity0]

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

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?

I wish the Ubuntu people were a bit more proactive in their security, though.

Re:Solution

[mattyrobinson69]

i think it more likely does something along the lines of:

cat /var/log/logfile | sed -e 's/^Your Root Password Is.*$//g' > /tmp/a ; mv /tmp/a /var/log/logfile

Re:Saw this on Digg

[kasperd]

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
But occationally it gets the file labels fucked up causing things to stop working. The Fedora people refuse to acknowledge there is a bug, after all you can just touch /.autorelabel and reboot.

all the major services are compiled to randomize memory mappings, but the user is none-the-wiser.
If you had actually been using Fedora since FC1, and you happened to be using it on a 586 architecture, you would have found out. Because for some reason they decided that on that architecture they would compile glibc with some options making it pretty picky about the location of the stack. This caused programs to crash at random, and the bug was never fixed. They simply wouldn't accept, that there could be a bug in glibc.

I can install Fedora and be fairly certain that even if somehow my system stopped updating
Actually that is not so unlikely to happen. Because on FC4 rhn-applet will always tell you, that there are no updates available. And occationally yum will also say that even when there are updates available. And the Fedora people does not consider this to be a bug.

And while we are at it, do you know what happens to the umask on a Fedora system? If I decide to set my umask to 077 such that other users cannot read by default, then /etc/bashrc is going to change it to 002. That means anything started from a script using bash as interpreter is going to create files with other permissions than intended.

I'm not saying Fedora is a bad distribution, after all I do use it on all my systems. You just shouldn't claim it to be so much more secure than other distributions. Yes, this bug in Ubuntu is very bad, but unfortunately they are not the first to introduce a bug that bad.

Re:Saw this on Digg

[Canordis]

Security against an attack if you have physical, unsupervised access to the box is nil, in any case. Carry a pendrive or a bootable CD containing a rescue Linux distro with you and boot from it. There, you can mess around with system config files and do things like creating your very own SSH account on the machine. Due to the way PCs work, 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.

Re:[easier] Solution

[Filip22012005]

Isn't the password in your bash history now (twice)?

Re:So what if this was fixed quickly.

[masterzora]

It's just a fact: "the sky is blue", "water is wet", Ubuntu is insecure.

Let's check your facts...
"the sky is blue" -- Well, the sky is actually black and it only appears blue because light is scattered in the atmosphere. So far you're 0 for 1.
"water is wet" -- This one is true... if you only consider its liquid form. However, its solid and gaseous forms are most definitely not wet. That makes you 0 for 2.

With a record like that, can we really believe your third so-called "fact"?

Re:[easier] Solution

[tpgp]

Isn't the password in your bash history now (twice)?

Whoops! You are of course completely right...

Just goes to show that you can't be half-assed about password security :-)

Mod my [easier] solution into the ground mods!

  Open a terminal and type:

sudo grep -r mypasswd /var/log

(if it returns your password, you're vulnerable

sudo apt-get update
sudo passwd base-config

(wait)

sudo grep -r mypasswd /var/log

(if it doesn't return your password, you're no longer vulnerable)

The 'mypasswd' string grepped for above will immdiately preceed your primary user password

Re:So what if this was fixed quickly.

[masterzora]

A black sky is called a "night sky". Solid water is called "ice" and gaseous water is called "steam".

Let me guess: American, right? Only an American can be this bad at science.

A black sky is the way it is. Ever see that thing they call "space"? You'll see the sky is black. The aforementioned scattering of light in our atmostphere makes it look blue during the day, but the sky itself is black. Consult any primary school science class for further details.

Water is the name of a chemical compound, also known as Dihydrogen monoxide. The phase doesn't change what it is, it is still water, the same way liquid nitrogen is still nitrogen. If that doesn't satisfy you, there is solid water that is not ice. It is amorphous solid water. And gaseous water is also called water vapor. Notice how both of those specifically mention that they are water.

Thanks for trying. Get an primary school education before trying again.

Brilliant use of an irrelevant last line, by the way.

Re:Saw this on Digg

[Bretai]

Well, 50-50 on the responses to this, I think.

Firstly owning up and making changes:
"I'm the Ubuntu installer maintainer, so obviously this bug is ultimately my fault. I'm sorry for that - it's clear it shouldn't have sneaked past QA. (We'll be updating our testing processes to be rather more careful about this sort of thing.)" - Colin Watson

Second quote:
"We've never updated the ISO images for any released Ubuntu distributions. We don't intend to, either, unless some terrifying and unforeseen showstopper arises." -CJW

Terrifying showstopper?? You mean like this one?! This could affect their reputation for years. I'd destroy all CDs affected. It's one thing to screw up. It something different to knowingly mail that CD to another unsuspecting user.

Re:Solution

[Anonymous Coward]

Nah sorry... Try again later. The password we're talking about is not a root password. It's the password of a 'normal' user who happens to have full sudo access... I hate to break it on you, you seemed so happy :-)

Re:So what if this was fixed quickly.

[cjwatson]

For the record:

• The code mentioned that was supposed to clear out the password from the database wasn't "a script to fix it after the fact"; it was in the same bit of code that dealt with asking the password, and had it worked as intended the password would never have ended up in cleartext in any file on disk in the first place;
• A better solution was also in place (making sure that passwords were stored in a separate database never copied to disk) but this failed to work due to a subtle cdebconf bug [debian.org];
• The first user account is created after the base system is installed;
• I had a conversation with Joey Hess about this bug last night, and far from being scathing, he was somewhat relieved that Debian escaped this particular manifestation of the bug essentially by luck, and acknowledged responsibility for one of the original design decisions in base-config that meant we weren't as well-defended against this sort of error as we might have been.

I'm happy to take responsibility for the lack of testing that meant we didn't spot this earlier, but it's not quite the trivial stupid mistake that people are making it out to be.

Re:Choose strong obscure passwords

[ajs318]

But what if someone wants to use \0 in a string?

Re:Open Password!

[ComaVN]

Ah, the Novell eDirectory installer comes to mind... it just ignores (skips, without a warning) non-alphanumeric characters when setting passwords. Of course, the regular login prompt doesn't, so that's a lot of hair-pulling fun...

Re:[easier] Solution

[Anonymous Coward]

Use history -c to clear the bash history.

Or

set +o history

before typing sensitive info, then

set -o history

when finished. That way the history file isn't flushed, just the relevant entries.

Re:Solution

[swillden]

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... having a password you don't know about is worse than having a password only you know.

No. The default Ubuntu install sets *no* root password. None. Not "one you don't know".

As others mentioned, the password under discussion here is a user account password (for an account with full sudo privileges, so it's effectively root).

Re:Open Password!

[Asic Eng]

But my root password really is ********. I mean really, who the hell is going to guess that?

Dunno - presumably it's long been in any password cracker out there? Along with "none" or "password" or any other "clever" password there is?

Re:Patch mirror

[cortana]

Well done, you just took out the ability for most daemons to write to their log files.

Re:Choose strong obscure passwords

[chris macura]

Gee, I dunno.

Oh yeah!

typedef struct {
      unsigned int len;
      char *content;
} String;

Re:Choose strong obscure passwords

[sqlrob]

Oh yeah, what possible header could include those updates?

How about
#include <string> ? Radical, I know, but you have to put strings that contain their length and can contain nul somewhere!

Re:Choose strong obscure passwords

[paulatz]

I remember when I had the bad idea of using such a password at the college. When they changed the keyboards from USA to italian layout I could not login for days.

Re:[easier] Solution

[fimbulvetr]

'sudo passwd' doesn't change root's password - the sudo does nothing in this case. It will still change yours.

If you wish to change root's pass, you need to 'sudo passwd root' or 'sudo su -;passwd'

Re:Real Solution: CHANGE YOUR PASSWORD

[Barrakketh]

Among other things, the patch should change the permissions of questions.dat to 700. Previously it was 644.

Additionally, this should only happen if you're performing an expert install; the normal installation procedure doesn't seem to have this problem.

The installer maintainer (Colin Watson) has said two things that may (or may not) be of interest:

I don't see how this is happening, because we deliberately db_set those questions to empty after retrieving the password to avoid this problem.

So I guess that didn't work on some install types. The other, which addresses your question about Breezy install CDs:

I've already put that on the agenda for discussion at the next technical board meeting. It'll take until then to come up with a really correct fix that would be suitable for fresh Breezy installer images (as opposed to the security patches which merely undo the damage after it's been caused) anyway.

Re:[easier] Solution

[Zwaxy]

"sudo passwd" changes root's password in ubuntu 5.04 and 5.10.

Where does this idea that you need to type "sudo passwd root" come from? I see it repeated in IRC channels and message boards, but it's just not true.

Re:Real Solution: CHANGE YOUR PASSWORD

[An Onerous Coward]

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

I've been +5 wrong a few times. It's always a bit embarrassing. Stupid moderators. :)

The fix does indeed fix the problem file. I applied it this morning, and afterwards the file in question (/var/log/debian-installer/cdebconf/questions.dat) is no longer readable by anyone but root, and no longer contains the offending passwords.

Re:Saw this on Digg

[BluenoseJake]

Let me the first to say...ME

Re:Place it in context of surroundings

[Kagami001]

Read what he said again: "network access to the machine"

He means remote access, like Remote Desktop/Terminal Services, or shared file access (if simple file sharing is turned off; the concept doesn't apply if it's on, since everybody authenticates as guest anyway in that case), VPN server access (when XP itself is acting as a VPN server), remote registry access, remote process control, etc. etc., as well as the RunAs command to run software under a different account than the currently logged on desktop. None of these are possible with a blank password on the target account.