Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 31 Jan 2012 08:22:13 +0100
From: Gian Piero Carrubba <>
To: "" <>
Cc: Nanakos Chrysostomos <>,
	Kurt Seifried <>,
	Jonathan Wiltshire <>,
	"" <>
Subject: Re: Re: Yubiserver package ships with pre-filled

* [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 
>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 
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 

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

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.