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."
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
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
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
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.
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.
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?
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.
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.
Well done, you just took out the ability for most daemons to write to their log files.