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

71–80 of 106 posts

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

#71

Post by RcouF1uZ4gsC »

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…

> 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 ever have to do anything suspicious, just do a great job maintaining the distro and just give access to the intelligence agency of all these vulnerabilities under embargo.

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

#74

Post by anonymous_sorry »

KronisLV wrote: post #10
Gigachad wrote: post #8

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

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.

Kernels and device drivers have to read and write from hardware registers. Doing so is fundamentally "unsafe", by Rust's definition. Hardware is a big bag of external state which can often be mutated external to any software running on the CPU. It's a device driver's job to abstract away this unsafe interface and (ideally) try to present a safe one.

That's not to say there aren't benefits to using languages other than C for this stuff. But a Rust kernel will necessarily rely on `unsafe` blocks to do its job.

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

#75

Post by hhh »

nerdponx wrote: post #33
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.

Why do you include it if it’s unused?

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

#76

Post by rrdharan »

Cyphase wrote: post #32
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…

Agree with everything you said except possibly:

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

I’m not so sure about that. Still understand why they’re handling it this way but this is bait like a big red bullseye or rainbow with a pot of gold at the bottom …

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

#77

Post by exploderate »

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)

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

#78

Post by eigenvalue »

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…

I had the same thought. I bet the NSA has a dossier on every single one of these people around the world. If they don’t, then they should!

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

#79

Post by worksonmine »

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.

You have to consider the author of curl has recently been vocal against CVE scoring for vulnerabilities that require very specific conditions or user stupidity to trigger. For him to come out with "the one rated HIGH is probably the worst curl security flaw in a long time" most likely means it's bad.

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

#80

Post by bayindirh »

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.

I don't agree. As an admin I can cordon off systems which might be exploited until the fix is released. If there's nothing to exploit, how can you exploit it?
Post reply on HN