Closed Bug 687745 Opened 13 years ago Closed 12 years ago

(CVE-2012-0474) URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward()

Categories

(Core :: DOM: Navigation, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla14
Tracking Status
firefox11 --- wontfix
firefox12 --- fixed
firefox13 --- fixed
firefox14 --- fixed
firefox-esr10 12+ verified

People

(Reporter: jordi.chancel, Assigned: smaug)

References

()

Details

(Whiteboard: [sg:high][qa!] fixed by bug 737307)

Attachments

(8 files, 1 obsolete file)

Attached image ScreenShot.png
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Build ID: 20110902133214

Steps to reproduce:

The problem originated is from the creation of a link with javascript (window.open ; document.location ; back() ; forward() ; fragment navigation and Redirect.) . When you open a new tab via window.open on another address (with SSL or not) and use all of this elements,  it's possible to spoof the URL and SSL/TLS.
It's also possible to steal saved password on Mozilla firefox if the web page spoofed contains a form with saved password. the form should be like : <form ACTION="/connect.php"> but not like this : <form ACTION="HTTP://www.xxx.yyy/connect.php"> for steal the saved password and login (I have chosen linkedin.com for demonstrate this).

This blank page can be changed with javascript with making a spoofing attak.



Actual results:

URL with SSL/TLS is Spoofed and we can steal saved password of linkedin.com (and many other website with a connection formulary's like linkedin.com)

/!\ I had found a very similare vulnerability on Google chrome in the past (same impact => SecSeverity:high)
Attached file TESTCASE1 (obsolete) —
Please try and retry this TESTCASE ! (don't works perfectly the first time)
Attachment #561095 - Attachment is obsolete: true
Attached file TESTCASE1.1
Better Testcase!
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.
screenshot2 with saved password
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:high]
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.
Component: General → Document Navigation
Product: Firefox → Core
QA Contact: general → docshell
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)
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!
Summary: URL & SSL/TLS Spoofing with saved password stealing using multiple history.back() and history.forward() → URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward()
movie of testcase1.1 => http://www.youtube.com/watch?v=PXl-Z5YKiYQ    
but now the spoofing works without back manually !
NEW +> ASSIGNED OR NOT ? :(
Attachment #561100 - Attachment mime type: application/octet-stream → application/java-archive
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?
Attachment #567588 - Attachment mime type: text/plain → application/x-rar-compressed
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.
Assignee: nobody → Olli.Pettay
Version: 6 Branch → Trunk
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.
Attached file 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, jst@mozilla.com) 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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Depends on: CVE-2012-0474
Whiteboard: [sg:high] → [sg:high] fixed by bug 737307
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.
Whiteboard: [sg:high] fixed by bug 737307 → [sg:high][qa+] fixed by bug 737307
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.
Whiteboard: [sg:high][qa+] fixed by bug 737307 → [sg:high][qa!] fixed by bug 737307
Verified in nightly (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120416 Firefox/14.0a1).
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla14
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?
Group: core-security
rforbes-bugspam-for-setting-that-bounty-flag-20130719
Flags: sec-bounty+
Summary: URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward() → CVE-2012-0474) URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward()
Summary: CVE-2012-0474) URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward() → (CVE-2012-0474) URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward()
Alias: (CVE-2012-0474)
Alias: (CVE-2012-0474)
Summary: (CVE-2012-0474) URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward() → URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward()
Summary: URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward() → (CVE-2012-0474) URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward()
You need to log in before you can comment on or make changes to this bug.