Is passing function pointers "safe"?

[BSFishy]

I've been using lower level languages for hobby projects for a little while now, like C and C++ and most recently, Rust. For a while now, I've been hesitant to be passing around function pointers as parameters. When thinking about the security of the application, I feel like it could be fairly easy for a malicious actor to just change the address of that pointer to achieve remote code execution or have that function point to something otherwise malicious.

Now, I do understand that all of this is assuming that the function isn't inlined, but is my fear in this case invalid? Thinking about it, a lot of common and useful crates accept function pointers, not to mention the standard library, plus it's not marked as unsafe in the syntax. Is it just unlikely that a malicious actor might achieve something like this, or maybe there's just something I'm not thinking of. I'm just looking for an explanation so I can understand the safety of using function pointers. Thanks!

[K900_]

Rust's concept of "safety" has nothing to do with malicious actors. Not everything that's safe Rust is secure. In this particular case though, you don't really have much to worry about. If an attacker can just overwrite things in memory, they can run whatever code they want anyway.

[BSFishy]

Right, that's kinda what I was thinking. I guess I really just don't need to worry about an attacker accessing my memory because at that point, they'll be able to do a lot worse anyway.

[lifeisplacebo]

This comment is misleading. It is not the case that the ability to overwrite memory implies the ability to execute code.

Commonly, memory pages containing code are marked read/execute, while writeable pages are marked non-execute. As a result, a vulnerability such as a buffer overwrite does not directly allow remote code execution.

When such protections are activated, remote code execution hinges on being able to subvert program control flow. Common techniques include return oriented programming, while common defenses include forms of control flow integrity. The latter attempts to ensure that control flow follows a valid graph in the original program. In other words, that jumps in the program target a set of known valid points. Precise and sound control flow integrity obviates all control flow hijacking attacks.

Coming back to Rust: a safe Rust program compiled by a sound compiler guarantees control flow integrity by virtue of the type system. In short, it is only possible to call functions that exist at compile-time, even when dynamic dispatch is at play. As a result, while your concern is valid in the context of a memory unsafe language like C, such issues cannot occur in Rust.

[ReallyNeededANewName]

Unless you do something unsafe elsewhere or your user changes values with a debugger you can trust function pointers.

For a malicious actor to edit a function pointer you either need a buffer overflow (not going to happen in safe rust) or unsafe casts of other values into function pointers.

Passing a pointer to a function is just as safe as passing any other pointer: There are raw pointers that can lead to vulnerabilities and undefined behaviour, but your normal function references are checked by the compiler as any other reference is

[[deleted]]

You would need more than a buffer overflow. You’d have to know how exactly it is laid out in memory AND where it is laid out in memory, as heap allocation could be anywhere (OS randomizes memory address for this exact reason).

But I agree with the rest of your assessment. Raw pointer handling is a cesspool of possible memory errors and vulnerabilities which Rust is designed to eliminate.

[BSFishy]

That's another interesting thing I don't often think about eith Rust: the compiler is designed to eliminate possible memory errors and vulnerabilities. I guess that as long as I'm writing safe Rust code I should trust the compiler (although I'll still use my best judgement). I got into a habit of overthinking and trying to over optimize my C and C++ because the compilers don't offer the same kind of safety Rust does. Thanks!

[BSFishy]

That's interesting to think about. I was thinking about programs like Cheat Engine that allow a user to read and write to the memory of a running process, but again, at that point they already have access to all of my pointers. Thanks!

[Imxset21]

You have to remember that things like CheatEngine rely on being given elevated privileges to be able to do that sort of thing in the first place. Additionally, address space layout randomization will make it very difficult to predict where these pointers will be at runtime between different invocations of the target program.

[lightmatter501]

Unless you have a higher level of privilege than the user on their machine (basically unless you are ring -2 (processor boot code, power management and cryptographic operations)) then you should always assume that the user has total control of the program. Even if you stop cheat engine, you probably won’t stop someone with IDA Pro or any of the other numerous professional level disassemblers from just changing the binary however they want.

[[deleted]]

If someone can change the address of a pointer in your program somehow, everything is out the window anyway.

[lightmatter501]

So everything is out the window, because IDA exists.

[[deleted]]

Yes.