ed0e1e4d44
1979 changes to exploits/shellcodes Couchdb 1.5.0 - 'uuids' Denial of Service Apache CouchDB 1.5.0 - 'uuids' Denial of Service Beyond Remote 2.2.5.3 - Denial of Service (PoC) udisks2 2.8.0 - Denial of Service (PoC) Termite 3.4 - Denial of Service (PoC) SoftX FTP Client 3.3 - Denial of Service (PoC) Silverstripe 2.3.5 - Cross-Site Request Forgery / Open redirection SilverStripe CMS 2.3.5 - Cross-Site Request Forgery / Open Redirection Silverstripe CMS 3.0.2 - Multiple Vulnerabilities SilverStripe CMS 3.0.2 - Multiple Vulnerabilities Silverstripe CMS 2.4 - File Renaming Security Bypass SilverStripe CMS 2.4 - File Renaming Security Bypass Silverstripe CMS 2.4.5 - Multiple Cross-Site Scripting Vulnerabilities SilverStripe CMS 2.4.5 - Multiple Cross-Site Scripting Vulnerabilities Silverstripe CMS 2.4.7 - 'install.php' PHP Code Injection SilverStripe CMS 2.4.7 - 'install.php' PHP Code Injection Silverstripe Pixlr Image Editor - 'upload.php' Arbitrary File Upload SilverStripe CMS Pixlr Image Editor - 'upload.php' Arbitrary File Upload Silverstripe CMS 2.4.x - 'BackURL' Open Redirection SilverStripe CMS 2.4.x - 'BackURL' Open Redirection Silverstripe CMS - 'MemberLoginForm.php' Information Disclosure SilverStripe CMS - 'MemberLoginForm.php' Information Disclosure Silverstripe CMS - Multiple HTML Injection Vulnerabilities SilverStripe CMS - Multiple HTML Injection Vulnerabilities Apache CouchDB 1.7.0 and 2.x before 2.1.1 - Remote Privilege Escalation Apache CouchDB 1.7.0 / 2.x < 2.1.1 - Remote Privilege Escalation Monstra CMS before 3.0.4 - Cross-Site Scripting Monstra CMS < 3.0.4 - Cross-Site Scripting (2) Monstra CMS < 3.0.4 - Cross-Site Scripting Monstra CMS < 3.0.4 - Cross-Site Scripting (1) Navigate CMS 2.8 - Cross-Site Scripting Collectric CMU 1.0 - 'lang' SQL injection Joomla! Component CW Article Attachments 1.0.6 - 'id' SQL Injection LG SuperSign EZ CMS 2.5 - Remote Code Execution MyBB Visual Editor 1.8.18 - Cross-Site Scripting Joomla! Component AMGallery 1.2.3 - 'filter_category_id' SQL Injection Joomla! Component Micro Deal Factory 2.4.0 - 'id' SQL Injection RICOH Aficio MP 301 Printer - Cross-Site Scripting Joomla! Component Auction Factory 4.5.5 - 'filter_order' SQL Injection RICOH MP C6003 Printer - Cross-Site Scripting Linux/ARM - Egghunter (PWN!) + execve(_/bin/sh__ NULL_ NULL) Shellcode (28 Bytes) Linux/ARM - sigaction() Based Egghunter (PWN!) + execve(_/bin/sh__ NULL_ NULL) Shellcode (52 Bytes)
30 lines
No EOL
4.2 KiB
Text
30 lines
No EOL
4.2 KiB
Text
Source: https://code.google.com/p/google-security-research/issues/detail?id=504
|
||
|
||
The latest version of the Vector.<primitive> length check in Flash 18,0,0,232 is not robust against memory corruptions such as heap overflows. While it’s no longer possible to obviously bypass the length check there’s still unguarded data in the object which could be corrupted to serve as a useful primitive.
|
||
|
||
To better describe this currently the Vector primitive object (at least on 32 bit) looks something like:
|
||
|
||
| unguarded length | unguarded capacity | xored length | ... | data |
|
||
|
||
The problem arises because the capacity is not guarded by the xor, and it’s before the xored length which is guarded. As we know the unguarded length value then if we have a suitable memory corruption vulnerability we could corrupt only the length and the capacity fields leaving the xored length alone. Of course we’d need to corrupt the length back to the same value (otherwise the length guard check would fail). If we set the capacity to be greater than that originally allocated then when a call is made to set the length (using the length Vector property) the runtime will assume the allocation is larger than it is and extend the vector over the end of the original allocation.
|
||
|
||
This in itself is not enough to serve as a useful primitive as extending the vector also 0’s any data afterwards so it’s not an information leak. However we’ve now got a vector which aliases some other part of the heap. If for example something else was allocated immediately after the vector which we can influence then it’d be possible to write data to that and read it out from the vector, and vice versa. Also depending on the heap type it might be possible to reconstruct heap headers, but it probably isn’t on Windows. As vector objects are now on the system heap it’s a lot harder to exploit. It’s likely that an attacker would need to utilize browser specific heap allocations rather than another flash allocation.
|
||
|
||
One way of fixing this, at least against buffer overflows, would be to move the xored length before the capacity. In this case the act of overflowing the capacity value would corrupt the guard length leading to the check failure when setting the new length to exceed the existing capacity. This wouldn’t do anything against a heap relative overwrite or a buffer underflow. In that case you could also apply the guard to the capacity field as well. If Vectors are completely moved out from the heap with other objects, as planned, exploiting this would probably be very difficult.
|
||
|
||
On a related note, it’s still possible to read the length of the vector without triggering the guard check. The length is whatever the unguarded length is set to. This could be used as a way of checking which vector objects have been corrupted by an overflow.
|
||
|
||
I’ve provided a simple example which allocates a 16k UInt vector. Using a debugger you can modify the capacity then press a key to show that the process doesn’t crash (at least doesn’t crash due to a length corruption). The following instructions are for IE11 with 32 bit tabs (the default even on x64 builds).
|
||
|
||
1. Load the swf file into IE
|
||
2. Attach WinDBG to the IE tab process
|
||
3. Search for the data pattern to find the vector using the command “s 0 L?10000000 78 56 34 12 f0 de bc 9a 00 00 00 00”. There should only be one hit.
|
||
4. Modify the capacity using the command “ed <address>-0xC 5000” replacing <address> with that found in step 3. Also look at <address>+0n64*0n1024 which will should show other data on the heap.
|
||
5. Resume execution in the debugger.
|
||
6. Select the flash object in the browser and press the ‘=’ key, you should see a trace message printing the new length.
|
||
7. If you return to the debugger and dump the data at <addresss>+0n64*0n1024 you’ll find the memory has been zeroed. Also at <addresss>+0n64*0n1024+3C you should find that the value 0x88888888 has been written to existing allocated memory.
|
||
|
||
The source is a HAXE file, you need to compile with the command line “haxe -main Test -swf output.swf -swf-version 10”
|
||
|
||
Proof of Concept:
|
||
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/38348.zip |