Security issues in PCem [possible emulator escape]

[slipstream]

Hello,

I wish to alert you of two security vulnerabilities I found in PCem. (I actually found them in PCem-X, where they have been fixed, but the vulnerable code exists also in PCem)

The two vulnerabilities are of the same type: array read/write where the index is a 32-bit integer and thanks to lack of bounds checking entirely under attacker control; and in the case of write, byte to be written is also under attacker control.

First issue is in DMA sector read/write in PIIX emulation, the second is in the VRAM read/write (MMU) in ET4000W32p emulation.

I successfully managed to escape the emulator and run a payload on the host using both of these issues.

To fix both issues, add proper bounds checking before accessing the relevant arrays.

Please note, that the reason why I publically post this, is because the issues have been fixed in PCem-X already, and someone could easily see the fixes done there, and find out that they have not been made in PCem, and code their own exploits.

-slipstream/RoL

[SarahWalker]

Is this really an issue though? I'm struggling to think actually what problems you could cause with this. I would have thought that if you can cause arbitrary code execution with this you could cause arbitrary code execution on the host without PCem anyway.

[ecksemmess]

It could easily become an issue as PCem gains in popularity, which seems likely to happen. There will be games and other software titles that become widely known for running best in PCem, and it would then be trivial for someone to release infected versions of those titles to abandonware sites which exploit this vulnerability to hijack the hosts of all those who attempt to run that software in PCem. A substantial amount of havoc could be wreaked that way, because many people don't feel the need to be particularly vigilant about scanning the abandonware they've downloaded for malware, given that they know they'll only be running that software in environments they expect to be properly sandboxed. Definitely a good idea to patch this up, as the solution seems straightforward enough.

[SarahWalker]

I'm pretty sure PCem isn't the only emulator where this sort of thing is possible, and very far from the most popular one. I will fix these issues, I'm just saying that this isn't something really worth worrying about that much.

[Alegend45]

I'm pretty sure PCem isn't the only emulator where this sort of thing is possible, and very far from the most popular one. I will fix these issues, I'm just saying that this isn't something really worth worrying about that much.

Actually, the only other emulator that's had these issues is ZSNES. A Super Nintendo emulator that was written in assembly, and was all-around shit. Also, trojans.

[ppgrainbow]

I'm pretty sure PCem isn't the only emulator where this sort of thing is possible, and very far from the most popular one. I will fix these issues, I'm just saying that this isn't something really worth worrying about that much.

Actually, the only other emulator that's had these issues is ZSNES. A Super Nintendo emulator that was written in assembly, and was all-around shit. Also, trojans.

Why did the ZSNES emulator had trojans? I know for a fact that certain anti-virus software would label ZSNES as a false-positive.

[SarahWalker]

I'm pretty certain ZSNES is not the only emulator with this kind of issue.

[SarahWalker]

Revs 384/385 contain my attempted fixes for these issues.

[te_lanus]

Why did the ZSNES emulator had trojans? I know for a fact that certain anti-virus software would label ZSNES as a false-positive.

Ignore him. He's a bsnes/higan fanboy so will trash any other emu that's in competition with it.

[EluanCM]

qemu, VMWARE, VirtualBox all have had security advisories.


Off-topic: ZSNES was great for its time and constrained resources, higan is best for modern machines simply because of accuracy (even after all the NIH syndrome problems)

[Battler]

From rv385:

Code: Select all

+                        if (piix_busmaster[channel].addr < (mem_size * 1024 * 1024))
+                        {
+                                int count = 512;
+                                if ((piix_busmaster[channel].addr + count) > (mem_size * 1024 * 1024))
+                                        count = (mem_size * 1024 * 1024) - piix_busmaster[channel].addr;
+                                memcpy(&ram[piix_busmaster[channel].addr], data + transferred, count);
+                        }
                         memcpy(&ram[piix_busmaster[channel].addr], data + transferred, 512 - transferred);

That last memcpy should be removed. :p

[SarahWalker]

Fixed in rev 386.

[t9999clint]

Glad to see you fix this, I understand that security is not really a huge concern at this stage of development, but I agree with ecksemmess on this. Also it's easier to fix this stuff now then to have it come up later when it's harder to recode without breaking things.

Emulator Escapes are an issue with almost all emulators and most of the good devs patch it. PCSX2 has been fairly good at patching this.
Also Off-Topic: ZSNES was a great emulator in it's day but years of neglect has left it in a sorry state that I don't recommend for anyone. Try ZMZ with the BSNES-Accuracy libretro dll. Works great for me and I get the old ZSNES interface. Nowadays I mostly use RetroArch though. (I am also a BSNES fanboy )