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

51–60 of 106 posts

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

#51

Post by Ekaros »

tsimionescu wrote: post #42
Palmik wrote: post #38

Earlier quoted context omitted.

To anyone that knows what the vulnerability is, this announcement does not bring any new information.

I suppose it's theoretically possible someone was hoarding this as a zero-day and may decide to more actively exploit it before it gets patched. Except of course that they don't know which precise vulnerability it is.

Also what I consider is that who has insider access and how does that information leak... This fix must be known at least some members of curl developers. Will they leak it or not? Or anyone who receive it early...

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

#52

Post by hsbauauvhabzb »

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…

I’m gonna guess apple has considered the ROI on this, the negative publicity can’t be good for them but in the context of apple id somewhat agree. I consider iOS probably more secure than desktop operating systems, and it’s the Crown Jewels of my life.

Curl is maintained by a much smaller set of people, and is delivered for free.

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

#53

Post by nurettin »

lithagger wrote: post #9
Gigachad wrote: post #8

C software really needs to be used in a sandbox because this stuff is inevitable.

All software handling untrusted input should be sandboxed really. Even if curl was written in a language that prioritises memory safety, there would still be plenty of opportunity for harmful, exploitable bugs to be introduced.

This is correct (assuming the same facetiousness as the gp comment), and even extends to algorithmic oversights and hardware errors. Your threads not stepping on each other's toes and your memory boundaries being automatically checked doesn't make you invulnerable.

Please do explain the negative reception.

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

#55

Post by Joeboy »

Gigachad wrote: post #8

C software really needs to be used in a sandbox because this stuff is inevitable.

If I skimmed this[0] right, it looks like curl is moving towards rust, in a piecemeal fashion.

[0] https://daniel.haxx.se/blog/2022/02/01/curl-with-rust/

Edit: Just because it seems pertinent, I noticed the line """"50% of past curl vulnerabilities are "C mistakes"""" in the slides linked by the post above.

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

#56

Post by alkonaut »

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 attacker to point it anywhere (e.g downloads from an url the attacker decides)?

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

#57

Post by tyingq »

technion wrote: post #22
fer wrote: post #16

Earlier quoted context omitted.

I have the feeling that this is gonna be way bigger than the log4j mess.

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.

I agree at a high level, but there are spaces where it would be common. CI/CD servers as one example. Or any wordpress server.

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

#58

Post by [deleted] »

Uptrenda wrote: post #27
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…

It really is insane how much you have to tip toe around tech circles just to say anything that isn't part of the colloquial circle jerk. What you're saying is the approach any competent software company takes to managing vulnerabilities. There's zero reason to write a prior notice that there's a flaw because it would cause panic and allow opportunities to exploit the flaw (((before there's a fix.))) This is the whole…

[deleted]

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

#59

Post by lijok »

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…

We're right in the middle of a 2 week sprint to try and release our product.

Had this notice not been made, on Wednesday all sprint work would of been forced to come to a screeching halt to deal with this.

Now we have a week to notify internal stakeholders and plan accordingly.

This is exactly how it should be done.

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

#60

Post by gruturo »

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.

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 on an internet-facing service without even a WAF in front of it. But hey, that's only a 9.2. Try having this discussion with an auditor. (I don't want to lump all auditors together - I have ~12 years of collaboration with them and met some excellent ones - typically the ones we lose after a short time because they're wasted on us. And then there are those who just want to see a documented risk acceptance and will happily tolerate some criminally insecure or stupid shit).

Post reply on HN