The world of enterprise security just got a wake-up call: CVE-2024-35141 impacts IBM Security Verify Access Docker images, versions 10.. up to and including 10..6. In plain English, if you’re running one of these Docker containers, a local attacker can get more permissions than they should—potentially taking over the whole system.

This post will cover the vulnerability, demonstrate an example exploit scenario, and help you fix the issue, using simple language and practical steps.

Exploitability: Local (code execution in the container)

- IBM Advisory: IBM X-Force (CVE-2024-35141)

What Went Wrong?

In affected versions, IBM’s Docker images for Verify Access run parts of their code with unnecessary privileges or as a user with higher access rights than needed. This means that someone who can get a shell inside the container—for example, with access to run jobs or scripts—might be able to perform tasks as the root user.

This is not just bad practice, but also opens the door to attackers escalating their rights, changing settings, installing software, or potentially breaking out of the container to the Docker host (if other vulnerabilities exist).

Let’s See How It Happens

Suppose IBM Security Verify Access runs a web app as a misconfigured user, but leaves some scripts or binaries as setuid root, or just runs everything as root by default.

Assume an attacker gains access to the container (maybe via an app RCE, misconfigured SSH, or simply as a valid but unprivileged user). Here’s a simplified code snippet that shows what such a container might look like in its Dockerfile:

# Vulnerable Dockerfile snippet (simplified example)
FROM ibm-security-verify-access:10..4

# Add application and utilities
COPY my-app /usr/local/bin/

# App runs as root (bad practice)
USER root

CMD ["/usr/local/bin/my-app"]

Or, worse, there’s an unnecessary setuid binary inside the container

# Inside running container, as a regular user
ls -l /usr/local/bin/helper
# output:
# -rwsr-xr-x 1 root root 123456 Apr 23 12:00 /usr/local/bin/helper

An attacker can leverage this setuid binary or application running as root, combined with known exploitation techniques, to spawn a root shell inside the container.

`bash

find / -perm -400 -type f 2>/dev/null

`

If any such binary is found and is poorly written (e.g., doesn’t drop privileges, allows unsafe commands), you can exploit it.

`bash

/usr/local/bin/helper

Modify Files, Get Full Control:

Now you’re root inside the container. You could change settings, deploy malware, or look for ways to escape to the Docker host.

Why Is This a Big Deal?

Containers are supposed to be isolated. But too many privileges in those containers, especially running stuff as root, means that an attacker gets full access within the container. While this is bad, things get much worse if there are Docker daemon misconfigurations: root in the container can lead to root on the host.

IBM Security Verify Access is widely used for critical access control. Anything that makes privilege escalation easy inside deployments increases risk and the attack surface for your most sensitive infrastructure.

Update Immediately:

IBM has released patched Docker images newer than 10..6. Grab the latest version from IBM’s repositories and redeploy.

FROM ibm-security-verify-access:10..7

RUN useradd -r -m -d /app myapp

Scan for setuid Binaries:

Periodically scan your containers for unexpected setuid/setgid binaries with find / -perm -400 -type f.

Regularly Review Dockerfile and Entrypoint Scripts:

Limit the number of scripts and binaries that require elevated privileges, or refactor them to drop privileges as soon as possible.

Follow Best Practices:

See Docker Security Best Practices – Docker Docs.

References

- IBM X-Force: CVE-2024-35141 Security Bulletin
- IBM Security Verify Access Documentation
- Docker Security Best Practices
- CVE-2024-35141 NVD Entry

Conclusion

CVE-2024-35141 is a local privilege escalation issue, but it deserves serious attention—the attack surface in enterprise access brokers can make or break your organization’s security. Patch your containers, don’t run as root, and audit for dangerous binaries.

Questions, concerns, or tips? Share your thoughts and let’s keep our containers safe.

Timeline

Published on: 12/19/2024 02:15:22 UTC