Memory safe ‘curl’ for a more secure internet
daniel.haxx.se
Memory safe ‘curl’ for a more secure internet
1–10 of 210 posts
Re: Memory safe ‘curl’ for a more secure internet
#2How often have libcurl HTTP or TLS backend bugs resulted in exploited vulnerabilities in the past?
Re: Memory safe ‘curl’ for a more secure internet
#3[deleted]
Re: Memory safe ‘curl’ for a more secure internet
#4How often have libcurl HTTP or TLS backend bugs resulted in exploited vulnerabilities in the past?
I don't have any data on exploitability, but 19 of the last 22 vulnerabilities (since 2018) have C-induced memory unsafety as a cause: https://curl.haxx.se/docs/security.html
Re: Memory safe ‘curl’ for a more secure internet
#5You can't get memory safety by picking a language with `unsafe` blocks. I appreciate the sentiment but the implementation details are important here; I'd take this more seriously if they picked something like OCaml instead of Rust.
Re: Memory safe ‘curl’ for a more secure internet
#6How often have libcurl HTTP or TLS backend bugs resulted in exploited vulnerabilities in the past?
I don't have any data on exploitability, but 19 of the last 22 vulnerabilities (since 2018) have C-induced memory unsafety as a cause: https://curl.haxx.se/docs/security.html
Oh thanks, that at least gives some idea of the potential. I see e.g. "HTTP/2 trailer out-of-bounds read" and "SSL out of buffer access"... I guess there might be some candidates.
Re: Memory safe ‘curl’ for a more secure internet
#7You can't get memory safety by picking a language with `unsafe` blocks. I appreciate the sentiment but the implementation details are important here; I'd take this more seriously if they picked something like OCaml instead of Rust.
Sure you can.
First, in a philosophical sense: pointers and x86 CPUs are real, ultimately any safe abstraction must be built on unsafe primitives. The ability and need to do that aren't specific to memory unsafety, we do that all over software engineering.
Second, empirically, my experience has been that the design of these abstractions can be safe, but moreover that the cordoning off of unsafe blocks makes 3p auditing for memory unsafety _much_ easier to do. It can be orders of magnitude faster than reviewing an entire C or C++ codebase.
Re: Memory safe ‘curl’ for a more secure internet
#8You can't get memory safety by picking a language with `unsafe` blocks. I appreciate the sentiment but the implementation details are important here; I'd take this more seriously if they picked something like OCaml instead of Rust.
A language like OCaml can still have memory unsafety issues introduced by the compiler or standard library. It just makes it much more manageable to effectively audit for and fix such issues. `unsafe` blocks serve the same purpose.
Re: Memory safe ‘curl’ for a more secure internet
#9You can't get memory safety by picking a language with `unsafe` blocks. I appreciate the sentiment but the implementation details are important here; I'd take this more seriously if they picked something like OCaml instead of Rust.
It's not all-or-nothing. Numbers do exist between 0% and 100%.
Re: Memory safe ‘curl’ for a more secure internet
#10You can't get memory safety by picking a language with `unsafe` blocks. I appreciate the sentiment but the implementation details are important here; I'd take this more seriously if they picked something like OCaml instead of Rust.
OCaml has its fair share of unsafe features, with the functions helpfully prefixed by "unsafe_". If you look through the stdlib you'll find dozens of such functions. Plus real world code uses them to do things like avoiding bounds checks. Much as I'm a fan of OCaml, even a pure OCaml implementation could do unsafe things.