W^X policy violation affects Windows drivers compiled in VS 2013 and previous
codeinsecurity.wordpress.com
W^X policy violation affects Windows drivers compiled in VS 2013 and previous
1–10 of 30 posts
Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous
#2From 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...
Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous
#3At 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.
Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous
#4ugh.
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.
Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous
#5At 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?
Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous
#6ugh. 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…
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.
Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous
#7At 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.
[deleted]
Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous
#8At 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.
Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous
#9At 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.
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.
Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous
#10At 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.
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,…
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.