check if a kernel page is read-only
Hi all, I'm writing a module to read/write kernel memory, and for this I'd like to check if a page is marked as read-only, so we don't have the right to write there (kernel code for instance). I though about the flags field from "struct page {}", but from the name I can't see any useful flag to check this. The only flag I saw is different between kernel code and module code is that kernel code has the flag "reserved" enabled, so it's not swapped. Could someone provide me a hint about that? Thank you very much
I think I can do that by getting the related pte of a virtuak kaddr, starting with pgd_offset_k <http://lxr.free-electrons.com/ident?i=pgd_offset_k>(address <http://lxr.free-electrons.com/ident?i=address>) , or directly with pte_t <http://lxr.free-electrons.com/ident?i=pte_t> *lookup_address <http://lxr.free-electrons.com/ident?i=lookup_address>(unsigned long address <http://lxr.free-electrons.com/ident?i=address>, unsigned int *level <http://lxr.free-electrons.com/ident?i=level>); And then I can checks the flags of this pte. 2016-09-05 12:59 GMT+02:00 Oscar Salvador <osalvador.vilardaga@gmail.com>:
Hi all,
I'm writing a module to read/write kernel memory, and for this I'd like to check if a page is marked as read-only, so we don't have the right to write there (kernel code for instance).
I though about the flags field from "struct page {}", but from the name I can't see any useful flag to check this.
The only flag I saw is different between kernel code and module code is that kernel code has the flag "reserved" enabled, so it's not swapped.
Could someone provide me a hint about that?
Thank you very much
On Mon, 05 Sep 2016 12:59:46 +0200, Oscar Salvador said:
I'm writing a module to read/write kernel memory, and for this I'd like to check if a page is marked as read-only
Actually, you almost certainly want to do a *much* stricter check than that. If your module is doing unrestricted writes, there's almost certainly a major design failure. Modules should *only* access memory that belongs to them - for instance, a driver for some new widget shouldn't be doing anything with memory that isn't either I/O buffer space allocated for that device, or the various struct * that the driver core sets up for a device. If you're trying to scribble *anywhere*, you're either trying to write a rootkit, or you're mis-designing something that will almost certainly be abused by somebody to backdoor in a rootkit. And I don't have much sympathy for "it's just a toy module" - if you can't be bothered to write modules with proper design, you shouldn't be coding in kernelspace. Learn to do it right from the beginning and don't learn sloppy habits. So what actual problem are you trying to solve by scribbling all over kernel space? There's probably a better way to do it.
On Mon, Sep 5, 2016 at 6:57 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 05 Sep 2016 12:59:46 +0200, Oscar Salvador said:
I'm writing a module to read/write kernel memory, and for this I'd like to check if a page is marked as read-only
Actually, you almost certainly want to do a *much* stricter check than that. If your module is doing unrestricted writes, there's almost certainly a major design failure. Modules should *only* access memory that belongs to them - for instance, a driver for some new widget shouldn't be doing anything with memory that isn't either I/O buffer space allocated for that device, or the various struct * that the driver core sets up for a device.
If you're trying to scribble *anywhere*, you're either trying to write a rootkit, or you're mis-designing something that will almost certainly be abused by somebody to backdoor in a rootkit.
And I don't have much sympathy for "it's just a toy module" - if you can't be bothered to write modules with proper design, you shouldn't be coding in kernelspace. Learn to do it right from the beginning and don't learn sloppy habits.
I guess this depends on the goals. I can think of a few valid reasons for making that with profiling/instrumentation in mind.
So what actual problem are you trying to solve by scribbling all over kernel space? There's probably a better way to do it.
Yes, tell us a little bit more about what you want to get. I guess we can help you if you tell us more about your problem. I'm curious.
2016-09-05 18:57 GMT+02:00 <Valdis.Kletnieks@vt.edu>:
On Mon, 05 Sep 2016 12:59:46 +0200, Oscar Salvador said:
I'm writing a module to read/write kernel memory, and for this I'd like to check if a page is marked as read-only
Actually, you almost certainly want to do a *much* stricter check than that. If your module is doing unrestricted writes, there's almost certainly a major design failure. Modules should *only* access memory that belongs to them - for instance, a driver for some new widget shouldn't be doing anything with memory that isn't either I/O buffer space allocated for that device, or the various struct * that the driver core sets up for a device.
If you're trying to scribble *anywhere*, you're either trying to write a rootkit, or you're mis-designing something that will almost certainly be abused by somebody to backdoor in a rootkit.
And I don't have much sympathy for "it's just a toy module" - if you can't be bothered to write modules with proper design, you shouldn't be coding in kernelspace. Learn to do it right from the beginning and don't learn sloppy habits.
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. Actually it's nothing that you couldn't do with # gdb /bin/ls /proc/kcore # x/4w [kernel_address] I wanted to check which kind of perms does it have a kernel page because I didn't want to be bothered by the "unable to handle kernel page request" if a user tries to write to a page which is read-only, so I wanted to check if that was the case, and just return an error in such case. Or also if a page is not resident in memory, either because is swapped or because was never mapped (checking the _PAGE_PRESENT bit). So far I'm using "lookup_address" to get the pte related to a kernel address in order to perform those checks, and that's working. The only doubt I have is: Can kernel pages be swapped? and if that's the case, there is a way to get check if a page is missing because was never mapped or because was swapped? Thanks
So what actual problem are you trying to solve by scribbling all over kernel space? There's probably a better way to do it.
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? :)
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@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
2016-09-07 15:47 GMT+02:00 Oscar Salvador <osalvador.vilardaga@gmail.com>:
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
I found a way by getting the beginning of the vma and then read from the offset generated from (my_address - beginning)
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@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Wed, 07 Sep 2016 15:47:30 +0200, Oscar Salvador said:
You are right regarding security stuff, but was not my will either bypassing memory protections or crashing the system.
Never said that was your intent. The problem is that given that tool, some other person can abuse your module with that intent.
- I write a user program which allocates a buffer, then writes something to it and calls a my module via read/write
OK, I'll bite - how are you hooking the read/write syscalls to code in your module? Via a pseudo-device and a struct *file_ops that points at your code? Oh - while you're at it, make sure your code deals properly with buffers that cross page boundaries (for instance, a 512 byte buffer that starts at 3840 bytes into a 4K page, and ends 256 bytes into the next page - particularly fun if the next page is either non-existent or paged out to swap. There's reasons why the code in copy_(to|from)_user() is ugly...
Thanks for the hints Valdis. 2016-09-07 18:48 GMT+02:00 <Valdis.Kletnieks@vt.edu>:
On Wed, 07 Sep 2016 15:47:30 +0200, Oscar Salvador said:
You are right regarding security stuff, but was not my will either bypassing memory protections or crashing the system.
Never said that was your intent. The problem is that given that tool, some other person can abuse your module with that intent.
- I write a user program which allocates a buffer, then writes something to it and calls a my module via read/write
OK, I'll bite - how are you hooking the read/write syscalls to code in your module? Via a pseudo-device and a struct *file_ops that points at your code?
I'm dealing with it with ioctls.
Oh - while you're at it, make sure your code deals properly with buffers that cross page boundaries (for instance, a 512 byte buffer that starts at 3840 bytes into a 4K page, and ends 256 bytes into the next page - particularly fun if the next page is either non-existent or paged out to swap. There's reasons why the code in copy_(to|from)_user() is ugly...
Taken the struct vm_area_struct and the field vm_start Are the first 4096 bytes from vm_start stored in one page, the next 4096 in another page and so on? (talking about 4k pages) I'm asking that because in that case is easy to find out how many pages should I read (just in case a buffer is close to the end of a page and follows on the next page).
participants (3)
-
Oscar Salvador -
Peter Senna Tschudin -
Valdis.Kletnieks＠vt.edu