11–20 of 32 posts
Wat. So you can only be attacked if you're using a socks5 proxy, and even then you can only be attacked by your own proxy ? Which rules out things like torsocks where you're running the proxy too. Does this really merit all of last week's antics?
cURL's own tracker had a banner stating severity High to be released October 11. It's October 11 and was already October 11 for a lot of the world 13 hours ago (as of writing) when this patch was posted. Nothing was early, nothing was leaked. EDIT: Why the downvotes? People don't like timezones or something?
https://github.com/curl/curl/discussions/12026 (2023-10-04T06:17:44Z)
Wat. So you can only be attacked if you're using a socks5 proxy, and even then you can only be attacked by your own proxy ? Which rules out things like torsocks where you're running the proxy too. Does this really merit all of last week's antics?
There are tons of shady open or semi-open proxies out there.
Earlier quoted context omitted.
There are tons of shady open or semi-open proxies out there.
There's also PAC/WPAD ( https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Proto... ). Together with some DHCP/ARP/DNS spoofing this might allow escalating from layer 2 connectivity (e.g. on a public wifi) to local root.
Edit: To answer your response, @Ao7bei3s, all great and well theoretically.. I am looking forward to being wrong, and I am eager to see what you can come up with to root or exfiltrate my MacOS with this.
Wat. So you can only be attacked if you're using a socks5 proxy, and even then you can only be attacked by your own proxy ? Which rules out things like torsocks where you're running the proxy too. Does this really merit all of last week's antics?
Earlier quoted context omitted.
There's also PAC/WPAD ( https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Proto... ). Together with some DHCP/ARP/DNS spoofing this might allow escalating from layer 2 connectivity (e.g. on a public wifi) to local root.
If you've got the ability to spoof DHCP/ARP in a corporate network, you really don't need this subpar vulnerability to do damage. That's a massive pile of big ifs for the impact - - a socks5 connection alone would instantly trigger a SOC investigation. Edit: To answer your response, @Ao7bei3s, all great and well theoretically.. I am looking forward to being wrong, and I am eager to see what you can come up with to ro…
* Buffer overflows tend to lead to remote code execution which is the most serious outcome and should always be treated as serious by default.
* libcurl is absolutely everywhere, not only in corporate networks.
* There is no such things as a trustworthy network; corporations are moving away from that model as it just doesn't work (zero trust). I can think of plenty of ways a motivated attacker might get L2 access to a corporate network if they aren't too picky about what they get access to, when and how long.
* Users can connect work devices to non-corporate networks. The generic example used to be coffee shops, now there's WFH.
* Non-corporate users matter too.
* Horizontal privilege escalation. Chaining multiple exploits into a successful attack is table stakes for modern attackers.
* It was only an example. There is a long history of people (especially those employed by companies with vulnerable products, though that's not the case here) being dismissive about exploitability and wrong about it.
If you want to critique my comment, point out that libcurl didn't actually merge libproxy which would've brought WPAD support... but my real point is that one should not dismiss a buffer overflow in libcurl.
Will people stop messing with unsafe buffers in C already? Even just using C++ with the most basic buffer/dynamic array template would have prevented this issue.
Engineering is based on trade offs. In this specific case, the answer is no, unfortunately. This does of course not absolve new or smaller projects of this critique, but let's give curl a pass on this one.