check if a kernel page is read-only

[Valdis.Kletnieks at 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)

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? :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 830 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160906/0bf76490/attachment-0001.bin