curl vulnerabilities ironed out with patches after week-long tease

After a week of rampant speculation about the nature of the security issues in curl, the latest version of the command line transfer tool was finally released today. Described by curl project founder and lead developer Daniel Stenberg as "probably the worst curl security flaw in a long time," the patches address two separate …

[b0llchit]

From RCE to DOS

...the flaws found in curl would not have existed had it been written in a more memory-safe language...

Instead, the logic errors would probably translate in denial of service problems.

A memory error is, of course, serious and problematic, but the cause is due to a logic error in the code. Like, I expected 3 but got 4. Rewriting the code in another language may very well fence off the class of memory errors. However, the logic error now translates into an exceptional state that needs to be handled. And how do you handle an error you didn't account for? Well, you can be lucky and somehow terminate or you can end in an endless loop. And that is a clear opening to a denial of service. One can argue that DOS is not as bad as RCE, but when it overflows/deletes your data stores, then you would not be happy either.

[Paul Crawford]

Hopefully analysis tools will be updated to spot this particular memory-trashing bug.

And yes, ideally we would not be using low-level languages for so many things and making such bugs easy to create, but unless someone invents a magic tool that will safely and reliably migrate complex existing C/C++ projects to a memory-save version such re-wires just ain't happening.

[Dan 55]

A lot of bother could be avoided with the right build environment - all the warnings are errors unless for a very good reason, all the sanitisers on, as many static analysers as you can find.

[SCP]

Static Code Analysis

We repeatedly run several static code analyzers on the code and none of them have spotted any problems in this function.

It would be interesting to know more about which static analyzers were being used - in particular whether there were any that use techniques like proofs or Abstract Interpretation. Or were these mainly style/convention based analyzers.

[Roland6]

Re: Static Code Analysis

However, the tools are only as good as the test cases:

” "It could have been detected with a better set of tests.”

Which suggests insufficient attention was paid to the definition of tests.

[hammarbtyp]

Re: Static Code Analysis

Problem with static code analyzers is that it can lull developers into a false sense of security and less attention is paid to good development practices like code reviews, unit tests etc.

Static code analyzers are great, but they often only catch the low hanging fruit, but they can seem like a magic bullet to those with less experience

[SCP]

Re: Static Code Analysis

Static code analyzers are great, but they often only catch the low hanging fruit, ...

This is a reason why the type of static analysis tool used is of interest - there are those that do deep semantic analysis and can detect deeply hidden defects.

A reasonable amount of good can be achieved with some of the more basic static analyzers (many of the usual mistakes made during design/implementation are of the fairly obvious type) and testing can itself be a mixed bag - it is often tricky to detect deep faults effectively (hence the advocates for automated fuzz testing to subject software to a wide combination of inputs).

You can't test/analyze in correctness, just detect mistakes and get them taken out (which itself can be problematic). This is why high integrity software requires the use of properly defined requirements (another problem in its own right), sound design methodologies, reliable implementation processes, and robust verification and validation.

[Roger Kynaston]

curling

Do the developers have a couple of assistants vigorously brushing the floor as their desks slide down the office? Enquiring minds wish to know.

[bazza]

Security Overblown?

Well, remote code execution is a pretty bad thing, even if someone has to "contrive" the circumstances to make it work. If an attacker wanted to get code execution on your system, they'd be doing their best to contrive the right circumstances, sure enough.

[Anonymous Coward]

Re: Security Overblown?

Forcing you to install and use a SOCKS5 proxy goes beyond "contrive" IMO.

[sabroni]

re: Stenberg admitted that the flaws found in curl...

...would not have existed had it been written in a more memory-safe language instead of C, but confirmed there were no plans to make such a switch.

What is it called when you keep repeating the same actions expecting a different outcome?

[Lee D]

Re: re: Stenberg admitted that the flaws found in curl...

As it says later on - if you want to volunteer, get on it.

The use-cases and options in something like curl mean you could easily spend several years trying to get there, and not be able to keep up with curl changes in the meantime.

Also, Rust, etc. are not panaceas and CANNOT act on untrusted data safely either. That's why you have unsafe(), etc. which is literally as bad as C but also can affect guarantees of "safe" Rust code near it in memory if they should fail or miscalculate.

When something is literally designed to act on untrusted data from the Internet, the number of sanity checks you would need are ... well... insane. And Rust etc. can't always fix those kinds of problems, or even deal with them at all.

It's why Rust is no good for device drivers, low-level kernel, memory management code, etc. - at some point in those tasks they have to act on untrusted data without a "type" and then form a well-specified type out of it in an error-free manner in order to be able to use it (e.g. DMA just gives you a memory address where the hardware is putting stuff). Those kinds of things require unsafe() code blocks in order to do, and unsafe is just as dangerous as C but with a false sense of security about surrounding Rust code built-in to it.

Sure, there's a lot that you can make safe in myriad ways, but you can also make it safe by using a safer version of C/C++ with a compiler that throws a fit at everything. And that's a far more viable outcome for a volunteer project than throwing out 30 years of development and starting again in a bug-free manner.

[SCP]

Re: re: Stenberg admitted that the flaws found in curl...

A point about languages that use constructs like unsafe() is that the construct acts as a red flag that should attract special attention during code reviews (or lead to extra caution when maintaining/altering the code). Of course they should be used judiciously rather than sprinkled around like confetti - every use of unsafe() should be justified in the design notes.

[Daniel Pfeiffer]

Why the constant free ads for TwitteX?

By using every occasion to ramble on about how they have two facesnames, you're giving that unsocial media brand too much attention! If they want to be X-ed out, then so be it! And if readers then don't understand what the X you're writing about, that would be a feature.

[Roland6]

Re: Why the constant free ads for TwitteX?

Someone at “X” was exceedingly smart or Musk just got lucky. I note instead of saying “Twitter” the BBC et al now say “ X, formerly known as Twitter,” and thus helping Musk in his rebrand. Personally, I would just continue to refer to it as “the social media widely known as Twitter” and if deemed necessary footnote the new name.

[Anonymous Coward]

So it's basically Tor users who are vulnerable

and only then in highly specific circumstances, because mainstream browsers don't use libcurl for normal page fetching (I think Mozilla uses it but only for crash reports).

And I for one don't have random files called "none" with cookies in them sitting around in my home directory either.

Yes I'm glad it's fixed, but I don't think very many people will need to panic about this