W^X policy violation affects Windows drivers compiled in VS 2013 and previous | Hacker News Reader

W^X policy violation affects Windows drivers compiled in VS 2013 and previous

codeinsecurity.wordpress.com

106 pointsmmastrac26 comments

ugh.

At the root, this issue is probably an oversight. Understanding why things are discardable and pageable is interesting though.

Memory is pageable because live memory is precious. Your multi-tasking OS that supports paging can dynamically load and unload pages of memory to a backing store, say, disk. This means that if the sum of the memory being used by all tasks is greater than the physical memory available on your computer, your computer can still work.

Ah, but let's consider a few facts. Data is stored in memory, but so is code. Can all the code in your system be paged to disk? There is some code in your kernel called the page fault handler. This code is responsible for identifying when the region of memory being accessed is not present, and can talk to the backing store to bring that memory back in. What happens if the page fault handler is, itself, paged out? What happens when the page fault handler needs to run?

So, now some code needs to be pinned into memory. It can not be paged out, or the system might stop working. Transitively, this property affects other pieces of code on the system following control and data dependencies between that code and the page fault handler. This can include device drivers that third parties write.

Some kernels say, all kernel memory is nonpageable, deal with it. Not Windows. In an attempt to make more memory available, it allows device drivers to mark code and data in the driver as both INIT and PAGEABLE. There are two contracts that you, the driver author, must live under when you do this. You must agree not to access anything in INIT after your DriverEntry (main) has returned, and, you must not attempt to run code in a PAGEABLE segment when the system cannot take a page fault. Many kernel mode components can easily fit code into these two contracts, so some good citizens do this.

The whole DISCARDABLE thing was a relic of pre-NT versions of Windows, back when people were just beginning to realize that 640K was not, in fact, enough for everybody. I'm surprised the kernel pays any attention to it at all anymore. There's not much upside to paging memory associated with drivers in and out. Certainly not worth the additional attack surface that you get by making things more complicated than necessary.

Pre-NT? Are you sure? My understanding of history is that the PE file format was part of NT 3. I would have thought that earlier systems kept as much paged as possible, but maybe that's wrong.

Maybe it's not worth it any more. My phone has 8GB of memory. I do remember a time when you could boot Windows XP on a system with 64MB of RAM when you needed special configuration / custom kernels to boot Linux on such a system. You would think that this was because of the pile of small choices made to relieve memory pressure...

In userland, the DISCARDABLE and MOVABLE flags date back at least to Windows 3. Not sure about the kernel.

That would have been a different file format though, right?

Yes, but the point is that movable/discardable flags are an old-school hack that probably shouldn't have made it into modern binary file formats to begin with.

Memory pressure didn't go away with NT 3.1 though... probably in Windows Vista it could have gone away...

> I do remember a time when you could boot Windows XP on a system with 64MB of RAM when you needed special configuration / custom kernels to boot Linux on such a system.

No, you're misremembering. A Linux kernel has never needed anywhere near that much RAM to boot. The first machine I used Linux on had 8MB RAM and that was considered plenty at the time. I do remember KDE being pretty slow on a machine with 64MB...maybe you're thinking of desktop environments.

Or fat initrds

Yep. The smallest I've seen IIRC was a 386 with 4MB running X11 back around 1998. Took a good time to boot and start X11, but it did work.

My first X86 machine running Linux was a 386DX/33 with 4MB of RAM. It booted the Linux 0.96 kernel (IIRC) just fine and I also used X on that machine. As far as I remember, I did have 16MB swap as well to make things actually usable, but the kernel itself would boot just fine with just the 4MB RAM. If memory serves me right, it was actually possible to get the kernel to boot with as little as 2MB in those days, but that was the limit.

I remember a custom kernel compile on this machine took a little over 24 hours. :-/

From the reddit netsec discussion, it seems like this is a mildly interesting compiler quirk with no obvious real-life consequence, as the steps required for exploitation could be better (and with less effort) applied to directly attack kernel data structures instead...?

https://www.reddit.com/r/netsec/comments/3jlipz/wx_policy_vi...

W^X policy??

https://en.wikipedia.org/wiki/W%5EX

Also known as DEP under Windows: https://en.wikipedia.org/wiki/Data_Execution_Prevention

Or more general: NX: https://en.wikipedia.org/wiki/NX_bit

There should probably be a definitive name for this.

Thank you.

[edit] I understand HN prefers to use the original headline when linking and the source has no need to explain the term but I do so enjoy learning new things from HN.

Writable exclusive OR eXecutable policy, applied to memory pages it makes memory safety bugs a lot harder to exploit, as an attacker can't simply load an executable payload (typically, shellcode) in the address space of the exploited program and jump to it...

Just to emphasize (be picky): Logically it is exclusive or (XOR), not inclusive (OR). That is either write or execute, but not both.

Too be really picky, logically it's NAND. Not writable and not executable is valid. :)

> as an attacker can't simply load an executable payload (typically, shellcode) in the address space of the exploited program and jump to it...

Very interesting read on how this works in practice: https://www.corelan.be/index.php/2010/06/16/exploit-writing-...

Is there a flag to mitigate this at link time?

At least you "felt fuzzy" doing free work for a multi billion dollar company. They didn't even give him proper responses or acknowledge the fix.

I'm not sure I understand the logic here, so just because microsoft is a multi billion dollar company people shouldn't be inspecting their code to find security holes?

would you say the same thing if the subject was ubuntu/linux?

I just think it is naive to feel good for helping Microsoft, when judging by the way they replied, don't care that much at all, and are profiting from your free work.

It's fine to feel good for helping fellow users or yourself though.

Someone always tries to make this comment when a security vulnerability comes up, and it's just as silly every time. If Microsoft asked him to investigate this, then paid him nothing then sure, you can call it "free work". But really, it's just that the author was interested in this one particular thing and decided to investigate it as a hobby and sent his findings in. The company shouldn't be expected to pay for it, or even care about it because they never requested it, and calling it "free work" or trying to imply that a company is in the wrong for not paying him because they're a "multi billion dollar company" is asinine.

I didn't say Microsoft is in the wrong. I think he is naive if he thinks they care or even really appreciate it though.

They didn't even give him proper responses.

I suspect the fuzzy feeling was more that his discovery seemed to have caused Windows to be changed. Who wouldn't feel some kind of emotion at that?

Reply on news.ycombinator.com