Overview

Most of my time this week was spent on writing a new fuzzer for channeld/full_channel.{c, h} operations and following up on received feedback. In addition, I also wrote a report for a DoS attack vector that one of my fuzzers uncovered.

Goals accomplished

  • Updated Matt on the gossipd-connectd target: Since the gossipd–connectd fuzz target was already substantially developed and even uncovered a vulnerability, I believed it was a good time to get Matt involved for feedback. I pushed the target upstream early this week but didn’t receive any feedback till now. I’ll wait for his reponse in the next week and if I don’t hear anything back, I will remind him of this target.

  • Fixed the codex32 target: I received extensive feedback on the codex32 target that I pushed upstream last week, which led to a significant amount of rework. I had to make several modifications to get the target into a more acceptable state, and the feedback–improvement loop continued right up to the end of the week. I’m happy to report that the target has finally received an ACK from Matt and is in a mergeable state now.

  • Addressed received feedback: Other than the feedback on the codex32 target, I also received substantial feedback on some other targets that I had pushed upstream, like the amount-arith target that I pushed upstream last week. This required a number of changes since the target was really subpar but I don’t think the work is finished as of yet. I believe Matt has already provided me feedback on the latest push, which I plan to address in the upcoming week.

  • Wrote a vulnerability report: When addressing feedback on the fundee_channel target I had previously pushed upstream, I encountered a new input set that caused a crash in CLN. I informed Matt, and after his investigation, we confirmed that this was indeed a real vulnerability. Interestingly, the crash would occur higher up the call stack (in the HSMD) rather than within the target function itself.

    Following that, the next step was to draft a report for the Core Lightning security mailing list. To do so, I had to set up and run the attack program Matt used to trigger the vulnerability. That took a bit of effort, but I’ve now completed it and sent the draft report to Matt for review. Once I hear back from him, I’ll move forward with sending the final report to the mailing list.

  • Worked on a stateful full-channel fuzzer: I started work on a commit_tx() fuzzer towards the end of last week and made some initial progress. However, I later concluded that the value it would provide didn’t justify the effort required. Instead of dropping the work altogether, I repurposed it into a stateful fuzzer for channeld/full_channel.{c, h} operations, which seemed like a more promising direction.

    Fortunately, there was already a unit test for full-channel operations that I could draw from, which helped me finish the work on this new target relatively quickly. However, the fuzzer currently crashes, and from my investigation, it looks like it could be due to a bug in the HTLC state machine. Before proceeding further, I’ll check in with Matt to confirm whether this is an actual bug or an expected behavior. Once I have clarity, I’ll decide on the next steps.

  • Revisited the initial_channel fuzzer: After Matt helped me pinpoint the cause of the crash in this target—unrealistically low dust_limit values—I implemented a fix for that. But instead of resolving the issue, it led to yet another crash. I brought this back to Matt, and this time it appeared to stem from another unrealistic channel parameter. I adjusted that too, but it just resulted in another different crash.

    At this point, it’s clear that continuing to patch over individual parameter issues in isolation isn’t the best use of time. Instead, I think the most productive next step is to attempt triggering this crash from a higher-level operation within the dual-funding protocol, or so does Matt believe.

  • Revisited the open_channel2 fuzzer: One of my goals last week was to make the open_channel2 fuzzer stateful at the moment when our simulated peer receives a message from another peer. I did implement changes that allow us to simulate more arbitrary incoming messages—rather than just a single, well-formed type—but converting the entire fuzzer to a fully stateful model would require significantly more time, and I don’t believe it’s justified. I’ve decided not to modify the fuzzer further for now. If Matt requests additional work, I’ll revisit it, but I feel this target is sufficiently thorough at present.

Next week’s goals

There are still quite some targets that I haven’t received the feedback for just yet, or have received the feedback but haven’t addressed yet. They are on the topmost of my priority list for the next week but other than those, here are some of my immediate goals:

  • Add a target for channeld-connectd interface: peer_in() in channeld/channeld.c is responsible for handling connectd messages such as UPDATE_ADD_HTLC and REVOKE_AND_ACK. Given its stateful structure, I have planned to add a stateful fuzz test simulating this function for quite some time now but couldn’t find the time to do it, so I plan on finally tackling this in the upcoming week.

  • Try triggering the initial_channel bug from the dual-channel handlers: I traced the callers of the function that triggers the crash in the initial_channel fuzzer and found that they all live in openingd/dualopend.c. This means that, to reproduce the bug from a higher level, I’ll need to target one of the handlers in that file. I’ll attempt this in the coming week, and if it doesn’t yield results, I’ll reach out to Matt for assistance.

  • Determine the severity of the gossipd-connectd vulnerability: It’s already confirmed that the vulnerability I discovered in CCAN’s integer map function—exposed by fuzzing the gossipd‑connectd interface—is genuine and requires a fix. However, Matt prefers that we assess its severity before notifying the Core Lightning team. To do this, I’ll adapt Matt’s attack program to send the specific gossip messages that trigger the crash instead of open_channel messages. Since the target is written in Go, I’ll need some assistance, but I believe this approach is the most effective way to gauge the crash’s impact. I’ll begin work on this in the coming week.

  • Reach a conclusion on the full-channel bug: I’ve added the full-channel target, which appears to have uncovered a potential vulnerability in the HTLC state machine. I’m not yet certain whether this is a genuine bug or merely the result of an impossible value. I plan to discuss it with Matt in our meeting next week and, hopefully, reach a conclusion.

  • Revisit the finished targets: I’ve already reviewed most of the targets I worked on; only the gossmap_manage target—and possibly one or two I may have overlooked—remains. I plan to revisit these in the coming week and wrap up this task for good.

  • Finish the work on the vulnerability report: I’ve already sent Matt the draft report and received his feedback. I didn’t have time to address his comments this week, but I plan to do so and finalize sending the report to the CLN team early next week.

Challenges

With the internship drawing to a close, my academic responsibilities are beginning to demand more of my time. I must report to my college at the start of next week, yet there are still a couple of weeks left in the internship—and I’m not yet at a point where I can begin to wrap things up work‑wise. My only option is to balance my coursework with my internship duties. I’ve already invested significant effort in this project, so it will take priority if a conflict arises. However, these are my final years of college, and I can’t afford an academic setback now. Maintaining both the quality of my work and my grades will require effort, but I’ve managed similar challenges before—and the fact that this is only temporary gives me confidence. I’m committed to giving both my best and optimistic about the outcome.

Today marks the end of the 10th week of my internship. I’m thrilled to have finally uncovered a serious vulnerability in the CLN codebase, and I’m equally grateful to Matt—none of this would have been possible without his guidance. Although I had hoped to add more targets to this project, with the finish line now in sight, I’ll scale back my ambitions. My plan is to first reach definitive conclusions on the potential bugs already identified before pursuing any new targets. That seems like the best course of action for now, and I remain hopeful that I can still uncover a few more significant vectors.

Till next time,

Chandra.

<
Previous Post
SoB: Week 9
>
Blog Archive
Archive of all previous blog posts