Malicious extensions can trigger infinite loop and eat memory

NEW
Unassigned

Status

()

Core
Document Navigation
--
critical
10 years ago
6 years ago

People

(Reporter: glandium, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
Created attachment 324736 [details]
Malicious extension

When chrome://global/content/netError.xhtml is missing (which can happen if a malicious extension adds an override), docshell enters an infinite loop, because it want to display a neterror for a filenotfound error for netError.xhtml, which it can't, so it displays a neterror for a filenotfound for the previous error, etc. This ends up eating all memory quite fast.

I'm attaching a small testcase xpi. Install it, then go anywhere where the neterror would show up, such as https://mozilla.org/ if you haven't added it already as an exception.
(Reporter)

Comment 1

10 years ago
FWIW, a backtrace when it is happening (just Ctrl+C'ed at a random time) ; the string length is colossal:
#0  0x00007feb4f5f3585 in nsACString_internal::ReplaceASCII (this=0x7fff59352970, cutStart=32, cutLength=0, 
    data=0x7feb0bb3d010 "about%3Aneterror%3Fe%3DfileNotFound%26u%3Dabout%253Aneterror%253Fe%253DfileNotFound%2526u%253Dabout%25253Aneterror%25253Fe%25253DfileNotFound%252526u%25253Dabout%2525253Aneterror%2525253Fe%2525253Dfil"..., length=4294967295) at nsTSubstring.cpp:510
#1  0x00007feb4f3b5bbc in nsDocShell::LoadErrorPage (this=0x2e60d80, aURI=<value optimized out>, aURL=<value optimized out>, aErrorPage=0x7fff59352f20 "neterror", 
    aErrorType=0x7fff59352ca0, aDescription=0x7feaf0160018, aCSSClass=0x7fff59352f80 "", aFailedChannel=0x2abeda8) at nsDocShell.cpp:3288
#2  0x00007feb4f3b62e3 in nsDocShell::DisplayLoadError (this=0x2e60d80, aError=<value optimized out>, aURI=0x1f77b50, aURL=0x0, aFailedChannel=0x2abeda8)
    at nsDocShell.cpp:3187
#3  0x00007feb4f3b3266 in nsDocShell::InternalLoad (this=0x2e60d80, aURI=0x1f77b50, aReferrer=0x0, aOwner=0x0, aFlags=0, aWindowTarget=0x0, aTypeHint=0x0, aPostData=0x0, 
    aHeadersData=0x0, aLoadType=2147483649, aSHEntry=0x0, aFirstParty=1, aDocShell=0x0, aRequest=0x0) at nsDocShell.cpp:7215
#4  0x00007feb4f3b5cd8 in nsDocShell::LoadErrorPage (this=0x2e60d80, aURI=<value optimized out>, aURL=<value optimized out>, aErrorPage=0x7fff59353bd0 "neterror", 
    aErrorType=0x7fff59353950, aDescription=0x7feb1c24f018, aCSSClass=0x7fff59353c30 "", aFailedChannel=0x2fb6208) at nsDocShell.cpp:3310
#5  0x00007feb4f3b62e3 in nsDocShell::DisplayLoadError (this=0x2e60d80, aError=<value optimized out>, aURI=0x255bf50, aURL=0x0, aFailedChannel=0x2fb6208)
    at nsDocShell.cpp:3187
#6  0x00007feb4f3b3266 in nsDocShell::InternalLoad (this=0x2e60d80, aURI=0x255bf50, aReferrer=0x0, aOwner=0x0, aFlags=0, aWindowTarget=0x0, aTypeHint=0x0, aPostData=0x0, 
    aHeadersData=0x0, aLoadType=2147483649, aSHEntry=0x0, aFirstParty=1, aDocShell=0x0, aRequest=0x0) at nsDocShell.cpp:7215
#7  0x00007feb4f3b5cd8 in nsDocShell::LoadErrorPage (this=0x2e60d80, aURI=<value optimized out>, aURL=<value optimized out>, aErrorPage=0x7fff59354880 "neterror", 
    aErrorType=0x7fff59354600, aDescription=0x7feb2e56c018, aCSSClass=0x7fff593548e0 "", aFailedChannel=0x2bba608) at nsDocShell.cpp:3310
#8  0x00007feb4f3b62e3 in nsDocShell::DisplayLoadError (this=0x2e60d80, aError=<value optimized out>, aURI=0x22dfbb0, aURL=0x0, aFailedChannel=0x2bba608)
    at nsDocShell.cpp:3187
(Reporter)

Comment 2

10 years ago
I guess fixing this could be done by checking aURI doesn't begin with about:neterror at the end of nsDocShell::InternalLoad and not doing DisplayLoadError then.
Uh... A malicious extension can just wipe your hard drive...  So while it might be worth fixing this to keep extension authors from accidentally shooting themselves in the foot, I don't think we should be worried about malicious ones here.
(Reporter)

Comment 4

10 years ago
Well, I, for one, shot myself in the foot while debugging bug #438688 and fortunately, I have enough RAM that I could kill firefox before it started eating swap.
This could also be triggered by future changes to about:neterror, who knows. I think it would be better with a failsafe.
You need to log in before you can comment on or make changes to this bug.