[erlang-questions] How to perform running code vs. beam files integrity check

[Mikael Pettersson]

Given the premise that the attacker is able to read and write the
Erlang VM's memory, you've already lost.  You could do something like:
1. Snapshot the process's text pages (VM, libc, other mapped
libraries) and store copies on a separate, secured system.
2. Augment the VM to report where it loads .beam files, then via an
external tool (e.g. ptrace-based) snapshot those too as modules get
loaded.  (Note: loaded modules have a very different representation to
the .beam originals).
3. At suitable times, using again an external tool, re-read the VM's
memory and compare with the snapshots stored elsewhere.

This will detect unexpected code modifications.

You cannot ask the VM to validate itself, since the attacker can
modify and neutralize that code.

However, equally bad may be if the attacker modifies data, but that is
less easy to detect since data often is meant to be modified; e.g.,
how can one determine if modifications to an ETS table are intentional
or not?

For real security you really need to prevent the attacker from ever
gaining access to the application's RAM.

If you're deploying on Linux or *BSD, I would consider locking down
the OS hosting the Erlang VM, e.g. by disabling ptrace, /dev/mem, and
similar mechanisms, and by restricting logins to only secure
terminals.  Oh, and disable Erlang RPC.

You may also consider deploying on a lockstep OS/HW platform (2 or
more systems executing in lockstep, the HW compares results and
detects if one starts to differ), but I don't know if they are
commercially available any more.  I think Tandem used to make such
systems, mainly for fault-tolerance.

On Mon, Sep 24, 2018 at 10:53 AM, Wojciech Ziniewicz
<wojtek@REDACTED> wrote:
> Hello,
>
> We develop an application on a highly regulated market. Some regulators
> force us to protect the running code from memory modification attacks.
> Consider following attack:
> - the app is running and all modules are loaded
> - attacker gains access to RAM, scans it and modifies a value in the memory
> (or a function) so the the running code differs from the code that has been
> loaded during initialization
> - the app continues operation without noticing that code has been modified
> - a state where two different apps are located on a  single machine: the one
> in RAM and the one on the disk
>
> I'm looking for *any* measures provided by erlang vm/tooling that would help
> mitigating this attack.
>
> The beam_lib provides tools for verifying the integrity of beam files but
> some kind of access to the running code would be required to close the loop
> here.
>
> Thanks
> WZ
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>