All of lore.kernel.org
 help / color / mirror / Atom feed
* [Clarification] writes to kernel addresses that came from userspace
@ 2021-09-12 16:20 Len Baker
  2021-09-12 18:22 ` Valentin Vidić
                   ` (4 more replies)
  0 siblings, 5 replies; 8+ messages in thread
From: Len Baker @ 2021-09-12 16:20 UTC (permalink / raw)
  To: kernelnewbies, Kees Cook; +Cc: Len Baker

Hi,

I am taking a look to the issues in the Kernel Self Protection Project [1]
and this one [2] (perform taint-tracking of writes to kernel addresses
that came from userspace) take my attention. Reading the explanation does
not make it clear to me where the flaw is.

[extracted from the KSPP]

It should be possible to perform taint tracking of addresses in the kernel
to avoid flaws of the form:

copy_from_user(object, src, ...);
...
memcpy(object.address, something, ...);

[end of extracted]

My question is: Why is this scenario a flaw?

If I understand correctly, the copy_from_user() function copies n bytes of
src (in user space address) to object (in kernel space address). I think
that it is the correct way to act. Then, in kernel space the object is
modified. So, I don't see the problem. Sorry if it is a trivial question
but I can not figure it out on my own.

[1] https://github.com/KSPP/linux/issues
[2] https://github.com/KSPP/linux/issues/126

Thanks in advance.

Regards,
Len

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Clarification] writes to kernel addresses that came from userspace
  2021-09-12 16:20 [Clarification] writes to kernel addresses that came from userspace Len Baker
@ 2021-09-12 18:22 ` Valentin Vidić
  2021-09-12 18:47   ` Kees Cook
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 8+ messages in thread
From: Valentin Vidić @ 2021-09-12 18:22 UTC (permalink / raw)
  To: Len Baker; +Cc: Kees Cook, kernelnewbies

On Sun, Sep 12, 2021 at 06:20:30PM +0200, Len Baker wrote:
> I am taking a look to the issues in the Kernel Self Protection Project [1]
> and this one [2] (perform taint-tracking of writes to kernel addresses
> that came from userspace) take my attention. Reading the explanation does
> not make it clear to me where the flaw is.
> 
> [extracted from the KSPP]
> 
> It should be possible to perform taint tracking of addresses in the kernel
> to avoid flaws of the form:
> 
> copy_from_user(object, src, ...);
> ...
> memcpy(object.address, something, ...);
> 
> [end of extracted]
> 
> My question is: Why is this scenario a flaw?
> 
> If I understand correctly, the copy_from_user() function copies n bytes of
> src (in user space address) to object (in kernel space address). I think
> that it is the correct way to act. Then, in kernel space the object is
> modified. So, I don't see the problem. Sorry if it is a trivial question
> but I can not figure it out on my own.

I suppose the problem is that userspace sets the value of object.address
to point to something dangerous. If the kernel tries to write to that
location later it will cause a crash or worse...

-- 
Valentin

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Clarification] writes to kernel addresses that came from userspace
  2021-09-12 16:20 [Clarification] writes to kernel addresses that came from userspace Len Baker
@ 2021-09-12 18:47   ` Kees Cook
  2021-09-12 18:47   ` Kees Cook
                     ` (3 subsequent siblings)
  4 siblings, 0 replies; 8+ messages in thread
From: Kees Cook @ 2021-09-12 18:47 UTC (permalink / raw)
  To: Len Baker; +Cc: kernelnewbies, linux-hardening

On Sun, Sep 12, 2021 at 06:20:30PM +0200, Len Baker wrote:
> I am taking a look to the issues in the Kernel Self Protection Project [1]
> and this one [2] (perform taint-tracking of writes to kernel addresses
> that came from userspace) take my attention. Reading the explanation does
> not make it clear to me where the flaw is.
> 
> [extracted from the KSPP]
> 
> It should be possible to perform taint tracking of addresses in the kernel
> to avoid flaws of the form:
> 
> copy_from_user(object, src, ...);
> ...
> memcpy(object.address, something, ...);
> 
> [end of extracted]
> 
> My question is: Why is this scenario a flaw?

I likely didn't give enough context in the Issue tracker. It's not a
flaw on its own, but rather an example of an attack situation if a flaw
were present (e.g. having no sanity-check on "object.address" above).

> If I understand correctly, the copy_from_user() function copies n bytes of
> src (in user space address) to object (in kernel space address). I think
> that it is the correct way to act. Then, in kernel space the object is
> modified. So, I don't see the problem. Sorry if it is a trivial question
> but I can not figure it out on my own.

The trouble is that the address came from userspace and (in this
example) has no validation, etc.

This Issue is about developing methods to perform "taint tracking"
within the kernel to better catch cases where validation is missing.
There is some limited support for this via the "__user" annotation and
the "address spaces" checks that "sparse" does, but that's been rather
limited in scope. Having something more like smatch doing function-graph
analysis would be nice for static analysis, and even better would be
stuff like DataFlowSanitizer[1], which can do this at runtime.

Hopefully that makes things more clear! I'll go update the issue
tracker. :)

-Kees

[1] https://clang.llvm.org/docs/DataFlowSanitizer.html

> [1] https://github.com/KSPP/linux/issues
> [2] https://github.com/KSPP/linux/issues/126

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Clarification] writes to kernel addresses that came from userspace
@ 2021-09-12 18:47   ` Kees Cook
  0 siblings, 0 replies; 8+ messages in thread
From: Kees Cook @ 2021-09-12 18:47 UTC (permalink / raw)
  To: Len Baker; +Cc: linux-hardening, kernelnewbies

On Sun, Sep 12, 2021 at 06:20:30PM +0200, Len Baker wrote:
> I am taking a look to the issues in the Kernel Self Protection Project [1]
> and this one [2] (perform taint-tracking of writes to kernel addresses
> that came from userspace) take my attention. Reading the explanation does
> not make it clear to me where the flaw is.
> 
> [extracted from the KSPP]
> 
> It should be possible to perform taint tracking of addresses in the kernel
> to avoid flaws of the form:
> 
> copy_from_user(object, src, ...);
> ...
> memcpy(object.address, something, ...);
> 
> [end of extracted]
> 
> My question is: Why is this scenario a flaw?

I likely didn't give enough context in the Issue tracker. It's not a
flaw on its own, but rather an example of an attack situation if a flaw
were present (e.g. having no sanity-check on "object.address" above).

> If I understand correctly, the copy_from_user() function copies n bytes of
> src (in user space address) to object (in kernel space address). I think
> that it is the correct way to act. Then, in kernel space the object is
> modified. So, I don't see the problem. Sorry if it is a trivial question
> but I can not figure it out on my own.

The trouble is that the address came from userspace and (in this
example) has no validation, etc.

This Issue is about developing methods to perform "taint tracking"
within the kernel to better catch cases where validation is missing.
There is some limited support for this via the "__user" annotation and
the "address spaces" checks that "sparse" does, but that's been rather
limited in scope. Having something more like smatch doing function-graph
analysis would be nice for static analysis, and even better would be
stuff like DataFlowSanitizer[1], which can do this at runtime.

Hopefully that makes things more clear! I'll go update the issue
tracker. :)

-Kees

[1] https://clang.llvm.org/docs/DataFlowSanitizer.html

> [1] https://github.com/KSPP/linux/issues
> [2] https://github.com/KSPP/linux/issues/126

-- 
Kees Cook

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Clarification] writes to kernel addresses that came from userspace
  2021-09-12 16:20 [Clarification] writes to kernel addresses that came from userspace Len Baker
  2021-09-12 18:22 ` Valentin Vidić
  2021-09-12 18:47   ` Kees Cook
@ 2021-09-13  7:59 ` Bernd Petrovitsch
  2021-09-13 18:01   ` Kees Cook
  2021-09-16  0:59 ` Random Guy
  2021-09-18  9:47 ` Len Baker
  4 siblings, 1 reply; 8+ messages in thread
From: Bernd Petrovitsch @ 2021-09-13  7:59 UTC (permalink / raw)
  To: Len Baker, kernelnewbies, Kees Cook

Hi all!

On 12/09/2021 18:20, Len Baker wrote:
[...]
> [extracted from the KSPP]
> 
> It should be possible to perform taint tracking of addresses in the kernel
> to avoid flaws of the form:
> 
> copy_from_user(object, src, ...);
> ...
> memcpy(object.address, something, ...);
> 
> [end of extracted]
> 
> My question is: Why is this scenario a flaw?
> 
> If I understand correctly, the copy_from_user() function copies n bytes of
> src (in user space address) to object (in kernel space address). I think > that it is the correct way to act. Then, in kernel space the object is

Yup.

> modified. So, I don't see the problem. Sorry if it is a trivial question
> but I can not figure it out on my own.

Shouldn't the memcpy() be a copy_to_user() as object.address is setup by 
the user space and thus a user space address?

MfG,
	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
      There is NO CLOUD, just other people's computers. - FSFE
                      LUGA : http://www.luga.at

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Clarification] writes to kernel addresses that came from userspace
  2021-09-13  7:59 ` Bernd Petrovitsch
@ 2021-09-13 18:01   ` Kees Cook
  0 siblings, 0 replies; 8+ messages in thread
From: Kees Cook @ 2021-09-13 18:01 UTC (permalink / raw)
  To: Bernd Petrovitsch; +Cc: Len Baker, kernelnewbies

On Mon, Sep 13, 2021 at 09:59:36AM +0200, Bernd Petrovitsch wrote:
> Hi all!
> 
> On 12/09/2021 18:20, Len Baker wrote:
> [...]
> > [extracted from the KSPP]
> > 
> > It should be possible to perform taint tracking of addresses in the kernel
> > to avoid flaws of the form:
> > 
> > copy_from_user(object, src, ...);
> > ...
> > memcpy(object.address, something, ...);
> > 
> > [end of extracted]
> > 
> > My question is: Why is this scenario a flaw?
> > 
> > If I understand correctly, the copy_from_user() function copies n bytes of
> > src (in user space address) to object (in kernel space address). I think > that it is the correct way to act. Then, in kernel space the object is
> 
> Yup.
> 
> > modified. So, I don't see the problem. Sorry if it is a trivial question
> > but I can not figure it out on my own.
> 
> Shouldn't the memcpy() be a copy_to_user() as object.address is setup by the
> user space and thus a user space address?

Right, _correct_ code would pass a userspace address, and use
copy_to_user() for writing to it. The goal here would be to find the
kinds of paths that might lead to bad conditions (i.e. answering "is it
possible for a userspace-controlled value to reach a place in the kernel
that didn't sanity-check it before doing indexing, sizing, etc?").

-- 
Kees Cook

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Clarification] writes to kernel addresses that came from userspace
  2021-09-12 16:20 [Clarification] writes to kernel addresses that came from userspace Len Baker
                   ` (2 preceding siblings ...)
  2021-09-13  7:59 ` Bernd Petrovitsch
@ 2021-09-16  0:59 ` Random Guy
  2021-09-18  9:47 ` Len Baker
  4 siblings, 0 replies; 8+ messages in thread
From: Random Guy @ 2021-09-16  0:59 UTC (permalink / raw)
  To: Len Baker; +Cc: Kees Cook, kernelnewbies

On Sun, Sep 12, 2021 at 9:21 AM Len Baker <len.baker@gmx.com> wrote:
> It should be possible to perform taint tracking of addresses in the kernel
> to avoid flaws of the form:
>
> copy_from_user(object, src, ...);
> ...
> memcpy(object.address, something, ...);
>
> [end of extracted]
>
> My question is: Why is this scenario a flaw?

Because of the first argument of memcpy.

> If I understand correctly, the copy_from_user() function copies n bytes of
> src (in user space address) to object (in kernel space address). I think
> that it is the correct way to act.

Yes.

> Then, in kernel space the object is modified.

Not necessarily. The object would be modified if

  memcpy(&object.address, something, ...);

was written. Without taking the address it is likely modifying something else.

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Clarification] writes to kernel addresses that came from userspace
  2021-09-12 16:20 [Clarification] writes to kernel addresses that came from userspace Len Baker
                   ` (3 preceding siblings ...)
  2021-09-16  0:59 ` Random Guy
@ 2021-09-18  9:47 ` Len Baker
  4 siblings, 0 replies; 8+ messages in thread
From: Len Baker @ 2021-09-18  9:47 UTC (permalink / raw)
  To: Valentin Vidić, Kees Cook, Bernd Petrovitsch, Random Guy
  Cc: kernelnewbies

Hi Valentin, Kees, Bernd and Random,

Thank you very much for all the info and advices. Now, things are
more clear to me.

Thank you all again for your time and guidance.

Regards,
Len

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-09-18  9:55 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-12 16:20 [Clarification] writes to kernel addresses that came from userspace Len Baker
2021-09-12 18:22 ` Valentin Vidić
2021-09-12 18:47 ` Kees Cook
2021-09-12 18:47   ` Kees Cook
2021-09-13  7:59 ` Bernd Petrovitsch
2021-09-13 18:01   ` Kees Cook
2021-09-16  0:59 ` Random Guy
2021-09-18  9:47 ` Len Baker

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.