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 9 users

Issue metadata

Status: Fixed
Closed: Dec 2012
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 0
Type: Bug

  • Only users with EditIssueCc permission may comment.

Sign in to add a comment

Issue 146254: Security: Windows blue screen and arbitrary code execution with corrupted font file

Reported by, Sep 3 2012

Issue description

This template is ONLY for reporting security bugs. Please use a different
template for other types of bug reports.

Please see the following link for instructions on filing security bugs:

Windows crashes with blue screen when opening a web page with a corrupted font file embedded with CSS font-face rule. This unfixed bug in Windows font handling possibly allows execution of code at kernel level.

Browsers like Firefox and Opera have their own font validation before passing the corrupt font to Windows kernel and therefor avoid crashing.

Chrome Version: 21.0.1180.89 stable, 23.0.1251.2 dev
Operating System: Microsoft Windows 7 x64 pro, service pack 1 (tested also on Windows Vista x64 enterprise and Windows 8 x64 enterprise)
A html file and a font file are provided as attachment. When opening the html file the browser and Windows OS crash.

Type of crash: browser and Windows OS
Crash State: [see link above: stack trace, registers, exception record]
Client ID (if relevant): [see link above]
414 KB Download
234 bytes View Download

Comment 1 by, Sep 3 2012

Labels: -Area-Undefined Area-Internals OS-Windows Feature-Fonts
Status: Untriaged
Definitely a kernel panic in win32k.sys, but I can't debug it from my laptop. Have you reported this to Microsoft, since it's a serious vulnerability in their kernel code?

To the people on the CC list, could one of you see if there's anything we can do to catch the issue and block the font in OTS? Otherwise, the only option is to close this bug out and wait for Microsoft to fix their kernel bug.

Firefox and Opera are unaffected only because they switched to DirectWrite, and the issue is triggering in win32k GDI. They don't filter malformed fonts, but I don't know how much the DirectWrite path changes the font handling (and if it fixes the bug or just blocks this repro).

Comment 2 by, Sep 3 2012

Will be able to take a look tomorrow if nobody beats me to it.

Comment 3 by, Sep 4 2012

Labels: reward-topanel
@eetu.luodemaa: thanks for the report. We will analyze it carefully :)
One initial note I had for you is that (I believe) Firefox uses the same font sanitizing library (OTS) that we developed for Chrome.
So if Chrome is affected but Firefox isn't, it's probably due to Chrome using different kernel calls with the bad font. For example, we had one case

@fjserna: this seems kind of possibly critical. Would you be so kind as to give us some thoughts on exploitability?

Comment 4 by, Sep 4 2012

Oops, my sentence was cut off. It should say:

For example, we had one case where there was a crash getting some form of font metrics or outlines, which was a Win kernel API used by Chrome but not all other browsers.

I can't find the reference, I'll keep looking.

Comment 5 by, Sep 4 2012

I'm looking the font whether ots can catch the issue.

Comment 6 by, Sep 4 2012

Status: Started
The font has invalid glyph indexes in cmap table. We should reject the font. OTS CL uploaded for review.

Comment 7 by, Sep 4 2012

The CL LGTM (thanks!), but I think we should confirm that the invalid index in CMAP is the direct cause of the kernel panic.

Yes, Firefox has been using OTS since Dec 2010.

Comment 8 by, Sep 4 2012

I agree. The CL will reject the font, but anyway I'll check it.

Comment 9 by, Sep 4 2012

What happens if you rewrite the invalid index in cmap to a valid one and accept the font (rather than just rejecting the font as a whole)?

Comment 10 by, Sep 4 2012

I created a modified font that contains valid cmap from the original font. I used sfntly subsetting to create the font. It modifies some other tables, but I think it generates almost the same font. The generated font is attached.

I confirmed the crash with the original font. Windows doesn't crash with the modified font.
414 KB Download

Comment 11 by, Sep 4 2012

May bad. Looks like Firefox started filtering fonts with our OTS code in early 2011:

Comment 12 by, Sep 4 2012

I think we should treat this as exploitable although I need to dig a bit more. It is cool we are going to filter these things at the browser level, but we need to keep in mind this can be used as a sandbox escape post exploiting some other vulnerability and gaining sandboxed code execution. 

I will take a deeper look and do some variation hunting on the win32k side since you already have covered the browser filtering part.

Please go ahead and contact so they can start the response process on our side.

Comment 13 by, Sep 4 2012

@fjserna - Correct, that's why these always get forwarded on to MS for a proper fix of the privilege escalation issue.

Comment 14 by, Sep 4 2012

Labels: SecSeverity-Critical
Tagging with an initial likely severity of "critical".

@eetu.luodemaa: would you like us to consider this under our vulnerability reward program, and take on co-ordination with Microsoft?

Comment 15 by, Sep 4 2012

@bashi @yusukes: I just want to make sure I understand: we're fairly sure that the crash is due to the invalid cmap index and not some other aspect of the corrupted font file? It'd be wonderful to have a validation we can cover in OTS.

Comment 16 by, Sep 4 2012

I think so but bashi@ would be a better person to answer the question.

Comment 17 by, Sep 4 2012

Project Member
The following revision refers to this bug:

r154803 | | 2012-09-04T20:33:33.235156Z

Changed paths:

OTS roll r94:r95

BUG= chromium:146254 

Review URL:

Comment 18 by, Sep 4 2012

I performed some cursory investigation, and in my assassment this crash represents an easily exploitable Elevation of Privileges vulnerability.

The immediate reason of the crash seems to be a 16-bit integer underflow: the win32k!vGetVerticalGSet routine assumes that the sum of two 16-bit values would be greater than 0 and perform a loop through 0..x-1 (0xffff here) filling up a session paged pool buffer (classic buffer overflow):

Integer overflow assembly:
.text:BF9E6955                 movzx   eax, word ptr [esi]
.text:BF9E6958                 mov     dx, [esi+2]
.text:BF9E6962                 add     dx, ax
.text:BF9E6968                 dec     dx
.text:BF9E696D                 movzx   eax, dx

Disassembled context, result=-1, v7=0, v6 points to a session paged pool buffer that's overflown, (v2 + 4) is a simple win32k!SearchDummyTable function that only returns the second parameter.
      v9 = (unsigned __int16)(result - v7 + 1);
        result = (*(int (__stdcall **)(int, _DWORD))(v2 + 4))(v2, *(_DWORD *)v6);
        *(_DWORD *)v6 = result;
        v6 += 4;
      while ( v9 );

Although at the time of the crash the buffer is "overwritten" with its own contents due to the function used (win32k!SearchDummyTable), the out-of-bounds values of the buffer are later used as an index into another array during an OR operation (contents of v19 are fully controlled 32-bit values) in win32k!bComputeGlyphAttrBits, which is an exploitable condition.

*(_BYTE *)((*(_DWORD *)v19 >> 3) + v7 + 12) |= glyphBits[*(_DWORD *)v19 & 7];

So this seems critical.

Comment 19 by, Sep 4 2012

Thanks j00ru.

I was talking to cevans@ before and due to the loop and heap (pool) massaging needed it would be kind of difficult to exploit this from the browser directly (you may want to reconsider the High severity) but totally doable from a post-exploitation context and elevating privileges.

Comment 20 by, Sep 4 2012

Wait did not read your text: 

"Although at the time of the crash the buffer is "overwritten" with its own contents due to the function used (win32k!SearchDummyTable), the out-of-bounds values of the buffer are later used as an index into another array during an OR operation (contents of v19 are fully controlled 32-bit values) in win32k!bComputeGlyphAttrBits, which is an exploitable condition."

In any case I still think browser to kernel execution would be very challenging but not process to kernel.

Comment 21 by, Sep 4 2012

Agreed with Fermin about the practical exploitability (browser-to-kernel very unlikely, renderer-to-kernel likely).

Comment 22 by, Sep 5 2012

I'm not 100% sure, but I think so. The font attached #10 is almost the same of the original corrupted font, but it doesn't cause crash. You can see the difference by using showttf command or similar tools. According to the checksum calculated by showttf, OS/2 and cmap are the only subtables which contains different values.

OTS r95 will reject the font. This means Chrome won't load the font at all and fall back fonts will be used.

Comment 23 by, Sep 5 2012

Labels: Merge-Approved Mstone-22
Status: FixUnreleased
Thanks -- any chance you can rev the OTS revision on both trunk and also the M22 branch?

Comment 24 by, Sep 5 2012

Project Member
Labels: -Merge-Approved merge-merged-1229
The following revision refers to this bug:

r154876 | | 2012-09-05T01:28:40.315469Z

Changed paths:

Merge 154803 - OTS roll r94:r95

BUG= chromium:146254 

Review URL:
Review URL:

Comment 25 by, Sep 5 2012

@eetu.luodemaa: aside from the question about us dealing with Microsoft (we have a good contact), with what name would you like us to credit you in our release notes?

Comment 26 by, Sep 5 2012

OTS r95 is already rolled on trunk. Merged to M22 branch.

Comment 27 by, Sep 5 2012

@bashi: thanks for a quick response!

Comment 28 by, Sep 7 2012

@fjserna @mjurczyk: I wonder if it might not be so tricky to exploit web -> kernel? The attacker can load any number of fonts in any order. Within those font loads, some of the structures within the fonts will represent an allocation of attacker-controlled length with attacker-controlled bytes. etc.

Comment 29 by, Sep 7 2012

You may deal with Microsoft on this matter. You can give credit to anonymous.

Comment 30 by, Sep 7 2012

Labels: Restrict-View-Google

Comment 31 by, Sep 7 2012

@scarybeasts: still, most of these semi-controlled allocations are freed after the font parsing is complete, and the degree of control and feedback an attacker would have within web context is most likely insufficient IMHO. I'm not saying it's impossible, but given our current knowledge of the crash (using out-of-bounds pool values as array indexes), this looks just terribly hard to exploit in a reliable manner.

Renderer -> kernel is much easier though, and would definitely be feasible.

Comment 32 by, Sep 7 2012

Actually could you give credits to "Joni Vähämäki and Eetu Luodemaa". Thank you

Comment 33 by, Sep 7 2012


I was the one who originally discovered the crash and although I was sure
it was something quite serious, I'm still surprised about the amount of
attention this has been getting.

Anyway, I thought it would be a good idea to sum up my own observations
here, although the above comments already describe the bug quite well. The
required conditions for the crash seem to be that the font's CMAP should
contain a format 4 subtable with a single segment identity mapping between
0x0000 to 0xffff (note that the last valid TTF glyph index is 0xfffe), and
the OS/2 table should have one of the code page bits between 17 and 21
(inclusive) set.

The attached file is a somewhat minimal font file (only 2 glyphs) which
meets these conditions. Only fonts that contain TrueType outlines seem to
cause the crash. An OpenType font with CFF glyph outlines that meets the
same conditions does not crash.

Joni Vähämäki
1.5 KB Download

Comment 34 by, Sep 7 2012

@scarybeasts: I agree with j00ru. Based on current browser pool massaging state of the art I would say it will be challenging enough to disuade regular exploit writers knowing this will get fixed soon.

I bet with enough time and motivation those browser to pool alloc primitives would be discovered and make this easier to exploit... but after that you need to deal with kernel ASLR where in a renderer -> kernel is not a problem.

Comment 35 by, Sep 7 2012

Labels: -Restrict-View-Google
Credit details passed along, thanks!

Given the nastiness of the bug, we also tagged in with our 60-day policy as we passed it over to Microsoft:

Comment 36 by, Sep 8 2012

Labels: -reward-topanel reward-5000 reward-unpaid
Given the new rewards structure, and the severity of this bug, and the fact it's interesting, and despite the fact it's not "our" fault: I'm delighted to offer a $5000 Chromium Security Reward.

Boilerplate text:
Please do NOT publicly disclose details until a fix has been released to all our
users. Early public disclosure may cancel the provisional reward.
Also, please be considerate about disclosure when the bug affects a core library
that may be used by other products.
Please do NOT share this information with third parties who are not directly
involved in fixing the bug. Doing so may cancel the provisional reward.
Please be honest if you have already disclosed anything publicly or to third parties.

Comment 37 by, Sep 9 2012

I understand that you passed the credits already and this may came late but can you add note about our company "Documill" to the credits?

Comment 38 by, Oct 2 2012

Re: #c37: done!

Eetu, how would you like the payout to be apportioned? I can pay it all to you, or split it 50/50 with yourself and Joni?

Comment 39 by, Oct 4 2012

You can pay it all to our company's bank account. We will handle splitting it ourselves. Please let me know how and when to pass you the details of the bank and account.

Comment 40 by, Oct 16 2012

Labels: -reward-unpaid
Ok, payment ready for wire. It can take a week or two from here but it's all lined up.

Comment 41 by, Oct 17 2012

Alright, thank you!

Comment 42 by, Nov 13 2012

Labels: -Restrict-View-SecurityTeam
De-restricting, because:

1) It's fixed in critical MS bulletin

2) There seems to be some confusion over whether the vulnerability is remotely triggerable. This report authoritatively notes that it is.

Comment 43 by, Dec 18 2012

Labels: -SecSeverity-Critical SecSeverity-None Restrict-AddIssueComment-EditIssueCc
Flagging as severity-none since this is a bug in Microsoft's font stack, rather than a bug in Chrome.

Comment 44 by, Dec 20 2012

Status: Fixed

Comment 45 by, Mar 10 2013

Project Member
Labels: -Type-Security -Area-Internals -Feature-Fonts -SecSeverity-None -Mstone-22 Cr-Content-Fonts M-22 Cr-Internals Security-Severity-None Type-Bug-Security

Comment 46 by, Mar 21 2013

Project Member
Labels: -Security-Severity-None Security_Severity-None

Comment 47 by, Apr 5 2013

Project Member
Labels: Cr-Blink

Comment 48 by, Apr 6 2013

Project Member
Labels: -Cr-Content-Fonts Cr-Blink-Fonts

Comment 49 by, Nov 18 2013

Labels: -Type-Bug-Security Type-Bug
Bulk unrestriction of Severity-none bugs.

Sign in to add a comment