Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11

github.com

Post reply on HN
Print view View original

91–100 of 106 posts

Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11

#91

Post by zorgmonkey »

Gigachad wrote: post #44
candiddevmike wrote: post #35

Earlier quoted context omitted.

Is Rust memory safe if you have to use unsafe everywhere, like in the kernel?

Android makes frequent use of unsafe but in their blog post they claim an unsafe rust line has never caused a memory issue. Because they are such a small and focused selection of the code, full scrutiny can be used for any unsafe lines.

Google has actually audited using cargo-vet every crate that chromiumos and fucshia depend on that have unsafe in it. They also have some additional rules related to cryptographic algorithms. I'm pretty surprised they haven't done the same for rust usage in android. https://github.com/google/rust-crate-audits

Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11

#92

Post by almatabata »

bawolff wrote: post #68
gulbanana wrote: post #29

Earlier quoted context omitted.

Both of those things are true. Many CVEs are unimportant, but serious security vulnerabilities do exist, and are very hard to avoid entirely when writing C.

And as much as c sucks, very serious vulns still exist even when using memory safe languages. There is no magic way to prevent all security issues.

Even memory safe languages do not technically eliminate all memory issues but they significantly reduce the amount of code you need to audit for memory issues.

You have no magical way of removing all memory security issues but you can definitely reduce the chance of one occurring by picking one of those memory safe languages.

The less time you have to spend on checking every piece of code memory allocations the more time you can spend on checking business logic for logical errors.

Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11

#93

Post by mschuster91 »

hhh wrote: post #75
nerdponx wrote: post #33

Earlier quoted context omitted.

Including mine once the security team sees the CVE warning, even though our image literally never uses curl or libcurl and only ever communicates with other internal systems, within our private network. Not that we shouldn't patch it! But unless the nasal demons are going to start a process and make unwanted HTTP connections, I'm not worried.

Why do you include it if it’s unused?

A lot of stuff depends on cURL/libcurl. IIRC, php these days has it enabled by default.

Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11

#94

Post by alkonaut »

exploderate wrote: post #77
alkonaut wrote: post #54

Place your bets: a) logic bug b) memory bug (buffer overrun/use after free/etc) c) other

Or 1) SSL 2) HTTP/3 3) Other (DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP)

b) and 2) is my bet.

Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11

#95

Post by Fatnino »

alkonaut wrote: post #56
ZiiS wrote: post #2

Ouch! Percentage of internet of things devices who don't ship libcurl is a rounding error. Percentage of internet of things devices that patch libcurl is also a rounding error.

But what does a “typical” attack on a libcurl vuln look like? Unlike a server process attack, wouldn’t curl be required to be directed to the attacker’s malicious content? So the vulnerable systems are those where an attacker can craft an endpoint where curl downloads data? Isn’t the lucky circumstance here that most systems with libcurl don’t use it and among those who do, an even tinier subset will allow an attacke…

Maybe it's a bug in how curl checks certificates.

So a victim behind a hostile AP might be redirected to a malicious site masquerading as a known legit site and when the bad site presents a maliciously crafted bogus certificate curl doesn't notice.

Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11

#96

Post by dzhiurgis »

fer wrote: post #89
technion wrote: post #22

Earlier quoted context omitted.

For the most part it's not common to be able to make a server call curl with an arbitrary server which is usually required to exploit this sort of thing. There will be some vulnerable apps, but the vast majority of servers with this vulnerability present won't be exploitable in any practical sense.

Sure. Or you can get an RCE on a car[0] after some bitsquatting[1]. [0] https://daniel.haxx.se/blog/2018/02/16/why-is-your-email-in-... [1] https://en.wikipedia.org/wiki/Bitsquatting

Cars entertainment system, not car itself

Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11

#97

Post by SheinhardtWigCo »

RcouF1uZ4gsC wrote: post #71
crote wrote: post #49

Earlier quoted context omitted.

No. At the moment, there is (most likely) no exploit available in the wild. A fix for the vulnerability is basically going to be the blueprint for an exploit. This means an exploit is pretty much guaranteed to start circulating within hours of the vulnerability & fix being released. A fix cannot immediately be applied to billions of machines. It takes time for distros to port the fixes and backport it to all the vers…

> On the other hand, by giving a pre-warning to the general public and coordinating the fix with distro maintainers in a closed mailing list, anyone who even remotely cares will be scheduling maintenance windows right when the deadline expires - and patches will be ready for immediate use. It seems that one of the most productive positions for an intelligence agency to infiltrate is a distro maintainer. They don’t ev…

Or infiltrate the telecom company and read all of the mailing lists. :)

Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11

#98

Post by alkonaut »

Fatnino wrote: post #95
alkonaut wrote: post #56

Earlier quoted context omitted.

But what does a “typical” attack on a libcurl vuln look like? Unlike a server process attack, wouldn’t curl be required to be directed to the attacker’s malicious content? So the vulnerable systems are those where an attacker can craft an endpoint where curl downloads data? Isn’t the lucky circumstance here that most systems with libcurl don’t use it and among those who do, an even tinier subset will allow an attacke…

Maybe it's a bug in how curl checks certificates. So a victim behind a hostile AP might be redirected to a malicious site masquerading as a known legit site and when the bad site presents a maliciously crafted bogus certificate curl doesn't notice.

True, there are probably ways that could make this more severe if it's related to that kind of thing. And it would need to be on that level to come close to an attack of the kind that the log4j debacle was.

Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11

#99

Post by dralley »

TeMPOraL wrote: post #82
ZiiS wrote: post #2

Ouch! Percentage of internet of things devices who don't ship libcurl is a rounding error. Percentage of internet of things devices that patch libcurl is also a rounding error.

Silver lining: perhaps this will be exploitable for the purpose of jailbreaking and de-cloudifying various mobile hardware and IoT devices, which would otherwise become (or already are) expensive paperweights.

Instead, the average device will just be an expensive cryptominer for Russian cybercriminals /s

Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11

#100

Post by novok »

sneak wrote: post #48
hsbauauvhabzb wrote: post #30

Earlier quoted context omitted.

I’m gonna start referring to these types of comments as ‘drive by rust evangelists’ Go write your own memory safe curl if one _actual_ vuln in 10 years is not within your risk appetite.

Forget about Rust, and forget about drive-bys. Why hasn't Apple rewritten libtiff, libpng, libjpeg, libwebp, et c in Swift? Their flagship moneymaker keeps getting popped via these, and they have thousands of engineers and a memory safe first party language. The zeroclick from a few weeks ago relied on a chain, the second most important of which (CVE-2023-41064) was in libwebp. (The first most important was a kernel…

Swift is probably not quite good enough for that type of library actually. There was a lot of hype about it being an everything language, but I'm not sure if it actually is for a low level graphics decoding library. For example, a core internal library of SwiftUI is written in C++, ActionGraph, and that is a pretty new thing!

Also apple can be slow to write things in new coding languages internally, there is a lot of stuff still in Objective-C and will be for many, many years.

Post reply on HN