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

[Thijs Kinkhorst]

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
>