3 ms·

Dhall was such a godsend to make our infra configs more safe & modular (we jointly configure Kubernetes & Terraform with it). If you need some example of use c

• deleted 8y ago
  [deleted]
• lomnakkus 8y ago
  This is great. I've been toying with the idea of using Dhall for various things and your post might just have given me the impetus to go actually do it!
• openasocket 8y ago
  RE: Dhall-Kafka pubsub Dhall seems to be safe in the sense that it will always terminate and will never crash or throw some kind of exception, but I don't think it's safe in the sense that it is safe to execute potentially malicious Dhall code, unless you restrict the allowed imports to a whitelist. At the very least that could be used to DDos some target by having the script try to import something from a victim domain. And you might be able to read data on local files and transmit that information back, I'm not sure. It depends on if imports are evaluated lazily, and the data of interest would have to be stored in a file on disk that can be imported. EDIT: Actually, it looks like you can import raw text, so it doesn't matter what format the on-disk data is that you are trying to extract. EDIT2: Actually, it doesn't even matter if imports are evaluated lazily or not, you can specify that a network import be made with given headers, so you could just set a header in the HTTP request to contain the sensitive data.
  • Gabriel439 8y ago
    Author here: You might be interested in this post on safety guarantees: https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarantees https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarant... The main risks in executing potentially malicious Dhall code that is not protected by a semantic integrity check are: * Using more computer resources than you expected (i.e. network/CPU/RAM) * Unintentional DDos (as you mentioned) * The malicious import returning a value which changes the behavior of your program If you protect the import with a semantic integrity check then the malicious import can no longer return an unexpected value, which eliminates the third issue (changing program behavior). Also, upcoming versions will cache imports based on the semantic integrity check, which would mitigate the second issue (DDos) for all but the first time you interpret the program. There is also a `dhall freeze` subcommand which takes a program and automatically pins imports to their most recent value using semantic integrity check. Regarding exfiltration, the import system guarantees that only local imports can access sensitive information such as file contents or environment variables. See: https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarantees#cross-site-scripting-xss https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarant... The only way that a remote import can obtain that information is if a local import supplied that information via Dhall's support for custom headers. In fact, this is actually an intended use of that feature (i.e. a local import fetching a Dhall expression from a private GitHub repository using an access token retrieved from an environment variable). So in other words the threat model is that as long as you can trust local imports then you can transitively trust remote imports because they cannot access your local filesystem or environment variables unless you explicitly opt into that via a local import. I think that's a reasonable threat model because if can't trust the contents of your local filesystem then you can't even trust the Dhall interpreter that you are using :) Imports are not computed and the set of imports that you retrieve is static (i.e. does not change in response to program state or input), so the set of imports or their paths cannot be used as an exfiltration vector.
    • openasocket 8y ago
      I had missed that wiki section on safety guarantees, my bad. It seems all of my proposed attacks wouldn't work. There's just one other that I thought of, and looking through your documentation I'm not sure if it would work or not. What if the host executing the script had access to some intranet site with sensitive data? Would I be able to do a network import of such a URL, load it as raw text, and provide that as a header to another import? Seriously great work on this, by the way. A total configuration language that allows some form of network access while still being secure against malicious input is a really really impressive tool!