check if a kernel page is read-only

check if a kernel page is read-only

[Oscar Salvador]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160905/6b48ef1a/attachment.html 

check if a kernel page is read-only

[Oscar Salvador]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160905/30b7ee5e/attachment.html 

check if a kernel page is read-only

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

So what actual problem are you trying to solve by scribbling all over kernel
space?  There's probably a better way to do it.
-------------- 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/20160905/3ce376ca/attachment.bin 

check if a kernel page is read-only

[Peter Senna Tschudin]

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.

check if a kernel page is read-only

[Oscar Salvador]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160906/0aeee0dd/attachment.html 

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 

check if a kernel page is read-only

[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 

check if a kernel page is read-only

[Oscar Salvador]

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 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/71c5f2a0/attachment.html 

check if a kernel page is read-only

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

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...
-------------- 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/20160907/9e553dd9/attachment.bin 

check if a kernel page is read-only

[Oscar Salvador]

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160912/374f07e8/attachment-0001.html