arnomi
I find myself quite often in the following situation.
Colleague: “Elixir/Erlang is problematic because we cannot secure the VM (i.e. Beam). It is vulnerable to code injection because anybody that gets to the system can start a remote shell and change running code without anybody noticing it. On the JVM in contrast this is not possible.”
To some extend this argument is correct. The JVM (and most other runtime systems) don’t offer the debug or cluster capabilities BEAM offers which make debugging a lot harder but also works in favor of securing the system (completely neglecting the code that is actually running withing the VM).
My question is: What are good arguments in favor of the security of BEAM and what are best practices to secure a running system (both in cluster mode and as a single isolated VM) as much as possible?
Trending in Discussions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
NobbZ
To be honest… But once the attacker has access to the system they can do anything… I do not need to alter the JVM to read its memory. To sniff network traffic, to get hands on certificates, to well, achieve about everything…
An attacker that came thus far, does not care anymore about the runtime. They care about the tasty stuff. SSH keys, config data (which usually contains passwords for DB or other external services), business data…
Exadra37
While what you say is true, @arnomi is not talking about the system running the VM, instead he is concerned about the VM itself, aka about what you can do when you get access to it without going through the server running the Erlang VM, eg: maybe like guessing the Erlang Cookie or breaking into it from the code(if this is possible!!!)
NobbZ
He is:
arnomi
Its both. I think I am mostly asking for: What are good arguments against the claim “runnig Beam is not secure”, (which by itself is not a well formulated claim, but one I have heard quite a lot).
And while on the topic, I think its interesting to understand best practices for securing a BEAM based system.
For example, one of the arguments against “you have lost if someone is in your system is: you at least might have monitoring on file level changes and intrusion detection systems. So if you are lucky you might catch this in time.” On the BEAM you cannot easily monitor (if at all) changes applied to the runtime system.
garazdawi
If you remove those debugging capabilities, by for instance not running distributed Erlang and not using run_erl/to_erl, you get into a very similar state as the JVM. You cannot debug, but you also cannot do code injection.
arnomi
Good point.
Is there anything you can do when running in cluster mode? My guess is the best protection would be to enable SSL for the distribution in which case you would at least need access to a proper certificate for connecting.
Is there anything that can be done from within the VM? For example monitoring code changes and sending notifications if a module gets reloaded?
garazdawi
Yes, I would never expose distributed Erlang to something that could potentially be an attacker without TLS enabled. That would be a very bad idea.
Yes there are ways to monitor, but if an attacker gets access to the node, they can disable the monitors.
idi527
Distribution over vpn is another alternative to tls (which I find simpler since no certificate management), wireguard will probably be integrated into the linux kernel “soon” (maybe in 5.0?). There’s also tinc, but it’s slower. I can publish a demo repo with my setup for both, if there is any interest. And if your hosting provider also provides a private network between vms as a service, then it’s even easier.
When I don’t need the distribution, I add
to the config to avoid epmd binding to all network interfaces. I also close all ports by default, and only leave the ones necessary for the application usage open.
dimitarvp
Do you have a good blog/video guide on how to tighten / selectively disable security-sensitive BEAM features? I for one I am not at all interested in Distributed Erlang because I am mostly doing small-to-medium apps and I’d like to have the distributed stack fully disabled until it’s very clear that I need it.
And yes, removing debugging (even though that’s an awful idea).
garazdawi
No, not really. If you don’t run distribution and turn off the shell, then the only other entry points into the system are what you create in your application.