Binary analysis tools, especially those like angr, typically come with an expectation that system interaction will be emulated or symbolic and won’t interact directly with host state unless explicitly permitted to do so. If the input binary is untrusted, then an attacker could leverage host interactivity issues to extract host information influence downstream processing. In this post, I will detail a bug which can demonstrate the former. The risk is concrete host information which winds up in angr analysis results might be leveraged by an attacker to gain insights into a host analysis platform.

Background

• chroot: This is a system call which allows a process with sufficient permissions to change the apparent root directory path resolution for itself and its children. You provide a real directory name as an argument and that directory will become “/” in subsequent path based file operations.
• SimProcedure: This is a hook for symbolic execution which allows the host to intercept and compute a response to a given function call. This is often used to implement guest behavior for common library functions or syscalls.
• concrete_fs: an argument in angr which enables the use of the host filesystem for guest file operations.

Host File Read in Angr

A binary analyzed by angr using default project settings can use the chroot system call to mount a host directory. Subsequent open/read calls can then read host contents (that the angr process has permissions for) without host approval and no concrete_fs requirement.

Note: The symbolic execution engine must reach the chroot procedure. Just having it in the binary is not sufficient.

First, let’s examine the key part of the chroot SimProcedure in angr 9.3.3 (abridged):

class chroot(angr.SimProcedure):
...
    def run(self, file_path):
    ...
        if not os.path.exists(newPath):
            return -1

        self.state.fs.mount("/", angr.SimHostFilesystem(newPath))

os.path.exists(newPath) tests for the existence of a file on the host filesystem. angr.SimHostFilesystem(newPath) creates a host filesystem object. state.fs.mount("/", ...) mounts that host based filesystem object to the simulated root path, making it accessible to guest symbolic execution paths. No check for concrete_fs is made. This is the trust-boundary violation.

The following binary, when compiled, will exercise the vulnerability:

/*
 * Minimal x86-64 Linux guest for validating angr's chroot SimProcedure.
 *
 * Build from the angr checkout when the binaries repository is beside it:
 *
 * gcc -O0 -o ../binaries/tests/x86_64/chroot_read \
 *   tests/procedures/posix/chroot_read/chroot_read.c
 *
 * The host directory to chroot into is argv[1].
 */

#include <fcntl.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    char buffer[64];
    int fd;
    ssize_t size;

    if (chroot(argv[1]) < 0)
        return 1;

    fd = open("/marker.txt", O_RDONLY);
    size = read(fd, buffer, sizeof(buffer));
    if (size > 0)
        write(STDOUT_FILENO, buffer, size);

    close(fd);
    return 0;
}

This binary simply calls chroot with an input argument. Assume marker.txt is a private file on the host system and there is an angr analysis which populates a report with the resolved stdout after symbolic execution. Then that report would contain the content of marker.txt. An example of such an analysis is as follows:

def test_chroot_read(binary: str, expected: str) -> None:
    marker = b"ANGR_CHROOT_HOST_READ_OK\n"

    # This directory and marker exist only on the analysis host. The Linux
    # guest is symbolically executed by angr; it is never run natively.
    with tempfile.TemporaryDirectory() as host_directory:
        Path(host_directory, "marker.txt").write_bytes(marker)

        project = angr.Project(binary, auto_load_libs=False)
        state = project.factory.entry_state(
            args=[binary, Path(host_directory).resolve().as_posix()],
            concrete_fs=False,
        )
        simulation = project.factory.simgr(state)
        simulation.run()

        assert not simulation.errored
        assert simulation.deadended
        stdout = [state.posix.dumps(1) for state in simulation.deadended]

    host_file_was_read = any(marker in output for output in stdout)
    print(f"angr {angr.__version__}: stdout={stdout!r}")

    if expected == "affected":
        assert host_file_was_read
    elif expected == "fixed":
        # The simulated open may still succeed with symbolic file content.
        assert not host_file_was_read
    else:
        raise ValueError("expected must be 'affected' or 'fixed'")

This issue was reported directly to the angr team via email, as recommended by the angr security policy, on August 28, 2026. The versions of angr affected: 9.2.12 through 9.3.3

What About write?

Upon finding this, my first question was if this could be turned into a write operation. Fortunately, host files are opened with "rb" permissions by default in the SimHostFilesystem implementation. Guest operations only affect simulated storage.

Resolution

The fix can be found in angr/angr#7017: Implement chroot properly. To summarize the angr team’s changes, they:

• added _root to track, internally, the root directory of the simulated filesystem
• changed chroot SimProcedure to use guest simulated fs relative to this root rather than forcing the host mount
• added a warning to the user if a chroot request path resolves to an already configured SimHostFileSystem, such as one created with concrete_fs=True

Thanks again to the angr team for the quick fix and turnaround!

References

Linux manual: chroot(2): Native Linux behavior, permissions, and limitations.

angr documentation: Hooks and SimProcedures: How Python procedures replace modeled guest behavior.

angr security policy at the fix commit: The project’s security expectations and private reporting guidance.

angr 9.3.3: Linux state initialization and concrete_fs: State construction and explicit host filesystem configuration.

angr 9.3.3: Vulnerable chroot SimProcedure: The procedure that creates a host-backed mount from the guest-supplied path.

angr 9.3.3: Host-backed filesystem implementation: Host-file loading and simulated filesystem caching.

angr 9.3.3: Simulated file implementation: File operations within simulated storage.

angr/angr#7017: Implement chroot properly: The fix and its regression tests.

pickle is Python’s built-in serialization/deserialization library. It allows users to capture Python state in a format that is transferable between interpreters. It has long been a rich source of bugs for users who rely on it to deserialize untrusted content. What makes pickle more dangerous than other serialization/deserialization utilities, such as JSON, is an object’s ability to override a special method called __reduce__, which embeds a callable into the pickled object. Upon deserialization, the callable can execute arbitrary Python code.

oauth2client is a deprecated Google library that implements OAuth 2.0 and integrates with Flask, a Python web framework. Its pickle deserialization is reachable from attacker-controlled input. If an attacker can forge a session cookie, that cookie can contain a payload that executes arbitrary code on the host before authentication.

In this post, I explain the bug, demonstrate the exploit, and alert any downstream users I may have missed.

The Bug

There are two functions I will highlight to help explain the bug: the source of the legitimate pickled OAuth 2.0 flow and the vulnerable destination of the forged pickle payload.

1. The _make_flow() function, which produces the serialized flow.

    flow = client.OAuth2WebServerFlow(
        client_id=self.client_id,
        client_secret=self.client_secret,
        scope=self.scopes,
        # ...
    )
    flow_key = _FLOW_KEY.format(csrf_token)
    session[flow_key] = pickle.dumps(flow) # ← pickled, stored in session
   

2. The _get_flow_for_token() function, which deserializes the pickle.

    flow_pickle = session.pop(
        _FLOW_KEY.format(csrf_token), None)
    if flow_pickle is None:
        return None
    else:
        return pickle.loads(flow_pickle) # ← deserialized from session
   

The cookie signature is validated before _get_flow_for_token() is called.

According to the project’s recommended default setup, the Flask app is instantiated with the oauth2client library integration and initialized with a SECRET_KEY. The key suggested by Google’s Bookshelf example is 'secret'. The oauth2client docstring uses 'your-secret-key'. This secret key is used to sign a cookie using HMAC. The cookie contains a pickled OAuth flow object.

The attacker must know or correctly guess the signing key. A wrong guess fails Flask’s cookie signature check, so the forged session is not loaded. The sequence of operations that leads to exploitation is as follows:

sequenceDiagram
    participant Attacker
    participant App as Flask app

    Attacker->>Attacker: Create new pickle from payload defining __reduce__
    Attacker->>Attacker: Build session with new pickle and matching CSRF token
    Attacker->>Attacker: Sign forged session cookie with candidate key
    Attacker->>App: Send forged cookie with OAuth callback
    App->>App: Validate cookie signature
    App->>App: Validate callback state and matching CSRF token
    App->>App: _get_flow_for_token() calls pickle.loads()
    Note over App: Pickle payload executes during deserialization

To validate the vulnerability, I created a simple proof of concept (PoC) that writes a file to the target server’s filesystem. Here is an excerpt:

class RCEPayload:
    def __reduce__(self):
        return (eval, ("open('poc_proof.txt', 'w').write('RCE achieved')",))

When pickle.loads is called, eval is run. When I ran the PoC in my test environment with oauth2client 4.1.3, Flask 3.1.3, and Python 3.13.2, I saw poc_proof.txt written to disk with the marker text.

Disclosure

I disclosed this vulnerability and the exploit PoC to Google on February 22, 2026. The report was marked as WONTFIX due to the project’s archived state, even though PyPI Stats reported 24,545,418 downloads of oauth2client in the last month when checked on October 11, 2026. These counts measure downloads, not unique users or vulnerable deployments. I am sharing these details without a fix strictly for educational purposes and to help downstream users mitigate the issue.

If your app is using:

from oauth2client.contrib.flask_util import UserOAuth2
oauth2 = UserOAuth2(app)

and you are using a weak secret key, then you may be vulnerable.

Brief Aside: Cracking HMAC Signatures

Assuming a weak secret, the HMAC-signed cookie can be brute-forced offline without server interaction. You only need one cookie/signing key. Hashcat 7.1.2 gives 2.53 billion guesses per second for mode 29100 (Flask Session Cookie) on my GPU (NVIDIA GeForce RTX 5080).

Lessons Learned

• Probably avoid pickle. This OAuth flow could have been JSON.
• Use google-auth instead of the deprecated oauth2client.
• Don’t use a hard-coded, weak, or shared example SECRET_KEY.

References

oauth2client 4.1.3 Flask integration: Source for _make_flow(), _get_flow_for_token(), and callback handling.

Google’s Bookshelf example: Example Flask application that sets SECRET_KEY to 'secret'.

Python 3.13 pickle documentation: Serialization behavior, __reduce__, and the warning against unpickling untrusted data.

Flask configuration documentation: The role of SECRET_KEY in signing session cookies and guidance on choosing a secure value.

HMAC overview: Background on keyed message authentication.

oauth2client download statistics: PyPI Stats reported 24,545,418 downloads in the last month when checked on October 11, 2026. This is a download count, not a count of vulnerable deployments.

Hashcat example hashes: Supported hash modes and example hashes. The GPU throughput reported above is from my own measurement.

Lately, I have been on a quest to find and fix bugs in open-source software that I use for my personal projects. In this post, I’ll highlight a bug that causes the analysis tool angr to miss functionality on certain architectures and could allow a malware author to evade static analysis.

Scenario

Assume you are given a Windows PE file and would like to determine whether it is malicious.

You run your nifty angr-based malware analyzer on it, and your tool reports that it is benign. You double-check the functions analyzed and note an entry point and a few functions called from it.

You run the executable and observe something strange: it prints a message whose strings appear in neither the entry-point function nor the functions called from it. This message appears to hint at malicious behavior occurring on the machine!

Contrary to what you might think, a lot happens before the entry point runs.

Background

Thread Local Storage (TLS)

Microsoft’s PE format documentation defines TLS as follows:¹

The .tls section provides direct PE and COFF support for static thread local storage (TLS). TLS is a special storage class that Windows supports in which a data object is not an automatic (stack) variable, yet is local to each individual thread that runs the code. Thus, each thread can maintain a different value for a variable declared by using TLS.

TLS callbacks support TLS setup and teardown. During startup, they run in sequence before the entry point.² Typical uses include calling constructors and destructors. This functionality can be abused to evade analysis by detecting analyzers before the main entry point.³

Use in the wild

I found a few examples of TLS callbacks being used for evasion:

• The first public use of TLS callbacks to run code before the entry point was W32.Shrug,⁴ credited to “roy g biv”.⁵ Chthon is a descendant file infector.⁶
• An analysis of a Mustang Panda PlugX sample shows that its DLL loader finds and calls the TLS callbacks of the target DLL.⁷
• Rhadamanthys uses static TLS callbacks.⁸

Because attackers use TLS callbacks to hide functionality, these callbacks are important targets for static analysis. But what if the analysis tool fails to parse them correctly?

The TLS Callback Bug in angr

angr is a symbolic execution analysis engine for executables that supports a variety of custom analyzers.

Under the hood, angr uses CLE, a library responsible for parsing and loading targets into a form that angr can analyze. CLE parses PE files, including their TLS callbacks.

CLE’s TLS callback handling is implemented in cle/backends/pe/pe.py:

def _register_tls_callbacks(self, addr):
    callbacks = []
    callback_rva = AT.from_lva(addr, self).to_rva()
    callback = self._pe.get_dword_at_rva(callback_rva)
    while callback != 0 and callback is not None:
        callbacks.append(callback)
        callback_rva += 4
        callback = self._pe.get_dword_at_rva(callback_rva)
    return callbacks

Can you spot the bug?

TLS callback addresses in 64-bit PE files are 8 bytes wide, not 4!

For a 64-bit PE file with a TLS callback at VA 0x140001000, the buggy parser reports two TLS callback addresses: 0x40001000 and 0x1, hiding the actual address. This affects downstream angr analyses that use the enumerated TLS callbacks.

Microsoft’s PE format documentation notes the architecture-dependent sizes:¹

Note: References to 32-bit offsets and index multipliers of 4 apply to systems with 32-bit architectures. In a system based on 64-bit architectures, adjust them as necessary.

The issue was reported and tracked in CLE issue #648. This bug dates back to at least CLE version 5.6.10.5. It affects angr/CLE versions up to and including 9.2.196. The downstream impact depends on how an analysis uses the parsed TLS callbacks.

The Fix

I added a check of the target’s architecture to select the appropriate pointer size and read function. The merged implementation is shown below:

def _register_tls_callbacks(self, addr):
    """
    TLS callbacks are stored as an array of virtual addresses to functions.
    The last entry is empty (NULL), which indicates the end of the table
    """
    callbacks = []

    callback_rva = AT.from_lva(addr, self).to_rva()
    is_64bit = self.arch.bits == 64
    ptr_size = 8 if is_64bit else 4
    get_ptr = (
        self._pe.get_qword_at_rva if is_64bit else self._pe.get_dword_at_rva
    )

    callback = get_ptr(callback_rva)
    while callback != 0 and callback is not None:
        callbacks.append(callback)
        callback_rva += ptr_size
        callback = get_ptr(callback_rva)

    return callbacks

Validation

To validate this fix, I added a unit test that checks a crafted executable with a TLS callback address above 4 GiB, so the upper 32 bits are nonzero:

def test_tls_x64(self):
    exe = os.path.join(TEST_BASE, "tests", "x86_64", "windows", "TLS.exe")
    ld = cle.Loader(exe, auto_load_libs=False)
    tls = ld.tls.new_thread()

    assert ld.main_object.tls_used
    assert ld.main_object.tls_callbacks == [0x140001000]

    assert tls is not None
    assert len(ld.tls.modules) == 1

This checks that CLE recovers the full 64-bit callback address rather than misreading it as two 32-bit entries.

You can examine the fix in PR #649. I’d like to give a shout-out to the angr team for the prompt review and merge!

Lessons Learned

• Always check for TLS callbacks.
• Ensure your debugger is configured to break on TLS callbacks.
• MSVC doesn’t always use a .tls section for TLS callbacks. Use the TLS data-directory entry to locate the TLS directory.

References