A security issue has been announced on May 23: http://openwall.com/lists/oss-security/2013/05/23/2 The RedHat bug notes it's fixed in 17.17, which we could update to on Mageia 3 and Cauldron. It's fixed in some earlier versions too, but no 14.x, so it's unclear how to handle Mageia 2 (which has 14.3). Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA3TOO, MGA2TOO
I will check how password is handled in 14, if i understood the fixing. I cannot fix it tonight though. I will work on it during the week end.
Status: NEW => ASSIGNED
I think in mga3 this issue is not a problem at the moment. Live cd tools does not work at all, i tested three different configuration working at Version freeze time. Does anyone has a working kickstart? Without a live out, i think we don't have the security issue :) I will open a bug for that and block this for mga3. As far as mga2 concerned, i will test 14 with the patch, stay tuned.
URL: svn+ssh://svn.mageia.org/svn/packages/updates/2/livecd-tools Commit: 427168 | anaselli | Fixes Bug 10259 - livecd-tools new security issue CVE-201... mga 2 is fixed and in testing. How can we manage this? Should we open 2 different bugs?
Yes, file a new bug for Mageia 2 which blocks this one. Assign the new bug to QA.
Hardware: i586 => All
hmm I'm reading better this issue: " Root Cause Kickstart can be used to automate operating system installations. A Kickstart file specifies settings for an installation. Once the installation system boots, it can read a Kickstart file and carry out the installation process without any further input from a user. Kickstart is used as part of the process of creating Images of Red Hat Enterprise Linux for cloud providers. It was discovered that when no 'rootpw' command was specified in a Kickstart file, the image creator tools gave the root user an empty password rather than leaving the password locked, which could allow a local user to gain access to the root account (CVE-2013-2069). We have corrected this issue by updating the Kickstart file used to build affected images to lock the password file. This issue was caused by the way a tool was used to create Images, and not due to a security vulnerability in Red Hat Enterprise Linux, or AWS. Red Hat would like to thank Amazon Web Services for reporting this issue. Amazon Web Services acknowledges Sylvain Beucler as the original reporter. " And : " Avoid setting empty root password (#964299) When using kickstart with no rootpw command, imgcreate ended up calling "passwd -d root", leaving the root account password-less. That may lead to local or remote privilege escalation. This change does the following: 1) There's no password manipulation done when password is empty string and rootpw was not called with --iscrypted 2) Password is locked when "rootpw --lock" is used Notes: Users can still shoot themselves in a foot by using: rootpw --iscrypted "" Resolves: rhbz#964299 (CVE-2013-2069) " I've just added the patch, but the real fix is to lock te password into the existing systems and to avoid building new ones without root password (they changed their kickstart). So i don't understand which is the problem really. If you want to have a non root password system you can do even with these changes... Before forking the bug i should add rootpw entry in our kickstart example, but that does lock the root password without been able to do anything as root in the outcome iso. Should i really change a thing like that, even if a user can remove that line?
Depends on: (none) => 10278
(In reply to Angelo Naselli from comment #5) > I've just added the patch, but the real fix is to lock te password into the > existing systems and to avoid building new ones without root password (they > changed their kickstart). So i don't understand which is the problem really. > If you want to have a non root password system you can do even with these > changes... You can still have it, but it's only going to happen if you configure it explicitly that way, knowing that's what you're doing. It's not going to silently happen accidentally anymore. > Before forking the bug i should add rootpw entry in our kickstart example, > but that does lock the root password without been able to do anything as > root in the outcome iso. Should i really change a thing like that, even if a > user can remove that line? It only locks the root password if it's not set. If you have a rootpw entry in the kickstart file which sets the root password, that one gets used. Maybe somewhere you can recommend people set one that way, but it really depends on the use case. In some cases it's probably perfectly fine to have it locked and nobody should need to access it. I don't use live CDs, but I would think if you have physical access to the machine running it you could boot to single user mode and set the root password that way. I don't think adding a rootpw line with some known-default root password in your example kickstart file would be a great idea, as it just replaces a known-default empty password with something else known. What is a bit perplexing is this: https://bugzilla.redhat.com/show_bug.cgi?id=964299#c8 Are they saying that these live CDs are configured to give the regular users full root access through sudo by default? If so, that's just as bad as this CVE.
if you don't set rootpw in ks the password is still empty, as you can see in https://bugzilla.redhat.com/show_bug.cgi?id=964299#c5 and https://git.fedorahosted.org/cgit/livecd/commit/?id=d40ec8e9d8e8222196f5f7f60b38983489794a67 the code is pretty clear - else: - self.unset() + + if ksrootpw.lock: + self.lock() Unset has been removed but also the else clause, replaced by a if containing (rootpw => lock) So the password is not locked by default, just if you want it. And then they added (always in the same comment5 above) a default lock into kick start files: https://git.fedorahosted.org/cgit/cloud-kickstarts.git/commit/generic?id=a81eef60ed108f37747168dbfe05dd6c6484ef63 I believe the rial problem is that these live cd can be copied into usb key or virtual machines and so you can get root access by logging in as user and doing the "su" command. Now a silly question.... but this is the behaviour of our live cd as well isn't it? Anyway until i'm not able to have livecd working again in 3 i cannot fix this, i start thinking it's too much effort for me maintaining a program in this situation (in which changing of kernels/dracut/etc need to be tested and tested again) that probably no one use...
(In reply to Angelo Naselli from comment #7) > if you don't set rootpw in ks the password is still empty, "It was discovered that livecd-tools gave the root user an empty password rather than leaving the password locked in situations where no 'rootpw' directive was used or when the 'rootpw --lock' directive was used within the Kickstart file" I could be wrong, but it sounds to me like having no rootpw directive is handled the same as having rootpw --lock, which before this fix failed to actually lock the account. If I'm right, then it will lock it by default now. > I believe the rial problem is that these live cd can be copied into usb key > or > virtual machines and so you can get root access by logging in as user and > doing the "su" command. It does sound like this issue is a bigger problem on VMs than live CDs, yes. > Now a silly question.... but this is the behaviour of our live cd as well > isn't it? I have no idea, but if they're intended to only be used as Live CDs, you could argue that's reasonable I suppose. > Anyway until i'm not able to have livecd working again in 3 i cannot fix > this, i start thinking it's too much effort for me maintaining a program in > this situation (in which changing of kernels/dracut/etc need to be tested > and tested > again) that probably no one use... Does that mean we should drop this package in Cauldron?
CC: (none) => tmb
About rootpw i will check it on centos, since i use livcd-tools for building an easy installer there. But on mga2 I'm sure the patch has not changed the behavior if you don't add rootpw to kickstart. (except for "passwd -d" that is not run anymore for root). About livecd yes, i think it's a normal behavior, but someone could copy it on USB key and then the CVE issue is valid for any live cds then. About dropping this package, no, i will say it as soon as i am taking a decision like that. Certainly it's not an easy task to work on, first patching for being compatible to urpmi and mageia, than taking care not to have any regressions any time something change internally. Anyway the real thing that matters to me if there is anyone interested in this package, but me.
Blocks: (none) => 11726
As written this is not a real security issue, if the user wants to create a live cd without root password can do that also with the fixing added. Moreover i'm not sure livecd tools works in mageia 4, certainly it does not in mgaeia 3. I was not able to work on it during these 6 months. I asked for help but no one was interested in worknig on this package, we could remove it from mirrors, however there are a lot of patches that i'd like not to loose so if it can stay into svn it could be fine. Thanks Angelo
Thanks for the feedback Angelo. CC'ing sysadmins as the maintainer requested to drop the package in Cauldron. Keeping it in SVN shouldn't be a problem.
CC: (none) => sysadmin-bugs
I am OK, I still use the livecd tool from Mandriva Are we going to provide a livecd tool with mga4?
CC: (none) => thomas
(In reply to Thomas Spuhler from comment #12) > I am OK, I still use the livecd tool from Mandriva > Are we going to provide a livecd tool with mga4? I think there are several, I don't know what's packaged. It'd be better to ask that on the mailing list.
Thomas i wanted to provide it for mageia 3, and from version freeze to final release of it, i discovered that live cd tools was not able to work anymore. Unfortunately i could not work on it during these long time. Have you tried if it works for you in mageia 3 by any chance? And yes, i hope to work on it as soon as possible that's why i asked for leaving it on SVN, and any helps/contributions here is appreciated :).
Moving this from the Mageia 4 security tracker (which is closing) to the Mageia 4 blocker tracker, just so it isn't missed.
Blocks: 11726 => 11704
David i have already committed the patch, even if livecd tools was not working, as it was before the patch. r427029 | anaselli | 2013-05-25 10:14:23 +0200(sab, 25 mag 2013) | 2 lines Fixes Bug 10259 - livecd-tools new security issue CVE-2013-2069 Angelo
No, you didn't add any patch. You tried to update it to 17.17, which would have fixed this, but it didn't build.
what didn't build? bm creating package list processing package livecd-tools-17.17-%mkrel 2 building source and binary packages succeeded! It's a python script! it does not work really, but neither the one that it was in mga3. You could use it, but the output live iso, simply does not start. You can leave it open if you want, but the fact is 17.17 contains the patch and it builds so mga4 has a non working but without that issue package!
I don't know why it didn't build, but 17.15-2.mga3 is still in the Cauldron repository. If what's in SVN now builds, then you can ask for a freeze push request, and maybe they'll still let it in at this late stage.
It's no use to be rude! I don't ask for a push becuase (and i'm tired to say that) it *does not* work. But it isn't a build issue, so if no one updated it after the rebuilding i don't know why either. svn log | head ------------------------------------------------------------------------ r507508 | umeabot | 2013-10-18 07:18:59 +0200(ven, 18 ott 2013) | 1 line Mageia 4 Mass Rebuild ------------------------------------------------------------------------ r427029 | anaselli | 2013-05-25 10:14:23 +0200(sab, 25 mag 2013) | 2 lines Fixes Bug 10259 - livecd-tools new security issue CVE-2013-2069 I cannot work on it atm! I said that tons of times, i also asked in dev mailing list to remove this package from mirrors, but to leave it in svn though. Moreover I am not motivated to work on this package atm, because it seems no one is really interestd in it, or better no one can help me (but coling) to fix dracut stuff and other things.
(In reply to Angelo Naselli from comment #20) > It's no use to be rude! I'm not sure where you got that. I just don't understand why you seem to be objecting to removing the package all of a sudden, when that was the agreed solution for now, because of what you said below. If you find time or get help to fix it later, it can be reintroduced through an update, but there's no sense in shipping a broken package with a security problem. > I don't ask for a push becuase (and i'm tired to say that) it *does not* > work. > But it isn't a build issue, so if no one updated it after the rebuilding > i don't know why either. The bot isn't allowed to push versions that are newer than what's already in the repository. > svn log | head > ------------------------------------------------------------------------ > r507508 | umeabot | 2013-10-18 07:18:59 +0200(ven, 18 ott 2013) | 1 line > > Mageia 4 Mass Rebuild > ------------------------------------------------------------------------ > r427029 | anaselli | 2013-05-25 10:14:23 +0200(sab, 25 mag 2013) | 2 lines > > Fixes Bug 10259 - livecd-tools new security issue CVE-2013-2069 > > I cannot work on it atm! I said that tons of times, i also asked in dev > mailing > list to remove this package from mirrors, but to leave it in svn though. Yes, exactly. That's the purpose of this bug blocking the tracker. > Moreover I am not motivated to work on this package atm, because it seems no > one is really interestd in it, or better no one can help me (but coling) to > fix dracut stuff and other things.
(In reply to comment #21) >> It's no use to be rude! >>I'm not sure where you got that. Sorry then i misudnerstood. :)
(In reply to Angelo Naselli from comment #22) > (In reply to comment #21) > >> It's no use to be rude! > > >>I'm not sure where you got that. > Sorry then i misudnerstood. :) :o) I think I misunderstood you in Comment 16 as well. Anyway, the package has been removed from Cauldron. Hopefully someone can help fix it at some point, but if you're not able to find time for it, we certainly all understand.
Version: Cauldron => 3Blocks: 11704 => (none)Whiteboard: MGA3TOO, MGA2TOO => (none)
Closing due to Mageia 3 EOL: http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/
Status: ASSIGNED => RESOLVEDResolution: (none) => OLD