<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-09-06 21:47 GMT+02:00 <span dir="ltr"><<a target="_blank" href="mailto:Valdis.Kletnieks@vt.edu">Valdis.Kletnieks@vt.edu</a>></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>
> I guess I explained it wrong. I'm not writing neither a rootkit nor a<br>
> module which is messing with kernel memory. I'm writing a module to be able<br>
> to r/w kernel/ user linear memory. It'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 "to be able to r/w kernel/user lineal memory", it's only<br>
a matter of semantics away from "messing with kernel memory".<br>
<br>
There's a *long* history of miscreants abusing security/forensic tools (which<br>
often run with extended privs) to pwn a system. For example, there'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't believe me...<br>
<br>
[~/src/metasploit] find . -name '*wires*'<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's been<br>
injected into the forensic tool? (Hint - checking the return address of the<br>
syscall isn'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 "probe_memory()" or similar that is called from<br>
all over the place, and can't protect against a subverted call.<br>
<br>
You can'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's trusting a check that'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>'<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's address with
"get_user_pages", 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's say a "hello!" 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(&pointer, 4096, 4096)), but not without it.<br></div><div>I
guess it'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 "middle" 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>