Re: CVE Request: MITM & Shoulder-surfing vuln in Ruby OTP/HOTP/TOTP library "ROPT" - ROTP

[Justin Bull <me () justinbull ca>]

> 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 () mitre 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 () mitre 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 () mitre org, I read CVE request 
HOWTOs stating that:

(1) cve-assign () mitre org inbox is subject to many, many reports and has a long turnaround
(2) cve-assign () mitre 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 () 
lists 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 () mitre 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail