

Amazon Web Services signature version 1 is insecure - cperciva
http://www.daemonology.net/blog/2008-12-18-AWS-signature-version-1-is-insecure.html

======
tlrobinson
Perhaps it's just late and my mind is tired, but it took me a minute to
understand what was going on. Maybe a simpler example would be helpful.

Since the delimiters are removed before computing the signature (so each is
just "ABCDEFGHIJLM"), the signatures for the following two query strings are
the same:

    
    
        ?A=B&C=D&E=FHIJKLM
    
        ?A=B&C=D&E=F&H=I&J=K&L=M
    

So if the value of of the E parameter is controlled by the user, they can
construct a value ("HIJKLM") such that the resulting signatures is the same as
the signature for a query with a bunch of additional parameters they choose
("H=I&J=K&L=M").

Clever.

------
jgrahamc
This is a lovely reminder that designing cryptographic protocols is hard. Even
something as simple as signing a bit of data can have nasty pitfalls.

~~~
cperciva
I wouldn't say that this shows that designing cryptographic protocols is hard.
"Use hashing and signature methods which don't have collisions" is a simple
rule, both to remember and to apply -- no harder than "drive on the right side
of the road" (or "drive on the left side of the road", depending on your
country).

Would you say that driving is hard because people have to remember which side
of the road to drive on?

~~~
tptacek
If there were 40 sides of the road to choose from, and the side you drove on
depended on the time of day and the color of your car, then yes, Colin, I
would say driving on the correct side of the road would be hard too.

Have you ever, in your whole career, worked with a team that wrote their own
crypto and got it right in version 1? Because I haven't.

~~~
cperciva
_Have you ever, in your whole career, worked with a team that wrote their own
crypto and got it right in version 1? Because I haven't._

As far as I know, I got the crypto right in tarsnap. If I didn't, please let
me know. :-)

~~~
tptacek
I don't think you really answered my question, Colin; I think that's a cop-out
answer. =)

~~~
cperciva
Maybe I misunderstood your question. I thought that "as far as I know, I got
the crypto right in [product where I wrote my own crypto protocols]" was a
pretty clear answer to "have you ever written your own crypto and gotten it
right?"

~~~
tptacek
I was asking if you'd ever worked with a team of (other, I implied
unsuccessfully) developers who got a cryptosystem right on the first try.

~~~
cperciva
Ok, that explains it. I didn't catch the fact that you were excluding the
degenerate case of a one-person team. :-)

~~~
tptacek
I also assumed you'd like your own stuff. But, now that we understand each
other: was that an answer to my original question?

~~~
cperciva
I believe I got the crypto right in version 1 of tarsnap, but I wasn't working
as part of a (non-degenerate) team. I've never done crypto with a team -- so
my answer to your (clarified) question must be a vacuous "no".

~~~
tptacek
But you've worked _against_ a couple teams now that got it wrong (Amazon,
OpenSSL). Do you agree that the evidence supports my argument?

~~~
cperciva
Not really, no. Amazon screwed up on a well-known widely-understood rule;
there aren't 40 different sides of the road involved with "hash collisions are
bad".

Similarly, the one _cryptographic_ complaint I have about OpenSSL (as opposed
to non-cryptographic security bugs) is their lack of attention to side
channels, and the same applies here -- we KNOW that side channels are bad. The
fact that the OpenSSL developers haven't made any systematic attempt to
prevent them doesn't mean that cryptography is hard; it just means that the
OpenSSL developers are careless.

~~~
brl
That's an interesting criticism of OpenSSL. Do you know of a general purpose
cryptographic library that has done a better job than OpenSSL at hardening
against side-channel attacks?

By default, OpenSSL has: RSA blinding, constant time montgomery
multiplication, careful review and correction of the conditional branches
which were attacked in that amazing series of branch prediction papers.

Doesn't seem to me that OpenSSL developers are careless and indifferent about
side-channel attacks.

~~~
cperciva
_Do you know of a general purpose cryptographic library that has done a better
job than OpenSSL at hardening against side-channel attacks?_

No, I don't know of any better cryptographic library. (This is why I said a
few days ago that writing a better cryptographic library was something I'd
like to do if I was rich.)

 _Doesn't seem to me that OpenSSL developers are careless and indifferent
about side-channel attacks._

They're playing whack-a-mole. There are over a thousand conditional branches
in the large integer arithmetic code alone. The fact that nobody has pointed
out how to exploit them yet doesn't mean that they're not exploitable.

------
jamess
Does it worry anyone else that there seems to be no protection provided
against replaying any particular authenticated request? If I were using this
service, I'd heavily recommend restricting non-https requests to read-only
operations. Any updates or deletes should be done using a security protocol
proofed against replay attacks, like HTTPS.

~~~
cperciva
At least in the case of SimpleDB, replaying requests is usually not a problem
-- if you Put or Delete an attribute which has already been Put or Deleted, it
has no effect.

~~~
jamess
Sorry, but you aren't thinking like a security professional here. Consider the
case, e.g., where you create a domain, delete it and recreate it. An attacker
monitoring the deletion can with impunity wipe out your data at a later date.

~~~
cperciva
I did say "usually". :-)

 _An attacker monitoring the deletion can with impunity wipe out your data at
a later date._

Only within the next 15 minutes. Beyond that point, AWS will reject the
request for having excess clock skew.

~~~
jamess
Ew! They use the timestamp parameter for that? That's both sick and wrong.
Requiring people who access your webservice to have an accurate clock is the
most braindead thing I've heard this month, at least. Oh boy, network
congestion and clock skew could combine to produce some wonderful heisenbugs
for developers. And for what? The want of nonce? Some ridiculous design
principle of making your API totally state free. _sigh_

~~~
cperciva
State-free protocols are useful when the server side is distributed and
potentially disconnected. :-)

As for "wonderful heisenbugs" -- the AWS services return a clear "hey, your
clock is broken" error, so it wouldn't be very hard to developers to figure
out what was going on.

------
cperciva
This is interesting: I submitted this article both here and to
programming.reddit.com; but at the same time as becoming the top story on
news.yc, it got voted down on reddit (well, 1 up vote, 2 down votes).

I wonder if this is just the random luck of who happened to see the post on
reddit first, or if news.ycers are innately more interested in security-
related stories than programming.redditers.

~~~
Freaky
Seems to be doing better on the netsec subreddit. +8, no downvotes in an hour,
vs +4-8 in 11 hours on progit

~~~
cperciva
Aha, that explains why I've been seeing traffic from reddit in my logs for the
past two hours -- thanks for resubmitting it to the more appropriate
subreddit.

------
tptacek
Example #489643876834 of why you, a very smart, very capable developer, should
not be writing crypto code. Rule #1: if you have to type the letters A-E-S or
S-H-A into your code, _you're doing it wrong_.

~~~
brl
There are pretty big mistakes to be made on the other side of this philosophy
as well. If you need to solve some cryptographic problem which is not exactly
the same as something which has already been designed, implemented, and
reviewed by competent cryptographers, then you essentially need to create a
new protocol and accept all the pitfalls which that entails.

PGP seems to be a popular 'primitive' to try to roll your own broken crypto
protocol out of.

Exhibit A: <http://enigform.mozdev.org/>

Exhibit B: <http://web.monkeysphere.info/>

Even SSL/TLS is not easy to use correctly (while understanding all the risks)
for purposes other than what it was originally designed for: Preventing credit
card numbers from being sniffed between a browser and a web merchant.

~~~
tptacek
Design a transport security protocol that is different in some way from TLS,
and a good chunk of those differences are going to be vulnerabilities that the
TLS designers figured out that you missed.

SSLv1 may have been originally designed for securing credit cards, but I'm not
sure that argument survives a close read of TLS; why waste time with mutual
authentication, with forward secrecy, with a custom record layer, with
arbitrary length certificate signing chains, etc etc etc. You might be
surprised at the number of systems that leverage TLS successfully on ports
other than 443.

We probably agree; no matter how you choose to implement crypto security in a
system, you're probably worse off for trying.

~~~
brl
Forward secrecy was one of the important mistakes I had in mind actually. If
you use TLS naively, you have none. You probably didn't even realize you
needed it.

Verifying certificates correctly is not so easy to get right either, if you
can even figure out what PKI means for your particular application in the
first place.

~~~
tptacek
Certificates are a lot like git branching. They're intimidating if you
consider them in their entirety, but simple if you stick to your old use
cases.

Enterprise apps make good use of certificates. A common use case is to set up
a private CA (a three-line shell script) and issue internal certs to all
endpoints in a system; you can then do crypto-strong access control just by
checking signatures. This is approximately to PKI what "using git just like
you used Subversion" is to git.

Another place where TLS has been a huge win is in wireless security; EAP-TLS
with mutual certificate auth is the de facto corporate wireless security
standard now.

------
there
i believe flickr's api uses the same method of creating signatures.

~~~
cperciva
I just looked at the flickr API documentation, and it looks like you're right
-- maybe that's where Amazon got the idea from. I'm not sure if it's a problem
in flickr's case, but I'll send them an email pointing out the possible
problem.

