On 27 Jul 2015 at 18:03, Gavin Lambert wrote:
On 23/07/2015 13:11, Niall Douglas wrote:
On 22 Jul 2015 at 13:35, Glen Fernandes wrote:
1. Use of documented kernel APIs: I'm torn here; on one hand, I don't condemn use of them and I would agree with Asbjørn that it isn't a show stopper. Yet you have a case of an actual show-stopper (crash) in AFIO because of the use of them.[1]
The show stopper crash is due to how ASIO implements its IOCP reactor which just happens to collide with the WOW64 bug. If I could modify the ASIO source code to special case this it's fixed. This is why Microsoft marked it as wonfix because even though it's a bug in their code, it is really super easy to work around if you modify your IOCP reactor.
Out of curiosity (and because I have my own non-ASIO IOCP reactor in a WOW64 process and I'd like to know if it's potentially similarly vulnerable), is there more detail on the bug you encountered or what triggers it?
The bug is in the WOW64 wrapper of NtQueryDirectoryFile, so unless you are using that API you will be unaffected. The WOW64 wrapper for NtQueryDirectoryFile uses the wrong alignment when repacking the ApcContext and IoStatusBlock parameters. It should 8 byte align them, instead it 4 byte aligns them. This causes the ApcContext to randomly be output by IOCP when it meant to output IoStatusBlock. One apparent workaround is to supply the same value for both parameters on x86, but this is rejected (correctly) as invalid parameters on a x86 kernel. It also causes rare memory corruption on WOW64 :( As I mentioned earlier, the simple workaround is don't use the status block returned by IOCP if awaiting a NtQueryDirectoryFile operation. Everything else works beautifully. Note that x86 on x86 kernel and x64 on x64 kernels are totally unaffected and IOCP works correctly. The bug is only in the WOW64 thunk wrapper. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/