<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-09-06 21:47 GMT+02:00  <span dir="ltr">&lt;<a target="_blank" href="mailto:Valdis.Kletnieks@vt.edu">Valdis.Kletnieks@vt.edu</a>&gt;</span>:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">On Tue, 06 Sep 2016 13:23:48 +0200, Oscar Salvador said:<br>
&gt; I guess I explained it wrong. I&#39;m not writing neither a rootkit nor a<br>
&gt; module which is messing with kernel memory. I&#39;m writing a module to be able<br>
&gt; to r/w kernel/ user linear memory. It&#39;s for a forensic tool.<br>
<br>
</span>And this, my friends, is an example of why things like this are *really*<br>
difficult to do correctly.<br>
<br>
There are very good reasons why (a) CONFIG_PROC_KCORE exists at all, and (b)<br>
why it only provides a read interface, not writing.<br>
<br>
If the module is &quot;to be able to r/w kernel/user lineal memory&quot;, it&#39;s only<br>
a matter of semantics away from &quot;messing with kernel memory&quot;.<br>
<br>
There&#39;s a *long* history of miscreants abusing security/forensic tools (which<br>
often run with extended privs) to pwn a system.  For example, there&#39;s been<br>
multiple holes found in wireshark, where a bugger overflow in one of the<br>
protocol dissectors allows the attacker to send a hand-crafted packet which<br>
takes over the wireshark process, and hilarity ensues....<br>
<br>
If you don&#39;t believe me...<br>
<br>
[~/src/metasploit] find . -name &#39;*wires*&#39;<br>
./modules/exploits/multi/misc/<wbr>wireshark_lwres_getaddrbyname_<wbr>loop.rb<br>
./modules/exploits/multi/misc/<wbr>wireshark_lwres_getaddrbyname.<wbr>rb<br>
./modules/exploits/windows/<wbr>misc/wireshark_lua.rb<br>
./modules/exploits/windows/<wbr>misc/wireshark_packet_dect.rb<br>
./modules/exploits/windows/<wbr>fileformat/wireshark_packet_<wbr>dect.rb<br>
./modules/exploits/windows/<wbr>fileformat/wireshark_mpeg_<wbr>overflow.rb<br>
./modules/auxiliary/dos/<wbr>wireshark<br>
<br>
So what *secure* way are you using for your kernel module to tell that a<br>
request came from your forensic tool, and not from malware code that&#39;s been<br>
injected into the forensic tool?  (Hint - checking the return address of the<br>
syscall isn&#39;t secure, because (a) it will move around every time the binary is<br>
rebuilt for new releases, and more importantly (b) the syscall is almost<br>
certainly in a function called &quot;probe_memory()&quot; or similar that is called from<br>
all over the place, and can&#39;t protect against a subverted call.<br>
<br>
You can&#39;t even have probe_memory() use __builtin_return_address(0) to check<br>
where it was called from, because the attacker can set up a properly crafted<br>
stack, patch the instruction following the call to branch back to malware,<br>
and then branch directly to the instruction that does the call....<br>
<br>
(And yes, having the check done in userspace is broken no matter *how*<br>
you do it, because it&#39;s trusting a check that&#39;s potentially subverted by<br>
the attacker)<br></blockquote><div><br><div>You are right regarding security stuff, but was not my will either bypassing memory protections or crashing the system.<br></div><div>I
 wanted to write a module to read from a kernel address or from a 
virtual address space from a certain pid, and write too, but just to 
those pages that can be written. (and even if <span lang="en"><span>it</span>&#39;<span>s a topical</span></span> it helped me to understand how the memory subsystem is working, since this was one of the motivations)<br><br></div><div>But I get your point, thanks for that.<br><br></div><div>Nevertheless, I have another question:<br><br></div><div><br></div><div>- I write a user program which allocates a buffer, then writes something to it and calls a my module via read/write<br></div><div>-
 The driver tries to get the user page of the buffer&#39;s address with 
&quot;get_user_pages&quot;, then tries to kmap this page and prints the content of
 the returned addr of kmap, so I can read what the userspace was put 
into that buffer. (let&#39;s say a &quot;hello!&quot; string)<br><br></div><div>This 
only works if the buffer allocated from userspace was allocated with 
some kind of mem_align (like posix_memalign with 
posix_memalign(&amp;pointer, 4096, 4096)), but not without it.<br></div><div>I
 guess it&#39;s because posix_memalign reserves a whole page for that 
buffer, then the addr that kmap is giving to you points at the 
beginning, but without the mem_align stuff, I guess the content of the 
buffer is just in the &quot;middle&quot; of the page.<br><br></div><div>is that right?<br></div><div><br></div>thanks<br><br> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<br>
So given all this, why are you bothering with a kernel module which re-invents<br>
the wheel already done for you in the /proc/kcore support? :)<br>
<br>______________________________<wbr>_________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.<wbr>org</a><br>
<a target="_blank" rel="noreferrer" href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies">https://lists.kernelnewbies.<wbr>org/mailman/listinfo/<wbr>kernelnewbies</a><br>
<br></blockquote></div><br></div></div>