Slashdot Mirror
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."
try sudo bash
The article title isn't entirely correct. There is no root password. But you can set one.
Read the article. The Slashdot summary is incorrect; the password is for the account you create during installation, which has sudo rights and therefore is just as effective as a root account.
Karma: Terrifying (mostly affected by atrocities you've committed)
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 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
But you can get the root password, as the default user has sudo access. 'sudo su -', and that is that.
Freedom would be not to choose between black and white but to abjure such prescribed choices. -Theodor Adorno
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?
"Quoting yourself is stupid." -Me
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.
If your /etc/shadow has something like "root:*:13039:0:99999:7:::", there's no root password.
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.
open var/log/installer/cdebconf/questions.dat, check at line 2140. Mine is there, individual results may vary
I love humanity, it is people I hate
Apple hasn't even acknowledged that the OSX privilege escalation exists, let alone patched it.
3 382
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=30
-- "I never gave these stories much credence." - HAL 9000
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.
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.
http://michaelsmith.id.au
What does this patch fix? The installer?
No, the patch removes that key from the file, and chmod's it 600.
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.
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.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
...in any form, even the hash!! Anything less is simply a huge security hole.
Netbooks, they come with Linux or a $3 copy of Windows. Either way, Microsoft loses.
Since long before MS-DOS had them:
Look..
Every bloody emperor has his hand up history's skirt [Peter Hammill/VdGG]
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.
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.
"Speaking the Truth in times of universal deceit is a revolutionary act." -- George Orwell
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.
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 /.autorelabel and reboot.
/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.
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
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
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.
Do you care about the security of your wireless mouse?
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.
I have never made but one prayer to God, a very short one: "O Lord, make my enemies ridiculous." And God granted it.
Isn't the password in your bash history now (twice)?
When the policeman of the tie, rule you violate, hello punishment of the kitty?
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"?
Remember, open source is free as in speech, not free as in bear.
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:(if it returns your password, you're vulnerable (wait) (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
My pics.
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.
Remember, open source is free as in speech, not free as in bear.
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.
Controlling complexity is the essence of computer programming. -Brian Kernigan
For the record:
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.
But what if someone wants to use \0 in a string?
Je fume. Tu fumes. Nous fûmes!
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...
Be wary of any facts that confirm your opinion.
Or before typing sensitive info, then when finished. That way the history file isn't flushed, just the relevant entries.
Dunno - presumably it's long been in any password cracker out there? Along with "none" or "password" or any other "clever" password there is?
Well done, you just took out the ability for most daemons to write to their log files.
Gee, I dunno.
Oh yeah!
typedef struct {
unsigned int len;
char *content;
} String;
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!
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.
this post contain no useful information, no need to mod it down
'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'
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.
"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.
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
You want the truthiness? You can't handle the truthiness!
Let me the first to say...ME
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.