<html style="direction: ltr;">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body bidimailui-charset-is-forced="true" style="direction: ltr;"
bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 05/01/2019 22:22, Shachar Shemesh
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7a371c33-269d-27ce-82d0-b4620f90b1e6@shemesh.biz">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; }</style>
<p>Since the above completely describes what the loader does to an
executable file, I don't see how mprotect can be used there
either.</p>
<br>
</blockquote>
<p>So, I decided to check my assumptions. Sure enough, it seems that
the loader is using a private mapping when mapping the executables
into memory. If that's the case, then you should, indeed, be able
to use mprotect to change the permissions, and change the
executable code.</p>
<p><br>
</p>
<p>Please note, however, that this will not change the data on file
or for any other process mapping the same section. It will only
change your process' view of the file. As such, this is not a
security problem.</p>
<p><br>
</p>
<p>If, for whatever reason, you don't want that to happen, you can
modify the loader (source is in glibc) to use MAP_SHARED when
mapping the file. This will attack this "attack" vector. This
will, most probably, also prevent gdb from setting breakpoints in
your system.</p>
<p><br>
</p>
<p>Also, please note that if the aim is to only allow a process to
execute its predetermined code then this is a futile move. The
process can still mmap a new memory segment and write whatever it
wants there.</p>
<p><br>
</p>
<p>Shachar<br>
</p>
</body>
</html>