0
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
Posted 2020-02-03T09:55:19.640
Reputation: 1
3Your 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 – 2020-02-03T10:01:00.610
In addition it's not unusual to allow this in some capacity e.g. for shared memory and direct process communication. – Seth – 2020-02-03T10:13:14.540
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 – 2020-02-03T10:19:31.417
Do you have to allow the debugger (UAC prompt) when you first run it? Not when you modify things, on its first run... – Mokubai – 2020-02-03T11:35:46.910
@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 – 2020-02-03T11:39:42.983
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 /zand you'll see you have debug privilege. – Mark – 2020-02-03T16:42:44.233@Mark I don't see anything like 'debug' in the output: https://pastebin.com/5nNAQHNZ
– Ahoj Lidi – 2020-02-03T17:40:49.673I'm not sure why you don't have any. That list should be full, did you run
gpresult /zas an admin? – Mark – 2020-02-03T18:48:04.920That 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 – 2020-02-03T19:33:01.330
@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 – 2020-02-03T19:42:00.120@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 – 2020-02-03T19:47:36.950
@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 – 2020-02-03T19:55:07.560
@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 – 2020-02-03T20:08:03.163
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 – 2020-02-04T19:13:06.370