Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20140509040453.GA27044@openwall.com>
Date: Fri, 9 May 2014 08:04:53 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Defeating memory comparison timing oracles

Hi,

Florian made this nice Red Hat security blog post a couple of days ago:

https://securityblog.redhat.com/2014/05/07/defeating-memory-comparison-timing-oracles/

The idea is to harden glibc's memcmp(3) to be partially timing-safe,
maybe only in the -D_FORTIFY_SOURCE=2 mode.

While I don't mind having memcmp(3) sometimes hardened, I think we
primarily need to have an explicit timing-safe memory comparison
function in glibc and elsewhere, and I think it'd be natural to adopt
OpenBSD's timingsafe_bcmp() prototype and semantics:

http://www.openbsd.org/cgi-bin/man.cgi?query=timingsafe_bcmp

People will need this very function e.g. when making LibReSSL portable:

http://insanecoding.blogspot.com/2014/04/common-libressl-porting-mistakes.html

Some good reading on the problem and possible solutions:

http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/
http://rdist.root.org/2010/08/05/optimized-memcmp-leaks-useful-timing-differences/
http://rdist.root.org/2010/11/09/blackhat-2010-video-on-remote-timing-attacks/

https://www.isecpartners.com/blog/2011/february/double-hmac-verification.aspx

Alexander

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.