# Native Client's NTDLL patch on x86-64 Windows

DevFeed: [Native Client's NTDLL patch on x86-64 Windows](<https://devfeed.tech/articles/native-client-s-ntdll-patch-on-x86-64-windows-21563.md>)

Original publisher: [Read original article](<http://lackingrhoticity.blogspot.com/2012/09/native-clients-ntdll-patch-on-x86-64-windows.html>)

Author: Mark Seaborn (noreply@blogger.com)

Published: 2012-09-29T02:54:00Z

Content type: tutorial

Language: en

Sources: [Mark Seaborn](<https://devfeed.tech/sources/mark-seaborn.md>)

Topics: [Security](<https://devfeed.tech/topics/security.md>), [Windows](<https://devfeed.tech/topics/windows.md>), [x86](<https://devfeed.tech/topics/x86.md>), [Exception](<https://devfeed.tech/topics/exception.md>), [Kernel](<https://devfeed.tech/topics/kernel.md>), [Chrome](<https://devfeed.tech/topics/chrome.md>), [Processes](<https://devfeed.tech/topics/processes.md>), [POSIX](<https://devfeed.tech/topics/posix.md>), [Unix](<https://devfeed.tech/topics/unix.md>)

Tags: [bug](<https://devfeed.tech/tags/bug.md>), [chrome](<https://devfeed.tech/tags/chrome.md>), [code](<https://devfeed.tech/tags/code.md>), [exception](<https://devfeed.tech/tags/exception.md>), [kernel](<https://devfeed.tech/tags/kernel.md>), [native-client](<https://devfeed.tech/tags/native-client.md>), [posix](<https://devfeed.tech/tags/posix.md>), [process](<https://devfeed.tech/tags/process.md>), [security](<https://devfeed.tech/tags/security.md>), [unix](<https://devfeed.tech/tags/unix.md>), [windows](<https://devfeed.tech/tags/windows.md>), [x86-64](<https://devfeed.tech/tags/x86-64.md>)

## AI overview

This technical article explains a security hole in Native Client on 64-bit Windows that could allow escape from the Native Client sandbox. It describes how differences between Windows vectored exception handling and Unix signal handling created the problem, and notes that Native Client used a process-local in-memory patch to NTDLL to prevent it.

## Source excerpt

Last year, I found a security hole in Native Client on 64-bit Windows that could be used to escape from the Native Client sandbox. Fortunately I found the hole before Native Client was enabled by default in Chrome. I recently wrote up the document below to explain the bug and how we fixed it. Native Client currently relies on a small, process-local, in-memory patch to NTDLL on 64-bit versions of Windows in order to prevent a problem that would create a hole in Native Client's x86-64 sandbox. The problem The problem arises because Windows does not have an equivalent of Unix's sigaltstack() system call. On Unix, a POSIX signal handler may be registered using signal() or sigaction(). When a process faults (e.g. as a result of a memory access error or an illegal instruction), the kernel passes control to the signal handler that is registered for the process. Normally, the signal handler is run on the stack of the thread that faulted. However, if an "alternate signal stack" has been registered using sigaltstack(), the signal handler will run on that stack instead. On Windows, "vectored exception handlers" are similar to Unix signal handlers, except that a vectored exception handler always gets run on the thread's current stack. This might have been OK, except that Windows has a different division of responsibility between kernel and userland compared with Unix. Windows does more in userland, and this creates problems for NaCl. On Unix, sigaction() is a syscall that user code calls that records a user-code signal handler function in a kernel data structure. If no signal handler is registered by user code, then when a fault occurs in a process, the kernel never passes control back to userland code in that process. On Windows, AddVectoredExceptionHandler() is provided in userland by a DLL rather than being provided by the kernel. AddVectoredExceptionHandler() adds the handler function to a list in userland memory. When a fault occurs in the process, the Windows kernel passe