Re: [OATH-Toolkit-help] libpam-oath vulnerable to replay of OTP as result of incorrectly parsing comments in users file?

[Jed Laundry]

Hi,

Looking at the code, the problem exists in usersfile.c

The problem is that parse_usersfile() is called first to find the matching usersfile entry, and uses parse_type() to find the type of OTP; #HOTP doesn't match any known type and therefore skipped_users isn't incremented. Later, once the correct username is found and the OTP token verifies, update_usersfile2() then only uses the username and skipped_users counter to find the line to replace (tokenising the type, secret, pin etc), and because skipped_users wasn't incremented, writes the update to the commented out line.

Hmmm.

Simon, how do you want to proceed? AFAICT, comments in the usersfile aren't explicitly supported and one is supposed to maintain separation between the usersfile, which controls authentication, and an authorisation file/mechanism, but I imagine that because it Just Works for usersfiles that don't contain duplicate usernames that there are a few people using it in this way...

Thanks,
Jed.

On 13 December 2013 05:11, Thijs Kinkhorst <address@hidden> wrote:

Hi Oath-maintainers,

Any news on the below issue?


Thijs

On Mon, December 9, 2013 12:31, Bas van Schaik wrote:
> Dear maintainers (cc. Debian Security Team),
>
> It appears that libpam-oath (part of oath-toolkit) in Debian Wheezy
> (version 1.12.4-1) incorrectly parses comments in its users file (e.g.
> /etc/users.oath), resulting in it failing to invalidate a used
> one-time-password (OTP), leaving it vulnerable to replay of OTPs. I
> didn't file this as a bug because of possible security implications -
> even though the risk seems small. Also, I'm not sure whether the problem
> is specific to libpam-oath, or whether any of the other packages derived
> from the oath-toolkit source are affected as well.
>
> Here's a description of the problem by example. The users.oath file
> consists of lines like the following:
>> HOTP    bas    [my-optional-secret-password]    [my-secret-key]
>> [last-used-OTP-index]    [last-used-OTP] [last-used-datetime]
>
> To prevent replay of a used OTP, the index and last OTP are updated
> whenever an OTP is used. However, libpam-oath fails to update said file
> if it contains a commented-out line that matches the username. For
> example, consider this users.oath in which the administrator decided to
> replace the old secret key "abcd" with a new key "efgh":
>> #HOTP    bas    -    abcd    55    12345678    2013-12-06T23:13:40L
>> HOTP    bas    -    efgh
>
> After using "efgh" for the first time with OTP 98765432, the users.oath
> /should/ contain the following:
>> #HOTP    bas    -    abcd    55    12345678
>> 2013-12-06T23:13:40L       [unchanged]
>> HOTP    bas    -    efgh    1    98765432 2013-12-07T23:13:40L
>> [invalidating OTP 98765432]
>
> However, libpam-oath incorrectly parses users.oath and actually updates
> the commented-out entry. So the users.oath file after using OTP
> "98765432" with key "efgh" looks like this:
>> #HOTP    bas    -    abcd    56    98765432
>> 2013-12-07T23:13:40L           [changed - even though it was commented
>> out]
>> HOTP    bas    -    efgh                 [didn't change!]
>
> Note that the entry for secret key "efgh" remains unchanged, and the
> commented-out entry for key "abcd" was updated (even though 98765432 is
> an OTP for key "efgh", hence unlikely to be a valid OTP for key "abcd").
> Consequently, libpam-oath actually accepts the used OTP "98765432"
> again, and again, and again. It will keep on updating the commented-out
> entry, whilst leaving the entry for secret "efgh" untouched.
> Furthermore, it will accept any new OTP as well, as long as this OTP
> lies within the preconfigured search window.
>
> It appears that libpam-oath correctly ignores commented-out lines when
> searching users.oath for matching entries, but does not ignore
> commented-out lines when updating users.oath. If the file contains
> multiple keys for the same user, the file is updated correctly. E.g.:
>> HOTP    bas    -    abcd    55    12345678    2013-12-06T23:13:40L
>> HOTP    bas    -    efgh
>
> Is updated to:
>> HOTP    bas    -    abcd    55    12345678    2013-12-06T23:13:40L
>> HOTP    bas    -    efgh    1    98765432    2013-12-08T23:13:40L
>
> After using OTP "98765432" for key "efgh".
>
> Unfortunately I haven't been able to test this vulnerability using the
> libpam-oath in Debian testing, as this version depends on packages that
> are unavailable for Wheezy. I'd be happy to provide any additional
> information if needed, and am more than happy to test alternative
> configurations or patches.
>
>    Bas van Schaik
>