This week, Jonathan Bennett and Randal Schwartz chat with Daniel Stenberg about curl! How many curl installs are there?! What’s the deal with CVEs? How has curl managed to not break its ABI for 18 years straight? And how did Daniel turn all this into a career instead of just a hobby? Watch to find out!
Continue reading “FLOSS Weekly Episode 808: Curl – Gotta Download ’em All”
What can you do with a cheap Linux machine with limited flash and only a single free GPIO line? Probably not much, but sometimes, just getting root to prove you can is the main goal of a project. If that happens to lead somewhere useful, well, that’s just icing on the cake.
Like many interesting stories, this one starts on AliExpress, where [Easton] spied some low-cost WiFi repeaters, the ones that plug directly into the wall and extend your wireless network another few meters or so. Unable to resist the siren song, a few of these dongles showed up in the mailbox, ripe for the hacking. Spoiler alert: although the attempt on the first device had some success by getting a console session through the UART port and resetting the root password, [Easton] ended up bricking the repeater while trying to install an OpenWRT image.
The second attempt, this time on a different but similar device, proved more fruitful. The rudimentary web UI provided no easy path in, although it did a pretty good job enumerating the hardware [Easton] was working with. With the UART route only likely to provide temptation to brick this one too, [Easton] turned to a security advisory about a vulnerability that allows remote code execution through a specially crafted SSID. That means getting root on these dongles is as simple as a curl command — no hardware hacks needed!
As for what to do with a bunch of little plug-in Linux boxes with WiFi, we’ll leave that up to your imagination. We like [Easton]’s idea of running something like Pi-Hole on them; maybe Home Assistant would be possible, but these are pretty resource-constrained machines. Still, the lessons learned here are valuable, and at this price point, let the games begin.
Sometimes, it pays to read the man pages of commands you use often. There might be a gem hidden in there that you don’t know about. Case in point: I’ve used curl (technically, cURL, but I’m going to stick with curl) many times to grab data from some website or otherwise make a web request. But what happens if you want to do the same thing from a C program? Well, you could be lazy and just spawn a copy of curl. But it turns out curl has a trick up its sleeve that can help you. If only I’d read the man page sooner!
The simplest use of curl is to just name a URL on the command line. For example, consider this session:
$ curl http://www.hackaday.com <html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx</center> </body> </html>
This isn’t so useful because it is a 301 response (to send you to the https server, in this case). The -L option will make curl go get the page instead of the redirect. Try:
$ curl -L http://www.hackaday.com
Curl gave us all a big warning that a severe security problem had been found in that code-base. Given the staggering number of Curl installs around the world, we held our collective breath and waited for the bombshell to drop this Wednesday. It turns out, it’s not quite as bad as feared — so long as you don’t have a SOCKS proxy.
In hindsight, shipping a heap overflow in code installed in over twenty billion instances is not an experience I would recommend. — Daniel Stenberg
The trouble started when the SOCKS5 proxy support was converted to a non-blocking implementation. It’s a win for libcurl to work on requests asynchronously, but refactoring code and new features always runs a bit of risk. SOCKS5 proxying has some quirks, like allowing DNS resolution to happen locally or at the proxy. The new async code starts out with:
bool socks5_resolve_local =
(proxytype == CURLPROXY_SOCKS5) ? TRUE : FALSE;
First off, unnecessary ternary is unnecessary. But note that this local variable gets set by the proxytype. If that’s CURLPROXY_SOCKS5_HOSTNAME, then it uses remote resolution. But inherited from old code is a check for a hostname that is too long for a SOCKS request (255 bytes). This code converts back to local resolution in this case.
The important detail here is that this function is now a state machine, that potentially runs multiple times for a single request, to achieve that asynchronous execution. The check for a too-long hostname only happens during the initialization state. Copying the hostname into the buffer happens in a different state. If setting up the connection takes enough time, the function will return and be executed again when something has changed. The ternary check runs again, but not the hostname-too-long. So if set to do remote resolution with a long enough host name, execution slips through this edge case, and the long hostname is copied into a too-small buffer.
It’s safe to assume that this heap overflow can result in arbitrary code execution. The fix has landed in 8.4.0, after being present for 1,315 days. [Daniel] goes ahead and gets ahead of the inevitable suggestion that Curl should be written in rust or another memory-safe language. Curl was started before those alternatives existed, and there is a very slow effort to move portions of the project to memory-safe languages. And you’re welcome to help out. Continue reading “This Week In Security: Curl Reveal, Rapid Reset DDoS, And Libcue”
There are a huge number of products available in the modern world that come with network connectivity now, when perhaps they might be better off with out it. Kitchen appliances like refrigerators are the classic example, but things like lightbulbs, toys, thermostats, and door locks can all be found with some sort of Internet connectivity. Perhaps for the worse, too, if the security of these devices isn’t taken seriously, as they can all be vectors for attacks. Even things like this Rigol oscilloscope and its companion web app can be targets.
The vulnerability for this oscilloscope starts with an analysis of the firmware, which includes the web control application. To prevent potentially bricking a real oscilloscope, this firmware was emulated using QEMU. The vulnerability exists in the part of the code which involves changing the password, where an attacker can bypass authentication by injecting commands into the password fields. In the end, the only thing that needs to be done to gain arbitrary code execution on the oscilloscope is to issue a curl command directed at the oscilloscope.
In the end, [Maunel] suggests not connecting this oscilloscope to the Internet at all. He has informed the producer about it but as of this writing there has not been a resolution. It does, however, demonstrate the vulnerabilities that can be present in network-connected devices where the developers of the software haven’t gone to the lengths required to properly secure them for use with the modern Internet. Even things not connected to a traditional Internet connection can be targets for attacks.
With millions of phishing attempts happening daily, we’ve probably all had our fair share of coming across one. For the trained or naturally suspicious eye, it’s usually easy to spot them — maybe get a good chuckle out of the ridiculously bad ones along the way — and simply ignore them. Unfortunately, they wouldn’t exist if they weren’t successful enough in the big picture, so it might be a good idea to inform the targeted service about the attempt, in hopes they will notify users to act with caution. And then there’s [Christian Haschek], who decided to have some fun and trying to render the phished data useless by simply flooding it with garbage.
After his wife received a text message from “their bank”, [Christian] took a closer look at the URL it was pointing to, and found your typical copy of the real login form at a slightly misspelled address. As the usual goal is to steal the victim’s credentials, he simply wrote a shell script that sends random generated account numbers and PINs for all eternity via cURL, potentially lowering any value the attackers could get from their attempt.
As the form fields limit the input length of the account number and PIN, he eventually wondered if the server side will do the same, or whether it would crash if longer data is sent to it. Sadly, he’ll never know, because after he modified the script, the site itself returned a 404 and had disappeared.
In the quest against phishing attacks, this should count as a success, but as [Christian] seemed to enjoy himself, he yearned for more and decided to take a look at a similar attempt he saw mentioned earlier on Reddit. Despite targeting the same bank, the server-side implementation was more sophisticated, hinting at a different attack, and he definitely got his money worth this time — but we don’t want to give it all away here.
Rest assured, [Christian Haschek] continues the good fight, whether by annoying attackers as he did with ZIP-bombing random WordPress login attempts or battling child pornography with a Raspberry Pi cluster. Well, unless he’s busy hunting down an unidentified device hooked up in his own network.
(Banner image by Tumisu)
Do you happen to remember a browser-based game “You Can’t JavaScript Under Pressure”? It presented coding tasks of ever-increasing difficulty and challenged the player to complete them as quickly as possible. Inspired by that game, [Ben Cox] re-implemented it as You Can’t cURL Under Pressure!
In it, the user is challenged in their knowledge of how to use the ubiquitous curl in a variety of different ways. Perhaps this doesn’t sound terribly daunting, especially if your knowledge of curl is limited to knowing it is a command-line tool to fetch something from a web server. But curl has a staggering number of features. The man page is over 4500 lines in length. The software’s main site offers a (free) 250+ page guide on how to use curl and libcurl. Reflecting on this is exactly what led [Ben] to create his challenge.
It’s a wonderful piece of work, but things get really interesting once [Ben] starts talking about the infrastructure behind it all. At its core the game works by giving the user a problem and a virtual machine, and catching outgoing HTTP calls to see whether they look correct. If the outgoing HTTP call is the right solution for the problem, terminate the current VM and start up the next one with the next problem. He’s put a lot of work into getting suitable VMs up and running quickly, securely, and properly isolated. The code can be found on the project’s GitHub repository for those who want a closer look.
But that’s not all. [Ben] says that in the past he’s had a bad habit of presenting interactive features in his blog posts that can’t keep up with sudden demand. So to address that, the system auto-scales as needed with a small Linux cluster; small brick-sized PCs are started and shut down automatically to meet demand. Hey, the only thing cooler than a functioning cluster is a cluster doing an actual job, like this one that detects NSFW images.
