🇰🇷 한글 설명
Linux 커널의 TPM 드라이버에서 null 키 이름 불일치가 발생해도 칩이 비활성화되지 않는 취약점이 발견되었습니다. 이로 인해 TPM 리셋 공격을 방어하기 위한 무결성 검사가 실패하더라도 칩이 계속 명령을 처리할 수 있는 상태로 유지됩니다.
💡 쉬운 설명
보안 칩(TPM)이 해킹 시도를 감지했을 때 스스로 작동을 멈춰야 하는데, 이를 감지하고도 계속 작동을 유지하는 결함이 있었습니다. 이 결함 때문에 공격자가 보안 칩을 속여 계속 명령을 내릴 수 있는 위험이 있었습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
tpm: Disable TPM on null key name mismatch
The null key name check exists to protect against TPM reset attacks, so
a mismatch should stop the device from serving further requests.
Currently it does not disable the chip when it finds a mismatch.
The mismatch is logged:
tpm tpm0: null key integrity check failed
but the chip keeps serving commands:
/ # tpm2_getcap -c properties-fixed
TPM_PT_FAMILY_INDICATOR:
as UINT32: 0x08322e3000
as string: "2.0"
...
tpm2_load_null() where the null key name check is run sets the chip as
disabled only if the rc is non zero. When the mismatch is seen, rc is
zero at that point and it returns success. The other issue is that the
caller expects the null key handle to be populated when the function
returns 0 which it does here without writing the handle and proceeds
assuming the null key handle is valid.
During the test, I noticed that tpm2_start_auth_session() uses the
uninitialized stack value as the key handle since tpm2_load_null()
returns 0 despite the integrity failure and proceeds with
TPM2_CC_START_AUTH_SESS with this value as salt key handle.
Set rc to -ENODEV on the mismatch. The error path then disables the chip
and returns the correct code to the caller.
Tested in QEMU with swtpm and CONFIG_TCG_TPM2_HMAC=y by making
TPM2_CC_CONTEXT_LOAD fail with TPM2_RC_INTEGRITY and changing the name
of the re-created null key. The chip is now disabled on the mismatch.
📍 영향받는 시스템
Linux kernel (TPM driver component)
⚔️ 공격 벡터
TPM 리셋 공격을 통해 null 키의 이름을 변경하여 무결성 검사를 우회하고 칩의 제어권을 유지함
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하여 무결성 검사 실패 시 TPM이 즉시 비활성화되도록 수정
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 해결된 패치 버전 이후인지 확인