스펙터, 또다시. 당신이 놓친 것을 알기에...
스펙터와 그 사촌인 멜트다운은 2018년부터 우리와 함께 해왔으며, 이러한 취약점에 대해 들을 수 있는 모든 것을 들었다고 생각할 수 있습니다. 하지만 스펙터에 대한 또 다른 포스팅을 준비했습니다.
스펙터가 계속 등장하는 이유는 무엇인가요? 스펙터의 문제는 취약점이 본질적으로 너무 광범위하여 하나의 단일 취약점이 아니라 취약점의 범주에 속한다는 것입니다.
스펙터의 새로운 버전이 계속 등장하고 있습니다. 새로운 스펙터 익스플로잇 코드가 공개 리포지토리와뿐만 아니라 두 개의 CVE가 기록되었다는 에 대해 보고했습니다.
그래서 이 글에서는 또 다른 새로운 변종 스펙터에 대해 다룹니다. 지금까지 인텔의 대응을 둘러싼 논쟁을 포함하여 스펙터가 어떻게 작동하는지 알려드리겠습니다. 또한 최신 변종뿐만 아니라 광범위한 스펙터로부터 운영을 보호할 때 고려해야 할 핵심 사항을 다룹니다.
콘텐츠:
1. 스펙터와 멜트다운 - 다시 보기
2. 스펙터는 어떻게 작동하나요?
3. 최신 스펙터 변종에 숨겨진 이야기는 무엇인가요...?
4. ...그리고 누가 이 문제를 해결해야 하나요?
5. 인텔은 자신들에게 달려 있지 않다고 말합니다.
6. 코딩만 제대로 하면 되는 문제인가요?
7. Spectre로부터 워크로드를 보호하는 방법
스펙터와 멜트다운 - 다시 보기
오늘날의 프로세서는 프로세서 성능을 개선하기 위해 복잡한 효율성 알고리즘에 의존합니다. 이 중 하나가 추측 실행입니다.
간단히 설명하자면, 추측 실행은 프로세서가 애플리케이션에 필요할 것으로 생각되는 작업을 수행하지만 이 작업이 필요한지 확실하지 않은 상태에서 실행하는 것입니다. 작업이 필요한 것으로 판명되면 결과를 더 빨리 사용할 수 있으므로 애플리케이션 속도가 빨라집니다. 그렇지 않은 경우 결과는 단순히 버려집니다.
사실 추측 실행은 최신 프로세서의 필수 요소입니다. 하지만 추측 실행은 의도하지 않은 결과를 초래할 수 있으며, 바로 이 부분에서 스펙터가 등장합니다. 2018년에 악의적인 공격자가 추측 실행을 악용할 수 있는 방법이 밝혀지면서 기술 커뮤니티에 큰 우려를 불러일으켰습니다.
스펙터는 어떻게 작동하나요?
스펙터의 작동 방식에 대해서는 자세히 설명하지 않겠습니다, 이 테크리퍼블릭 가이드가 좋은 시작점이 될 것입니다.. 게다가 모든 스펙터 익스플로잇은 다르게 작동합니다. 하지만 대체로 스펙터 및 관련 익스플로잇은 프로세서를 조작하여 추측 실행의 "폐기된" 데이터에 액세스하도록 함으로써 악의적인 공격자가 간접적으로 무단 데이터에 액세스할 수 있게 합니다.
스펙터의 한 가지 "긍정적인" 점은 스펙터 익스플로잇을 구축하기가 매우 어렵다는 것입니다. 특정 정보를 훔치려는 의도로 추측 실행 공격을 시도하고 설계하기는 어렵습니다. 그럼에도 불구하고 해커는 스펙터 관련 취약점을 악용하여 유용할 수도 있고 유용하지 않을 수도 있는 데이터를 빼낼 수 있습니다.
그러나 스펙터의 우려스러운 측면은 암호화된 데이터도 프로세서가 데이터를 처리하는 동안 암호화되지 않은 상태로 캡처될 수 있기 때문에 스펙터 공격에 취약하다는 점입니다.
멜트다운과 스펙터에 대해 더 많이 알려지면서 보안 전문가들이 알고 있던 익스플로잇을 완화하기 위한 다양한 패치가 출시되었지만, 단일 패치로 스펙터 관련 취약점을 모두 완화할 수는 없습니다. 이는 스펙터가 본질적으로 버그가 아닌 추측 실행의 단점에 의존하기 때문입니다.
최신 스펙터 변종에 숨겨진 이야기는 무엇인가요...?
말할 필요도 없이, 2021년 5월에 또 다른 스펙터 익스플로잇이 등장했습니다. 여러분은 아르스 테크니카의 전체 글은 여기에서 읽을 수 있습니다.에서 읽어보실 수 있지만, 핵심 사항 몇 가지만 살펴보겠습니다. 우선, 이번 익스플로잇은 또 다른 새로운 투기적 실행 익스플로잇입니다. 2018년 기술 커뮤니티에서 제기한 우려가 타당했음을 증명하는 것으로, 스펙터는 금방 사라지지 않을 개방형 위협입니다.
이번에 버지니아 대학교의 연구원들은 인텔과 AMD가 지금까지 발표한 모든 완화 조치를 우회하는 새로운 실행 공격을 발견했습니다. 이 공격은 더 복잡한 명령어에서 파생된 단순화된 명령어인 '마이크로 연산'의 캐시 역할을 하는 CPU의 버퍼를 표적으로 삼습니다. 다시 말하지만, 마이크로 연산 기능은 프로그램이 더 빠르게 실행될 수 있도록 효율성을 위해 사용됩니다.
이 논문에서 연구팀은 공격자가 '사이드 채널' 공격, 즉 컴퓨터 시스템에 저장된 데이터를 관찰하는 방법으로 마이크로 옵스 캐시를 사용할 수 있는 방법을 설명합니다. 공격자는 CPU의 동작을 면밀히 관찰함으로써 다른 방법으로는 볼 수 없는 데이터에 대한 결론을 도출할 수 있습니다.
다시 말하지만, 이 익스플로잇은 비교적 복잡한 구성이지만, 그럼에도 불구하고 이 문제는 존재하며 현재까지 스펙터 드라마에 새로운 차원을 더하고 있습니다.
...그리고 누가 이 문제를 해결해야 할까요?
새로운 스펙터 익스플로잇은 인텔과 AMD에서 만든 프로세서에 영향을 미치며, 둘 다 유사한 프로세서 명령어 집합에 의존하기 때문입니다. 아직까지 AMD는 이 새로운 취약점에 대해 대응하지 않았습니다. 하지만 인텔의 대응이 주목받고 있습니다.
이전의 스펙터 익스플로잇은 인텔과 AMD의 하드웨어 패치와 운영 체제 패치를 혼합하여 완화되었습니다. 다시 말하지만, 모든 스펙터 관련 익스플로잇을 처리할 수 있는 단일 패치는 없지만 하드웨어 수준과 소프트웨어 모두에서 패치를 통해 개별 익스플로잇을 관리할 수 있습니다.
하지만 스펙터의 최신 변종은 이러한 모든 방어 체계를 무너뜨립니다. 당연히 스펙터를 수정할 수 있는 새로운 패치가 언제 출시될지 궁금해집니다.
정보에 따르면 그들이 결정할 일이 아니라고 합니다.
이번 사건은 Ars Technica 및 Threatpost를 비롯한 여러 소식통에 따르면 인텔은 기본적으로 최신 스펙터 익스플로잇에 대한 패치를 출시하지 않을 것이라고 합니다. 인텔은 소프트웨어를 개발할 때 모범 사례를 준수하면 최신 스펙터 익스플로잇이 위험을 초래하지 않도록 할 수 있다고 말합니다.
이 회사는 쓰렛포스트에 이렇게 말했습니다:
"인텔은 보고서를 검토한 결과 기존 완화 조치가 우회되지 않았으며 이 시나리오는 보안 코딩 지침에서 다루고 있음을 연구진에게 알렸습니다. 인텔의 지침을 따르는 소프트웨어에는 이미 uop 캐시 부수적 채널을 포함한 부수적 채널에 대한 보호 기능이 있습니다. 새로운 완화 조치나 지침이 필요하지 않습니다."
물론 보안 코딩은 많은 취약점의 영향을 제한하거나 무효화할 수 있으며 더 안전한 소프트웨어를 생산할 수 있습니다. 인텔의 보안 코딩 지침의 핵심 중 하나는 상수 시간 프로그래밍을 사용하는 것이지만, 프로그래머에게는 어려운 기술인 동시에 성능에 영향을 미칩니다.
코딩만 제대로 하면 되나요?
연구 논문의 개념 증명 코드는 인텔이 제안한 프로그래밍 원칙을 준수하지 않으며, 따라서 인텔은 새로운 취약점이 아니라 단순히 올바르게 프로그래밍하면 피할 수 있는 문제라고 말하고 있습니다. 한 보안 연구원도 이에 동의하며, 이 논문은 성능 저하를 수반하더라도 프로그래밍 관행을 더욱 정리해야 한다고 제안했습니다.
이에 대해 이 논문의 저자는 취약점은 CPU에 있으며, 따라서 과거 인텔이 스펙터 위협을 완화하기 위해 제공했던 마이크로코드 패치가 필요하다고 답했습니다.
연구팀은 또한 일상적으로 사용되는 소프트웨어의 상당수가 상수 시간 프로그래밍을 적용하지 않으며 가까운 장래에 이러한 상황이 바뀔 것으로 예상하지 않는다고 말합니다. 특히, 이 논문의 저자는 상수 시간 프로그래밍은 일반적으로 애플리케이션의 특수한 보안 루틴 내에서만 사용되며, 이는 이 방식이 수반하는 오버헤드 때문이라고 지적했습니다.
이 논쟁은 계속되고 있으며, 적어도 현재로서는 패치가 없기 때문에 공격자가 스펙터 취약점을 악용할 수 있는 여지가 남아 있지만 아직까지 악용 사례는 나타나지 않았습니다.
스펙터로부터 워크로드를 보호하는 방법
스펙터 패치는 추측 실행과 같은 프로세서 효율성 도구를 수정하여 익스플로잇의 기회를 제한하기 때문에 스펙터 완화 조치의 불편한 문제 중 하나는 항상 성능에 미치는 영향이었습니다.
이 최근 기사 에서 에서는 스펙터 취약점을 방어하는 데 수반되는 보안 위협에 대해 설명합니다. 스펙터 익스플로잇은 그 자체로 매우 심각하지만, 스펙터 익스플로잇을 통해 해킹에 성공한 실제 사례는 상대적으로 적다는 점도 한 가지 중요한 점입니다. 이는 이 글의 앞부분에서 언급한 바와 같이 추측 실행의 약점을 기반으로 공격을 설계하는 것이 어렵다는 점을 반영합니다.
그렇다고 해서 조직이 Spectre와 점점 더 많은 익스플로잇 제품군을 무시할 수 있는 것은 아닙니다. 일부 Spectre 패치는 다른 패치보다 성능에 더 큰 영향을 미치므로 잘 조사하여 Spectre에 대한 패치와 성능 유지 사이의 균형을 유지해야 합니다.
앞서 설명했듯이 최신 스펙터 익스플로잇에 대한 패치는 없습니다. 워크로드에 따라, 그리고 워크로드를 구동하는 코드를 변경할 수 있는지 여부에 따라 이 백서에 설명된 기법에서 파생된 공격으로부터 워크로드를 보호하기 위해 인텔이 제안한 모범 사례를 따르는 것이 좋습니다.
하지만 대부분의 사용자는 그렇게 할 수 없습니다. 가장 좋은 방법은 패치가 릴리스되는 즉시 배포하는 것입니다. 자동화된 라이브 패치가 이를 도와줄 수 있습니다..
그 동안 위협 환경과 저희 블로그를 계속 주시해 주세요. 스펙터에 대한 글은 이번이 마지막이 아닐 가능성이 높습니다.