Don’t panic. Yes, there were a bunch of CVEs affecting potentially hundreds of thousands of users found in rsync in early December – and made public on Tuesday – but a fixed version came out the same day, and was further tweaked for better compatibility the following day.
There are no known attacks exploiting the flaws in the wild.
The half a dozen security holes in rsync were announced on Openwall on January 14. One of them has a CVSS severity score of 9.8 out of 10, and the description says:
As this affects all versions of rsync since version 3.2.7 in October 2022, we hope anyone running a public-facing rsync server updated it quickly. The others are all less severe, in the 5.6-7.5 range, but they’re all as old as rsync itself, which dates back to 1996.
Good news: these vulnerabilities were identified in December of last year, and rsync 3.40, released the day after the Openwall announcement, fixes all of them. That version did introduce a few regressions, though, and the following day (January 15) saw a minor bug-fix version, version 3.4.1. As this is a high-priority problem – BleepingComputer says it identified 600,000 affected machines – Linux distributors are on the case.
For instance, Canonical put out an update going back to Ubuntu 14.10 on the day of the announcement. As you’d expect, except for the latest “Oracular Oriole” release, it only covers LTS versions. If you’re still running CentOS Linux, we hope you’re paying someone for fixes.
That syncing feeling
Rsync is a very interesting tool. What it does sounds a little like magic. It synchronizes two copies of an arbitrarily large file across a relatively slow connection without sending the contents of the file across the line. When it comes to distributing software updates, this is a superpower. And it’s FOSS. As a result of those two factors, it’s exceptionally widely used by all sorts of operating systems. Therefore vulnerabilities in rsync affect a lot of computers.
This means that the six CVEs on January 14 are a big deal. The first five all have consecutive numbers, and stem from issues logged in Red Hat’s Bugzilla on December 5. The severe one is a heap buffer overflow in rsync due to improper checksum length handling, and the next two also relate to checksums – info leak via uninitialized stack contents (but it’s just one byte), and the rather more worrying leaking of arbitrary client files. The next two are a path traversal vulnerability and safe-links option bypass leads to path traversal.
All of these were reported by the same team of Google security researchers – Simon Scannell, Pedro Gallegos, and Jasiel Spelman. The final one, race condition handling symbolic links, was found on December 18 by Russian pen-tester Aleksei Gorban, a Kaspersky veteran who now works for TikTok. ®
Bootnote
Microsoft, which tends to like to do things its own way, has its own protocol for performing the same task as rsync, called Remote Differential Compression (RDC).
As you might expect, back in 2006, Microsoft claimed this was better, but as the more cynical spectators might anticipate, you can also find RDC on the list of deprecated features as of Windows Server 2019.