긴 머신 인스트럭션 하나로 x86 SMM 동기화를 깨는 smiiiiiiiiiiiiiiii 공격 공개
- SMM(System Management Mode) 보안 모델은 한 코어가 SMM에 진입하면 모든 코어가 동시에 SMM에 들어가야 하는 구조에 의존함
- 공격자는 느린 MMIO 소스를 읽는 등 극도로 오래 걸리는 단일 머신 인스트럭션으로 한 코어를 바쁘게 만들어 SMM 진입을 지연시킴
- 다른 코어의 SMM 진입을 기다리는 대기시간은 최대 1초로 타임아웃되며, 이 구간에서 한 코어는 SMM 밖, 다른 코어는 SMM 안에 있는 상태가 생겨 공격 창구가 열림
- 저자 xoreaxeaxeax는 README에 완화 방법 섹션을 추가했지만, 타임아웃을 없애면 멈춘 코어가 플랫폼 전체를 멈추게 하고 늘리면 다중 코어 플랫폼 성능이 떨어져 명확한 해법이 없다고 설명함
- 공격에는 root 권한이 필요하며, 저자는 sandsifter, movfuscator, rosenbridge 등 x86 저수준 취약점 연구 프로젝트를 여러 개 공개한 인물로, DEFCON 종료 직후 다시 이런 프로젝트를 올리기 시작함
Hacker News opinions
README가 굳이 'LOOOONG 인스트럭션'이라는 걸 강조하려고 코드 블록을 저렇게 길게 늘여놓은 게 웃김. 주제 자체도 재밌는데 이 디테일이 더 재밌게 만듦.
짧은 인스트럭션은 안 되는거야 아니면 무조건 길어야만 하는거야? 설명이 좀 애매하던데.
왜 1초 타임아웃이 있는지 모르겠음. 이거 패치하면 결국 무한 타임아웃으로 갈 것 같은데.
이거 패치 가능한거야? 혹시 하드웨어 워치독이라서 마이크로코드로 못 고치는거 아닐까.
2^32 크로스오버 카운터 같아 보이던데.
SMM은 시간에 민감한 작업을 많이 하니까, 시스템 과열됐는데 한 코어가 멈춰있으면 무한정 기다리기보단 열 대응하는게 낫지. SMI는 정해진 시간 안에 정상 처리로 돌아와야 해서 타임아웃이 필요한거임.
저자가 Mitigations 섹션에 쓴 설명이 맞말임. 타임아웃 없애면 멈춘 코어가 플랫폼 전체를 멈추게 하고, 늘리면 멀티코어 플랫폼 성능이 죽음. 뚜렷한 해법이 없어 보임.
긴 인스트럭션을 강제로 중단시키는 방법이 더 나은 선택일 것 같음. 하위호환이 깨지더라도, 예를 들면 그 프로세스를 kill하는 식으로.
xoreaxeaxeax가 왜 초장기 실행 인스트럭션 리스트를 모으고 있었는지 이제 알겠다. 이거 유저모드에서도 되는거야 설마??
vfio나 igb_uio, uio_pci_generic 쓰면 가능할지도, 근데 그래도 root 레벨 접근이 필요함.
진짜 느린 인스트럭션인가 싶기도 함. 사실 느린 MMIO 소스에서 복사하는 거라 느려 보이는거지, read(2)가 달에 있는 소켓 fd라서 느린 것처럼.
PCIe 장치를 USB로 연결할 수 있으니 악용 가능할듯. 유저가 접근 가능한 MMIO 디바이스를 FPGA로 에뮬레이트해서 느리게 만들면 됨. GPU 같은 게 딱 떠오름.
그래도 root는 필요함.
펌웨어 설계자들도 이 공격을 예상은 했는데 벤더한테 떠넘긴 것 같음. 주석에 '타임아웃 값은 시스템에서 가장 긴 IO 작업보다 길어야 한다'고 써있음.
Thunderbolt 액세서리가 임의로 긴 IO 오퍼레이션을 유발할 수 있을지 궁금함. 어느 계층에서 포기하고 fault를 내는지가 상한선일듯.
SMM이 타임아웃이 필요한 건 알겠는데, 긴 인스트럭션 끝나면 그 코어는 멈추는거 아님? 공격이 되려면 SMM이 하는 일과 뭔가 상호작용해야 할 것 같은데.
첫 코어가 두번째한테 SMM 합류하라고 하고 타임아웃나서 자기 일 하고 나가는데, 그 다음에 두번째 코어가 SMM에 들어감. 그러면 첫 코어는 SMM 밖, 두번째는 안에 있는 상태가 되고 이때 첫 코어가 두번째를 공격할 수 있는거임.
SMM은 여전히 구린 발상이네. 관리용 코어를 따로 안 두려고 돈 아낀 결과임.
ARM도 EL3라는 게 있어서 구조는 똑같음. 여러 권한 레벨 자체가 문제가 아니라 SMM의 불투명하고 유저 적대적인 구현이 문제임.
이 깃허브 프로필 최근 4일 전까지 거의 조용했는데 갑자기 프론트페이지 자주 뜨는거 뭐임?
rosenbridge 레포 커밋들은 8년 전이라고 나오던데.
DEFCON 라스베가스 컨퍼런스가 지난 주말에 있었잖음.
xoreax는 x86 히든 인스트럭션 찾는 유명한 영상이 있음. pxe로 pos 부팅해서 찾은 얘기가 전설임. opcode fault로 기기가 브릭될 수 있어서 각 pos를 모니터링하고 물리적 on/off까지 tap해서 수동 리부팅해야 했다고 함.
Chris는 원래 잡다한 재밌는 exploit들 올렸는데 Intel 들어가면서 멈췄었음. LinkedIn 보니 최근 Intel 나온 것 같아서 다시 재밌는 프로젝트 올리는 듯.
'모든 blocking operation엔 타임아웃이 있어야 한다'는 만트라가 왜 멍청하고 근시안적인지 보여주는 사례임. 임의 타임아웃 후 계속하면 invariant 깨지고, 실패시키면 부하 상황에서 디버그하기 힘든 실패가 생김. 시스템이 멈춰서 디버그할 수 있게 하고 워치독으로 리부팅하는게 나음.
여기서 실패해야 하는건 미친듯이 느린 MMIO를 하는 인스트럭션 자체임. 디버그가 어렵지 않음. vmovdqu가 MMIO 주소공간에서 fault나는건 큰 red flag고, 이 공격 자체가 워낙 비정상적인 협조 소프트웨어가 필요해서 정상 워크로드가 영향받을 일은 없을듯.
타임아웃 아이디어 흥미로운데, 펌웨어가 SMM 실행시간을 엄격히 제한하면 이 공격 클래스를 완전히 없앨 수 있는거야 아니면 그냥 크래시나 DoS로 바뀌는거야?
기술적으로 이건 취약점이 아님, root가 필요하니까. '자기 하드웨어 통제권 되찾기'라고 부르는게 더 맞음. SMM은 유저가 통제도 못하고 메모리 영역도 못 보는 구조라 악랄함. CPU 벤더들이 유저가 통제 못하는 모드를 왜 만들었겠음, DRM이나 정부 백도어 용도가 아니면 설명이 안됨.