check if a kernel page is read-only

[osalvador.vilardaga@gmail.com (Oscar Salvador)]

2016-09-06 21:47 GMT+02:00 <Valdis.Kletnieks@vt.edu>:

> On Tue, 06 Sep 2016 13:23:48 +0200, Oscar Salvador said:
> > I guess I explained it wrong. I'm not writing neither a rootkit nor a
> > module which is messing with kernel memory. I'm writing a module to be
> able
> > to r/w kernel/ user linear memory. It's for a forensic tool.
>
> And this, my friends, is an example of why things like this are *really*
> difficult to do correctly.
>
> There are very good reasons why (a) CONFIG_PROC_KCORE exists at all, and
> (b)
> why it only provides a read interface, not writing.
>
> If the module is "to be able to r/w kernel/user lineal memory", it's only
> a matter of semantics away from "messing with kernel memory".
>
> There's a *long* history of miscreants abusing security/forensic tools
> (which
> often run with extended privs) to pwn a system.  For example, there's been
> multiple holes found in wireshark, where a bugger overflow in one of the
> protocol dissectors allows the attacker to send a hand-crafted packet which
> takes over the wireshark process, and hilarity ensues....
>
> If you don't believe me...
>
> [~/src/metasploit] find . -name '*wires*'
> ./modules/exploits/multi/misc/wireshark_lwres_getaddrbyname_loop.rb
> ./modules/exploits/multi/misc/wireshark_lwres_getaddrbyname.rb
> ./modules/exploits/windows/misc/wireshark_lua.rb
> ./modules/exploits/windows/misc/wireshark_packet_dect.rb
> ./modules/exploits/windows/fileformat/wireshark_packet_dect.rb
> ./modules/exploits/windows/fileformat/wireshark_mpeg_overflow.rb
> ./modules/auxiliary/dos/wireshark
>
> So what *secure* way are you using for your kernel module to tell that a
> request came from your forensic tool, and not from malware code that's been
> injected into the forensic tool?  (Hint - checking the return address of
> the
> syscall isn't secure, because (a) it will move around every time the
> binary is
> rebuilt for new releases, and more importantly (b) the syscall is almost
> certainly in a function called "probe_memory()" or similar that is called
> from
> all over the place, and can't protect against a subverted call.
>
> You can't even have probe_memory() use __builtin_return_address(0) to check
> where it was called from, because the attacker can set up a properly
> crafted
> stack, patch the instruction following the call to branch back to malware,
> and then branch directly to the instruction that does the call....
>
> (And yes, having the check done in userspace is broken no matter *how*
> you do it, because it's trusting a check that's potentially subverted by
> the attacker)
>

You are right regarding security stuff, but was not my will either
bypassing memory protections or crashing the system.
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 it's a topical it helped me to understand
how the memory subsystem is working, since this was one of the motivations)

But I get your point, thanks for that.

Nevertheless, I have another question:


- I write a user program which allocates a buffer, then writes something to
it and calls a my module via read/write
- 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)

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.
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.

is that right?

thanks



>
> So given all this, why are you bothering with a kernel module which
> re-invents
> the wheel already done for you in the /proc/kcore support? :)
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160907/22372eb9/attachment-0001.html