locked
How to set PAGE_NOACCESS state in a WindowsStore Apps ?

    Question

  • I've read the answer:
    http://social.msdn.microsoft.com/Forums/de-DE/aad27744-f09f-44b3-a73d-cbcee93f4805/is-it-possible-to-allocate-executable-memory-are-there-alternatives-for-virtualalloc-and-friends?forum=winappswithnativecode

    and of course its clear, that setting pages to EXECUTABLE state
    can cause a serious security issue.

    But in desktop apps VirtualProtect also can change the state of read/write aceess to
    private pages. That is a very helpful tool for buffer overrun prevention.

    So if you (on a 4KB page memory) require a buffer of for 
    example 5 pages (=5000h bytes), then simply a buffer of 6 pages
    could be allocated: first 5 pages for the buffer data and one another page
    with PAGE_NOACCESS to prevent a buffer overrun. (Any overrun would lead into
    an exception, which can be easily handled. And so the faulty instruction is
    easy to find).

    VirtualProtect is required to set that PAGE_NOACCESS state. Without that,
    a buffer overrun not always leads to an exception. It even can destroy other
    data, which is located AFTER the last page. 

    Is there something similar in WindowsStore Apps API, where such a PAGE_NOACCESS
    state can be set?




    Monday, June 16, 2014 6:24 PM

Answers

  • Hi - I understand your reasoning for wanting this API (security), but Windows Store apps are already running in a sandboxed environment. Are you finding that there's a security hole in the environment that causes you to want to set this state?

    As Larry says in the previous post, those functions are not available in Windows Store apps.


    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Tuesday, June 17, 2014 12:50 PM
    Moderator

All replies

  • Hi - I understand your reasoning for wanting this API (security), but Windows Store apps are already running in a sandboxed environment. Are you finding that there's a security hole in the environment that causes you to want to set this state?

    As Larry says in the previous post, those functions are not available in Windows Store apps.


    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Tuesday, June 17, 2014 12:50 PM
    Moderator
  • Hi, thanks for your answer.

    Its good, that they run in a sandbox environment. But that kind of security was not meant.

    Its more an app internal security:

    If you allocate bigger memory blocks (in a multiple of system's page size) through HeapAlloc (which is available on WindowsStoreApps),  the use of VirtualProtect is no problem (on desktop apps).

     (When you allocate small memory blocks through HeapAlloc , multiple memory blocks can exist on a single page. So then already msdn docs say, that VirtualProtect is not recommend to use. That I agree.)

    But already using many blocks within a page can cause serious problems, when buffer overruns destroy data of another block within same page. Cause of that, the use of full page aligned memory blocks is safer. That is what VirtualAlloc provides.

    On such blocks then any buffer overrun would only affect the NEXT page (and that in desktop apps can be protected by VirtualProtect using PAGE_NOACCESS ). Without that protection, your own data, which was allocated in a direct following page, can be destroyed, if a buffer overrun occurs. Its also very hard to find the real error in such cases, cause the app seems to run without error for a while, but its data is already damaged. If important data was located there, for example file handles or offsets, calls to CloseHandle can even disturb other application's UI elements. (see PICT0002disturbed.jpg on http://connect.microsoft.com/VisualStudio/feedback/details/823175/getprocaddress-crashes-on-invalid-argument-instead-of-returning-zero) cause unfortunalety some OS functions (as GetProcAddress crash on wrong parameter inputs)

    So the internal app security of other parts can be affected, cause through buffer overruns then other private data blocks can be damaged, which can lead to problems.

    I think its an app internal security problem, which could lead to problems with app reliability.


    ------------------------------

    sometimes its also helpful to be able to change the access state from read/write to readonly and back: example: if you define a var in .const section, its much better protected as in .data section.  If you for example only need to initialize that var one time on start of app (and if its not always the same value), so for eample a global main window handle,  calling VirtualProtect can enable write access for that page on app start, change the value to desired value and the again change state back to readonly. for the full time of runni8ng the app, then the window handle is write protected and so any attempts of overwriting it (by undefined behavior/buffer overruns,..) is avoided.

    so simply an API function "HeapProtect" noaccess/readwrite/readonly for all allocated datablocks, which are sized in a multiple of system's page size, (for current process only) would be great.

    Tuesday, June 17, 2014 2:04 PM