Administrator root password readable in cleartext on Breezy

[karl]

The root password from the first user registred by Breezy can be found by any user by reading the file /var/log/installer/cdebconf/questions.dat

a quick

grep -r rootpassword /var

shows that the rootpassword is forgotten in cleartext by the installer on several occations

/var/log/installer/cdebconf/questions.dat:Value: mypasswd
/var/log/installer/cdebconf/questions.dat:Value: mypasswd
/var/log/debian-installer/cdebconf/questions.dat:Value: mypasswd
/var/log/debian-installer/cdebconf/questions.dat:Value: mypasswd

Karl Øie

[karl (karloie)]

i have done basic install of ubuntu breezy 5.10 and then installed kubuntu-desktop and nvidia drivers, nothing modified

[Dennis Kaarsemaker (dennis)]

This is no longer the case in dapper

[Barrakketh (barrakketh)]

I can confirm this on Kubuntu Breezy.

What I will say is that this isn't the 'root' password that is in cleartext, but the user name/password that you created at install. After all, the root account is locked by default even though the user password will still let you get root privs with sudo.

Name: passwd/title
Template: passwd/title

Name: passwd/user-fullname
Template: passwd/user-fullname
Value: mfogtman

Name: passwd/user-password
Template: passwd/user-password
Value: <mypasswashere>

Name: passwd/user-password-again
Template: passwd/user-password-again
Value: <mypasswashere>

Name: passwd/username
Template: passwd/username
Value: mfogtman

[karl (karloie)]

this is quite serious since the default user is granted sudo rights, all i need to do is tu use this password to do a "sudo su-", then change the rootpassword to whatever i want and own the computer

[karl (karloie)]

even worse, this file might be left over in the the filesystem on people that upgrades from breezy 5.10, so saying its fixed in dapper is not a solution

people must be warned and adviced to delete these files asap

[X (u78qir8a9-deactivatedaccount)]

We need a security update that removes/patches this file.

This brings on a huge security problem that even a moderately knowledgeable admin can run into if the admin installs a ssh-server.

[OffHand (offhand303)]

I can confirm this bug. My password is also stored in plain text/readable.

[jeremyh (jeremy-jeremyh)]

I have checked this on two Breezy installs, one is a normal install and the other is a server install, both have this bug.

[X (u78qir8a9-deactivatedaccount)]

I failed to do this above, but here is a "formal" confirmation from me.

I can confirm this issue on my install, a new breezy install on ppc
all the directories in the path /var/log/installer/cdebconf are all chmod 755 owned root:root
The file questions.dat is chmod 644 owned root:root

[Colin Watson (cjwatson)]

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. Nevertheless, I'll investigate at the earliest opportunity, and probably release a base-config update that gets rid of those fields.

[karl (karloie)]

please include in the fix a command that removes the /var/log/installer/cdebconf/questions.dat and /var/log/debian-installer/cdebconf/questions.dat files from old affected systems

[Colin Watson (cjwatson)]

That's what I just said! :-)

[karl (karloie)]

oh, sorry, just a bit excited here, im part of an actual bughunt!

[philips (brandon-ifup)]

This might be a help to those on a bug hunt:

I checked a computer running Breezy that was installed from a Beta release and it didn't seem to have the password. Possibly a regression between the betas and release?

[Hans van Kranenburg (knorrie)]

When a machine is installed with expert-mode, no password shows up in the logs.

From a Breezy machine with default install:

Name: passwd/user-password
Template: passwd/user-password
Value: myuserpasswd

Name: passwd/user-password-again
Template: passwd/user-password-again
Value: myuserpasswd

From a Breezy machine with expert install:

Name: passwd/md5
Template: passwd/md5

Name: passwd/password-empty
Template: passwd/password-empty

Name: passwd/password-mismatch
Template: passwd/password-mismatch

Name: passwd/root-password-crypted
Template: passwd/root-password-crypted

Name: passwd/root-password-empty
Template: passwd/root-password-empty

Name: passwd/shadow
Template: passwd/shadow
Value: true

Name: passwd/title
Template: passwd/title

[Ken Minardo (kminardo)]

I will also confirm status of this on Kubuntu 5.10

Just a small bug >.<

Right now I'm just going to chmod 700 the files until we get a patch for his.

[Ubuntu User (idleubuntuuser)]

I confirm this also, but if the user changes password through KDE change password GUI, it will not appear in this file again. So solution is change password or modify this file, asap. I agree with above poster, this is a critical bug and needs a fix straight away.

[Rob Shepherd (rob-robshepherd)]

/var/log/debian-installer is a symlink to /var/log/installer

[Colin Watson (cjwatson)]

Security updates are heading in the direction of breezy-security and dapper right now.

[Nogimics (nogimics-deactivatedaccount)]

Confirmed here too :(

[Yuki Izumi (kivikakk)]

Confirmed on about five machines more. I'm sure this is enough confirmation..

[Colin Watson (cjwatson)]

We don't need multiple Ubuntu tasks for this bug; the shadow one will do, since that's where the bulk of the bug fix resides, and where at least part of the bug was caused in the first place.

And yes, more confirmation of this bug isn't needed now that I (installer maintainer) have confirmed it myself and uploaded security patches, but thanks all the same. :-)

[Alexandre Patenaude (alexandrep)]

I had formated my PC and had installed a daily version of Dapper from the begining of March (can't remember the exact date, though). I'd like to say that the information concerning the user created during the installation is still there in the files! So it is not solved in Dapper, unlike Dennis said. Or maybe I'm just weird or anything...

In /var/log/installer/cdebconf, lines 2133-2147

Name: passwd/user-fullname
Template: passwd/user-fullname
Value: [my name]

Name: passwd/user-password
Template: passwd/user-password
Value: [my password]

Name: passwd/user-password-again
Template: passwd/user-password-again
Value: [my password]

Name: passwd/username
Template: passwd/username
Value: [my username]

(and /var/log/debian-installer that is a symlink to /var/log/installer)

[MB (mangoblues)]

Wow... this security bug was fixed within a few hours, we are about 12:00 Sunday evening; or should I say 00:00 Monday morning ?

This is serious stuff. Thank you Colin, you are brilliant !

[Emil Oppeln-Bronikowski (opi)]

Intresting. My server was dist-upgraded from Hoary (IIRC) and it lacks this entries. Or maybe I've installed it with Expert mode? I'll check other machine. My Breezy-now-update-to-Dapper machine's clean, too.

[towsonu2003 (towsonu2003)]

@Colin Watson: I confirm that no _updates_ solved this problem. I had to delete the file myself after installing _all_ the updates 1 *minute* ago. Pls digg deeper.

@Alexandre P. Can anyone using Dapper confirm this? A forum post to Dapper Development section might attract attention? This is already *digg*ed.

damn...

[Colin Watson (cjwatson)]

On Sun, Mar 12, 2006 at 11:57:08PM -0000, towsonu2003 wrote:
> @Colin Watson: I confirm that no _updates_ solved this problem. I had to
> delete the file myself after installing _all_ the updates 1 *minute*
> ago. Pls digg deeper.

I have uploaded the source packages, but they are still in the process
of being built. I expect updated binary packages to be available within
the next couple of hours.

[Colin Watson (cjwatson)]

On Mon, Mar 13, 2006 at 12:06:07AM +0000, Colin Watson wrote:
> I have uploaded the source packages, but they are still in the process
> of being built. I expect updated binary packages to be available within
> the next couple of hours.

To update you on that, amd64, i386, and sparc binaries for dapper will
be available in about fifteen minutes; ia64 in about an hour and fifteen
minutes; and the powerpc build is stuck behind a gcj-4.0 upload, but it
shouldn't take too much longer.

[xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob)]

I didn't notice the password being revealed on my own laptop, but all my lab machines were exposed. Confirmed on 22+ machines. Hopefully the patch will fix this. Nice work guys ;-)
--
Kristian Hermansen

[David Symons (bimberi)]

Just a note that /var/log/debian-installer/ is a symlink to /var/log/installer/ so it there is only the one file to remove (or chmod).

[Martin Pitt (pitti)]

Breezy fixed in http://www.ubuntu.com/usn/usn-262-1

[Norbert Kiesel (nk-iname)]

I just upgraded a 5.10 installation for this. I did remove the file once I read about the problem usinf "shred -u", so I can't confirm that it works. However, I saw that the fix was added to /usr/sbin/base-config itself and not to the postinst of base-config. Is base-config really run during an upgrade? Or will this fix only take effect after the next reboot?

Also, the priority in the changelog is "low". Should that not be "critical" (or at least "high")?

Finally: is there any downside if I just remove (or better shred) that file?

[Colin Watson (cjwatson)]

On Mon, Mar 13, 2006 at 01:03:23AM -0000, Norbert Kiesel wrote:
> I just upgraded a 5.10 installation for this. I did remove the file
> once I read about the problem usinf "shred -u", so I can't confirm that
> it works. However, I saw that the fix was added to /usr/sbin/base-
> config itself and not to the postinst of base-config. Is base-config
> really run during an upgrade? Or will this fix only take effect after
> the next reboot?

No, the base-config fix was only to deal with new installations from
customised CD images built from breezy + breezy-security. The fix for
upgraders is in the passwd package.

> Also, the priority in the changelog is "low". Should that not be
> "critical" (or at least "high")?

Yeah, but I forgot in among everything else I was trying to do. It
doesn't actually make much difference in practice.

> Finally: is there any downside if I just remove (or better shred) that
> file?

(There's no huge virtue in shredding the file, since it only makes a
difference to somebody with physical disk access anyway.)

The only downside is that the log will no longer be available to help
triage installer bugs. If you didn't encounter any other installer bugs,
removing it is safe enough.

[xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob)]

Exploit Code to test your own vulnerable system:
http://www.ubuntuforums.org/showpost.php?p=818304&postcount=74
--
Kristian Hermansen

[Rohan Dhruva (rohandhruva)]

How about a new iso with this fix and other updates ? Imo, this fix is serious enough to issue a r1. Ofcourse not through shipit, but atleast for new users who install breezy ?

[Colin Watson (cjwatson)]

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.

[Zoltan (zoltans)]

Hi Guys,
I just need to say that I only do "expert" installs and *both* the root password and the user password created at install time *are* in the log file.

So all those feeling relieved that they did a "expert" install, shouldn't be :-)

Cheers & well spotted Karl.

[LatexBURP (latexburqa)]

I'm also using expert installs, and I have around 30 machines with "the Problem".

[Colin Watson (cjwatson)]

So, here's the set of stuff that I've released so far for this bug.

Breezy security updates:

shadow (1:4.0.3-37ubuntu8) breezy-security; urgency=low

  * Tidy up after Malone bug #34606, which left passwords exposed in
    /var/log/installer/cdebconf/questions.dat, by removing those passwords;
    for good measure, make /var/log/installer/cdebconf/* world-unreadable if
    this bug is detected.

 -- Colin Watson <email address hidden> Sun, 12 Mar 2006 21:43:40 +0000

base-config (2.67ubuntu20) breezy-security; urgency=low

  * Tidy up after Malone bug #34606, which left passwords exposed in
    /var/log/installer/cdebconf/questions.dat, by removing those passwords
    when base-config runs; for good measure, make
    /var/log/installer/cdebconf/* world-unreadable if this bug is detected.

 -- Colin Watson <email address hidden> Sun, 12 Mar 2006 22:28:05 +0000

shadow deals with upgraders, and base-config deals with people doing fresh installs from CD images they've built themselves from breezy + breezy-security (which is more of a corner case, but it won't be obvious to most people why the shadow fix can't cover fresh installs).

Dapper:

shadow (1:4.0.13-7ubuntu2) dapper; urgency=low

  * Tidy up after Malone bug #34606, which left passwords exposed in
    /var/log/installer/cdebconf/questions.dat, by removing those passwords;
    for good measure, make /var/log/installer/cdebconf/* world-unreadable if
    this bug is detected.

 -- Colin Watson <email address hidden> Sun, 12 Mar 2006 22:45:32 +0000

This mirrors the breezy-security change. There's no base-config change because base-config is no longer used in Dapper, and since this bug only manifests in some very strange circumstances in Dapper it's not necessary to do that kind of post-install cleanup there.

cdebconf (0.97ubuntu2) dapper; urgency=low

  * Backport from trunk:
    - Honour accept_types/reject_types for questions registered against
      templates that were received in DATA commands over passthrough. This
      was one of the root causes of Ubuntu's recent installer password
      disclosure vulnerability (CVE-2006-1183).

 -- Colin Watson <email address hidden> Mon, 13 Mar 2006 02:08:16 +0000

This fixes one of the two fundamental issues that caused this bug. (The other was in initial-passwd-udeb, which Dapper no longer uses, which is part of the reason it largely doesn't suffer from this.)

cdebconf (0.97ubuntu3) dapper; urgency=low

  * Backport from trunk:
    - Reset question template pointers whenever they change, not just when
      the tag changes; do this in X_LOADTEMPLATEFILE and dpkg-reconfigure as
      well as debconf-loadtemplate.
    - Add a remove method to the question database; use this to migrate
      questions to the correct stacked database in the event that their
      types change (fixes preseeded passwords ending up in questions.dat on
      the installed system in some cases).
  * Add CVE number to 0.97ubuntu2 changelog entry.

 -- Colin Watson <email address hidden> Mon, 13 Mar 2006 13:43:30 +0000

This fixes a more subtle issue, namely that preseeded installs of Dapper where the...

[qazwiz (qazwiz)]

I'm new to the linux nomenclature so pardon a dumb question.... but wouldn't just locking the logfile to root only access prevent the security problems?

if the default lockout of root could prevent the installer from accessing it there is it possible to tie it to the first user only(the only PW that gets logged is first user so ok for him to see)

I would think there should be some way to limit access to the logfile since it is only there IF something (else) goes wrong

As to the severity, I am not opposed to a low severity since EVERYONE should immediatly change EVERY first pasword on EVERY app, account and anything else you can think of. and this precaution seems to fix the problem. (my prefered first password list includes "changemenow")

[pirast (pirast)]

It is already fixed :-)

[towsonu2003 (towsonu2003)]

"Status" shows it as "in progress"? Someone's busy with dapper.. :P

[Colin Watson (cjwatson)]

On Tue, Mar 14, 2006 at 08:31:44PM -0000, qazwiz wrote:
> I'm new to the linux nomenclature so pardon a dumb question.... but
> wouldn't just locking the logfile to root only access prevent the
> security problems?

Yes, and we've already done that now; although I prefer to go further
and make sure the password isn't there at all. I'm just leaving this bug
open while we clean up all the pieces.

[John Vivirito (gnomefreak)]

i maked it as fix released due to the fix being released for a while now and neither breezy nor dapper have this issue anylonger.

[Colin Watson (cjwatson)]

I want this bug left at something other than fix-released until a breezy point release is made.

[Matt Zimmerman (mdz)]

I don't expect that we'll do a point release for Breezy, given that Dapper is out (and with its own first point release on the way). Any reason to keep this open?

[Jamie Strandboge (jdstrand)]

Does this still affect Nexenta? Baltix?

[Erast (erast)]

Not the case for Nexenta...

[Jamie Strandboge (jdstrand)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!