271194 - When going from a secure to a non-secure page without clicking a button in the security dialog, the non-secure page appears as secure

Status: VERIFIED FIXED

(Core :: Security: PSM, defect)

Description

[Tristor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

First of all, for reproducability, you must have it set so that links from other
applications open in the same window /and/ the same tab, and you must have the
dialog boxes that tell you when you go between secure and non-secure pages
turned on.

I went to http://gmail.com and then switched windows back to IRC and clicked on
a link in chat (http://www.mslinux.com) and then switched back to Firefox. 
After the page had loaded, I clicked okay on the dialog box.  Upon doing this,
the address bar went yellow/gold and the padlock appeared in the corner, even
though the page was not secure.  At Jesse Ruderman's recommendation, I am going
to classify this as a security bug.

I have reproduced 5 times, just to confirm that it happens every time.  I will
attach a screenshot.

I see a possibility that this could be used to spoof a secure site, when it is
not, and garner passwords, ect.  Although I am not sure exactly how that would
be pulled off.

Reproducible: Always
Steps to Reproduce:
1. Make sure you meet the requirements to reproduce I noted above
2. Goto http://gmail.com and make sure not to click anything on the security dialog
3. Switch windows to something else
4. Click a link in the secondary app
5. Switch back to Firefox
6. Click okay on the dialog
Actual Results:  
The address bar goes yellow/gold and the padlock appears in the lower left
corner as if the site were secure using https.

Expected Results:  
Regardless of which button on the dialog the user pushes, it should detect that
it's no longer on a secure site (https) and forego making the changes in
appearance that would indicate security.

Comment 1

[Tristor]

Attachment: My screenshot of the bug in action

This is a screenshot I took on the 3rd reproduction of the bug, I will be
following with a post of a screenshot taken by esteban from #bs in Moznet, who
also reproduced the bug with a different non-secure site as the second site.

Comment 2

[Tristor]

Attachment: This is a screenshot that esteban linked me to after he reproduced the bug. This is using his homepage which is also non-secure.

<esteban> http://quaddro.net/~esteban/firefoxbug.PNG
<esteban> that was from double clicking on the lock in the bottom right

After following the steps for reproduction I mentioned in #bs, esteban came up
with this screenshot, which shows that when the lock is double-clicked, it
shows that the page is encrypted in that dialog, even though it is obviously
not.

Comment 3

[Jesse Ruderman]

Attachment: demonstrates how a web page could exploit this hole

As long as you haven't turned off the "Warn me when entering secure sites"
dialog, clicking the link in this page is sufficient to spoof an insecure site
as being secure.

Comment 4

[Jesse Ruderman]

I can reproduce this bug using Firefox 1.0 on WinXP (using the testcase).

Comment 5

[Wolf [:wolf]]

I can reproduce in both
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
-- and --
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

Comment 6

[Jesse Ruderman]

Attachment: demonstrates how a web page could exploit this hole

Same demo, but with www.mozilla.org as the second URL instead of
www.google.com.  www.google.com is bad for this demo because it redirects if
you're not in the US.

Comment 7

[Tristor]

A note on the second testcase, I had issues with the popup blocker keeping it
from opening mozilla.org, and it would just bring up paypal.  On my third try
with it, after turning the popup blocker off, I reproduced with the second testcase.

Comment 8

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225
Firefox/1.0.1

Using a clean profile, the bug still exists somewhat within 1.0.1  Using the
testcases provided, and using my method of reproduction, the websites will show
the padlock in the corner as before, and the yellow address bar as before,
however, the site itself will not render, the page comes up blank.  I don't
consider the bug completely fixed, but I don't see it as a true security threat
anymore, since 1.0.1 causes a new behavior.

Comment 9

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217

Does not reproduce in Mozilla 1.7.5, using either testcase, or my method

Comment 10

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050322
Firefox/1.0+

Retesting using the latest nightly and a clean profile, does not reproduce
following my steps for reproduction, but does reproduce when using the first
testcase. 

Comment 11

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050402
Firefox/1.0+

Retesting using latest-trunk.  I can still reproduce this using the first testcase.

Comment 12

[Tristor]

My steps to reproduce as reported no longer appear to be valid, however both the
first and second testcase attachments made by Jesse still work.  I do want to
make the note that this reproduces exactly as described on trunk builds, but on
1.0.1 Milestone, the page does not render at all when using the testcases or my
method of reproduction.  

New Steps to Reproduce:

1. Click on either testcase
2. Click okay on both security dialogs
3. See Google/Mozilla.org become 'secure'

Comment 13

[Daniel Veditz [:dveditz]]

Still a problem on the trunk (as Tristor notes), Suite in addition to Firefox,
over to Core.

In 1.0.3 the final result to the testcases above is the URL bar showing
http://www.mozilla.org with the lock icon, but the page contents go blank.
Clicking the lock icon (trunk or branch) shows "Connection not verified" so deep
down we know we shouldn't be showing the locked state.

Comment 14

[Tristor]

(In reply to comment #13)
> Still a problem on the trunk (as Tristor notes), Suite in addition to Firefox,
> over to Core.
> 
> In 1.0.3 the final result to the testcases above is the URL bar showing
> http://www.mozilla.org with the lock icon, but the page contents go blank.
> Clicking the lock icon (trunk or branch) shows "Connection not verified" so deep
> down we know we shouldn't be showing the locked state.


On Trunk it does in fact show content (on last check, I can check in the latest
nightly, was planning to wait until the first of May to comment on this again)
with the lock icon and the status bar color change still, I am not sure what was
different between Trunk and 1.0.2 Milestone that caused the difference that then
carried over to 1.0.3 Milestone.  Let me go run and test this real fast again in
Trunk and report back.

Comment 15

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050426
Firefox/1.0+

Still reproduces on latest trunk as originally shown, as I thought.  Behavior is
as you described in 1.0.3. 

Comment 16

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050521
Firefox/1.0+

WFM?  Daniel, do you still see this in Trunk, it appears that following the
steps using the testcase no longer reproduces this in 0521.  I am not going to
mark this, I will let you do it, but I want to wait until after all the complete
breakage from 281988 has passed by.  

When using the first testcase, clicking the link opened a new windows and went
almost immediately to Google, none of the secure UI features were displayed at
all, I am hoping this has been fixed (accidentally or otherwise) by something
else, since that would absolutely make my day.

Comment 17

[Jesse Ruderman]

I can still reproduce using the testcase from comment 6.  Remember that
security.warn_entering_secure must be true for the exploit to work.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050521
Firefox/1.0+

Comment 18

[Kai Engert (:KaiE:)]

This seems to be tricky to reproduce, I can not reproduce on Linux using Mozilla
1.7.7

But I guess I understand,
I guess the problem happens, when loading of two URL loads overlap.

Displaying the warning dialog box delays the first load. And the second URL load
is initiated while we are still waiting.

The tracking code in mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp
is probably not aware of such overlapping.

If it is indeed possible that progress messages for separate loads do overlap,
the security state tracking must be changed to be more robust.

Comment 19

[Tristor]

(In reply to comment #18)
> This seems to be tricky to reproduce, I can not reproduce on Linux using Mozilla
> 1.7.7
> 
> But I guess I understand,
> I guess the problem happens, when loading of two URL loads overlap.
> 
> Displaying the warning dialog box delays the first load. And the second URL load
> is initiated while we are still waiting.
> 
> The tracking code in mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp
> is probably not aware of such overlapping.
> 
> If it is indeed possible that progress messages for separate loads do overlap,
> the security state tracking must be changed to be more robust.
> 


That sounds about right.  It never occurs if people turn off the security boxes
(which most people do) so it would be a low likelihood that it would be
exploited, but for people who keep the security warnings turned on for whatever
reason (I do), it does occur seemingly at random.  I don't believe I have ever
got this to reproduce on Mozilla Suite.  When I originally filed, I asked a
couple of people in IRC on Mozilla to help me reproduce, since I didn't have it
installed at the time, and they were unable to do so using 1.7.5.  I have always
(until that last comment of mine) been successful in reproducing on Firefox
Trunk nightlies, and milestones.  I will try to reproduce again and see if I
can't do it this time around since Jesse still sees it.

Comment 20

[Tristor]

Attachment: Effect of testcase in 0521, notice the URL

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050521
Firefox/1.0+

As you can see in this screenshot, the new effect seems to be the secure UI
changes, but the URL of the secure site that is forcing the spoof (paypal.com
in this example) is displayed in the URL bar, although the site you are on
(mozilla.org in this example) is displayed in the corner with the padlock
symbol.  This is different than was previously happening, and I am not sure why
it has this effect.  Jesse, was this what you say when you reproduced with the
testcase in comment #6 as well?

Comment 21

[Jesse Ruderman]

No, I'm not seeing the same thing.  I see "mozilla.org" in the address bar and
status bar (both indicated as being secure), while you see "paypal.com" in the
address bar.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050521
Firefox/1.0+.

Comment 22

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050524
Firefox/1.0+

I was able to reproduce it as originally reported, using the testcase in comment
#6.  It appears that what I got when reproducing on 0521 was a fluke of some
sort, I no longer see paypal.com in the location bar when doing this.

Comment 23

[Daniel Veditz [:dveditz]]

I'm seeing what Jesse sees on the trunk -- the final page shows www.mozilla.org
in the url and status bars, secure. Opening page info shows the page correctly
as "not verified", in spite of the lock icon being shown on the browser window.
Mousing over the locks gives a generic titlebar, not the one that lists the CA
as in true secure sites.

Comment 24

[Tristor]

(In reply to comment #23)
> I'm seeing what Jesse sees on the trunk -- the final page shows www.mozilla.org
> in the url and status bars, secure. Opening page info shows the page correctly
> as "not verified", in spite of the lock icon being shown on the browser window.
> Mousing over the locks gives a generic titlebar, not the one that lists the CA
> as in true secure sites.

That is what I am seeing now as well.  This has changed from the original
behavior in that the security certification no longer is displayed incorrectly.
 From the screenshot that esteban took in attachment 166744 [details] you can see it
originally did display that the unsecured site was secure and that the site had
a certificate from the CA that had certified the secure site used before it
(gmail in that instance).  So, this has been partially 'fixed' by something
else, I am presuming.

Comment 25

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050616
Firefox/1.0+

Trying to reproduce on this build is interesting.  The first two times I was
unable to reproduce using the testcase in comment #6, but the third time (third
time is the charm?) I was still able to reproduce.  Any word on when this might
be fixed?  I will keep testing for it every month to make sure the status of
reproduction stays current.

Comment 26

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050720
Firefox/1.0+

Monthly re-test.  I still see this being reproduced with the latest nightly.

Comment 27

[Tristor]

Due to the change of blocking-aviary1.1 not meaning anything (and there not
being an aviary 1.1, furthermore), I am asking for blocking-1.8b4

Comment 28

[Asa Dotzler [:asa]]

This appears to be fixed by the splitwindows changes. Resolving as such. 

Comment 29

[Tristor]

Attachment: Shows that this is not fixed

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050818
Firefox/1.6a1

Using the most recent installer build from pacifica-trunk, I tested this again
multiple times.  Each time I still see the UI features of a secure page come up
for the mozilla.org frontpage using the testcase in comment #6.  To help with
reproducing, Asa, try waiting a moment after the dialog for secure pages pops
up, this is what prompts the bug to happen. 

 I think it has something to do with it loading mozilla.org in the background
while still going through the motions on the foreground for a secure page.  The
proper behavior would be to halt any page loads until the user clears the
dialog box, and /then/ begin loading the page.	If that were to happen, it
would load Paypal (secure) and then move immediately to Mozilla.org (unsecure)
and display the correct UI.

I am reopening this bug, since it is not fixed.  I retested hoping it was fixed
and I could give a verification, but it is not so :/

Comment 30

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051017
Firefox/1.6a1

My current environment is a bit different from my previous testing environment
and is also much cleaner, so it should tell quite nicely if this still is
present in the current 1.5 beta builds.

Testing using the most recent installer build from pacifica-trunk, it appears
that this still exists.  I used the testcase in comment #6, as usual.

Just a monthly update to check if it is still present or not.

Comment 31

[Kai Engert (:KaiE:)]

In addition to the problem reported by Tristor, 3 warnings dialogs are shown,
but one would expect only two of them.


Ok, I am now able to reproduce the problem, with both Firefox and Seamoney.
I understand the problem and I have a fix.


Explanation:

At the time the security tracking code displays the warning dialog, updating the
security state variables has not yet been fully completed.

If new document loading happens, while the dialog is shown, more events are
being sent to the security tracking, which are being partly processed, based on
the incomplete state. What we get is chaos.


The idea to the fix is, to complete all updating of state variables first. Only
after having done so, we bring up the warning dialog.

When other events come in, like loading another document while the dialog is
still shown, the new event is processed based on the correct state.


With the patch that I'll attach, the lock icon goes to the correct state. Only
two warning dialogs are shown, as one would expect.


Firefox seems to be completely fine with this patch. However, there is one issue
remaining with Seamonkey. After having confirmed both warning messages, the
display page is the insecure page, and the lock icon is in the insecure state,
as expected. But the problem remaining is: The URL bar still displays the
address of the secure page! It seems that processing of URL bar location changes
gets into trouble, too.

Comment 32

[Kai Engert (:KaiE:)]

Attachment: Patch v1

Comment 33

[Kai Engert (:KaiE:)]

I understand why Seamonkey will display the address of the secure page in the
URL bar, even with this patch applied.

The test case causes two warning dialogs to be shown. The "leaving secure" is
displayed topmost, it is modal, and has to be clicked first by the user. The
"entering secure" message (was triggered by the first page) will be clicked
afterwards. I guess, the fact the warning dialogs blocks processing of the web
progress notification even, also blocks that portion of our code, which is
responsible for updating the URL bar. Because of the stacking of modal dialogs,
the progress event for the secure page will be processed in the end, and seems
to win in the race to update the URL bar.

Although Firefox shows the same modal dialogs in the same order, the URL bar
remains at the insecure location. So Firefox' URL bar tracking seems to be more
directly connected to the displayed content.

(BTW, this is another bug that would profit from a fix to bug 62178, because the
warning dialog about state transition will then no longer be delayed, but
hapenning before displayed content changes.)

Comment 34

[Kai Engert (:KaiE:)]

I tested this bug and test patch with 6 different browser, that is 12 tests.
I think the patch is an improvement and should be taken for trunk, 1.7 branch,
1.8 branch and aviary 1.1 branches.

Here are the results (final display) of my tests:

Seamonkey 1.7 branch:
VERY BAD: content area blank, URL bar says http, secure lock

Seamonkey 1.8 branch:
VERY BAD: content area shows insecure page, URL bar says https, secure lock

Seamonkey trunk:
VERY BAD: content area shows insecure page, URL bar says https, secure lock

Firefox 1.0.7:
VERY BAD: content area blank, URL bar says http, URL bar is yellow, secure lock

Firefox 1.8 branch:
VERY BAD: content area shows insecure page, URL bar says http, URL bar yellow,
secure lock

Firefox trunk:
VERY BAD: content area shows insecure page, URL bar says http, URL bar yellow,
secure lock



Seamonkey 1.7 branch with patch applied:
ACCEPTABLE: content area blank, URL bar says http, insecure lock

Seamonkey 1.8 branch with patch applied:
BAD: content area shows insecure page, URL bar says https, insecure lock

Seamonkey trunk with patch applied:
BAD: content area shows insecure page, URL bary says https, insecure lock

Firefox 1.0.7 with patch applied:
ACCEPTABLE: content area blank, URL bar says http, URL bar white, insecure lock

Firefox 1.8 branch with patch applied:
GOOD: content area shows insecure page, URL bar says http, URL bar white, no lock

Firefox trunk with patch applied:
GOOD: content area shows insecure page, URL bar says http, URL bar white, no lock

Comment 35

[Kai Engert (:KaiE:)]

For completeness sake, I repeated the tests, with the order of secure/insecure
pages reversed, that is the final displayed was a secure page, in my additional
series of tests. Same results.

Comment 36

[Kai Engert (:KaiE:)]

What is left to be done?

For Mozilla 1.7.x and Firefox 1.0.7+, the browser content area goes blank,
although URL bar shows the URL of the final loaded page. I'm a bit concerned,
because when the final displayed page is a secure page, we display a lock icon,
 for an incorrectly shown blank page.

Should this "content goes blank" bug, that appears only in the older versions,
be worked on? As a separate bug?


For Seamonkey 1.8 and trunk, with the patch applied, we now display the correct
lock icon, but the URL bar still displays the wrong URL. This is an improvement,
but still bad.

Should this "URL bar wrong in Seamonkey" problem be worked on in this, or in a
separate bug?


No more work seems to be required for Firefox versions based on 1.8 branch and
trunk, the patch seems to be sufficient.

Comment 37

[Asa Dotzler [:asa]]

We're going to mark this as blocking, but if reviews suggest it's too scary for
this late in the game, that may fall off. Thanks for all your work on this Kai. 

Comment 38

[Tristor]

Sorry for the bug spam, but I just wanted to thank you for all your help Kai,
and I hope this patch gets in soon.  Very awesome!

Comment 39

[Daniel Veditz [:dveditz]]

Comment on attachment 200144 [details] [diff] [review]
Patch v1

r=dveditz
Looks good, patch fixes the bug.

Comment 40

[Asa Dotzler [:asa]]

Kai, can you land this on the trunk so we can verify it fixes the problem there
and get this approved for the branch, ASAP. Thanks.

Comment 41

[Darin Fisher]

fixed-on-trunk

Comment 42

[Kai Engert (:KaiE:)]

Regarding the remaining problem in Seamonkey, as explained in comment 36, I
filed the separate bug 313335.

Comment 43

[Asa Dotzler [:asa]]

I've verified that this is fixed on the trunk with the latest tinderbox build on
windows.

Comment 44

[Kai Engert (:KaiE:)]

fixed1.8

Comment 45

[Kai Engert (:KaiE:)]

Comment on attachment 200144 [details] [diff] [review]
Patch v1

This patch is appropriate for 1.7.13 and 1.0.8, too.

Comment 46

[Kai Engert (:KaiE:)]

I verified on Linux the patch fixes the issue on both 1.7 and aviary branches.

Comment 47

[Daniel Veditz [:dveditz]]

Comment on attachment 200144 [details] [diff] [review]
Patch v1

a=dveditz for drivers

Comment 48

[Kai Engert (:KaiE:)]

fixed-aviary1.0.8, fixed1.7.13

Comment 49

[Jay Patel [:jay]]

v.fixed on 1.0.1 Aviary branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060213 Firefox/1.0.8, looks ok with Jesse's testcase in comment #6.