libxml2 vulnerability, a new hack vector for Vita and PS4?
Scene member Dragood2 dropped by our forums recently to point a new vulnerability in libxml2, an open source XML processing library.
The interesting part for readers of this blog is that libxml2 is a library used both on the PS4 and the PS Vita. An exploitable vulnerability in the library could potentially be ported to these consoles.
I was expecting the forum thread would generate lots of replies but it hasn’t received the attention it deserves so far. The vulnerability is fresh, so it is most likely present on the PS4 and the PS Vita. The question of course, is if this could lead to an exploit or not. From
dragood2 the oss-sec mailing list:
A couple of weeks back while working on a related bug [CVE-2016-3627] I discovered a specially created xml file is capable of triggering a stack overflow before libxml2 can detect its a invalid xml file.
The vulnerability triggers a stack overflow, and now has its own CVE: CVE-2016-3705.
For the PS4, CTurt has confirmed to me that FreeBSD has had Stack Protector baked in since FreeBSD 8.0, meaning that this vulnerability (if confirmed on PS4) would be useless on its own (Unless some other exploit could help bypass stack protection?).
Status of the vulnerability on the PS Vita is unknown so far and I don’t think anyone has tested. I do not know if the PS Vita’s firmware has some sort of stack protection implemented. Given that the PS Vita has been a tough nut to crack with pretty advanced security, it wouldn’t be surprising, but it would be great if Vita experts could chime in.
In order to test, someone would need to confirm if the test file (provided in the source link below) actually crashes the PS Vita (or the PS4) when accessed. To access such an XML file, one might have to use a proxy such as SKFU Pr0xy in order to trick the console and download the test file instead of one of the regular XML files it uses, for example to check for firmware update.
There’s some test work to be done here, but nothing fundamentally hard.
Normally I would not blog about this in such early stages, when nothing’s been confirmed, but I think this needs some visibility, and people with time+skills to confirm if something can be done with this.
Updates: we initially incorrectly implied that dragood2 was behind the vulnerability, the article has been altered to correct that