449974 - AMO cookies don't specify "secure" connections, potentially hackable

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Administration, defect)

Description

[Daniel Veditz [:dveditz]]

Mike Perry gave a talk at Defcon 16 about using spoofed http (insecure) connections to steal auth cookies from normally-secure sites. Even if a site is only available over SSL and redirects any plain HTTP connection attempts, if the cookies themselves don't contain the "secure" flag a victim who forgets to specify http_s_ could be hijacked to a fake AMO site that steals their cookies. This is probably pretty common, with people entering just addons.mozilla.org out of natural laziness and letting browser magic supply http:// and then redirect to https://.

Mike sent the following to [e-mail]:
  I'm doing a presentation on grabbing insecure https cookies at Defcon:
  http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Perry
  http://seclists.org/bugtraq/2007/Aug/0070.html

  The majority of the details of the issue are in that bugtraq link.

  I've noticed that the cookies on addons.mozilla.org ... are
  not marked for encrypted sessions only. This
  means that these cookies can be hijacked by attackers on the local
  network, via Dan Kaminsky's DNS poisoning attack, or via injection
  onto a cable modem network (a cable modem packet injection technique
  was also presented at this DEFCON).

  This is particularly dangerous ... where some extension developers
  are given 'trusted' status. An attacker can
  target one of these users and push out a malicious Firefox extension
  to tens or even hunderds of thousands of users before being noticed.

Comment 1

[Daniel Veditz [:dveditz]]

This is not just a theoretical danger, we have seen targeted attacks against trusted mozilla developers on other services. Post Defcon the knowledge of this general weakness is now public, and only about half the DNS servers are patched against Kaminsky's flaw it's a reasonable chance someone will think of those in combination with AMO and see what they can do (Firefox is an obvious high profile target). This should be fixed ASAP.

Comment 3

[Michael Morgan [:morgamic]]

Taking, not sure fligtar is around.

Comment 4

[Michael Morgan [:morgamic]]

Attachment: v1, changes session secure bit to true by default

Comment 5

[Laura Thomson :laura]

Comment on attachment 333132 [details] [diff] [review]
v1, changes session secure bit to true by default

WFM

Comment 6

[Michael Morgan [:morgamic]]

Do you know if subsequent calls of setcookie() will have secure as true?

Comment 7

[Laura Thomson :laura]

Is there some reason not to hard set session.cookie_secure to true in php.ini?

Comment 8

[Michael Morgan [:morgamic]]

Not really, since the entire site is SSL.

Comment 9

[Laura Thomson :laura]

Then let's do it, and we should be gold.

Comment 10

[Michael Morgan [:morgamic]]

; Cookies should only be sent via https.
session.cookie_secure = true 

This needs to be set in php.ini.  I'll file an IT bug for this (can't reassign/switch components without losing security flag).

Comment 11

[Michael Morgan [:morgamic]]

Bug 449989

Comment 12

[Michael Morgan [:morgamic]]

This should be fixed.  We:
* hard-coded session.cookie_secure = true in php.ini
* restarted everything on the php5 cluster
* nuked all pre-existing sessions
* used tamper data to watch traffic/cookies
* loaded http://addons.mozilla.org
* did not see the AMOv3 auth cookie present in the page headers

Comment 13

[Daniel Veditz [:dveditz]]

People who previously got an AMOv3 cookie (logged in with the "remember me" box checked) do not automatically get their cookies upgraded to secure. Looks like the cookie expires in two weeks so some users will be insecure until then, unless they log out and back in or otherwise clear their cookies.

Is there a way to tell the site to forget every currently logged-in session to force everyone to log in again? I imagine the session IDs must be stored in a table somewhere that could be erased, right? Or you could change the code to use an AMOv3a cookie which no one is going to have.

Comment 14

[Michael Morgan [:morgamic]]

That's why we truncated the cake_sessions table.  Their cookies still exist client-side but won't permit a valid session without reauthentication.  During reactivation their session will be assigned a new sessid.

Comment 15

[Michael Morgan [:morgamic]]

(In reply to comment #12)
> This should be fixed.  We:
> * nuked all pre-existing sessions

Comment 16

[Michael Morgan [:morgamic]]

I double checked this and it does require login after truncating that table even if you used 'remember me'.

Comment 17

[Daniel Veditz [:dveditz]]

ah thanks... I missed the significance of that bit and naively tested myself by logging in, removing the secure flag from the cookie manually, and then testing whether it would reset the cookie to secure at any point. But if the sessions got killed on the server side that ought to fix it, we don't need to worry about people who do manual cookie hacking.

Since the talk was public and this is now fixed we should open up the bug. Especially since AMO was apparently one of the examples used in the talk (hey Mike: next time please give us more than a hour or two notice)