Unchiseled, the story of my first CVE (CVE-2024-43798)

I've always found it ironic how the worst vulnerabilities are often caused by the simplest mistakes. Today, I will be talking about CVE-2024-43798, a vulnerability we discovered in Chisel, a popular open source project for tunneling network connections. While this post serves as an advisory, I will mainly be going in depth on the personal story of finding, fixing, and reporting the issue. (If you just want the details of what to do, scroll to the bottom.)

Background

Chisel is a popular project (12.6k GitHub stars at the time of writing) which allows you to setup encrypted tunnels (using the SSH protocol) to proxy network connections. The main use for a project like this is getting around firewalls. For example, connecting to internal services behind a network firewall via a Chisel server. You can also use it in reverse, allowing Chisel to act as a reverse proxy, in order to expose otherwise inaccessible services to the public internet. I would recommend looking at the project's advertised features, as there's a lot of interesting configurations in which Chisel can be used in.

At Fyra Labs, we use Chisel in one of our projects, Chisel Operator, which allows you to tunnel Kubernetes services to the public internet easily. The operator can either use a Chisel server that you manually setup, or automatically provision and manage a VPS on a specified Cloud provider (ex. AWS) for tunneling. The vulnerability we discovered mainly affects the second case.

Discovery

On an otherwise slow day, my colleague and current maintainer of Chisel Operator, Cappy, was messing around with her homelab. She uses (and created!) Chisel Operator in order to get around her ISP's CGNAT.

As she was messing around, she attempted to manually connect (with the Chisel CLI) to the Chisel server deployed by the operator, forgetting to specify credentials. Despite the credentials not being passed, the connection was established successfully. This came as a surprise to her and thus she notified me.

We soon set up a Chisel server for testing, using the same steps that the operator would have done automatically, which includes generating and specifying a password required for connection. Yet again, the Chisel server let us connect without specifying a password. At this moment, a pit in my stomach grew. We knew that there was quite a bit of usage of our project in the wild, including an enterprise customer who had a support contract with us. We had to fix this fast.

Cause

Remember how I commented on the irony of the worst vulnerabilities being caused by the simplest fuck ups, well, we're about to see that on full display. I remember being on a Discord call late at night, panicked, reading through the Chisel source code. Simultaneously, Cappy was tinkering more with the Chisel deployment we were using for testing. She soon noticed that the Chisel server would enforce authentication when passing a password on the --auth command line flag, but not when passed with the AUTH environment variable.

These methods were both documented as valid ways to configure the server with a password. However, even more surprising to us, the Chisel client would respect that AUTH variable. With this information, I checked in the source where AUTH was actually being read. This is where we realized that contrary to the documentation, AUTH was never read in the server entrypoint, only in the client entrypoint. Three lines of code. Oh shit.

Reporting

After we determined the cause, I emailed the maintainer, Jaime, describing the vulnerability. I also contacted our enterprise client and notified them of the issue. Luckily, they weren't affected due to their configuration. Cappy also wrote a workaround for the issue in Chisel Operator, setting credentials using the --auth flag instead, and silently rolled it into a standard patch release.

Jaime got back to us around a week later (thankfully right before I was to go on a trip to give a talk at Flock to Fedora), silently patching the bug in an otherwise standard release. We further communicated, setting up GitHub security advisories on the project repo, and filing an advisory there in order to request a CVE number. He also discovered that the issue was already reported 3 years prior, but forgot about it (mood) because of lack of time for open source.

Takeaways (Lea's thoughts)

Here are a short list of personal thoughts:

• If you're a maintainer of a FOSS project on GitHub, please enable GitHub's vulnerability reporting feature if you haven't already. It makes reporting and disclosing a vulnerability faster and easier.
• It's important to remember that maintainers of FOSS projects have no obligation to you, including when it comes to security vulnerabilities. Many companies (and individuals) foolishly see open source as a endless faucet of free (and high-quality) code. Want guarantees? Start paying maintainers.
  • It's unlikely that we would have done this work if it weren't for the one customer who has a support contract for Chisel Operator with us.
    • [SHAMELESS PLUG INCOMING] If you need any open source (or Linux) work done, send us an email at [email protected]. We'd love to talk to you.
• If you ever need a "case-study" for your stubborn management of why funding FOSS matters, well here you go.
• Thanks to Cappy and Jaime :3

What you need to do

If you're a user of Chisel, update to at least v1.10.0 or specify server credentials using the --auth flag.

If you're a user of Chisel Operator, update your deployment to at least v0.3.4. Please note that for automatically provisioned exit nodes, you will have to delete those and redeploy. For manually provisioned exit nodes, follow the instructions for Chisel as mentioned before.