Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

[ CONTENT OF TYPE application/pgp-signature SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ