Root Password Readable in Clear Text with Ubuntu

Open source by L505 · 2006-03-12 17:38 · Score: 5, Funny

What's the problem? Open source passwords make it more secure.

Re:Open source by themoodykid · 2006-03-12 18:23 · Score: 3, Funny

Yes, exactly. If someone screws up your system, somebody else will come along and fix it for you. The many eyes make all bugs shallow or something. Think of it as a Wiki-style OS security.

Saw this on Digg by Stevyn · 2006-03-12 17:38 · Score: 3, Insightful

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.

Re:Saw this on Digg by Anonymous Coward · 2006-03-12 17:42 · Score: 5, Insightful

Oh PLEASE, what a joke of a comment. The fact is, they fucked up BIG TIME. Yeah, it's a nice distro, but so is windows, and had microsoft made this error you'd be on their ass about how crappy windows is.

The bias here on slashdot sometimes makes me sick.

Grow up people!
Re:Saw this on Digg by Parham · 2006-03-12 17:54 · Score: 4, Insightful

If Microsoft had made the error, we'd have to wait until the second Tuesday of the month for the fix. If this bug wasn't caught by tomorrow for me, then I'd have to wait an entire month for a fix. Ubuntu put out the patch as soon as it was discovered. There is no bias here, I use Windows just as much as Linux. However, Microsoft's patching cycles simply suck.
Re:Saw this on Digg by Bacon+Bits · 2006-03-12 18:01 · Score: 5, Insightful

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. Or do you honestly think people would be saying "oh, well, at least MS has a patch!" I'm no fan of Microsoft as a company, but denying that a bias exists on Slashdot about this kind of thing -- apologising for *nix, criticising Windows -- is just outright absurd.
Be honest. Everyone here knows that storing the root password as plain text is a clear program error. And since GNU/Linux is a rather secure OS that doesn't have this vulerability in any other distro, this code was added by the Ubuntu team. If this is the quality of code that the Ubuntu team is developing for it's distro, though, I do have to question why it is so popular. Why was such an obvious mistake missed? Who forgot to check how the root password is stored? Who forgets that kind of thing? Not the kind of developer I'd want to trust with my security, I'll tell you what.

--
The road to tyranny has always been paved with claims of necessity.
Re:Saw this on Digg by RzUpAnmsCwrds · 2006-03-12 18:08 · Score: 5, Insightful

If Microsoft had made the error, we'd have to wait until the second Tuesday of the month for the fix. If this bug wasn't caught by tomorrow for me, then I'd have to wait an entire month for a fix. Ubuntu put out the patch as soon as it was discovered. There is no bias here, I use Windows just as much as Linux. However, Microsoft's patching cycles simply suck.

Patching is quite frankly irrelivent with this bug. While it certainly has to be done to close the hole in the future, there are already hundreds of thousands of Ubuntu systems out there with the password sitting on the disk. How are you to be sure as an administrator that the password has not been compromised already? What about backup copies that might have the password?

The fix is to change the administrator/root password. The bug only affects a system at install-time, and it will continue to affect new installs so long as the broken installer is floating around. Patching it today is hardly more effective than patching it on April 6.
Re:Saw this on Digg by MobileTatsu-NJG · 2006-03-12 18:23 · Score: 4, Interesting

"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)
Re:Saw this on Digg by xlsior · 2006-03-12 18:25 · Score: 5, Interesting

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.

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/bulleti n/MS00-035.mspx

(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)
Re:Saw this on Digg by xlsior · 2006-03-12 18:30 · Score: 5, Informative

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.
Re:Saw this on Digg by drsmithy · 2006-03-12 18:44 · Score: 4, Informative

However, Microsoft's patching cycles simply suck.
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.
Re:Saw this on Digg by LnxAddct · 2006-03-12 19:28 · Score: 5, Insightful

Why the hell is everyone trying to downplay the severity of this? This is a serious issue, its worse than most security problems I've seen with *any* operating system, stop the hand waving, and spread the word instead. This *is* serious and shows poorly on the Ubuntu developers. I mean, how many people have set up linux for their parents or family, chosen Ubuntu and now they have to make sure they go in and change that. Updating won't always work (for reasons listed elsewhere), the only sure thing to do is to physically change it (if ssh access is enabled than its easier).

One of Ubuntu's big things is giving out free cd's, in particular targeted to people who don't know what linux is. Me and my roommates actually had a 100 or so Ubuntu CDs, most of which we've given away. We both run Fedora, it fits our needs as "powerusers" better, but give out Ubuntu simply out of convenience and to help the "cause". They are both nice distros, but security is definitely one area where Fedora surpasses all of the other distros.

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, all the major services are compiled to randomize memory mappings, but the user is none-the-wiser. That goes for advanced and beginning users. I can install Fedora and be fairly certain that even if somehow my system stopped updating, that any vulnerabilities found would be stopped by these additional measures anyway. The measures in place make most buffer overflows useless and even if you somehow got passed all of the measures to prevent overflows and you got root through an exploit in a vulnerable service (despite that the services don't run as root), SELiux would probably still make your entry pretty pointless.

The point I'm making is, the differece between a secure OS a non-secure OS are ones where even without updates, the security measures in place are foward looking and work to prevent current unknown attacks. Fedora has damn near perfected this, but if any of the users of the Ubuntu CDs I've given out somehow managed to disable updates, they are screwed now. There should never be a situation like that. Bravo on the response time, but seriously the users most likely to be affected don't read /. or digg and if they don't update then they are screwed more than they were before. I don't like knowing that a local user vulnerability will can give out root access
Regards,
Steve
Re:Saw this on Digg by Canordis · 2006-03-12 19:53 · Score: 5, Insightful

This is a consequence of Ubuntu's different security model. 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. A brain fart. Nothing really malicious, and not the sign of an incompetent programmer. Something you could've done.

Most Windows vulnerabilities are that, too. There's just more of them. And the system is inherently less secure, so it doesn't resist those quite as well. And it's harder to update because it's a monolithic kludge. Of course, some Windows vulnerabilities are just the product of poor design.

And another thing, if this happened, /. would bash Microsoft insanely. True. There is a bias. But still, I highly doubt the issue would be fixed in the same day, on a Sunday, and the update would be availiable quickly and painlessly.

--
I have never made but one prayer to God, a very short one: "O Lord, make my enemies ridiculous." And God granted it.
Re:Saw this on Digg by wertarbyte · 2006-03-12 20:05 · Score: 4, Interesting

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.
Re:Saw this on Digg by kasperd · 2006-03-12 20:17 · Score: 3, Informative

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
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 /.autorelabel and reboot.

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 /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.

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?
Re:Saw this on Digg by Canordis · 2006-03-12 20:17 · Score: 2, Informative

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.
Re:Saw this on Digg by mtenhagen · 2006-03-12 20:33 · Score: 2, Insightful

Just changing the root password is not enough, this 'bug' was here for months any could have installed a rootkit or did who knows what. This is going to be a fresh install for me.

And that fresh install will be gentoo. This is really embarrassing for Ubunutu. Iam just so happy my work servers all run solaris.

--
200GB/2TB $7.95 Coupon: SAVE90DOLLAR
Re:Saw this on Digg by Kwiik · 2006-03-12 21:16 · Score: 2, Insightful

This is MUCH more akin to something such as Dell (or any other vendor, picking on the biggie here) releasing an OEM version of their OS in which the administrator account's password is always the same, or something along these lines -- but wait, usually XP Pro doesn't have any admin passwords on OEM installations, it merely sits in the background, waiting for me to control+alt+delete twice at some home user's logon screen, and log in as administrator without a password. This has been an issue since XP Pro.. it isn't a problem with Microsoft, and it generally isn't even considered a problem. This is an issue with OEM's releasing Microsoft OS's. This issue isn't with Linux, it's with a Linux provider, and as such is completely irrelevant to the entire scenario (unless, of course, you are doing a Microsoft funded study of Windows VS Linux security)

--
Vehicle Stars used car search is my current project
Re:Saw this on Digg by Bretai · 2006-03-12 21:40 · Score: 2, Informative

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
Re:Saw this on Digg by FireFury03 · 2006-03-12 22:32 · Score: 3, Interesting

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
Re:Saw this on Digg by tolan-b · 2006-03-13 01:21 · Score: 2, Funny

While I wouldn't quite put it as trollfully as you have, I would agree with you that it wouldn't be my first choice for a server OS. That'd probably be Debian stable.
Re:Saw this on Digg by BluenoseJake · 2006-03-13 09:30 · Score: 2, Informative

Let me the first to say...ME

Time From Discovery to Patch by ergo98 · 2006-03-12 17:42 · Score: 5, Insightful

Invariably, a lot of the comments to this story are going to commend the team on the incredibly speed with which they've released a patch, and there'll probably be some comments comparing it to closed software. Yet another victory for the open source model!

Yet how long has this massive fault been sitting there waiting for the first person to discover it? How do we know that the public acknowledgement of it was the first actual discovery of it?

I believe Breezy was released in October, so for five months install logs have been sitting, world-readable, often with the root password. Surely in that time someone well less savoury motives did a simple grep of an install looking for the most trivial of faults.

Feeling confident in the speed of the patch relies upon the belief that no one with nefarious motives discovered it before a benevolent bug submitter did.

Re:Time From Discovery to Patch by MichaelSmith · 2006-03-12 17:53 · Score: 5, Insightful

I believe Breezy was released in October, so for five months install logs have been sitting, world-readable, often with the root password. Surely in that time someone well less savoury motives did a simple grep of an install looking for the most trivial of faults.
Anybody with an ounce of common sense should know that you never leave a critical password floating around in plain text. Not in memory, not in swap and you never print it to a bloody log file. Who's going to want to check it?

Passwords are supposed to be non-reversable. The NetBSD installer seems to run the passwd command directly during installation, so the installer never sees the password. Did somebody get the bright idea of prompting for the password in their own UI when the graphical installer was done? This should have been caught. The design of the installer is at fault. Not the log file. I wouldn't count this one as fixed until the installer never sees the password. Sorry for the rant.

--
http://michaelsmith.id.au
Re:Time From Discovery to Patch by xenocide2 · 2006-03-12 21:09 · Score: 2, Interesting

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

Re:I believe this is a feature by Anonymous Coward · 2006-03-12 17:43 · Score: 2, Informative

try sudo bash

Re:I believe this is a feature by dtfinch · 2006-03-12 17:43 · Score: 2, Informative

The article title isn't entirely correct. There is no root password. But you can set one.

Re:But Ubuntu has no root account! by Yosho · 2006-03-12 17:44 · Score: 5, Informative

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)

The cyberpunk credo comes to mind... by Anonymous Coward · 2006-03-12 17:44 · Score: 5, Funny

Information wants to be free

windows by Chimera512 · 2006-03-12 17:45 · Score: 3, Funny

see this is why i use windows. there are never security patches to install, just service packs which allow me to get new secutiry features like windows firewall. nothing beats windows security, and there's that helpful blue screen to tell me if something's gone wrong.

Awesome by ergo98 · 2006-03-12 17:46 · Score: 2, Insightful

30 seconds and my post got a flamebait. I love Slashdot.

Within the same 30 seconds a post appeared following mine comparing the fix (which has the massive complexity of deleting some log files) with Microsoft's WMF fix, exactly as predicted. Beautiful, and so predictable.

steenkin batchers by Anonymous Coward · 2006-03-12 17:46 · Score: 5, Funny

Fuuuuck.

I knew I never should have trusted those badgers.

Smiling at me with their big cartoon teeth, eating up all the aspen, wanting to admin their own machines.

I've been a sap, and it's going to cost me.

And now I'm worried about the hedgehogs.

Place it in context of surroundings by slashbob22 · 2006-03-12 17:47 · Score: 2, Insightful

This IS a very serious issue, however it does require some work (accessing log) to obtain root. In comparison to other operating systems which provide default root ("administrator") access, without a password, on installation; this isn't as big of a deal. On top of this, from my understanding, a change of the root password after installation would prevent further issues. Overall this seems to be a problem but certainly not a huge one.

--
Proof by very large bribes. QED.

Re:Place it in context of surroundings by damiam · 2006-03-12 18:34 · Score: 5, Insightful

In comparison to other operating systems which provide default root ("administrator") access, without a password, on installation; this isn't as big of a deal.
WTF are you smoking? No modern OS sets up an unpassworded root account by default, especially on a multiuser system. And if they did, there would be no expectation of security. Here, there is the expectation of security, and it is violated.
In fact, this attack is even worse than the average privilege escalation vulnerability, because a) it's amazingly stupid on the part of the programmer and b) the attacker gains not just root priveleges but the root password, which is often reused by less-paranoid users for other purposes.

--
It's hard to be religious when certain people are never incinerated by bolts of lightning.
Re:Place it in context of surroundings by Anonymous Coward · 2006-03-12 20:11 · Score: 2, Interesting

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.
Re:Place it in context of surroundings by Kagami001 · 2006-03-13 09:40 · Score: 2, Informative

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.

Re:okay by MichaelSmith · 2006-03-12 17:48 · Score: 3, Funny

A patch in 2 hours for a massive security hole in an OS, on a sunday as mentioned earlier.

Sunday is probably peak development time for free software.

--
http://michaelsmith.id.au

Colin Watson's response was very professional by zippity8 · 2006-03-12 17:48 · Score: 3, Informative

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

Re:I believe this is a feature by killeena · 2006-03-12 17:48 · Score: 2, Informative

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

So what if this was fixed quickly. by Anonymous Coward · 2006-03-12 17:48 · Score: 5, Insightful

Any programmer who doesn't stop themselves and think that writing something like fprintf(logfile, "root password entered is: %s\n", password); is not the best idea should not be writing code for a secure operating system.

Re:So what if this was fixed quickly. by strider44 · 2006-03-12 18:38 · Score: 3, Insightful

Come now, do you really think that somewhere in the code there's a manual fprintf writing the root password to the file? You could have at least made a simple attempt at reading the article to find out what it's about and what causes it.

The problem here is that the main user password (Ubuntu doesn't have a root password) is asked through the questions dialogue in the installer. Everything here is automatic and the questions dialogue just simply records everything down in a file called "questions.dat". It's a serious error for a programmer sure, but it's just a lack of thinking of everything when programming, which is what every single security hole is caused by, lets face it. You could just as easily say everyone who doesn't check their arrays every single time no matter what shouldn't be let within ten feet of gcc, but alas even the best make mistakes. Not only this, but someone who doesn't check every array may be letting through a remote exploit, which is much much more serious than this bug.

The mantra of course applies here: Unless you've programmed a totally secure operating system, keep your mouth shut.
Re:So what if this was fixed quickly. by arrrrg · 2006-03-12 19:11 · Score: 3, Informative

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.
Re:So what if this was fixed quickly. by DNS-and-BIND · 2006-03-12 19:34 · Score: 2, Insightful

In a real project, someone who made a greenhorn mistake like that would be fired. In Open Source, you just say "oopsie" and keep blundering forward.

--
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
Re:So what if this was fixed quickly. by masterzora · 2006-03-12 21:00 · Score: 2, Informative

It's just a fact: "the sky is blue", "water is wet", Ubuntu is insecure.
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.
Re:So what if this was fixed quickly. by LordLucless · 2006-03-12 21:17 · Score: 2, Insightful

I have. My homebrew OS doesn't even compile. No security problems there.

Joking aside, if you apply that little mantra of yours to other scenarios, you'll see how silly it is. How about "Don't criticise Gigli unless you've produced the perfect film"? How about "Don't criticise your plumber for not fixing your leak and flooding your basement until you've laid the perfect pipe"? How about "Don't criticise your goverment until you've ruled over the perfect society"?

You do not need to be an expert to see when an expert is doing a crap job of it.

--
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
Re:So what if this was fixed quickly. by masterzora · 2006-03-12 21:23 · Score: 2, Informative

A black sky is called a "night sky". Solid water is called "ice" and gaseous water is called "steam".
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.
Re:So what if this was fixed quickly. by cjwatson · 2006-03-12 21:53 · Score: 3, Informative
For the record:
- The code mentioned that was supposed to clear out the password from the database wasn't "a script to fix it after the fact"; it was in the same bit of code that dealt with asking the password, and had it worked as intended the password would never have ended up in cleartext in any file on disk in the first place;
- A better solution was also in place (making sure that passwords were stored in a separate database never copied to disk) but this failed to work due to a subtle cdebconf bug;
- The first user account is created after the base system is installed;
- I had a conversation with Joey Hess about this bug last night, and far from being scathing, he was somewhat relieved that Debian escaped this particular manifestation of the bug essentially by luck, and acknowledged responsibility for one of the original design decisions in base-config that meant we weren't as well-defended against this sort of error as we might have been.
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.

Open Password! by aurb · 2006-03-12 17:49 · Score: 5, Funny

Contribute to Open Password comunity - release your passwords under the GPP (General Public Password) license! Because closed passwords are just series of * symbols - it's hard to use, share and modify them freely. :-)

Re:Open Password! by AuMatar · 2006-03-12 18:12 · Score: 4, Funny

But my root password really is ********. I mean really, who the hell is going to guess that?

--
I still have more fans than freaks. WTF is wrong with you people?
Re:Open Password! by Brandybuck · 2006-03-12 18:21 · Score: 5, Interesting

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!
Re:Open Password! by dwater · 2006-03-12 20:05 · Score: 2, Interesting

You should've made the password something with a tab in it...(works on some login methods, but not others).

--
Max.
Re:Open Password! by ComaVN · 2006-03-12 22:14 · Score: 2, Informative

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.
Re:Open Password! by Asic+Eng · 2006-03-13 00:15 · Score: 2, Informative

But my root password really is ********. I mean really, who the hell is going to guess that?
Dunno - presumably it's long been in any password cracker out there? Along with "none" or "password" or any other "clever" password there is?

Re:okay by Aranth+Brainfire · 2006-03-12 17:49 · Score: 4, Informative

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

You're an idiot by Kasracer · 2006-03-12 17:51 · Score: 2

Fixing a patch that either simply removes this log file or encrypts the password in it is very simple. I could do this in a few minutes tops.

Microsoft's security issues often are the result of an issue that requires code re-writes and changes. It takes time to do that, compile it, and test it. There is a huge difference between this tiny flaw and a buffer overflow in Windows Media Player.

Re:okay by ralph+alpha · 2006-03-12 17:54 · Score: 3, Insightful

Deleting a log file isn't quite the same thing as fixing buffer overflows and whatnot in a huge chunk of code. Yeah, it took MS 2 weeks -- and that was too long. It's not like the two bugs were equal in scope, though.

Despite this little pasword issue... by Anonymous Coward · 2006-03-12 18:04 · Score: 2, Insightful

Ubuntu is poised to become to standard by which Linux distros are judged. I've been running the latest stable release, Breezy Badger 5.10 for awhile and it's rock solid, good looking, and easy to administer. Last night I downloaded Flight 5, the latest development iso for Dapper Drake 6.04, and was immediately impressed. In just one upgrade, they've managed to really go the extra mile with all the new features. I love minimalist simplicity, and Ubuntu gives me just that. Ubuntu is Debian made easy for the masses. You get the bullet-proof Debian core with a great, easy interface. Nothing touches this at the moment. Linux for human being is a great tagline.
Now, let the script kiddies who have nothing better to do flame me for saying Ubuntu is cool. These same script kiddies who think they're 1337 because they have to manually set up their Slackware box. These same wanna-be geeks who are still bootstrapping their Gentoo systems for 12 hours to extract a extra 5 milliseconds of speed from their CPUs. I've done all that and now that I'm almost 40 years old, I just want a quick, stable system to work from.

Re:Despite this little pasword issue... by MichaelSmith · 2006-03-12 18:31 · Score: 3, Informative

Ubuntu is Debian made easy for the masses. You get the bullet-proof Debian core with a great, easy interface. Nothing touches this at the moment.
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

Re:Just in case by Andrew+Tanenbaum · 2006-03-12 18:06 · Score: 2, Informative

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.

Re:Just in case by dtfinch · 2006-03-12 18:08 · Score: 2, Informative

If your /etc/shadow has something like "root:*:13039:0:99999:7:::", there's no root password.

Re:Just in case by miro+f · 2006-03-12 18:11 · Score: 2, Interesting

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...

Preview of 5.10 Not Affected by InViViD · 2006-03-12 18:13 · Score: 2, Informative

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.

Re:okay by The+Bungi · 2006-03-12 18:14 · Score: 4, Insightful

When you have 300,000,000 users things are a little more complicated than when you have 3,000.

Interesting juxtaposition by prockcore · 2006-03-12 18:18 · Score: 5, Insightful

I find it very interesting that the severity of this bug is identical to the severity of the security hole found in OSX last week... yet the difference in attitudes is remarkable.

Look at the slashdot summary. "An extremely critical bug and security threat". Compare with the OSX bug which was written off because it's not remotely exploitable.

Apple hasn't even acknowledged that the OSX privilege escalation exists, let alone patched it.

For Ubuntu 5.10 users: by dartarrow · 2006-03-12 18:22 · Score: 2, Informative

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

Solution by itismike · 2006-03-12 18:25 · Score: 5, Informative

open a terminal and type:
sudo apt-get update
wait for it to finish
click the Red update icon in the upper-right corner
click through the update
locate the file and verify that it is unreadable by a non-privileged user

Re:Solution by itismike · 2006-03-12 19:14 · Score: 3, Informative

Wait, so the fix leaves the cleartext root password on the hard disk?
No, the patch both removes the PW from the log file and chmod's the log file itself to 600.
Re:Solution by GigsVT · 2006-03-12 19:16 · Score: 2, Funny

Let me guess, it runs grep -v yourPassword on the log file, which then gets entered into the bash history? :)

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Re:Solution by 1u3hr · 2006-03-12 19:22 · Score: 4, Insightful

1. Change your password.
(Only passwords used during the install are written to the file in question.)
Re:Solution by mattyrobinson69 · 2006-03-12 20:03 · Score: 2, Informative

i think it more likely does something along the lines of:

cat /var/log/logfile | sed -e 's/^Your Root Password Is.*$//g' > /tmp/a ; mv /tmp/a /var/log/logfile
Re:Solution by Uber+Banker · 2006-03-12 22:36 · Score: 3, Insightful

With every ubuntu installation the first thing I did was setting a root password, even if you don't have any intention of using it, in my opinion having a password you don't know about is worse than having a password only you know.

Make sure you remove permissions for users to change the root password though. On a default Ubuntu install all a user need do is sudo passwd and enter root's new password (no need to enter the old one).
Re:Solution by swillden · 2006-03-12 23:41 · Score: 4, Informative

I asked them (again and again) "surely you are setting this to something?" and they all said no. It is now perfectly clear that the people answering my questions had no clue... having a password you don't know about is worse than having a password only you know.
No. The default Ubuntu install sets *no* root password. None. Not "one you don't know".
As others mentioned, the password under discussion here is a user account password (for an account with full sudo privileges, so it's effectively root).

--
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.

Apple did patch the recent OS X holes by I'm+Don+Giovanni · 2006-03-12 18:25 · Score: 2, Informative

Apple hasn't even acknowledged that the OSX privilege escalation exists, let alone patched it.

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=303 382

--
-- "I never gave these stories much credence." - HAL 9000

What does patch help? by magi · 2006-03-12 18:25 · Score: 3, Insightful

Ubuntu users, be sure to get the patch right away.

What does this patch fix? The installer? Sorry, but the installer is burned in the installation media, and a patch can be applied only after the installer has been run. So updating the system or even upgrading to Dapper (where it has been fixed) doesn't help. So....patch whAt???

No really, the installation ISO images should be fixed immediately and redistributed.

Also saying that it "only affects The 5.10 Breezy Badger release" may be a bit belittling, as probably most people have installed exactly that release.

Re:What does patch help? by prockcore · 2006-03-12 18:37 · Score: 2, Informative

What does this patch fix? The installer?

No, the patch removes that key from the file, and chmod's it 600.
Re:What does patch help? by identity0 · 2006-03-12 20:02 · Score: 2, Informative

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.
Re:What does patch help? by Fallingcow · 2006-03-12 20:19 · Score: 2, Interesting

I actually picked up the 5.10 disks last week, and was thinking of installing it... glad I didn't.

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 /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.

Choose strong obscure passwords by L505 · 2006-03-12 18:31 · Score: 5, Interesting

Using special characters not available on the keyboard is another strong security measure..

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.

Re:Choose strong obscure passwords by Anonymous Coward · 2006-03-12 19:42 · Score: 3, Interesting

...still more proof that NUL-terminated strings are the work of the devil. C'mon -- give up two bytes at the front of the string to tell how long the damned thing is. It's not fucking 1974 where the loss of a couple of bytes is gonna crap out the system. Prepend the length -- and reserve a value like 0xFFFF to mean "at the end of this string find another string with its own length encoded there..." -- Yes, I know, there's the potential for collision with a string that's actually 0xFFFF bytes long - but hey, the problem was solved to everyones satisfaction by pretty much every RLE encoding scheme.
Null termination is evil. Every buffer overflow you read about is a side-effect of null termination which could be avoided -- at the cost of two bytes per every sixty-five-thousand bytes of string.
Re:Choose strong obscure passwords by ajs318 · 2006-03-12 20:40 · Score: 3, Interesting

Only two bytes? That's a limitation of 65536 chars -- not that much really when you think about it. For crying out loud, we have 64-bit processors now. Please, let's think of the future, and reserve eight bytes for string length -- just in case somebody ever wants to put the entire addressable space into a scalar.

--
Je fume. Tu fumes. Nous fûmes!
Re:Choose strong obscure passwords by grahamlee · 2006-03-12 21:24 · Score: 5, Funny

Hey, if we're thinking of the future, let's not use a fixed-width length field for the string at all! That way, we can never generate a string longer than the permitted length field. Let's just terminate the string by a known character sequence, and guarantee that that sequence doesn't appear in the string itself. We could use the \0 character as the terminator.
Re:Choose strong obscure passwords by chris+macura · 2006-03-13 01:03 · Score: 2, Informative

Gee, I dunno.

Oh yeah!

typedef struct {
unsigned int len;
char *content;
} String;
Re:Choose strong obscure passwords by Syberghost · 2006-03-13 01:28 · Score: 2, Interesting

Those of you who have been doing the online thing a long time might recall an old BBS door game called "Time of Chaos". In that game, you could have a base with a passcode for the door, but opponents could buy a piece of gear that allowed them to make an attempt to crack your passcode.

The game would show the passcode as a series of periods ("."), replacing a random number of them with the actual codes. By using several of these devices, you could get several or all of the characters in the passcode by repeating the attempt.

A common defense was to use passcodes that consisted of periods, spaces, and alt-255, which on IBM-compatible systems of the time generated a character that looked onscreen like a space but wasn't.

This was especially effective if the attacker was on a system that couldn't easily generate the alt-255 character.
Re:Choose strong obscure passwords by sqlrob · 2006-03-13 02:04 · Score: 2, Informative

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!
Re:Choose strong obscure passwords by paulatz · 2006-03-13 02:14 · Score: 2, Informative

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

Use the right tool... by MarkByers · 2006-03-12 18:34 · Score: 5, Insightful

Don't use a bleeding edge home desktop OS if you want a secure multi-user server.

--
I'll probably be modded down for this...

Re:Use the right tool... by kestasjk · 2006-03-12 22:31 · Score: 3, Interesting

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);

Legal before security-the openssl vs netatalk mess by SuperBanana · 2006-03-12 18:35 · Score: 4, Interesting

Want another example of Debian/Ubuntu idiocy?

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.

Whew! by cciRRus · 2006-03-12 18:39 · Score: 2, Funny

Good thing I'm using Windows.

--
w00t

Re:Root password should never be recorded, ever by MichaelSmith · 2006-03-12 18:43 · Score: 2, Interesting

All that the operating system/software need to know is how to verify that the password entered is correct. And that can be done without storing the root password at all (encrypted or not) with a hash.

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

Re:MOD PARENT UP by optikSmoke · 2006-03-12 18:54 · Score: 2, Funny

Where else am i supposed to store my passwords?

/etc/motd?

(Just in case...)

Agreed. by jd · 2006-03-12 18:55 · Score: 2, Informative

If the password needs to be temporarily stored, there are plenty of ways to store a password that are secure and fast. Besides, since you'll only ever actually check the password against a hashed value, it would be more logical to store the hash if you want the speed.

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)

Root Passwords should never be stored ANYWHERE... by hvatum · 2006-03-12 18:58 · Score: 2, Informative

...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.

Re:Root password should never be recorded, ever by 19thNervousBreakdown · 2006-03-12 19:02 · Score: 2, Insightful

Insecure memory? Unless I'm missing something huge here, one process can't read another's memory. Can you give an example of how something can end up in "insecure" memory?. Maybe if you have access to /dev/(k)mem. Same goes for swap afaik. If those problems haven't been solved long ago, any Linux distro is swiss cheese.

Which means it's as simple as a GUI prompt for the password, and a pipe to passwd, no writing to disk necessary at all.

--
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>

Re:UNIX mouse driver released by Pogue+Mahone · 2006-03-12 19:02 · Score: 5, Informative

Since when did UNIX have mice.

Since long before MS-DOS had them:

Look..

--
Every bloody emperor has his hand up history's skirt [Peter Hammill/VdGG]

Patch mirror by atomic-penguin · 2006-03-12 19:06 · Score: 2, Insightful

#!/bin/sh
PASS="my_root_password"

echo "Why would anyone log a password in the installer?\n"
find /var/log -type f -exec sed -i s/$PASS//g' {} \;

echo "Why would anyone have /var/log readable by users?\n"
chown -R root:root /var/log
chmod -R o-rwx /var/log

echo "All done, thanks for using Atomic-Penguin\'s unofficial ubutnu patch!\n"

--
/^([Ss]ame [Bb]at (time, |channel.)){2}$/

Re:Patch mirror by zcat_NZ · 2006-03-12 21:18 · Score: 2, Funny

echo "Why would anyone leave their root password hardcoded in a bash script" ; exit 1

--
455fe10422ca29c4933f95052b792ab2
Re:Patch mirror by cortana · 2006-03-13 00:26 · Score: 3, Informative

Well done, you just took out the ability for most daemons to write to their log files.

Re:Legal before security-the openssl vs netatalk m by SnowZero · 2006-03-12 19:09 · Score: 4, Insightful

...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 has been discussed at length, and OpenSSL's license is GPL incompatible. Everyone else may simply think it's ok to bend the rules, and that they won't ever get sued for it. That's not a safe assumption for a volunteer-based distribution.

This doesn't stop every other distribution on the planet from compiling netatalk with openssl, and hence supporting encrypted passwords.

"Everyone else breaks the rules, so its ok." That doesn't work for speeding tickets, and it doesn't work in contract/license disputes.

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.

Maybe you and any other users of appletalk on unsecure networks ought to band together and fix it. Alternatively you can just switch distributions or upgrade your networking from appletalk (a 1980s protocol, since you were talking about being 10-years backwards).

Does it suck? Yes. It sucks that the OpenSSL people won't change their license, and upstream netatalk doesn't care either. However Debian would risk legal action against ALL users if they break the law, even though 1% of the users use this package. They chose the solution for 99% of their users, which is the best you can hope for in an esoteric case like this.

Does not apply to expert mode installs by Pausanias · 2006-03-12 19:10 · Score: 2, Interesting

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

Re:Does not apply to expert mode installs by Pausanias · 2006-03-12 20:42 · Score: 2, Interesting

OK, well folks in the bug report are now saying they have the cleartext password in their logs even with an expert install. So it's not at all clear why some users have the cleartext and other don't. Anybody know why?

Not in my logs at all by Philip+K+Dickhead · 2006-03-12 19:15 · Score: 2, Informative

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

Real Solution: CHANGE YOUR PASSWORD by Stephen+Samuel · 2006-03-12 19:35 · Score: 3, Insightful

Anybody who's done a breezy install and allowed any sort of remote or non-admin access should be changing their password .... NOW! .

The patch (unless it goes out and deletes the offending files) is only going to patch the installer (which you're probably never going to run again). You're still going to have a cleartext copy of your original admin password sitting on the box in a file with read-other permissions.

Even if the files get deleted (or have their permissions changed), you still have no idea as to whether somebody has read the files since October.

BTW: Are they re-burning the installation CDs?

--
Free Software: Like love, it grows best when given away.

Re:Real Solution: CHANGE YOUR PASSWORD by Barrakketh · 2006-03-13 02:23 · Score: 2, Informative

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.
Re:Real Solution: CHANGE YOUR PASSWORD by An+Onerous+Coward · 2006-03-13 06:02 · Score: 2, Informative

"The patch (unless it goes out and deletes the offending files) is only going to patch the installer (which you're probably never going to run again). You're still going to have a cleartext copy of your original admin password sitting on the box in a file with read-other permissions."

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) is no longer readable by anyone but root, and no longer contains the offending passwords.

--
You want the truthiness? You can't handle the truthiness!

Dude, if you have to... by Anonymous Coward · 2006-03-12 19:48 · Score: 2, Insightful

..install a backdoor password, at least make it a not easily crackable one.. :|

Re:Root Passwords should never be stored ANYWHERE. by Attrition_cp · 2006-03-12 20:06 · Score: 2, Insightful

Just a question, if the password hash isn't stored anywhere, how do you compare the password you enter to the actual password?

--
Touched By His Noodley Appendage.

Re:[easier] Solution by Filip22012005 · 2006-03-12 20:46 · Score: 2, Informative

Isn't the password in your bash history now (twice)?

--
When the policeman of the tie, rule you violate, hello punishment of the kitty?

Re:[easier] Solution by tpgp · 2006-03-12 21:00 · Score: 3, Informative

Isn't the password in your bash history now (twice)?

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:

sudo grep -r mypasswd /var/log

(if it returns your password, you're vulnerable

sudo apt-get update sudo passwd base-config

(wait)

sudo grep -r mypasswd /var/log

(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.

"you should fix it" is elitist bullshit by SuperBanana · 2006-03-12 21:35 · Score: 3, Insightful

Alternatively you can just switch distributions or upgrade your networking from appletalk (a 1980s protocol, since you were talking about being 10-years backwards).

Secure password authentication in AFP was introduced at least 10 years ago. We're talking about AppleSHARE here, Mr. Genius. A protocol fully maintained and used extensively on current hardware. I'll switch to SMB when it offers the same level of performance as AFP (it doesn't, not even close, in raw transfer speed or directory operations) and the same filename compatibility.

Maybe you and any other users of appletalk on unsecure networks ought to band together and fix it.

So let's get this straight.

Linux software authors tell us how wonderful Linux is, how great "open source" is. We won't be locked into anything, blah blah.
We switch over. Things are good; it's free, it's fast, it's mostly stable and somewhat bug-free. Until we discover problems.
We report the problems- even filing those nice bug reports in Bugzilla.
We notice nobody's giving our problems any attention (over the course of years) and we complain about the delay.
We get told "it's a matter of principle" and to go fuc...sorry, I mean...fix it ourselves.

Like many a faithful geek, I was led down the path of "enlightenment" offered. I helped give open-source software market share. I helped sell open-source to my boss, and my boss's boss. I redirected my career to support open-source software.

And what do I get in return? "Fix it yourself, you dumb user."

To think I still get asked why I'm not running Linux on my Powerbook. Because IT JUST WORKS; no politics, no "nobody cares about that bug so it won't be fixed". Because I don't have to deal with arrogant blowhard grad students telling me to fix software myself. I have neither the time, ability, knowledge nor inclination necessary to run around fixing complex software. 99.999% of the rest of the world doesn't either. Sad reality of life is that there is an extremely small segment of the population of linux users that have even the slightest qualifications to know how to go about fixing bugs or adding features.

Like most academics, you have zero comprehension of what matters in the real world. Joe Sixpack doesn't go into Firefox and add features. Jane Officeuser doesn't fix GnuTLS so it works with netatalk. Users don't give a damn about theoretical lawsuit possiblities. They don't give a shit about the finer points of licensing. Nothing impresses a CIO or a Director of IT less than "oh, we have to transmit passwords in clear-text because the license for a system library isn't compatible with the license for the server software."

Oh, and if you believe the whole Debian kool-aide line about "we have to protect this because we'd ALL BE SUED", I have two bridges in NY I'd just LOVE to sell you. PS: It says "gullible sheep" on the ceiling.

--
Please help metamoderate.

Re:"you should fix it" is elitist bullshit by Chris+Pimlott · 2006-03-12 22:33 · Score: 2, Insightful

Licenses aren't a technical detail of Linux, it's the core. It's what makes them possible. If we decide to start ignorning them because they are inconvenient in some particur situation, we weaken the entire foundation of open source software.

And anyway, you may find in this post-SOX world that administrators care a bit more about the legality of their software than you may think.

Re:first rule by Vo0k · 2006-03-12 21:46 · Score: 3, Funny

> So they call me as they need the password for the isp access, "penis",

If you tried this on my system, it wouldn't work, it would say your password is too short.

--
Anagram("United States of America") == "Dine out, taste a Mac, fries"

Re:Root account not activated during installation by Dan+Farina · 2006-03-12 23:46 · Score: 2, Insightful

Why is this a right-minded concept, may I ask? I am truly ignorant of the reasoning, so please enlighten me...

Re:[easier] Solution by fimbulvetr · 2006-03-13 02:16 · Score: 2, Informative

'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'

Re:[easier] Solution by Zwaxy · 2006-03-13 03:16 · Score: 2, Informative

"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.

Slashdot Mirror

Root Password Readable in Clear Text with Ubuntu

115 of 520 comments (clear)