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 <[email protected]> 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 > > > > >
