My minimal, memory-safe Go rsync steers clear of vulnerabilities
5 hours ago
- #memory safety
- #Go programming
- #rsync security
- In January 2025, multiple security researchers published 6 vulnerabilities in rsync, some allowing arbitrary code execution and file leaks, prompting an analysis of whether a custom rsync implementation in Go was affected.
- The article covers 12 vulnerabilities from January 2025 and May 2026 batches, advising users to upgrade upstream rsync to 3.4.3+ and gokrazy/rsync to v0.3.3+.
- Using Go's memory safety features (e.g., bounds checking, zero-initialized memory) prevented or mitigated many vulnerabilities, turning potential exploits into panics or errors.
- Go's os.Root API, introduced in Go 1.24, provides traversal-resistant file operations, helping prevent path traversal and TOCTOU vulnerabilities.
- gokrazy/rsync, a minimal reimplementation targeting protocol version 27, avoided many vulnerabilities by not implementing complex features like incremental recursion, compression, or hostname-based ACLs.
- OpenBSD's openrsync (written in C) also avoided many vulnerabilities through validation, restricted features, and defense-in-depth measures like unveil(2) and pledge(2), though it was affected by one TOCTOU issue.
- Defense-in-depth mechanisms on Linux include mount namespaces, systemd hardening, Landlock, and Go's os.Root, with os.Root offering fine-grained, per-operation security.
- Most vulnerabilities stemmed from missing or incorrect input validation, highlighting the importance of bounds checks and safe APIs.
- Complexity in software (e.g., added protocol features) introduced vulnerabilities where validation was not updated, suggesting that minimal implementations reduce attack surfaces.
- The conclusion emphasizes that structural fixes in Go (bounds checking, os.Root) and avoiding unnecessary complexity help prevent security issues, with gokrazy/rsync largely unaffected due to its minimal design and Go's features.