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

[Eric Pailleau]

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 <eric.pailleau@REDACTED> 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
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180925/33815a31/attachment.htm>