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

41–50 of 106 posts

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

#41

Post by rowanG077 »

Palmik wrote: post #38
rowanG077 wrote: post #28

Earlier quoted context omitted.

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.

It most definitely does. You know it's going to be patched. You no longer have to tiptoe around to conceal the problem. This can be the difference between snooping a bit of data here and there and just straight up dumping the contents of entire servers.

Of course this depends on the vulnerability itself. But knowing a vulnerability will be patched can be hugely interesting and worthwhile information

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

#42

Post by tsimionescu »

Palmik wrote: post #38
rowanG077 wrote: post #28

Earlier quoted context omitted.

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.

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.

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

#43

Post by 7373737373 »

nickysielicki wrote: post #36
7373737373 wrote: post #24

Earlier quoted context omitted.

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.

That would be a good start, because it would allow one to "hollow out the attack surface" - a great concept I've encountered in the erights community. Primitives that allow one to gradually secure a system in the future when the need arises.

Though unfortunately it doesn't provide the level of expressivity and flexibility that a full capability security architecture would.

The world has a great deal to learn from the likes of KeyKOS, seL4 and Genode, i don't see any of these issues going away without their adoption (or at least their ideas, in other systems).

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

#44

Post by Gigachad »

candiddevmike wrote: post #35
Gigachad wrote: post #12

Earlier quoted context omitted.

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?

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.

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

#45

Post by croes »

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…

This only works for curl itself. But how many programs use curl or libcurl and bow many of those won't get an update?

It's good to know beforehand to check which software in your stack will be affected so you can take precautions if those don't get an update fast enough.

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

#46

Post by hsbauauvhabzb »

theobeers wrote: post #39
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.

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.

Does the root cause even matter when the ancestor poster is already blaming C?

If we’re gonna start somewhere when it comes to memory safety, I assume fixing adobe acrobat would have a better ROI.

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

#47

Post by tsimionescu »

rowanG077 wrote: post #41
Palmik wrote: post #38

Earlier quoted context omitted.

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

It most definitely does. You know it's going to be patched. You no longer have to tiptoe around to conceal the problem. This can be the difference between snooping a bit of data here and there and just straight up dumping the contents of entire servers. Of course this depends on the vulnerability itself. But knowing a vulnerability will be patched can be hugely interesting and worthwhile information

Except of course they don't know what vulnerability is getting patched. So, they might actually end up revealing a different vulnerability.

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

#48

Post by sneak »

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.

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 privilege escalation. XNU is c and cpp, of course.)

I really can't imagine that writing performant replacements for these libraries would be that daunting a task for them, and it would permanently shut down an entire class of repeated, ongoing vulnerabilities. I really don't understand why Apple relies on 3p code for format parsing/decoding when it has proven over and over again to be a source of brand damage.

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

#49

Post by crote »

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 versions they still support, it takes time for admins to notice the vulnerability at all, and it takes time to schedule a support window and apply the fix to all your machines. From initial disclosure until significant numbers have been patched can easily take days - or even weeks. During that time, people will be actively exploiting the vulnerability.

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. This significantly reduces the amount of time the vulnerability will be public without a patch being available for the general population.

It's of course a different story when it is a zero-day actively actively exploited in the wild already, but that doesn't seem to be the case here.

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

#50

Post by rowanG077 »

tsimionescu wrote: post #47
rowanG077 wrote: post #41

Earlier quoted context omitted.

It most definitely does. You know it's going to be patched. You no longer have to tiptoe around to conceal the problem. This can be the difference between snooping a bit of data here and there and just straight up dumping the contents of entire servers. Of course this depends on the vulnerability itself. But knowing a vulnerability will be patched can be hugely interesting and worthwhile information

Except of course they don't know what vulnerability is getting patched. So, they might actually end up revealing a different vulnerability.

Of course. It's a risk that could easily be worth it depending on the actor and vulnerability
Post reply on HN