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



  • 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?


  • 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.


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2