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

DeVault: Announcing the Hare programming language

Posted May 2, 2022 13:19 UTC (Mon) by ddevault (subscriber, #99589)
In reply to: DeVault: Announcing the Hare programming language by HelloWorld
Parent article: DeVault: Announcing the Hare programming language

That's not how this works. Opportunistic improvements are part of defense in depth. It improves security to use this module, but it is not *necessary* for security to use this module.

to post comments

DeVault: Announcing the Hare programming language

Posted May 2, 2022 14:54 UTC (Mon) by farnz (subscriber, #17727) [Link]

So how do I conditionally compile Hare such that if a secure keystore isn't available, my code refuses to compile? This module isn't that, because it works cross-platform, even if there is no secure keystore available.

In effect, it's opportunistically downgrading my code if I move from a platform like Linux with a secure keystore to one without, and long experience shows that opportunistic downgrades are a really bad thing for security. An opportunistic upgrade would be if you (e.g.) detected use of the bytes::zero secure zeroing operation, and upgraded from "normal" storage to a secure keystore.

What I, as a developer doing my best to not add too many more security bugs to the world, is for my code to actively alert the next developer (which might even be me a few years later) if they are making decisions that contradict things my code assumes is true. This particular module does exactly the opposite - if I make decisions that are true assuming the keystore is secure (which is testably true on Linux), and then someone uses my code on FreeBSD (where it's not true in this version of the code), then the user who switches to FreeBSD has introduced flaws I wasn't expecting to have to handle.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 10:36 UTC (Tue) by nix (subscriber, #2304) [Link] (7 responses)

The problem with opportunistic improvements in security, as we've seen with SSL over the years, is that as soon as an attacker gets involved it becomes clear that these are really *reductions* in security because an attacker can either force the selection of the least secure option or focus only on those for whom the opportunistic improvement did not kick in (thus reducing the overall security of the library to its least secure set of features).

Now maybe you're saying most people will never be attacked so there's no point worrying about this -- but in that case why encrypt anything at all? The whole point of encrypting things is to stop attackers from reading them! Maybe you think that most attackers won't be sufficiently dedicated... but it only takes one attacker to write a tool to do whatever thing you think is difficult and suddenly it's easy and every script kiddie is doing it.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 10:38 UTC (Tue) by ddevault (subscriber, #99589) [Link] (6 responses)

I am familiar with the downgrade attacks that you are referring to, and they do not apply here. I would be very impressed if a man in the middle was able to force a victim into installing BSD instead of Linux in order to exploit some vulnerability - a separate vulnerability, to be clear, given that storing keys in the heap is not automatically a vulnerability.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 12:59 UTC (Tue) by farnz (subscriber, #17727) [Link] (4 responses)

The specific concern I have is related to a user trusting the programmer. The problem here is that the language sets me up for a fall if I do trust the programmer.

Assume I'm administrating a FreeBSD fleet; I discover a need, and find a program written in Hare that fills that need. The documentation written by the programmer asserts several security claims that are true on the assumption that a secure keystore is used, and false otherwise. Being a conscientious sysadmin, before relying on the documentation, I first compile the program and run its test suite.

Here's where the pain lies - because there's no way for a Hare programmer to fail the tests if the keystore is not actually secure (but instead heap memory), I see a full set of passes. And then I get burnt because I trusted the programmer, but the language provided no way for the programmer to tell me that, because of my system choices, my trust is misplaced.

And this applies even if the programmer is conscientious - in autotools C, for example, I'd note that keyctl is not available, and not compile in the "in memory secure" keystore, because it's not present on this platform. It'd then be obvious to the conscientious sysadmin that in memory key storage is not available on FreeBSD, and that you need another implementation (be that PKCS#11, TPMv2, Yubikey, or whatever else the programmer designed in), or that I can't trust the security claims that depend on keyctl.

If Hare wanted me to be able to trust the programmer, there would at a minimum be a way for the programmer to prevent the code relying on the key store if it's not secure. That mechanism is not present here.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:16 UTC (Tue) by ddevault (subscriber, #99589) [Link] (3 responses)

>The documentation written by the programmer asserts several security claims that are true on the assumption that a secure keystore is used, and false otherwise.

This is an error in the downstream software, not in Hare. We cannot prevent programmers from making untruthful claims about their software. And, *again*, storing secrets in the heap in the face of the lack of a kernel-managed keystore *does not directly make your program insecure*.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:40 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

It's also a bug in Hare, because it claims to be a secure keystore, but it's not on some systems. And while storing secrets in the heap does not directly make your program insecure, I'm not talking about that - I'm referring to the case where the program does things to ensure that it's secure as long as the keys are not on the heap or stack outside of the times they're used.

And again, it's trivial to fix in Hare - just an is_secure_store function that returns true on Linux, false on other platforms for now.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:43 UTC (Tue) by ddevault (subscriber, #99589) [Link] (1 responses)

Again, the "claims" it makes are, verbatim, the following:

> On platforms without a suitable feature, a fallback implementation stores the secrets in the process heap, providing no security. This is an opportunistic API which allows your program to take advantage of these features if available.

In my opinion, this is very clear.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:45 UTC (Tue) by farnz (subscriber, #17727) [Link]

And in my opinion, it's not clear at all - which platforms have secure storage? How do I tell my users that they've chosen a platform that doesn't work the way I want it to? How do I prevent use of the keystore when it's not actually secure?

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:45 UTC (Tue) by nix (subscriber, #2304) [Link]

> I would be very impressed if a man in the middle was able to force a victim into installing BSD instead of Linux in order to exploit some vulnerability

They wouldn't. They would search the set of people using whatever-it-is and filter out those running Linux, knowing that *all the rest* were storing the keys on the heap and they could use heap spraying or whatever. (For which they'd probably need another vulnerability. They're very good at chaining these things together...)