What is the point of VirtualProtect when any process, including malware, can use it?

Question

I understand that the VirtualProtect function changes the permissions on a page in memory without question. Surely this ends up with no immediate purpose when any running process is able to use it?

For example, someone could easily write a piece of malware which uses the VirtualProtectEx function in order to detour instructions and cause havoc. On the other hand, a user may have a legitimate reason for allowing a process to modify memory (ie. game cheats).

Candelabra

That assumes that the attacker can run code on the system they are attacking, which VirtualProtect tries to stop. – Shavon

Windows is protected when no malware is running, and there are no vulnerabilities that allow a malware to run. If we start from the premise "malware is already running" then it's a no-brainer that we reach a conclusion "malware can cause havoc". But the premise is wrong. – Ellora

Answer 1

Someone could easily write that piece of malware, but how would they get the target to execute it?

VirtualProtect allows me to make memory executable selectively. This means that I can mark the buffer where I store untrusted data as non-executable, and the security vulnerability that I have that allows the untrusted user to modify the return address of my function cannot jump to that buffer and execute code there, thus stopping an attacker from executing VirtualProtect himself.

It also allows me to make memory read-only. This means I can mark the area next to the untrusted buffer read-only, and a buffer overflow cannot overwrite more essential data. Thus, no remote code in my application, no VirtualProtect by the attacker.

Once the attacker somehow gains access to the system, he can use VirtualProtect to remove protections of processes at the same security level, but at this point you have already lost anyway.

Purport

Thanks, very interesting. I don't see why others think my question is badly asked though. Oh well! – Candelabra

@Mhmk I would assume it's because once malware is on the system reasoning about security is pointless, given that security has already been compromised. – Edson

@Edson this question also applies to other areas such as injection of game cheats. The user may want to modify the game's memory, but the game itself wouldn't want cheating. The point I am trying to make is security may not be an issue for the user in similar cases. – Candelabra

@Mhmk in that particular case ACLs are your friend, only a debugger with an ACL the same as the process can debug it. That said doing so would probably make the game unplayable. – Edson

@Mhmk Cheat prevention is not in the purview of VirtualProtect. In fact nothing is, because the only way to completely prevent cheating is to remove physical access to the machine. Games these days instead try to detect cheating and then take action based on that (usually suspending the game account). – Purport

Still an important question. In security, when one starts with the premise "You have already been compromised" the issue then becomes how to detect the malicious software, and keep it from doing damage. "You're hacked, you're screwed" isn't good enough anymore. – Purpose

@RickHenderson That may be so, but that is a very different, far broader question than "why isn't VirtualProtect a security hole in itself?" – Purport

Answer 2

I have used VirtualProtect to help track down an improper memory access.

I allocated a page of memory, initialized it, then marked it Unreadable/Unwriteable, and then another component in our mega-monolithic program improperly accessed my pointer. As soon as that component tried to write to an unwritable page, we saw the Access Violation, and we knew who the offending party was.

(prior to this, we only knew that memory had been overwritten... but we did not know which component was doing it).

Heidyheifer

Answer 3

Mostly to prevent attacks and to allow for JITs and the like. Without VirtualProtect you have no way to mark the page as non-writable and executable or vice versa. That said if the system already has malware on it then the issue is so to speak already past the airtight door. In the ideal case a process can also use ACLs to prevent another process from inspecting its memory or changing it's memory protections. This is how secure playback works.

If malware is already on the system then nothing you do will work because the malware may be in kernel mode. In which case it already can do whatever it likes.

Edson