122.28 KB, image/png
1.66 KB, application/java-archive
64.62 KB, image/png
84.74 KB, image/png
1.62 KB, application/x-rar-compressed
99.83 KB, image/png
1.63 KB, application/octet-stream
198 bytes, text/plain
Created attachment 561095 [details] TESTCASE1 Please try and retry this TESTCASE ! (don't works perfectly the first time)
If the testcase1.1 don't works the first time , please back or forward manually ( button back or forward).
Result of testcase1.1 can show the cookie of attacker but the content is linkedin.com . I think we can bypass de cross origin.
I had to run the testcase several times, but it does reproduce for me in Firefox 6 and Nightly. Just to make clear what Jordi is reporting: When using window.open and some APIs to navigate the opened document, it is possible to navigate the opened document to a different site, while the location bar doesn't stay in sync with the new location. In cases where the navigated document winds up on a login form with a relative <form action>, an attacker could steal the submitted form data because it would be presumably sent to the relative location on the attacker's domain.
i will try to code a better testcase!
http://www.alternativ-testing.fr/Research/Mozilla/possible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.html Please use this testcase , if it don't works the first time , forward or back manually for show the spoofing ! I think this testcase don't works the first time, so please try and retry for show the spoofing (don't forget back or forward manually if the spoofing don't works directly)
@Brandon Sterne : this testcase don't works with you?
@Brandon : I've coded a better Testcase ! => http://www.alternativ-testing.fr/Research/Mozilla/possible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.html + back or forward manually if it don't work directly !
(In reply to Jordi Chancel from comment #9) > @Brandon Sterne : this testcase don't works with you? The first testcase works, so that's why I confirmed this bug.
This vulnerability works again on Firefox 7.0.1 !
(In reply to Jordi Chancel from comment #8) > http://www.alternativ-testing.fr/Research/Mozilla/ > possible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing. > html > > Please use this testcase , if it don't works the first time , forward or > back manually for show the spoofing ! Jordi, the above url is a 404 for me. Did it get removed from the server?
Sorry for the elimination! http://www.alternativ-testing.fr/Research/Mozilla/possible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.html + back manually if it don't work directly ! I think this testcase don't works the first time, so please try and retry for show the spoofing (don't forget back or forward manually if the spoofing don't works directly)
Created attachment 566637 [details] ScreenShot firefox 7.0.1 http://www.alternativ-testing.fr/Research/Mozilla/possible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.html works perfeclty using back manually on Mozilla Firefox 7.0.1 !
New URL of the testcase => http://www.alternativ-testing.fr/Research/Mozilla/564fg65gf465gfbh42gpossible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.html (more sure)
don't forget back manually!
I've coded a better testcase => http://www.alternativ-testing.fr/Research/Mozilla/564fg65gf465gfbh42gpossible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.html //It works without back manually and can steal the saved password and login!
movie of testcase1.1 => http://www.youtube.com/watch?v=PXl-Z5YKiYQ but now the spoofing works without back manually ! NEW +> ASSIGNED OR NOT ? :(
Created attachment 567588 [details] TESTCASE2.0 (back automaticaly, can steal saved password) New better Testcase (v2.0)
Neither Brandon nor I have been able to reproduce this "seemlessly", though a couple of times (out of many, many, more failed attempts) I did get the PoC to work by hitting the forward (not back!) button once I was on the LinkedIn page. At that point the URL changed to www.alternativ-testing.fr but the "Larry" button continued to say LinkedIn (slight difference from the movie). The LinkedIn content was not deleted (including the replayed saved password) and clicking submit did send the password to Jordi's site as shown in the movie. On the times I've gotten to almost the right state (LinkedIn showing, password replayed, forward button but not back enabled) I can go back to the original window and manually do "a.history.forward()" to bring about the spoof so maybe it's just a timing issue that could be easily solved. This report is more of a constellation of issues rather than a simple singular bug. As a "spoof" it's about on par with your typical phishing page (URL bar has the wrong domain), but the fact that Firefox has replayed the password could be convincing. Although the form submit relative URL goes to the wrong domain, apparently internally we still think we're on LinkedIn because I cannot access any properties of the document through the window handle held by the original page. 1) Is the bug that the content (or bfcache?) and URL history got out of sync, or that we didn't clear the content when we navigated to www.alternativ-testing.fr? Or that we changed the URL without really navigating at all? 2) There's a Larry-spoofing problem in that we take the current-page's URL rather than a URL from the certificate, leading to showing the remembered secure state (blue larry) with an HTTP insecure domain. 3) If we think the content is from LinkedIn why is the form submitting somewhere else? Are other relative URLs also incorrectly calculated in this state (say some AJAX-y script) or is this problem restricted to <form>s? 4) This is another case where auto-replaying of passwords before there's any indication of intent to use the form gets us into trouble.
or one vulnerability with multiple effect! a simpler and better testcase is possible ! but on my firefox , testcase2.0 works perfectly or half the time!
I have not yet tried testcase2.0, my comments were based on the initial testcase and the one hosted on your site.
I have no idea about #1 and #3 from comment 21. That just should not be happening. Even if the url bar is confused, relative URLs for something like forms should be resolved wrt the document base URI... Justin, Olli?
Just FYI, I've managed to reproduce the problem twice using testcase2.0. I didn't really debug this yet, but it looked like the linkedin page got different documentURI, which is why some relative urls in the page didn't link to linkedin.
And you can see that <form> of linkedin (e-mail and password) is redirected to my site (https://www.alternativ-testing.fr/secure/login inftead of https://www.linkedin.com/secure/login).
Olli, can you own this and investigate further? If not, let me know and we'll see who else might be able to help out here.
Created attachment 571822 [details] ScreenShot4 Firefox 7.0.1 with developer.mozilla.org The new screenshot of result of the new testcase(using developer.mozilla.org) (so without Linkedin.com, Because Linkedin.com password stealing don't work now because they are a new security in login page )
You can see than the saved password and login of developer.mozilla.org are sent to attacker page . this time i've don't coded a PHP stealer of the password sent because it requiere a .htaccess but i already use a different htaccess on my website base.
I have cc'd Eddy Bordi because he help me to exploit bug 703111 wich is very similar to this.
Created attachment 575054 [details] Basic testcase I simplified the operation of spoofing, simply click on "Spoof" and after page loading, click on forward.
this vulnerability isn't patched but ihave reported this last year. can you fix it please? this vulnerability is high!
(In reply to Johnny Stenback (:jst, firstname.lastname@example.org) from comment #28) > Olli, can you own this and investigate further? If not, let me know and > we'll see who else might be able to help out here. This was asked in October of 2011. Can we get an update and make sure someone is looking at this issue?
This may be the same as bug 737307, which has a working testcase.
We fixed bug 737307 in trunk. I've never been able to reproduce this bug, but to those of you who can, it would be great if you could tell us if the issue is now fixed.
Mid-air with Justin! I've verified bug 737307 with a nightly. I've verified with the testcase in comment 34 that the behavior in nightly seems to be fixed for this after the fix for bug 737307. The testcase still works in current Aurora but not the nightly.
I have multiple working testcase too , please credit me the first , i'm the first to report this bug and demonstrate that it's a high vulnerability (stealing of credential password and login saved into a input ). So please credit me the first.
Jordi, you will get credit.
[Triage Comment] If bug 737307 is fixed on ESR is there something else here to give us a reason to keep tracking this bug for ESR or can we mark this one fixed too?
(In reply to Lukas Blakk [:lsblakk] from comment #43) > [Triage Comment] > If bug 737307 is fixed on ESR is there something else here to give us a > reason to keep tracking this bug for ESR or can we mark this one fixed too? We can mark this as fixed for ESR.
Yes i wiil get credit , but the first please!
(In reply to Jordi Chancel from comment #45) > Yes i wiil get credit , but the first please! I'm not sure what you're asking, Jordi. Are you concerned which order names go in on the advisories for the bugs we write?
yes i am concerned which order names go in on the advisories for the bugs you write
(In reply to Jordi Chancel from comment #47) > yes i am concerned which order names go in on the advisories for the bugs > you write All right, Jordi. From our point of view, the order isn't important and we don't specifically put one name before another as a way of indicating which bug reporter is more important.
If you have more questions, Jordi, let's discuss this in email and not the bug.
Using the testcase in comment 34, I confirm this behaviour is fixed for Firefox 10.0.4esr. 10.0.3esr exhibits the bug, 2012-04-16 esr10 does not.
Verified in nightly (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120416 Firefox/14.0a1).
it's the Bug 700080 witch was fixed on the last update ... not this bug ? BUT http://www.mozilla.org/security/announce/2012/mfsa2012-27.html SHOW THIS BUG on the bugs list. an error of you?