Administrator root password readable in cleartext on Breezy
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Baltix |
Medium
|
Mantas Kriaučiūnas | ||
| Nexenta Operating System |
Fix Released
|
Undecided
|
Unassigned | |
| Ubuntu |
Critical
|
Unassigned | ||
| shadow (Ubuntu) |
Critical
|
Colin Watson |
Bug Description
The root password from the first user registred by Breezy can be found by any user by reading the file /var/log/
a quick
grep -r rootpassword /var
shows that the rootpassword is forgotten in cleartext by the installer on several occations
/var/log/
/var/log/
/var/log/
/var/log/
Karl Øie
karl (karloie) wrote : | #1 |
Dennis Kaarsemaker (dennis) wrote : | #2 |
This is no longer the case in dapper
Barrakketh (barrakketh) wrote : | #3 |
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/
Template: passwd/
Value: mfogtman
Name: passwd/
Template: passwd/
Value: <mypasswashere>
Name: passwd/
Template: passwd/
Value: <mypasswashere>
Name: passwd/username
Template: passwd/username
Value: mfogtman
karl (karloie) wrote : | #4 |
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) wrote : | #5 |
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) wrote : | #6 |
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) wrote : | #7 |
I can confirm this bug. My password is also stored in plain text/readable.
jeremyh (jeremy-jeremyh) wrote : | #8 |
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) wrote : | #9 |
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/
The file questions.dat is chmod 644 owned root:root
Colin Watson (cjwatson) wrote : | #10 |
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) wrote : | #11 |
please include in the fix a command that removes the /var/log/
Colin Watson (cjwatson) wrote : | #12 |
That's what I just said! :-)
karl (karloie) wrote : | #13 |
oh, sorry, just a bit excited here, im part of an actual bughunt!
philips (brandon-ifup) wrote : | #14 |
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) wrote : | #15 |
When a machine is installed with expert-mode, no password shows up in the logs.
From a Breezy machine with default install:
Name: passwd/
Template: passwd/
Value: myuserpasswd
Name: passwd/
Template: passwd/
Value: myuserpasswd
From a Breezy machine with expert install:
Name: passwd/md5
Template: passwd/md5
Name: passwd/
Template: passwd/
Name: passwd/
Template: passwd/
Name: passwd/
Template: passwd/
Name: passwd/
Template: passwd/
Name: passwd/shadow
Template: passwd/shadow
Value: true
Name: passwd/title
Template: passwd/title
Ken Minardo (kminardo) wrote : | #16 |
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) wrote : | #17 |
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) wrote : | #18 |
/var/log/
Colin Watson (cjwatson) wrote : | #19 |
Security updates are heading in the direction of breezy-security and dapper right now.
Confirmed here too :(
Yuki Izumi (kivikakk) wrote : | #21 |
Confirmed on about five machines more. I'm sure this is enough confirmation..
Colin Watson (cjwatson) wrote : | #22 |
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) wrote : | #23 |
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/
Name: passwd/
Template: passwd/
Value: [my name]
Name: passwd/
Template: passwd/
Value: [my password]
Name: passwd/
Template: passwd/
Value: [my password]
Name: passwd/username
Template: passwd/username
Value: [my username]
(and /var/log/
MB (mangoblues) wrote : | #24 |
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) wrote : | #25 |
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-
towsonu2003 (towsonu2003) wrote : | #26 |
@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) wrote : Re: [Bug 34606] Administrator root password readable in cleartext on Breezy | #27 |
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) wrote : | #28 |
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.
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) wrote : | #30 |
Just a note that /var/log/
Martin Pitt (pitti) wrote : | #31 |
Breezy fixed in http://
Norbert Kiesel (nk-iname) wrote : | #32 |
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/
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) wrote : | #33 |
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.
Exploit Code to test your own vulnerable system:
http://
--
Kristian Hermansen
Rohan Dhruva (rohandhruva) wrote : | #35 |
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) wrote : | #36 |
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) wrote : | #37 |
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) wrote : | #38 |
I'm also using expert installs, and I have around 30 machines with "the Problem".
Colin Watson (cjwatson) wrote : | #39 |
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/
for good measure, make /var/log/
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/
when base-config runs; for good measure, make
/var/
-- 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/
for good measure, make /var/log/
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_
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-
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-
- 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...
Changed in shadow: | |
status: | Confirmed → In Progress |
qazwiz (qazwiz) wrote : | #40 |
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")
magilus (magilus) wrote : | #41 |
It is already fixed :-)
towsonu2003 (towsonu2003) wrote : | #42 |
"Status" shows it as "in progress"? Someone's busy with dapper.. :P
Colin Watson (cjwatson) wrote : | #43 |
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) wrote : | #44 |
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.
Changed in shadow: | |
status: | In Progress → Fix Released |
Colin Watson (cjwatson) wrote : | #45 |
I want this bug left at something other than fix-released until a breezy point release is made.
Changed in shadow: | |
status: | Fix Released → Fix Committed |
Matt Zimmerman (mdz) wrote : | #46 |
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?
Changed in shadow: | |
status: | Fix Committed → Fix Released |
Jamie Strandboge (jdstrand) wrote : | #47 |
Does this still affect Nexenta? Baltix?
Erast (erast) wrote : | #48 |
Not the case for Nexenta...
Jamie Strandboge (jdstrand) wrote : | #49 |
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!
i have done basic install of ubuntu breezy 5.10 and then installed kubuntu-desktop and nvidia drivers, nothing modified