인텔 관리 엔진
1. 개요
Intel Management Engine (Intel ME)
인텔의 프로세서 관리 펌웨어. 수정된 미닉스의 일종이며 PCH에 내장되어 있는 쿼크 프로세서에서 실행된다. 그러므로 CPU에서 실행되는 운영체제에서 터치를 할 수 없다. 인텔 관리 엔진은 OS의 독립적으로 시스템 하드웨어에 직접 접근 가능하며, 또한 네트워크에도 마찬가지로 접근 가능하다.
인텔 관리 엔진은 2008년부터 사용되었다.
2. 설명
구글이 이 엔진을 뜯으면서 미닉스로 만들어졌다는 사실과 기능들이 밝혀졌다.
[image]
- '당신이 모르는 코드 영역'으로 표시된 주황색과 붉은 색 영역은 사용자가 들여다 볼 수 없는 메모리를 의미하며
- 붉은 색으로 구분된 영역은 개별적인 x86 CPU에서 실행됨을 의미한다.
- 네트워크 통제
- 인텔의 여러 신기능과 기타 기능들 - Anti-theft, AES-NI(TLS) 등등...
- 전원관리
- 원격제어(AMT): 인텔 프로세서 중 vPro 기능이 사용된 제품에서만 활성화돼있다.
3. 문제점
프로세서에 펌웨어가 존재하는 것 자체는 문제가 되지 않는다, 프로세서에 펌웨어가 존재하는 것은 매우 흔하다. 스마트폰에도 존재하며 AMD의 프로세서에도 존재한다. 다만 ME의 경우 그 펌웨어가 꼭 필요하다고 보기 힘든 과도한 권한과 기능을 가진체 불투명하게 작동한다는 부분이 비난의 원인이다.
이 관리 엔진의 소스 코드는 인텔의 영업 기밀이라 어찌되는지 누구도 모른다. 소스 코드를 공개하지 않는 것에 대해서 당연하다는 의견도 있다. 소스 코드가 해커에게 유출될 경우, 더 심각한 보안 문제가 생길 수 있기 때문이다. 하지만 구글측의 의견은 보안을 위해 오픈 소스로 만드는 게 더 안전하다는 것이다. 소스 코드를 공개하면 구글의 엔지니어들이 매의 눈으로 보안 취약점이 있나 확인이 가능하기 때문이다. 오픈소스로 내버려뒀더니 하트블리드가 터진 OpenSSL을 생각해보면 설득력이 떨어지긴 하지만[1][2] 여튼, 이런 AMT로 인해서 마이크로소프트와 구글은 이 기능을 무진장 싫어하고 있다.
구글은 AMD CPU 구입이 해결책이 될 수 없다고 평가했는데, AMD도 인텔 관리 엔진(ME)과 비슷한 기능을 하는 펌웨어의 소스 코드를 공개하지 않기 때문이다.[3] 그래서 구글은 자사의 하드웨어에 탑재된 ME 펌웨어를 무력화 했을 뿐만 아니라. SMM등 운영체제 하에서 모니터링 불가능한 작동방식으로 구현된 기능을 완전히 걷어넨 UEFI의 대체재인 너프(NERF)라는 소프트웨어를 직접 개발하였다. 구글이 ME를 무력화 한 방식 역시 일반인들이 me를 무력화 하는 방식과 마찬가지로 부팅을 차단하는 펌웨어 무결성 검사가 모든 모듈을 검증하지 않는다는 부분을 이용한 꼼수를 사용한 것으로...
이전의 서술처럼 ME펌웨어 자신들의 코드로 대체 하는 방식은 아닌데 이것은 심지어 구글에게도 인텔이 ME를 커스텀할 수 있도록 허락하거나 협조하지 않았기 때문이다.
이러한 서드파티나 사용자들의 불만이 그저 불투명성과 보안에 대한 과민한 걱정으로 치부할 수 없는 것 이 인텔 관리 엔진은 여러 번 보안 이슈를 겪었다.
그 중 일부는 인텔 액티브 관리 기술(Intel Active Management Technology, 인텔 AMT)과 관련된 문제였는데, 이 모듈은 별도의 BMC등을 통해서 제공되는 관리기능에 준하는 관리기능을 PCH와 내장 내트워크 카드 만으로 제공하는 기능이다. BMC 추가에 따른 비용증가 없이도 IPMI 등 원격 관리 프로토콜을 지원하므로 작은 규모의 홈서버 등에서는 상당히 유용한 기능이나. 원격지에 포트를 개방하고 통신한다는 특성과 이것이 수행되는 프로세서가 사용자에 의해 모니터링할 수 없다는 점 그리고 역으로 사용자의 자료에는 제한 없이 접근할 수 있다는 요인이 합처져 취약점이 노출 된다면 굉장히 위험할 수 있다. 이러한 위험에도 불구하고 아주 편의적이고 소규모 시스템에 한해서는 BMC를 탑재 하는것에 비해서 기능적으로 우월한 면마저 있기 때문에 위험에도 불구하고 이 기능은 도태되지 않고 꾸준히 버전업 되고 있다.
그리고 2017년 11월 8일 11.x 버전 이하의 인텔 관리 엔진이 있는 컴퓨터에 USB를 꽂으면 AMT가 활성화되어 이를 마음대로 주무를 수 있는 취약점이 발견되었다. 즉, '''USB만 꽂으면 바로 컴퓨터가 호구로 변한다는 소리'''이다. 좀비 PC건, 랜섬웨어든 뭐가 실행되어도 운영 체제에서 막을 수 없다. USB 포트에 물리적으로 접근 할 기회만 부여되면 해당 시스템의 보안 레벨이나 운영 체제에 상관없이 침투할 수 있다는 것으로[4] 도청이나 감시, 기밀 탈취에 활용 가능한 여지가 무궁무진하다. 클라우드와 암호화 기술이 발전하면서 물리적 탈취보다는 보안 정보를 취득하는 것이 중요해지고 있는데 여기에 사용 할 수 있는 만능키인 셈. 역으로 이 취약점을 악용해서 USB로 아예 게임용 메모리핵을 커널단보다 더 밑에서 작동시켜서 배틀아이같은 안티치팅 프로그램을 바보로 만드는 핵도 퍼지고 있다.(...) 이 문제는 2017년 11월 30일 11.8.50.3425 인텔 관리 엔진 펌웨어와 11.7.0.1045 인텔 관리 엔진 드라이버 업데이트를 컴퓨터나 메인보드 기업들에게 제공해 해결됐다.
4. AMD의 경우
AMD도 비슷한 AGESA라는 펌웨어를 굴리고 있다. 다만, 인텔과 달리 AMD의 경우 펌웨어를 ARM 프로세서에 탑재하고, 코드는 ARM 프로세서의 Secure Enclave에 저장된다.
2017년 9월 28일, AMD에서 인텔의 관리 엔진 역할을 하는 플랫폼 보안 프로세서(PSP, Platform Security Processor)에 원격 코드 실행 취약점이 발견되었다. 해당 취약점은 구글 클라우드 보안 팀에 의해 발견되었으며 2017년 12월 7일에 픽스가 완성되었다. 해당 보안 취약점에 대한 정보는 2018년 1월 3일 대중에 공개되었다.
5. 관련 문서
[1] 물론 OpenSSL 이 클로즈드 소스였으면 하트블리드는 아직도 발견조차 안되었을 수도 있다. 그나마 하트블리드는 외부 보안 회사에서 발견했지만, 클로즈드 소스였다면 wild 에서 0-day 익스플로잇으로 먼저 쓰이다가 발견되었을 수도 있다. 실제로 Internet Explorer 에서는 이렇게 악용돼서 쓰이던 게 발견돼서 패치된 사례가 많기도 하고.[2] 다른 반론으로 인텔의 펌웨어와 OpenSSL은 주목도가 다르다는 점을 들 수 있다. 인텔이 소스코드를 공개한다면 해커들뿐 아니라 구글, 인텔과 떼어놓을 수 없는 관계인 마이크로소프트, 그 외 굴지의 보안 회사들과 내로라하는 전문가들이 눈에 불을 켜고 달려들어 소스코드를 분석할 테니 취약점이 발견되지 않을리가 없다.[3] 구글, 인텔CPU 허점에도 AMD 안 쓴 이유 2017-12-04[4] 물론 타겟이 될 시스템에 맞춘 공격수단은 별도로 준비해야할 것이다. 리눅스에 윈도우용 코드를 넣어도 소용 없으니까.