Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LTS Updates #562

Merged
merged 9 commits into from
Sep 16, 2022
Merged

LTS Updates #562

merged 9 commits into from
Sep 16, 2022

Conversation

aggarg
Copy link
Member

@aggarg aggarg commented Sep 16, 2022

Description

This PR address the following issues:

  1. ARMv7-M and ARMv8-M MPU ports: It is possible for a third party that already independently gained the ability to execute injected code to read from or write to arbitrary addresses by passing a negative argument as the xIndex parameter to pvTaskGetThreadLocalStoragePointer() or vTaskSetThreadLocalStoragePointer() respectively. We thank Certibit Consulting, LLC for reporting this issue.
  2. ARMv7-M and ARMv8-M MPU ports: It is possible for an unprivileged task to invoke any function with privilege by passing it as a parameter to MPU_xTaskCreate, MPU_xTaskCreateStatic, MPU_xTimerCreate, MPU_xTimerCreateStatic, or MPU_xTimerPendFunctionCall. We thank Huazhong University of Science and Technology for reporting this issue.
  3. ARMv7-M and ARMv8-M MPU ports: It is possible for a third party that has already independently gained the ability to execute injected code to achieve further privilege escalation by branching directly inside a FreeRTOS MPU API wrapper function with a manually crafted stack frame. We thank Certibit Consulting, LLC, Huazhong University of Science and Technology and the SecLab team at Northeastern University for reporting this issue.
  4. ARMv7-M MPU ports: It is possible to configure overlapping memory protection unit (MPU) regions such that an unprivileged task can access privileged data. We thank the SecLab team at Northeastern University for reporting this issue.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

ARMv7-M allows overlapping MPU regions. When 2 MPU regions overlap, the
MPU configuration of the higher numbered MPU region is applied. For
example, if a memory area is covered by 2 MPU regions 0 and 1, the
memory permissions for MPU region 1 are applied.

We use 5 MPU regions for kernel code and kernel data protections and
leave the remaining for the application writer. We were using lowest
numbered MPU regions (0-4) for kernel protections and leaving the
remaining for the application writer. The application writer could
configure those higher numbered MPU regions to override kernel
protections.

This commit changes the code to use highest numbered MPU regions for
kernel protections and leave the remaining for the application writer.
This ensures that the application writer cannot override kernel
protections.

We thank the SecLab team at Northeastern University for reporting this
issue.

Signed-off-by: Gaurav Aggarwal <[email protected]>
This commit makes the privileged RAM and stack regions non-executable.

Signed-off-by: Gaurav Aggarwal <[email protected]>
It was possible for a third party that had already independently gained
the ability to execute injected code to achieve further privilege
escalation by branching directly inside a FreeRTOS MPU API wrapper
function with a manually crafted stack frame. This commit removes the
local stack variable `xRunningPrivileged` so that a manually crafted
stack frame cannot be used for privilege escalation by branching
directly inside a FreeRTOS MPU API wrapper.

We thank Certibit Consulting, LLC, Huazhong University of Science and
Technology and the SecLab team at Northeastern University for reporting
this issue.

Signed-off-by: Gaurav Aggarwal <[email protected]>
It was possible for an unprivileged task to invoke any function with
privilege by passing it as a parameter to MPU_xTaskCreate,
MPU_xTaskCreateStatic, MPU_xTimerCreate, MPU_xTimerCreateStatic, or
MPU_xTimerPendFunctionCall.

This commit ensures that MPU_xTaskCreate and MPU_xTaskCreateStatic can
only create unprivileged tasks. It also removes the following APIs:
1. MPU_xTimerCreate
2. MPU_xTimerCreateStatic
3. MPU_xTimerPendFunctionCall

We thank Huazhong University of Science and Technology for reporting
this issue.

Signed-off-by: Gaurav Aggarwal <[email protected]>
It was possible for a third party that already independently gained the
ability to execute injected code to read from or write to arbitrary
addresses by passing a negative argument as the xIndex parameter to
pvTaskGetThreadLocalStoragePointer() or
vTaskSetThreadLocalStoragePointer respectively.

This commit adds checks to ensure that passing a negative argument as
the xIndex parameter does not cause arbitrary read or write.

We thank Certibit Consulting, LLC for reporting this issue.

Signed-off-by: Gaurav Aggarwal <[email protected]>
Signed-off-by: Gaurav Aggarwal <[email protected]>
@aggarg aggarg requested a review from a team as a code owner September 16, 2022 10:11
Signed-off-by: Gaurav Aggarwal <[email protected]>
Signed-off-by: Gaurav Aggarwal <[email protected]>
History.txt Outdated
@@ -1,5 +1,30 @@
Documentation and download available at https://www.FreeRTOS.org/

Changes between FreeRTOS V10.4.3 LTS Patch 2 and FreeRTOS V10.4.3 LTS Patch 3 released September 16 2022

+ ARMv7-M and ARMv8-M MPU ports: It is possible for a third party that
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The history file should make it clear these issues applied to the prior version. So "it was possible", rather than "is possible", as a minimum.

@aggarg aggarg merged commit 9fa8dcb into FreeRTOS:lts_updates Sep 16, 2022
@aggarg aggarg deleted the lts_mpu_updates branch September 16, 2022 16:48
@aggarg aggarg restored the lts_mpu_updates branch September 16, 2022 16:58
@Mancent Mancent linked an issue Apr 1, 2023 that may be closed by this pull request
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

H
3 participants