Date: Tue, 31 Jan 2012 08:22:13 +0100 From: Gian Piero Carrubba <gpiero@...rf.it> To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com> Cc: Nanakos Chrysostomos <nanakos@...ed-net.gr>, Kurt Seifried <kseifried@...hat.com>, Jonathan Wiltshire <jmw@...ian.org>, "team@...urity.debian.org" <team@...urity.debian.org> Subject: Re: Re: Yubiserver package ships with pre-filled identities * [Mon, Jan 30, 2012 at 11:32:12PM +0200] Nanakos Chrysostomos: >>2) can someone remotely/locally access these accounts? what are the >>credentials for these accounts ("invalid keys"?), can an attacker >>access >>them? >> > >If someone programs or uses a software emulation for the yubikey can >have access to whatever the user of the application uses it for ( the >yubiserver). For example if someone uses Pam yubico module with the >su or sshd server to provide a two factor authentication scheme he >should suffer from this security issue if he hasn't deleted or >deactivated the test account. If someone by mistake installs >yubiserver and doesn't use him to validate his otp or hmac otp, he >won't suffer from this security issue. Someone can only suffer if he >uses the server and hasn't deleted or deactivated the test account >which is shipped with the server. Just elaborating a bit more. Yubiserver performs key validation, so it could perform authentication (or part of, if used in a multi-factor authentication schema) but it can't by itself grant authorizations. For example, I'm not sure a default account can be an immediate problem when yubiserver is used with the pam module, as the latter - if I'm not wrong - need a mapping file for associating users to keys in order to assign the right authorizations. More generally, in a 2FA environment, a default account in yubiserver could lessen the security level but should not expose a straight attack vector. Problem arises when a user doesn't check the account db  and blindly trust the results of key validation, possibly automatically mapping successfully validated keys to default users. I doubt this can happen for system logins, unless something is seriously wrong, but there are other resources for whose I think this scenario is plausible (i.e. authentication to a proxy server or granting access to a network segment). To be honest, issuing a CVE seems a bit overkilling to me. Anyway I strongly support the idea that it should not ship default accounts that can be overlooked, specially when distributed via distro packages with the additional automatisms in place (e.g. typically the daemon is automatically started, enabling de facto the accounts, and some other integrations could be in place). Ciao, Gian Piero.  yes, shame on him, but this is not the point.
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ