CVE-2020-17087 VS CIS Containment?

“The Chrome zero-day was used to allow attackers to run malicious code inside Chrome, while the Windows zero-day was the second part of this attack, allowing threat actors to escape Chrome’s secure container and run code on the underlying operating system — in what security experts call a sandbox escape.”

How does CIS Containment is affected by this Windows CVE-2020-17087? Assuming Default ‘Fully Virtualized’ level and also Cruelsister’s suggested ‘Run Virtually > Restricted’ level?

PS: For some odd reason I can’t create a New Topic in Defense + / Sandbox Help section.

this not affect CIS, in case code chromium the hack need have acess the machine;
“fully virtuallizes” not allow acess to system :-TU

sorry my english!

In case of the Chrome vulnerability I believe it will not affect CIS, however speaking about the Windows CVE-2020-17087 itself which is a Buffer Overflow vulnerability in a Kernel-mode Windows Driver, can it bypass CIS Protection layers since the vulnerability is located at the Kernel level (also the same level as CIS Protection layers)?

Yes any vulnerability in kernel-mode will affect any and all security mechanisms running both in user-mode and kernel-mode. For example, video game cheat developers load and exploit a vulnerable kernel driver to perform Direct Kernel Object Manipulation (DKOM) to load and hide their cheat from anti-cheat applications, something that Windows own security architecture prevents in the first place.

Now regarding this particular CVE and comdo sandbox, fully virutallized does not prevent opening handles to device objects, except for \Device\PhysicalMemory and \Device\Harddisk*. However, I’m not sure what would happen in regards to opening a handle with restriction level set to limited or higher, it may or may not be blocked, but I think \Device\CNG would have to be added to protected files for the restriction to be applied to it.

PS: For some odd reason I can't create a New Topic in Defense + / Sandbox Help section.
Checking on this.

Thank you Futuretech for the explanation. Maybe I should create a Wish request for them to add “\Device\CND” to Protected Objects and point to this particular CVE…

It’s CNG*, typo on my part, but like I said even if you do add it, I don’t know if it will work even with using restriction levels, something I never tested before. It shouldn’t be blocked under fully virutalized sandbox setting, as it only blocks access to specific device objects. Also you should be good to post new topics for now.

Oh ok no problem, and thank you for helping with the issue in posting Topics as well.
Maybe some skilled person (Cruelsister maybe? ;D) will volunteer to test CIS against this particular CVE and wether adding “\Device\CNG” is enough to solve the problem? I would be willing to test myself but my tight schedule might not allow me to do it.