This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.

Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com
/chromium/src/+/master/docs/security/faq.md

Please see the following link for instructions on filing security bugs:
https://www.chromium.org/Home/chromium-security/reporting-security-bugs

NOTE: Security bugs are normally made public once a fix has been widely
deployed.

VULNERABILITY DETAILS
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>.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available, the bug report will become
visible to the public.

VERSION
Chrome Version: [66.0.3359.117] + [stable]
Operating System: [linux]

REPRODUCTION CASE
Please include a demonstration of the security bug, such as an attached
HTML or binary file that reproduces the bug when loaded in Chrome. PLEASE
make the file as small as possible and remove any content not required to
demonstrate the bug.

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: GPU process
Crash State: d0573792cf03341d
Client ID (if relevant): [see link above]

 

Deleted: server.py 901 bytes

server.py 901 bytes View Download

Deleted: webgl.html 636 bytes

webgl.html 636 bytes View Download

Deleted: index.html 272 bytes

index.html 272 bytes View Download