intel me 관련해서 지속적으로 헛점이 발견되고 거기에 관해서 기사가 뜨지만
사용자의 관점에서는 별 느낌이 없습니다.
이는 이 보안의 헛점이란게 물리적 접근과 동시에 복잡한 방식으로 뚫어야 겨우 가능한
접근성이 매우 낮은 종류의 취약점이기 때문인데요..
그럼에도 지속적으로 어것만 쪼고 있는 보안 업체가 있고 뭔가 발견 될 때마다 지속적으로 난리가 나는 건.
이 ME 라는 친구가 작동하는 방식 때문입니다.
ME는 CPU를 위함 펌웨어 라고 흔히들 알려져 있으나...
사실 X86 CPU와 독립적으로 작동하는 PCH에 통합되어 있는 다른 CPU에서 구동 됩니다.
펌웨어는 UEFI와 같이 flash rom에 저장되어 있다. PCH 내부의 메모리로 로드되고 나면
X86 CPU 본체에서는 직접적으로 접근할 수 없는 상태가 됩니다.
수정은 커녕 내부에 뭐가 있는지 볼수도 없습니다.
역으로 PCH 내부에 있는 ME 펌웨어는 x86CPU의 MMIO은 IO port든 마음대로 접근 할 수 있을 뿐만 아니라..
vPro 같은걸 지원하는 재품들의 경우 네트워크 칩셋이랑은 직통으로 연결되어 있어서 x86 CPU의 매모리 공간을 경유하지 않고도
외부와 통신을 할 수 있습니다...
이 시스템의 보안의 헛점들이 접근성이 낮음에도 주목을 받는것은 이런 이유입니다.
넣기는 거의 불가능 해 보이지만. 넣고 나면 루트킷으로도 확인이 불가능 합니다.
동일하게 루트킷으로 발견이 불가능한 레벨의 코드인 SMM 에 삽입되는 악성코드는 마찬가지로 접근성이 매우 낮은데도
누군가 실용적으로 써 먹다가 들킨 예가 있습니다.
x86 CPU를 쓰는 네트워크 장비에 미리 넣어서 납품을 해 버린거죠.
SMM은 일단 x86 CPU에서 돌아가긴 하는거라 우회적으로 나마 작동의 흔적이 남는데.
ME는 아예 별도의 컴퓨터에서 도는 데다 매우 불투명 하게 작동합니다.
비슷한 짓을 하고 있는 사람이 있다면 이쪽은 더 들키기가 힘든거죠..
가능성은 낮지만 여지가 있는것 자체로 매우 불안한 그런 시스템인거죠.
그리고 이 시스템 관련해서 인텔 자체가 과하게 비난을 받는 이유도 몇가지가 있는데...
첫째는 이런게 있을 필요가 있느냐는 부분입니다.
언급했다시피 시스템 전체를 내려다보고 간섭할 수 있는 절대적인 위치에 있는 칩에
구지 온갖 기능이 다 들어 있는 프로그래밍 가능한 묵직한 펌웨어가 올라갈 필요가 있는가 하는거죠.
사람 불안하게 만드는 이런 불안한 친구를 꼭 있을 필요도 없는데 왜 넣느냐는 거죠..
둘째는 내껀데 왜 내맘대로 확인도 못하게 하느냐는 겁니다.
수정된 펌웨어가 실행 될 수 있으면 모니터링 할 수 있도록 메모리 따서 외부로 유출하는 코드를 넣던가 해서
인텔 너님이 실리콘에 이상한거 안 넣었는지 확인하고 안심하고 쓰겠는데.
왜 그런짓 못하게 용을 쓰고 해시 키도 안풀고 그러느냐는거죠.
뭐... 개인적으로는 그렇게 보안 관련해서는 안전불감증에 가까워서.. 별 불안은 안느낌니다만..
이게 좀 불려서 펌웨어를 커스텀 할 수 있게 되었으면 하는 생각은 있습니다.
NAS 같은거 꾸밀때 컴퓨터에 구지 라즈베리 파이 같은걸 붙여서 절전 대기시에 처리해야할 일을 맞기거나 하는데..
예네를 커스텀 할 수 있으면 아주아주 편하고 깔끔하게 외부 컨트롤러 없이 하고 싶은걸 거의 다 할 수 있을것 같거든요..
이미 쓰고있는건 어쩔 수 없으니 쓰고있을 뿐이고
당장 저 조차 '다음 컴퓨터는 AMD다' 라고 생각 하고 있습니다.
AMD로 가야겠다 라는 마음이 오히려 별 느낌이 없다는 반증이 아닐까 싶습니다...
사실 저도 x399를 쓰고 있긴 한데.
그나마 ME 쪽은 일단 플레시에 실장되어 있는 펌웨어는 언팩 하는 방법이 커뮤니티에 퍼저 있는데.
AMD 쪽은 오히려 완전 깜깜이 입니다.
더 소수만이 분석하고 구조를 파악할 수 있는거죠..
제가 x79 쓸때 펌웨어 고자된 상태로 1년 넘개 썻던 적이 있네요...
소비자 입장에서의 편의는 뭐 글쌔요 싶어요..
몇가지 시나리오(?)가 있었는데요..
가상머신에 일부 서비스를 올리고 가상머신에 다른 IP를 할당했을때 해당 IP로 가는 요청 패킷이 절전모드를 해제 못하는 문제가 있었습니다.
네트워크 카드의 절전 해제가 비트맵으로 ARP 패킷을 검출해서 깨우는 방식이였는데 NIC의 윈도우즈 드라이버는 그걸 마음대로 설정할 수 있는 인터페이스를 제공 안해서요.
가상머신으로 가는 ARP를 받아서 깨워즈는 기능을 구현 했던 적이 있습니다..
추후에 윈도우즈 드라이버로 가는 비트맵 설정을 후킹하는 필터 드라이버를 올리는 방식으로 바꿨지만요..
절전과는 관계 없지만
https://www.clien.net/service/board/cm_rasp/13643122?po=0&sk=title&sv=%EB%AA%A8%EB%8B%88%ED%84%B0&groupCd=&pt=3CLIEN
요것도 했었네요...
여기에 대한 태도의 스팩트럼이 꽤 넓어서
음모론 그 자체부터 인텔님에 대한 무한한 신뢰 까지 다양한 사람들이 있는데요..
구글은 ME를 꼼수로 차단하고 UEFI도 다 밀어 버렸다고 합니다.
구현에 SMM이 필요한 복잡한 UEFI 기능들을 전부 배제하고 운영쳊제 하에서 관리하도록 만들었다고 하더군요..
서버라서 가능했겠지만요..
UEFI를 밀어버리고 자작 대체제를 쓰는건 구글이 아니면 좀 무리가 따르는 일이겠지만..
ME를 막아버린건 구글이라고 특수한 요령이 있었던게 아니라..
커뮤니티서 발견한 꼼수를 그대로 사용한 거라고 합니다.
ME 펌웨어에서
딱 와치독스를 유지해서 컴퓨터가 꺼지지 않도록 하는 부분만 빼고 다른 모듈을 지워 버리는건데..
ME가 모듈별로 해시 검증을 따로 하기 때문에 가능한 일이죠..