From ${URL} : - _check_signature() ignores the nonce value when validating signed urls def _check_signature(self, request, consumer, token): timestamp, nonce = request._get_timestamp_nonce() self._check_timestamp(timestamp) signature_method = self._get_signature_method(request) try: signature = request.get_parameter('oauth_signature') except: raise MissingSignature('Missing oauth_signature.') # Validate the signature. valid = signature_method.check(request, consumer, token, signature) if not valid: key, base = signature_method.signing_base(request, consumer, token) raise Error('Invalid signature. Expected signature base ' 'string: %s' % base) Ignoring the nonce value enables replay attacks. This appears to already be known (ignoring the misleading title): https://github.com/simplegeo/python-oauth2/issues/129 - _check_timestamp() does not constrain how far into the future times may be, (also does not prevent negative times, but probably not relevant for a CVE) def _check_timestamp(self, timestamp): """Verify that timestamp is recentish.""" timestamp = int(timestamp) now = int(time.time()) lapsed = now - timestamp if lapsed > self.timestamp_threshold: raise Error('Expired timestamp: given %d and now %s has a ' 'greater difference than threshold %d' % (timestamp, now, self.timestamp_threshold)) The timestamps are probably most useful to limit the number of nonces that must be stored and compared but it seems generally useful to prevent timestamps from the distant future from being allowed. - make_nonce(), generate_nonce(), and generate_verifier() use a poor prng: @classmethod def make_nonce(cls): """Generate pseudorandom number.""" return str(random.randint(0, 100000000)) def generate_nonce(length=8): """Generate pseudorandom number.""" return ''.join([str(random.randint(0, 9)) for i in range(length)]) def generate_verifier(length=8): """Generate pseudorandom number.""" return ''.join([str(random.randint(0, 9)) for i in range(length)]) Nonces may not need full-blown /dev/urandom but the Python 'random' documentation clearly states the results are repeatable. The lack of seeding in this module makes me think this is too weak for this use. The safety of oauth depends upon the verifier being unguessable, and this is both too short, with too few character choices, and probably does need full-blown /dev/urandom style randomness. The poor PRNG for the nonce has been known since 2010-04-24 (silly github, hover your _mouse pointer_ over the "3 years ago" text in the bug report): https://github.com/simplegeo/python-oauth2/issues/9 @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
Upstream claims to have this fixed. https://github.com/joestump/python-oauth2/issues/129#issuecomment-125934274 https://github.com/joestump/python-oauth2/commit/82dd2cdd4954cd7b8983d5d64c0dfd9072bf4650
(In reply to Manuel Rüger from comment #1) > Upstream claims to have this fixed. > https://github.com/joestump/python-oauth2/issues/129#issuecomment-125934274 > > > https://github.com/joestump/python-oauth2/commit/ > 82dd2cdd4954cd7b8983d5d64c0dfd9072bf4650 I only see CVE-2013-4346 referenced. Please clarify if 4347 is also fixed.
CVE-2013-4347 was fixed via https://github.com/joestump/python-oauth2/commit/82dd2cdd4954cd7b8983d5d64c0dfd9072bf4650 which was first released as part of v1.9 by upstream. @ Arches, please test and mark stable: =dev-python/oauth2-1.9.0_p1
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please vote.
GLSA Vote: No
