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

61–70 of 106 posts

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

#61

Post by PlutoIsAPlanet »

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…

> Why hasn't Apple rewritten libtiff, libpng, libjpeg, libwebp, et c in Swift?

Because they're shared libraries which other programs have linked to.

Additionally they've had decades of work and rewriting them increases chance that it will break something.

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

#64

Post by scrpl »

jddj wrote: post #17

> Updating the shared libcurl library should be enough to fix this issue on all operating systems. > Then again there will also be countless docker (and similar) images that feature their own copies, so there will still be quite a large number of rebuilds necessary I bet. Quite a large number, yeah.

And embedded systems (cars and stuff)...

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

#65

Post by sneak »

PlutoIsAPlanet wrote: post #61
sneak wrote: post #48

Earlier quoted context omitted.

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…

> Why hasn't Apple rewritten libtiff, libpng, libjpeg, libwebp, et c in Swift? Because they're shared libraries which other programs have linked to. Additionally they've had decades of work and rewriting them increases chance that it will break something.

I'm talking about for use in Apple's first-party apps, like PassKit/Wallet, which is how the zeroclick happened recently. Apple gets to choose what codecs PassKit uses.

They also use them in Safari, AFAIK.

I'm also pretty sure most consumers of them are using them via ImageIO, which is under Apple's exclusive control.

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

#66

Post by runeks »

PlutoIsAPlanet wrote: post #61
sneak wrote: post #48

Earlier quoted context omitted.

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…

> Why hasn't Apple rewritten libtiff, libpng, libjpeg, libwebp, et c in Swift? Because they're shared libraries which other programs have linked to. Additionally they've had decades of work and rewriting them increases chance that it will break something.

> Because they're shared libraries which other programs have linked to.

It's almost always apple's own iMessage app that gets compromised; so they can use whatever library they want.

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

#68

Post by bawolff »

gulbanana wrote: post #29
foul wrote: post #18

Sad to see this just a month and a half from this post: https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve... Is the CVE system unreasonably alarmistic or is C unpredictable with flaws?

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.

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

#69

Post by SeekMeBaby »

crote wrote: post #49
Ekaros wrote: post #20

I kinda hate doing things this way... Could it be better not to just come out with somewhat alarmist take that hey we are going to release high risk vulnerability in week... And fixes to that... But instead just release new version and CVE at same time? Now is everyone trying to get ready to exploit this on 11th, or already getting most out of it if they know? And does this information really make anyone to hover the…

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…

[flagged]

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

#70

Post by bawolff »

gruturo wrote: post #60
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.

The CVE severity scores kind of make sense in absolute (Daniel's post clearly shows that this isn't always the case) but many companies have an inelastic, inflexible, unthinking approach to them which really frustrates our effort to prioritize actually relevant stuff. A CVSS 10 on a log4j library sitting unused in a folder, shipped with an app that isn't even running, should not have prio over an unauthenticated RCE…

> And then there are those who just want to see a documented risk acceptance and will happily tolerate some criminally insecure or stupid shit

The job of an auditer isn't to make you secure, its to make sure you aren't lying about implementing your security policies. If your policies are stupid, all they are going to do is ensure you follow your stupid policies.

Post reply on HN