I had this demonstrated and explained to me recently by Amanieu: put the following in segfault.asm:
code
CNSTP4 805306368
JUMPV
and then make it into a QVM:
$ q3asm -o ui.qvm segfault.asm
Wrap it in a pk3 and dump it in baseq3 (named such that it will be loaded as a priority). The result:
Loading vm file vm/ui.qvm...
...which has vmMagic VM_MAGIC_VER2
Loading 0 jump table targets
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7b166d0 (LWP 12292)]
0x0811c68e in VM_Compile (vm=0x9a0c3c0, header=0xb619af4c)
at src/qcommon/vm_x86.c:557
557 jused[lastConst] = 1;
(gdb) bt
#0 0x0811c68e in VM_Compile (vm=0x9a0c3c0, header=0xb619af4c)
at src/qcommon/vm_x86.c:557
#1 0x080b0e80 in VM_Create (module=0x8123846 "ui",
systemCalls=0x8064177 <CL_UISystemCalls>, interpret=VMI_COMPILED)
at src/qcommon/vm.c:592
#2 0x080654c3 in CL_InitUI () at src/client/cl_ui.c:1029
#3 0x0805d135 in CL_StartHunkUsers (rendererOnly=qfalse)
at src/client/cl_main.c:2758
#4 0x0807a442 in Com_Init (commandLine=0xbfe4dd74 "")
at src/qcommon/common.c:2529
#5 0x080f7c81 in main (argc=8, argv=0xbfe4e244) at src/sys/sys_main.c:548
(gdb) print lastConst
$1 = 805306368
This looks like just a simple bounds check missing, but I'm out of my depth in the VM compiler.
Of course there's a limited amount you can do to stop arbitrary VMs from crashing the client, but this being an uninitialised memory access it's almost certainly worth closing before someone makes a security exploit of it.
Credit for finding this pretty much solely goes to Amanieu, I just did the subsequent writeup
The x86_64 vm compiler is also vulnerable to this. I haven't checked the ppc and sparc compilers, but they could be too. Basicly check that all jump and call targets are within the instructionCount. (and negative values for call, for syscalls)
(In reply to comment #4)
> Furthermore, the opStack still needs to be checked. This code will crash
> ioquake3 as well:
>
> code
> CNSTP4 805306368
> CNSTP4 0
> JUMPV
Fixed in vm_x86_64.c
PPC does not have a problem with this kind of attack because it just keeps opstack values in registers and never writes them to memory.
Created attachment 2717[details]
opStack protection for x86 VM
This patch adds opStack protection to x86 QVM. As the ebx register is the only register that can be used freely and allows access to the lowest byte for add/sub I had to move registers around. Furthermore, all opStack operations must be changed to scaled indexing. This means that this patch is very extensive. However, the performance penalty should be very low. Please test this.
I had this demonstrated and explained to me recently by Amanieu: put the following in segfault.asm: code CNSTP4 805306368 JUMPV and then make it into a QVM: $ q3asm -o ui.qvm segfault.asm Wrap it in a pk3 and dump it in baseq3 (named such that it will be loaded as a priority). The result: Loading vm file vm/ui.qvm... ...which has vmMagic VM_MAGIC_VER2 Loading 0 jump table targets Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7b166d0 (LWP 12292)] 0x0811c68e in VM_Compile (vm=0x9a0c3c0, header=0xb619af4c) at src/qcommon/vm_x86.c:557 557 jused[lastConst] = 1; (gdb) bt #0 0x0811c68e in VM_Compile (vm=0x9a0c3c0, header=0xb619af4c) at src/qcommon/vm_x86.c:557 #1 0x080b0e80 in VM_Create (module=0x8123846 "ui", systemCalls=0x8064177 <CL_UISystemCalls>, interpret=VMI_COMPILED) at src/qcommon/vm.c:592 #2 0x080654c3 in CL_InitUI () at src/client/cl_ui.c:1029 #3 0x0805d135 in CL_StartHunkUsers (rendererOnly=qfalse) at src/client/cl_main.c:2758 #4 0x0807a442 in Com_Init (commandLine=0xbfe4dd74 "") at src/qcommon/common.c:2529 #5 0x080f7c81 in main (argc=8, argv=0xbfe4e244) at src/sys/sys_main.c:548 (gdb) print lastConst $1 = 805306368 This looks like just a simple bounds check missing, but I'm out of my depth in the VM compiler. Of course there's a limited amount you can do to stop arbitrary VMs from crashing the client, but this being an uninitialised memory access it's almost certainly worth closing before someone makes a security exploit of it. Credit for finding this pretty much solely goes to Amanieu, I just did the subsequent writeupCreated attachment 2717 [details] opStack protection for x86 VM This patch adds opStack protection to x86 QVM. As the ebx register is the only register that can be used freely and allows access to the lowest byte for add/sub I had to move registers around. Furthermore, all opStack operations must be changed to scaled indexing. This means that this patch is very extensive. However, the performance penalty should be very low. Please test this.