Strangely even if you try to set a DACL on the section object the kernel will return an error, there is no actual way to secure these types of objects other than by setting a name. I can understand the reason why it works this way, unnamed objects are not supposed to be trivially shareable so why go to the expense of performing a security check unnecessarily.
Symboliclinker os 10.9.5 windows#
This bug is the result of a corner case in the Windows OS. While not the default you can add the Object Address column to the table, you can then use this information when looking at unnamed sections to determine if any are shared with a more privileged process, and whether any sections are only granted FILE_MAP_READ permissions in the low-privileged process. A quick way to check on this is to use a tool such as Process Hacker or Process Explorer and look at the handle table.
Remember that even though each process has different handles, each refers to the same section object in the kernel. One final note on how you might find similar issues in other applications. Of course a bug like this might be even more important when site-isolation is enabled as a default in Chrome. While this is not directly a sandbox breakout it could be used as part of a chain as demonstrated in previous attacks against the Chrome sandbox. From a compromised renderer you can call DuplicateHandle to elevate the privileges of the section handle to re-gain write access, then modify the shared memory to execute arbitrary Javascript in any rendered page, including more-privileged chrome:// pages.
0 kommentar(er)
