2

I found that many debuggers (like x64dbg) or hex viewers (HxD) allow you to access and modify memory of another process. It works without any asking for permission.

I even wrote a simple program that replaces a string in memory of other processes and it works. (It uses CreateToolhelp32Snapshot, Process32First, Process32Next functions to find the process, OpenProcess to access it, VirtualMemoryEx to get valid memory locations and ReadProcessMemory/WriteProcessMemory to read/write into it.) It could potentially be misused for malicious activity.

Why does that work? Why does Windows provide us such a functionality? Shouldn't it be more restricted?

Ahoj Lidi
  • 21
  • 1
  • 2
  • 4
    Your user is presumably an administrator on your machine. If you were not then you would (presumably) only be able to do this to processes created by your current non-administrator user. – Mokubai Feb 03 '20 at 10:01
  • In addition it's not unusual to allow this in some capacity e.g. for shared memory and direct process communication. – Seth Feb 03 '20 at 10:13
  • I tried it only as admin. Most home computers just have one account. But even with UAC on max it doesn't ask me to allow it. I successfully modified text in a text field in Firefox. – Ahoj Lidi Feb 03 '20 at 10:19
  • Do you have to allow the debugger (UAC prompt) when you first run it? Not when you modify things, on its first run... – Mokubai Feb 03 '20 at 11:35
  • @Mokubai No. I downloaded x64dbg, didn't install it (or whatever the Setup option in x96dbg.exe means). Never asked me for a permission. No UAC prompt. And it works. I can change memory, set breakpoints, etc. – Ahoj Lidi Feb 03 '20 at 11:39
  • 1
    Debugging is a privilege. The CPU can't share memory - if programs want to share memory they memory map the same file. Windows has ways of inserting code into the debugee and the debugger and debugee talk via Windows. Type `gpresult /z` and you'll see you have debug privilege. – Mark Feb 03 '20 at 16:42
  • @Mark I don't see anything like 'debug' in the output: https://pastebin.com/5nNAQHNZ – Ahoj Lidi Feb 03 '20 at 17:40
  • I'm not sure why you don't have any. That list should be full, did you run `gpresult /z` as an admin? – Mark Feb 03 '20 at 18:48
  • 4
    That processes can read/write memory of other processes of the same user is a fact. I assume the integrity levels (lower, normal, elevated) has been introduced to reduce the impact of remote code injected in e.g. a web browser process. In the end the full memory access is the way Windows was designed to allow inter-process communication and for compatibility reasons Microsoft can't change this behavior anymore as it would break a lot of programs. – Robert Feb 03 '20 at 19:33
  • @Mark Actually, I didn't. Now, I tried to run it as admin, and I can see "Debug programs" there. Here's the new output: https://pastebin.com/Rxmc74TU – Ahoj Lidi Feb 03 '20 at 19:42
  • @Robert Isn't it a security threat? Someone could write a program that would steal your login credentials, change your inputs (bank account number, bitcoin address), behavior of programs, etc. – Ahoj Lidi Feb 03 '20 at 19:47
  • @Ahoj That is a question how you define security. Modern OS that provide sand boxing features provide a different level of security. Windows just protects the processes of user1 against those from user2 (and those with a lower integrity level). Of course the remaining risk on Windows is therefore a bit higher... – Robert Feb 03 '20 at 19:55
  • @Robert It's just hard to believe that it is so easy to do bad stuff on the most popular OS (for a PC) that a lot of people uses. – Ahoj Lidi Feb 03 '20 at 20:08
  • https://devblogs.microsoft.com/oldnewthing/20200203-00/?p=103391 _It rather involved being on the other side of this airtight hatchway: Disclosure of information you already had access to_ – Mark Feb 04 '20 at 19:13
  • @AhojLidi the worst thing in an OS, as I think, is when it restricts me from doing anything I want on MY computer with MY memory. This kind of baby-sitting by the OS that you propose degrades me from actual owner of the system to some keyboard hitting monkey. The thing is, its not Window's fault if you install or run some malicious program for dubious source and it steals you credentials, its 100% of you, as a user. – ScienceDiscoverer Aug 09 '22 at 05:17

0 Answers0