Curl 8.4 Released For Addressing A Big Security Vulnerability

[stormcrow]

Agreed, this is really niche. SOCKS proxy? Do people still use proxies?

Proxies are common in environments where the traffic is being monitored for information security purposes (ex. large corporations, governments, etc.) But this is a pretty specific set of circumstances that must all be true before the overflow is triggered. Not saying there's not any, because libcurl is used by a huge number of 3rd party software and people do silly things, but by default curl-the-tool requires passing additional arguments to make it cause the overflow + a socks proxy + a URL with more than 255 bytes. Third party tools are an unknown. (And obviously the URL can be contrived by the attacker)

[AlanTuring69]

Big shocker that it wouldn't have happened by using a memory safe language. Looking at all of the clowns who continually hate on rust because they're too old or too bad at their job to learn new programming languages.

I wonder if they are the type to complain about a new hard hat comes out that reduces risk of injury due to falling objects by 10% with literally no consequences. "If you just don't get hit then you don't have to worry!!!!!!!!!!!!!"

[wswartzendruber]

Rust is an obvious solution to several issues. But it does have some handicaps. C's advantage is that it's essentially frozen in time. You'll rarely come across code that your C compiler is too old to compile. Then different versions of your C compiler will behave relatively similarly.
Languages like C++ and Rust are a moving target. It would be difficult for an LTS solution to find a compromise between keeping up with Rust releases to allow even backported Curl patches to compile while making sure all their stable (which might be old) software still compiles.

IIRC, old Rust projects are supposed to build on new SDKs. This is why we're supposedly never going to see a Rust 2.0 or some such.

New language features that break compatibility are added via language editions. But a binary can contain object code built from multiple language editions.

[stormcrow]

Big shocker that it wouldn't have happened by using a memory safe language. Looking at all of the clowns who continually hate on rust because they're too old or too bad at their job to learn new programming languages.

I wonder if they are the type to complain about a new hard hat comes out that reduces risk of injury due to falling objects by 10% with literally no consequences. "If you just don't get hit then you don't have to worry!!!!!!!!!!!!!"

If people read the Curl team's announcement, it probably wouldn't have happened if whoever brought in the socks code had actually audited it before they did so. Instead, they did like a lot of programmers do: naively copy and pasted example code without bothering to check if it's bug free.

Yes, this wouldn't happen with Rust, Ada/SPARK, or any other memory safe language. And this is a reason why a transition to safer tooling is necessary for the industry. But it also wouldn't have happened if the programmer had done his job in the first place and actually reviewed the code. This is clearly pointed out in the CVS announcement. If this had been a programming logic error rust wouldn't have saved them.

[moltonel]

C's advantage is that it's essentially frozen in time. You'll rarely come across code that your C compiler is too old to compile.

You wish. And let's not even talk about hardware where the only available compiler is an abandoned ten year old fork of gcc.

Then different versions of your C compiler will behave relatively similarly.

Emphasis on "relatively". Between UB, differences between arches, and regressions, you need some pretty solid testing to distribute to a new hardware/os/compiler. Ever wonder why Linux distributions take months to upgrade gcc ?

Languages like C++ and Rust are a moving target. It would be difficult for an LTS solution to find a compromise between keeping up with Rust releases to allow even backported Curl patches to compile while making sure all their stable (which might be old) software still compiles.

Rust/C/C++ are all equally careful about not breaking backward compatibility, So you can upgrade your compiler to suit programs using new language features, without worrying about old programs no longer compiling.

[stormcrow]

C's advantage is that it's essentially frozen in time. You'll rarely come across code that your C compiler is too old to compile. Then different versions of your C compiler will behave relatively similarly.

This isn't true. Not even remotely. It's literally never been true for the entire history of C. I'm working through re-learning (modern -17 standard) C at this very moment and the book goes to pains to point out that C has never been frozen in time, nor do different C compilers behave the same. They have different features and object output let alone the operating system and hardware architectures they're built on top impose their own features, requirements, and limitations.

The C standard itself leaves a great deal up to implementation details. Historically, DEC C wasn't strictly compatible with Sun's C nor IBM C, while MS C will differ from LLVM & GCC. GCC and LLVM definitely implement different parts of the C standard as their code bases grow. Generally speaking, complex or idiomatic C written for GCC won't compile under Visual Studio without changes, and vice versa... and neither one are entirely compatible with Intel's C compiler either. Sure if you stick within the same compiler lineage you'll (possibly - and I mean possibly because things change - errata, deprecation, subtly altered behavior) be ok, but that same C code may not be portable to any other platform or build suite on the same platform nor different generations of the same hardware. Even when C compilers are feature complete with the same version of the standard C89, C11, etc. that doesn't mean they're strictly compatible in all ways with each other - implementation details and extensions will always be the fly in the ointment (and good luck writing performant complex code without -isms).

[stormcrow]

You wish. And let's not even talk about hardware where the only available compiler is an abandoned ten year old fork of gcc.



Emphasis on "relatively". Between UB, differences between arches, and regressions, you need some pretty solid testing to distribute to a new hardware/os/compiler. Ever wonder why Linux distributions take months to upgrade gcc ?



Rust/C/C++ are all equally careful about not breaking backward compatibility, So you can upgrade your compiler to suit programs using new language features, without worrying about old programs no longer compiling.

I'd just like to point out that just because a very old C program compiles doesn't mean it'll execute as expected even if you're using the same build chain (GCC, binutils, etc) but distant future version: eg program written for GCC 3 on a Pentium 4 CPU but you have GCC 12 on a Ryzen 5xxx. Sometimes C programs depend on implementation quirks or features in older compiler/linker versions and hardware that don't completely translate to modern expectations. They compile fine, but will crash or give unexpected results when executed because the implementation details evolved over time. That makes some degree of alteration necessary. (Agreeing and elaborating with your statement.) And to be fair, most if not all programming languages are going to have this + more problems with programs that old.

[Delgarde]

He does name Rust as the obvious rewrite language. And mentions that a partial/gradual rewrite is already kinda-sort-of very slowly happening.

That's a bit of an overstatement. Libcurl supports a number of backend variants... and one of those variants is binding to an existing Rust HTTP library. That's somewhat short of rewriting Curl itself in Rust.

[Serafean]

Quoting the blog:

Including the latest two CVEs reported for curl 8.4.0, the accumulated total says that 41% of the security vulnerabilities ever found in curl would likely not have happened should we have used a memory-safe language.

memory safety helps a lot, but is not a panacea.

[oleid]

Rust is an obvious solution to several issues. But it does have some handicaps. C's advantage is that it's essentially frozen in time. You'll rarely come across code that your C compiler is too old to compile.

Yet, lots of C code didn't work out of the box with modern compilers.

https://wiki.gentoo.org/wiki/Modern_C_porting

Languages like C++ and Rust are a moving target.

Rust promises that you can compile old code with any modern compiler. As long as your compiler is more modern than the code you won't get any problems (unless there is a regression that didn't get detected, of course. But this can happen with any compiler for any language).