none
How can I prevent a user from creating a memory dump? RRS feed

  • Question

  • Hi experts,

    how can I prevent a user from creating a memory dump of a process?

    Systems: Windows 10 and Windows Server

    Thanks a lot and have a good day,

    Ulrich

    Thursday, September 12, 2019 11:30 AM

Answers

  • Hello Ulrich Schumacher,

    There seems no way to prevent a user from creating a memory dump especially when the user is the owner or administrator of the machine.

    Dump file is useful for troubleshooting when the application runs into problem. So why do you want to prevent to create dump file? If you can show your concern maybe we can find a workaround.

    Best regards,

    Rita


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, September 13, 2019 2:12 AM
  • Running the code in an enclave (see the CreateEnclave function) would prevent it and its data from being dumped. However, it looks very difficult to implement, and you would still need a network server to verify the attestation report and securely load the code to the enclave.

    Monday, September 16, 2019 9:26 PM
  • I think I would move any process in my app that needs to be secure to a web service.   This way my app can not be decompiled or find any thing in a memory dump the user should not have access to.  There is also a class called SecureStrings which can help keep things like passwords a little safer from memory dumps

    https://docs.microsoft.com/en-us/dotnet/api/system.security.securestring?view=netframework-4.8 

    Sunday, September 15, 2019 10:12 AM
  • The thing to remember here is that users have full control over what they own. The other thing to remember is that while modern applications have some level of role based security, desktop applications purely have token based security. This is based upon the user's user name or the group that the user belongs to. This means that a process ran by a user will always give that user full access.

    There is no specific right for create a memory dump, since technically all you would need is VM read access right for a process to create a memory dump, and why would you ever deny a user the right to read the process address space for one of their processes.

    I would say that any flaw here is not in allowing the user to create a memory dump, but it is placing it in the address space of a process for a user which you feel they shouldn't be able to access. You disallowing memory dumps doesn't disallow injecting a DLL and scanning through the process address space or doing some other code injection.

    The only way you can do this securely is by placing the data which you feel is sensitive in a completely separate process, preferably one with administrative rights (like a service) and use IPC to communicate, or as a web service like Ken Tucker suggested.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Sunday, September 15, 2019 12:23 PM

All replies

  • Hello Ulrich Schumacher,

    There seems no way to prevent a user from creating a memory dump especially when the user is the owner or administrator of the machine.

    Dump file is useful for troubleshooting when the application runs into problem. So why do you want to prevent to create dump file? If you can show your concern maybe we can find a workaround.

    Best regards,

    Rita


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, September 13, 2019 2:12 AM
  • Hi Rita,

    thank you for supporting.

    It is all about security. A memory dump is a security risk as users can search the memory for critical data. We have a .NET rich client application and looking for a way to prevent users (no administrators) from creating a memory dump by simply using the task manager. It would be ok if the system is able to do this because of troubleshooting issues, but why should a user need to do this? Maybe there is a way by using group policies.

    Best regards and have a good day,

    Ulrich

    Sunday, September 15, 2019 8:59 AM
  • I think I would move any process in my app that needs to be secure to a web service.   This way my app can not be decompiled or find any thing in a memory dump the user should not have access to.  There is also a class called SecureStrings which can help keep things like passwords a little safer from memory dumps

    https://docs.microsoft.com/en-us/dotnet/api/system.security.securestring?view=netframework-4.8 

    Sunday, September 15, 2019 10:12 AM
  • The thing to remember here is that users have full control over what they own. The other thing to remember is that while modern applications have some level of role based security, desktop applications purely have token based security. This is based upon the user's user name or the group that the user belongs to. This means that a process ran by a user will always give that user full access.

    There is no specific right for create a memory dump, since technically all you would need is VM read access right for a process to create a memory dump, and why would you ever deny a user the right to read the process address space for one of their processes.

    I would say that any flaw here is not in allowing the user to create a memory dump, but it is placing it in the address space of a process for a user which you feel they shouldn't be able to access. You disallowing memory dumps doesn't disallow injecting a DLL and scanning through the process address space or doing some other code injection.

    The only way you can do this securely is by placing the data which you feel is sensitive in a completely separate process, preferably one with administrative rights (like a service) and use IPC to communicate, or as a web service like Ken Tucker suggested.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Sunday, September 15, 2019 12:23 PM
  • Running the code in an enclave (see the CreateEnclave function) would prevent it and its data from being dumped. However, it looks very difficult to implement, and you would still need a network server to verify the attestation report and securely load the code to the enclave.

    Monday, September 16, 2019 9:26 PM