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

31–40 of 106 posts

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

#31

Post by tsimionescu »

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…

Actually, the approach taken by curl is the best of all worlds: they give minimal information to attackers ("there is a bug"), and they maximize the amount of people that know a critical fix will be required, with a specific date for when the fix will be there.

The more traditional way of releasing the fix and the detailed description of the vulnerability at the same time is strictly worse. It's a very slight improvement for people who monitor these news (attackers don't get to find out there is some issue they could look for), but at a massive cost to those who don't monitor these news as often (attackers know exactly how and what to exploit before they find out).

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

#32

Post by Cyphase »

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…

(The details of the following depend on the nature of the flaw/exploit.)

I think a pre-announcement gives much more advantage to the population of defenders than to the population of attackers.

Attackers can move faster than most defenders, and they only need to find one weak link. Also there are a lot more defenders with various states of readiness, and only one attacker with the resources to spray the internet with the exploit needs to find it in order for there to already be a big problem.

How much faster will attackers be able to do anything because they know it's coming? Mostly only as long as it would have taken them to hear about it.

How much faster will defenders be able to do anything because they know it's coming? They can spend the next week making a list of things that need to be done and places that they'll need to deploy updates, so that when it's available they can act immediately and efficiently.

The risk that attackers will suddenly find the flaw after years because they were told "there's a flaw in cURL" seems low.

There is a risk that the details leak to attackers in advance of the release.

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

#33

Post by nerdponx »

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.

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.

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

#34

Post by filleokus »

fer wrote: post #16
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.

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

Hmm. The worst case I can think of is if the vulnerability is exploitable before (or during) verification of TLS certificates for http(s).

That would mean that someone in a MITM position would be able to inject the payload when libcurl make requests.

But even that seems less messy than log4j? It can't possibly be as common that libcurl makes connections to arbitrary user entered urls, compared to log4j logging user entered text.

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

#35

Post by candiddevmike »

Gigachad wrote: post #12
KronisLV wrote: post #10

Earlier quoted context omitted.

I wonder whether we'll ever get to a point where the kernel, the drivers and the userland software are all written in memory safe languages, possibly with other safe mechanisms and abstractions thrown in; yet to have it become mainstream and as popular as Linux is now. Might take decades of work though and probably nobody cares enough for something like that.

Android has been replacing a lot of core components with Rust and other memory safe languages. The Asahi team built a GPU driver in Rust recently. Seems like things are moving in the right direction.

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

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

#36

Post by nickysielicki »

7373737373 wrote: post #24
Gigachad wrote: post #8

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

In this networked world, it really is a terrible language, there is no excuse for it The only authority this program should have is network access, some compute time and permission to create and write to one or more files. Nothing more. Though this is where almost all of our currently popular programming languages and operating systems are failing. They are fundamentally broken. Just on account of security, monolithi…

The issue is not that there’s no way to do this, it’s that there’s no portable way to do this.

A seccomp bpf implementation of https://man.openbsd.org/pledge.2 could go a long way.

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

#38

Post by Palmik »

rowanG077 wrote: post #28
hardware2win wrote: post #26

Earlier quoted context omitted.

I think current way is better This way admins and ppl can prepare. If you release fix and cve at the same time then race between bad actors and ppl starts

And now the race has started with admins not being able to do anything. Anyone that knows of this vulnerability has enough time for a last hurray to exploit it as much as possible.

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

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

#39

Post by theobeers »

hsbauauvhabzb wrote: post #30
Gigachad wrote: post #8

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

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.

Let’s wait and see what the vulnerability is. Maybe it doesn’t have anything to do with the pitfalls of C. But if it does, expect to read a lot more comments like this.

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

#40

Post by hsbauauvhabzb »

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…

Security engineer here and for context I manage a very small amount of servers that don’t really matter too much. Having the notice means that I see it on HN before i need to patch - that’s massively handy.

I don’t want to run updates on cron because I feel the risks may outweigh the benefits in some cases, if this extends to other implementations (php curl, etc) then I doubt vuln scanners would pick it up.

Not every company has infinite resources, and security notices are a firehouse.

Sure this gives bad actors more of a chance to tee up staff to hit this thing, but it helps the competent but under resourced blue teamers a chance too.

Edit: I upvoted you btw and would encourage others to consider this also. I think your opinion is a valid perspective and conversation provoking which iirc is the point of votes - I’d rather not see HN fall into an echo chamber hive-mind, if it’s not already too late.

Post reply on HN