Blog

Fuzz testing is incredibly useful: it has caught many a bug during the development of NTP packet parsing and gzip/bzip2 (de)compression.

But I've always been unsatisfied with the fuzzer being a black box. When it runs for hours and reports no issues, what do we actually learn from that? In ntpd-rs we've previously had a bug fly under the radar because the fuzzer just did not reach a large chunk of code. So, does my fuzzer actually exercise the code paths that I think it should?

Over the past couple of months we've been hard at work on libbzip2-rs, a 100% Rust drop-in compatible implementation the bzip2 compression and decompression functionality.

For this project, we used c2rust for the initial translation from the C code to a Rust implementation. The generated Rust code has now been cleaned up and made safe where possible. This post describes our experiences using c2rust for this project.

This article was authored by Jordy Aaldering and Folkert de Vries

Over the past couple of months, we teamed up with Bernard van Gastel and Jordy Aaldering at Radboud University's Software Energy Lab to measure nea's energy efficiency.

The NTP protocol is used by many devices to synchronize their system clocks. However, many devices use SNTP clients (Simple NTP) which are even more vulnerable to interference. As most (S)NTP packets are unauthenticated, they are vulnerable to spoofing, making it possible to change a device's time by manipulating (S)NTP packets.

In this blog, we discuss how (S)NTP packets can be forged to manipulate a device's system clock. Especially on the default SNTP client for many Linux systems, this turned out to be very easy. We will also dicuss the consequences of such attacks, as well as how these attacks can be prevented.