protect CONTROL and LR on stack

benwilliam10 wrote on Monday, July 23, 2018:

When using unprivilege tasks, it is pretty simple to access the stack of a sleeping unprivilege task and modify the pushed values for CONTROL register and give so the unprivilege task the full privilege.
Or modifying the pushed LR of a privilege task to execute its own malicious code.

As far as I understand thats what the MPU is for. It does not allow a running task to access anything else than the own stack and some userdefined regions.

But do I have any chance to avoid this issue without dynamic MPU ?

My theoretic idea is:
I have a static MPU protected area where all the TCBs are stored. Can I modify the FreeRTOS in a way taht it is not pishing the CONTROL and LR on the stack but into the TCB? and restoring them from there during taskswitch.

maybe this was already done by someone? or does the SafeRTOS version provide suck kind of protection?

rtel wrote on Monday, July 23, 2018:

I can’t remember which registers are pushed automatically so it might be
that those registers are pushed automatically meaning you can’t save
them in the TCB. If that is the case then you could save a copy of the
registers in the TCB, and then check the copy and the values on the
stack are not different - that would have to be done with care though to
ensure the malicious code cannot interfere with taking the copy, or
later comparing the copy.

richard_damon wrote on Tuesday, July 24, 2018:

First comment, even with ‘unprivaledged’ tasks, FreeRTOS makes no pretenses that it provides total security.
Also, your sample malicious code must have been made privaledged or explicitly have been given access to the victims task stack segement to perform such an attack.
In my experiance, unpriveledge tasks will have access to only their own stack segment (and aren’t running when those registers on on the stack), perhaps some limited I/O space if there are devices that are incharge of manipulating, and possible a segment or two of global data they need access to. They should have no need to have direct access to other tasks stacks.

benwilliam10 wrote on Tuesday, July 24, 2018:

@richard barry, thanks, thsi could be the way to go! I’ll give it a try

@richard damon, this is only true if you use the dynamic MPU stuff which FreeRTOS is providing, but I need nearly all MPU regions to protect a few single Peripherals, which otherwise would not be possible with the FreeRTOS MPU configuration.

richard_damon wrote on Tuesday, July 24, 2018:

Ben, yes, FreeRTOS has a definite mind to how an MPU is used, and part of that is that for normal tasks you trust them. Normal tasks have unlimited access to the machine.

Unpriviledge tasks on the other hand are very limited. They only can access the few resources that they are allowed.

You don’t use regions to ‘protect’ devices or regions of memory (black listing) but use them to permit access to those things you don’t fully trust (white listing).

Protecting certain devices globally means you only sort of trust your program. This is not in the model used by FreeRTOS. Sort-of trusting requires a LOT more work to setup and get right.