Comment by rwmj | Hacker News Reader

Comment by rwmj | Hacker News Reader

Sort of related to this (it wouldn't solve this issue, but I think it would improve overall ecosystem security & quality):

I do wish curl would split the curl backend protocols (http, ftp etc) into separate loadable modules so that we (downstream distro packagers) can reduce the total attack surface through packaging changes.

For example, we could have:

  /usr/lib/libcurl/curl-http.so
  /usr/lib/libcurl/curl-ftp.so

packaged separately as "libcurl-http" and "libcurl-ftp". Curl clients which only want HTTP would be set to depend on "libcurl-http" only, so the FTP support wouldn't even be on the system unless a package needs it.

There is a way to whitelist protocols already in curl (CURLOPT_PROTOCOLS(3)), but that requires modifying existing programs, and I think this could be used in addition.

There are lots of weird modules in curl (telnet, gopher, pop3 -- which don't get me wrong I think is great!) but they should not be a part of the default install of most Linux distros.

Do you have any evidence that this would provide security improvements besides the heuristic of reducing surface area? Have there been past exploits?

CVE-2013-0249 (in the qemu curl driver) was an exploit where the entire qemu process could be exploited because of a bug in curl's SASL driver, which could be invoked remotely by redirecting an http[s]:// URL initiated by qemu. This was fixed by changing qemu to use CURLOPT_PROTOCOLS(3) (as I detailed in my initial posting above) so that curl wouldn't try to redirect to SASL connections starting from an initial HTTP request.

IMHO it would be a lot better instead of having to change every possible curl client, to have some kind of distro-level limit on what code might be run by curl.

Of course I would still say if you're using curl, you really must use CURLOPT_PROTOCOLS or have a good excuse why not. The above change is just a backstop.

Would there still be a batteries-included curl package that some software/packages could depend on, if they don't want to worry about which protocol is supported? I'd hate for users throwing an FTP/whatever link at a tool that used to "just work" suddenly getting a "protocol not found" error.

I imagine yes you'd want a backwards compatible package that pulls in everything. Packages that require that might(?) be a red flag.

Again it's about hardening the default, not making it secure in every imaginable configuration.

It would have the added advantage of only needing load modules required for that particular command in action as well. If a module were vulnerable, it couldn’t be used as a jump point for some gadget in another module.

You can build curl without support for ftp.

Yes you're quite right that you can do this when building curl:

  ./configure --disable-ftp

But then you end up with a libcurl that can never support FTP clients. However FTP is still a useful protocol in some circumstances, perhaps very limited these days, but still used. I think that it's better to expose this through a module system reflected into the distribution packages. It makes things much more visible.

> It makes things much more visible.

In what way? Recompiling a few different binaries for various levels of usage (with/without whichever protocols needed) doesn't seem like an arduous task, especially for a distro. And the docs on how to do it from the curl project are very clear and "visible". I'm not sure how any module system would improve on this.

In fact, it seems like it would disimprove purely by virtue of not being idiomatic - compile flags are a familiar and straightforward, well-known approach.

> compile flags

they don't play nicely with os package managers like apt.

Which is another reason why dependencies shouldn't be shared

Your solution is multiple copies of libcurl all over the place, all compiled in different ways, probably different versions, and that's supposed to be more secure and maintainable?

More secure: not more, but equally. More maintainable: infinitely. This is how software is being built today in secure environments anyway, since you need to own the supply chain.

Dependencies are not actually shared that often. Here's a good post about it: https://drewdevault.com/dynlib

Reply on news.ycombinator.com