Re: cve requests for python-oauth2

[Kurt Seifried <kseifried () redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have some clarifying questions, see below

On 09/12/2013 11:34 AM, Seth Arnold wrote:
> Hello Kurt, all, I recently gave python-oauth2 a quick audit and
> believe it needs three CVE entries:
>
> - _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

Yeah ignoring nonces is not good. Oddly enough CWE only has CWE-323
"Reusing a Nonce, Key Pair in Encryption" there is nothing for
"completely ignored nonce". So this gets a CVE. Please use
CVE-2013-4346 for this issue.

> - _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.

I see how this can be a problem, but with proper nonces it shouldn't
be an issue on it on, correct? As such I'm leaning towards classifying
this one as security hardening.

> - 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

Yeah to quote Python random():

However, being completely deterministic, it is not suitable for all
purposes, and is completely unsuitable for cryptographic purposes.

so even with a 'random' seed can attacker could conceivably take a
sample and then brute force the original seed allowing them to predict
future values. So this would go under insufficient randomness and get
a CVE. Please use CVE-2013-4347 for this issue.

> Thanks


- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSMhxHAAoJEBYNRVNeJnmTo1MQALHLps+XJ37Nfge/ZO0lNh0F
/CbiL9rkwYRdM61kKi13H995HcGeCcjiPI+v/6GlIEWJIrtHbf8bkYA1aqQF5cvi
yb1cYQ0Q8h51q6mC57IPfx3EIRLbcHws+WzWrHYBrGz3yHzfLy9ZJs5D1CV8UHve
X18QTmU654vEIZ4GhdWQnvktzCHlZ32tigP+PD+utXPQ/sjd0C3GGVicsh1BNVyG
GB006iRrwlA1xgyyJxLXVcz24zeXFTDpHq8NQVXfj4LILAVGzyS53RWh8+FocdR0
HoUSPZfzg5N2+vt8HjjWJNdlaAW2uKijR6eNSNDF5HH3I+LuCY01sww+40IN6I+U
ncVuo1U8c4F+Nt8EjrxMJAa1DCdy0voee1yn8fQt7/doAN7yZdElaispQ0YkWqJC
HQVdz8+1k/NxrLyJQ3vKZPh6qiPIoYykRFkTUjZQJ/I5yJ2ffRP76/mNkIMsWZy2
YVMCeeZbHe7g7y56FWE6poCI7JYRGXPLWGOTioOI2RSVYGVfsyEEZAAdISKIpS9z
xw9aPZCd3IYf9ouUV+Ra85egWWvZf7VC9sESa5CCqEWX1XO0lXKR3TadzVYtK9+q
dY3ZhlaYlmZbZWlJagesCxp9KL+LYbRkw/Q+YoboLxJMaHBw2AaQsbEpK4mPAeXe
JzSDqUqrfiG4W4qpITFb
=hOZj
-----END PGP SIGNATURE-----