4 ms·

Elixir, which runs on the Beam VM, had piqued my interest for a while, so finally set out to learn about it this weekend. On searching for "flaws" of the langua

• strmpnk 7y ago
  It seems to lack any context for the claims. It is true that the distributed Erlang protocol is not something you'd want to expose to other parts of your system with different privilege levels, but it's entirely possible to restrict what connects and how (if at all, it is an optional part of the system). The main idea behind clustering is resilience of homogeneous components, not between varied applications or security domains. I do find it a bit disingenuous from that perspective. However the video is at least right on a few points: * if you have control of one node, you can effectively control the connected nodes (if any) as well * you can dynamically update and load code on all nodes (by design) * you can connect to other nodes as a hidden node, though it's still technically visible, but you need to specifically look for it and it only is visible to the node you connect to (so be sure to monitor this on all nodes) * the protocol itself is not designed to be public facing as timing attacks and cookie guessing are problems. (Cookies in this context are meant to prevent mistaken cluster connections and aren't really a security feature.) * the clustering is a fully connected mesh so a malicious user could DOS a network by rapidly rebooting a node to clog existing communication and burn through ephemeral ports for connections to use (really only applies to very large clusters but it's good to know how well you can handle spurious node membership changes) Having said that though, undetectable is a lazy claim (there are many ways to address this depending on how you setup your nodes and which epmd implementation you use) and the requirements are to keep the interface/ports open to things not part of the cluster. It's also far from a hard requirement to use the distribution feature at all if you don't trust your ability to setup an isolated network. It'd be the same issue if you had some external untrusted etcd or consul node connect to the rest and start screwing with consensus with similar devastation. Lastly, there are other ways to cluster Erlang nodes which don't necessarily inherit disterl's problems (disterl = what is built-in but it can be replaced or augmented). Libraries like Partisan look very promising. (EDIT: formatting)
• ramchip 7y ago
  Erlang distribution is just not meant to be used over the Internet, both for security and network reliability reasons. It’s something you would use on a restricted LAN. It’s also entirely optional. There’s an FAQ entry explaining the reasoning behind this - in short, making a distribution protocol that can work securely with untrusted nodes is very difficult and risky, so the more pragmatic choice is to just not support that use case. https://github.com/erlang/otp/wiki/FAQ:-What-kind-of-patches-will-be-approved%3F#can-i-write-a-patch-to-increase-the-security-of-the-erlang-distribution https://github.com/erlang/otp/wiki/FAQ:-What-kind-of-patches...
• bdibs 7y ago
  This is an issue that’s overblown, simply have a firewall that exposes used ports and you’re fine. There’s also an option within the release tool distillery to limit it to the local network. Not to mention even if an attacker found your unsecured setup, they’d also need to know your “cookie”/key to do anything. It’s no different than leaving SSH login with password enabled on any server.
  • dhab 7y ago
    The speaker claims that the cookie/key can be known by causing VM crash, which is done by exploiting the monotonic nature of cookie values which are stored as atoms which has a fixed cap on how many they can be, which when exceeded causes VM to crash. He estimates the time to do that be 10 mins (I forgot the exact memory limit)
    • bdibs 7y ago
      That’s definitely an issue, but again can be easily mitigated with a simple firewall that doesn’t allow every port to be open to the world.