Closed Bug 271194 Opened 20 years ago Closed 19 years ago

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

Categories

(Core :: Security: PSM, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

VERIFIED FIXED

People

(Reporter: tristor, Assigned: KaiE)

References

Details

(Keywords: fixed1.7.13, fixed1.8, testcase, Whiteboard: [sg:spoof])

Attachments

(6 files, 1 obsolete file)

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.
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.
<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.
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.
I can reproduce this bug using Firefox 1.0 on WinXP (using the testcase).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
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
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.
Attachment #166748 - Attachment is obsolete: true
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.
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.1+ → blocking-aviary1.1?
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.
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
Flags: blocking-aviary1.1? → blocking-aviary1.1+
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.
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.
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'
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.
Assignee: firefox → kaie
Blocks: lockicon
Component: General → Security: PSM
Product: Firefox → Core
QA Contact: general
Whiteboard: [sg:spoof]
Version: unspecified → Trunk
(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.
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.
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.
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+
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.
(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.
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?
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+.
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.
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.
(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.
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.
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.
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
Flags: blocking1.8b4?
Flags: blocking1.8b4?
Flags: blocking1.8b4+
Flags: blocking-aviary1.5+
This appears to be fixed by the splitwindows changes. Resolving as such.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → 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 :/
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Flags: blocking1.8b5+ → blocking1.8b5-
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.
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.
Attached patch Patch v1Splinter Review
Attachment #200144 - Flags: review?(dveditz)
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.)
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
Status: REOPENED → ASSIGNED
Flags: blocking1.8rc1?
Flags: blocking1.7.13?
Flags: blocking-aviary1.0.8?
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.
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.
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.
Flags: blocking1.8rc1? → blocking1.8rc1+
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 on attachment 200144 [details] [diff] [review] Patch v1 r=dveditz Looks good, patch fixes the bug.
Attachment #200144 - Flags: superreview?(darin)
Attachment #200144 - Flags: review?(dveditz)
Attachment #200144 - Flags: review+
Attachment #200144 - Flags: approval1.8rc1?
Attachment #200144 - Flags: superreview?(darin) → superreview+
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.
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Regarding the remaining problem in Seamonkey, as explained in comment 36, I filed the separate bug 313335.
I've verified that this is fixed on the trunk with the latest tinderbox build on windows.
Status: RESOLVED → VERIFIED
Attachment #200144 - Flags: approval1.8rc1? → approval1.8rc1+
fixed1.8
Keywords: fixed1.8
Flags: testcase+
Flags: blocking1.7.13?
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8?
Flags: blocking-aviary1.0.8+
Comment on attachment 200144 [details] [diff] [review] Patch v1 This patch is appropriate for 1.7.13 and 1.0.8, too.
Attachment #200144 - Flags: approval1.7.13?
Attachment #200144 - Flags: approval-aviary1.0.8?
I verified on Linux the patch fixes the issue on both 1.7 and aviary branches.
Comment on attachment 200144 [details] [diff] [review] Patch v1 a=dveditz for drivers
Attachment #200144 - Flags: approval1.7.13?
Attachment #200144 - Flags: approval1.7.13+
Attachment #200144 - Flags: approval-aviary1.0.8?
Attachment #200144 - Flags: approval-aviary1.0.8+
fixed-aviary1.0.8, fixed1.7.13
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.
Group: security
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: