가상 머신 (VM)이 동일한 물리적 머신에서 실행중인 다른 VM을 "해킹"할 수 있습니까?

질문 :

• VM이 손상 (해킹) 된 경우 동일한 물리적 시스템에서 실행중인 다른 VM에 어떤 위험이 있습니까?
• 동일한 물리적 호스트에서 실행되는 VM간에 어떤 종류의 보안 문제가 있습니까?
• 그 (잠재적 인) 약점 및 / 또는 문제 목록이 있습니까?

경고:

많은 가상화 유형 / 솔루션이 존재하며 다른 약점을 가질 수 있음을 알고 있습니다. 그러나 대부분 특정 벤더 버그가 아닌 가상화 기술에 대한 일반적인 보안 문제를 찾고 있습니다.

실제 사실, (심각한) 연구, 경험있는 문제 또는 기술적 인 설명을 제공하십시오. 구체적으로 작성하십시오. 귀하의 의견을 말하지 마십시오.

• 예 :

2 년 전, MMU 와 관련된 보안 문제 (다른 컴퓨터의 메인 메모리에 액세스 하는 것)가있을 수 있다고 들었습니다 . 그러나 이것이 오늘날의 실제 위협인지 아니면 이론적 인 연구인지는 모르겠습니다. 제목.

편집 : 또한GnuPG가 다른 VM에서실행되는 경우에도 L3 CPU 캐시를 이용하여 동일한 물리적 시스템에서 GnuPG 비밀 키를 검색 할 수있는 이 "플러시 + 재로드"공격을 발견 했습니다 . GnuPG는 이후 패치되었습니다.

물론 작동하는 익스플로잇이 있다면 동일한 하드웨어에서 실행되는 다른 VM을 익스플로잇 할 수 있습니다. 또한 하나 존재할 수 있습니다. 귀하의 질문은 최근에 하나의 작품을 보여줍니다. 특정 익스플로잇이나 PoC는 여기에서 공유하지 않겠지 만 어떻게 할 수 있는지 기꺼이 말할 것입니다.

이 컨텍스트에서 사용되는 익스플로잇은 서비스를 악용하려는 동일한 머신에서 실행할 때 작동하는 익스플로잇과 자연스럽게 다르며 격리가 증가하여 상당히 어려워지는 경향이 있습니다. 그러나 이러한 악용을 수행하는 데 사용할 수있는 일반적인 방법은 다음과 같습니다.

• 하이퍼 바이저를 공격하십시오 . VM이 지정된 하이퍼 바이저에서 충분히 권한있는 셸을 얻을 수 있으면 시스템의 모든 VM을 제어 할 수 있습니다. 이에 접근하는 방법은 VM에서 하이퍼 바이저로 존재하고 하이퍼 바이저에 매우 의존적 인 데이터 흐름을 찾는 것입니다. 반 가상화 된 드라이버, 클립 보드 공유, 디스플레이 출력 및 네트워크 트래픽과 같은 것들이 이러한 유형의 채널을 만드는 경향이 있습니다. 예를 들어 반 가상화 된 네트워크 장치에 대한 악의적 인 호출로 인해 해당 트래픽을 물리적 NIC 드라이버로 전달하는 하이퍼 바이저 컨텍스트에서 임의의 코드가 실행될 수 있습니다.
• 호스트의 하드웨어를 공격하십시오 . 많은 장치에서 펌웨어 업데이트가 가능하며 VM에서 해당 메커니즘에 액세스 할 수 있으면 의도에 맞는 새 펌웨어를 업로드 할 수 있습니다. 예를 들어, NIC에서 펌웨어를 업데이트 할 수있는 경우 한 MAC 주소 (피해자)에 대해 다른 대상 MAC 주소 (귀하의 것)에 대한 트래픽 바인딩을 복제 할 수 있습니다. 이러한 이유로 많은 하이퍼 바이저가 가능한 경우 이러한 명령을 필터링합니다. ESXi는 VM에서 시작될 때 CPU 마이크로 코드 업데이트를 필터링합니다.
• 호스트 아키텍처 공격. 본질적으로 또 다른 타이밍 기반 주요 공개 공격 인 인용 한 공격이이를 수행합니다. 캐싱 메커니즘이 운영 타이밍에 미치는 영향을 활용하여 운영에서 대상 VM이 사용중인 데이터를 식별합니다. 가상화의 핵심은 구성 요소 공유입니다. 컴포넌트가 공유되는 경우, 사이드 채널의 가능성이 존재합니다. 동일한 호스트의 다른 VM이 대상 VM의 컨텍스트에서 실행되는 동안 하드웨어의 동작에 영향을 줄 수있는 한, 대상 VM은 공격자가 제어합니다. 참조 된 공격은 VM의 CPU 캐시 동작 (본질적으로 공유 된 범용 상태)을 제어하는 ​​VM 기능을 사용하여 피해자의 메모리 액세스 시간이 액세스하는 데이터를보다 정확하게 공개합니다. 공유 된 글로벌 상태가있는 곳이면 공개 가능성도 존재한다. 가상의 예를 들어 ESXi의 VMFS를 마사지하고 가상 볼륨의 일부를 동일한 물리적 디스크 주소를 참조하게하는 공격 또는 메모리 벌룬 시스템이 실제로 메모리를 공유해야 할 때 일부 메모리를 공유 할 수 있다고 생각하는 공격을 상상해보십시오. 비공개 (이것은 후 사용 또는 이중 할당 악용이 작동하는 방식과 매우 유사합니다). 하이퍼 바이저가 무시하지만 액세스를 허용하는 가상 CPU MSR (모델 특정 레지스터)을 고려하십시오. 이는 VM간에 데이터를 전달하여 하이퍼 바이저가 제공해야하는 격리를 차단하는 데 사용될 수 있습니다. 가상 디스크의 중복 구성 요소가 한 번만 저장되도록 압축을 사용할 가능성도 고려하십시오. 공격자가 자체 가상 디스크에 기록하고 관찰하여 다른 가상 디스크의 내용을 식별 할 수있는 일부 구성에는 (매우 어려운) 사이드 채널이 존재할 수 있습니다 하이퍼 바이저가하는 일 물론 하이퍼 바이저는이를 방지해야하며 가상의 예는 중요한 보안 버그 일 수 있지만 때로는 이러한 문제가 발생합니다.
• 다른 VM을 직접 공격하십시오 . 대상 VM에 근접한 호스트가있는 경우 호스트 구성 방법 및 액세스 제어 배포시 가정 사항에 따라 완화 된 액세스 제어 또는 의도적 인 VM 간 통신을 활용할 수 있습니다. 이것은 약간 관련이 있지만 언급이 있습니다.

특정 공격은 시간이 지남에 따라 발생하고 패치되므로 특정 메커니즘을 악용 가능하거나 실험실 조건에서만 악용 할 수 있거나 악용 할 수없는 것으로 분류하는 것은 결코 유효하지 않습니다. 보시다시피, 공격은 복잡하고 어려운 경향이 있지만 특정 시간에 실행 가능한 공격은 빠르게 변하는 것이므로 준비해야합니다.

즉, 위에서 언급 한 벡터 (어떤 경우에는 마지막 것을 제외하고는 가능)는 베어 메탈 환경에 존재하지 않습니다. 그렇습니다. 보안은 사용자 가 모르는 익스플로잇 과 공개 되지 않은 익스플로잇으로부터 보호하는 것이므로 베어 메탈이나 하이퍼 바이저가 VM을 모두 호스트하지 않는 환경에서는

일반적으로 안전한 응용 프로그램 프로그래밍을위한 효과적인 전략은 컴퓨터가 컴퓨터에서 실행중인 다른 프로세스를 가지고 있다고 가정하는 것입니다. VM에 존재합니다. 그러나 특히 처음 두 범주의 경우 하드웨어를 처음 접하는 사람이 승리한다는 것을 기억하십시오.

이론적으로는 아닙니다. 하이퍼 바이저의 요점은 가상 머신을 서로 분리하는 것입니다.

실제로 다양한 하이퍼 바이저에 보안 버그가 있었으며 현재 가상 머신 하나가 동일한 호스트의 다른 가상 머신에 하이퍼 바이저 나 다른 가상 머신에 영향을 줄 수 있습니다. sVirt (KVM / QEMU 용) 와 같은 보안 조치 는이 문제를 해결하기위한 것입니다.

편집 : 나는이 주제가 몇 개월 전에 완료되었다고 생각했지만 방금 회복되었으며 이제 OP는 더 많은 '실제 사실, 인용 연구'등을 요구하고 있기 때문에 도대체 무엇을 알아 냈습니다.

이 특성의 악용은 다음과 같습니다.

1. 드문
2. 본질적으로 민감하고 공개적으로 공유되지 않으므로,이 사이트의 누군가가 그 사실을 알기 전에 공급 업체가 익스플로잇을 패치합니다.
3. 복잡하고 공급 업체에 따라 다름

하이퍼 바이저를 해킹하고 다른 VM에 액세스하는 것은 불가능하다고 말할 수 없습니다. 하이퍼 바이저 익스플로잇을 사용한 공격에 대한 많은 이야기를 찾을 수 없다는 점을 고려할 때 그 경험이 매우 낮다는 것을 제외하고는 얼마나 많은 위험이 있는지 정량화 할 수도 없습니다.

여기 에 몇 가지 하이퍼 바이저 기반 공격이 수행되었음을 암시하는 흥미로운 기사 가 있습니다.

그러나, 그 어느 때보 다 하이퍼 바이저에 의존하는 기술로 인해 그러한 익스플로잇은 다른 유형의 익스플로잇보다 더욱 긴급하게 패치되고 보호됩니다.

다음은 IBM X-Force 2010 중기 동향 및 위험 보고서에서 발췌 한 내용입니다.

전체 화면으로 보려면이 이미지를 새 탭에서여십시오.

"하이퍼 바이저로 이스케이프"취약점의 측정 된 백분율을 확인하십시오. 주장을 뒷받침하는 더 많은 데이터가 있기 때문에 당연히 보고서의 나머지 부분을 읽고 싶을 것입니다.

다음 은 Playstation 3 하이퍼 바이저에서 수행 될 수있는 가능한 악용에 대한 이야기입니다. 어쩌면 당신의 사업이 그것의 어떤 경우에, 소니의 경우를 제외하고, 귀하의 비즈니스에 대한 영향력으로 매우 영향력.

여기 에 VMware의 Eric Horschman이 쓴 훌륭한 기사가 있습니다.이 기사는 10 대가 Micro-of $ tt를 타는 십대처럼 들리지만 여전히 좋은 기사입니다. 이 기사에서는 다음과 같은 좋은 것을 찾을 수 있습니다.

마이크로 소프트 글래스 하우스의 주민들은 우리의 길을 던질 다른 돌을 가지고있었습니다. Microsoft는 ESX 및 ESXi의 게스트 브레이크 아웃 취약점으로 CVE-2009-1244를 지적했습니다. 게스트 급등 익스플로잇은 심각한 비즈니스이지만 다시 한 번 Microsoft는 사실을 잘못 표현하고 있습니다. VMware는 자사 제품의 취약점을 패치하기 위해 신속하게 대응했으며 ESX는 Microsoft가 생각하는 것보다 훨씬 덜 영향을 받았습니다.

경쟁사들 사이에서 어려움. 그러나 아마도 전체 기사에서 그가 가장 명쾌한 것은 다음과 같습니다.

진실은 취약점과 악용이 엔터프라이즈 소프트웨어에서 완전히 사라지지는 않는다는 것입니다.

끊임없이 인용 할 테오 드 Raddt 오픈 BSD 프로젝트 :

보안 허점없이 운영 체제 나 응용 프로그램을 작성할 수없는 전 세계 소프트웨어 엔지니어 모음이 보안 허점없이 가상화 계층을 돌릴 수 있고 갑자기 쓸 수 있다고 생각한다면 어리석지 않더라도 절대적으로 대단합니다.

약간 염증성이지만 그의 요점은 잘 이해됩니다. 이론적으로 가상화는 가상 머신과 해당 호스트를 완전히 분리해야합니다. 실제로 고급 공격자가 이러한 보호 기능을 우회하여 다른 가상 머신에 액세스하거나 호스트를 악화시킬 수있는 보안 취약점이 가끔 있습니다 ( 적대적인 가상화 환경의 호스트에 대한 보안 노출에 대한 실증적 연구 참조 ). Ryan Ries가 언급했듯이 이러한 종류의 취약점은 매우 드물며 (존재하지 않음을 의미하지는 않음) 종종 공급 업체가 공개하지는 않지만 존재합니다.

이러한 종류의 공격 가능성에 대해 걱정이된다면 어느 정도는 생각해야합니다. 단일 가상 호스트 또는 가상 호스트 클러스터에서 보안 영역을 혼합하지 않는 것이 좋습니다. 예를 들어, DMZ 가상 머신 전용 2 개의 호스트 가상 호스트 클러스터, 미들웨어 전용 클러스터 및 보호 자산 용 전용 클러스터가 있습니다. 공격자가 다른 가상 머신을 파괴하거나 하이퍼 바이저 자체를 악화시킬 수있는 방식으로 취약점이 악용되는 경우 이러한 방식으로 보안 모델이 그대로 유지됩니다.