Curl 8.4.0 released [LWN.net]

Version 8.4.0 of the curl data-transfer tool has been released, mostly in response to a relatively severe security vulnerability that can be triggered when a SOCKS5 proxy server is in use. See this blog post for details on what went wrong. "In hindsight, shipping a heap overflow in code installed in over twenty billion instances is not an experience I would recommend."

to post comments

Curl 8.4.0 released

Posted Oct 11, 2023 15:31 UTC (Wed) by kleptog (subscriber, #1183) [Link] (12 responses)

> Yes, this family of flaws would have been impossible if curl had been written in a memory-safe language instead of C, but porting curl to another language is not on the agenda.

There is some part of me wondering if at some point LLMs will become clever enough that they will be able to rewrite well-written C code into Rust. Even if it isn't perfect and requires some looping feeding the compilers errors back to fix issues, if it can do a 90% conversion that would still save a fantastic amount of work. I don't think LLMs as they are currently designed would quite work for this task, but it seems like the kind of thing they should be good at.

Curl 8.4.0 released

Posted Oct 11, 2023 16:22 UTC (Wed) by farnz (subscriber, #17727) [Link] (5 responses)

A half-way house in that direction would be an LLM that could take Rust output from C2Rust (which is horrific code, because it's currently a 1:1 translation of C to Unsafe Rust that's - at least in theory - semantically equivalent), and turn chunks of it into Safe Rust.

Curl 8.4.0 released

Posted Oct 11, 2023 22:21 UTC (Wed) by Alterego (guest, #55989) [Link] (4 responses)

Automatic translation into another language ?
Give it a try with a text, from your mother tongue to another, and translate it back...
I guess you will see that if you do that with a code, the result will probably not be more secure than the original (and probably will do something else)

Curl 8.4.0 released

Posted Oct 12, 2023 8:26 UTC (Thu) by kleptog (subscriber, #1183) [Link] (2 responses)

I'm not sure that's a good analogy. The reason natural language translation is hard is because the meanings of words are fuzzy. While "school" in Dutch and English at a dictionary level mean the same thing, at any deeper level the meaning starts to diverge rapidly because in the end they refer to a construct deeply rooted in the local culture. Even within the Anglosphere, "college" can mean completely different things depending on where you are.

Programming languages on the other hand have precise meaning. They all have the purpose of telling a computer what to do and the results can be validated automatically. And C and Rust are close enough together that I think that a straight forward translation would produce reasonable results. I would not expect a translation from C to Erlang for example to work nearly as well.

It may not be idiomatic Rust, but that's fine, it doesn't have to work in one pass. As a programmer I would rather start from a "mostly functional non-idiomatic Rust conversion" than to type the whole thing in again from scratch.

As for the security, that comes from using idiomatic Rust constructs. I wouldn't trust an LLM conversion from anything to C, though idiomatic C++ is probably pretty safe.

Curl 8.4.0 released

Posted Oct 12, 2023 14:32 UTC (Thu) by smoogen (subscriber, #97) [Link]

> The reason natural language translation is hard is because the meanings of words are fuzzy.

> Programming languages on the other hand have precise meaning.

I can say that after watching the same code work differently depending on the compiler version because the code relied on part of the language was 'undefined', 'hardware defined', 'compiler defined' or 'either interpretation is valid' says that a lot of code are additionally fuzzy, because at some point the specification was written in a natural language or the people who wrote the specification could not agree on a precise meaning.

Reading through the The CERT C Coding Standard to see where all the ways C code can go off the rails depending on the hardware has reminded me that all the times I have said that programming languages have precise meaning has been a little white lie to allow myself to sleep at night.

Curl 8.4.0 released

Posted Oct 13, 2023 9:04 UTC (Fri) by vadim (subscriber, #35271) [Link]

Languages like C are unfortunately extremely fuzzy regarding to encoding intentions.

Think something like:

do_stuff(&thing);

Does do_stuff take a pointer for performance reasons, or because do_stuff might need to modify the thing? Can do_stuff stash the pointer somewhere to do something to it later? How is 'thing' supposed to be allocated and deallocated? Is it bad to keep thing existing for too long? Is it non-const because it really can be modified, or because const'ing things was not in fashion yet? Etc, etc.

There's many such questions even the original developer might struggle to answer quickly. Some things can be reasonably guessed. Some require reading the documentation. Some might require talking to other programmers to determine whether caching things is ever a thing that might ever happen in the future even if it doesn't yet.

Curl 8.4.0 released

Posted Oct 12, 2023 10:18 UTC (Thu) by farnz (subscriber, #17727) [Link]

C2Rust does the automatic translation from C to Rust already, with the quality that you'd expect. We'd be asking the LLM to do Rust to Rust translation, where it picks up on "bad" Rust and outputs the equivalent "good" Rust, in the process turning on extra compiler features that check for security issues automatically.

Curl 8.4.0 released

Posted Oct 11, 2023 16:26 UTC (Wed) by magfr (subscriber, #16052) [Link] (1 responses)

I suspect, sadly (or luckily?) without any base for it, that the ability to rewrite it to safe anything is equivalent to the ability to rewrite it to safe C.

Curl 8.4.0 released

Posted Oct 11, 2023 17:45 UTC (Wed) by mb (subscriber, #50428) [Link]

No, not really.
The checking whether the code is *actually* safe happens in the Rust compiler, not in the LLM.

Curl 8.4.0 released

Posted Oct 11, 2023 20:17 UTC (Wed) by Depereo (guest, #104565) [Link]

A person would do a (near infinitely) better job and produce a more maintainable result.

Curl 8.4.0 released

Posted Oct 12, 2023 8:59 UTC (Thu) by opsec (subscriber, #119360) [Link]

Maybe some LLMs can exploit themselves to escape 8-)

Curl 8.4.0 released

Posted Oct 12, 2023 11:10 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

There are various checkers and dialects of C that try to compile a restricted subset of C to a memory-safe code. In practice that does not work on anything non-trivial as it requires a massive rewrite.

I think what Mozilla is doing is more productive. That is, compile C or C++ code to native with a compiler that enforces the same restrictions that WASM sandbox do. Then, at runtime, create a very lightweight sandbox and run library there.

Clearly a buffer overflow will still be overflow but the damage will be restricted to the sandbox memory and any exploit will be severely restricted. As long as the caller then checks that the output of the sandbox is sane, this gives much improved protection without the need to rewrite the library.

Curl 8.4.0 released

Posted Oct 16, 2023 15:59 UTC (Mon) by NAR (subscriber, #1313) [Link]

The problem is that you don't actually want the Rust code to do exactly the same as the C code did, because that includes the bugs in the C code as well. What you need is the specification of the C code and the AI/human coders to create Rust code from that specification.

Curl 8.4.0 released

Posted Nov 4, 2023 20:36 UTC (Sat) by acolin (subscriber, #61859) [Link]

Surprizing they accepted the IPFS "support." It amounts to rewriting ipfs://hash URLs into http://localhost:1234/ipfs/hash (a gateway process running locally).

This approach does not seem to scale. Should every application that ever accesses resources via URLs get patched to support such a rewrite? Why not just use the gateway URL directly? If this support was actually linking against some libipfs that can resolve such URLs via the p2p network, that would be valuable. But, as it is, would have never bet on this patch getting accepted.