[FD] 1503A - Chrome - ui::AXTree::Unserialize use-after-free

[Berend-Jan Wever]

T*L;DR*
After 60 day deadline has passed, I am releasing details on an unfixed
use-after-free vulnerability in Chrome's accessibility features, which are
disabled by default. The issue does not look exploitable.

*More details*
http://berendjanwever.blogspot.nl/2015/07/1503a-chrome-uiaxtreeunserialize-use.html


*Chromium bug*https://code.google.com/p/chromium/issues/detail?id=479743

Cheers,

SkyLined

 Gratuitous ASCII
-


db
db
   SOMEBODYb   SETUPUS  SS
SS
  SSdb db  db CSb, db CD CD SS
SS
 ;S; CTHEBOMBSb  ,SY' CMOVEZIGb  ,SY'   `" SS_  SS
SS
,SP SS   SS   _qSS"  SP   _qSS" iD b,_  SS
SS
   dSYbiS'   SS CS7"SS ,SP` CS7"SS,SS` SS `'*YD YP
YP
 dS'  Yb  ,S*SP SS  _,S7'   SS_,dSP'
SS
   4S' YD C*   CSP` YPCS7"` YP   CS7'  YP   CD
CD


for great
justice

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] JScript 5.7 (MSIE 8) RegExpBase::FBadHeader regular expression use-after-free

[Berend-Jan Wever]

Recompiling the regular expression pattern during a replace can cause
the code
to reuse a freed string, but only if the string is freed from the cache by
allocating and freeing a number of strings of certain size.

CVE-2015-2482:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2482
ZDI-15-515:http://www.zerodayinitiative.com/advisories/ZDI-15-515/
MS15-108:  https://technet.microsoft.com/en-us/library/security/MS15-108

Repro:

  var r=new RegExp("A|x|x|xx|+", "g");
  "A".replace(r, function (){
for (var j = 0; j < 16; j++) new Array(0x1000).join("B");
r.compile();
  });


Repro-in-a-tweet:
https://twitter.com/berendjanwever/status/654048253047140352

Cheers,

SkyLined

Follow me on twitter for a new browser bug every* day!
https://twitter.com/berendjanwever

(* might be more than one some days)

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Microsoft Edge CDOMTextNode::get_data type confusion

[Berend-Jan Wever]

Hey,

Last Tuesday, Microsoft fixed a security issue in Microsoft Edge that I
was aware of, but had not had time to report. (i.e. I was waiting for
vulnerability contributor programs to look over my analysis and make me
an offer for the information). Since this issue has been fixed, I have
published my analysis on my blog
.

In short: Specially crafted Javascript inside an HTML page can trigger a
type confusion bug in Microsoft Edge that allows accessing a C++ object
as if it was a BSTR string. This can result in information disclosure,
such as allowing an attacker to determine the value of pointers to other
objects and/or functions. This information can be used to bypass ASLR
mitigations. It may also be possible to modify arbitrary memory and
achieve remote code execution, but this was not
investigated.

Cheers,

SkyLined

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2016-0199 / MS16-063: MSIE 11 garbage collector attribute type confusion

[Berend-Jan Wever]

CVE-2016-0199 / MS16-063: MSIE 11 garbage collector attribute type confusion

This information is available in an easier to read format on my blog at
http://blog.skylined.nl/

With [MS16-063] Microsoft has patched [CVE-2016-0199]: a memory
corruption bug
in the garbage collector of the JavaScript engine used in Internet
Explorer 11.
By exploiting this vulnerability, a website can causes this garbage
collector
to handle some data in memory as if it was an object, when in fact it
contains
data for another type of value, such as a string or number. The garbage
collector code will use this data as a virtual function table (vftable)
in order
to make a virtual function call. An attacker has enough control over
this data
to allow execution of arbitrary code.

Known affected software and attack vectors
--
+ **Microsoft Internet Explorer 11** (all versions before the June 2016
patch)

  An attacker would need to get a target user to open a specially crafted
  webpage. Disabling JavaScript should prevent an attacker from
triggering the
  vulnerable code path.

Repro
-
I've created two separate html files that can be used to reproduce this
issue
and shows control over a 32-bit vftable pointer in x86 versions of MSIE or a
partial control over a 64-bit vftable pointer in x64 versions.

HTML



  oElement = document.createElement("IMG");
  var oAttr = document.createAttribute("loop");
  oAttr.nodeValue = oElement;
  oElement.loop = 0x41424344; // Set original value data to 44 43 42 41
  oElement.setAttributeNode(oAttr); // Replace oElement with original
value data
  oElement.removeAttributeNode(oAttr);
  CollectGarbage(); // Use original value data as address 0x41424344 of
a vftable


(I've had to use xcript rather than script because Gmail refused to send it
otherwise, see https://support.google.com/mail/answer/6590 for the reason.)

Description
---
When `setAttributeNode` is used to set an attribute of a HTML element,
and the
`Attr` node's `nodeValue` is not a valid value, this `nodeValue` is set
to the
value the attribute had before the call. This can happen for instance
when you
try to set an attribute that must have a string or number value by using an
`Attr` node with a HTML element as its `nodeValue` (as this is not a
string or
number). The HTML element in `nodeValue` is replaced with the string or
number
value the attribute had before the call to `setAttributeNode`.

If the `Attr` node is then removed using `removeAttributeNode` and the
garbage
collector runs, the code appears to assume the nodeValue still contains an
object, rather than the string or number it has been changed into. This
causes
the code to use the data for the string or number value as if it was a C++
object. It attempts to determine a function pointer for a method from the
object's virtual function table before calling this function using the
pointer.

If the previous value is a string, the character data from the string is
used
to calculate the function pointer. If the previous value is a number,
the value
of the number is used. This provides an attacker with a large amount of
control
over the function pointer and may allow execution of arbitrary code.

Scanner
---
I build a "scanner" to analyze this issue and help create two
proof-of-concept
files that show control over the vftable pointer. More details and the
source
for these can be found on my blog at http://blog.skylined.nl.

Cheers,

SkyLined


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Magic values in 32-bit processes on 64-bit OS-es and how to exploit them

[Berend-Jan Wever]

(You can read all this information in more detail on
http://blog.skylined.nl)

Software components such as memory managers often use magic values to
mark memory as having a certain state. These magic values can be used
during debugging to determine the state of the memory, and have often
(but not always) been chosen to coincide with addresses that fall
outside of the user-land address space on 32-bit versions of the
Operating System. This can help detect vulnerabilities by causing an
access violation when such magic value is used as a pointer as well as
mitigate exploitation of such vulnerabilities by making it impossible to
have this "poisoned" pointer refer allocated memory under the attacker's
control.

For instance, Microsoft's C++ debugging runtime library initializes
stack memory to 0x. When an uninitialized object pointer is used
to read the value of a property or call a method of the object, this
reliably causes an access violation on 32-bit versions of Microsoft
Windows and prevents an easy path to exploitation.

The Wikipedia article on magic values has a list containing some of the
values and when they are used. You will notice how all of the values
used on Windows have their high bit set (i.e. >= 0x8000). As explain
earlier, this is because on 32-bit versions of Windows these addresses
cannot be used to allocate memory in user-land by default. Windows does
have a /3GB switch that allows you to change the upper limit for
user-land memory to 0xC000, but AFAIK this is not used very often
and still excludes a large number of magic values.

Magic values on 64-bit OS-es

On 64-bit architectures, there is no need to reserve part of the 32-bit
address space for kernel memory. Consequently, a 32-bit applications
running on 64-bit versions of Windows is able to allocate memory in
almost the entire 32-bit address range. This allows 32-bit applications
to allocate more memory, including at all addresses that these magic
values can reference. Ever since their introduction over 10 years ago,
Javascript heap-sprays in web-browsers in particular offers an attacker
the ability to finely control memory allocations and their content for
use in exploits.

Proof-of-Concept

Last year I stumbled upon a two different bugs in two different web
browsers where a magic value was used to mark memory which had not yet
been initialized. Both vulnerabilities allowed me to get the web
browsers to use the memory as a pointer before initializing it to a sane
value. using Javascript, I was able to allocate memory at the magic
value address the web browsers ended up using and store information at
this location that allowed me to exploit both of these two
vulnerabilities. These issues have both been address, so I can discuss
them in more detail.

CVE-2014-1592 Firefox xul.dll!nsHtml5TreeOperation use of poisoned memory

Mozilla 1088635 
covers a bug in Firefox that could it to use data from a freed and
"poisoned" object through specially crafted HTML, which resulted in
access violations around address |0x5a5a5a5a| on x86 systems. The memory
used to back the object was marked with this magic value after it was
freed. Because this magic value resulted in an address can be allocated
even on 32-bit versions of Windows, I suggested in Mozilla 1182002
 that the value
get updated with something that makes it a little harder to exploit.
This and other reasons for changing the magic values, led to magic
values being changed to |0xe4e4e4e4| for uninitialized memory and
|0xe5e5e5e5| for freed memory.

verifier!AVrfDebugPageHeapAllocate incorrect memory initialization a.k.a
Google Chrome use of uninitialized FLS pointer

In August last year, I found what appear to be a thread-safety
vulnerability in Google Chrome when handling audio data, that could lead
to use of an uninitialized pointer. This issue is only visible when
running Chrome with page heap enabled, as the memory used to store the
pointer appears to be set to 0x after allocation when page heap
is not enabled. This means this NULL pointer will not be used by the
code to reference memory. However, when running Chrome with page heap
enabled, the pointer will be initialized to 0xD0D0D0D0 and gets used in
code that allows at least freeing of arbitrary memory pointers.

After doing a more thorough analysis, Ricky Zhou explained to me in the
Chromium bug
 that the
issue is not in Chromium, but in |verifier.dll|. This DLL is used to
implement page heap on Windows. The problem is that in
|verifier!AVrfDebugPageHeapAllocate|, the |HEAP_ZERO_MEMORY| flag is
sometimes ignored, which in this case caused the memory to get
initialized with the wrong value. I reported this issue to Microsoft at
the end of October last year and after getting the MSRC case number
31596, I never heard back from them again.

Mit

Re: [FD] Magic values in 32-bit processes on 64-bit OS-es and how to exploit them

[Berend-Jan Wever]

Obviously, this may be of interest to authors of security software that
aims to mitigate exploitation of 0-day: it should be possible to:
1) actively reserve memory regions referenced by such pointers to
prevent allocation by an exploit. The additional address space
fragmentation should not be a problem for most applications, but I have
no data, so you might want to consider:
2) analyze various binaries for their use of magic values, and actively
reserve only those memory regions referenced by such pointers. If that
still causes problems in some applications:
3) white-/black-list applications for this mitigation.

If any of the authors of EMET are reading this, please let me know so I
don't have to write you an email to make sure you have seen it for
consideration as an added mitigation.

Cheers,

SkyLined


On 21-06-2016 17:01, Berend-Jan Wever wrote:
> (You can read all this information in more detail on
> http://blog.skylined.nl)
>
> Software components such as memory managers often use magic values to
> mark memory as having a certain state. These magic values can be used
> during debugging to determine the state of the memory, and have often
> (but not always) been chosen to coincide with addresses that fall
> outside of the user-land address space on 32-bit versions of the
> Operating System. This can help detect vulnerabilities by causing an
> access violation when such magic value is used as a pointer as well as
> mitigate exploitation of such vulnerabilities by making it impossible to
> have this "poisoned" pointer refer allocated memory under the attacker's
> control.
>
> For instance, Microsoft's C++ debugging runtime library initializes
> stack memory to 0x. When an uninitialized object pointer is used
> to read the value of a property or call a method of the object, this
> reliably causes an access violation on 32-bit versions of Microsoft
> Windows and prevents an easy path to exploitation.
>
> The Wikipedia article on magic values has a list containing some of the
> values and when they are used. You will notice how all of the values
> used on Windows have their high bit set (i.e. >= 0x8000). As explain
> earlier, this is because on 32-bit versions of Windows these addresses
> cannot be used to allocate memory in user-land by default. Windows does
> have a /3GB switch that allows you to change the upper limit for
> user-land memory to 0xC000, but AFAIK this is not used very often
> and still excludes a large number of magic values.
>
> Magic values on 64-bit OS-es
>
> On 64-bit architectures, there is no need to reserve part of the 32-bit
> address space for kernel memory. Consequently, a 32-bit applications
> running on 64-bit versions of Windows is able to allocate memory in
> almost the entire 32-bit address range. This allows 32-bit applications
> to allocate more memory, including at all addresses that these magic
> values can reference. Ever since their introduction over 10 years ago,
> Javascript heap-sprays in web-browsers in particular offers an attacker
> the ability to finely control memory allocations and their content for
> use in exploits.
>
> Proof-of-Concept
>
> Last year I stumbled upon a two different bugs in two different web
> browsers where a magic value was used to mark memory which had not yet
> been initialized. Both vulnerabilities allowed me to get the web
> browsers to use the memory as a pointer before initializing it to a sane
> value. using Javascript, I was able to allocate memory at the magic
> value address the web browsers ended up using and store information at
> this location that allowed me to exploit both of these two
> vulnerabilities. These issues have both been address, so I can discuss
> them in more detail.
>
> CVE-2014-1592 Firefox xul.dll!nsHtml5TreeOperation use of poisoned memory
>
> Mozilla 1088635 <https://bugzilla.mozilla.org/show_bug.cgi?id=1088635>
> covers a bug in Firefox that could it to use data from a freed and
> "poisoned" object through specially crafted HTML, which resulted in
> access violations around address |0x5a5a5a5a| on x86 systems. The memory
> used to back the object was marked with this magic value after it was
> freed. Because this magic value resulted in an address can be allocated
> even on 32-bit versions of Windows, I suggested in Mozilla 1182002
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1182002> that the value
> get updated with something that makes it a little harder to exploit.
> This and other reasons for changing the magic values, led to magic
> values being changed to |0xe4e4e4e4| for uninitialized memory and
> |0xe5e5e5e5| for freed memory.
>
> verifier!AVrfDebugPageHeapAllocate incorrect memory initialization a.k.a
> Google Chrome u

Re: [FD] Magic values in 32-bit processes on 64-bit OS-es and how to exploit them

[Berend-Jan Wever]

I've released a Proof-of-Concept html page that uses Javascript typed
arrays in 32-bit Chrome and Firefox on 64-bit Windows to allocated
address 0xDEADBEEF and store the value 0xBADC0DED there. You can find
this and details on the implementation at
http://blog.skylined.nl/20160622001.html.

That page also contains a write-up on CVE-2014-1736; a vulnerability in
32-bit Chrome on 64-bit Windows that allows arbitrary read&write that
was caused by the fact that that 64-bit Windows allows allocations of
memory at address 0x8000 and up.

On 21-06-2016 19:45, Berend-Jan Wever wrote:
> Obviously, this may be of interest to authors of security software
> that aims to mitigate exploitation of 0-day: it should be possible to:
> 1) actively reserve memory regions referenced by such pointers to
> prevent allocation by an exploit. The additional address space
> fragmentation should not be a problem for most applications, but I
> have no data, so you might want to consider:
> 2) analyze various binaries for their use of magic values, and
> actively reserve only those memory regions referenced by such
> pointers. If that still causes problems in some applications:
> 3) white-/black-list applications for this mitigation.
>
> If any of the authors of EMET are reading this, please let me know so
> I don't have to write you an email to make sure you have seen it for
> consideration as an added mitigation.
>
> Cheers,
>
> SkyLined
>
>
> On 21-06-2016 17:01, Berend-Jan Wever wrote:
>> (You can read all this information in more detail on
>> http://blog.skylined.nl)
>>
>> Software components such as memory managers often use magic values to
>> mark memory as having a certain state. These magic values can be used
>> during debugging to determine the state of the memory, and have often
>> (but not always) been chosen to coincide with addresses that fall
>> outside of the user-land address space on 32-bit versions of the
>> Operating System. This can help detect vulnerabilities by causing an
>> access violation when such magic value is used as a pointer as well as
>> mitigate exploitation of such vulnerabilities by making it impossible to
>> have this "poisoned" pointer refer allocated memory under the attacker's
>> control.
>>
>> For instance, Microsoft's C++ debugging runtime library initializes
>> stack memory to 0x. When an uninitialized object pointer is used
>> to read the value of a property or call a method of the object, this
>> reliably causes an access violation on 32-bit versions of Microsoft
>> Windows and prevents an easy path to exploitation.
>>
>> The Wikipedia article on magic values has a list containing some of the
>> values and when they are used. You will notice how all of the values
>> used on Windows have their high bit set (i.e. >= 0x8000). As explain
>> earlier, this is because on 32-bit versions of Windows these addresses
>> cannot be used to allocate memory in user-land by default. Windows does
>> have a /3GB switch that allows you to change the upper limit for
>> user-land memory to 0xC000, but AFAIK this is not used very often
>> and still excludes a large number of magic values.
>>
>> Magic values on 64-bit OS-es
>>
>> On 64-bit architectures, there is no need to reserve part of the 32-bit
>> address space for kernel memory. Consequently, a 32-bit applications
>> running on 64-bit versions of Windows is able to allocate memory in
>> almost the entire 32-bit address range. This allows 32-bit applications
>> to allocate more memory, including at all addresses that these magic
>> values can reference. Ever since their introduction over 10 years ago,
>> Javascript heap-sprays in web-browsers in particular offers an attacker
>> the ability to finely control memory allocations and their content for
>> use in exploits.
>>
>> Proof-of-Concept
>>
>> Last year I stumbled upon a two different bugs in two different web
>> browsers where a magic value was used to mark memory which had not yet
>> been initialized. Both vulnerabilities allowed me to get the web
>> browsers to use the memory as a pointer before initializing it to a sane
>> value. using Javascript, I was able to allocate memory at the magic
>> value address the web browsers ended up using and store information at
>> this location that allowed me to exploit both of these two
>> vulnerabilities. These issues have both been address, so I can discuss
>> them in more detail.
>>
>> CVE-2014-1592 Firefox xul.dll!nsHtml5TreeOperation use of poisoned memory
>>
>> Mozilla 1088635 <https://bugzilla.mozilla.org/s

[FD] Microsoft Internet Explorer 9 MSHTML CAttrArray use-after-free details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the first
entry in that series.
The below information is also available on my blog at
http://blog.skylined.nl/20161101001.html. There you can find a repro
that triggered this issue in addition to the information below.
Follow me on twitter.com/berendjanwever for daily browser bugs.

MSIE 9 MSHTML CAttrArray use-after-free
===
(MS14-056, CVE-2014-4141)

Synopsis

A specially crafted webpage can cause Microsoft Internet Explorer to
reallocate a memory buffer in order to grow it in size. The original
buffer will be copied to newly allocated memory and then freed. The code
continues to use the freed copy of the buffer.

Known affected versions, attack vectors and mitigations
---
+ Microsoft Internet Explorer 9

  An attacker would need to get a target user to open a specially
  crafted webpage. Disabling JavaScript should prevent an attacker from
  triggering the vulnerable code path.

Analysis

The CAttrArray object initially allocates a CImplAry buffer of 0x40
bytes, which can store 4 attributes. When the buffer is full, it is
grown to 0x60 bytes. A new buffer is allocated at a different location
in memory and the contents of the original buffer is copied there. The
repro causes the code to do this, but the code continues to access the
original buffer after it has been freed.

Exploit
---
If an attacker was able to cause MSIE to allocate 0x40 bytes of memory
and have some control over the contents of this memory before MSIE
reuses the freed memory, there is a chance that this issue could be used
to execute arbitrary code. I did not attempt to write an exploit for
this vulnerability myself.

Timeline

* April 2014: This vulnerability was found through fuzzing.
* July 2014: This vulnerability was submitted to [ZDI][].
* July 2014: ZDI reports a collision with a report by another
  researcher. (From the credits given by Microsoft and ZDI, I surmise
  that it was Peter 'corelanc0d3r' Van Eeckhoutte of Corelan who
  reported this issue.
* October 2014: Microsoft release MS14-056, which addresses this issue.
* November 2016: Details of this issue are released.


Cheers,

SkyLined

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] MSIE 11 MSHTML CView::CalculateImageImmunity use-after-free details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the second
entry in that series.

The below information is also available on my blog at
http://blog.skylined.nl/20161102001.html. There you can find a repro
that triggered this issue in addition to the information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 11 MSHTML CView::CalculateImageImmunity UAF


(The fix and CVE number for this bug are not known)

Synopsis

Setting the `listStyleImage` property of an Element object causes MSIE
11 to allocate 0x4C bytes for an "image context" structure, which
contains a reference to the document object as well as a reference to
the same `CMarkup` object as the document. When the element is removed
from the document/document fragment, this image context is freed on the
next "draw". However, the code continues to use the freed context almost
immediately after it is freed.

Known affected versions, attack vectors and mitigations
---
+ Microsoft Internet Explorer 11

  An attacker would need to get a target user to open a specially
  crafted webpage. As far as can be determined, disabling JavaScript
  should prevent an attacker from triggering the vulnerable code path.

Exploit
---
I tried a few tricks to see if there was an easy way to reallocate the
freed memory before the reuse, but was unable to find anything. I do not
know if there is a way to cause further reuse of the freed memory later
on in the code. Running the repro as-is without page heap does not
appear to trigger crashes. It does not appear that there is enough time
between the free and reuse to exploit this issue.

Timeline

* May 2014: This vulnerability was found through fuzzing.
* June 2014: This vulnerability was submitted to ZDI.
* July 2014: ZDI rejects the submission.
* November 2016: The issue does not reproduce in the latest build of
  MSIE 11.
* November 2016: Details of this issue are released.

Unfortunately, my records of what happened after ZDI rejected the issue
are patchy. It appears that I did not pursue reporting the issue
anywhere else, but Microsoft does appear to have patched the issue, as I
can no longer reproduce it.

Cheers,

SkyLined


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] MSIE 10 MSHTML CElement::GetPlainTextInScope out-of-bounds read

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the third
entry in that series.

The below information is also available on my blog at
http://blog.skylined.nl/20161103001.html. There you can find a repro
that triggered this issue in addition to the information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 10 MSHTML CElement::GetPlainTextInScope out-of-bounds read
===

(The fix and CVE number for this bug are not known)

Synopsis

An unknown issue in Microsoft Internet Explorer 10 could cause it to
read data out-of-bounds. This issue was fixed before I was able to
analyze it in detail, hence I did not determine exactly what the root
cause was.

Known affected software
---
  + Internet Explorer 10

An attacker would need to get a target user to open a specially
crafted web-page. No special configuration settings are required in
order to trigger the issue. No realistic mitigations are known;
Javascript is not required to trigger the issue.

Description
---
My fuzzers were using a predecessor of BugId
(https://github.com/SkyLined/BugId) to generate a report whenever they
found a bug. Unfortunately, this wasn't as sophisticated as BugId is, so
the information contained in these report is not as helpful. Still, I saved
three reports, for crashes with slightly different stacks. This could
have been caused by three different versions of MSIE 10 (every month
when Microsoft released a new version with patches, the code may be
optimized differently, which could explain these differences). It could
also have been caused by the fuzzing framework attempting to reduce the
size of the repro by cutting out chunks, which could lead to slightly
different code-paths. Unfortunately, I do not know which.

Either way, looking at the reports that were automatically generated for
this bug (which can be found at the end of this article), one can find
the following interesting information on all three:
1) The stack tells us that there was a call to `CTextArea::Notify`,
   which suggests the one `textarea` element found in the repro is
   important to triggering the issue.
2) The stack also tells us that there was a call to
   `CElement::GetPlainTextInScope`, which is commonly used to extract
   the text inside an element, so the text content in the `textarea`
   element is probably also important to triggering the issue. Since
   there is no closing `` tag, this could be all the data in
   the repro after the opening `` tag, or up to the first
   closing tag (``), depending on how the HTML parser works.
3) Clicking on stack `Frame 1` in the report shows the report contains
   some disassembly and registers. Unfortunately, the code that
   generated the disassembly had a bug and started at the wrong
   address, so this isn't very useful. However, clicking on `Registers`
   will show that:
   * The crash happened in `MSHTML!memcpy`
   * the code looked for a unicode linefeed (0x000A) immediately after
 data pointed to by `edx`.
   The `Registers` section does suggest the following:
   * `ecx` was 0, so maybe all the data was already copied at this
  point?
   * `edx` was apparently used as a pointer to the data being copied.

Online documentation for `memcpy` does not mention this behavior of
looking for a linefeed, so it could be that `MSHTML` has an odd
implementation, or that the symbol is simply wrong. I'm assuming that
the code did copy the text content of a `textarea` element and was
looking for a `CR`, `LF` line terminator. Unfortunately, the data at
`edx` only contained one or the other, causing the code to look for the
`LF` outside of the memory area allocated to store the data.

Exploit
---
The above suggests that there is limit opportunity for exploiting this
issue: it may be possible to determine if a memory block allocated for a
string of an attacker controlled size is followed by a memory block that
starts with the bytes `0A 00`. To better understand the impact, one
would have to get an older version of MSIE 10 and debug the crash.
Unfortunately, I did not have time to do so.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] MSIE 9 MSHTML CPtsTextParaclient::CountApes out-of-bounds read

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the third
entry in that series.

The below information is also available on my blog at
http://blog.skylined.nl/20161104001.html. There you can find a repro
that triggered this issue in addition to the information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 9 MSHTML CPtsTextParaclient::CountApes out-of-bounds read
==

Synopsis

A specially crafted webpage can cause Microsoft Internet Explorer 9 to
access data before the start of a memory block. An attack that is able
to control what is stored before this memory block may be able to
disclose information from memory or execute arbitrary code.


Known affected versions, attack vectors and mitigations
---
+ **Microsoft Internet Explorer 9**

  An attacker would need to get a target user to open a specially
  crafted webpage. As far as can be determined, disabling JavaScript
  should prevent an attacker from triggering the vulnerable code path.

Description
---
It's quite common in MSIE for an object to "contain" another object in
memory, and for MSIE to add offsets to pointers to find a contained
object, or to subtract offsets to find the container of such a contained
object. It appears that this vulnerability revolves around MSIE assuming
one object is contained inside another, whereas in reality it is not.
The code is using a flag in the object to determine if it is a
"stand-alone" object or a "contained" object. The bug is that either the
code is using this flag incorrectly (the flag is correct, but does not
indicate the object is a "contained" object) or the flag has been set
incorrectly (the code is correct, but the flag should not have been set
as the object is not "contained" in another object).

Eventually, a method is called to operate on an object using a pointer
at an offset *before* allocated memory.

Exploitation

Using Heap Feng-Shui, it may be possible to allocated a heap block
immediately before the one used in the bug and control its content in
order to control the data the code is operating on. Unfortunately, at
the time I did not look at what the code did with the data if the access
violation could be prevented, so it's not possible for me to say exactly
what an attacker might do with this vulnerability. But one can speculate
that this might allow an attacker to have the code use some secret value
(e.g. a pointer to a function in a modules) in a way that allows him/her
to retrieve the value (i.e. information disclosure). It might be
possible to have the code modify a value located anywhere in memory,
and/or have the code call/jump to a location of an attackers choosing
(i.e. arbitrary code execution).

I did not investigate the crash on x64, but I can only imagine the code
is the same, but the offsets are different.

Cheers,

SkyLined


___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] VBScript CRegExp..Execute use of uninitialized memory details (MSIE 8-11, IIS, CScript.exe/WScript.exe)

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the fifth
entry in that series.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161107001.html. There you can find a repro
that triggered this issue in addition to the information below as well
as a Proof-of-Concept exploit.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

VBScript CRegExp::Execute use of uninitialized memory
=
https://technet.microsoft.com/en-us/library/security/MS14-080
https://technet.microsoft.com/en-us/library/security/MS14-084
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6363

Synopsis

A specially craft script can cause the VBScript engine to access data
before initializing it. An attacker that is able to run such a script in
any application that embeds the VBScript engine may be able to control
execution flow and execute arbitrary code. This includes all versions of
Microsoft Internet Explorer.

Known affected versions, attack vectors and mitigations
---
* vbscript.dll
  The issue affects versions 5.6 through 5.8 and both the 32- and 64-bit
  vbscript.dll binaries.

* Windows Script Host
  VBScript can be executed in the command line using cscript.exe/
  wscript.exe. An attacker would need to find a script running on a
  target machine that accepts an attacker supplied regular expression
  and a string, or be able to execute his/her own script. However,
  since the later should already provide an attacker with arbitrary
  code execution, no additional privileges are gained by exploiting
  this vuln.

* Microsoft Internet Explorer
  VBScript can be executed from a webpage; MSIE 8, 9, 10 and 11 were
  tested and are all affected. MSIE 11 requires a META tag to force it
  to render the page as an earlier version, as MSIE 11 attempts to
  deprecate vbscript (but fails, so why bother?).
  An attacker would need to get a target user to open a specially
  crafted webpage. Disabling scripting, particularly VBScript, should
  prevent an attacker from triggering the vulnerable code path.
  Enabling *Enhanced Protected Mode* appears to disable VBScript on my
  systems, but I have been unable to find documentation online that
  confirms this is by design.

* Internet Information Server (IIS)
  If Active Server Pages (ASP) are enabled, VBScript can be executed in
  Active Server Pages. An attacker would need to find an asp page that
  accepts an attacker supplied regular expression and a string, or be
  able to inject VBScript into an ASP page in order to trigger the
  vulnerability.

Description
---
During normal operation, when you execute the `RegExp.Execute` method
from `VBScript` the code in vbscript.dll executes the `CRegExp::Execute`
function. This function creates a `CMatch` object for each match found,
and stores pointers for all of these `CMatch` objects in a singly linked
list of `CMatchBlock` structures (Note: the vbscript.dll symbols do not
provide a name for this structure, so I gave it this name). Each
`CMatchBlock` structure can store up to 16 such pointers, as well as a
pointer to the next `CMatchBlock`. This
last pointer is NULL unless all pointers in the `CMatchBlock` object are
in use and more storage is needed, in which case a new `CMatchBlock`
object is created and a link to the new object is added to the last one
in the list. The code counts how many matches it has found so far, and
this corresponds to the number of `CMatch` objects it has allocated.

When an error occurs in this part of the code, the error handling code
will try to clean up and free all `CMatchBlock` structures created
before the error occurred. To do this, it walks the linked list of
`CMatchBlock` structures and for each structure, release each `CMatch`
object in the structure. All `CMatchBlock` structures except the last
one should have 16 such pointers, the last `CMatchBlock` structure can
have 1-16, depending on how many matches where found in total. This
appears to have been designed to count how many `CMatch` objects it has
yet to free. This counter is initialized to the number of matches found
before the error occurred and should be decremented whenever the code
frees a `CMatch` object, so the code can determine how many `CMatch`
object are in the last `CMatchBlock` structure. However, this code
neglects to decrement this counter. This causes the code to assume all
`CMatchBlock` structures have 16 `CMatch` object pointers if there were
more than 16 matches in total, and attempt to release 16 `CMatch`
objects from the last `CMatchBlock` structure, even if less than 16
pointers to `CMatch` objects were stored there. This results in the code
using uninitialized memory as a pointer to an object on which it
attempts to call the `Release` method.

Timeline

* March 2014:

[FD] VBScript RegExpComp::PnodeParse out-of-bounds read details (MSIE 8-11, IIS, CScript.exe/WScript.exe)

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the sixth
entry in that series.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161108001.html. There you can find a repro
that triggered this issue in addition to the information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

VBScript RegExpComp::PnodeParse out-of-bounds read
==
(The fix and CVE number for this bug are not known)

Synopsis

A specially crafted script can cause the VBScript engine to read data
beyond a memory block for use as a regular expression. An attacker that
is able to run such a script in any application that embeds the VBScript
engine may be able to disclose information stored after this memory
block. This includes all versions of Microsoft Internet Explorer.

Known affected versions, attack vectors and mitigations
---
* vbscript.dll
  The issue is known to have affected versions 5.8.7600.16385 up to
  5.8.9600.16384,   and both the 32- and 64-bit vbscript.dll binaries.
  It may also impact earlier versions as well as later versions as I am
  not sure exactly when the issue was addressed by Microsoft.

* Windows Script Host
  VBScript can be executed in the command line using  cscript.exe/
  wscript.exe. An attacker would need to find a script running on a
  target machine that accepts an attacker supplied regular expression
  and a string, or be able to execute his/her own script. However,
  since the later should already provide an attacker with arbitrary
  code execution, no additional privileges are gained by exploiting
  this vuln.

* Microsoft Internet Explorer
  VBScript can be executed from a web-page; MSIE 8, 9, 10 and 11 were
  tested and are all affected. MSIE 11 requires a META tag to force it
  to render the page as an earlier version, as MSIE 11 attempts to
  deprecate VBScript (but fails, so why bother?).
  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling scripting, particularly VBScript, should
  prevent an attacker from triggering the vulnerable code path.
  Enabling *Enhanced Protected Mode* appears to disable VBScript on my
  systems, but I have been unable to find documentation on-line that
  confirms this is by design.

* Internet Information Server (IIS)
  If Active Server Pages (ASP) are enabled, VBScript can be executed in
  Active Server Pages. An attacker would need to find an asp page that
  accepts an attacker supplied regular expression and a string, or be
  able to inject VBScript into an ASP page in order to trigger the
  vulnerability.

Description
---
When a regular expression is used to find matches in a string, it is
first "compiled". During compilation, when a '\' escape character is
encountered, the RegExpComp::PnodeParse function reads the next
character to determine the type of escape sequence. However, if the last
character in a regular expression is a '\' character, the code will read
and use the terminating '\0' character as the second character in the
escape sequence. This causes the code to ignore the end of the string
and continue to compile whatever data is found beyond it as if it was
part of the regular expression.

Time-line
-
* June 2014*: This vulnerability was found through fuzzing, but I was
  unable to reproduce it outside of my fuzzing framework for unknown
  reasons.
* April 2015: This vulnerability was found through fuzzing again.
* April 2015: This vulnerability was submitted to ZDI.
* May 2015: ZDI rejects the submission.
* November 2016: The issue does not reproduce in the latest build of
  MSIE 11.
* November 2016: Details of this issue are released.

Cheers,

SkyLined

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] MSIE 9-11 MSHTML PROPERTYDESC::HandleStyleComponentProperty OOB read details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
seventh entry in that series.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161109001.html. There you can find a repro
that triggered this issue in addition to the information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 9-11 MSHTML PROPERTYDESC::HandleStyleComponentProperty OOB read

(MS16-104, CVE-2016-3324)

Synopsis

A specially crafted web-page can cause Microsoft Internet Explorer to
assume a CSS value stored as a string can only be `"true"` or `"false"`.
To determine which of these two values it is, the code checks if the
fifth character is an `'e'` or a `"\0"`. An attacker that is able to set
it to a smaller string can cause the code to read data out-of-bounds and
is able to determine if a `WCHAR` value stored behind that string is
`"\0"` or not.

Known affected versions, attack vectors and mitigations
---
* MSIE 9-11 (earlier versions were not tested)

  An attacker would need to get a target user to open a specially
  crafted webpage. Disabling JavaScript should prevent an attacker from
  triggering the vulnerable code path.

Description
---
Certain code that handles CSS properties in MSIE assumes that the
property value is always a string set to either `"true"` or `"false"`.
To determine which of these two values it is, the code checks if the
fifth character is `'\0'`. However, it is possible to set such values to
arbitrary strings, including a smaller string. This causes the code to
read beyond the end of the string and allows an attacker to determine if
an WORD stored after the string is `'\0'`.

The vulnerable code is in
`MSHTML!PROPERTYDESC::HandleStyleComponentProperty`.
This code is heavily branched to handle various types of CSS properties.
Luckily, the type being exploited is one of the first to be handled. The
code appears to assume that the value is provided as a pointer to a
`BSTR` which will always have a `WCHAR` at offset +8 that may be `'\0'`
or not. If this `WCHAR` is not `'\0'`, a CSS property is set to a
certain value, otherwise it is set to an empty string. As long as this
`BSTR` is always either be `"true"` or `"false"`, this code works as
expected. However, it is possible to provide an arbitrary value for this
`BSTR`, which can be shorter than 4 `WCHARs`. This would causing the
code to read a `WCHAR` outside of the memory used to store that `BSTR`.

Known properties of the type that leads to the vulnerable code path
include `textDecorationBlink`, `textDecorationLineThrough`,
`textDecorationLineNone`, `textDecorationOverline`, and
`textDecorationUnderline`.

Exploit
---
The value of a CSS property is updated based on the value of the fifth
`WCHAR`, and this CSS property can be read from Javascript to determine
if this `WCHAR` was `'\0'` or not. This allows a limited form of
information disclosure. During my testing, I used the
`textDecorationBlink` property, which can be used to set the CSS
`text-decoration` property to `"blink"` or an empty string.

Using Heap-Feng Shui, it may be possible to reuse memory allocated for
other strings that have since been freed and determine if they had a
`'\0'` `WCHAR` as their fifth character. This includes strings to should
normally not be accessible to the website, such as those from a
different origin. Also using Heap Feng-Shui, it may be possible to
allocate some interesting object immediately following the string, in
order to determine if a `WORD` at the start of that object is 0 or not.

Time-line
-
* Februari 2016: This vulnerability was found through fuzzing.
* Februari 2016: This vulnerability was submitted to ZDI, iDefense
  and EIP.
* March-July 2016: ZDI, iDefense and EIP all either reject the
  submission or fail to respond.
* July 2016: This vulnerability was reported to Microsoft with a
  60-day deadline to address the issue.
* August 2016: Microsoft is granted an 11 day extension to the
  deadline to address it in September's Patch Tuesday.
* September 2016: The vulnerability was address by Microsoft in
  MS16-104.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] WININET CHttpHeaderParser::ParseStatusLine out-of-bounds read details

[Berend-Jan Wever]

Some additional information:

It was pointed out to me that I did not adequately explain that WININET
is widely used by Microsoft applications to handle HTTP requests,
*AND* probably be all third-party applications that use Windows APIs to
make HTTP requests. All these applications may be vulnerable to the
issue, though it may be hard to exploit in most (if not all).

According to Microsoft this issue affected MSIE and Edge and was fixed
through MS16-104 (MSIE) and MS16-105 (Edge). Unfortunately, the below
email failed to mention MS16-104.

I do not know why Microsoft did not mention other applications in their
bulletins, nor why they have two fixes for specific applications (their
browsers), rather than one fix for a component of the Windows Operating
System.

One wonders what would happen on a system where you have previously
uninstalled both MSIE and Edge: do neither of the fixes apply and will
your system be left vulnerable? Let me know if you found out!

Cheers,

SkyLined


On 10-11-2016 10:49, Berend-Jan Wever wrote:
> Throughout November, I plan to release details on vulnerabilities I
> found in web-browsers which I've not released before. This is the
> eight entry in that series, although this particular vulnerability does
> not just affect web-browsers, but all applications that use WININET to
> make HTTP requests.
> 
> The below information is available in more detail on my blog at
> http://blog.skylined.nl/20161110001.html. There you can find a repro
> that triggered this issue in addition to the information below.
> 
> Follow me on http://twitter.com/berendjanwever for daily browser bugs.
> 
> WININET CHttpHeaderParser::ParseStatusLine out-of-bounds read
> =
> (MS16-105, CVE-2016-3325)
> 
> Synopsis
> 
> A specially crafted HTTP response can cause the `CHttpHeaderParser::
> ParseStatusLine` method in WININET to read data beyond the end of a
> buffer. The size of the read can be controlled through the HTTP
> response. An attacker that is able to get any application that uses
> WININET to make a request to a server under his/her control may be able
> to disclose information stored after this memory block. This includes
> Microsoft Internet Explorer.
> 
> Known affected versions, attack vectors and mitigations
> ---
> * WININET.dll
>   The issue was first discovered in pre-release Windows 10
>   fbl_release.140912-1613, which contained WININET.DLL version
>   11.00.9841.0.   This vulnerability appears to have been present in
>   all versions of Windows 10 since, up until the issue was addressed in
>   August 2016. As far as I can tell WININET is widely used by Microsoft
>   applications to handle HTTP requests. All these applications may be
>   vulnerable to the issue, though it may be hard to exploit in most (if
>   not all). No mitigations against the issue are known.
> 
> * Microsoft Internet Explorer
>   XMLHttpRequest can be used to trigger this issue - I have not tried
>   other vectors. To exploit the vulnerability, Javascript is most
>   likely required, so disabling Javascript should mitigate it.
> 
> * Microsoft Edge
>   XMLHttpRequest can be used to trigger this issue - I have not tried
>   other vectors. To exploit the vulnerability, Javascript is most
>   likely required, so disabling Javascript should mitigate it.
> 
> * Microsoft Windows Media Player
>   Opening a link to a media file on a malicious server can be used to
>   trigger the issue.
> 
> Description
> ---
> When WININET is processing a `HTTP 100` response, it expects another
> HTTP response to follow. WININET stores all data received from the
> server into a buffer, uses a variable to store an index into this buffer
> to track where it is currently processing data, and uses another
> variable to store the length of the remaining data in the buffer.
> 
> When processing the headers of the `HTTP 100` request, the code updates
> the index correctly, but does not decrement the length variable. When
> the code processes the next request, the length variable is too large,
> which can cause the code to read beyond the end of the data received
> from the server. This may cause it to parse data stored in the buffer
> that was previously received as part of the current HTTP response, and
> can even cause it to do the same for data read beyond the end of the
> buffer. This can potentially lead to information disclosure.
> 
> The larger the `HTTP 100` response is, the more bytes the code reads
> beyond the end of the data. Here are some example responses and their
> effect:
> 
>   "HTTP 100\r\n\r\nX" (12 bytes in HTTP 100 response)
> => read "X" and the n

[FD] WININET CHttpHeaderParser::ParseStatusLine out-of-bounds read details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
eight entry in that series, although this particular vulnerability does
not just affect web-browsers, but all applications that use WININET to
make HTTP requests.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161110001.html. There you can find a repro
that triggered this issue in addition to the information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

WININET CHttpHeaderParser::ParseStatusLine out-of-bounds read
=
(MS16-105, CVE-2016-3325)

Synopsis

A specially crafted HTTP response can cause the `CHttpHeaderParser::
ParseStatusLine` method in WININET to read data beyond the end of a
buffer. The size of the read can be controlled through the HTTP
response. An attacker that is able to get any application that uses
WININET to make a request to a server under his/her control may be able
to disclose information stored after this memory block. This includes
Microsoft Internet Explorer.

Known affected versions, attack vectors and mitigations
---
* WININET.dll
  The issue was first discovered in pre-release Windows 10
  fbl_release.140912-1613, which contained WININET.DLL version
  11.00.9841.0.   This vulnerability appears to have been present in
  all versions of Windows 10 since, up until the issue was addressed in
  August 2016. As far as I can tell WININET is widely used by Microsoft
  applications to handle HTTP requests. All these applications may be
  vulnerable to the issue, though it may be hard to exploit in most (if
  not all). No mitigations against the issue are known.

* Microsoft Internet Explorer
  XMLHttpRequest can be used to trigger this issue - I have not tried
  other vectors. To exploit the vulnerability, Javascript is most
  likely required, so disabling Javascript should mitigate it.

* Microsoft Edge
  XMLHttpRequest can be used to trigger this issue - I have not tried
  other vectors. To exploit the vulnerability, Javascript is most
  likely required, so disabling Javascript should mitigate it.

* Microsoft Windows Media Player
  Opening a link to a media file on a malicious server can be used to
  trigger the issue.

Description
---
When WININET is processing a `HTTP 100` response, it expects another
HTTP response to follow. WININET stores all data received from the
server into a buffer, uses a variable to store an index into this buffer
to track where it is currently processing data, and uses another
variable to store the length of the remaining data in the buffer.

When processing the headers of the `HTTP 100` request, the code updates
the index correctly, but does not decrement the length variable. When
the code processes the next request, the length variable is too large,
which can cause the code to read beyond the end of the data received
from the server. This may cause it to parse data stored in the buffer
that was previously received as part of the current HTTP response, and
can even cause it to do the same for data read beyond the end of the
buffer. This can potentially lead to information disclosure.

The larger the `HTTP 100` response is, the more bytes the code reads
beyond the end of the data. Here are some example responses and their
effect:

  "HTTP 100\r\n\r\nX" (12 bytes in HTTP 100 response)
=> read "X" and the next 11 bytes in memory as the next response.
  "HTTP 100\r\n\r\n" (12 bytes in HTTP 100 response)
=> read "" and the next 8 bytes in memory as the next response.
  "HTTP 100XXX\r\n\r\nX" (15 bytes in HTTP 100 response)
=> read "X" and the next 14 bytes in memory as the next response.
  "HTTP 100XXXXXX\r\n\r\nX..." (N bytes in HTTP 100 response)
=> read "X" and the next (N-1) bytes in memory as the next response.

Exploit
---
This issue is remarkably similar to [an issue in HTTP 1xx response
handling I found in Google
Chrome][https://code.google.com/p/chromium/issues/detail?id=299892] a
while back. That issue allowed disclosure of information from the main
process' memory through response headers. I attempted to leak some data
using this vulnerability by using the following response:

  "HTTP 100XXXXXX\r\nHTTP 200 X"

I was hoping this would cause the OOB read to save data from beyond the
end of the `HTTP 200` reponse in the `statusText` property of the
`XMLHttpRequest`, but I did not immediately see this happen; all I got
was "OK" or an empty string.

Unfortunately, I did not have time to reverse the code and investigate
further myself. All VCPs I submitted the issue to rejected it because
they though it was not practically exploitable.

Time-line
-
* October 2014: This vulnerability was found through fuzzing.
* October-November 2014: This vulnerability was submitted to ZD

[FD] Google Chrome blink Serializer::doSerialize bad cast details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
ninth entry in that series, and the first to not target a Microsoft browser.

The below information is available in more detail on my blog at
http://blog.skylined.nl/2016001.html.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

Google Chrome blink Serializer::doSerialize bad cast

(This fix and CVE number for this issue are not known)

Synopsis

When serializing JavaScript objects for sending to another window using
the `postMessage` method, the code in blink does not handle `Symbol`
objects correctly and attempts to serialize this kind of object as a
regular object, which results in a bad cast. An attacker that can
trigger this issue may be able to execute arbitrary code.

Known affected versions, attack vectors and mitigations
---
* Chrome 38
  An attacker would need to get a target user to open a specially
  crafted webpage. Disabling JavaScript should prevent an attacker from
  triggering the vulnerable code path.

Repro
-

  postMessage(Symbol());


Description
---
The repro causes a call to `blink::V8Window::postMessageMethodCustom`.
This method creates a `Serializer` object for the "script value" of the
symbol. In ``blink::`anonymous namespace'::Serializer::doSerialize`` the
code attempts to determine the type of object being serialized and runs
specific code to to serialize each type. This code does not distinguish
between a `Symbol` and a regular object, and therefor runs code designed
to handle the later to serialize the former. This results in a bad cast
to a `v8::Object`.

Exploit
---
The exploitability of a bad cast depends on many things, including what
properties and methods the real object type and the object type it was
cast to have, how much control an attacker has over the values of
properties of the object, how the code proceeds to use the badly cast
object, compiler optimizations, heap management, etc... Without further
investigation it is impossible to say what an attacker could gain from
exploiting this vulnerability. In this specific case, I did not have
time to investigate exploitability on Google Chrome releases, so I
cannot proof this is actually exploitable.


Time-line
-
* October 2014: This vulnerability was found through fuzzing.
* November 2014: This vulnerability was submitted to ZDI, iDefense
  and EIP.
* December 2014: This issue appears to have been fixed and no longer
  reproduces.
* December 2014: ZDI, iDefense and EIP all either reject the
  submission or fail to respond.
* November 2016: Details of this issue are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2015-0040: Microsoft Internet Explorer 11 MSHTML CMapElement::Notify use-after-free details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
tenth entry in that series.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161114001.html.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

Microsoft Internet Explorer 11 MSHTML CMapElement::Notify use-after-free

(MS15-009, CVE-2015-0040)

Synopsis

A specially crafted web-page can cause MSIE 11 to interrupt the handling
of one `readystatechange` event with another. This interrupts a call to
one of the various `CElement::Notify` functions to make
another such call and at least one of these functions is non-reentrant.
This can have various repercussions, e.g. when an attacker triggers this
vulnerability using a `CMapElement` object, a reference to that object
can be stored in a linked list and the object itself can be freed. This
pointer can later be re-used to cause a classic use-after-free issue.


Known affected versions, attack vectors and mitigations
---
* Microsoft Internet Explorer 11
  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript should prevent an attacker from
  triggering the vulnerable code path.

Description
---
When a `DocumentFragment` containing an applet element is added to the
DOM, all elements receive a notification that they are removed from the
`CMarkup`. Next, they are added to the DOM and receive notification of
being added to another `CMarkup`. When the applet is added, a
`CObjectElement` is created and added to the `CMarkup`. This causes a
`readystatechange` event to fire, which interrupts the current code.
During this `readystatechange` event, the DOM may be modified, which
causes further notifications to fire. However, elements in the
`DocumentFragment` that come after the applet element have already
received a notification that they have been remove from one `CMarkup`,
but not that they have been added to the new one. Thus, these elements
may receive another notification of removal, followed by two
notifications of being added to a `CMarkup`.

AFAICT, this event-within-an-event itself is the root cause of the bug
and allows memory corruption in various ways. I discovered the issue
because the code in `CMapElement::Notify` is non-reentrant and does not
handle this sequence of events well. This code maintains a singly linked
list of map elements that have been added to the document. An object
should never be added to this list twice, as this will cause a loop in
the list (a map element pointing to itself as the next in
the list). However, the event-within-an-event can be used to first cause
two consecutive calls to remove the same element from this list followed
by two calls to add the same element to the list. This results in the
following sequence of events:

* The first call to remove the element will remove it from the list.
* The second call to remove the element will do nothing.
* The first call to add the element will add it to the list.
* The second call to add the element will try to add it to the list
  again,  causing the list to contain a loop. This list is now corrupt.

At this point, an attacker can remove the `CMapElement`, causing the
code to try to remove it from the list and free it. However, because of
the loop in the list, the above code will not actually remove it from
the list. After this, the pointer in the list points to freed memory and
an attacker can force MSIE to reuse it.

Time-line
-
* *September 2014*: This vulnerability was found through fuzzing.
* *September 2014*: This vulnerability was submitted to ZDI.
* *September 2014*: This vulnerability was acquired by ZDI.
* *February 2015*: Microsoft address this issue in MS15-009.
* *November 2016*: Details of this issue are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Microsoft Edge edgehtml CAttr­Array::Destroy use-after-free details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
eleventh entry in that series. Unfortunately I won't be able to publish
everything within one month at the current rate, so I may continue to
publish these through December and January.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161115001.html.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

Microsoft Edge edgehtml CAttrArray::Destroy use-after-free
==
(This fix and CVE number for this issue are not known)

Synopsis

A specially crafted web-page can cause Microsoft Edge to free memory
used for a `CAttrArray` object. The code continues to use the data in
freed memory block immediately after freeing it. It does not appear that
there is enough time between the free and reuse to exploit this issue.

Known affected software and attack vectors
--
* Microsoft Edge 11.0.10240.16384
  An attacker would need to get a target user to open a specially
  crafted web-page. JavaScript is not necessarily required to trigger
  the issue.

Description
---
When an element is created and style properties are added, these are
stored in a `CAttrArray` object. A new `CAttrArray` is able to store up
to 8 properties. If more properties need to be stored, the code will
allocate memory for a larger `CAttrArray` and copy the existing
properties into this new object before freeing the old memory. The code
will then continue to use the freed memory almost immediately. In the
first repro, the "font" style property is the ninth property and
triggers this issue. In the second repro, the only property of a
`CAttrArray` is removed, at which point it is freed but no new object
is allocated. However, the code follows the same path and also reuses
the freed memory.

Exploit
---
What little investigation I did appears to indicate that there is no way
to reallocate the freed memory before its reuse. It is therefore
probably not possible to exploit this issue that way. I did not
investigate how the freed memory is used by the code exactly, and I did
not look into other methods to exploit the issue. I did create a second
repro that triggers the issue "on-demand" from Javascript but, as is to
be expected, no Javascript is executed between the free and the re-use.

Time-line
-
* September 2015: This vulnerability was found through fuzzing.
* September 2015: This vulnerability was submitted to ZDI.
* September 2015: This vulnerability was rejected by ZDI.
* November 2016: The issue no longer reproduces in Microsoft Edge.
* November 2016: Details of this issue are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2015-2482 MSIE 8 jscript RegExpBase::FBadHeader use-after-free details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
twelfth entry in that series. Unfortunately I won't be able to publish
everything within one month at the current rate, so I may continue to
publish these through December and January.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161116001.html.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 8 jscript RegExpBase::FBadHeader use-after-free

(MS15-018, CVE-2015-2482)

Synopsis

A specially crafted web-page can cause the Javascript engine of
Microsoft Internet Explorer 8 to free memory used for a string. The code
will keep a reference to the string and can be forced to reuse it when
compiling a regular expression.

Known affected software, attack vectors and mitigations
---
* Microsoft Internet Explorer 8
  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling Javascript should prevent an attacker
  from triggering the vulnerable code path.

Description
---
Recompiling the regular expression pattern during a replace can cause
the code to reuse a freed string, but only if the string is freed from
the cache by allocating and freeing a number of strings of certain size,
as explained by Alexander Sotirov in his Heap Feng-Shui presentation.

Exploit
---
Exploitation was not investigated.

Time-line
-
* *March 2015*: This vulnerability was found through fuzzing.
* *March 2015*: This vulnerability was submitted to ZDI.
* *April 2015*: This vulnerability was acquired by ZDI.
* *October 2015*: Microsoft addressed this issue in MS15-018.
* *November 2016*: Details of this issue are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Microsoft Internet Explorer 11 iertutil LCIEGetTypedComponentFromThread use-after-free details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
thirteenth entry in that series. Unfortunately I won't be able to
publish everything within one month at the current rate, so I may
continue to publish these through December and January.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161117001.html.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

Microsoft Internet Explorer 11 iertutil LCIEGetTypedComponentFromThread
use-after-free
===
(The fix and CVE number for this issue are unknown)

Synopsis

A specially crafted web-page can cause the iertutil.dll module of
Microsoft Internet Explorer 11 to free some memory while it still holds
a reference to this memory. The module can be made to use this reference
after the memory has been freed. Unlike many use-after-free bugs in
MSIE, this issue, and apparently all code in this module, is not
mitigated by MemGC. This issue appears to have been addressed in July
2016, as it failed to reproduce after the July security updates were
installed.


Known affected software, attack vectors and mitigation
--
+ Microsoft Internet Explorer 11

  An attacker would need to get a target user to open a specially
  crafted web-page and allow the web-page to open a popup. The target
  user may need to run MSIE in the non-default single process mode.
  Disabling JavaScript should prevent an attacker from triggering the
  vulnerable code path.

Description
---
This looks like a pretty straightforward use-after-free, but I did not
investigate at what point in the repro the memory gets freed and when it
gets re-used, so I do not know if an attacker has any chance to force
reallocation of the freed memory before reuse.

The issue can be triggered with MemGC enabled; the object that is freed
does not appear to be protected by MemGC.

The repro requires that MSIE is run in single-process mode in order to
trigger the use-after-free. It is not known if it is possible to tweak
the repro to have MSIE take a similar code-path that leads to a
use-after-free when MSIE is not in single-process mode.

MSIE can be started in single process mode by setting the following
registry key before starting MSIE:

`HKCU\Software\Microsoft\Internet Explorer\Main\TabProcGrowth = DWORD:0`

To revert this change, remove the registry key or set the value to 1 and
restart MSIE.

Exploit
---
A number of factors appear to be getting in the way of creating a usable
exploit for this issue:
* I did not investigate if it is possible to reproduce the issue without
  opening a pop-up to make it exploitable in the presence of a pop-up
  blocker.
* I did not investigate if it is possible to reproduce the issue without
  running MSIE in single-process process mode to exploit it on a system
  with default settings.
* I did not investigate if it is possible to reallocate the freed memory
  between the free and the use-after-free in order to modify control
  flow.
Because there are so many things that would need to be investigated in
order to write an exploit, I felt it was not cost-effective for me to do so.

Time-line
-
* July 2016: This vulnerability was found through fuzzing.
* July 2016: This vulnerability was submitted to ZDI and iDefense.
* July 2016: ZDI reports they are unable to reproduce the issue.
* November 2016: Details of this issue are released.

Cheers,
SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2016-3247 Microsoft Edge CTextExtractor::GetBlockText OOB read details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
fourteenth entry in that series. Unfortunately I won't be able to
publish everything within one month at the current rate, so I may
continue to publish these through December and January.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161118002.html.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

Microsoft Edge CTextExtractor::GetBlockText OOB read
=
(MS16-104, CVE-2016-3247)

Synopsis

A specially crafted web-page can cause an integer underflow in Microsoft
Edge. This causes `CTextExtractor::GetBlockText` to read data outside of
the bounds of a memory block.

Known affected software, attack vectors and mitigations
---
* Microsoft Edge 11.0.10240.16384
  An attacker would need to get a target user to open a specially
  crafted web-page. JavaScript is not necessarily required to trigger
  the issue.

Description
---
Though I did not investigate thoroughly, I did find out the following:
* The root cause appears to be an integer underflow in a 32-bit
  variable used in `CTextExtractor..GetBlockText` as an index to read a
  `WCHAR` in a string buffer. This index is decreased once too often
  and becomes -1, or a very large positive number depending on how it
  is used.
* This does not result in a crash on 32-bit systems, as an integer wrap
  causes the code to read one `WCHAR` before the start of the buffer,
  which is normally also in allocated memory.
* On 64-bit systems, the 32-bit -1 value is interpreted as 0x,
  a very large positive value. As this is an index into a `WCHAR`
  string, it gets multiplied by two and added to the start of the
  buffer to find the location of a `WCHAR` to read. This causes the OOB
  read to be around 8Gb (!!) beyond the address at which the buffer is
  allocated.
* The crash happens in code that appears to be rendering the web-page,
  which does not immediately offer an obvious way of extracting
  information using this bug.

Exploit
---
This is where it gets interesting, as the OOB read happens
approximately 0x2` bytes after the address at which the buffer
is allocated. This presents us with a problem: how to store some
information that we'd be interested in reading at such a large offset
from the original allocation?

As one might come to expect from me, I used a heap spray. But it needed
to be a special kind of heap spray as I did not want to actually have to
allocate 8Gb of RAM. However, about ten years ago (boy, time flies!) I
developed a heap spray that uses significantly less RAM than a
traditional heap spray does; in practice probably about 33% in most
cases, but theoretically much more in ideal situations. I've been
meaning to blog about it, but never found the time to do so until today:
you can read all about it here:

http://blog.skylined.nl/20161118001.html

That said, I have not actually looked at whether it is possible to
exfiltrate useful information using this bug. However, I did write a
Proof-of-Concept that attempts to make sure something is allocated in
the area where the OOB read happens. This PoC uses these heap spray
tricks to spray the heap while minimizing memory use. The
Proof-of-Concept uses about ~5.3Gb to allocate the memory at around 8Gb
distance from the buffer (up to ~10Gb to be sure). When you load the PoC
in a 64-bit version of Edge, you may notice that, unlike the original
repro, it will not crash Edge (even though it does trigger the
issues): the heap spray has allocated the memory that the out-of-bounds
read accesses, and this prevents an access violation exception.
Refreshing the page is likely to screw up the precise allocation process
needed and will probably cause a crash.

This proves that it is theoretically possible to allocate information at
the address used by the code. All that is left is prove that the
information read by the code can be exfiltrated somehow, and you have a
working exploit. This is left as an exercises to the reader.

Time-line
-
* June 2016: This vulnerability was found through fuzzing.
* June 2016: This vulnerability was submitted to ZDI and iDefense.
* July 2016: This vulnerability was acquired by ZDI.
* September 2016: This vulnerability was addressed by Microsoft in
  MS16-104.
* November 2016: Details of this issue are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Tetris heap spraying: spraying the heap on a budget

[Berend-Jan Wever]

L.S.

Over the past decade, heap sprays have become almost synonymous with
exploits in web-browsers. After having developed my first practical
implementation of a heap spray about ten years ago, I found that the
amount of memory needed in some cases was too much for a realistic
attack scenario. I needed a new kind of heap spray that did not allocate
as much RAM as traditional heap sprays do. So, I developed a heap spray
that uses significantly less RAM than a traditional heap spray does. In
practice it uses about 33% less in most cases, but theoretically it
could be much, mush less in ideal situations. This
technique requires only the ability to free some of the blocks of memory
used to spray the heap during spraying and should otherwise be
applicable to every existing implementation.

I wrote an article on my blog that describes the technical details of
this technique, you can find it here:

http://blog.skylined.nl/20161118001.html

I recently used this technique in a Proof-of-Concept for a vulnerability
in Microsoft Edge. You can find details about that vulnerability and the
PoC here:

http://blog.skylined.nl/20161118002.html

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] MSIE8 MSHTML Ptls5::Ls­Find­Span­Visual­Boundaries memory corruption

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
fifteenth entry in that series. Unfortunately I won't be able to
publish everything within one month at the current rate, so I may
continue to publish these through December and January.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161121001.html.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE8 MSHTML Ptls5::LsFindSpanVisualBoundaries memory corruption

(The fix and CVE number for this bug are unknown)

Synopsis

A specially crafted web-page can cause an unknown type of memory
corruption in Microsoft Internet Explorer 8. This vulnerability can
cause the `Ptls5::LsFindSpanVisualBoundaries` method (or other methods
called by it) to access arbitrary memory.

Known affected software, attack vectors and mitigations
---
* Microsoft Internet Explorer 8

  An attacker would need to get a target user to open a specially
  crafted web-page. JavaScript is not necessarily required to trigger
  the issue.

Description
---
The memory corruption causes the `Ptls5::LsFindSpanVisualBoundaries`
method to access data at seemingly random addresses. However, these
addresses appear to always be in the same range as valid heap addresses,
even if they are often not DWORD aligned. The reason for the memory
corruption is not immediately obvious.

Time-line
-
* July 2014: This vulnerability was found through fuzzing.
* November 2016: Details of this issue are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2015-0050: Microsoft Internet Explorer 8 MSHTML SRunPointer::SpanQualifier/RunType OOB read details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
sixteenth entry in that series. Unfortunately I won't be able to
publish everything within one month at the current rate, so I may
continue to publish these through December and January.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161122001.html. There you can find a repro
that triggered this issue in addition to the information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 8 MSHTML SRunPointer::SpanQualifier/RunType OOB read
=
(MS15-009, CVE-2015-0050)

Synopsis

A specially crafted web-page can cause Microsoft Internet Explorer 8 to
attempt to read data beyond the boundaries of a memory allocation. The
issue does not appear to be easily exploitable.

Known affected software, attack vectors and mitigations
---
* Microsoft Internet Explorer 8

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling Javascript should prevent an attacker
  from triggering the vulnerable code path.

Description
---
The issue requires rather complex manipulation of the DOM and results in
reading a value immediately following an object. The lower three bits of
this value are returned by the function doing the reading, resulting in
a return value in the range 0-7. After exhaustively skipping over the
read AV and having that function return each value, no other side
effects were noticed. For that reason I assume this issue is hard if not
impossible to exploit and did not investigate further. It is still
possible that there may be subtle effects that I did not notice that
allow exploitation in some form or other.

Time-line
-
* *June 2014*: This vulnerability was found through fuzzing.
* *October 2014*: This vulnerability was submitted to ZDI.
* *October 2014*: This vulnerability was rejected by ZDI.
* *November 2014*: This vulnerability was reported to MSRC.
* *February 2015*: This vulnerability was addressed by Microsoft in
  MS15-009.
* *November 2016*: Details of this issue are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2015-1251: Chrome blink Speech­Recognition­Controller use-after-free details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
seventeenth entry in that series. Unfortunately I won't be able to
publish everything within one month at the current rate, so I may
continue to publish these through December and January.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161123001.html. There you can find a repro
that triggered this issue, snippets from the vulnerable source and more
details in addition to the information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

Chrome blink SpeechRecognitionController use-after-free
===
(Chromium 455857, CVE-2015-1251)

Synopsis

A specially crafted web-page can cause the blink rendering engine used
by Google Chrome and Chromium to continue to use a speech recognition
API object after the memory block that contained the object has been
freed. An attacker can force the code to read a pointer from the freed
memory and use this to call a function, allowing arbitrary code execution.

Known affected software and attack vectors
--
+ Google Chrome 39.0

  An attacker would need to get a target user to open a specially
  crafted webpage. Disabling Javascript should prevent an attacker from
  triggering the vulnerable code path.

Description
---
Creating a `webkitSpeechRecognition` Javascript object in a popup window
before closing the popup frees a C++ object used internally by the
speech recognition API code but leaves a dangling pointer to the freed
memory in another C++ object. When the `start()` Javascript method is
called, this dangling pointer is used to try to read a function pointer
from a virtual function table and call that function. An attacker has
ample time to groom the heap between the free and re-use in order to
control the function pointer used by the code, allowing arbitrary code
execution.

Exploit
---
An attacker looking to exploit this issue is going to want to try and
control the contents of the freed memory, before getting the code to use
the dangling pointer to call a virtual function. Doing so would allow an
attacker to execute arbitrary code. This is made possible because steps
5 and 6 can both be triggered at a time of the attackers choosing,
giving the attacker the ability to free the memory in step 5 whenever
this is convenient and attempt to reallocate and fill it with any data
before executing step 6. This should allow an attacker to create a fake
`vftable` pointer and gain arbitrary code execution. In order to develop
a working exploit, existing mitigations will need to be bypassed, most
significantly ASLR and DEP. As this vulnerability by itself does not
appear to allow bypassing these mitigations, I did not develop a working
exploit for it.

Time-line
-
* November 2014: This vulnerability was found through fuzzing.
* December 2014: This vulnerability was submitted to ZDI and iDefense.
* January 2015: This vulnerability was acquired by ZDI.
* February 2015: This vulnerability was fixed in revision 190993.
* May 2015: This vulnerability was addressed by Google in
  Chrome 43.0.2357.65.
* November 2016: Details of this issue are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Microsoft Internet Explorer 11 MSHTML CGeneratedContent::HasGeneratedSVGMarker type confusion

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
eighteenth entry in that series. Unfortunately I won't be able to
publish everything within one month at the current rate, so I may
continue to publish these through December and January.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161124001.html. There you can find a repro
that triggered this issue, reversed snippets from the vulnerable code
and more details in addition to the information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 11 MSHTML CGeneratedContent::HasGeneratedSVGMarker type confusion
===
(The fix and CVE number for this issue are unknown)

Synopsis

A specially crafted web-page can cause a type confusion in HTML layout
in Microsoft Internet Explorer 11. An attacker might be able to exploit
this issue to execute arbitrary code.

Known affected software and attack vectors
--
+ Microsoft Internet Explorer 11

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling Javascript should prevent an attacker
  from triggering the vulnerable code path.


Description
---
Internally MSIE uses various lists of linked `CTreePos` objects to
represent the DOM tree. For HTML/SVG elements a `CTreeNode` element is
created, which embeds two `CTreePos` instances: one that contains
information about the first child of the element and one that indicates
the next sibling or parent of the element. For text nodes an object
containing only one `CTreePos` is created, as such nodes never have any
children. `CTreePos` instances have various flags set. This includes a
flag that indicates if they are the first (`fTPBegin`) or second
(`fTPEnd`) `CTreePos` instance for an element, or the only instance for
a test node (`fTPText`).

The `CTreePos::Branch` method of an `CTreePos` instance embedded in a
`CTreeNode` can be used to calculate a pointer to the `CTreeNode`. It
determines if the `CTreePos` instance is the first or second in the
`CTreeNode` by looking at the `fTPBegin` flag and subtract the offset of
this `CTreePos` object in a `CTreeNode` object to calculate the address
of the later. This method assumes that the `CTreePos` instance is part
of a `CTreeNode` and not a `TextNode`. It will yield invalid results
when called on the later. In a `TextNode`, the `CTreePos` does not have
the `fTPBegin` flag set, so the code assumes this is the second
`CTreePos` instance in a `CTreeNode` object and subtracts 0x24 from its
address to calculate the address of the `CTreeNode`. Since the
`CTreePos` instance is the first element in a `TextNode`, the returned
address will be 0x24 bytes before the `TextNode`, pointing to memory
that is not part of the object.

Note that this behavior is very similar to another issue I found around
the same time, in that that issues also caused the code to access memory
0x24 bytes before the start of a memory region containing an object.
Looking back I believe that both issues may have had the same root cause
and were fixed at the same time. You can find more details about that
other issue in my blog post here:

http://blog.skylined.nl/20161104001.html

The `CGeneratedContent::HasGeneratedSVGMarker` method walks the DOM
using one of the `CTreePos` linked lists. It looks for any descendant
node of an element that has a `CTreePos` instance with a specific flag
set. If found, the `CTreePos::Branch` method is called to find the
related `CTreeNode`, without checking if the `CTreePos` is indeed part
of a `CTreeNode`. If a certain flag is set on this `CTreeNode`, it
returns true. Otherwise it continues scanning. If nothing is found, it
returns false.

The repro creates a situation where the
`CGeneratedContent::HasGeneratedSVGMarker` method is called on an SVG
path element which has a `TextNode` instance as a descendant with the
right flags set to cause it to call `CTreePos::Branch` on this
`TextNode`. This leads to type confusion/a bad cast where a pointer that
points before a `TextNode` is used as a pointer to a `CTreeNode`.

Exploit
---

I did not find any code path that could lead to exploitation. However, I
did not do a thorough step through of the code to find out if and how I
might control execution flow upwards in the stack. Also, it appears
trivial to have MSIE survive the initial crash by massaging the heap. It
might be possible that other methods are affected by a similar issue and
that further DOM manipulations can be used to trigger a more interesting
code path.

Time-line
-
* *July 2014*: This vulnerability was found through fuzzing.
* *September 2014*: This vulnerability was submitted to ZDI.
* *September 2014*: This vulnerability appears to have been fixed.
* *October 2014*: This vulnerability was rejected by ZDI.
* *November 

[FD] CVE-2013-3120 MSIE 10 MSHTML CEditAdorner::Detach use-after-free details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
nineteenth entry in that series. Unfortunately I won't be able to
publish everything within one month at the current rate, so I may
continue to publish these through December and January.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161125001.html. There you can find a repro
that triggered this issue in addition to the information below.
Today's release is a bit skimpy as it was found over 3 years ago, back
when I did not have the tool-set to analyze issues that I have today.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 10 MSHTML CEditAdorner::Detach use-after-free
==
(MS13-047, CVE-2013-3120)

Synopsis

A specially crafted web-page can cause Microsoft Internet Explorer 10 to
continue to use an object after freeing the memory used to store the
object. An attacker might be able to exploit this issue to execute
arbitrary code.

Known affected software and attack vectors
--
+ Microsoft Internet Explorer 10

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling Javascript should prevent an attacker
  from triggering the vulnerable code path.

Details
---
The last line of script (`designMode = "off"`) will cause some cleanup
in MSIE, which appears to trigger use of a stale pointer in
`CEditAdorner::Detach`. I did not investigate further.

Time-line
-
* November 2012: This vulnerability was found through fuzzing.
* November 2012: This vulnerability was submitted to EIP.
* December 2012: This vulnerability was rejected by EIP.
* January 2013: This vulnerability was submitted to ZDI.
* March 2013: This vulnerability was acquired by ZDI.
* June 2013: This issue was addressed by Microsoft in MS13-047.
* November 2016: Details of this issue are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2016-0063: MSIE 8-11 MSHTML DOMImplementation type confusion details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
twentieth entry in that series. Unfortunately I won't be able to
publish everything within one month at the current rate, so I may
continue to publish these through December and January.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161128001.html. There you can find a repro
that triggered this issue in addition to the information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 8-11 MSHTML DOMImplementation type confusion
=
(MS16-009, CVE-2016-0063)

Synopsis

A specially crafted web-page can cause a type confusion vulnerability in
Microsoft Internet Explorer 8 through to 11. An attacker can cause code
to be executed with a stack layout it does not expect, or have code
attempt to execute a method of an object using a vftable, when that
object does not have a vftable. Successful exploitation can lead to
arbitrary code execution.

Known affected software and attack vectors
--
+ Microsoft Internet Explorer 8, 9, 10 and 11

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling Javascript should prevent an attacker
  from triggering the vulnerable code path.


Description
---
I identified two attack vectors to this vulnerability. One of them is
that Javascript can make a copy of the `hasFeature` method of a
`DOMImplementation` object in one window and use it as a method of
another object in another window. Doing so can cause at least two issues
in the `MSHTML!Method_VARIANTBOOLp_BSTR_o0oVARIANT` function of MSIE:
* A FailFast exception when the code detects that calling a method of
  an object has not cleaned up the stack as expected; this is because
  the called function appears to expect a different number of arguments
  or a different calling convention. This issue can be triggered by
  changing the line `o.x();` in the repro to `o.x(new Array)`.
* An out-of-bounds write when `MSHTML!CBase::PrivateGetDispID` is
  called; this is probably caused by a type confusion bug: the code
  expects a `VARIANT` object of one type, but is working on an object
  of a different type.

Exploitation of this attack vector was not attempted. I reversed
`Method_VARIANTBOOLp_BSTR_o0oVARIANT` only sufficiently to get an idea
of the root cause, but not enough to determine exactly what is going on
or how to control the issue for command execution.

Another attack vector is calling the `isPrototypeOf` method of the
`DOMImplementation` interface as a function: this results in type
confusion where a C++ object is assumed to implement `IUnknown` when in
fact it does not. The code attempts to call the `IUnknown::Release`
method, expecting a vftable to be stored at offset 0, but since the
object has no vftables, a member property is stored at this offset,
which appears to have a static value `002dc6c0`. An attacker that is
able to control this value, or allocate memory and store data at that
address, may be able to execute arbitrary code.

No attempts were made to further reverse the code and determine the
exact root cause. A few attempts were made to control the value at
offset 0 of the object in question, as well as get another object in its
place with a different value at this location, but both efforts were
brief and unsuccessful.

Time-line
-
* September 2015: This vulnerability was found through fuzzing.
* October 2015: This vulnerability was submitted to ZDI.
* November 2015: This vulnerability was acquired by ZDI.
* February 2016: This issue was addressed by Microsoft in MS16-009.
* November 2016: Details of this issue are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Google Chrome Accessibility blink::Node corruption details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
twenty-first entry in that series. Unfortunately I won't be able to
publish everything within one month at the current rate, so I may
continue to publish these through December and January.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161129001.html. There you can find a repro
that triggered this issue and relevant code snippets in addition to the
information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

Google Chrome Accessibility blink::Node corruption
==
(The fix and CVE number for this issue are unknown)

Synopsis

A specially crafted web-page can trigger an unknown memory corruption
vulnerability in Google Chrome Accessibility code. An attacker can
cause code to attempt to execute a method of an object using a vftable,
when the pointer to that object is not valid, or the object is not of
the expected type. Successful exploitation can lead to arbitrary code
execution.

Known affected software and attack vectors
--
* Chrome 48.0.2540.0 dev-m

  An attacker would need to get a target user to open a specially
  crafted webpage. Renderer accessibility must be enabled through the
  "--force-renderer-accessibility" command-line option. Disabling
  JavaScript will not prevent an attacker from triggering the
  vulnerable code path.

Description
---
Repeatedly loading two different pages in an iframe can cause the
accessibility code to crash. This crash can happen in two different code
paths, which are similar and both end up crashing because of a corrupt
`blink::Node` instance. The first code path calls
`blink::isDisabledFormControl` with the corrupt `blink::Node` instance
as an argument from `AXNodeObject::canSetFocusAttribute`. This causes an
access violation when `blink::isDisabledFormControl` attempts to call
the `isDisabledFormControl` method on the corrupt `blink::Node` instance.

The second code path calls `blink::Element::fastGetAttribute` with the
corrupt `blink::Node` instance as an argument from
`blink::AXObject::getAttribute`.

This can cause an access violation at various locations along the code
path, but almost certainly does so if the code reaches the part where it
attempts to match the attribute name, as the
`blink::AttributeCollectionGeneric<...>` was taken from a corrupt
`blink::Node` instance and that data is therefore almost certainly
completely invalid.

Exploit
---
Is is unclear to me why the `blink::Node` instance was corrupted. During
analysis, I was having trouble running Google Chrome with Page Heap
enabled, which severely limited my ability to reliably crash the
application and find out what information on the heap belongs to what
object. Then, before I could get my debugging environment fixed, the
issue appears to have been fixed, as I was no longer able to reproduce
it. Any information on exploitability is therefore based on speculation.

An attacker who is able to trigger the issue reliably, and has some
control over the corrupted `blink::Node` instance that is returned, or
heap memory in this area, may be able to control execution flow through
the `blink::isDisabledFormControl` call, as this uses information from
the corrupted `blink::Node` instance as a pointer to a vftable.

Time-line
-
* October 2015: This vulnerability was found through fuzzing.
* November 2016: Details of this issue are released.

(This issue was never reported, as I was struggling with my debugging
environment, as described above. At some point after I discovered it,
this issue appears to have been fixed, as evidenced by the repro no
longer working. However, I have no exact date, nor a fix number to
provide here).

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Opera foreignObject textNode::removeChild use-after-free details

[Berend-Jan Wever]

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
twenty-second entry in that series. Unfortunately I won't be able to
publish everything within one month at the current rate, so I may
continue to publish these through December and January.

Due to the recent Firefox 0-day, I've selected a very old and not so
interesting bug for today, so you can get back to looking at the former
as soon as possible.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161130001.html. There you can find a repro
that triggered this issue and an exploit that may or may not work in
addition to the information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

Opera foreignObject textNode::removeChild use-after-free

(The fix and CVE number for this issue are unknown)

Synopsis

A specially crafted web-page can trigger a use-after-free vulnerability
in Opera. This vulnerability was found a very long time ago, back when I
did not keep organized records of my analysis, so unfortunately, I
cannot speculate on the potential impact or exploitability.

Known affected software and attack vectors
--
* Opera 12

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript should prevent an attacker
  from triggering the vulnerable code path.

Description
---
As I mentioned, I did not keep detailed records of my analysis, so there
is not much I can say about this vulnerability, other than that I did
attempt to write an exploit. However, I do not know how successful this
exploit was. I did not include it in my report to iDefense, so I am
assuming it was not successful.


Time-line
-
* Before August 2012: This vulnerability was found through fuzzing.
* August 2012: This vulnerability was submitted to iDefense.
* September 2012: This vulnerability was acquired by iDefens
  (see note).
* November 2016: Details of this vulnerability are released.

(I asked ZDI and iDefense if they were interested in Opera
vulnerabilities before submitting them. ZDI responded that they was not,
but iDefense _accidentally_ said they were. After submitting my first
vulnerability, iDefense explained that there had been a mistake on their
side and that they were not in fact interested. However, they kindly
offered to buy this vulnerability for a token reward, which I accepted).

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2015-6168: MS Edge CMarkup::EnsureDeleteCFState use-after-free details

[Berend-Jan Wever]

As I am sure you are by now well aware, in November I decided to start
releasing details on all vulnerabilities I found in web-browsers that I
had not released before. As I was unable to publish all of them within a
single month, I will try to continue to publish all my old
vulnerabilities, including those not in web-browser, as long as I can
find some time to do so. If you find this information useful, you can
help me make some time available by donating bitcoin to
183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

This is the twenty-third entry in the series. This information is
available in more detail on my blog at
http://blog.skylined.nl/20161201001.html. There you can find a repro
that triggered this issue in addition to the information below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MS Edge CMarkup::EnsureDeleteCFState use-after-free
===
(MS15-125, CVE-2015-6168)

Synopsis

A specially crafted web-page can trigger a memory corruption
vulnerability in Microsoft Edge. I did not investigate this
vulnerability thoroughly, so I cannot speculate on the potential impact
or exploitability.

Known affected software and attack vectors
--
* Microsoft Edge 11.0.10240.16384

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript does not prevent an attacker
  from triggering the vulnerable code path.

Description
---
At the time this issue was first discovered, MemGC was just introduced,
and I had not yet fully appreciated what an impact it would have on
mitigating use-after-free bugs. Despite MemGC being enabled in Microsoft
Edge by default, this issue appeared to me to have been a use-after-free
vulnerability. However, both Microsoft and ZDI (whom I sold the
vulnerability to) describes it as a memory corruption vulnerability, so
it's probably more complex than I assumed.

At the time, I did not consider this vulnerability to be of great
interest, as there was no immediately obvious way of controlling the
vulnerability in order to exploit it. So, I did not do any further
investigation into the root cause and, if this was indeed a
use-after-free, how come MemGC did not mitigate it?
In hindsight, it would have been a good idea to investigate the root
cause, as any use-after-free that is not mitigated by MemGC might
provide hints on how to find more vulnerabilities that bypass it.

Time-line
-
* August 2015: This vulnerability was found through fuzzing.
* August 2015: This vulnerability was submitted to ZDI.
* December 2015: Microsoft addresses this vulnerability in MS15-125.
* December 2016: Details of this vulnerability are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2013-0019: MSIE 9 CDoc::ExecuteScriptUri use-after-free

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found in web-browsers that I had not released before. I will try to
continue to publish all my old vulnerabilities, including those not in
web-browser, as long as I can find some time to do so. If you find this
information useful, you can help me make some time available by donating
bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

This is the twenty-fourth entry in the series. This information is
available in more detail on my blog at
http://blog.skylined.nl/20161202001.html. There you can find a repro
that triggered this issue in addition to the information below.

Today's release is interesting to me personally, as this was the first
bug I sold as a bug bounty hunter after I quit my job at Google to live
off security bug bounties. Unfortunately, this was quite some time ago,
before I had proper tools or incentive to analyze the issues I was
finding, so there aren't many details in this release.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 9 CDoc::ExecuteScriptUri use-after-free
==
(MS13-009, CVE-2013-0019)

Synopsis

A specially crafted web-page can trigger a use-after-free vulnerability
in Microsoft Internet Explorer 9. I did not investigate this
vulnerability thoroughly, so I cannot speculate on the potential impact
or exploitability.

Known affected software and attack vectors
--
* Microsoft Internet Explorer 9

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript does not prevent an attacker
  from triggering the vulnerable code path.

Description
---
It appears I either did not analyze this issue (probably), or misplaced
my analysis (probably not), as I cannot find any details in my archives,
other than a repro and a HTML bug report created by a predecessor to
BugId (https://github.com/SkyLined/BugId).
From the information provided by ZDI in their advisory, and Microsoft in
their bulletin, as well as the bug report, it seems to have been a
use-after-free vulnerability. Unfortunately, that is all the analysis I
can provide.

Time-line
-
* June 2012: This vulnerability was found through fuzzing.
* June 2012: This vulnerability was submitted to ZDI.
* July 2012: This vulnerability was acquired by ZDI.
* September 2012: This vulnerability was disclosed to Microsoft by ZDI.
* February 2013: Microsoft addresses this vulnerability in MS13-009.
* December 2016: Details of this vulnerability are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2016-3222: MS Edge CBaseScriptable::PrivateQueryInterface memory corruption

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found in web-browsers that I had not released before. I will try to
continue to publish all my old vulnerabilities, including those not in
web-browser, as long as I can find some time to do so. If you find this
information useful, you can help me make some time available by donating
bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

This is the twenty-fifth entry in the series. This information is
available in more detail on my blog at
http://blog.skylined.nl/20161205001.html. There you can find repros
that triggered this issue in addition to the information below.

Today's release is interesting, as I accidentally published a repro for
this as part of #DailyBug on twitter in May of this year, believing at
the time that it was a simple NULL pointer:
https://twitter.com/berendjanwever/status/729957166447218688
I found out not to long after that, that it was actually a security
vulnerability. Details on how this happened are below.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MS Edge CBaseScriptable::PrivateQueryInterface memory corruption

(MS16-068, CVE-2016-3222)

Synopsis

A specially crafted web-page can trigger a memory corruption
vulnerability in Microsoft Edge. I did not investigate this
vulnerability thoroughly, so I cannot speculate on the potential impact
or exploitability.

Known affected software and attack vectors
--
* Microsoft Edge
  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript does not prevent an attacker
  from triggering the vulnerable code path.

Discovery
-
This issue was found through fuzzing in the 64-bit version of Microsoft
Edge, in which the original repro triggered what appeared to be a NULL
pointer dereference in `CBaseScriptable::PrivateQueryInterface`. So,
after a very brief look at the repro, I filed a bug in the public Edge
bug tracker and published it on twitter as part of #DailyBug.

Soon after, I found another repro that trigger a slightly different NULL
pointer dereference in `CBaseScriptable::PrivateQueryInterface` in a
64-bit version of Edge.

I never tested the these two repros in a 32-bit version of Edge before
publishing them, which I immediately regretted after finding that the
second repro triggered an access violation using the obviously non-NULL
address 0x1BF37D8 in a 32-bit version of Edge!

Around this time, I started finding many variations of this bug: getting
the type of various properties or objects associated with another window
was triggering all kinds of access violations. Many of these were not
using NULL pointers on 32-bit Edge.

I looked again at the original `crypto` repro and noticed that although
it triggered an access violation using a NULL pointer on both 32-bit and
64-bit versions of Edge, the two addresses (3 and 8 respectively) had
different alignment. This is rather odd: true NULL pointer dereferences
can cause an access violation at a different offset from NULL on these
two architectures because property values and pointers stored before the
one being read/written can have different sizes on 32-bit and 64-bit
systems, but one usually expects them to have similar alignment: the
last two bits of the address should be the same.

Report
--
If only I had tested the original repro in a 32-bit version of Edge when
I first analyzed the issue, I might have realized it was more than a
simple NULL pointer and not published it before doing additional research.

I contacted ZDI and asked if they would be interested in buying the
vulnerability at this point, given that I publicly released the repro
that triggered a NULL pointer and filed it with Microsoft. I was hoping
they would decide that this did not disclose the underlying
vulnerability and that it as such would still be a 0-day. Unfortunately
for me, they were not interested in acquiring details in this situation.

At that point I decided to contact the Microsoft Security Response
Center and report the additional information I had found. I also
contacted a few people working on the Edge team at Microsoft directly to
let them know they might want to escalate this bug from a simple NULL
pointer to a security vulnerability. Unfortunately, this let them to
decided to mark the bug I had filed in the Edge bug tracker as hidden. I
warned them that this did little good, as the details were still public
in my twitter and even if I deleted that, in general
what goes on the internet stays on the internet.

Analysis

Since I had publicly released the repro, I was not going to be seeing
any kind of reward for this bug, so analyzing the issue was not a
priority for me. Unfortunately that meant I did not analyze it at all,
other than to speculate that this bug was likely to have been a
type-confusion or bad cast, where assembled co

Re: [FD] CVE-2016-3222: MS Edge CBaseScriptable::PrivateQueryInterface memory corruption

[Berend-Jan Wever]

FYI: this link to my blog was 404 until early this morning. It is now up
if you are still interested in reading it.

On 05-12-2016 11:55, Berend-Jan Wever wrote:
> Since November I have been releasing details on all vulnerabilities I
> found in web-browsers that I had not released before. I will try to
> continue to publish all my old vulnerabilities, including those not in
> web-browser, as long as I can find some time to do so. If you find this
> information useful, you can help me make some time available by donating
> bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.
> 
> This is the twenty-fifth entry in the series. This information is
> available in more detail on my blog at
> http://blog.skylined.nl/20161205001.html. There you can find repros
> that triggered this issue in addition to the information below.
> 
> Today's release is interesting, as I accidentally published a repro for
> this as part of #DailyBug on twitter in May of this year, believing at
> the time that it was a simple NULL pointer:
> https://twitter.com/berendjanwever/status/729957166447218688
> I found out not to long after that, that it was actually a security
> vulnerability. Details on how this happened are below.
> 
> Follow me on http://twitter.com/berendjanwever for daily browser bugs.
> 
> MS Edge CBaseScriptable::PrivateQueryInterface memory corruption
> 
> (MS16-068, CVE-2016-3222)
> 
> Synopsis
> 
> A specially crafted web-page can trigger a memory corruption
> vulnerability in Microsoft Edge. I did not investigate this
> vulnerability thoroughly, so I cannot speculate on the potential impact
> or exploitability.
> 
> Known affected software and attack vectors
> --
> * Microsoft Edge
>   An attacker would need to get a target user to open a specially
>   crafted web-page. Disabling JavaScript does not prevent an attacker
>   from triggering the vulnerable code path.
> 
> Discovery
> -
> This issue was found through fuzzing in the 64-bit version of Microsoft
> Edge, in which the original repro triggered what appeared to be a NULL
> pointer dereference in `CBaseScriptable::PrivateQueryInterface`. So,
> after a very brief look at the repro, I filed a bug in the public Edge
> bug tracker and published it on twitter as part of #DailyBug.
> 
> Soon after, I found another repro that trigger a slightly different NULL
> pointer dereference in `CBaseScriptable::PrivateQueryInterface` in a
> 64-bit version of Edge.
> 
> I never tested the these two repros in a 32-bit version of Edge before
> publishing them, which I immediately regretted after finding that the
> second repro triggered an access violation using the obviously non-NULL
> address 0x1BF37D8 in a 32-bit version of Edge!
> 
> Around this time, I started finding many variations of this bug: getting
> the type of various properties or objects associated with another window
> was triggering all kinds of access violations. Many of these were not
> using NULL pointers on 32-bit Edge.
> 
> I looked again at the original `crypto` repro and noticed that although
> it triggered an access violation using a NULL pointer on both 32-bit and
> 64-bit versions of Edge, the two addresses (3 and 8 respectively) had
> different alignment. This is rather odd: true NULL pointer dereferences
> can cause an access violation at a different offset from NULL on these
> two architectures because property values and pointers stored before the
> one being read/written can have different sizes on 32-bit and 64-bit
> systems, but one usually expects them to have similar alignment: the
> last two bits of the address should be the same.
> 
> Report
> --
> If only I had tested the original repro in a 32-bit version of Edge when
> I first analyzed the issue, I might have realized it was more than a
> simple NULL pointer and not published it before doing additional research.
> 
> I contacted ZDI and asked if they would be interested in buying the
> vulnerability at this point, given that I publicly released the repro
> that triggered a NULL pointer and filed it with Microsoft. I was hoping
> they would decide that this did not disclose the underlying
> vulnerability and that it as such would still be a 0-day. Unfortunately
> for me, they were not interested in acquiring details in this situation.
> 
> At that point I decided to contact the Microsoft Security Response
> Center and report the additional information I had found. I also
> contacted a few people working on the Edge team at Microsoft directly to
> let them know they might want to escalate this bug from a simple NULL
> pointer to a security vulnerability. 

[FD] CVE-2015-1730: MSIE jscript9 Java­Script­Stack­Walker memory corruption details and PoC

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found in web-browsers that I had not released before. I will try to
continue to publish all my old vulnerabilities, including those not in
web-browser, as long as I can find some time to do so. If you find this
information useful, you can help me make more time available by donating
bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

This is the twenty-sixth entry in the series. This information is
available in more detail on my blog at
http://blog.skylined.nl/20161206001.html. There you can find repros
that triggered this issue in addition to a Proof-of-Concept exploit, as
well as the information below.

Today's release is interesting, in part because it is an odd
vulnerability that I've not seen before or since: it's like a
stack-based use-after-free. The time-line is also interesting in that
ZDI first did not believe it to be exploitable and EIP thought it was a
duplicate of a bug they had already reported to Microsoft. Both turned
out to be wrong. Then I reported it to iDefense as well, who
accidentally send the details over plain-text email, causing ZDI to
reject my submission for fear of the bug leaking to the public. Luckily
for me, iDefense did end up acquiring the bug.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE jscript9 JavaScriptStackWalker memory corruption
=
(MS15-056, CVE-2015-1730)

Synopsis

A specially crafted web-page can trigger a memory corruption
vulnerability in Microsoft Internet Explorer 9. A pointer set up to
point to certain data on the stack can be used after that data has been
removed from the stack. This results in a stack-based analog to a heap
use-after-free vulnerability. The stack memory where the data was stored
can be modified by an attacker before it is used, allowing remote code
execution.

Known affected software and attack vectors
--
* Microsoft Internet Explorer 9

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript should prevent an attacker
  from triggering the vulnerable code path.

Description
---
MSIE attempts to handle stack exhaustion caused by excessive recursion
in Javascript gracefully by generating a JavaScript exception. While
generating the exception, information about the call stack is gathered
using the JavascriptStackWalker class. It appears that the code that
does this initializes a pointer variable on the stack the first time it
is run, but re-uses it if it gets called a second time. Unfortunately,
the information the pointer points to is also stored on the stack, but
is removed from the stack after the first exception is handled. Careful
manipulation of the stack during both exceptions allow an attacker to
control the data the pointer points to during the second exception.

Exploit
---
The vulnerable pointer points to valid stack memory during the first
exception, but it is "popped" from the stack before the second. In order
to exploit this vulnerability, the code executed during the first
exception is going to point this pointer to a specific area of the
stack, while the code executed during the second is going to allocate
certain values in that same area before the pointer is re-used.

Control over the stack contents during a stack exhaustion can be
achieved by making the recursive calls with many arguments, all of which
are stored on the stack. This is similar to a heap-spray storing values
on large sections of the heap in that it is not entirely deterministic,
but the odds are very highly in favor of you setting a certain value at
a certain address.

Further details of how to exploit this issue can be found in my blog at
http://blog.skylined.nl/20161206001.html

Time-line
-
* 13 October 2012: This vulnerability was found through fuzzing.
* 29 October 2012: This vulnerability was submitted to EIP.
* 18 November 2012: This vulnerability was submitted to ZDI.
* 27 November 2012: EIP declines to acquire this vulnerability because
  they believe it to be a copy of another vulnerability they already
  acquired.
* 7 December 2012: ZDI declines to acquire this vulnerability because
  they believe it not to be exploitable.

During the initial report detailed above, I did not have a working
exploit to prove exploitability. I also expected the bug to be fixed
soon, seeing how EIP believed they already reported it to Microsoft.
However, about two years later, I decided to look at the issue again and
found it had not yet been fixed. Apparently it was not the same issue
that EIP reported to Microsoft. So, I decided to try to have another
look and developed a Proof-of-Concept exploit.

* April 2014: I start working on this case again, and eventually
  develop a working Proof-of-Concept exploit.
* 6 November 2014: ZDI was informed of the new analysis and reopens the
  case.
* 15 November

[FD] CVE-2013-1309:

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found that I have not released before. This is the twenty-seventh entry
in the series. This information is available in more detail on my blog
at http://blog.skylined.nl/20161207001.html. There you can find a repro
that triggered this issue in addition to the information below.

Today's release is not very interesting, because it was one of the first
bugs I found and reported to the ZDI back in 2012, before I had
developed the tools and skills to properly analyze MSIE bugs. This
report is therefore very scarce in information.

If you find this information useful, and would like to help me make time
to continue releasing this kind of information, you can make a donation
in bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 9 MSHTML CDispNode::InsertSiblingNode use-after-free
=
(MS13-037, CVE-2013-1309)

Synopsis

A specially crafted web-page can trigger a memory corruption
vulnerability in Microsoft Internet Explorer 9. I did not investigate
this vulnerability thoroughly, so I cannot speculate on the potential
impact or exploitability.

Known affected software and attack vectors
--
* Microsoft Internet Explorer 9
  An attacker would need to get a target user to open a specially
  crafted web-page. JavaScript does not appear to be required for an
  attacker to triggering the vulnerable code path.

Details
---
This bug was found back when I had very little knowledge and tools to do
analysis on use-after-free bugs, so I have no details to share. The ZDI
did do a more thorough analysis and provide some details in their
advisory at http://www.zerodayinitiative.com/advisories/ZDI-13-083/.

Time-line
-
* 1 November 2012: This vulnerability was found through fuzzing.
* 2 November 2012: This vulnerability was submitted to ZDI.
* 19 November 2012: This vulnerability was acquired by ZDI.
* 4 February 2013: This vulnerability was disclosed to Microsoft by ZDI.
* 29 May 2013: Microsoft addresses this vulnerability in MS13-037.
* 7 December 2016: Details of this vulnerability are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2013-1306: MSIE 9 MSHTML CDisp­Node::Insert­Sibling­Node use-after-free details

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found that I have not released before. This is the twenty-eighth entry
in the series. This information is available in more detail on my blog
at http://blog.skylined.nl/20161208001.html. There you can find a repro
that triggered this issue in addition to the information below.

Today's release is again not very interesting, because it also was one
of the first bugs I found and reported back in 2012, before I had
developed the tools and skills to properly analyze MSIE bugs. This
report is therefore very scarce in information. I did get some more
details from EIP about the root cause, which I've included.

If you find this information useful, and would like to help me make time
to continue releasing this kind of information, you can make a donation
in bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 9 MSHTML CDispNode::InsertSiblingNode use-after-free
=
(MS13-037, CVE-2013-1306)

Synopsis

A specially crafted web-page can trigger a memory corruption
vulnerability in Microsoft Internet Explorer 9. I did not investigate
this vulnerability thoroughly, so I cannot speculate on the potential
impact or exploitability.

Known affected software and attack vectors
--
* Microsoft Internet Explorer 9
  An attacker would need to get a target user to open a specially
  crafted web-page. JavaScript does not appear to be required for an
  attacker to triggering the vulnerable code path.

Details
---
This bug was found back when I had very little knowledge and tools to do
analysis on use-after-free bugs, so I have no details to share. The EIP
provided me with some details of their analysis, which I'll paraphrase
here: It is a use-after-free vulnerability where the span object in the
frame.html file is reused after being freed. It appears to be impossible
to reallocate the freed memory before it is reused. Part of the freed
memory is overwritten when it is freed because a WORD `FreeEntryOffset`
value is stored at offset 0. This value is then used as part of a
pointer to a vftable in order to call a method. This pointer now consist
of the upper 16-bits of the old vftable and the lower 16-bits contain
the `FreeEntryOffset` value. Exploitation is near impossible without a
way to have more control over this pointer in the freed memory block.
ZDI also did a more thorough analysis and [provide very similar details
in their advisory at
http://www.zerodayinitiative.com/advisories/ZDI-13-082/

Time-line
-
* 27 September 2012: This vulnerability was found through fuzzing.
* 3 October 2012: This vulnerability was submitted to EIP.
* 11 October 2012: This vulnerability was rejected by EIP.
* 2 November 2012: This vulnerability was submitted to ZDI.
* 19 November 2012: This vulnerability was acquired by ZDI.
* 22 January 2013: This vulnerability was disclosed to Microsoft by ZDI.
* 29 May 2013: Microsoft addresses this vulnerability in MS13-037.
* 8 December 2016: Details of this vulnerability are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] MSIE 9 MSHTML CElement::Has­Flag memory corruption

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found that I have not released before. This is the twenty-ninth entry
in the series. This information is available in more detail on my blog
at http://blog.skylined.nl/20161209001.html. There you can find a repro
that triggered this issue in addition to the information below.

If you find these releases useful, and would like to help me make time
to continue releasing this kind of information, you can make a donation
in bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 9 MSHTML CElement::HasFlag memory corruption
=
(The fix and CVE number for this issue are not known)

Synopsis

A specially crafted web-page can trigger a memory corruption
vulnerability in Microsoft Internet Explorer 9. I did not investigate
this vulnerability thoroughly, so I cannot speculate on the potential
impact or exploitability.

Known affected software and attack vectors
--
* Microsoft Internet Explorer 9

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript should prevent an attacker
  from triggering the vulnerable code path.

Details
---
This bug was found back when I had very little knowledge and tools to do
analysis on use-after-free bugs, so I have no details to share. In
addition, EIP said they were already aware of the bug and provided no
details, this issue appears to have been fixed before ZDI was able to
look at it.

Time-line
-
* 27 September 2012: This vulnerability was found through fuzzing.
* 7 November 2012: This vulnerability was submitted to EIP.
* 27 November 2012: This vulnerability was rejected by EIP.
* 28 November 2012: This vulnerability was submitted to ZDI.
* Between December 2012 and February 2013: Microsoft addresses this
  vulnerability.
* 27 February 2012: This vulnerability was rejected by ZDI.
* 8 December 2016: Details of this vulnerability are released.

I would like to note that although ZDI did not acquire the vulnerability
as it was patched before they could finish analysis, they did offer me
ZDI reward points as a courtesy.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2013-3111: MSIE 9 IEFRAME CSelectionInteractButtonBehavior::_UpdateButtonLocation use-after-free

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found that I have not released before. This is the thirtieth entry
in the series. This information is available in more detail on my blog
at http://blog.skylined.nl/20161212001.html. There you can find a repro
that triggered this issue in addition to the information below.

If you find these releases useful, and would like to help me make time
to continue releasing this kind of information, you can make a donation
in bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 9 IEFRAME CSelectionInteractButtonBehavior::_UpdateButtonLocation
use-after-free
===
(MS13-047, CVE-2013-3111)

Synopsis

A specially crafted web-page can trigger a use-after-free vulnerability
in Microsoft Internet Explorer 9. I did not investigate this
vulnerability thoroughly, so I cannot speculate on the potential impact
or exploitability.

Known affected software and attack vectors
--
* Microsoft Internet Explorer 9
  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript should prevent an attacker
  from triggering the vulnerable code path.

Details
---
This bug was found back when I had very little knowledge and tools to do
analysis on use-after-free bugs, so I have no details to share. EIP
revealed that this was a use-after-free vulnerability.

Time-line
-
* 27 September 2012: This vulnerability was found through fuzzing.
* 3 December 2012: This vulnerability was submitted to EIP.
* 10 December 2012: This vulnerability was rejected by EIP.
* 12 December 2012: This vulnerability was submitted to ZDI.
* 25 January 2013: This vulnerability was acquired by ZDI.
* 15 February 2013: This vulnerability was disclosed to Microsoft by
  ZDI.
* 27 June 2013: This vulnerability was address by Microsoft in MS13-047.
* 8 December 2016: Details of this vulnerability are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] MSIE 9 MSHTML CMarkup::ReloadInCompatView use-after-free

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found that I have not released before. This is the thirty-first entry
in the series. This information is available in more detail on my blog
at http://blog.skylined.nl/20161213001.html. There you can find a repro
that triggered this issue in addition to the information below.

If you find these releases useful, and would like to help me make time
to continue releasing this kind of information, you can make a donation
in bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE9 MSHTML CMarkup::ReloadInCompatView use-after-free
===
(The fix and CVE number for this issue are not known)

Synopsis


A specially crafted web-page can trigger a use-after-free vulnerability
in Microsoft Internet Explorer 9. During a method call, the `this`
object can be freed and then continues to be used by the code that
implements the method. It appears that there is little to no time for an
attacker to attempt to control the contents of the freed memory before
the re-use, which would allow remote code execution.

Known affected software and attack vectors
--
* Microsoft Internet Explorer 9
  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript should prevent an attacker
  from triggering the vulnerable code path.

Details
---
By switching the a document's `designMode` property to `on` in a
deferred script, MSIE 9 can be made to reload a web page using
`CMarkup::ReloadInCompatView`. This method calls
`CDoc::CompatViewRefresh`, which indirectly calls
`CScriptCollection::~CScriptCollection`, which releases the `CMarkup`
object used as `this` in `CMarkup::ReloadInCompatView`.

The relevant stack for the freeing of this `CMarkup` object is:
```
76e8c484 kernel32!HeapFree+0x0014
6780c4d8 MSHTML!CMarkup::`vector deleting destructor'+0x0026
6776fb9b MSHTML!CScriptCollection::~CScriptCollection+0x0152
67816a0d MSHTML!CScriptCollection::Release+0x0053
6751f7e7 MSHTML!CWindow::SuperNavigateInternal+0x04c4
675209f7 MSHTML!CWindow::SuperNavigate2WithBindFlags+0x0032
679b05f8 MSHTML!CDoc::CompatViewRefresh+0x00a0
679c00d4 MSHTML!CMarkup::ReloadInCompatView+0x021f
```

Immediately after returning to `CMarkup::ReloadInCompatView`, the code
will use the (now freed) `CMarkup` object. When page heap is enabled,
this lead to an immediate access violation.

Exploit
---
I did not immediately find a way to control the freed memory before the
reuse following the `CDoc::CompatViewRefresh` call. I did not
immediately find other locations in the code where the same stale
pointer to the `CMarkup` object is used after it has been freed. It may
not be possible to exploit this use-after-free, as there does not appear
to be an easy window of opportunity to modify the freed memory before
its reuse.

However, when loading the repro in MSIE with page heap disabled, I do
see crashes from time to time, but in different locations in the code.
This indicates that one or more of the following should be true:
* There are ways to modify the freed `CMarkup` object before it is
  reused.
* There are other locations where the freed `CMarkup` object is used
  after it has been freed, and the freed `CMarkup` object can be
  modified before this happens.
* There could be other stale pointers to freed memory that get reused,
  and there are ways to modify the freed memory they point to before
  that reuse.

As these other crash stacks do not include
`CMarkup::ReloadInCompatView`, it seems most likely that they are caused
by the second or third option, which could indicate that the bug is in
fact exploitable.

Time-line
-
* 5 May 2014: This vulnerability was found through fuzzing.
* 14 May 2014: This vulnerability was submitted to ZDI.
* 3 July 2014: This vulnerability was rejected by ZDI.
* 9 July 2014: This vulnerability was submitted to EIP.
* July/August 2014: This vulnerability was rejected by EIP.
* 13 August 2014: This vulnerability was submitted to iDefense.
* Date unknown: This issue was withdrawn from iDefense.
* Date unknown: This vulnerability was address by Microsoft.
* 13 December 2016: Details of this vulnerability are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2013-3143: MSIE 9 IEFRAME CMarkup..Remove­Pointer­Pos use-after-free

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found that I have not released before. This is the 32nd entry in the
series. This information is available in more detail on my blog at
http://blog.skylined.nl/20161214001.html. There you can find a repro
that triggered this issue in addition to the information below.

If you find these releases useful, and would like to help me make time
to continue releasing this kind of information, you can make a donation
in bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 9 IEFRAME CMarkup..RemovePointerPos use-after-free
===
(MS13-055, CVE-2013-3143)

Synopsis

A specially crafted web-page can trigger a use-after-free vulnerability
in Microsoft Internet Explorer 9. I did not investigate this
vulnerability thoroughly, so I cannot speculate on the potential impact
or exploitability.

Known affected software and attack vectors
--
* **Microsoft Internet Explorer 9**

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript should prevent an attacker
  from triggering the vulnerable code path.

Details
---
This bug was found back when I had very little knowledge and tools to do
analysis on use-after-free bugs, so I have no details to share. ZDI
revealed that this was a use-after-free vulnerability, though their
advisory (at http://www.zerodayinitiative.com/advisories/ZDI-13-163/)
mentions an iframe, which is not in the repro I provided.

Time-line
-
* Sometime in November 2012: This vulnerability was found through fuzzing.
* 11 November 2012: This vulnerability was submitted to EIP.
* 10 December 2012: This vulnerability was rejected by EIP.
* 12 December 2012: This vulnerability was submitted to ZDI.
* 25 January 2013: This vulnerability was acquired by ZDI.
* 15 February 2013: This vulnerability was disclosed to Microsoft by
  ZDI.
* 26 July 2013: This vulnerability was address by Microsoft in MS13-055.
* 14 December 2016: Details of this vulnerability are released.

Cheers,

SkyLined



signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] MSIE 9 IEFRAME CMarkup­Pointer::Move­To­Gap use-after-free

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found that I have not released before. This is the 33rd entry in the
series. This information is available in more detail on my blog at
http://blog.skylined.nl/20161215001.html. There you can find a repro
that triggered this issue in addition to the information below.

If you find these releases useful, and would like to help me make time
to continue releasing this kind of information, you can make a donation
in bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 9 IEFRAME CMarkupPointer::MoveToGap use-after-free
===
(The fix and CVE number for this issue are not known)

Synopsis

A specially crafted web-page can trigger a use-after-free vulnerability
in Microsoft Internet Explorer 9. The use appears to happen only once
almost immediately after the free, which makes practical exploitation
unlikely.

Known affected software and attack vectors
--
* Microsoft Internet Explorer 9

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript should prevent an attacker
  from triggering the vulnerable code path.

Details
---
It appears there is an implementation bug in the `splitText` method of
`CDATASection` (Text) objects in SVG. `splitText` should split a `Text`
node into two `Text` nodes, by creating a new `Text` node and moving
some of the text data from the original node to the new node. After
this, each node contains a sub-string of the original text.

The bug can be triggered by calling this method with zero as the index
argument on a `CDATASection` which contains some text. In this case, the
code will return a new `Text` node that contains the entire text but it
does not remove the text from the original node. I am speculating that
this causes an additional reference to the test data without increasing
its reference counter. This failure to increase the reference counter
can cause this reference counter to drop to zero before all references
are destroyed.

Time-line
-
* Unknown date: This vulnerability was found through fuzzing.
* 12 December 2012: This vulnerability was submitted to EIP.
* 21 January 2013: This vulnerability was rejected by EIP.
* Unknown date: This vulnerability was address by Microsoft.
* 15 December 2016: Details of this vulnerability are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2013-0090: MSIE 9 IEFRAME CView::EnsureSize use-after-free

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found that I have not released before. This is the 34th entry in the
series. This information is available in more detail on my blog at
http://blog.skylined.nl/20161216001.html. There you can find a repro
that triggered this issue in addition to the information below.

If you find these releases useful, and would like to help me make time
to continue releasing this kind of information, you can make a donation
in bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 9 IEFRAME CView::EnsureSize use-after-free
===
(MS13-021, CVE-2013-0090)

Synopsis

A specially crafted web-page can trigger a use-after-free vulnerability
in Microsoft Internet Explorer 9. I did not investigate this
vulnerability thoroughly, so I cannot speculate on the potential impact
or exploitability.

Known affected software and attack vectors
--
* Microsoft Internet Explorer 9

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript should prevent an attacker
  from triggering the vulnerable code path.

Details
---
This bug was found back when I had very little knowledge and tools to do
analysis on use-after-free bugs, so I have no details to share. ZDI
revealed that this was a use-after-free vulnerability in their advisory
at http://www.zerodayinitiative.com/advisories/ZDI-13-097/.

Time-line
-
* Sometime in October 2012: This vulnerability was found through
  fuzzing.
* 29 October 2012: This vulnerability was submitted to EIP.
* 27 November 2013: This vulnerability was rejected by EIP.
* 14 January 2013: This vulnerability was submitted to ZDI.
* 6 February 2013: This vulnerability was acquired by ZDI.
* 13 February 2013: This vulnerability was disclosed to Microsoft by
  ZDI.
* 29 May 2013: This vulnerability was address by Microsoft in MS13-021.
* 14 December 2016: Details of this vulnerability are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2013-6627: Chrome Chrome HTTP 1xx base::StringTokenizerT<...>::QuickGetNext OOBR

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found that I have not released before. This is the 35th entry in the
series. This information is available in more detail on my blog at
http://blog.skylined.nl/20161219001.html. There you can find a repro
that triggered this issue in addition to the information below, it also
provides code snippets for the affected code, and a diagram that
attempts to explain the memory layout.

This advisory contains a lot more information about the root cause and
how to exploit it, as Google Bug Bounties reward high quality
bug-reports to a point where it is worth investigating a bug in detail.

If you find these releases useful, and would like to help me make time
to continue releasing this kind of information, you can make a donation
in bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

Chrome HTTP 1xx base::StringTokenizerT<...>::QuickGetNext OOBR
==
(CVE-2013-6627)

Synopsis

A specially crafted HTTP response can allow a malicious web-page to
trigger a out-of-bounds read vulnerability in Google Chrome. The data is
read from the main process' memory.

Known affected software, attack vectors and potential mitigations
-
* Google Chrome up to, but not including, 31.0.1650.48

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript does not prevent an attacker
  from triggering the vulnerable code path, but may prevent
  exfiltration of information.

  Since the affected code has not been changed since 2009, I assume this
  affects all versions of Chrome released in the last few years.

Details
---
The `HttpStreamParser` class is used to send HTTP requests and receive
HTTP responses. Its `read_buf_` member is a buffer used to store HTTP
response data received from the server. Parts of the code are written
under the assumption that the response currently being parsed is always
stored at the start of this buffer (as returned by
`read_buf_->StartOfBuffer()`), other parts take into account that this
may not be the case (`read_buf_->StartOfBuffer() +
read_buf_unused_offset_`). In most cases, responses are removed from the
buffer once they have been parsed and any superfluous data is moved to
the beginning of the buffer, to be treated as part of the next response.
However, the code special cases `HTTP 1xx` replies and returns a result
without removing the request from the buffer. This means that the
response to the next request will not be stored at the start of the
buffer, but after this `HTTP 1xx` response and `read_buf_unused_offset_`
should be used to find where it starts.

A look through the code has revealed one location where this can lead to
a security issue (also in `DoReadHeadersComplete`). The code uses an
offset from the start of the buffer (rather than the start of the
current responses) to pass as an argument to a `DoParseResponseHeaders`.
`DoParseResponseHeaders` passes the argument unchanged to
`HttpUtil::AssembleRawHeaders`. The `HttpUtil::AssembleRawHeaders`
method takes two arguments: a pointer to a buffer, and the length of the
buffer. The pointer is calculated correctly (in
`DoParseResponseHeaders`) and points to the
start of the current response. The length is the offset that was
calculated incorrectly in `DoReadHeadersComplete`. If the current
response is preceded by a `HTTP 1xx` response in the buffer, this length
is larger than it should be: the calculated value will be the correct
length plus the size of the previous `HTTP 1xx` response
(`read_buf_unused_offset_`).

The code will continue to rely on this incorrect value to try to create
a copy of the headers, inadvertently making a copy of data that is not
part of this response and may not even be part of the `read_buf_`
buffer. This could cause the code to copy data from memory that is
stored immediately after `read_buf_` into a string that represents the
response headers. This string is passed to the renderer process that
made the request, allowing a web-page inside the sandbox to read memory
from the main process' heap.

Exploit
---
The impact depends on what happens to be stored on the heap immediately
following the buffer. Since a web-page can influence the activities of
the main process (e.g. it can ask it to make other HTTP requests), a
certain amount of control over the heap layout is possible. An attacker
could attempt to create a "heap feng shui"-like attack where careful
manipulation of the main process' activities allow reading of various
types of information from the main process' heap. The most obvious
targets that come to mind are http request/response data for different
domains, such as log-in cookies, or session keys and function pointers
that can be used to bypass ASLR/DEP. There are undoubtedly many other
fo

[FD] CVE-2014-1785: MSIE 11 MSHTML CSpliceTreeEngine::RemoveSplice use-after-free

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found that I have not released before. This is the 36th entry in the
series. This information is available in more detail on my blog at
http://blog.skylined.nl/20161220001.html. There you can find a repro
that triggered this issue in addition to the information below, as well
as a Proof-of-Concept exploit that attempts to prove exploitability.

If you find these releases useful, and would like to help me make time
to continue releasing this kind of information, you can make a donation
in bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 11 MSHTML CSpliceTreeEngine::RemoveSplice use-after-free
=
(MS14-035, CVE-2014-1785)

Synopsis

A specially crafted web-page can trigger a use-after-free vulnerability
in Microsoft Internet Explorer 11. There is sufficient time between the
free and reuse for an attacker to control the contents of the freed
memory and exploit the vulnerability.

Known affected software, attack vectors and potential mitigations
-
* Microsoft Internet Explorer 11

  An attacker would need to get a target user to open a specially
  crafted web-page. Disabling JavaScript should prevent an attacker
  from triggering the vulnerable code path.

Details
---
This was one of the first bugs where I attempted to do a proper
analysis, and I got some feedback from ZDI that explained what I got
right and what I got wrong. Basically, on x86, a 0x28 byte memory block
is allocated in `MSHTML!CMarkup::DoEmbedPointers` and when you execute
`document.execCommand("Delete")`. This memory can be freed when you
execute `document.open()` in a `DOMNodeRemoved` event handler. After
that, you can use Javascript to reallocate the memory before it is reused.

Time-line
-
* 30 December 2013: This vulnerability was submitted to ZDI.
* 8 January 2014: This vulnerability was acquired by ZDI.
* 14 January 2014: This vulnerability was disclosed to Microsoft by ZDI.
* 10 June 2014: This vulnerability was address by Microsoft in MS14-035.
* 20 December 2016: Details of this vulnerability are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] CVE-2014-4138: MSIE 11 MSHTML CPaste­Command::Convert­Bitmapto­Png heap-based buffer overflow

[Berend-Jan Wever]

Since November I have been releasing details on all vulnerabilities I
found that I have not released before. This is the 37th entry in the
series. This information is available in more detail on my blog at
http://blog.skylined.nl/20161221001.html. There you can find a repro
that triggered this issue in addition to the information below, as well
as a Proof-of-Concept exploit that attempts to prove exploitability.

If you find these releases useful, and would like to help me make time
to continue releasing this kind of information, you can make a donation
in bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

MSIE 11 MSHTML CPasteCommand::ConvertBitmaptoPng heap-based BOF
===
(MS14-056, CVE-2014-4138)

Synopsis

A specially crafted web-page can trigger an out-of-bounds write in
Microsoft Internet Explorer 11. Code that handles pasting images from
the clipboard uses an incorrect buffer length, which allows writing
beyond the boundaries of a heap-based buffer. An attacker able to
trigger this vulnerability can execute arbitrary code.

Known affected software, attack vectors and potential mitigations
-
* **Microsoft Internet Explorer 11.0.9600.16521**

  An attacker would need to get a target user to open a specially
  crafted web-page. In order to trigger the issue, the web-page needs
  to either programmatically copy/paste an image using Javascript or
  get the user to do this (for instance by tricking the user into
  typing keyboard shortcuts such as CTRL+C/CTRL+V) . By default, MSIE
  prompts the user to allow or disallow programmatically copy/pasting
  the first time a website tries to do this, so user-interaction is
  normally required in such cases. Disabling the `Allow Programmatic
  clipboard access` setting in `Internet Options` -> `Security
  Settings` -> [Choose a zone] -> `Scripting` should prevent websites
  from programmatically copy/pasting an image. Disabling execution of
  scripts on web-pages altogether will have the same effect. Please
  note that neither option prevents a website from social engineering
  the user into typing a keyboard shortcut to copy/paste the image.

Details
---
When an image is pasted in MSHTML, it gets converted from BMP format to
PNG. This is done in the `MSHTML!CPasteCommand::ConvertBitmaptoPng`
function. This function incorrectly uses the size of the original BMP
image to allocate memory for storing the converted PNG image. The PNG
image will be smaller than the BMP under most circumstances, but if a
specially crafted image leads to the original BMP image being smaller
than the converted PNG, the function will write PNG data beyond the
bounds of the allocated memory.

Exploit
---
An attacker looking to exploit this issue will commonly attempt to get
the memory allocated to store the PNG image in a location that is
followed by a pre-allocated memory block that contains information the
attacker would like to modify. Using the buffer overflow, the attacker
can overwrite this pre-allocated memory block with attacker controlled
data. Depending on the type of the pre-allocated memory, this could
allow the attacker to read or modify arbitrary information within the
process and take control of execution flow. No attempt was made to
create a Proof-of-Concept that shows this level of control.

Time-line
-
* 8 May 2014: This vulnerability was submitted to ZDI.
* 9 June 2014: This vulnerability was acquired by ZDI.
* 23 June 2014: This vulnerability was disclosed to Microsoft by ZDI.
* 14 October 2014: This vulnerability was address by Microsoft in
  MS14-056.
* 21 December 2016: Details of this vulnerability are released.

Cheers,

SkyLined


0x2557C5AA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Is the era of ezine txt files over?

[Berend-Jan Wever]

​​While search engines may have taken away the need to bundle contributions
into magazines, and I think the desire to direct traffic to one's personal
site also contributes to decentralization, all this does not explain the
shocking lack of ASCII art in most exploits.

Cheers,

SkyLined 

 ,g6SSSs,

   ,sdSS5c, `YSP^`   `'YSb
 SS
 ,SY'  `'YSb  SS  ` TSi
SS
 iS` JSS` SS _  `SS  __
SS
 YS,   `YSSY  SS   _   ,sSb  SS  SS (SS) SS_sdSbj,,s'
SS
 *Sb_`*   SS,yiSk SS*`   SS  SS  ^^  SSP'` `*Sj  dS' SS'
,sSSS
  `*YSb,_ SS ,iSP"`   SS,   _SS  SS  ss  SS  SS)(SS (SY'
 SS
  `"Yb,   SSS*^'YS,*YSSSPSS  SS  SS  SS ,SP  YS,__  SS
 SS
  gSSSb  !Si  SS SS  _   SS  SP  SS  SS   ,dSS`   "7YSb YS,_
 YS
 SS' SSP  SS  SS  _.dSP  )Ss,_  ,SS (S7  SS  SP'   Y'
 "YSbjg,JS
 SS,_dS7  SS`YSSP* .dSSPYSSSP*  iS)  ^^  '   ..ygjjdd=ESt.
``^"*$
  *YS*`   "P  P`   .SSbyid6SSYYVV**''^^```1996

  dY*"^``  ^^



​​

On Thu, Jul 10, 2014 at 7:12 PM, Aaron Peterson  wrote:

> I think POC||GTFO is the best modern version of this, and it still has a
> lot of old-school feel to it.  Here is one of the mirror sites:
> http://openwall.info/wiki/people/solar/pocorgtfo
>
>
> On Thu, Jul 10, 2014 at 3:19 AM,  wrote:
>
> > Hi,
> >
> > I am way too fresh in infosec to have seen many of the classic ezine txt
> > files as they first appeared, but have enjoyed learning from them. Even
> as
> > recent as 2006, there's been cool ones like:
> >
> > http://repo.fea.st/dot-aware-alpha.txt
> >
> > Sure Phrack releases once in a while but in general, is the era of ezine
> > txt files now over? Do people no longer pack everything into ascii art
> for
> > the sake of learning?
> >
> > --
> > rai
> >
> >
> > ___
> > Sent through the Full Disclosure mailing list
> > http://nmap.org/mailman/listinfo/fulldisclosure
> > Web Archives & RSS: http://seclists.org/fulldisclosure/
> >
>
> ___
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/
>

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] 1501H - MSIE 8 - F12 Developer Tools tooltips use-after-free

[Berend-Jan Wever]

​TL;DR: Full disclosure of low risk 0-day in MSIE 8 after 60-day deadline
passed
without a fix.

1501H - MSIE 8 - F12 Developer Tools tooltips use-after-free
=

Synopsis

When using the Developer Tools of MSIE 8, one might hover the mouse over a
button in the "Script" tab, at which point a "tooltip" is shown. If one then
clicks the button, a use-after-free occurs.

Known affected software and attack vectors
--
  + MSIE 8

An attacker would need to get a target user to open a specially crafted
webpage. The attacker would then need to trick the target user into
hovering
the mouse over a button until the tooltip is shown and then click the
button.

Description
---
Open a new tab, and then open the Developer Tools by pressing F12, or
selecting it from the "Tools" menu. Then select the "Scripts" tab in the
Developer Tools window. Next hover the mouse over one of the buttons with
the
text "Start Debugging", "Run Script" and "Multi Line Mode"/"Single Line
Mode".
When a tooltip is shown, click the button. Here's what happens next with
paged
heap enabled:

(4dc.814): Access violation - code c005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0b507fd0 ebx=0200 ecx=06a48ea0 edx=0001 esi=06a48ea0
edi=09a21fd0
eip=7427c0d6 esp=0b40f98c ebp=0b40f98c iopl=0 nv up ei pl nz na po
nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=
efl=00010202
comctl32!CToolTipsMgr::PopBubble+0xc:
7427c0d6 8b400c  mov eax,dword ptr [eax+0Ch]
ds:0023:0b507fdc=

1:019> kP
ChildEBP RetAddr
0b40f98c 7427aa85 comctl32!CToolTipsMgr::PopBubble+0xc
0b40f9b4 741fc26a comctl32!CToolTipsMgr::HandleRelayedMessage+0x117
0b40faec 741fbf57 comctl32!CToolTipsMgr::ToolTipsWndProc+0x944
0b40fb18 7651c4e7 comctl32!CToolTipsMgr::s_ToolTipsWndProc+0x32
0b40fb44 7651c5e7 USER32!InternalCallWinProc+0x23
0b40fbbc 76515294 USER32!UserCallWinProcCheckWow+0x14b
0b40fbfc 76515582 USER32!SendMessageWorker+0x4d0
0b40fc1c 741fc235 USER32!SendMessageW+0x7c
0b40fc58 741f42aa comctl32!RelayToToolTips+0x49
0b40fc78 741ff5ee comctl32!TTSubclassProc+0x33
0b40fcdc 741ff490 comctl32!CallNextSubclassProc+0x3d
0b40fd3c 7651c4e7 comctl32!MasterSubclassProc+0x54
0b40fd68 7651c5e7 USER32!InternalCallWinProc+0x23
0b40fde0 7651cc19 USER32!UserCallWinProcCheckWow+0x14b
0b40fe40 7651cc70 USER32!DispatchMessageWorker+0x35e
0b40fe50 6e8e98ef USER32!DispatchMessageW+0xf
WARNING: Stack unwind information not available. Following frames may be
wrong.
0b40fe84 6e8ee3fb iedvtool+0x598ef
0b40fe9c 76ceee1c iedvtool+0x5e3fb
0b40fea8 770c37eb kernel32!BaseThreadInitThunk+0xe
0b40fee8 770c37be ntdll!__RtlUserThreadStart+0x70
0b40ff00  ntdll!_RtlUserThreadStart+0x1b

1:019> !heap -p -a @eax
address 0b507fd0 found in
_DPH_HEAP_ROOT @ 161000
in free-ed allocation (  DPH_HEAP_BLOCK: VirtAddr
VirtSize)
b5119f4:  b507000
2000
6fb3947d verifier!AVrfDebugPageHeapReAllocate+0x036d
7712620b ntdll!RtlDebugReAllocateHeap+0x0033
770ee4f0 ntdll!RtlReAllocateHeap+0x0054
741f27fe comctl32!CToolTipsMgr::AddTool+0x0031
741f28ca comctl32!CToolTipsMgr::ToolTipsWndProc+0x09a4
741fbf57 comctl32!CToolTipsMgr::s_ToolTipsWndProc+0x0032
7651c4e7 USER32!InternalCallWinProc+0x0023
7651c5e7 USER32!UserCallWinProcCheckWow+0x014b
76515294 USER32!SendMessageWorker+0x04d0
76515582 USER32!SendMessageW+0x007c
69cc8c71 jsdbgui+0x00028c71
69cc8fa2 jsdbgui+0x00028fa2
69cc903b jsdbgui+0x0002903b
69cca6e2 jsdbgui+0x0002a6e2
69cc5513 jsdbgui+0x00025513
7651c4e7 USER32!InternalCallWinProc+0x0023
76535b7c USER32!UserCallDlgProcCheckWow+0x0132
765359f3 USER32!DefDlgProcWorker+0x00a8
7653a60e USER32!SendMessageWorker+0x0340
76515582 USER32!SendMessageW+0x007c
741fc05d comctl32!CCSendNotify+0x03e3
741f364c comctl32!SendNotifyEx+0x0063
7427a9f4 comctl32!CToolTipsMgr::PopBubble+0x00a3
7427c016 comctl32!CToolTipsMgr::PopBubble+0x001c
7427b50b comctl32!CToolTipsMgr::ShowVirtualBubble+0x0010
741fc26a comctl32!CToolTipsMgr::ToolTipsWndProc+0x0944
741fbf57 comctl32!CToolTipsMgr::s_ToolTipsWndProc+0x0032
7651c4e7 USER32!InternalCallWinProc+0x0023
7651c5e7 USER32!UserCallWinProcCheckWow+0x014b
76515294 USER32!SendMessageWorker+0x04d0
76515582 USER32!SendMessageW+0x007c
741fc235 comctl32!RelayToToolTips+0x0049

Exploit
---
Because the attacker vector appears highly unlikely to represent a risk to
any
user, I did not bother to do an in-depth investigation. However, the
use-after-
free occurs in the same process in which the web-page is rendered. This
suggests
that there may be a way for the web-page to reallocate the