[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120131072213.GA3713@caimano.fdc.rm-rf.it>
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 [0] 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.
[0] 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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
