Overview

Most of my time this week was spent optimizing the open_channel fuzzer and following up on received feedback. In addition, I also explored a few new fuzz target ideas.

Goals accomplished

  • Reworked the tlv_invoice_request target: I received feedback on the tlv_invoice_request wire fuzzer that I pushed earlier this week, and it turned out that the functions I was trying to fuzz are already tested at a higher level by the existing fuzz-bolt12-invrequest-decode test. Instead of discarding the new target and the work I had put into it, I decided to rework it as an improvement to the existing test. The rework is now complete, and the resulting PR is #8485.

  • Reworked the tlv_offer target: I’d already created a fuzz test for tlv_offer, but I later realized that its marshalling and unmarshalling functions are already covered by the existing fuzz-bolt12-offer test. Following the same approach as with the tlv_invoice_request fuzzer, I reworked my new test into an enhancement for that existing target. The work is now complete, and I’ll push the improvements upstream shortly.

  • Reworked the parse_onion_message target: One of my main goals for the week was to revisit and improve the fuzz targets I had already written, focusing on increasing their code coverage to a satisfactory level. I started with the parse_onion_message target. Instead of fuzzing the core parse_onion_message() function in common/parse_onion_message.c directly, I restructured the target so that the fuzzer’s entry point is the actual handler for onion messages from peers- handle_onion() in connectd/onion_message.c.

    Rewriting the target took about a day, but the result is a much more realistic and comprehensive test that exercises the full path down to parse_onion_message(). The target works well and I plan to push it upstream in the upcoming week.

  • Addressed received feedback: I received feedback on some of the fuzz targets I had previously pushed upstream, including the one for codex32 operations. A good portion of my time this week was spent addressing that feedback and making the necessary changes. I’ll continue monitoring for any further suggestions, but for now, the updates have been implemented and I’m ready to move forward with the remaining work.

  • Improved the open_channel target: In my efforts to trigger the bug in initial_channel_tx(), I focused on improving the fuzz target for fundee_channel(), which processes incoming open_channel messages from peers. While I had started this work last week, it turned out to be much more involved than anticipated and extended into this week as well. I’m happy to report that the effort paid off, the improved target successfully triggers the bug in initial_channel_tx().

    This likely indicates a serious DoS vulnerability, although I’ll need further confirmation to be certain. I’ve already notified Matt about the finding and pushed the new open_channel target along with the crashing input upstream in PR #8411. The next steps now depend on his assessment.

Next week’s goals

Here are some of my immediate goals for the next week:

  • 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 planned to add a stateful fuzz test simulating this function in this week but couldn’t find the time to do it, so I plan on tackling this in the upcoming week.

  • Revisit the finished targets: I planned on revisiting some of my complex targets to ensure they exercise their code paths more effectively, and I’ve started implementing the plan with the onion_message_parse fuzzer, but there’s still a lot of targets left, so I plan on doing the same for them in the upcoming week.

  • Possibly complete the target for channeld-lightningd interface: I had already completed the initial work for this target, but after my last discussion with Matt, I realized that the lightningd interfaces aren’t particularly valuable fuzzing targets, as they generally don’t handle untrusted input directly. That said, since I’ve already invested time into developing this fuzzer, I’d still like to wrap it up quickly if I get the opportunity, rather than letting the work go to waste.

Challenges

The open_channel target ended up taking significantly more time than I had anticipated—roughly two full days. While I’m glad I was ultimately able to achieve the depth I was aiming for with this target, this experience reinforced something I noted in last week’s Challenges section: pushing fuzzers to reach meaningful depth tends to be a time-intensive process. With that in mind, I’ll need to be more selective moving forward and prioritize targets where I believe the investment is most likely to yield impactful results.

Week 8 of SoB wraps up this week, with midterm evaluation results expected at the start of the next. I’m fairly confident about passing, though of course, there’s always a bit of uncertainty until it’s official.

This week, I had to allocate some time to prepare for my upcoming semester, which meant slightly less time for SoB work during weekdays. That said, I made sure to catch up over the weekend to stay on track. Looking ahead, I expect academic responsibilities to take up more of my time, so my goal is to get as much meaningful work done as possible before the semester fully kicks in.

Till next time,

Chandra.

<
Previous Post
SoB: Week 7
>
Next Post
SoB: Week 9