<p dir="ltr"></p>
<p dir="ltr">Sure. <br>
And not access to node.<br>
-setcookie  option in ps is a serious security issue for example. </p>
<br><br>---- Kenneth Lundin a écrit ----<br><br><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 24, 2018, 23:30 Eric Pailleau <<a href="mailto:eric.pailleau@wanadoo.fr">eric.pailleau@wanadoo.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
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. <br>
This imply to give up this feature for your app.<br>
An attack could change code for a single process and recover original module code between two checks.<br>
Erlang has no security.</p>
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?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think it is better to concentrate on not letting an attacker have access to RAM. </div><div dir="auto"><br></div><div dir="auto">/Kenneth </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>---- Wojciech Ziniewicz a écrit ----<br><br><div dir="ltr"><div>Hello,</div><div><br></div><div>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:</div><div>- the app is running and all modules are loaded</div><div>- 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 <br></div><div>- the app continues operation without noticing that code has been modified</div><div>- a state where two different apps are located on a  single machine: the one in RAM and the one on the disk</div><div><br></div><div>I'm looking for *any* measures provided by erlang vm/tooling that would help mitigating this attack.</div><div><br></div><div>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. <br></div><div><br></div><div>Thanks</div><div>WZ<br></div></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank" rel="noreferrer">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></div></div>