The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
High
PR
The attacker requires privileges that provide significant (e.g., administrative) control over the vulnerable system allowing full access to the vulnerable system’s settings and files.
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: Google Chrome Swiftshader Texture Allocation Integer Overflow
There's a remotely triggerable memory corruption issue in SwiftShader that's reachable from WebGL, resulting from an integer overflow issue.
In the GPU process there is validation on the sizes passed to texture creation functions to ensure that they shouldn't cause overflow. However, in the Swiftshader code there is a separate rounding up of render-target sizes to the next even size, which allows bypassing this validation.
(Note the additional +4, which is also (unexpected by the chrome gpu process) unsafe but in practice shouldn't cause an issue.)
https://cs.chromium.org/chromium/src/third_party/swiftshader/src/Renderer/Surface.cpp?l=3261
void *Surface::allocateBuffer(int width, int height, int depth, int border, int samples, Format format)
{
// Render targets require 2x2 quads
int width2 = (width + 1) & ~1;
int height2 = (height + 1) & ~1;
// FIXME: Unpacking byte4 to short4 in the sampler currently involves reading 8 bytes,
// and stencil operations also read 8 bytes per four 8-bit stencil values,
// so we have to allocate 4 extra bytes to avoid buffer overruns.
return allocate(size(width2, height2, depth, border, samples, format) + 4);
}
Size calculation takes place here:
https://cs.chromium.org/chromium/src/third_party/swiftshader/src/Renderer/Surface.cpp?l=2646
unsigned int Surface::size(int width, int height, int depth, int border, int samples, Format format)
{
width += 2 * border;
height += 2 * border;
// Dimensions rounded up to multiples of 4, used for compressed formats
int width4 = align(width, 4);
int height4 = align(height, 4);
switch(format)
{
// ... snip ...
default:
return bytes(format) * width * height * depth * samples;
}
}
The maximum value for bytes(format) is 16, with something like GL_RGBA32F, and samples is 1.
We can't cause this value to overflow if we have to provide the texture contents, since allocating a sufficiently large Float32Array will be larger than the renderer memory limits, but we can use glTexStorage3D to trigger the overflow.
We need to meet the following conditions:
1 <= width <= 0x2000
1 <= height <= 0x2000
1 <= depth <= 0x2000
16 * width * height * depth <= 0x100000000ull;
If these conditions are met, and we can also produce values such that:
16 * ((width + 1) & ~1) * ((height + 1) & ~1) * depth >= 0x100000000ull;
Then we'll get an integer overflow during size calculation, and end up with a small buffer for a large texture.
If we use the path glTexSubImage3D to initialize the texture, this will zero out (Chrome's expected size) of the texture (~4gig) in the (260 byte) allocation, which may make exploitation awkward, but especially in a context like the GPU process with multiple threads interacting, it's likely possible to exploit this issue. There may also be alternative paths which avoid the wild memset, but I'm reporting now so that work on a fix can start.
Note, it is possible for an attacker to force use of the Swiftshader backend for WebGL rendering by simply crashing the GPU process a few times (for a platform dependent value of 'few'). The attached PoC uses 4 domains and cycles between them to trigger 3 (hardware accelerated) GPU process crashes due to OOM (on my workstation, at least) which will then be followed by the (software accelerated) GPU process hitting this bug. Mileage may vary with different GPU drivers/OpenGL implementations.
Crashes with the PoC will be fairly random - whatever you'd expect for zeroing out your entire heap...
Thread 1 "chrome" received signal SIGSEGV, Segmentation fault.
0x00007fe697e94551 in egl::Image::loadImageData(egl::Context*, int, int, int, int, int, int, unsigned int, unsigned int, egl::Image::UnpackInfo const&, void const*) ()
from src/out/non-asan/swiftshader/libGLESv2.so
(gdb) bt
#0 0x00007fe697e94551 in egl::Image::loadImageData(egl::Context*, int, int, int, int, int, int, unsigned int, unsigned int, egl::Image::UnpackInfo const&, void const*) ()
at src/out/non-asan/swiftshader/libGLESv2.so
#1 0x0000000000000000 in ()
(gdb) x/10i $pc
=> 0x7fe697e94551 <_ZN3egl5Image13loadImageDataEPNS_7ContextEiiiiiijjRKNS0_10UnpackInfoEPKv+9911>: jmpq *0x28(%rax)
0x7fe697e94554 <_ZN12_GLOBAL__N_113LoadImageDataILNS_8DataTypeE1EEEviiiiiiiiiiPKvPv>: push %rbp
0x7fe697e94555 <_ZN12_GLOBAL__N_113LoadImageDataILNS_8DataTypeE1EEEviiiiiiiiiiPKvPv+1>: push %r15
0x7fe697e94557 <_ZN12_GLOBAL__N_113LoadImageDataILNS_8DataTypeE1EEEviiiiiiiiiiPKvPv+3>: push %r14
0x7fe697e94559 <_ZN12_GLOBAL__N_113LoadImageDataILNS_8DataTypeE1EEEviiiiiiiiiiPKvPv+5>: push %r13
0x7fe697e9455b <_ZN12_GLOBAL__N_113LoadImageDataILNS_8DataTypeE1EEEviiiiiiiiiiPKvPv+7>: push %r12
0x7fe697e9455d <_ZN12_GLOBAL__N_113LoadImageDataILNS_8DataTypeE1EEEviiiiiiiiiiPKvPv+9>: push %rbx
0x7fe697e9455e <_ZN12_GLOBAL__N_113LoadImageDataILNS_8DataTypeE1EEEviiiiiiiiiiPKvPv+10>: sub $0x48,%rsp
0x7fe697e94562 <_ZN12_GLOBAL__N_113LoadImageDataILNS_8DataTypeE1EEEviiiiiiiiiiPKvPv+14>: mov %r8d,0xc(%rsp)
0x7fe697e94567 <_ZN12_GLOBAL__N_113LoadImageDataILNS_8DataTypeE1EEEviiiiiiiiiiPKvPv+19>: test %r9d,%r9d
(gdb) i r
rax 0x0 0
rbx 0x8814 34836
rcx 0x1 1
rdx 0x10 16
rsi 0x30b20f90860 3346332715104
rdi 0x30b2081f500 3346324911360
rbp 0x1406 0x1406
rsp 0x7ffdafd862c8 0x7ffdafd862c8
r8 0xfffffffffffffff0 -16
r9 0x1 1
r10 0x75 117
r11 0x30b2088ee90 3346325368464
r12 0xc2 194
r13 0x2a3 675
r14 0x8814 34836
r15 0x0 0
rip 0x7fe697e94551 0x7fe697e94551 <egl::Image::loadImageData(egl::Context*, int, int, int, int, int, int, unsigned int, unsigned int, egl::Image::UnpackInfo const&, void const*)+9911>
eflags 0x10202 [ IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb)
See crash-id d0573792cf03341d for a crash on the current stable branch.
To test using the attached PoC, either run chrome with --disable-gpu to force software rendering, or create 4 aliases to localhost evil0.com, evil1.com, evil2.com and evil3.com in your /etc/hosts file and run ./server.py <port_number> and point your browser to evil0.com:<port_number>.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/45059.zip
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum