Syscalls are disabled with seccomp. What attacks are still possible? How to prevent them?

Question

I want to run a piece of untrusted code on my machine.

I've disabled all syscalls (besides exit, sigreturn, read and write) with seccomp for a process. Now, I'd like to spawn a child process that will execute the untrusted code.

• What attacks are still possible?
• How to prevent them?

Answer 1

Depends what file descriptors the process has open, and a few other things. Here are some likely possibilities:

Denial of Service

• RAM exhaustion: if RAM allocation is unrestricted, just allocate as much memory as you can. Assuming it's a 64-bit process, you can easily exceed physical memory, and even swap, that way.
• CPU exhaustion: assuming CPU time is unrestricted, you can keep one core per thread busy with garbage tasks. On a heavily parallel system your process might not have enough threads to keep the CPU at 100%, but it can certainly used more than its fair share and potentially increase power usage to drain the battery or do other stuff like that.
• Disk I/O exhaustion: assuming there's at least one FD open to an actual file, you can saturate the disk I/O pretty easily. Even with NVMe drives, it should be easily possible to fill the entire bus with worthless activity.
• Disk space exhaustion: assuming there's at least one FD open for write to a file, and no disk space quota, you can fill up whatever volume(s) the writable file(s) is/are on.
• Network bandwidth exhaustion: assuming that at least one file descriptor is a network socket, you can fill it up with garbage activity to choke the network and especially Internet connectivity.

Elevation of Privilege

Assuming that there exists some more-privileged process that reads what this one writes (either reading files off the disk, off a local or network socket / pipe, or through some other IPC mechanism), you can try attacking that process.

• If it parses structured data, attack the parser, looking for a memory corruption vuln (if you find one, go for a return-to-libc attack; you already know the ASLR mask).
• If it takes commands from the process output (either directly or by reading an output script / config file), try to find outputs that let your write, or overwrite, arbitrary data to a sensitive location. Or that lets you destroy sensitive data by overwriting. Or at least make the privileged process waste a bunch of resources, as a more-privileged DOS.
• If it passes on the data you give it to some other system, attempt injection attacks against that system. For example, if it puts the data your process writes into a database, try SQL injection.

Answer 2

It really depends on what the file descriptors are connected to.

If they're connected to a terminal, they could be used to modify the terminal including, depending on the configuration of the terminal, executing arbitrary code. They could also exhaust memory if they're run inside a terminal emulator that has a large backscroll. If they're connected to files, they can be used to write malicious data that will exploit other programs when read or consume excessive amounts of disk space.

If they're connected to sockets, either directly or through standard input, output, and error over SSH, they can be used to send malicious data elsewhere, such as to exploit vulnerabilities in remote servers, or they can be used to use excessive amounts of network bandwidth, starving more important traffic and potentially causing a DoS. They could also be used to engage in part of a DDoS attack if they're certain types of sockets.

Note that "malicious" here doesn't just mean an attempt at a buffer overflow or code execution. It could mean sending data that is intentionally random so as to cause a receiving process to spend excessive resources in error handling. It could mean sending normal amounts of data in very small chunks so the remote system has to spend excessive resources in processing network packets or parsing the data. In this sense, you would need to consider anything that causes undesired operation or unpleasant consequences, including a DoS.

In any case, if the process just refuses to read, that can cause a bunch of inconvenience and backups in other areas and could lead to a DoS. Similarly if other processes expect to read from your malicious process and it refuses to write anything.

How you stop these really depends on what your file descriptors are connected to. You'll need to consider what happens if the output is voluminous and also what happens if it's specially crafted to be malicious in order to exploit the things that will interact with the output, as well as what happens if your process refuses to read or write anything.