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 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. : 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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ