How to perform running code vs. beam files integrity check

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

How to perform running code vs. beam files integrity check

Wojciech Ziniewicz
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: How to perform running code vs. beam files integrity check

Mikael Pettersson-5
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
<[hidden email]> 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
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: How to perform running code vs. beam files integrity check

PAILLEAU Eric
In reply to this post by Wojciech Ziniewicz


Hi, considering that Erlang was invented for code change at runtime, and two versions of same module can run at same time in different processes... Hard to know if a difference is an attack or not.
This imply to give up this feature for your app.
An attack could change code for a single process and recover original module code between two checks.
Erlang has no security.



---- Wojciech Ziniewicz a écrit ----

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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: How to perform running code vs. beam files integrity check

Kenneth Lundin


On Mon, Sep 24, 2018, 23:30 Eric Pailleau <[hidden email]> wrote:


Hi, considering that Erlang was invented for code change at runtime, and two versions of same module can run at same time in different processes... Hard to know if a difference is an attack or not.
This imply to give up this feature for your app.
An attack could change code for a single process and recover original module code between two checks.
Erlang has no security.

You claim that Erlang has no security, but that does not make Erlang less secure than any other language or runtime if the attacker can manipulate RAM for the running user space application?

I think it is better to concentrate on not letting an attacker have access to RAM. 

/Kenneth 



---- Wojciech Ziniewicz a écrit ----

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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: How to perform running code vs. beam files integrity check

PAILLEAU Eric

Sure.
And not access to node.
-setcookie  option in ps is a serious security issue for example.



---- Kenneth Lundin a écrit ----



On Mon, Sep 24, 2018, 23:30 Eric Pailleau <[hidden email]> wrote:


Hi, considering that Erlang was invented for code change at runtime, and two versions of same module can run at same time in different processes... Hard to know if a difference is an attack or not.
This imply to give up this feature for your app.
An attack could change code for a single process and recover original module code between two checks.
Erlang has no security.

You claim that Erlang has no security, but that does not make Erlang less secure than any other language or runtime if the attacker can manipulate RAM for the running user space application?

I think it is better to concentrate on not letting an attacker have access to RAM. 

/Kenneth 



---- Wojciech Ziniewicz a écrit ----

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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions