Jon Oberheide j...@oberheide.org added the comment:
Sounds good to me, Nick.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14955
___
___
Python
Jon Oberheide j...@oberheide.org added the comment:
Wow, that escalated quickly. :-)
Nick, thanks for keeping things focused and on track.
To recap, the primary motivation here is two-fold. First, folks are using ==
pretty frequently in an unsafe manner when comparing digests, signatures
Jon Oberheide j...@oberheide.org added the comment:
On a side note, it may be useful to follow the conventions that already exist
in OpenBSD for their timingsafe_bcmp(3):
http://www.rootr.net/man/man/timingsafe_bcmp/3
timingsafe may be a more reasonable naming convention that is a bit less
Jon Oberheide j...@oberheide.org added the comment:
Thanks for the feedback, haypo. I've updated the patch to use unicode-internal.
As long as the encode() of the expected non-attacker-controlled digest is not
dependent on the actual contents of the digest, we should be good.
--
Added
New submission from Jon Oberheide j...@oberheide.org:
Hi all,
I was informed that the hmac.secure_compare() function added in 14532 is not
time-independent when processing unicode values:
The function as given is probably not timing independent if the attacker can
provide unicode values
Jon Oberheide j...@oberheide.org added the comment:
You should explain what you already said: it is not a risk because the
length of a HMAC is fixed.
Well, that's not entirely accurate. Exposing the length of the HMAC can expose
what underlying hash is being used (eg. HMAC-SHA1 has different
Jon Oberheide j...@oberheide.org added the comment:
Ok, patch v4 uploaded. Only change is the rename to secure_compare.
--
Added file: http://bugs.python.org/file25414/hmac-time-independent-v4.patch
___
Python tracker rep...@bugs.python.org
http
Jon Oberheide j...@oberheide.org added the comment:
I have used the name secure_compare in the past for such a function. That
said, I don't have strong feelings either way about the naming, so I'll yield
to the others.
--
___
Python tracker rep
Jon Oberheide j...@oberheide.org added the comment:
v3 patch, based on feedback from the review here:
http://bugs.python.org/review/14532/show
--
Added file: http://bugs.python.org/file25262/hmac-time-independent-v3.patch
___
Python tracker rep
Jon Oberheide j...@oberheide.org added the comment:
This is not time independent. Is it an issue?
You're correct, the length check does leak the length of the expected digest as
a performance enhancement (otherwise, your comparison runtime is bounded by the
length of the attackers input
Jon Oberheide j...@oberheide.org added the comment:
You could rewrite:
result |= x ^ y
as:
result |= (x != y)
You could, but it's best not to introduce any conditional branching based if at
all possible. For reference, see:
http://rdist.root.org/2009/05/28/timing-attack
Jon Oberheide j...@oberheide.org added the comment:
Here's a v2 patch. Changes include checking the input types via isinstance,
test cases to exercise the type checking, and a note documenting the leak of
the input length.
--
Added file: http://bugs.python.org/file25197/hmac-time
Jon Oberheide j...@oberheide.org added the comment:
In fact, it'd probably be useful to have a time_independenct_comparison()
helper function somewhere in general.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14532
Jon Oberheide j...@oberheide.org added the comment:
Ah yeah, I suppose it's not be exploitable in this case due to the challenge
nonce.
However, it might still be a good thing to fix for to set an example for other
hmac module users (internal or external) that might not have the same
Jon Oberheide j...@oberheide.org added the comment:
You call it obfuscating, I call it security correctness and developer
education. Tomayto, tomahto. ;-)
Anywho, your call of course, feel free to close.
--
___
Python tracker rep...@bugs.python.org
Jon Oberheide j...@oberheide.org added the comment:
One thing that could definitely be interesting is to look through the
code base and example to see if a similar - but vulnerable - pattern
is used, and fix such occurrences.
Based on some quick greps, I didn't see many internal users
Jon Oberheide j...@oberheide.org added the comment:
Will do!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14532
___
___
Python-bugs-list
Jon Oberheide j...@oberheide.org added the comment:
Here's a v1. Works with both str and bytes types for Python 3.x.
Not sure I'm completely happy with the docs, but I'd appreciate any feedback on
them!
--
keywords: +patch
Added file: http://bugs.python.org/file25186/hmac-time
New submission from Jon Oberheide j...@oberheide.org:
The multiprocessing module performs a time-dependent comparison of the HMAC
digest used for authentication:
def deliver_challenge(connection, authkey):
import hmac
assert isinstance(authkey, bytes)
message = os.urandom
19 matches
Mail list logo
