check if a kernel page is read-only

2016-09-06 21:47 GMT+02:00 [off-list ref]:

On Tue, 06 Sep 2016 13:23:48 +0200, Oscar Salvador said:

quoted

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

quoted

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