Windows Kernel Writeable and Executable pages

Hello everybody!
This is my first post in this site, so please let me know if I posted in the wrong place or in wrong format. Thanks.

I am conducting a research, in which I have setup a fresh install of Windows x64 (both 8.1 and 10).

I have written a driver which walks the page tables and prints out memory information, and have noticed that there exist many writeable and executable memory ranges (PAGE_READWRITE_EXECUTE), which contradicts the idea of DEP and W^X, and really poses an inconceivable security hole (and this is in contradiction with Windows’ great work on security improvements and exploit mitigation).

Well, my question to you then, is why?

What could be so important for Microsoft’s developers to justify such irresponsible behaviour?

In addition, I have written a Volatility based script that assured my research results were correct, and have ran it on a dump I acquired using LiveKD. The link to the code is here:
https://github.com/scalys7/Virtual-Address-Space-Research

I did not add the memory dump as it was not of any significance - it was done on a clean 8.1 x64 VM, and thus should be easy to reproduce. If it is needed for some reason however, feel free to ask for it.

I would greatly appreciate any insights on this matter.
Thanks in advance, and good weekend to you all!

xxxxx@gmail.com wrote:

I am conducting a research, in which I have setup a fresh install of Windows x64 (both 8.1 and 10).

I have written a driver which walks the page tables and prints out memory information, and have noticed that there exist many writeable and executable memory ranges (PAGE_READWRITE_EXECUTE), which contradicts the idea of DEP and W^X, and really poses an inconceivable security hole (and this is in contradiction with Windows’ great work on security improvements and exploit mitigation).

Well, my question to you then, is why?

What could be so important for Microsoft’s developers to justify such irresponsible behaviour?

History. Vast number of third-party drivers were written before this
kind of thing became important. By default, ExAllocatePool returns RWX
pages, and most drivers use the default.

Now, an RWX region is not dangerous in and of itself. An RWX region in
user space can only be exploited against the owning app. An RWX region
in kernel space can only be exploited by kernel code, and kernel code is
trusted code. Once an attacker has kernel access, it’s game over.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hey Tim, thanks for your quick reply.

First, I have found kernel RWX even in .sys drivers that were written by Microsoft, and stored under the Windows directory, so this is not a third-party exclusive problem.

Second, an RWX region is one that may be used to surpass exploit mitigation techniques, such as DEP, and could be the cause for a privilege escalation attack to succeed.
Therefore, it is highly dangerous in the view of modern OS security.

You have said that this is the default generated from ExAllocatePool. Is there a possibility for examining memory addresses allocated by that function, and perhaps determine whether all allocated RWX memory was due to the invocation of this function, and then VirtualProtect them in order to remove unnecessary attributes?

One last thing, ExAllocatePool sounds to me as a dynamic memory allocator used for ongoing memory management of drivers data structures etc., and yet, all RWX I have found under Windows 10 were actually code, not data. I have VP’d them and stripped write permissions, and the OS continued to run without blue-screening on me (it did blue-screen when i stripped execute tho) This means that the origin of these pages is probably different. Care to address this issue?

Thanks!

On Nov 18, 2016, at 3:12 PM, xxxxx@gmail.com wrote:

Second, an RWX region is one that may be used to surpass exploit mitigation techniques, such as DEP, and could be the cause for a privilege escalation attack to succeed.

Not by itself, of course. That’s why it is pointless to focus so narrowly on one aspect like this. An RWX page allows an existing exploit to do more damage than it might otherwise have done, but as long as a kernel RWX page is not accessible in user-mode, it doesn’t represent any additional risk.

Therefore, it is highly dangerous in the view of modern OS security.

It is undesirable, which is why the rules changed in Windows 10. It is not “highly dangerous”.

You have said that this is the default generated from ExAllocatePool. Is there a possibility for examining memory addresses allocated by that function, and perhaps determine whether all allocated RWX memory was due to the invocation of this function, and then VirtualProtect them in order to remove unnecessary attributes?

Not in an existing system, although I suppose you could install a trap early in the system.

One last thing, ExAllocatePool sounds to me as a dynamic memory allocator used for ongoing memory management of drivers data structures etc.,

If you don’t know this, then you do not understand nearly enough about kernel programming to do the kind of investigation you are attempting.

and yet, all RWX I have found under Windows 10 were actually code, not data. I have VP’d them and stripped write permissions, and the OS continued to run without blue-screening on me (it did blue-screen when i stripped execute tho) This means that the origin of these pages is probably different. Care to address this issue?

If you have kernel addresses, then you can look in the driver list and see which drivers are involved.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

“the rules changed in Windows 10” How are they changed? there still are RWX pages in memory.
Maybe you talked about the default protection given by AllocatePool?

It is not that I am some kind of “Windoze defender”, but the above is just a classical example of FUD…

As long as userland code has no access to these pages (which is enforced by ‘Supervisor’ bit in PTE) there is no security hole whatsoever. If some KM driver is malicious…well, then all the bets are off anyway.

Anton Bassov

Yes, the real protection is possible only when a protection is performed with higher level of privileges. Kernel protection should have been implemented by a hypervisor.

Part or all of the PTE space pages has the NX bit not set. A simple “!pte nt” command is enough to show it. Although the PTE space is probably not an exploitable region, it is clearly a data only region.

Kernel protection should have been implemented by a hypervisor.

It has been doine.

Deploy Device Guard: enable virtualization-based security

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/deploy-device-guard-enable-virtualization-based-security

Thank you all for the continuous attempt at supporting Microsoft’s mistakes by claiming they are irrelevant, but you are all wrong on this matter.
Exploit mitigation techniques are not there to prevent an already loaded “malicious module/driver” from allocating new code blocks; it is there for one and only reason - to harden the exploit development procedure.

DEP for Kernel space is not necessarily there in order to prevent local privilege escalation attacks; quite the contrary actually, as Windows are quite fond of leading the way for an easy, generic exploitation procedure of such ones (such as their API provided information leaks, or the self-reference trick - which, don’t get me wrong, is a beautiful page management trick, but completely shadows all the advantages Kernel ASLR, DEP, and SMEP has provided against local privilege escalation attacks and turned them completely irrelevant. see the link here, if you want to read more about that https://labs.mwrinfosecurity.com/blog/windows-8-kernel-memory-protections-bypass/)

DEP for Kernel space under Windows is actually more of a RCE (remote code execution) mitigation, and leaving RWX pages turns it completely irrelevant - as all that is left for the security research to overcome is ASLR - once he gets a solid enough information leak, the exploit is done - he simply needs to find one of the many thousands of RWX pages, write its shellcode there and jump to it. If no RWX pages where there, he would have needed to construct some tedious ROP chain out of that information leak (and than face some anti-code-reuse mitigations as well… this topic is actually getting much more advanced nowadays)

And to top all of those disadvantages, legitimate RWX pages in kernel mode gives shelter to malicious ones, and really hardens the forensic procedure - as it is impossible to filter out thousands of pages; if there were no RWX pages in a fresh install, then the forensic researcher would be able to conduct a much more productive research on this matter as well.

So although many of you have really stubbornly insisted on making this not a big deal, it is.
And apparently wikipedia thinks alike on this matter (https://en.wikipedia.org/wiki/W^X) and so does Linux, which not a single RWX kernel page is to be found in (at least on my Ubuntu 12.04 resesarch, do not catch me off-gaurd on older kernels here).

Now, may we please consider the real question here - what are the reason for these RWX pages, and why are they needed?

I do understand that ExAllocatePool has, in the past, delivered default RWX protection which may cause some of the data-only pages to be marked as executable as well.

What D. T. has added, if I understood him correctly, is that many of the PTE entries that reference a page table, for the OSes memory management procedure, are marked (with no good reason) as executable as well and could be filtered out as well (correct me if I’m wrong please). BTW, if Windows has a self-reference PML4 selector - than I don’t see the use of mapping other entries for page-table management, as all of the paging constructs could be managed only by that neat treat, but that is going off-topic.

Then again, Windows 10 had many RWX, but all of them were for execute usage only - marking them as non-writeable left the system intact (I mean, a blue screen could have happened on some later time, but I have encountered none.) but marking them as non-executable (but writeable) handed off a blue screen (for attempting to execute a non-execute page out of ClipSP.sys)
So this still leaves an unattained issue - why are there RWX pages that contain code? This, should be the case of self-modifying code or dynamic position independent modules loading - but both of those techniques are mostly used in malicious software (or software that tries to protect its intellectual property using some packers) and should not be considered a legitimate behaviour.

Does anyone has a clue on this matter?

Thank you all for your time!

I remember of a linux kernel vulnerability that was present in the network stack for about 7 years. This vulnerability gave total remote control to the attacker.

I remember also these admin guys posting on RedHat forums about their systems being attacked. This was sad.

No one is safe out there

In just the last few weeks the “Dirty COW” Linux kernel bug was discovered, and among other things, pretty much every release of Android is exploitable.

A quick look at the current CVE score for 2016, http://www.cvedetails.com/top-50-products.php?year=2016 is not showing Windows as unusually insecure or unusually secure. Android, Debian Linux, and Ubuntu Linux were the top 3 in number of distinct vulnerabilities. If you click on a product link on that page, it gives some real interesting breakdowns about the types of vulnerabilities and the annual trends. Using the number of CVE’s is likely in imperfect measurement of security, but it is an available number based on real data. I would love to see a number like CVE’s per million machines.

I’m certain Microsoft has a good understanding of the issue of writable executable memory. I’m also sure they have a long list of things that could improve security, but since they don’t have infinite resources, they must prioritize what changes will be done and which won’t.

The OP seems to be focused on a a specific way security might be improved, but if he had the list of everything that could done and the resource constraints, would he prioritize things the same way? The OP also reports that Linux has zero write executable pages, yet the 2016 CVE score seems to show a lot of vulnerabilities in Linux flavors of OS’s, which seems to suggest the overall security improvement from not having any writeable executable memory isn’t helping as much as one would think.

I personally would want to see SIGNIFICANTLY better CVE stats for one OS over another before I would say one vendor is doing a lot better on security. I see FreeBSD only had 6 CVE’s in 2016, vs 268 for Ubuntu. I’m curious what the total number of Ubuntu vs FreeBSD systems is.

Jan

On 11/19/16, 3:45 PM, “xxxxx@lists.osr.com on behalf of xxxxx@gmail.com” wrote:

I remember of a linux kernel vulnerability that was present in the network stack for about 7 years. This vulnerability gave total remote control to the attacker.

I remember also these admin guys posting on RedHat forums about their systems being attacked. This was sad.

No one is safe out there

Second, an RWX region is one that may be used to surpass exploit mitigation techniques, such as DEP, and could be the cause for a privilege escalation attack to succeed.

…and, at the same time,

DEP for Kernel space is not necessarily there in order to prevent local privilege escalation attacks; quite the contrary actually,…

So how do you think one is supposed to understand your ideas???

As I told you already (and all the regular readers of this list know it anyway), I am one of the last people on this planet who may be suspected of any sympathy to MSFT. Furthermore, I am not saying that making all kernel memory RWX is necessarily a good idea either. The only thing that I said (and keep on saying) is that linking “executable” bit of a kernel page’s PTE to the possibility of privilege escalation attacks is just FUD - no matter what the implications of RWX kernel pages security-wise are, privilege escalation attack is none of them.

BTW, once we are at it, when it comes to security, Window is fundamentally flawed in itself, so that things like RWX page protection simply fade is comparison to its most fundamental issues.
For example, what would you say about such an essential Windows feature as Explorer trying to execute any file with.exe extension whenever you click on its corresponding icon???

Look - this system is so fundamentally insecure that it does not even disallow program execution
by default. Does it make sense to even speak about RWX protection of the kernel pages under these circumstances??? Seems to be the same thing as worrying about the security implications of an open second-floor window of a house with a missing front door, don’t you think…

Anton Bassov

It is just a matter of consistency.

The “least privilege” rule is simple: if a privilege is not required than it is not granted.

So, if a region of memory does not contain code, no page in this region should be executable.

On Nov 20, 2016, at 7:01 PM, xxxxx@gmail.com wrote:

It is just a matter of consistency.

The “least privilege” rule is simple: if a privilege is not required than it is not granted.

So, if a region of memory does not contain code, no page in this region should be executable.

You need to think in the real world. That’s a perfectly fine rule to use when you are designing an operating system kernel, but the Windows kernel was designed 28 years ago, and best practices were quite different then. Many modern practices need to be backstitched into that design, while still maintaining the backwards compatibility that is such a keystone in the Microsoft platform.

Look, it is what it is. The danger areas are being patched over time. In the meantime, you aren’t making any friends here by arguing a theoretical point.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> In the meantime, you aren’t making any friends here by arguing a theoretical point.

Well, I have always been under the impression that the very purpose of a technical NG is to discuss the technical issues, rather than “to make friends” - after all, this is what Facebook et al are for .

In fact, the very idea of setting up some “XYZ Sycophant Club” or “ABC Propaganda Department”
in a technical NG seems at least strange to me, but I do realize that most of this list’s “regulars” have a different opinion on this subject…

Anton Bassov

It is truly remarkable to me that I’ve posted a question in the most
relevant forum filled with best Windows kernel researchers out there and
the post has gone so off-topic that my question was left unanswered.

I came here to learn; discuss a problem with intelligent people and attempt
at solving it, yet this is not what happened.

I would very much like to leave the “are RWX pages a security flaw” talk
out of this post and get back to understand: why are Windows kernel modules
allocate and execute code dynamically.

Back to it, with your permission, three ground facts should be set as the
ground for later discussions:

1. Some of the RWX pages are (without real need) allocated with such
   permissions due to it being a default for the kernel allocation method -
   ExAllocatrPool.

2. Changing ALL kernel RWX pages to RW in Windows 10 caused an immediate
   blue screen, due to a (now) non-executable page being run, and the bugcheck
   identified it to belong to ClipSp.sys - a signed Windows driver, which PEs
   section are not marked as RWX.

3. Changing ALL kernel RWX pages to RX in Windows 10 did not cause a blue
   screen.

So, logically the next-in-line question should be: what is the cause for
ClipSp to dynamically allocate a code thunk?

I claim that it dynamically allocated it as it’s PE file did not specify to
load the module with RWX permissions, and it makes no sense (for me) to
change the permissions in runtime if a loadtime mechanism exists.

There fore, the next logical clame would be that this is an intentional
mechanism that this driver used in order to allocate run-time code. Then
why is it such? And why did it need the page to stay writeable?

I await your thoughts on this matter. Help me understand this better!

Good week to you all.

On Nov 21, 2016 2:50 PM, wrote:

> > In the meantime, you aren’t making any friends here by arguing a
> theoretical point.
>
> Well, I have always been under the impression that the very purpose of a
> technical NG is to discuss the technical issues, rather than “to make
> friends” - after all, this is what Facebook et al are for .
>
> In fact, the very idea of setting up some “XYZ Sycophant Club” or “ABC
> Propaganda Department”
> in a technical NG seems at least strange to me, but I do realize that most
> of this list’s “regulars” have a different opinion on this subject…
>
>
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

>So, logically the next-in-line question should be: what is the cause for
ClipSp to dynamically allocate a code thunk?

just curious, did u try analyzing the memory block? did it represent any
objects or known symbols? hooks come to mind when one talks about such
scenarios.

On Mon, Nov 21, 2016 at 1:24 PM, jc scaly wrote:

> It is truly remarkable to me that I’ve posted a question in the most
> relevant forum filled with best Windows kernel researchers out there and
> the post has gone so off-topic that my question was left unanswered.
>
> I came here to learn; discuss a problem with intelligent people and
> attempt at solving it, yet this is not what happened.
>
> I would very much like to leave the “are RWX pages a security flaw” talk
> out of this post and get back to understand: why are Windows kernel modules
> allocate and execute code dynamically.
>
> Back to it, with your permission, three ground facts should be set as the
> ground for later discussions:
>
> 1) Some of the RWX pages are (without real need) allocated with such
> permissions due to it being a default for the kernel allocation method -
> ExAllocatrPool.
>
> 2) Changing ALL kernel RWX pages to RW in Windows 10 caused an immediate
> blue screen, due to a (now) non-executable page being run, and the bugcheck
> identified it to belong to ClipSp.sys - a signed Windows driver, which PEs
> section are not marked as RWX.
>
> 3) Changing ALL kernel RWX pages to RX in Windows 10 did not cause a blue
> screen.
>
> So, logically the next-in-line question should be: what is the cause for
> ClipSp to dynamically allocate a code thunk?
>
> I claim that it dynamically allocated it as it’s PE file did not specify
> to load the module with RWX permissions, and it makes no sense (for me) to
> change the permissions in runtime if a loadtime mechanism exists.
>
> There fore, the next logical clame would be that this is an intentional
> mechanism that this driver used in order to allocate run-time code. Then
> why is it such? And why did it need the page to stay writeable?
>
> I await your thoughts on this matter. Help me understand this better!
>
> Good week to you all.
>
> On Nov 21, 2016 2:50 PM, wrote:
>
>> > In the meantime, you aren’t making any friends here by arguing a
>> theoretical point.
>>
>> Well, I have always been under the impression that the very purpose of a
>> technical NG is to discuss the technical issues, rather than “to make
>> friends” - after all, this is what Facebook et al are for .
>>
>> In fact, the very idea of setting up some “XYZ Sycophant Club” or “ABC
>> Propaganda Department”
>> in a technical NG seems at least strange to me, but I do realize that
>> most of this list’s “regulars” have a different opinion on this subject…
>>
>>
>>
>> Anton Bassov
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list online at: http:>> lists.cfm?list=ntdev>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer&gt;
>>
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
> on crash dump analysis, WDF, Windows internals and software drivers!
> Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:>

Not yet. That should be my next step.
What would you look for if you were me?

I guess I would try to disassemble it and see how much code it contains and
try understand it’s function, at least broadly.

I would also want to see if it is inside a pool allocation or inside the
.sys module or none of that.

Any more clues?

I could also make the crash dump accessible to you if you’d like to explore
it.

On Nov 22, 2016 12:05 AM, “Ami Awbadhho” wrote:

> >So, logically the next-in-line question should be: what is the cause for
> ClipSp to dynamically allocate a code thunk?
>
> just curious, did u try analyzing the memory block? did it represent any
> objects or known symbols? hooks come to mind when one talks about such
> scenarios.
>
> On Mon, Nov 21, 2016 at 1:24 PM, jc scaly wrote:
>
>> It is truly remarkable to me that I’ve posted a question in the most
>> relevant forum filled with best Windows kernel researchers out there and
>> the post has gone so off-topic that my question was left unanswered.
>>
>> I came here to learn; discuss a problem with intelligent people and
>> attempt at solving it, yet this is not what happened.
>>
>> I would very much like to leave the “are RWX pages a security flaw” talk
>> out of this post and get back to understand: why are Windows kernel modules
>> allocate and execute code dynamically.
>>
>> Back to it, with your permission, three ground facts should be set as the
>> ground for later discussions:
>>
>> 1) Some of the RWX pages are (without real need) allocated with such
>> permissions due to it being a default for the kernel allocation method -
>> ExAllocatrPool.
>>
>> 2) Changing ALL kernel RWX pages to RW in Windows 10 caused an immediate
>> blue screen, due to a (now) non-executable page being run, and the bugcheck
>> identified it to belong to ClipSp.sys - a signed Windows driver, which PEs
>> section are not marked as RWX.
>>
>> 3) Changing ALL kernel RWX pages to RX in Windows 10 did not cause a blue
>> screen.
>>
>> So, logically the next-in-line question should be: what is the cause for
>> ClipSp to dynamically allocate a code thunk?
>>
>> I claim that it dynamically allocated it as it’s PE file did not specify
>> to load the module with RWX permissions, and it makes no sense (for me) to
>> change the permissions in runtime if a loadtime mechanism exists.
>>
>> There fore, the next logical clame would be that this is an intentional
>> mechanism that this driver used in order to allocate run-time code. Then
>> why is it such? And why did it need the page to stay writeable?
>>
>> I await your thoughts on this matter. Help me understand this better!
>>
>> Good week to you all.
>>
>> On Nov 21, 2016 2:50 PM, wrote:
>>
>>> > In the meantime, you aren’t making any friends here by arguing a
>>> theoretical point.
>>>
>>> Well, I have always been under the impression that the very purpose of a
>>> technical NG is to discuss the technical issues, rather than “to make
>>> friends” - after all, this is what Facebook et al are for .
>>>
>>> In fact, the very idea of setting up some “XYZ Sycophant Club” or “ABC
>>> Propaganda Department”
>>> in a technical NG seems at least strange to me, but I do realize that
>>> most of this list’s “regulars” have a different opinion on this subject…
>>>
>>>
>>>
>>> Anton Bassov
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> Visit the list online at: http:>>> lists.cfm?list=ntdev>
>>>
>>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>>> software drivers!
>>> Details at http:
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at <
>>> http://www.osronline.com/page.cfm?name=ListServer&gt;
>>>
>> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
>> on crash dump analysis, WDF, Windows internals and software drivers!
>> Details at To unsubscribe, visit the List Server section of OSR Online
>> at
>
>
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
> on crash dump analysis, WDF, Windows internals and software drivers!
> Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:>

>What would you look for if you were me?

the possibilities are large, and I am not sufficiently qualified to any
this with precision.

I was hoping that a dps

might yield some known symbols (if thy
are published). Sometimes, if they are c++ objects, they have vtables and
such, and those would have known symbols.

in other times, they might represent callback functions inside of windows,
which might be exported/labled.

if it is pure code, then perhaps setting a break on access to it, and
seeing the call stack on when it is hit.

check for pool allocations (like you said) to make out which pool it is,
and see where else it is used.

>I would also want to see if it is inside a pool allocation or inside the
.sys module or none of that.

it wouldnt be inside a sys file would it? If so why would you need an
ExAllocatePool at all? yes if could be code kept as a resource inside of a
sys file and copied out once the allocation succeeds. in that case, you can
use a PE analyzer to see the resources in the binary in question so see if
that matches the contents of the allocated block. i would be careful
though, it is easy to keep encrypted blocks of resources, a simple xor
version of it will through you off track.

like i said, there are a lot of possibilities, and I am not expert in this.

BTW, is this a windows binary or is it a third party driver which is
winqual certified? if it is the later i wouldnt be surprised it is doing
such stuff, it is easy to fool winqual, as long as the allocation
logic/path is not part of regular work flow 9say triggered by an ioctl), it
is easy to pass whql, verifier wont complain at all. Even if verifier
complains, it is easy to bypass verifier and still get winqual passed.

if it is windows binary, then I dont know the reasons at all...

On Mon, Nov 21, 2016 at 2:18 PM, jc scaly wrote:

> Not yet. That should be my next step.
> What would you look for if you were me?
>
> I guess I would try to disassemble it and see how much code it contains
> and try understand it's function, at least broadly.
>
> I would also want to see if it is inside a pool allocation or inside the
> .sys module or none of that.
>
> Any more clues?
>
> I could also make the crash dump accessible to you if you'd like to
> explore it.
>
> On Nov 22, 2016 12:05 AM, "Ami Awbadhho" wrote:
>
>> >So, logically the next-in-line question should be: what is the cause
>> for ClipSp to dynamically allocate a code thunk?
>>
>> just curious, did u try analyzing the memory block? did it represent any
>> objects or known symbols? hooks come to mind when one talks about such
>> scenarios.
>>
>> On Mon, Nov 21, 2016 at 1:24 PM, jc scaly wrote:
>>
>>> It is truly remarkable to me that I've posted a question in the most
>>> relevant forum filled with best Windows kernel researchers out there and
>>> the post has gone so off-topic that my question was left unanswered.
>>>
>>> I came here to learn; discuss a problem with intelligent people and
>>> attempt at solving it, yet this is not what happened.
>>>
>>> I would very much like to leave the "are RWX pages a security flaw" talk
>>> out of this post and get back to understand: why are Windows kernel modules
>>> allocate and execute code dynamically.
>>>
>>> Back to it, with your permission, three ground facts should be set as
>>> the ground for later discussions:
>>>
>>> 1) Some of the RWX pages are (without real need) allocated with such
>>> permissions due to it being a default for the kernel allocation method -
>>> ExAllocatrPool.
>>>
>>> 2) Changing ALL kernel RWX pages to RW in Windows 10 caused an immediate
>>> blue screen, due to a (now) non-executable page being run, and the bugcheck
>>> identified it to belong to ClipSp.sys - a signed Windows driver, which PEs
>>> section are not marked as RWX.
>>>
>>> 3) Changing ALL kernel RWX pages to RX in Windows 10 did not cause a
>>> blue screen.
>>>
>>> So, logically the next-in-line question should be: what is the cause for
>>> ClipSp to dynamically allocate a code thunk?
>>>
>>> I claim that it dynamically allocated it as it's PE file did not specify
>>> to load the module with RWX permissions, and it makes no sense (for me) to
>>> change the permissions in runtime if a loadtime mechanism exists.
>>>
>>> There fore, the next logical clame would be that this is an intentional
>>> mechanism that this driver used in order to allocate run-time code. Then
>>> why is it such? And why did it need the page to stay writeable?
>>>
>>> I await your thoughts on this matter. Help me understand this better!
>>>
>>> Good week to you all.
>>>
>>> On Nov 21, 2016 2:50 PM, wrote:
>>>
>>>> > In the meantime, you aren't making any friends here by arguing a
>>>> theoretical point.
>>>>
>>>> Well, I have always been under the impression that the very purpose of
>>>> a technical NG is to discuss the technical issues, rather than "to make
>>>> friends" - after all, this is what Facebook et al are for .
>>>>
>>>> In fact, the very idea of setting up some "XYZ Sycophant Club" or "ABC
>>>> Propaganda Department"
>>>> in a technical NG seems at least strange to me, but I do realize that
>>>> most of this list's "regulars" have a different opinion on this subject...
>>>>
>>>>
>>>>
>>>> Anton Bassov
>>>>
>>>> ---
>>>> NTDEV is sponsored by OSR
>>>>
>>>> Visit the list online at: >>>> lists.cfm?list=ntdev>
>>>>
>>>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>>>> software drivers!
>>>> Details at
>>>>
>>>> To unsubscribe, visit the List Server section of OSR Online at <
>>>> http://www.osronline.com/page.cfm?name=ListServer>
>>>>
>>> --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY
>>> seminars on crash dump analysis, WDF, Windows internals and software
>>> drivers! Details at To unsubscribe, visit the List Server section of
>>> OSR Online at
>>
>>
>> --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
>> on crash dump analysis, WDF, Windows internals and software drivers!
>> Details at To unsubscribe, visit the List Server section of OSR Online
>> at
>
> --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
> on crash dump analysis, WDF, Windows internals and software drivers!
> Details at To unsubscribe, visit the List Server section of OSR Online at
>

Can you read points 2) and 3) of your previous message again ?