381569 - Offer option to include "Secure" attribute for cookies

Status: RESOLVED DUPLICATE of bug 449984

(Bugzilla :: Administration, task, P4)

Description

[Nico R.]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.3) Gecko/20070403 Firefox/2.0.0.3
Build Identifier: 

Bugzilla sends all cookies back to the User Agent without the “Secure” attribute (see RFC 2965, section 3.2.2, top of page 7) set. For example, when first browsing via HTTPS and then accidentally using HTTP in between, this allows stealing of login information for eavesdroppers.

The “Secure” attribute should be set by Bugzilla for its cookies—at least when the protocol is HTTPS and at least for the login cookie(s?).

Reproducible: Always

Steps to Reproduce:
Example using Mozilla’s Bugzilla:
1. Go to <URL:https://bugzilla.mozilla.org/index.cgi?GoAheadAndLogIn=1>.
2. Login to Bugzilla. [Your User Agent will receive Bugzilla login cookies.]
3. Start a network-monitoring tool (packet sniffer) if you like to, so you can see the effect.
4. Go to <URL:http://bugzilla.mozilla.org/> and watch your login information be sent over the wire without encryption.
Actual Results:  
Login information leaks, because it is transmitted over HTTP (unencrypted).

Expected Results:  
No leak of login cookies, because User Agent decides not to send them (because the “Secure” attribute is set on them).

See RFC 2965, section 3.2.2, top of page 7 for information about the “Secure” attribute in cookies.

Comment 1

[timeless]

this would make it hard/impossible for someone to have a bugzilla that requires secure logins but allows you to take your login cookie and use it to view the rest of the bugzilla. that's not an entirely unreasonable configuration (it should be the admin's choice).

Comment 2

[Max Kanat-Alexander]

Yeah, timeless's concern there is valid.

Comment 4

[Daniel Kahn Gillmor]

Attachment: automatically set secure attribute if "ssl" is set to "always"

I think if the administrator of the system has set "ssl" to "always", there's no reason not to set this flag (that is, the legitimate concern raised by timeless, above, is mitigated).  So i'm attaching this simple (but untested) patch as a start toward a solution.  I don't know the codebase well enough to know if Bugzilla::CGI::send_cookie() effectively wraps all cookies emitted by bugzilla, though, so i don't know if this covers all cases.

However, i don't think it can hurt.

Comment 5

[Damien Miller]

Without the patch mentioned in comment #4, Bugzilla is vulnerable to credential eavesdropping via a downgrade attack.

An attacker just needs to get their victim to make a HTTP request of a Bugzilla's non-SSL instance (e.g. via Javascript, a hidden iframe or img tag) and the Bugzilla_logincookie would be visible in the clear. 

IMO this should be treated as a security bug because it largely negates one of the protections that SSL is supposed to provide.

Comment 6

[Daniel Kahn Gillmor]

fwiw, the patch from comment #4 is no longer untested.  Damien just applied it to https://bugzilla.mindrot.org/ (which has the "ssl" param set to "always"), and it works as expected.  The cookies are issued with the secure flag.

Comment 7

[David Lawrence [:dkl]]

What is it were a separate setting on its own? Would that better address timeless' comment in commet #1? 

We have a patch for this already for our Bugzilla for the 3.0 upgrade we are working on that can be viewed at 

https://bugzilla.redhat.com/show_bug.cgi?id=429495

I was considering posting the patch for upstream review til I saw this bug and was  wondering which way would be best

Dave

Comment 8

[Bradley Baetz (:bbaetz)]

This should potentially cover the sudo cookie too.

Comment 9

[Frédéric Buclin]

(In reply to comment #8)
> This should potentially cover the sudo cookie too.

No need. The login cookie would already be secured, and the sudo cookie contains nothing useful (only the sudo'ed user ID, which isn't hard to guess).

Comment 10

[Frédéric Buclin]

This bug has finally been fixed in bug 449984.