Coming up this week on Breaking Badness: Knit and Curl, HTTP/2 Electric Boogaloo, and Gold, Guidance, and Grievances.
Here are a few highlights from each article we discussed:
Knit and Curl
- curl 8.4.0 was released to patch and release details on what was considered a hyped up high-severity security vulnerability, easing concerns regarding severity
- What is curl?
- curl is a really old utility by technology standards, dating back to 1998! It’s used in command lines or scripts to transfer data from websites and other web-based resources
- But it’s not just Linux geeks hunched over clicky keyboards using it: curl is also used in cars, television sets (UGGH), routers, printers, audio equipment, mobile phones, tablets, medical devices, set-top boxes, computer games, media players and is the Internet transfer engine for thousands of software applications in over twenty billion installations, according to its maintainer
- So whether you realized it or not, curl is used daily by you and virtually every Internet-using human on the globe. It was likely used in the process by which you got this here podcast
- What are the two vulnerabilities in question and the concerns surrounding the severity?
- This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake. SOCKS5 is also a pretty old utility, allowing sort of VPN-like proxy connections from a client to a server through a firewall
- So the proxy can allow any kind of IP traffic over this connection which is often called a “tunnel.”
- So now on to the vulnerability itself: when curl is asked to pass along the hostname to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that hostname can be is 255 bytes
- If the hostname is detected to be longer than 255 bytes, curl switches to local name resolving and instead passes on the resolved address only to the proxy. Due to a bug, the local variable that means “let the host resolve the name” could get the wrong value during a slow SOCKS5 handshake, and contrary to the intention, copy the too long hostname to the target buffer instead of copying just the resolved address there
- And as some listeners might know, buffer overflows are one of the real fundamental kinds of vulnerabilities—you’re placing data into memory in an unauthorized or unexpected way, and these overflows are exploitable in a variety of ways, up to and including arbitrary code execution on the target device
- For an overflow to happen it needs a slow enough SOCKS5 handshake to trigger the local variable bug, and the client using a hostname longer than the download buffer. Perhaps with a malicious HTTPS server doing a redirect to a specially crafted URL
- Importantly, the maintainer says that typical server latency is likely “slow” enough to trigger this bug without an attacker needing to influence it by DoS or SOCKS server control
- Now here’s why this thing might not be as bad as it initially looked: While it’s fairly easy to exploit, researchers so far have found that the existing proof-of-concept exploits only cause curl to crash, leading to a denial of service attack rather than to code execution. An annoyance for sure but not the end of the world
- But also, as most people using curl are not connecting through SOCKS5, the bug would not affect them. 20 years ago, SOCKS proxies were used extensively but there are a lot of other mechanisms that are in technology stacks. Curl itself—yes, used tons. SOCKS5, not so much
- This vulnerability is useful in targeting cybersecurity researchers and developers
- When we mentioned that most people using curl aren’t using SOCKS proxies, that was true—because most people aren’t security researchers. But that esteemed population does in fact use SOCKS somewhat often, especially for hitting APIs for various kinds of testing and debugging and explorations of various kinds
- On Wednesday, October 11, curl 8.4.0 was released and things were not as bad as predicted
- Security researchers are the ones who saw it, so it’s natural that they had a strong reaction to this—we think that’s why it blew up so much on infosec Twitter, by which we do not mean that “x” thing but rather the ethereal concept of an online community of security nerds who care about this kind of thing
- We think everyone kind of took a beat and realized that key point from earlier—that the whole world isn’t using SOCKS proxies the way that security researchers are. So yes, they themselves might make decent targets of this thing—except that now there’s a patch as you noted, and there’s a lot of awareness of it, given that it looked for a minute there like a Big Deal
- What does this say about reporting vulnerabilities such as these? Was too much fear, uncertainty, and doubt shared?
- Given that we don’t see a huge amount of sky-is-falling overhype from the security community, at least in my experience, we feel like the occasional overshoot is a relatively small price to pay for the awareness that the community provides on the regular
HTTP/2 Electric Boogaloo
- More than 8 years after the adoption of HTTP/2, DDoSers devised a rapid reset attack.
- Backing up further, there’s HTTP/1 powering connections around the world since 1989
- HTTP/2 is a rework of that spec – there’s a really good blog from AWS on this – designing a protocol to handle more connections and do a lot more with the Internet writ large
- What they ended up with was the ability to run a bunch of streams at layer 4
- It turns out they might have forgotten to close those streams, and the spec is written this way so there are some servers that adhere to that spec and therefore, they are vulnerable to this, and other servers are able to handle this DDoS attempt a little better
- The folks out in DDoS land have discovered you can open a bunch of streams all at once and if they aren’t closed, you can ask over and over again and create a lot of noise from just a few hosts
- Just stuffing connections with a lot of bits or you can request things at layer 4 for a lot of packets
- There are multiple kinds of DDoS attacks
- One is to stuff a ton of requests and the other is to flood with IPs
- Need a volume of machines to drive those attacks
- This particular attack is more impressive because it’s a newer implementation of a DDoS
- Because the spec didn’t force folks to think about this, some of them didn’t
- Some of the folks who left specs open drive more traffic around the Internet
- There were a lot of folks working behind the scenes to mitigate this to try not to bother users
- Who are these attackers targeting?
- They’ll go with whoever is vulnerable and go from there
- They did manage to knock some stuff off for a period of time
- The Internet Engineering Task Force (IETF) wasn’t included in this article
- Taylor thinks there will be a meeting and this has definitely caught their attention
- There will be a longtail to this that will take a while to play out
This Week’s Hoodie/Goodie Scale
Knit and Curl
[Taylor]: 1/10 Hoodies
[Tim]: 1/10 Hoodies
HTTP/2 Electric Boogaloo
[Taylor]: 5.55/10 Hoodies
[Tim]: 4/10 Hoodies
That’s about all we have for this week, you can find us on Twitter @domaintools, all of the articles mentioned in our podcast will always be included on our podcast recap. Catch us Wednesdays at 9 AM Pacific time when we publish our next podcast and blog.
*A special thanks to John Roderick for our incredible podcast music!
