Open jovanbulck opened 7 years ago
On the other hand, a multithreaded SM in the above scenario should of course only disable itself after it has finished all its internal execution threads.
The ID should still be cleared, however, since the continuation point could possibly be the entry point of another SM. In such a case, the continuation SM could be tricked into believing the call originated from a valid (still loaded) SM...
Problem. The
unprotect
instruction currently does not clear caller ID, which may enable an attacker controlling the continuation argument to spoof one caller authentication in multithreaded programs, without interrupting SMs:An attacker controlling the unprotected domain suspends thread1 on the unprotected sensor SM outcall. Next, the sensor SM is disabled in thread 2 and execution continues at an unprotected continuation point (with the valid callerID of the sensor SM). At this point, the attacker simply "returns" into the reader SM, passing arbitrary spoofed return values in CPU registers. The reader SM now cannot rely anymore on
sancus_get_caller_id
to authenticate this return call.Solution. After execution of the unprotect instruction, the ID of the previously executing module should be zero.