MIME-Version: 1.0
Received: by 10.142.44.16 with HTTP; Tue, 1 Dec 2009 21:39:07 -0800 (PST)
Date: Tue, 1 Dec 2009 21:39:07 -0800
Delivered-To: coda.hale@gmail.com
Message-ID: <bc5412480912012139l40752f3el9954bfe17b621063@mail.gmail.com>
Subject: Timing attack in Rack's cookie session store
From: Coda Hale <coda.hale@gmail.com>
To: chneukirchen <chneukirchen@gmail.com>
Content-Type: text/plain; charset=UTF-8
I was looking at Rack's cookie code for a friend of mine today, and
saw that your HMAC comparison code uses a variable-time comparison
algorithm, making it vulnerable to a timing attack, e.g.
<http://github.com/rails/rails/commit/1f07a89c5946910fc28ea5ccd1da6af8a0f972a0>
<http://codahale.com/a-lesson-in-timing-attacks/>
--
Coda Hale
http://codahale.com
Delivered-To: coda.hale@gmail.com
Received: by 10.142.44.16 with SMTP id r16cs456047wfr;
Wed, 2 Dec 2009 05:12:07 -0800 (PST)
Return-Path: <chneukirchen@gmail.com>
Received-SPF: pass (google.com: domain of chneukirchen@gmail.com designates 10.142.67.6 as permitted sender) client-ip=10.142.67.6;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of chneukirchen@gmail.com designates 10.142.67.6 as permitted sender) smtp.mail=chneukirchen@gmail.com; dkim=pass header.i=chneukirchen@gmail.com
Received: from mr.google.com ([10.142.67.6])
by 10.142.67.6 with SMTP id p6mr14520wfa.20.1259759527394 (num_hops = 1);
Wed, 02 Dec 2009 05:12:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type;
bh=a6+EN+ZDkXJ8ZVo0ENcIzeo1Ux2DOjcH2DbOR3mwDw8=;
b=jT8NyQqrAn6vlrcrtq7MVoXRC/eTMzDcOvyxnw4JU7hg/IiRGlzKJa4cxVJb4YIucg
PJ0/VUUCpOvWLc4B/6AaD7QjYCaAByFV0dHyGl9lfHYfeyzSk4q2k4TKseqhPWGjxF++
rppuz+ueyca/9t2EjCkWPi8ATHIOBCXzoQqnc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
b=GjQiseY2YnzG1b6u9tWGTD0nhucxhwdluDP/OuHsHlbPXJQdyZY4OIivgtXgBeWVH9
6A1H2JCtEHBsHlEqO6oLydhwlxFGuunZpd/WU0+3vH6Vj6zsOrvJ8aPgUsdboE3znwnT
5Y2G/mgWGouM1r858exXqCCPLpspAbEb+YeXU=
MIME-Version: 1.0
Received: by 10.142.67.6 with SMTP id p6mr11939wfa.20.1259759527367; Wed, 02
Dec 2009 05:12:07 -0800 (PST)
In-Reply-To: <bc5412480912012139l40752f3el9954bfe17b621063@mail.gmail.com>
References: <bc5412480912012139l40752f3el9954bfe17b621063@mail.gmail.com>
Date: Wed, 2 Dec 2009 14:12:07 +0100
Message-ID: <e064621a0912020512w344e724ta9a2585a6d5e1c83@mail.gmail.com>
Subject: Re: Timing attack in Rack's cookie session store
From: Christian Neukirchen <chneukirchen@gmail.com>
To: Coda Hale <coda.hale@gmail.com>
Cc: rack-core@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Dec 2, 2009 at 6:39 AM, Coda Hale <coda.hale@gmail.com> wrote:
> I was looking at Rack's cookie code for a friend of mine today, and
> saw that your HMAC comparison code uses a variable-time comparison
> algorithm, making it vulnerable to a timing attack, e.g.
>
> <http://github.com/rails/rails/commit/1f07a89c5946910fc28ea5ccd1da6af8a0f972a0>
> <http://codahale.com/a-lesson-in-timing-attacks/>
In theory, this is true. However, I think the "fix" is worse than the
actual issue.
Remember that Rack::Session::Cookie uses SHA1, which generates 40-char
hexdigests.
This already reduces the possibility of a timing attack, because a
40-char comparison
is very fast (on this 3ghz P4 here):
10M a == b => true takes 9.7s here
10M a == b => false takes 8.7s here (first char different.)
Since only a single comparison is made, this equals to measuring 10
microseconds,
which is impractical over the network etc. and vanishes in sight of
the other code running anyway.
(Instantiating Rack::Request, the actual HTTP call, etc.)
On invalid HMACs the session data is cleared immediately.
Rails' secure_compare is 100x slower.
I welcome discussion on this issue.
> --
> Coda Hale
> http://codahale.com
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
MIME-Version: 1.0
Received: by 10.142.240.19 with HTTP; Wed, 2 Dec 2009 09:01:15 -0800 (PST)
In-Reply-To: <e064621a0912020512w344e724ta9a2585a6d5e1c83@mail.gmail.com>
References: <bc5412480912012139l40752f3el9954bfe17b621063@mail.gmail.com>
<e064621a0912020512w344e724ta9a2585a6d5e1c83@mail.gmail.com>
Date: Wed, 2 Dec 2009 09:01:15 -0800
Delivered-To: coda.hale@gmail.com
Message-ID: <bc5412480912020901x65a0d1d0qe64b29b5d010225f@mail.gmail.com>
Subject: Re: Timing attack in Rack's cookie session store
From: Coda Hale <coda.hale@gmail.com>
To: Christian Neukirchen <chneukirchen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Dec 2, 2009 at 5:12 AM, Christian Neukirchen
<chneukirchen@gmail.com> wrote:
> Since only a single comparison is made, this equals to measuring 10
> microseconds,
> which is impractical over the network etc. and vanishes in sight of
> the other code running anyway.
> (Instantiating Rack::Request, the actual HTTP call, etc.)
No, that's within reach of a practical attack over the internet, and
certainly over a LAN.
From Crosby et al <http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.p=
df>:
> We have shown that, even though the Internet induces significant timing j=
itter,
> we can reliably distinguish remote timing dif- ferences as low as 20=CE=
=BCs. A LAN
> environment has lower timing jitter, allowing us to reliably distinguish =
remote
> timing differences as small as 100ns (possibly even smaller). These preci=
se
> timing differences can be distinguished with only hundreds or possibly
> thousands of measurements.
I would wager that this form of statistical analysis will not get harder to=
do.
> On invalid HMACs the session data is cleared immediately.
Unless you begin to block the client's IP, that's not an effective
countermeasure. Eventually the attacker will discover all 40 bytes of
the HMAC and have a valid session, regardless of how many previous
attempts were discarded.
> Rails' secure_compare is 100x slower.
Yes, it is slower. I made no attempt to optimize it when I wrote it,
so I'm sure it can be improved. (In theory, you can make it as fast as
the strcmp of a valid HMAC.)
But if your comparison function takes less time to compare an HMAC
which has a bad last byte than it does to compare an HMAC which is
correct, you leave yourself (and all the users of Rack, whether they
know it or not) vulnerable to timing attacks.
--=20
Coda Hale
http://codahale.com
Delivered-To: coda.hale@gmail.com
Received: by 10.220.108.225 with SMTP id g33cs185785vcp;
Fri, 4 Dec 2009 11:59:03 -0800 (PST)
Received: by 10.101.11.34 with SMTP id o34mr4650432ani.25.1259956742480;
Fri, 04 Dec 2009 11:59:02 -0800 (PST)
Return-Path: <chneukirchen@gmail.com>
Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211])
by mx.google.com with ESMTP id 1si5174367ywh.125.2009.12.04.11.59.01;
Fri, 04 Dec 2009 11:59:01 -0800 (PST)
Received-SPF: pass (google.com: domain of chneukirchen@gmail.com designates 209.85.220.211 as permitted sender) client-ip=209.85.220.211;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of chneukirchen@gmail.com designates 209.85.220.211 as permitted sender) smtp.mail=chneukirchen@gmail.com; dkim=pass (test mode) header.i=@gmail.com
Received: by mail-fx0-f211.google.com with SMTP id 3so2964129fxm.4
for <coda.hale@gmail.com>; Fri, 04 Dec 2009 11:59:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:received:to:subject
:references:from:cc:date:in-reply-to:message-id:user-agent
:mime-version:content-type;
bh=QLfQ7zgTMPGhictAkjVSbtrH0hVBz7MY//2deSQVt04=;
b=htOV8XREaB+pVL8zbHxIq9TiZHDsNSzTOTt6n9Wz7icGlpf+6l7PmEqPQubs9c+k7s
YCwdTG7TrLke+KtxTIxOxm3IdUOYLmdvaxYLp9ndzdYTmFEUvzErdNLYoZL3lsZ5cHRl
tM+RMN8X3covD5eFVLa7BUXdZiv7Y6NrtAnN0=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=to:subject:references:from:cc:date:in-reply-to:message-id
:user-agent:mime-version:content-type;
b=BIVud36OA5XtJILks35GbmtaDuGGCWc1UcfNWISx5icwvzcNAaefJ9XcsBDbEQ5yyX
u5phRMj/PNxpyzkYjtR8ictSxsodDKcmBGAyB1sJw6U5E5m1Ec3PK79VUSR5y7SfLCSx
BtvIY97RJXF3EHyY3Ke99GFhOrJtYLDjN9J38=
Received: by 10.103.76.21 with SMTP id d21mr1141272mul.78.1259956740761;
Fri, 04 Dec 2009 11:59:00 -0800 (PST)
Return-Path: <chneukirchen@gmail.com>
Received: from lamia.local (p5B16A075.dip0.t-ipconnect.de [91.22.160.117])
by mx.google.com with ESMTPS id y37sm8845250mug.17.2009.12.04.11.58.57
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Fri, 04 Dec 2009 11:58:58 -0800 (PST)
Received: by lamia.local (Postfix, from userid 501)
id 4E031D1DF89; Fri, 4 Dec 2009 20:58:54 +0100 (CET)
To: Coda Hale <coda.hale@gmail.com>
Subject: Re: Timing attack in Rack's cookie session store
References: <bc5412480912012139l40752f3el9954bfe17b621063@mail.gmail.com>
<e064621a0912020512w344e724ta9a2585a6d5e1c83@mail.gmail.com>
<bc5412480912020901x65a0d1d0qe64b29b5d010225f@mail.gmail.com>
From: Christian Neukirchen <chneukirchen@gmail.com>
Cc: rack-core@googlegroups.com
Date: Fri, 04 Dec 2009 20:58:54 +0100
In-Reply-To: <bc5412480912020901x65a0d1d0qe64b29b5d010225f@mail.gmail.com> (Coda Hale's message of "Wed\, 2 Dec 2009 09\:01\:15 -0800")
Message-ID: <m2k4x2h5oh.fsf@gmail.com>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (darwin)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
[Please keep the Cc:.]
Coda Hale <coda.hale@gmail.com> writes:
>> Rails' secure_compare is 100x slower.
>
> Yes, it is slower. I made no attempt to optimize it when I wrote it,
> so I'm sure it can be improved. (In theory, you can make it as fast as
> the strcmp of a valid HMAC.)
>
> But if your comparison function takes less time to compare an HMAC
> which has a bad last byte than it does to compare an HMAC which is
> correct, you leave yourself (and all the users of Rack, whether they
> know it or not) vulnerable to timing attacks.
Yes. Some ideas on doing a comparsion that is fast and not exploitable:
(a.to_i(16) ^ b.to_i(16)).zero?
.zero? runs in constant time, to actually force ^ to do full 160-bit
operations, maybe one needs:
((a.to_i(16) | 2<<161) ^ (b.to_i(16) | 2<<161)).zero?
Comments?
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
MIME-Version: 1.0
Received: by 10.220.108.225 with HTTP; Fri, 4 Dec 2009 13:42:52 -0800 (PST)
In-Reply-To: <m2k4x2h5oh.fsf@gmail.com>
References: <bc5412480912012139l40752f3el9954bfe17b621063@mail.gmail.com>
<e064621a0912020512w344e724ta9a2585a6d5e1c83@mail.gmail.com>
<bc5412480912020901x65a0d1d0qe64b29b5d010225f@mail.gmail.com>
<m2k4x2h5oh.fsf@gmail.com>
Date: Fri, 4 Dec 2009 13:42:52 -0800
Delivered-To: coda.hale@gmail.com
Message-ID: <bc5412480912041342w3c8fef68r61a63e0148401c9e@mail.gmail.com>
Subject: Re: Timing attack in Rack's cookie session store
From: Coda Hale <coda.hale@gmail.com>
To: Christian Neukirchen <chneukirchen@gmail.com>
Cc: rack-core <rack-core@googlegroups.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Dec 4, 2009 at 11:58 AM, Christian Neukirchen
<chneukirchen@gmail.com> wrote:
> Yes. =C2=A0Some ideas on doing a comparsion that is fast and not exploita=
ble:
>
> =C2=A0(a.to_i(16) ^ b.to_i(16)).zero?
>
> .zero? runs in constant time, to actually force ^ to do full 160-bit
> operations, maybe one needs:
>
> =C2=A0((a.to_i(16) | 2<<161) ^ (b.to_i(16) | 2<<161)).zero?
>
> Comments?
It's an interesting idea, but this won't work either.
The internal representation of "00000000000000000000" as a Bignum will
be smaller than the internal representation of "FFFFFFFFFFFFFFFFFFFF":
>> ("F" * 20).to_i(16).size
=3D> 12
>> ("0" * 20).to_i(16).size
=3D> 8
Because both rb_cstr_to_inum() and rb_big_xor() call bignorm() on the
resulting values, neither the xor nor the zero check are constant-time
operations. I think this approach would defeat a simple byte-by-byte
attack, but it would still be vulnerable to more mathematically
sophisticated attacks, along the lines of Brumley and Boneh's RSA
attack[1].
[1] http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
--=20
Coda Hale
http://codahale.com
Delivered-To: coda.hale@gmail.com
Received: by 10.220.17.23 with SMTP id q23cs134218vca;
Sat, 5 Dec 2009 02:16:54 -0800 (PST)
Received: by 10.213.26.140 with SMTP id e12mr628076ebc.0.1260008213348;
Sat, 05 Dec 2009 02:16:53 -0800 (PST)
Return-Path: <jftucker@gmail.com>
Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224])
by mx.google.com with ESMTP id 21si3852698ewy.62.2009.12.05.02.16.51;
Sat, 05 Dec 2009 02:16:52 -0800 (PST)
Received-SPF: pass (google.com: domain of jftucker@gmail.com designates 209.85.219.224 as permitted sender) client-ip=209.85.219.224;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of jftucker@gmail.com designates 209.85.219.224 as permitted sender) smtp.mail=jftucker@gmail.com; dkim=pass (test mode) header.i=@gmail.com
Received: by mail-ew0-f224.google.com with SMTP id 24so3709854ewy.26
for <multiple recipients>; Sat, 05 Dec 2009 02:16:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:subject:mime-version
:content-type:from:in-reply-to:date:cc:message-id:references:to
:x-mailer;
bh=7/CHrui9eDe7K4oorVoHup2lnoxxQVdJwQaqNEEVNb4=;
b=oWgq3V0WgTYzjEHRndL4Kfj4ZvPiwJvBVBeJ+fgk+d6JnZLlwEHLux5ROKx2JJlipq
N/7rVnkR9wK5RaCBv8B3VM5hLKSObhK1ZVeimQ3OvPUGiD2g85W4U+wIvx822j+qxRR5
6uUZCLUOyyDp6l53wKkUOm3bk4K33344oEnQ8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=subject:mime-version:content-type:from:in-reply-to:date:cc
:message-id:references:to:x-mailer;
b=pxhwkaj6QlJWlNdfvii9cy75mmdNPzgsWaTDkVnxBRyi2QUl6W0D4l4R4al8NCw4jC
D2VgqXoBAUS0NCS9Ua8oJJuGRhuzU3KbmiJsJ8vNbQHlfP+w8LncwFMnbIAemaN3EUex
WmHDtbY0C5UvvZB+UD7o7aTY9p+5PmIl/kWmk=
Received: by 10.216.89.70 with SMTP id b48mr252931wef.160.1260008211083;
Sat, 05 Dec 2009 02:16:51 -0800 (PST)
Return-Path: <jftucker@gmail.com>
Received: from ?192.168.1.107? (bb-87-81-237-21.ukonline.co.uk [87.81.237.21])
by mx.google.com with ESMTPS id i6sm8624431gve.1.2009.12.05.02.16.48
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Sat, 05 Dec 2009 02:16:49 -0800 (PST)
Subject: Re: Timing attack in Rack's cookie session store
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/signed; boundary=Apple-Mail-1-380650656; protocol="application/pkcs7-signature"; micalg=sha1
From: James Tucker <jftucker@gmail.com>
In-Reply-To: <bc5412480912041342w3c8fef68r61a63e0148401c9e@mail.gmail.com>
Date: Sat, 5 Dec 2009 10:16:48 +0000
Cc: Christian Neukirchen <chneukirchen@gmail.com>
Message-Id: <F8B04289-F603-4BDC-BD97-94CBC31EA8B1@gmail.com>
References: <bc5412480912012139l40752f3el9954bfe17b621063@mail.gmail.com> <e064621a0912020512w344e724ta9a2585a6d5e1c83@mail.gmail.com> <bc5412480912020901x65a0d1d0qe64b29b5d010225f@mail.gmail.com> <m2k4x2h5oh.fsf@gmail.com> <bc5412480912041342w3c8fef68r61a63e0148401c9e@mail.gmail.com>
To: rack-core@googlegroups.com,
Coda Hale <coda.hale@gmail.com>
X-Mailer: Apple Mail (2.1077)
--Apple-Mail-1-380650656
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 4 Dec 2009, at 21:42, Coda Hale wrote:
> On Fri, Dec 4, 2009 at 11:58 AM, Christian Neukirchen
> <chneukirchen@gmail.com> wrote:
>> Yes. Some ideas on doing a comparsion that is fast and not =
exploitable:
>>=20
>> (a.to_i(16) ^ b.to_i(16)).zero?
>>=20
>> .zero? runs in constant time, to actually force ^ to do full 160-bit
>> operations, maybe one needs:
>>=20
>> ((a.to_i(16) | 2<<161) ^ (b.to_i(16) | 2<<161)).zero?
>>=20
>> Comments?
>=20
> It's an interesting idea, but this won't work either.
>=20
> The internal representation of "00000000000000000000" as a Bignum will
> be smaller than the internal representation of "FFFFFFFFFFFFFFFFFFFF":
>=20
>>> ("F" * 20).to_i(16).size
> =3D> 12
>>> ("0" * 20).to_i(16).size
> =3D> 8
>=20
> Because both rb_cstr_to_inum() and rb_big_xor() call bignorm() on the
> resulting values, neither the xor nor the zero check are constant-time
> operations. I think this approach would defeat a simple byte-by-byte
> attack, but it would still be vulnerable to more mathematically
> sophisticated attacks, along the lines of Brumley and Boneh's RSA
> attack[1].
Are any of these attacks practically viable after running through a ruby =
VM and other rack operations?
Sorry, the viability of these attacks would require that 'background =
noise' is less significant than the timing issue. Ruby, being a VHLL, =
has certain factors (even on faster / smaller implementations) that make =
some of these things extremely difficult, possibly provably impossible, =
especially on current interpreters and hardware.
>=20
> [1] http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
>=20
> --=20
> Coda Hale
> http://codahale.com
--Apple-Mail-1-380650656
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJljCCBEYw
ggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEw
KjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYw
EQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwz
LTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAi
hiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC
YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55uuUMc
YL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV67APpp8z
hZrTcY5Qj5ndYjCCBUgwggQwoAMCAQICECeMlak0fpR8Io4+aS7PnaswDQYJKoZIhvcNAQEFBQAw
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0w
OTExMjAwMDAwMDBaFw0xMDExMjAyMzU5NTlaMIIBETEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsT
FVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0
c2NhcGUgRnVsbCBTZXJ2aWNlMRUwEwYDVQQDFAxKYW1lcyBUdWNrZXIxITAfBgkqhkiG9w0BCQEW
EmpmdHVja2VyQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOAB6yX/
8ziknn0eW8pEvxNyz16y+pkpvHXtm09QNWS9UpWuyq2j1HDDW91sLqcla79IxYDGjRuuerfVLuFw
16lvZyENeb+NoajnA1Paow+taYqKuSQMNVjVFiy2ZPcZREKFOUUB+GkYLz6ErZ/2CB8esdB11Xya
r/S2/8Qm3VM4xwaAf0Thq5zKimnkM+yXZEicYV8Ny+IxnxDMEvzolqJVdfMGnlbhcv1LFj96Rt9v
kuV/J4lpmDTP1SXlIqprPFD4rC8Q54ktnhBjZt4jQkQ/RRE3f4GhnACpomSzjmw99Com6gT1/YaL
tT00yCMwCxrGxgYT8em2XZ79HaIpW20CAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDsw
OQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw
YTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEw
P6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRh
bElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEALH+Csg+lKzykCtckS9T/1M/b2LYbn1egArQeg1WN
cj2xWet7/4eM+nnswKcQNYgDOI8hb6dwkB/aPPR/D9buUyQZzSeCoXFEpnAMFGcp5q2mxELBjHiu
toKCBAKYjV9X8kcJYnW6ypJG+9UOL8JXEYU42i16UAQCizljT+lubYefVudNKNzpcTPbGJ0lF0zh
q/HN5lEPBAhJsj8P79zMy96YQdLNli0ulVDwdv761+kyCtZlV3bBtQM9YHXBArUDC0Dr3ByzkrBG
rKvVf+VmRXf82ytatHKNGantVZ51jhKTBylmm0OqVI/ZIS/IzGtKcTlakp91R5EuLI4NY6RKgjGC
BIswggSHAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzICECeMlak0fpR8Io4+aS7PnaswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMjA1MTAxNjQ4WjAjBgkqhkiG9w0BCQQxFgQU
4c/1iaks4wTUXc2TaY2GcXw4/OUwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQJ4yVqTR+lHwijj5pLs+dqzCC
AQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m
IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz
b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT
dWJzY3JpYmVyIENBIC0gRzICECeMlak0fpR8Io4+aS7PnaswDQYJKoZIhvcNAQEBBQAEggEAcI85
EMSkEd6YLihH+xnMSjkq0wuKxaCmtl72ITKyXEC2veoU0DwYqKMO/DcfdG74YqCUXPDSMaQFiRGL
6xg3Qtt11/z6KSVOslKIYl4o0vfOzO98p2qNMLHJ7QKgv8rMoBFjkYgrkoHamDZ7BovtWxs8cEE0
GZLT5W5ypcnZpOmRMgTt8FjSWrBkpW2W6PMA+sUo7z0u3Ank5YvFaQwqAJJzfbD1lKBy1ys7d2yn
D3Mho/JOtWrb3/ridLeI3dLfUdNVMCv6FTAP2KzxSix6NMtsH/B5Pe5Cb74s0Cy4eFGhMobAHJiT
YZjPDF43mVk6LTOi8Cqpu7xgri7ZPPgB9gAAAAAAAA==
--Apple-Mail-1-380650656--
MIME-Version: 1.0
Received: by 10.220.17.23 with HTTP; Sat, 5 Dec 2009 08:40:24 -0800 (PST)
In-Reply-To: <F8B04289-F603-4BDC-BD97-94CBC31EA8B1@gmail.com>
References: <bc5412480912012139l40752f3el9954bfe17b621063@mail.gmail.com>
<e064621a0912020512w344e724ta9a2585a6d5e1c83@mail.gmail.com>
<bc5412480912020901x65a0d1d0qe64b29b5d010225f@mail.gmail.com>
<m2k4x2h5oh.fsf@gmail.com>
<bc5412480912041342w3c8fef68r61a63e0148401c9e@mail.gmail.com>
<F8B04289-F603-4BDC-BD97-94CBC31EA8B1@gmail.com>
Date: Sat, 5 Dec 2009 08:40:24 -0800
Delivered-To: coda.hale@gmail.com
Message-ID: <bc5412480912050840u15a6b272u32a463c060647362@mail.gmail.com>
Subject: Re: Timing attack in Rack's cookie session store
From: Coda Hale <coda.hale@gmail.com>
To: James Tucker <jftucker@gmail.com>
Cc: rack-core <rack-core@googlegroups.com>,
Christian Neukirchen <chneukirchen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Dec 5, 2009 at 2:16 AM, James Tucker <jftucker@gmail.com> wrote:
> Are any of these attacks practically viable after running through a ruby =
VM and other rack operations?
Absolutely.
> Sorry, the viability of these attacks would require that 'background nois=
e' is less significant than the timing issue. Ruby, being a VHLL, has certa=
in factors (even on faster / smaller implementations) that make some of the=
se things extremely difficult, possibly provably impossible, especially on =
current interpreters and hardware.
That's not the case.
From Crosby et al <http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.p=
df>:
> We have shown that, even though the Internet induces significant timing j=
itter,
> we can reliably distinguish remote timing differences as low as 20=CE=BCs=
. A LAN
> environment has lower timing jitter, allowing us to reliably distinguish =
remote
> timing differences as small as 100ns (possibly even smaller). These preci=
se
> timing differences can be distinguished with only hundreds or possibly
> thousands of measurements.
The Java security team recently patched a timing attack I reported to
them about exactly the same thing --
<http://java.sun.com/javase/6/webnotes/6u17.html> -- and the JVM is
substantially more complex in terms of runtime characteristics.
Nate Lawson found a similar vulnerability in Keyczar, a cryptographic
library for Python and Java --
<http://groups.google.com/group/keyczar-discuss/browse_thread/thread/5571ec=
a0948b2a13/7d0f902722a520d9?lnk=3Dgst>
-- and Python's VM is on the same order of complexity as Ruby's.
It doesn't matter if the application runs on machine code, inside a
VM, or inside a JIT-optimizing VM. It doesn't matter if it allocates
20 bytes of memory or 200 MB. All that matters is that whatever
portion of that time is spent verifying the HMAC can be correlated
with the contents of the HMAC.
Given that information, the rest is just a matter of sample size and analys=
is.
--=20
Coda Hale
http://codahale.com
Delivered-To: coda.hale@gmail.com
Received: by 10.220.17.23 with SMTP id q23cs142528vca;
Sat, 5 Dec 2009 15:18:48 -0800 (PST)
Received: by 10.213.38.200 with SMTP id c8mr5017692ebe.59.1260055127987;
Sat, 05 Dec 2009 15:18:47 -0800 (PST)
Return-Path: <jftucker@gmail.com>
Received: from mail-ew0-f220.google.com (mail-ew0-f220.google.com [209.85.219.220])
by mx.google.com with ESMTP id 25si7141273ewy.25.2009.12.05.15.18.46;
Sat, 05 Dec 2009 15:18:46 -0800 (PST)
Received-SPF: pass (google.com: domain of jftucker@gmail.com designates 209.85.219.220 as permitted sender) client-ip=209.85.219.220;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of jftucker@gmail.com designates 209.85.219.220 as permitted sender) smtp.mail=jftucker@gmail.com; dkim=pass (test mode) header.i=@gmail.com
Received: by mail-ew0-f220.google.com with SMTP id 20so2394151ewy.20
for <coda.hale@gmail.com>; Sat, 05 Dec 2009 15:18:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:from:mime-version
:content-type:subject:date:in-reply-to:to:references:message-id
:x-mailer;
bh=eF+auSMrlXIfisCavSoc92qYozPp+/yhkAx6ZJ+JeLI=;
b=XlljB178BOT+oBSWkngNLyAaBPhgJP8x88y4bklgTFoezuTg9Ax7V3zvGdmIEd86b4
ga4P6MLP1fXNxh1/6izImftV9X19pR9ohPu0oyOsriYdAVye/y7hjzXQvz8DFDnwyaiN
raa2UpBzGiOYHA5OKZALUR9cCKcfrseBVuYyQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=from:mime-version:content-type:subject:date:in-reply-to:to
:references:message-id:x-mailer;
b=suTQXwqjK8RhUHCDXLIcu9KiSyD0Z1jgQFh8fB0y9gz55TTnt7m6xTEkPkWxScwsdO
ABQwLr+yC3owsAgNT0oAdlAMWKnkdSKZytbZjccE5xOF5nqsMoh6BdiSKpwKlmJRaraz
wIQzh98DRliHXc1foefjk8eNE/25G5ZtSotBE=
Received: by 10.216.86.131 with SMTP id w3mr1585035wee.156.1260055123906;
Sat, 05 Dec 2009 15:18:43 -0800 (PST)
Return-Path: <jftucker@gmail.com>
Received: from ?192.168.1.107? (bb-87-81-237-21.ukonline.co.uk [87.81.237.21])
by mx.google.com with ESMTPS id t2sm9974999gve.24.2009.12.05.15.18.41
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Sat, 05 Dec 2009 15:18:42 -0800 (PST)
From: James Tucker <jftucker@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/signed; boundary=Apple-Mail-1-427562650; protocol="application/pkcs7-signature"; micalg=sha1
Subject: Re: Timing attack in Rack's cookie session store
Date: Sat, 5 Dec 2009 23:18:40 +0000
In-Reply-To: <bc5412480912050840u15a6b272u32a463c060647362@mail.gmail.com>
To: Coda Hale <coda.hale@gmail.com>
References: <bc5412480912012139l40752f3el9954bfe17b621063@mail.gmail.com> <e064621a0912020512w344e724ta9a2585a6d5e1c83@mail.gmail.com> <bc5412480912020901x65a0d1d0qe64b29b5d010225f@mail.gmail.com> <m2k4x2h5oh.fsf@gmail.com> <bc5412480912041342w3c8fef68r61a63e0148401c9e@mail.gmail.com> <F8B04289-F603-4BDC-BD97-94CBC31EA8B1@gmail.com> <bc5412480912050840u15a6b272u32a463c060647362@mail.gmail.com>
Message-Id: <8E64E8B8-386F-497B-B59A-2165E2BC143A@gmail.com>
X-Mailer: Apple Mail (2.1077)
--Apple-Mail-1-427562650
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 5 Dec 2009, at 16:40, Coda Hale wrote:
> On Sat, Dec 5, 2009 at 2:16 AM, James Tucker <jftucker@gmail.com> =
wrote:
>> Are any of these attacks practically viable after running through a =
ruby VM and other rack operations?
>=20
> Absolutely.
>=20
>> Sorry, the viability of these attacks would require that 'background =
noise' is less significant than the timing issue. Ruby, being a VHLL, =
has certain factors (even on faster / smaller implementations) that make =
some of these things extremely difficult, possibly provably impossible, =
especially on current interpreters and hardware.
>=20
> That's not the case.
>=20
> =46rom Crosby et al =
<http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf>:
>> We have shown that, even though the Internet induces significant =
timing jitter,
>> we can reliably distinguish remote timing differences as low as =
20=CE=BCs. A LAN
>> environment has lower timing jitter, allowing us to reliably =
distinguish remote
>> timing differences as small as 100ns (possibly even smaller). These =
precise
>> timing differences can be distinguished with only hundreds or =
possibly
>> thousands of measurements.
>=20
> The Java security team recently patched a timing attack I reported to
> them about exactly the same thing --
> <http://java.sun.com/javase/6/webnotes/6u17.html> -- and the JVM is
> substantially more complex in terms of runtime characteristics.
>=20
> Nate Lawson found a similar vulnerability in Keyczar, a cryptographic
> library for Python and Java --
> =
<http://groups.google.com/group/keyczar-discuss/browse_thread/thread/5571e=
ca0948b2a13/7d0f902722a520d9?lnk=3Dgst>
> -- and Python's VM is on the same order of complexity as Ruby's.
>=20
> It doesn't matter if the application runs on machine code, inside a
> VM, or inside a JIT-optimizing VM. It doesn't matter if it allocates
> 20 bytes of memory or 200 MB. All that matters is that whatever
> portion of that time is spent verifying the HMAC can be correlated
> with the contents of the HMAC.
>=20
> Given that information, the rest is just a matter of sample size and =
analysis.
I didn't find proof of your answer in any of the links you provided, =
sorry.
>=20
> --=20
> Coda Hale
> http://codahale.com
--Apple-Mail-1-427562650
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJljCCBEYw
ggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEw
KjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYw
EQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwz
LTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAi
hiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC
YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55uuUMc
YL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV67APpp8z
hZrTcY5Qj5ndYjCCBUgwggQwoAMCAQICECeMlak0fpR8Io4+aS7PnaswDQYJKoZIhvcNAQEFBQAw
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0w
OTExMjAwMDAwMDBaFw0xMDExMjAyMzU5NTlaMIIBETEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsT
FVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0
c2NhcGUgRnVsbCBTZXJ2aWNlMRUwEwYDVQQDFAxKYW1lcyBUdWNrZXIxITAfBgkqhkiG9w0BCQEW
EmpmdHVja2VyQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOAB6yX/
8ziknn0eW8pEvxNyz16y+pkpvHXtm09QNWS9UpWuyq2j1HDDW91sLqcla79IxYDGjRuuerfVLuFw
16lvZyENeb+NoajnA1Paow+taYqKuSQMNVjVFiy2ZPcZREKFOUUB+GkYLz6ErZ/2CB8esdB11Xya
r/S2/8Qm3VM4xwaAf0Thq5zKimnkM+yXZEicYV8Ny+IxnxDMEvzolqJVdfMGnlbhcv1LFj96Rt9v
kuV/J4lpmDTP1SXlIqprPFD4rC8Q54ktnhBjZt4jQkQ/RRE3f4GhnACpomSzjmw99Com6gT1/YaL
tT00yCMwCxrGxgYT8em2XZ79HaIpW20CAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDsw
OQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw
YTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEw
P6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRh
bElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEALH+Csg+lKzykCtckS9T/1M/b2LYbn1egArQeg1WN
cj2xWet7/4eM+nnswKcQNYgDOI8hb6dwkB/aPPR/D9buUyQZzSeCoXFEpnAMFGcp5q2mxELBjHiu
toKCBAKYjV9X8kcJYnW6ypJG+9UOL8JXEYU42i16UAQCizljT+lubYefVudNKNzpcTPbGJ0lF0zh
q/HN5lEPBAhJsj8P79zMy96YQdLNli0ulVDwdv761+kyCtZlV3bBtQM9YHXBArUDC0Dr3ByzkrBG
rKvVf+VmRXf82ytatHKNGantVZ51jhKTBylmm0OqVI/ZIS/IzGtKcTlakp91R5EuLI4NY6RKgjGC
BIswggSHAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzICECeMlak0fpR8Io4+aS7PnaswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMjA1MjMxODQwWjAjBgkqhkiG9w0BCQQxFgQU
zlA9YGDDJxQZDugOxBkJfEXwlNcwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQJ4yVqTR+lHwijj5pLs+dqzCC
AQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m
IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz
b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT
dWJzY3JpYmVyIENBIC0gRzICECeMlak0fpR8Io4+aS7PnaswDQYJKoZIhvcNAQEBBQAEggEAItuk
+lu2mVeBsVC47xAd3qodEBOuA8r6EAbzys/AEKgR23WwuYgiMte9uxDJGkrnW2co/3mUHrzTx2cq
xNzOHiRiFndYdFeZNN0iTctQNnxGXnJuDIMqHjMhzTWAjQjVBUIkasLeXAzc5oVRUrBdszVPC+qR
RrILkp3w8z++yqSiDs91GNi70z7ch3z9HPVCT1qsiDiN3NgmT0Bo1scfEeIPqiFgmjYxYXMRnwnv
a1chOdLBBQqStofh+wh+/ZaJVG5/Xp/frEnIl9f1+3pEpI5qJJGNjBzEqAUbGNZeQqvLXdF0sujs
swtna8GoBkZNURZdv2tSQFyiZThEOnPztQAAAAAAAA==
--Apple-Mail-1-427562650--
Delivered-To: coda.hale@gmail.com
Received: by 10.220.17.23 with SMTP id q23cs143072vca;
Sat, 5 Dec 2009 15:46:32 -0800 (PST)
Received: by 10.213.25.76 with SMTP id y12mr4434037ebb.26.1260056791832;
Sat, 05 Dec 2009 15:46:31 -0800 (PST)
Return-Path: <jftucker@gmail.com>
Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226])
by mx.google.com with ESMTP id 2si15952037ewy.8.2009.12.05.15.46.30;
Sat, 05 Dec 2009 15:46:30 -0800 (PST)
Received-SPF: pass (google.com: domain of jftucker@gmail.com designates 209.85.219.226 as permitted sender) client-ip=209.85.219.226;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of jftucker@gmail.com designates 209.85.219.226 as permitted sender) smtp.mail=jftucker@gmail.com; dkim=pass (test mode) header.i=@gmail.com
Received: by mail-ew0-f226.google.com with SMTP id 26so4348060ewy.23
for <coda.hale@gmail.com>; Sat, 05 Dec 2009 15:46:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:from:mime-version
:content-type:subject:date:in-reply-to:to:references:message-id
:x-mailer;
bh=ZA3O52TBhTQFzQLZiUNx7pzbETFQmn7hLetnd4hu+8M=;
b=S25DILqbLIAOu+WZQyj9dbrDH5t/B0QoXLrCEQQrY1Lwd6E/UvxL3BmK+k11aHPUDe
A8fJAcjLq2SrWW2ry1qeNYiwscGSkpA01rxyIn1F+WqbtxcyvM5fNonhZxtdlEIBh131
4ApJ97QlRhqpcMttfeJ9YAfmcNZ4K+Z6oOeaE=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=from:mime-version:content-type:subject:date:in-reply-to:to
:references:message-id:x-mailer;
b=SRINfPWgrKGzYhkpXkPcf+HLrzL6f3msjK/rK7ePJgsXCESVVP6Cz2TTwKBng2HuU1
iOTnahLdhiU1Q/pLNJJYc7HbltNAYGp+4ClApEtAf96mp1G0s0SLdvnTKVoeLenMKQtd
zK7ZrfbGjZANzBTwjGx5RP8OajKCYc7PNVC0A=
Received: by 10.216.87.133 with SMTP id y5mr1789061wee.139.1260056790072;
Sat, 05 Dec 2009 15:46:30 -0800 (PST)
Return-Path: <jftucker@gmail.com>
Received: from ?192.168.1.107? (bb-87-81-237-21.ukonline.co.uk [87.81.237.21])
by mx.google.com with ESMTPS id t12sm10034305gvd.20.2009.12.05.15.46.27
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Sat, 05 Dec 2009 15:46:28 -0800 (PST)
From: James Tucker <jftucker@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/signed; boundary=Apple-Mail-1-429228410; protocol="application/pkcs7-signature"; micalg=sha1
Subject: Re: Timing attack in Rack's cookie session store
Date: Sat, 5 Dec 2009 23:46:26 +0000
In-Reply-To: <bc5412480912050840u15a6b272u32a463c060647362@mail.gmail.com>
To: Coda Hale <coda.hale@gmail.com>
References: <bc5412480912012139l40752f3el9954bfe17b621063@mail.gmail.com> <e064621a0912020512w344e724ta9a2585a6d5e1c83@mail.gmail.com> <bc5412480912020901x65a0d1d0qe64b29b5d010225f@mail.gmail.com> <m2k4x2h5oh.fsf@gmail.com> <bc5412480912041342w3c8fef68r61a63e0148401c9e@mail.gmail.com> <F8B04289-F603-4BDC-BD97-94CBC31EA8B1@gmail.com> <bc5412480912050840u15a6b272u32a463c060647362@mail.gmail.com>
Message-Id: <B2A0A9D3-D314-43F4-9AA3-0DD8337E3C89@gmail.com>
X-Mailer: Apple Mail (2.1077)
--Apple-Mail-1-429228410
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 5 Dec 2009, at 16:40, Coda Hale wrote:
> On Sat, Dec 5, 2009 at 2:16 AM, James Tucker <jftucker@gmail.com> =
wrote:
>> Are any of these attacks practically viable after running through a =
ruby VM and other rack operations?
>=20
> Absolutely.
>=20
>> Sorry, the viability of these attacks would require that 'background =
noise' is less significant than the timing issue. Ruby, being a VHLL, =
has certain factors (even on faster / smaller implementations) that make =
some of these things extremely difficult, possibly provably impossible, =
especially on current interpreters and hardware.
>=20
> That's not the case.
>=20
> =46rom Crosby et al =
<http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf>:
>> We have shown that, even though the Internet induces significant =
timing jitter,
>> we can reliably distinguish remote timing differences as low as =
20=CE=BCs. A LAN
>> environment has lower timing jitter, allowing us to reliably =
distinguish remote
>> timing differences as small as 100ns (possibly even smaller). These =
precise
>> timing differences can be distinguished with only hundreds or =
possibly
>> thousands of measurements.
>=20
> The Java security team recently patched a timing attack I reported to
> them about exactly the same thing --
> <http://java.sun.com/javase/6/webnotes/6u17.html> -- and the JVM is
> substantially more complex in terms of runtime characteristics.
>=20
> Nate Lawson found a similar vulnerability in Keyczar, a cryptographic
> library for Python and Java --
> =
<http://groups.google.com/group/keyczar-discuss/browse_thread/thread/5571e=
ca0948b2a13/7d0f902722a520d9?lnk=3Dgst>
> -- and Python's VM is on the same order of complexity as Ruby's.
>=20
> It doesn't matter if the application runs on machine code, inside a
> VM, or inside a JIT-optimizing VM. It doesn't matter if it allocates
> 20 bytes of memory or 200 MB. All that matters is that whatever
> portion of that time is spent verifying the HMAC can be correlated
> with the contents of the HMAC.
>=20
> Given that information, the rest is just a matter of sample size and =
analysis.
Sorry, I had more of a read, and a think about how the exploit would be =
implemented, and it started to make more sense how the variation from =
other portions of the system becomes insignificant over a sufficient =
sample size; sorry for the noise.
With regard to the fix, it's an unfortunate penalty we're going to have =
to pay, and might be something we should consider asking for in ruby.
>=20
> --=20
> Coda Hale
> http://codahale.com
--Apple-Mail-1-429228410
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJljCCBEYw
ggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEw
KjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYw
EQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwz
LTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAi
hiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC
YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55uuUMc
YL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV67APpp8z
hZrTcY5Qj5ndYjCCBUgwggQwoAMCAQICECeMlak0fpR8Io4+aS7PnaswDQYJKoZIhvcNAQEFBQAw
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0w
OTExMjAwMDAwMDBaFw0xMDExMjAyMzU5NTlaMIIBETEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsT
FVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0
c2NhcGUgRnVsbCBTZXJ2aWNlMRUwEwYDVQQDFAxKYW1lcyBUdWNrZXIxITAfBgkqhkiG9w0BCQEW
EmpmdHVja2VyQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOAB6yX/
8ziknn0eW8pEvxNyz16y+pkpvHXtm09QNWS9UpWuyq2j1HDDW91sLqcla79IxYDGjRuuerfVLuFw
16lvZyENeb+NoajnA1Paow+taYqKuSQMNVjVFiy2ZPcZREKFOUUB+GkYLz6ErZ/2CB8esdB11Xya
r/S2/8Qm3VM4xwaAf0Thq5zKimnkM+yXZEicYV8Ny+IxnxDMEvzolqJVdfMGnlbhcv1LFj96Rt9v
kuV/J4lpmDTP1SXlIqprPFD4rC8Q54ktnhBjZt4jQkQ/RRE3f4GhnACpomSzjmw99Com6gT1/YaL
tT00yCMwCxrGxgYT8em2XZ79HaIpW20CAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDsw
OQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw
YTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEw
P6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRh
bElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEALH+Csg+lKzykCtckS9T/1M/b2LYbn1egArQeg1WN
cj2xWet7/4eM+nnswKcQNYgDOI8hb6dwkB/aPPR/D9buUyQZzSeCoXFEpnAMFGcp5q2mxELBjHiu
toKCBAKYjV9X8kcJYnW6ypJG+9UOL8JXEYU42i16UAQCizljT+lubYefVudNKNzpcTPbGJ0lF0zh
q/HN5lEPBAhJsj8P79zMy96YQdLNli0ulVDwdv761+kyCtZlV3bBtQM9YHXBArUDC0Dr3ByzkrBG
rKvVf+VmRXf82ytatHKNGantVZ51jhKTBylmm0OqVI/ZIS/IzGtKcTlakp91R5EuLI4NY6RKgjGC
BIswggSHAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzICECeMlak0fpR8Io4+aS7PnaswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMjA1MjM0NjI2WjAjBgkqhkiG9w0BCQQxFgQU
XLHBpJSgzuvMm3cWe2Iy0CrbYFowggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQJ4yVqTR+lHwijj5pLs+dqzCC
AQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m
IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz
b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT
dWJzY3JpYmVyIENBIC0gRzICECeMlak0fpR8Io4+aS7PnaswDQYJKoZIhvcNAQEBBQAEggEAEU0h
PlhJelM5SP5n/OLAGnQu8rFmI/VTsXKh5CITuTL7corl/WokjTFwRJEVpivFsIAU2qJq6/Lg9enQ
SXDQdO9eC5+B5Orskcx5/kIGqfQNaUNk3iRenKvpRWEAnt83VEI2kMo6EqwLtGcvtbOW2gWduoG6
SO6Lzba3dmwZ2mghZJurss+Pq08OEqd94QgvXGxTsN68MQ8RPHzN0M9bY5PeQl19x+J2/d9fxqlm
tY5QdeSaU1yR3xLafiuS6wBTDTW2tqL8jTd3ET9BiNH6jOO8IsAFUgVxfqsoyrxnx7Z/uec/MOWs
ZsUaLwyb/SwN0dMINlGJ1xQ5yRBd8lqoaQAAAAAAAA==
--Apple-Mail-1-429228410--
MIME-Version: 1.0
Received: by 10.220.17.23 with HTTP; Sat, 5 Dec 2009 16:29:56 -0800 (PST)
In-Reply-To: <B2A0A9D3-D314-43F4-9AA3-0DD8337E3C89@gmail.com>
References: <bc5412480912012139l40752f3el9954bfe17b621063@mail.gmail.com>
<e064621a0912020512w344e724ta9a2585a6d5e1c83@mail.gmail.com>
<bc5412480912020901x65a0d1d0qe64b29b5d010225f@mail.gmail.com>
<m2k4x2h5oh.fsf@gmail.com>
<bc5412480912041342w3c8fef68r61a63e0148401c9e@mail.gmail.com>
<F8B04289-F603-4BDC-BD97-94CBC31EA8B1@gmail.com>
<bc5412480912050840u15a6b272u32a463c060647362@mail.gmail.com>
<B2A0A9D3-D314-43F4-9AA3-0DD8337E3C89@gmail.com>
Date: Sat, 5 Dec 2009 16:29:56 -0800
Delivered-To: coda.hale@gmail.com
Message-ID: <bc5412480912051629n7e83bb58mc93c785c5cad3825@mail.gmail.com>
Subject: Re: Timing attack in Rack's cookie session store
From: Coda Hale <coda.hale@gmail.com>
To: James Tucker <jftucker@gmail.com>
Cc: rack-core <rack-core@googlegroups.com>,
Christian Neukirchen <chneukirchen@gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sat, Dec 5, 2009 at 3:46 PM, James Tucker <jftucker@gmail.com> wrote:
> With regard to the fix, it's an unfortunate penalty we're going to have to pay, and might be something we should consider asking for in ruby.
You have my sympathies, and I'd support a better HMAC library for
Ruby. All of the timing attacks involving HMACs that I've seen are the
direct consequence of standard libraries treating the MAC as a string
or array of bytes as opposed to an object or data type in its own
right, with specific semantics like constant-time comparison. It's a
failure of encapsulation.
--
Coda Hale
http://codahale.com
Delivered-To: coda.hale@gmail.com
Received: by 10.220.17.23 with SMTP id q23cs164229vca;
Sun, 6 Dec 2009 15:31:38 -0800 (PST)
Received: by 10.213.97.27 with SMTP id j27mr7300682ebn.64.1260142297208;
Sun, 06 Dec 2009 15:31:37 -0800 (PST)
Return-Path: <jftucker@gmail.com>
Received: from mail-ew0-f223.google.com (mail-ew0-f223.google.com [209.85.219.223])
by mx.google.com with ESMTP id 2si20719557ewy.28.2009.12.06.15.31.35;
Sun, 06 Dec 2009 15:31:36 -0800 (PST)
Received-SPF: pass (google.com: domain of jftucker@gmail.com designates 209.85.219.223 as permitted sender) client-ip=209.85.219.223;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of jftucker@gmail.com designates 209.85.219.223 as permitted sender) smtp.mail=jftucker@gmail.com; dkim=pass (test mode) header.i=@gmail.com
Received: by mail-ew0-f223.google.com with SMTP id 23so2942426ewy.4
for <coda.hale@gmail.com>; Sun, 06 Dec 2009 15:31:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:from:mime-version
:content-type:subject:date:in-reply-to:to:references:message-id
:x-mailer;
bh=6zYvbLC13SrvdAFu1UxN0iKLOKSR7t6G/wXtZDevxRo=;
b=v5do3WFxRtBM40QB1hZ1dTkqdMF88Qcc8K2NiFjPszEGxXehHGhT86KSH8uhHIDAsJ
Ob6+VNdZ6J4kBRrvsRdIFBAXNsu9OJLqOw4lKgdqFSmtwxjZP6kznyVPC5gNTtgSTpXk
xLKB1fvGwfzKxpSs3+VESxWRq67DVFG+/KSEA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=from:mime-version:content-type:subject:date:in-reply-to:to
:references:message-id:x-mailer;
b=HIwowyeHMnU5SJUxk3wWblb+Eh1Sym4fz72xD7exb3amd71ahw8itCbUrzWjH9SWIn
z8Ikgd6+U/dA81j7t8P6P7axicrj5q1jjOApf3053IG5oW5/24CKLjgjDLZaXsVgQcFr
s2+BS5r9fEg+nR75PELwKUP0GidsDreq8gX8I=
Received: by 10.216.89.5 with SMTP id b5mr2173673wef.143.1260142295054;
Sun, 06 Dec 2009 15:31:35 -0800 (PST)
Return-Path: <jftucker@gmail.com>
Received: from ?192.168.1.107? (bb-87-81-237-21.ukonline.co.uk [87.81.237.21])
by mx.google.com with ESMTPS id g9sm12002304gvc.10.2009.12.06.15.31.32
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Sun, 06 Dec 2009 15:31:33 -0800 (PST)
From: James Tucker <jftucker@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/signed; boundary=Apple-Mail-1-514733498; protocol="application/pkcs7-signature"; micalg=sha1
Subject: Re: Timing attack in Rack's cookie session store
Date: Sun, 6 Dec 2009 23:31:31 +0000
In-Reply-To: <bc5412480912051629n7e83bb58mc93c785c5cad3825@mail.gmail.com>
To: Coda Hale <coda.hale@gmail.com>
References: <bc5412480912012139l40752f3el9954bfe17b621063@mail.gmail.com> <e064621a0912020512w344e724ta9a2585a6d5e1c83@mail.gmail.com> <bc5412480912020901x65a0d1d0qe64b29b5d010225f@mail.gmail.com> <m2k4x2h5oh.fsf@gmail.com> <bc5412480912041342w3c8fef68r61a63e0148401c9e@mail.gmail.com> <F8B04289-F603-4BDC-BD97-94CBC31EA8B1@gmail.com> <bc5412480912050840u15a6b272u32a463c060647362@mail.gmail.com> <B2A0A9D3-D314-43F4-9AA3-0DD8337E3C89@gmail.com> <bc5412480912051629n7e83bb58mc93c785c5cad3825@mail.gmail.com>
Message-Id: <D99FC304-21DC-45CC-867D-8399FD1010F6@gmail.com>
X-Mailer: Apple Mail (2.1077)
--Apple-Mail-1-514733498
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 6 Dec 2009, at 00:29, Coda Hale wrote:
> On Sat, Dec 5, 2009 at 3:46 PM, James Tucker <jftucker@gmail.com> =
wrote:
>> With regard to the fix, it's an unfortunate penalty we're going to =
have to pay, and might be something we should consider asking for in =
ruby.
>=20
> You have my sympathies, and I'd support a better HMAC library for
> Ruby. All of the timing attacks involving HMACs that I've seen are the
> direct consequence of standard libraries treating the MAC as a string
> or array of bytes as opposed to an object or data type in its own
> right, with specific semantics like constant-time comparison. It's a
> failure of encapsulation.
Agreed. In the meantime, +1 on the patch, unless there's any way we can =
get it faster.
>=20
> --=20
> Coda Hale
> http://codahale.com
--Apple-Mail-1-514733498
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJljCCBEYw
ggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEw
KjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYw
EQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwz
LTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAi
hiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC
YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55uuUMc
YL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV67APpp8z
hZrTcY5Qj5ndYjCCBUgwggQwoAMCAQICECeMlak0fpR8Io4+aS7PnaswDQYJKoZIhvcNAQEFBQAw
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0w
OTExMjAwMDAwMDBaFw0xMDExMjAyMzU5NTlaMIIBETEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsT
FVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0
c2NhcGUgRnVsbCBTZXJ2aWNlMRUwEwYDVQQDFAxKYW1lcyBUdWNrZXIxITAfBgkqhkiG9w0BCQEW
EmpmdHVja2VyQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOAB6yX/
8ziknn0eW8pEvxNyz16y+pkpvHXtm09QNWS9UpWuyq2j1HDDW91sLqcla79IxYDGjRuuerfVLuFw
16lvZyENeb+NoajnA1Paow+taYqKuSQMNVjVFiy2ZPcZREKFOUUB+GkYLz6ErZ/2CB8esdB11Xya
r/S2/8Qm3VM4xwaAf0Thq5zKimnkM+yXZEicYV8Ny+IxnxDMEvzolqJVdfMGnlbhcv1LFj96Rt9v
kuV/J4lpmDTP1SXlIqprPFD4rC8Q54ktnhBjZt4jQkQ/RRE3f4GhnACpomSzjmw99Com6gT1/YaL
tT00yCMwCxrGxgYT8em2XZ79HaIpW20CAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDsw
OQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw
YTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEw
P6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRh
bElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEALH+Csg+lKzykCtckS9T/1M/b2LYbn1egArQeg1WN
cj2xWet7/4eM+nnswKcQNYgDOI8hb6dwkB/aPPR/D9buUyQZzSeCoXFEpnAMFGcp5q2mxELBjHiu
toKCBAKYjV9X8kcJYnW6ypJG+9UOL8JXEYU42i16UAQCizljT+lubYefVudNKNzpcTPbGJ0lF0zh
q/HN5lEPBAhJsj8P79zMy96YQdLNli0ulVDwdv761+kyCtZlV3bBtQM9YHXBArUDC0Dr3ByzkrBG
rKvVf+VmRXf82ytatHKNGantVZ51jhKTBylmm0OqVI/ZIS/IzGtKcTlakp91R5EuLI4NY6RKgjGC
BIswggSHAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzICECeMlak0fpR8Io4+aS7PnaswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMjA2MjMzMTMxWjAjBgkqhkiG9w0BCQQxFgQU
VoA9e0FqBcQgQQSjGlFsH13DyP4wggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQJ4yVqTR+lHwijj5pLs+dqzCC
AQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m
IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz
b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT
dWJzY3JpYmVyIENBIC0gRzICECeMlak0fpR8Io4+aS7PnaswDQYJKoZIhvcNAQEBBQAEggEAjR11
oE3SZiijjSpBHJdWDHuXejGM+5bz+yjGIBPCcbdwmxc01FZ6CA/JWYkhpWsGSM9Gs2Qj1O15V/1a
U1Hf3sp230dRhALWzVyAJOD9rl2EcqgvIuUp6XM8l6bCwM4zJ7Pji2iae/0WzcbYHzMI+6Hxqnbm
fks74TS9IIOFSXPPFC/g6BY4/SRIbyMnTkLP8FEnm24IYLrkZ5+vmShj8r7nzjh5SAP8xn+nzP4c
Ls3DRxEcYgUcGhQuT3rWJ3R10/G52cRegyBbu0FsU8QWIY5VRKvLdnqqpp+mPdPpCd2XBl9e7mRP
LrYyWX8n5bKmFBjAzNThsmjmo2cA5/C6GAAAAAAAAA==
--Apple-Mail-1-514733498--
