oath-toolkit-help
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[OATH-Toolkit-help] libpam-oath vulnerable to replay of OTP as result of


From: Bas van Schaik
Subject: [OATH-Toolkit-help] libpam-oath vulnerable to replay of OTP as result of incorrectly parsing comments in users file?
Date: Mon, 09 Dec 2013 11:31:43 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]