Security question about injection

If I have a golang binary and as an attacker I want to inject into its memory, or replace it on disk, what would I be trying to get the application code to let me do?

e.g. you’ve got a set of supported syscalls: Supported System Calls · nanovms/nanos Wiki · GitHub

it looks like the usual thing some injectors on linux would have (ptrace, memcp, memset) are off the table.

is the elf itself at least kept read only on disk (vs the static folders)? is there ever writable disk space on the image? (would be nice for storing sqlite on the remaining disk space)

given a poorly written app, how would it end up overwriting itself inside of nanoVMs?

There are a few questions here. Let me try to answer.

I wrote about this a while back ago here: Hacking Unikernels Through Process Injection [A Step by Step Guide] | HackerNoon .

  1. With a default setup yes you’d be able to write over the binary if the application would let you. However, we have the exec_protection flag that can be enabled Configuration - Ops which prevents the kernel from executing code outside the main executable and anything else clearly marked. It’s not on by default because there are a few JITs out there that wouldn’t work with it. As a defender pledge and unveil are both supported and could help prevent this as well: Applying Sandbox Security to Node.JS Unikernels with OpenBSD Pledge and Unveil .

  2. The writeable disk space is configurable up to the end user, normally via Configuration - Ops but other volumes in the case of a database for example can be mounted.

Just as an update to this, we chatted about it and we didn’t see any reason not to have the default for the program and loader to be read-only Disallow overwriting of program and interpreter files by default by francescolavra · Pull Request #1842 · nanovms/nanos · GitHub regardless of potential RFI, whether exec_protection is turned on or if pledge/unveil is used (although you can toggle this off if you have some weird polymorphic case we haven’t thought of).