Trusted Application Memory Safety and Release Decision for a Payment TA
A payment trusted application runs in a GlobalPlatform TEE on a handheld POS terminal. The TA has a 64 KB heap, a 32 KB stack, and a single thread. It implements an EMV-like transaction: it receives a normal-world buffer containing a PAN and cryptogram, calls an ocall to a host crypto library for RSA, and returns a result. A penetration test finds two issues. First, after each transaction the TA calls free() on the request buffer but never wipes it; a later ecall can allocate the same heap region and read stale PAN data. Second, one ecall accepts a pointer and length from the normal world and copies length bytes into a fixed 256-byte stack buffer without checking length. The testers could not read the TEE heap from the normal world, but they did trigger a crash. Release is in three weeks. The product owner wants to ship because “the TEE protects the heap.”
1. Triage the two findings. For each, state the attacker capabilities required, the realistic impact, and which is more urgent.
Read the worked answer
Stale PAN in the heap. Required capability: ability to invoke the TA’s ecalls, typically a malicious or compromised normal-world app that can connect to the TA. On a POS terminal, that is plausible after a software compromise. Impact: disclosure of cardholder data from a previous transaction, a serious PAN confidentiality breach. The TEE does not help because the data is legitimately copied into the TA and then left behind; isolation protects against other TAs and the normal world, not against a client calling the TA’s own interface. Unchecked length in ecall. Required capability: same client access. Impact: stack buffer overflow, TA crash, and potentially control-flow hijack inside the TEE. Even a crash is a denial of service at the payment moment; a write beyond the stack can corrupt pointers. This is more urgent because it is memory corruption in the trusted component and may be exploitable for code execution. The PAN leak is high severity but requires a later allocation to reuse the same region; the overflow is directly triggerable. Both must be fixed before release.
2. Design the ecall boundary and memory-hygiene fixes. Include how to handle the normal-world RSA ocall.
Read the worked answer
At every ecall: validate the pointer is non-null and within the shared-memory region, validate length against the destination size before copying, reject integer overflow, and copy once into a TA-local buffer. Never trust a length after the copy; avoid TOCTOU by not re-reading shared memory. Use a fixed maximum request size and return a typed error. For the 256-byte stack buffer, replace it with a bounded structure and a compile-time check; add stack canaries and -fstack-protector-strong if the toolchain supports it. Zeroize sensitive buffers with a secure wipe that the compiler cannot optimize away, on all paths including error paths, before free() and at TA close. Do not rely on free() to scrub. For the RSA ocall: minimize data sent to the normal world; if the host library sees the PAN or cryptogram, that defeats the TEE. Prefer a TA-local crypto implementation or a hardware crypto API. If the ocall is unavoidable, send only blinded or non-sensitive values and validate the response. Add fuzzing of all ecall parameters and a regression test that allocates after a transaction and checks for zeroed memory.
3. The product owner wants to ship in three weeks. What is your release recommendation and what evidence would change it?
Read the worked answer
Do not ship the current build. The stack overflow is a directly triggerable memory-safety defect in the component that handles card data, and the stale-heap issue is a likely PAN disclosure. Three weeks is enough for a focused fix if the team freezes features: patch the ecall validation, replace the fixed stack buffer, add secure zeroization, and run a targeted review of every ecall and ocall. Evidence needed before release: a code review of the TA boundary, static analysis with no high findings, fuzzing of length and pointer combinations, a test that triggers the old overflow and confirms rejection, a heap-reuse test that confirms zeroization, and a negative test showing the normal world cannot read TA memory. Also confirm the ocall does not expose the PAN. If the fixes slip, disable the vulnerable transaction path or delay; do not rely on “the TEE protects the heap.” If the product is in a PCI assessment, document the change and re-test.