writes to kernel addresses that came from userspace
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
[email protected]
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Quoted 16 lines · Len Baker
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]
Quoted 7 lines
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...
Signature · 6 lines
Valentin _______________________________________________ Kernelnewbies mailing list [email protected] https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Quoted 10 lines · Len Baker
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:
Quoted 7 lines
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).
Quoted 5 lines
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
Quoted 2 lines
[1] https://github.com/KSPP/linux/issues
[2] https://github.com/KSPP/linux/issues/126
Signature · 1 line
Kees Cook
Hi all!
On 12/09/2021 18:20, Len Baker wrote:
[...]
Quoted 9 lines
[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, ...);
Quoted 6 lines
[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.
Quoted 2 lines
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
Signature · 8 lines
Bernd Petrovitsch Email : [email protected] There is NO CLOUD, just other people's computers. - FSFE LUGA : http://www.luga.at _______________________________________________ Kernelnewbies mailing list [email protected] https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Quoted 20 lines · Bernd Petrovitsch
Hi all!
On 12/09/2021 18:20, Len Baker wrote:
[...]Quoted 9 lines
[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, ...);Quoted 6 lines
[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
Quoted 7 lines
Yup.
Quoted 2 lines
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 acopy_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?").
Signature · 6 lines
Kees Cook _______________________________________________ Kernelnewbies mailing list [email protected] https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Quoted 10 lines · Len Baker
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.
Quoted 3 lines
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.
Quoted 1 line
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
[email protected]
https://lists.kernelnewbies.org/mailman/listinfo/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
[email protected]
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies