[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150622113539.4066D6C028A@smtpvmsrv1.mitre.org>
Date: Mon, 22 Jun 2015 07:35:39 -0400 (EDT)
From: cve-assign@...re.org
To: me@...tinbull.ca
Cc: 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> A tangible example would be the devise-two-factor library, which uses ROTP
> ... an (albeit narrow) attack surface is available as a result
>> https://github.com/tinfoil/devise-two-factor/issues/30
>> vilda: RFC 6238 requires the implementation to disallow (MUST NOT) multiple submissions
>> ShaneWilton: Thanks for pointing this out! I'll fix it when I have a chance.
devise-two-factor can potentially have a CVE ID. As you mentioned, the
attack surface is somewhat narrow, and it might make more sense to see
how the devise-two-factor vendor announces the update. For example, if
the vendor makes a code change to prevent multiple submissions and
describes the code change as resolving a vulnerability, then there can
be a CVE ID.
> 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
We don't currently know of a way to comprehensively and precisely
specify this for all possible behaviors in all products. A CVE is
typically not used for a case in which, when the product was
originally shipped, the implemented behavior was the behavior desired
by the vendor. This, of course, has the ambiguity of what "desired"
means.
>>> https://github.com/mdp/rotp/issues/44#issuecomment-113824151
>>> Looking at other OTP libraries, I can't find any that actually try and
>>> implement protection against reuse, most likely because it requires
>>> some external storage to do correctly.
This is an example in which it appears reasonable for a vendor to skip
full RFC compliance (and, importantly, not advertise full RFC
compliance) because the context and capabilities of the product make
it substantially difficult to address one of the threat models.
Another example:
>> https://github.com/tinfoil/devise-two-factor/blob/master/README.md
>>
>> you'll need to generate an encryption key, and store it in an
>> environment variable of your choice
>> http://www.ietf.org/rfc/rfc6238.txt
>>
>> 5.1
>>
>> The key store MUST be in a secure area
It appears that this devise-two-factor documentation doesn't
explicitly rule out operating systems where environment-variable
values are readable by all users (see
http://security.stackexchange.com/questions/14000/environment-variable-accessibility-in-linux
for related discussion). So, this might be another case where there
isn't full RFC 6238 compliance, and yet the vendor may have never had
any intention of supporting the applicable operating systems.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVh/KyAAoJEKllVAevmvmsDysH/01bM5ToKwulwBHN8TDIUWPa
RXA+YCJ6UePNhyrfzSnaXP0RtnfU5gpKGws8oZnxENjz4Vgmkv/exPpDZzgVedQ9
B6M9cy6rFM+Qyu8SMaUp4wtjet7FAO/ZyyyBjwQSGMQ9LQoz7QBp09OHN68F0MBe
YTuk+uswC1BgWtSJJVEzTUkOKn88Lg0Og8H3m5FDdLhrO/i74yOmEofe1LokR6ww
a6SfNRfFXS/BWMVvgtJw1JVHc5FnJsiDjIB6rTBfhfm2vhxVvMqqdq3GpUVtpnYP
AlBzqUwtGm4D/rUxVgrSYae2zdFPuQXqkmVOcZy9aa8r15oH0i1R6bBUsi6B2nM=
=aJW2
-----END PGP SIGNATURE-----
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.
