DeVault: Announcing the Hare programming language [LWN.net]

DeVault: Announcing the Hare programming language

Posted May 4, 2022 10:23 UTC (Wed) by ilammy (subscriber, #145312)
In reply to: DeVault: Announcing the Hare programming language by wtarreau
Parent article: DeVault: Announcing the Hare programming language

I never said one should ignore updates in the dependencies, or that there can never be security vulnerabilities in libraries written in memory-safe languages. Please stop dealing in absolutes.

Of course, vulnerabilities are not limited to RCE caused by undefined behavior due to memory safety issues. Just about any library parsing anything might have an implementation bug which can causes a DoS, which is a vulnerability too. Just about any “big” library might be having some obscure feature that indirectly calls into shell. But that’s hardly on the same scale of impact as, say, heartbleed – not of the “drop everything and patch your software yesterday” scale. Nor it has the same occurrence and memory-safety-related bugs in non-memory-safe libraries.

Look at zlib, for example. Here are some stats for zlib-related CVEs published since 2019:

in zlib:
  3 missing bounds check (CVE-2018-25032, CVE-2021-26025, CVE-2018-20819)
  1 double free (CVE-2019-12874)
  1 unbounded memory allocation (CVE-2020-11612)

in zlib usage:
  2 DLL hijack (CVE-2021-26807, CVE-2020-11081)

(Speaking of which, shared libraries themselves open up possibilities for attacks, like DLL hijacking.)

Using shared libraries does not magically free you from keeping track of your dependencies that might wreck havoc, or from maintaining your systems. The purported argument for shared libraries is that “distro maintainers” (= people who are not us) are going to take care of the updates, so that we don’t have to rebuild and update our applications. But who’s going to install these updates to shared libraries? Who is going to restart affected services? Who is going to figure out which systems need an update? When all these details are considered, the static/shared choice is so minuscule that it’s hardly important.

I believe the main benefit of shared libraries currently is that you don’t have to deal with whatever obscure build system is used by the dependency. Because chances are, if it’s distributed as a shared library – not in source-only form, already integrated in your application – then the library does need a “build system” in the first place.

to post comments

DeVault: Announcing the Hare programming language

Posted May 4, 2022 12:16 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (2 responses)

> who’s going to install these updates to shared libraries? Who is going to restart affected services? Who is going to figure out which systems need an update?

There is an amazing tool called "apt-get" that does all of those things.

DeVault: Announcing the Hare programming language

Posted May 4, 2022 12:41 UTC (Wed) by ilammy (subscriber, #145312) [Link] (1 responses)

That’s the point. Replacing binaries is only a part of the problem.

APT is not going to get my system have up-to-date repositories that I trust configured all by itself, someone has to administer that configuration.

APT is not going to package my software all by itself, someone has to write all that Debian packaging, telling dpkg that ”my-app.service” is from “my-app” package which depends on “libssl” and needs to be restarted when its dependencies are updated.

APT is not going to decide for me which instance need an update, which instances are safe to update and in what sequence. Someone has to define that, then orchestrate actual update, juggle the load, etc.

APT is not going to test the update for me before it’s deployed. Someone has to try it out first in a safe environment.

Sure, there are automated tools for switching over one binary for another, sending signals, waiting on pipes, etc. But that specific part is just a small fraction of what “update” entails. And those tools do not really care whether they have to replace “libvulnerable.so” or statically linked “vulnerable-executable”.

DeVault: Announcing the Hare programming language

Posted May 5, 2022 9:33 UTC (Thu) by pabs (subscriber, #43278) [Link]

There is needrestart (and needrestart-session) for automatically restarting services after shared library upgrades (and Perl/Python/etc modules). It works fairly well, the main issue right now is cgroupsv2 breaks things a little bit.

https://github.com/liske/needrestart
https://github.com/liske/needrestart-session
https://github.com/liske/needrestart/issues/235

DeVault: Announcing the Hare programming language

Posted May 4, 2022 13:31 UTC (Wed) by wtarreau (subscriber, #51152) [Link] (1 responses)

> The purported argument for shared libraries is that “distro maintainers” (= people who are not us) are going to take care of the updates, so that we don’t have to rebuild and update our applications. But who’s going to install these updates to shared libraries?

No that's not the main point. The main point is that you can limit the amount of stuff you have to replace. When you upgrade your libc to get rid of the ghost vulnerability, all your executables are fixed at once. When they're all static, you have to replace all your executables with the ones the distro vendor had nicely rebuilt for you. And that can take quite some time when there are lots of packages, up to several days for mainstream distros, which will significantly delay the deployment of the fix in field. In addition it means that when there are multiple vendors (local builts counting as a "vendor" as well), it then becomes extremely difficult to make sure the system is fixed.

But fixes deployment is an entire class of problems on its own, there's no single nor excellent solution, there are pros and cons everywhere. Shared libs come with a number of cons but none of them is dramatic, and a number of pros that can keep you out of the mud. Static libs tend to navigate between much worse and much better, and will occasionally leave you a bad feeling.

DeVault: Announcing the Hare programming language

Posted May 4, 2022 15:11 UTC (Wed) by farnz (subscriber, #17727) [Link]

It's a trade-off. Shared linking forces you to consider backwards and forwards compatibility in your ABI, where static linking permits you to get away with only caring about API.

Static linking also enables library consumers to simply test for the behaviour they expect; with shared linking, you need to be confident that the set of library behaviour you depend upon is by design, and not a happy accident. If you don't take the ABI contracts seriously (on either side of the ABI), then you get broken by mistake as an implementation detail you happened to care about changes.

Tooling to help get this right sort-of exists (abidiff for example), but it's more than just the things that can be checked by tooling that matter - for example, if I change a library so that you now need to call mylib_free on a pointer I returned, where previously free worked, you're going to be surprised.