[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E53B5E6C-1251-424F-A1F8-564775158247@justinbull.ca>
Date: Sun, 21 Jun 2015 18:13:42 -0400
From: Justin Bull <me@...tinbull.ca>
To: cve-assign@...re.org,
oss-security@...ts.openwall.com
Subject: Re: CVE Request: MITM & Shoulder-surfing vuln in Ruby OTP/HOTP/TOTP library "ROPT" - ROTP
> We don't think there can be a CVE ID for any aspect of the report
> recommending that the verifier comply with RFC 6238. We agree that it
> would be useful for the ROTP documentation to place some emphasis on
> the actual verifier behavior, to cover the scenario where a user
> guesses that full RFC compliance was intended, and later discovers
> that a "MUST NOT" condition isn't met.
Unfortunate in my opinion, but fair enough.
If software that uses ROTP to provide two-factor authentication fails to implement the TOTP “burning” in its verification step, and does not explicitly state full RFC 6238 compliance, is that grounds for a CVE ID? I’m curious as to what *counts* as a valid CVE ID, since at the end of the day, an RFC designed to define & provide a 2FA mechanism is not being followed and an (albeit narrow) attack surface is available as a result. A tangible example would be the devise-two-factor[1] library, which uses ROTP.
The way I see it, any software that uses ROTP for TOTP and does not complete the necessary OTP consumption work as defined in the RFC, that *counts* as providing flawed software. And by flawed I mean vulnerable to attack.
But alas, perhaps I’m being just pedantic, making mountains out of molehills, and pragmatism is required here.
> > NOTE: I have already sent a similar email to MITRE requesting a CVE
> > ID, but been advised to submit here as well (then cancel the request
> > to MITRE
>
> We aren't exactly sure what this means. The MITRE CVE team currently
> does not advise anyone to send messages to oss-security. The "already
> sent" apparently refers to a message from an hour earlier. Messages
> for us can be sent to either oss-security or to cve-assign@...re.org
> but should not be sent to both addresses. Of course, we are willing to
> accommodate the occasional case where someone accidentally sends to
> cve-assign@...re.org but actually wanted to make the information
> public immediately on oss-security.
>
Ah so a few mistakes on my part. After having sent the initial report to cve-assign@...re.org, I read CVE request HOWTOs stating that:
(1) cve-assign@...re.org inbox is subject to many, many reports and has a long turnaround
(2) cve-assign@...re.org should be contacted first before a public report
(3) That if the security report is already public (in this case via GitHub) that a public email to oss-security@...ts.openwall.com is a better option for both speed and full disclosure
That advice was from a colleague who had experience requesting CVE IDs, not from anyone from within MITRE.
For all intents and purposes, I really wanted to make the info public immediately on sos-security, and only knew this *after* I sent the original report to cve-assign@...re.org.
Apologies for the kerfuffle. It won’t occur in future reports :-)
> (Subject line modified to account for the "ROPT" typo.)
Thanks for catching that. I was 48 hours post-op from LASIK and had low-vision, it’s very hard to spot typos.
[1]: https://github.com/tinfoil/devise-two-factor/issues/30
Best Regards,
Justin Bull
PGP Fingerprint: E09D 38DE 8FB7 5745 2044 A0F4 1A2B DEAA 68FD B34C
Download attachment "signature.asc" of type "application/pgp-signature" (843 bytes)
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.
