155768 - solo.nordea.fi - unable to login to service (problem with cookies)

Status: VERIFIED FIXED

(Tech Evangelism Graveyard :: Other, defect)

Description

[Ere Maijala (slow)]

Solo banking service worked fine using the trunk build from 2nd July, but is
broken in 20020703. Complains about temporary cookies not working. The english
version is available at
https://solo3.nordea.fi/cgi-bin/SOLO0001?A01Y_LANF=3&A01Y_MASTER=1. Can be
tested using customer number 123456 and password 1111.

Comment 1

[Tuukka Tolvanen (sp3000)]

linux trunk cvs 2002-07-04:

"Http error 404: Session control information missing. Temporary session Cookie
usage is required." (error web page)

Same result if accepting all cookies or only from originating site.

wfm with 2002-06-21-08-trunk.

Comment 2

[Ere Maijala (slow)]

Also works with 20020702, so it has been broken between these two builds. There
seems to be a checkin of some cookie fix yesterday.

Comment 3

[Marc Boullet]

Yes. bug #155114 unfortunately not accessible

Comment 4

[Stephen P. Morse]

It's accessible to me.  I'll investigate.

Comment 5

[Stephen P. Morse]

The RFC2109 cookie spec section 4.3.2 states the conditions under which a 
set-cookie request shall be rejected.  Namely:

> 4.3.2 Rejecting Cookies

> To prevent possible security or privacy violations, a user agent rejects
> a cookie (shall not store its information) if any of the following is true: 
>
>   * The value for the Path attribute is not a prefix of the request-URI.

This particular site is attempting to set the cookie SoloSessionMac with a path 
attribute and requesting URI as follows:

   path attribute: /cgi-bin/S4zRggxhEm
   requesting URI: /cgi-bin

So the site is attempting to set a cookie for a path that it does not control, 
and the browser is wise to reject it.  That is one part of the patch for the 
security bug 155114 that you cannot see.

Unfortunately, this rule has never been enforced before by any version of 
mozilla, nor by N4.x, nor by IE.  So suddenly we are breaking sites that are 
setting bad cookies and, IMO, deserve to be broken.  Depending on the number and 
importance of the sites broken, we might either (1) consider this as an 
evengalism issue and tell the sites to fix their cookies, or (2) back off part 
of the security patch and allow sites to set such potentionally-hostile 
cookies.  I will raise this issue in bug 155114.

Comment 6

[Stephen P. Morse]

Marking this as a security-sensitive bug since it involves other bugs that are 
security-sensitive.

Comment 7

[Ere Maijala (slow)]

Considering this particular service (I think there might be others broken too)
this is a serious problem for Finnish users (and possibly also Swedish etc.) as
I believe the amount of Solo users is hundreds of thousands in many countries.
If it's not possible to back out this part of the patch, I'd give the user a
possibility to accept the cookie (a dialog perhaps). 

Comment 8

[Daniel Veditz [:dveditz]]

In bug 155114 you said IE was not vulnerable to the attack, but this site
clearly works with IE. What would we have to relax to get this site working,
while still preventing the attack as IE does? If we can do that it might be good
enough, and be guaranteed compatibility with most of the web.

Comment 9

[Stephen P. Morse]

Dan, see my comments in bug 155114 comment 15.

As I explained there, there are issues with both setting of cookies and the 
getting of cookies.  The attack in bug 155114 was based on the getting of 
cookies.  The breaking of this website is based on the setting of cookies.

IE is not respecting RFC 2109 regarding the setting of cookies, which is why 
they are not breaking this site.  They are respecting it regardig the getting of 
cookies, which is why they are not vulnerable to the attack in bug 155114.

Comment 10

[Ere Maijala (slow)]

Is there any progress regarding this in bug 155114? I'm asking because I can't
access that one and this problem is a blocker bug for me.

Comment 11

[Stephen P. Morse]

That bug report is currently concerned with what we land on the branch (which 
will be the Netscape 7 product) and is leaning toward landing the part of the 
patch for the getting of cookies only.  That way we will plug the security hole 
in the Netscape product while not breaking any more sites that we don't know 
about.

However the feeling is that we keep the full patch on the trunk since that 
brings us into conformance with the standard, and see if we get reports of any 
other broken sites.  If it is only this one site that is broken, then this is 
probably best handled as an evangelism issue -- i.e., explain to the site 
webmaster that there is an error on his site and ask him to correct it. 

Comment 12

[Stephen P. Morse]

The decision was made to back out part of the bug 155114 patch on the branch 
only.  Actually that patch was a composite patch for two bugs (the other being 
bug 155083), and it was the 155083 part that was backed out.

This will remain on the trunk however, and is now an evangelism issue.  
Reassigning.

Comment 13

[Stephen P. Morse]

Really reassigning this time.

Comment 14

[Ere Maijala (slow)]

Hmm.. does this still need to be security-sensitive?

I've sent a query to Nordea about the issue. They don't seem to publish email
addresses, but feedback can be given through their web pages. 

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

Note: while the RFC says this is a security issue, it certainly isn't a major
one, if it's really one at all.  Setting a path in the cookie that's deeper than
the current URL isn't actually dangerous; setting it with a shallower one could
also be dangerous (think about setting a cookie for my.hosting.service/ from
my.hosting.service/~evil_user/index.html - if my.hosting.service/~good_user keys
off the cookie for the wrong things, someone accessing ~good_user might cause
~good_user's page to mis-behave or even send data to the wrong person).

What I imagine they were worried about was my.hosting.service setting the cookie
for my.hosting.service/~someones_dir.  However, generally someone who has access
to parent directories of URL's has more control, not less, so I don't see this
as a true security issue.

In the example from bug 155114, if mywebpage.netscape.com/stephen sets a cookie
for path mywebpage.netscape.com/stephen/pictures, it really isn't any form of
security hole that I can see.  It only would be a security hole if it let you
set a cookie for mywebpage.netscape.com/stephenmpmorse.  So I think the RFC is
overly paranoid.  (BTW, if IE and NS4 allowed this, what about the attack I just
mentioned?  Do they allow it, or do they require deeper paths to have a '/'
after the current path?)

Is this really true, BTW?

   path attribute: /cgi-bin/S4zRggxhEm
   requesting URI: /cgi-bin

Requesting URI seems unlikely to be just "/cgi-bin".  I'd think it was more
likely /cgi-bin/something, and the /something was stripped before
cookie_pathOK() was called.  This makes me wonder if the requesting URI was
actually /cgi-bin/S4zRggxhEm, and because of the stripping we're getting it wrong.

i.e. someone should verify that this really is a non-implemented RFC issue, and
not a bug.

Comment 16

[Ere Maijala (slow)]

Part of me hopes that this is a bug in Mozilla, and the other part would be
ashamed if it is ;/ Though, if it's a bug where something is stripped from the
uri, why wouldn't it bite other sites?

Comment 17

[Stephen P. Morse]

I can no longer access this site -- it appears to be down.

However I just made a checkin for bug 155114 which I believe will fix this 
problem.  So I'm marking this as wfm.  If I'm mistaken and it is still a 
problem, then please reopen.

Comment 18

[Ere Maijala (slow)]

The site is up and still doesn't work for me (build from cvs done after seeing
that comment). Reopening.

Comment 19

[Ere Maijala (slow)]

The service works again using the latest nightly (2002072008). Tested after I
noticed the changes were backed out. Is this temporary? Anyway, resolving at
least for now.

Comment 20

[Stephen P. Morse]

Addressing the question in comment 15, my posting in comment 5 was in error, 
(although the bottom line was the same).  The correct values for this site are:

 path attribute: /cgi-bin/S0LDzy3yj2/

 requestin URI /cgi-bin/SOLO0001

So this site will be broken once the patch for bug 155114 is put back in because 
it violates the RFC2109 spec.  That will have to be addressed as an evangelism 
issue (unless this site is considered so important that we have to abandon out 
spec-checking because of it).

Reoponing this bug report because we know it will break, unless we want to be 
more conservative in our patch for bug 155114.

Comment 21

[Ere Maijala (slow)]

Great :( I've sent a message to Nordea about it.

Repeating myself: Does this still need to be security-sensitive?

Comment 22

[Stephen P. Morse]

Patch for bug 155114 has been subdivided into two patches.  The part of that 
patch that will break the finish site is now in bug 155083

Comment 23

[Ere Maijala (slow)]

Stephen, could you cc me on those bugs?

Comment 24

[Stephen P. Morse]

*** Bug 158261 has been marked as a duplicate of this bug. ***

Comment 25

[Jacek Piskozub]

-> Europe: West (Finland belongs there in Mozilla tech evangelism)

Comment 26

[Stephen P. Morse]

*** Bug 167654 has been marked as a duplicate of this bug. ***

Comment 27

[Ere Maijala (slow)]

Received a message from Nordea today. They are going to try to fix it, but also
say that they feel Mozilla is too strict in this case.  

Comment 28

[Ere Maijala (slow)]

*** Bug 168673 has been marked as a duplicate of this bug. ***

Comment 29

[Stephen P. Morse]

*** Bug 169538 has been marked as a duplicate of this bug. ***

Comment 30

[Stephen P. Morse]

*** Bug 170347 has been marked as a duplicate of this bug. ***

Comment 31

[Kalle Valo]

*** Bug 171641 has been marked as a duplicate of this bug. ***

Comment 32

[Stephen P. Morse]

Patch for bug 155083 has been backed out.  This site should now be working

Comment 33

[Ere Maijala (slow)]

Incidentally, solo.nordea.fi was also fixed this morning. 

Comment 34

[Brant Gurganus]

VERIFIED FIXED 2002120508

Comment 35

[Bob Clary [:bc] (inactive)]

resolved euro west non-.com url bugs to other