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."
no need to give them local access to your system, they can easily read it if you have an ssh server set up for example. And no it doesn't display the root password, but it displays a username/password combination which has access to sudo. So just as bad.
being vague is almost as cool as doing that other thing...
I actually used ***** as a backdoor password for a system I once worked on. Really! The service department demanded a backdoor password to give the service people, so that they wouldn't be calling in all the time for passwords. I fought and fought, but the lure of a continuing paycheck was too much, so I finally relented. My second choice was eight spaces.
Don't blame me, I didn't vote for either of them!
"It came out, it was fixed. There are going to be problems in any project this large, but it shows how much the Ubuntu team cares to respond to a problem this quickly and on a Sunday of all days. Ubuntu really has become a nice distro. It's completely free and polished around the edges. I hope they continue to do well."
I know this rationale gives everybody the warm fuzzies, but this is still a really bone-headed mistake. You guys really shouldn't be this forgiving about it.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Nevertheless, AC is right. If it was relvealed that the local Administrator account or the domain Administrator account was stored anywhere as plain text in Windows 2000, XP, or 2003, then MS would be reamed endlessly and very harshly here.
i n/MS00-035.mspx
Interestingly enough Microsoft did make pretty much the same mistake, with Microsoft SQL 7, both servicepack 1 & 2. They wrote the SQL administrator password to the installation log file, which would give you full access to any SQL database on the server. Written to a logfile in the TEMP folder, which by default has full read/write access for any user on the system.
Security bulletin: https://www.microsoft.com/technet/security/bullet
(The 'non-recommended' mode mentioned is using SQL authentication instead of windows NTLM authentication, which much more common then they try to make it sound)
Many people know how to generate these special characters but I'll mention anyway: using the ALT/META key and the NUMPAD keys. Having a character map printout handy so you know the DEC (decimal) values of these special characters is a good idea if you decide to implement one of these passwords. Punch in ALT-DecimalValue with number lock on.
They may not work in some situations if special characters and not allowed, but you'd be surprised that they do work most often.
I bet most dictionary attacks don't run through many special characters. The cracker is lazy too and will probably not even consider that you chose a funny character which does not even exist on the keyboard.
Remember not to use NULL (#0) though, for crying out loud.
The netatalk package, which provides Appletalk services (most commonly used servies are AFP, ie filesharing, and papd, the printing spooler), isn't compiled in with ANY encrypted password support. If you connect to a debian or debian-based appletalk fileserver, you get a warning you are transmitting your password in clear-text. Yes, we're jumping about 10 years BACKWARDS in security.
Why? Because the legal-circle-jerk that is the debian-legal mailing list, decided that it wasn't "legal" to link netatalk (a GPL project) to OpenSSL (license supposedly incompatible with GPL.) This doesn't stop every other distribution on the planet from compiling netatalk with openssl, and hence supporting encrypted passwords.
They politely suggested that GnuTLS, which isn't even remotely drop-in, be used instead. That was back in 2002...and the issue still hasn't been addressed. I filed a bug on it and the bug was simply ignored.
Please help metamoderate.
I assume that the OpenBSD installer runs passwd to set the root password during installation, similar to NetBSD.
But if either of these OS's went to a graphical installer they would need to write a graphical passwd command which makes an effort to keep the plain text out of swap files, insecure memory, etc.
That's a big ask, IMHO. Which doesn't mean its ok to print the thing out, just that doing it properly is very hard.
But in this day and age of development frameworks, etc, there is less of a need for a programmer to think about the meaning of what he is reading from the UI. The backend programmer may assume that the UI guy understands about passwords, but he may not, to.
http://michaelsmith.id.au
I didn't find the password in my installer logs. It seems that if you install in expert mode you're OK. See the bug report here:
https://launchpad.net/distros/ubuntu/+bug/34606
You should've made the password something with a tab in it...(works on some login methods, but not others).
Max.
You can't be root in Ubuntu; you have to consciously make the decision to run software as root by typing 'sudo' before it. (Actually you can run a shell under sudo, but still.) The idea was that since you can't login as root, the system is more secure and resists exploits that try to gain root access. This vulnerability is the kind of stupid mistake people make sometimes.
There is another stupid vulnerability I noticed in Ubuntu, which relates directly to the missing root password: If something goes wrong during system startup (e.g. a failed fsck), usually you are prompted for the root password to open the rescue console and fix the issue. Not so with Ubuntu: Since there is not root password, you will be thrown into a root shell without any hesitation. Kind of strange, is it? One could argue that once you have physical access to the system, you have a lot of possibilities to circumvent the system's security, but I found this issue to be rather harsh.
Life is just nature's way of keeping meat fresh.
When XP (as of SP2) doesn't have a password on an account it doesn't allow network access to the machine with that user, so a blank admin password after setup can be more secure than a simple password.
I actually picked up the 5.10 disks last week, and was thinking of installing it... glad I didn't.
/var/log/installer/cdebconf/questions.dat to remove the password. Or delete the file; I'm pretty sure it's only there in case you want a record of your install, so unless you get a kick out of reviewing your installation process, just rm the damn thing.
You think that--within one week of installing--someone who already has a valid login to your machine would have 0wned your box using this security hole? What, was it a server or something?
If it was just your desktop machine, then yeah, this is crappy, but it's hardly a disaster, and the odds are pretty good that not even one person running Ubuntu on a simple desktop machine was harmed by this at all.
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?
Er, or you could just edit line 2140 (IIRC) of
The design of the installer is naturally at fault. The way it works currently is it stores the answers to a bunch of questions asked during install, and then feeds them into the install system. If the answers list was simply a log, the easy fix would have happened ages ago: simply don't output the password to the file. Clearly the system is using that to send to the create first user script. That script is supposed to remove that entry, but it appears to have temporarily broken. I gather its generally useful for repeated installs, but storing plaintext passwords in a file is still a bad idea, reguardless of how easy it is to access it. I suspect the guys responsible for the installer will be able to provide a better discussion of what went wrong, how to fix it, and how to test for similar errors in the future. Theoretically, you shouldn't have any storage on disk for it, even for the duration of an install. But realistically, the window during which you could convievably attack this temporary storage is very miniscule. The answers list is pretty long and deleting a line from it wouldn't likely result in data getting duplicated on disk. Maybe with a full journaled FS, but I'm not sure on that one. Still, I'd much rather see a fix more along the lines you've described above.
The bigger scare factor here is that the Ubuntu repos are presumably running Ubuntu. You can moan on about md5 security and RSA signatures, but when the private keys are readable all bets are off. Let's hope they run netBSD.
I should point out that while I am using breezy, I don't have this problem in my install log and neither did anyone else I know using Ubuntu. Probably because I installed it long long ago, before this particular vuln existed. Additionally, I've read it doesn't happen in dapper, the next version in testing. Oh, and calling Ubuntu's installer "graphical" would be far too generous.
I Browse at +4 Flamebait
Open Source Sysadmin
True, it's also worth bearing in mind that the server install of Ubuntu 5.10 doesn't suffer from this vulnerability.
// MD_Update(&m,buf,j);
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.
Encrypting the hard drive is an answer, but then you have the problem of where do you store the key to access it? If it's stored in the bootloader or the kernel then that can be extracted by the attacker if they have physical access to the system. This is basically the same as the DRM problem - you can encrypt the content but you always have to decrypt it to use it so you need the key stored somewhere and that is always a possible attack vector.
Also, you need to think very carefully about the ramifications of encrypting data - if you lose the key you're screwed.
Encrypting the hard drive using keys stored in Palladium is an option but it only protects you from someone removing the drive and installing it in another machine, and again - if you motherboard (with it's Palladium chip) blows up you're buggered.
http://blog.nexusuk.org