Bugs: Difference between revisions
mNo edit summary |
No edit summary |
||
Line 10: | Line 10: | ||
17:17:40.000655000 Request | 17:17:40.000655000 Request | ||
17:17:40 (System locks up) Crash | 17:17:40 (System locks up) Crash | ||
17:17:44.957274000 | 17:17:44.957274000 Response | ||
17:17:48.500481000 Response | 17:17:48.500481000 Response | ||
17:17:48.500567000 Response | 17:17:48.500567000 Response |
Revision as of 15:40, 12 March 2015
Unknown / unpatched
Vidnow (TCP Buffer Overflow)
When you launch Vidnow for the first time it gets http://sceecatalogs.vidzone.tv/386/vidzone_386_US.db.psarc. This file is 5mb. This file loads into a 60k tcp buffer. No checks are done at all on the files size/hash/contents. Therefore, it is possible to redirect Vidnow to load a substitute file. When vidnow is redirected to load a large enough file the TCP Window buffer is overrun,somewhere between byte 34,125,000 and 35,000,000 of the substitute file. Despite the buffer overflow and crash, the substitute data is still transmitted and the application only throws the exception when another tcp packet is sent. As a result, the application crashes and the console locks up for a minute. Directly before the console resumes normal operations after the crash, an unusually large number of tcp (RST) packets are sent. While no exploit that makes use of this crash is currently available, a carefully crafted file may be able to exploit this or similar issues to gain code execution, among other things.
Crash Timeline
17:17:39.899984000 Request 17:17:40.000655000 Request 17:17:40 (System locks up) Crash 17:17:44.957274000 Response 17:17:48.500481000 Response 17:17:48.500567000 Response 17:17:50.356427000 (System no longer locked up) Console Regains Control (74 byte packet sent) 17:17:50.357555000 Contacts Crashlog Server/System Operation Resumes
Sandbox Exploitation
For some reason the system fails to perform any checks/verify certain sys library's before installing them. This allows you to replace those library files with your own binary. The system will install your packaged binary to the HDD as if it were a regular update. In order to run this binary, you need to meet all the requirements listed below.
Running your own code in sandbox requires 4 things:
1.Disabling SHA-1 Checksums ✔ useSha1Checksums = "false" OR -Change SHA-1 checksums to match modified pkg
2.Generate a valid signature/disable or bypass signature authentication ✖ Hash of container + Magic Number form signature -Hash can be computed from modified files -Magic Number = ???
3.Repacking Containers ✔ Lib pkg not signed or encrypted. You can modify everything as long as you don't change the structure.
4.Crafting proper binary ✔ Binary files in sandbox aren't signed or encrypted. If you use the proper version of the compiler (Get the ver info from the original binarys) you can craft a binary that's accepted as valid.
Assuming you can get code running disabling sandboxing is trivial.
Patched
Reference sites
- http://www.vulnerability-lab.com/
- http://seclists.org/
- http://cxsecurity.com/
- http://www.exploit-db.com/
- http://www.osvdb.org/
- http://www.cvedetails.com/vulnerability-list/vendor_id-6/Freebsd.html
- http://www.cvedetails.com/vulnerability-list/vendor_id-6/cvssscoremin-9/cvssscoremax-/Freebsd.html
|