685168 - XML expansion attack through Javascript leads to crash

Status: NEW

(Core :: XML, defect)

Description

[g0uZ]

Attachment: HTML_XML.txt

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110825133144

Steps to reproduce:

Load a XML file containing an expansion attack with an XMLHttpRequest call. Same effect with nested entities infinite loop. 


Actual results:

Linux : Firefox crash, system is unusable (need to restart X)
Windows XP / Seven : firefox crash, system is slow but usable

All tested version are affected : 3.6.14 / 6.0 / 6.0.1

Firefox is unusable : immediate. Delay for crash is between 10 and 60 seconds.




Expected results:

Protection against XML expansion attack as if the XML file was loaded directly.

Comment 1

[Bob Clary [:bc] (inactive)]

Attachment: expansion_attack.xml

Comment 2

[Bob Clary [:bc] (inactive)]

Attachment: test.html

Comment 3

[Bob Clary [:bc] (inactive)]

Attachment: test.html

now with proper domain.

Comment 4

[g0uZ]

Attachment: Right XML file

Comment 5

[g0uZ]

Funny thing : first XML file provided (with the first entity define as empty) is not detected as a recursion when access directly (without javascript) and also lead to a (less violent) DOS.

Comment 6

[g0uZ]

Attachment: POC

New (good) test file.

Comment 7

[g0uZ]

Comment on attachment 558909 [details]
POC

Does not work on bugzilla...

Comment 8

[g0uZ]

Working POC : http://www.root-me.org/bug_id_685168/poc.html

Comment 9

[Daniel Veditz [:dveditz]]

Definitely confirmed. Since it's sucking up so much memory I had to kill it before it crashed so I don't know if it's going to be stack exhaustion, OOM, or maybe something bad in expat. The stack I saw when I killed it was in DOM node insertion, but the ultimate crash might be later/elsewhere.

Peter: please check whether this is a DoS or worse.

Comment 10

[g0uZ]

It's a memory exhaustion DOS. Firefox will fail trying to allocate memory through mozalloc() call wich lead to INT3 / ERROR_NOT_ENOUGH_MEMORY and "Access Violation when reading 0x00000000".

Does not seems to be exploitable for remote exec (imho).

Comment 11

[Andrew McCreight [:mccr8]]

I don't think a DOS is a huge deal that needs to be S2. It did make the parent process stop responding when I tried to exit, at least in a debug build, so that's something.