Stagefright: 안드로이드를 변화시킨 공격

Xda 안드로이드Nov 09, 2023

Stagefright는 최근 Android에서 발견된 최악의 익스플로잇 중 하나입니다. 자세한 내용을 읽고 자신을 보호하는 방법을 알아보려면 클릭하세요!

Android의 가장 강력한 점 중 하나는 주로 이해관계자가 자신의 특정 요구에 맞는 방식으로 OS를 포크, 수정 및 재배포할 수 있는 오픈 소스 특성입니다. 그러나 오픈 소스라는 이점은 맬웨어 및 보안 문제에 있어서 양날의 검처럼 작용합니다. 소스 코드가 무료로 제공되는 프로젝트에 유능한 기여자가 많으면 결함을 찾아 패치하는 것이 더 쉽습니다. 그러나 소스 수준에서 문제를 해결한다고 해서 최종 소비자의 손에서 문제가 해결되는 것은 아닙니다. 따라서 데이터에 민감한 기업 요구 사항에 맞는 OS를 선택할 때 Android는 최고의 선택이 아닙니다.

Google I/O 2014에서 Google은 Android For Work 프로그램. Android For Work는 기업 요구에 맞게 트윈 프로필 접근 방식을 채택했습니다. 이를 통해 IT 관리자는 직원을 위한 별도의 사용자 프로필 - 하나는 업무에 중점을 두고 다른 프로필은 직원의 개인용으로 남겨둡니다. 사용. 하드웨어 기반 암호화 및 관리자 관리 정책을 사용하여 업무 및 개인 데이터가 명확하고 안전하게 유지되었습니다. 이후 Android For Work는 멀웨어로부터 기기를 보호하는 데 중점을 두면서 이후 몇 달 동안 더 많은 관심을 받았습니다. 구글도 그럴 계획이다. 모든 장치에 대해 전체 장치 암호화를 활성화합니다. Android Lollipop과 함께 출시될 예정이었지만 OEM이 구현할 수 있는 선택 사항으로 지정되는 성능 문제로 인해 폐기되었습니다.

안전한 안드로이드를 위한 추진은 전적으로 구글의 일이 아닙니다. 삼성이 이를 통해 상당히 중요한 역할을 했기 때문입니다. AOSP에 대한 KNOX 기여, 이는 궁극적으로 강화된 Android For Work. 그러나 최근 Android의 보안 악용 및 취약성은 기업 채택에 대한 인기와 관련하여 어려운 과제를 지적합니다. 적절한 사례는 최근 Stagefright 취약점입니다.

내용물:

  • 스테이지프라이트란 무엇인가요?
  • Stagefright는 얼마나 심각한가요?
  • Stagefright가 다른 "대규모 취약점"과 다른 점은 무엇입니까?
  • 업데이트 딜레마
  • 안드로이드, 무대공포증 이후
  • 마무리 메모

스테이지프라이트란 무엇인가요?

간단히 말해서 Stagefright는 Android에서 미디어 재생을 위해 코드 라이브러리를 활용하는 익스플로잇입니다. libstagefright. libstagefright 엔진은 MMS를 통해 악성 영상 형태로 수신되는 코드를 실행하는 데 사용되므로 피해자의 휴대폰 번호만 있으면 공격이 성공할 수 있습니다.

우리는 사내 전문가, XDA 선임 인정 개발자 및 개발자 관리자에게 연락했습니다. pulser_g2 좀 더 자세한 설명을 드리기 위해.

"내가 이 글을 쓰는 동안, [Stagefright] 익스플로잇은 BlackHat에서 설명될 예정이었습니다.링크], 아직 슬라이드나 백서 세부 정보는 제공되지 않습니다.

그러므로 나는 이 설명을 완전한 정확성 등을 갖춘 매우 심층적인 설명보다는 무슨 일이 일어나고 있는지에 대한 대략적인 아이디어로 제공하고 있습니다.

Stagefright를 구성하는 다양한 버그가 있으며 이러한 버그에는 고유한 CVE가 있습니다.일반적인 취약점 및 노출] 추적 번호:

  • CVE-2015-1538
  • CVE-2015-1539
  • CVE-2015-3824
  • CVE-2015-3826
  • CVE-2015-3827
  • CVE-2015-3828
  • CVE-2015-3829

불행하게도 사용 가능한 패치는 각 CVE에 직접 연결되어 있지 않으므로 설명하기가 약간 복잡합니다.

1. [CVE-2015-1538]

MPEG4 처리 코드에서 3GPP 메타데이터(비디오가 3GPP 형식인 경우 형식 및 기타 추가 정보를 설명하는 항목) 처리 코드에는 버그가 있습니다. 데이터가 지나치게 큰 메타데이터는 거부하지 않고, 너무 작은지 여부만 확인합니다. 이는 공격자가 필요한 것보다 더 긴 메타데이터 부분을 포함하는 "수정" 또는 "손상된" 파일을 제작할 수 있음을 의미합니다.

"신뢰할 수 없는" 데이터(예: 사용자 또는 코드 외부의 다른 위치에서 가져온)를 처리하기 위해 코드를 작성할 때 가장 큰 과제 중 하나는 가변 길이 데이터를 처리하는 것입니다. 비디오는 이에 대한 완벽한 예입니다. 소프트웨어는 현재 상황에 따라 메모리를 동적으로 할당해야 합니다.

이 경우 버퍼는 일부 메모리에 대한 포인터로 생성되지만 그것이 가리키는 배열의 길이가 한 요소가 너무 짧습니다. 그런 다음 메타데이터를 이 배열로 읽어들였고 이 배열의 마지막 항목이 "null"(또는 0)이 아닐 수도 있었습니다. 배열의 마지막 항목이 0인 것이 중요합니다. 왜냐하면 이것이 소프트웨어가 배열이 완료되었음을 알려주는 방식이기 때문입니다. 마지막 값을 0이 아닌 값으로 만들 수 있으면(배열이 잠재적으로 하나의 요소가 너무 작기 때문에) 코드의 다른 부분에서 악성 코드를 읽을 수 있고 너무 많은 데이터를 읽을 수 있습니다. 이 값의 끝에서 멈추는 대신 읽어서는 안 되는 다른 데이터를 계속해서 읽을 수 있습니다.

(참조: 옴니롬 게릿)

2. [CVE-2015-1539]

메타데이터의 가능한 가장 짧은 "크기"는 UTF-16 문자열이므로 6바이트여야 합니다. 코드는 정수 값 크기를 가져와서 6을 뺍니다. 이 값이 6보다 작으면 뺄셈이 "언더플로우"되어 순환되어 매우 큰 숫자가 됩니다. 예를 들어 0부터 65535까지만 셀 수 있다고 상상해 보세요. 숫자 4에서 6을 빼면 0 아래로 내려갈 수 없습니다. 따라서 65535로 돌아가서 거기부터 계산합니다. 그게 바로 여기서 일어나는 일이에요!

6 미만의 길이가 수신되면 프레임이 잘못 디코딩될 수 있습니다. byteswap 프로세스는 변수 len16을 사용합니다. 이 값은 다음으로 시작하는 계산에서 얻어집니다. (사이즈-6). 이로 인해 의도한 것보다 훨씬 더 큰 스왑 작업이 발생하여 프레임 데이터의 값이 예기치 않은 방식으로 변경될 수 있습니다.

(참조: 옴니롬 게릿)

3. [CVE-2015-3824]

큰 놈! 이것은 불쾌합니다. 이 마지막 문제에는 정반대의 문제가 있습니다. 즉, 정수가 "너무 커질" 수 있는 정수 오버플로입니다. 예를 들어 65535에 도달했는데 더 이상 셀 수 없으면 굴러서 다음으로 0으로 이동합니다!

이를 기반으로 메모리를 할당하는 경우(Stagefright가 수행하는 작업!) 배열에 너무 적은 메모리가 할당되게 됩니다. 여기에 데이터를 넣으면 관련 없는 데이터를 악성 파일 작성자가 제어하는 ​​데이터로 덮어쓸 가능성이 있습니다.

(참조: 옴니롬 게릿)

4. [CVE-2015-3826]

또 다른 불쾌한 것! 마지막 것과 매우 유사합니다 - 배열(버퍼로 사용됨)이 너무 작게 만들어지는 또 다른 정수 오버플로입니다. 이렇게 하면 관련 없는 메모리를 덮어쓸 수 있으며 이는 다시 좋지 않습니다. 메모리에 데이터를 쓸 수 있는 사람은 관련 없는 다른 데이터를 손상시킬 수 있으며, 이를 사용하여 자신이 제어하는 ​​일부 코드가 휴대폰에서 실행되도록 할 수 있습니다.

(참조: 옴니롬 게릿)

5. [CVE-2015-3827]

이 마지막 것들과 매우 유사합니다. 변수는 일부 메모리를 건너뛸 때 사용되며, 이는 뺄셈 중에 음수가 될 수 있습니다(위와 같이). 이로 인해 "건너뛰기" 길이가 매우 길어지고 버퍼가 오버플로되어 액세스해서는 안 되는 메모리에 액세스할 수 있게 됩니다.

(참조: 옴니롬 게릿)

또한 [Android] 5.1에도 적용된 것으로 보이는 일부 (잠재적으로) 관련 수정 사항이 있습니다.

(참조: 옴니롬 게릿)

이는 과거 보안 수정으로 인한 문제를 중지하기 위한 검사를 추가하여 자체적으로 오버플로될 수 있는 경계 검사를 추가합니다. C에서는 signed int로 표현될 수 있는 숫자는 signed int로 저장됩니다. 그렇지 않으면 작업 중에 변경되지 않습니다. 이러한 검사에서 일부 정수는 부호가 없는 것이 아닌 부호가 있는 것으로 만들어질 수 있으며, 이로 인해 나중에 최대값이 줄어들고 오버플로가 발생할 수 있습니다.

(참조: 옴니롬 게릿)

좀 더 정수 언더플로가 발생합니다(숫자가 너무 낮으면 해당 숫자에 대한 뺄셈이 수행되어 음수가 됩니다). 이로 인해 다시 작은 숫자가 아닌 큰 숫자가 발생하고 이로 인해 위와 동일한 문제가 발생합니다.

(참조: 옴니롬 게릿)

그리고 마지막으로 또 다른 정수 오버플로가 발생합니다. 이전과 마찬가지로 다른 곳에서 사용하려고 하므로 오버플로될 수 있습니다.

(참조: 옴니롬 게릿)"

Stagefright는 얼마나 심각한가요?

에 따라 블로그 게시물 모 연구 회사인 Zimperium Research Labs가 발표한 Stagefright 익스플로잇의 잠재적 노출 내용은 다음과 같습니다. Android 기기의 95%(약 9억 5천만 대)가 Android 2.2 및 위로. 설상가상으로 Jelly Bean 4.3 이전 장치에는 이 악용에 대한 적절한 완화 기능이 포함되어 있지 않기 때문에 "최악의 위험"에 처해 있습니다.

Stagefright가 처리할 수 있는 피해와 관련하여 pulser_g2는 다음과 같이 말했습니다.

[blockquote 작성자="pulser_g2"]"Stagefright는 그 자체로 시스템 사용자에게 전화로 액세스 권한을 부여합니다. 하지만 실제로 이를 남용하려면 ASLR(주소 공간 레이아웃 무작위화)을 우회해야 합니다. 이것이 달성되었는지 여부는 현재로서는 알 수 없습니다. 이 악용을 통해 시스템 또는 미디어 사용자로서 장치에서 "임의 코드"를 실행할 수 있습니다. 이들은 장치의 오디오 및 카메라에 액세스할 수 있으며 시스템 사용자는 루트 익스플로잇을 시작하기에 좋은 장소입니다. 휴대폰을 루팅하는 데 사용한 놀라운 루트 익스플로잇을 모두 기억하시나요?

이는 잠재적으로 장치에서 루트를 확보하는 데 자동으로 사용될 수 있습니다! 루트가 있는 사람이 전화기를 소유합니다. SELinux를 우회해야 했지만 TowelRoot가 이를 관리했고 PingPong도 이를 관리했습니다. 루트가 되면 휴대전화의 모든 내용이 공개됩니다. 메시지, 열쇠 등."[/blockquote]최악의 시나리오에 대해 말하면 코드를 전달하고 이 공격을 실행하는 데 MMS만 필요합니다. 사용자 메시지를 열 필요조차 없습니다 많은 메시징 앱은 사용자가 MMS와 상호작용하기 전에 MMS를 사전 처리합니다. 이는 사용자가 성공적인 공격을 전혀 인식하지 못하고 전화기의 현재 및 미래의 모든 데이터를 손상시킬 수 있다는 점에서 스피어 피싱 공격과 다릅니다.

Stagefright가 다른 "대규모 취약점"과 다른 점은 무엇입니까?

"모든 취약점은 사용자에게 어느 정도 위험을 초래합니다. 이것은 특히 위험합니다. 누군가가 원격으로 공격할 수 있는 방법을 찾으면(즉, 가능합니다. ASLR을 피할 수 있는 방법이 발견된 경우), 귀하가 아래에 있다는 사실을 깨닫기도 전에 트리거될 수 있습니다. 공격"

Android Installer Hijacking, FakeID와 같은 오래된 공격은 물론 TowelRoot 및 PingPong과 같은 루트 공격을 실행하려면 어느 시점에서 사용자 상호 작용이 필요합니다. 악의적으로 사용하면 많은 피해가 발생할 수 있다는 점에서 여전히 "악용"이지만 Stagefright는 여전히 이론적으로 피해자의 휴대전화 번호만 있으면 휴대전화를 트로이 목마로 전환할 수 있으므로 최근 들어 많은 주목을 받고 있습니다. 날.

하지만 안드로이드가 이 공격에 전적으로 영향을 받는 것은 아닙니다. Android 보안 수석 엔지니어인 Adrian Ludwig는 다음과 같은 몇 가지 우려 사항을 해결했습니다. Google+ 소식:

[blockquote 작성자="Adrian Ludwig"]"모든 소프트웨어 버그가 보안 악용으로 바뀔 수 있다는 일반적이고 잘못된 가정이 있습니다. 실제로 대부분의 버그는 악용될 수 없으며 Android에서는 이러한 가능성을 개선하기 위해 많은 노력을 기울였습니다.

Ice Cream Sandwich(Android 4.0) 이후 도입된 일부 기술 목록은 다음과 같습니다. 여기. 그 중 가장 잘 알려진 것은 ASLR(Address Space Layout Randomization)으로 완전히 완성되었습니다. PIE(Position Independent Executables)를 지원하는 Android 4.1에서 현재 Android의 85% 이상에 사용됩니다. 장치. 이 기술은 공격자가 성공적인 익스플로잇을 구축하는 데 필요한 코드의 위치를 ​​추측하는 것을 더 어렵게 만듭니다.

우리는 ASLR에서 멈추지 않고 NX, FortifySource, 읽기 전용 재배치, 스택 카나리아 등도 추가했습니다."[/blockquote]

그러나 Stagefright가 Android의 미래에 심각한 문제이고 관련 이해관계자들이 이를 심각하게 받아들이고 있다는 사실은 여전히 ​​부인할 수 없습니다. Stagefright는 또한 방 안의 흰 코끼리, 즉 단편화 문제와 최종적으로 소비자에게 도달하는 업데이트 문제를 강조했습니다.

업데이트 딜레마

업데이트에 관해 말하자면, 많은 사람들이 약속한 것처럼 OEM이 사용자 보안을 책임지고 있다는 점은 좋은 일입니다. Stagefright와 같은 악용에 대한 보안 수정 사항 및 패치를 통합하기 위해 특별히 업데이트 프로세스를 개선합니다.

가장 먼저 공식 성명을 발표한 가운데 구글은 다음과 같이 약속했습니다. 월간 보안 업데이트 (계획된 OS 및 플랫폼 업데이트 외에도) 거의 3년 된 Nexus 4를 포함하여 대부분의 Nexus 기기에 적용됩니다. 삼성은 또한 통신사 및 파트너와 협력하여 월간 보안 업데이트 프로그램 하지만 이 구현의 장치 및 타임라인 세부 정보를 지정하지 못했습니다. 이는 이동통신사와 협력하여 보안 업데이트에 대한 "신속한 경로" 접근 방식을 언급하고 있어 흥미롭습니다. 통신사에서 더 자주 업데이트될 것으로 예상됩니다(보안 기반이지만 펌웨어 업그레이드도 가속화되기를 바랍니다). 장치.

이 팩에 합류하는 다른 OEM으로는 LG도 포함됩니다. 월간 보안 업데이트. 모토로라도 발표했다. 업데이트할 기기 목록 Stagefright 수정 사항이 포함되어 있으며 목록에는 2013년 이후 회사에서 만든 거의 모든 장치가 포함되어 있습니다. 소니도 그런 말을 하더군요 해당 장치는 곧 패치를 받게 됩니다. 도.

일단 통신사에서도 업데이트가 예정되어 있습니다. 스프린트는 성명을 발표했다 일부 장치는 이미 Stagefright 패치를 받았으며 더 많은 장치가 업데이트될 예정입니다. AT&T도 이를 따랐다. 일부 장치에 패치를 발행하여. Verizon도 패치를 발표했습니다. 비록 Galaxy S6 Edge 및 Note 4와 같은 고급 스마트폰을 우선시하는 느린 출시이긴 하지만요. T-Mobile Note 4도 Stagefright 패치 업데이트를 받았습니다.

최종 사용자로서 공격을 받을 가능성을 줄이기 위해 취할 수 있는 몇 가지 예방 조치가 있습니다. 우선, 휴대폰에 있는 메시징 앱에서 MMS 메시지 자동 검색을 비활성화하세요. 이는 익스플로잇이 작동하는 데 사용자 상호 작용이 필요하지 않은 경우를 제어해야 합니다. 그런 다음 출처를 알 수 없고 신뢰할 수 없는 MMS 메시지의 미디어를 다운로드하지 않도록 주의하세요.

XDA 고급 사용자로서 다음도 할 수 있습니다. Stagefright를 비활성화하려면 빌드 소품을 편집하세요.. 이는 Stagefright로부터 자신을 보호할 수 있는 완전하고 확실한 방법은 아니지만, 이전 Android 빌드에 갇혀 있는 경우 공격이 성공할 가능성을 줄일 수 있는 기회를 얻을 수 있습니다. 맞춤형 ROM 솔루션도 있는데, 대부분은 정기적으로 AOSP와 소스를 동기화하므로 Stagefright 수정 사항이 통합됩니다. AOSP 기반 ROM을 실행하는 경우 Stagefright 패치가 포함된 최신 ROM 릴리스로 업데이트하는 것이 좋습니다. 당신이 사용할 수있는 이 앱 현재 일일 운전자가 Stagefright의 영향을 받는지 확인하세요.

안드로이드, 무대공포증 이후

Stagefright는 Android와 그 조각화 및 업데이트 문제에 대한 경종일 뿐입니다. 이는 이러한 중요한 수정 사항을 적시에 수많은 장치에 배포할 수 있는 명확한 메커니즘이 없다는 점을 강조합니다. OEM이 장치에 대한 패치를 출시하려고 시도하는 동안 이러한 수정 사항의 대부분은 최신 플래그십에만 국한된다는 것이 가혹한 사실입니다. 기타 비플래그십 및 구형 장치(소형 OEM의 경우는 훨씬 적음)는 계속해서 Stagefright에 노출될 것입니다.

이번 공격에는 긍정적인 희망이 있습니다: Android의 업데이트 프로세스에 대한 관심을 다시 끌고 미래의 많은 기업이 기업용으로 Android를 채택하는 쪽으로 관심을 끌지 못할 것이라고 밝혔습니다. Google이 더 큰 기업 채택을 위해 노력함에 따라 업데이트 전략과 OEM에 허용되는 제어 범위를 다시 생각해야 할 것입니다.

Android M이 시장 출시에 가까워짐에 따라 Google이 Play 서비스 패키지를 선호하여 AOSP의 점점 더 많은 구성 요소를 분리하기로 결정한 것은 놀라운 일이 아닙니다. 결국 이는 기기가 Google Play 스토어와 함께 배송되는지 여부에 대해 Google이 여전히 완전한 통제권을 갖고 있는 영역 중 하나입니다. 이것 나름의 단점이 있다 오픈 소스 영역을 클로즈 소스 벽으로 대체하는 형태입니다.

Android의 미래를 추측할 때 Google이 OEM이 AOSP에 수행할 수 있는 변경을 제한할 가능성도 (매우 적음) 있습니다. 와 더불어 RRO 프레임워크 Android M의 기능 상태에 존재하므로 Google은 OEM이 RRO 스킨 형태로 외관만 변경하도록 제한할 수 있습니다. 이를 통해 더 빠른 업데이트 배포가 가능하지만 OEM이 Android를 완전히 맞춤설정할 수 있는 기회가 거부되는 대가를 치르게 됩니다.

가능할 수 있는 또 다른 경로는 다음과 같이 배송되는 모든 장치에 대해 이를 의무화하는 것입니다. Google Play 스토어는 고정된 기간(최대 2회) 동안 보안 업데이트를 보장받습니다. 연령. Play 서비스 프레임워크를 사용하여 중요한 보안 업데이트 및 패치가 있는지 확인할 수 있으며, 규정을 준수하지 않을 경우 Play 스토어 액세스가 취소됩니다.

마무리 메모

이 문제를 해결할 수 있는 우아한 방법이 없기 때문에 이것은 여전히 ​​추측일 뿐입니다. 매우 전체주의적인 접근 방식이 없으면 수정에 도달하는 데 항상 몇 가지 단점이 있습니다. 시중에 나와 있는 Android 기기의 수는 엄청나게 많기 때문에 각 기기의 보안 상태를 추적하는 것은 매우 큰 작업입니다. 현재의 방식이 확실히 최고는 아니기 때문에 Android 업데이트 방식을 다시 생각하는 것이 시급합니다. XDA 개발자는 Android가 Google의 폐쇄 소스 계획과 협력하면서 계속해서 오픈 소스 뿌리에 충실하기를 바랍니다.

귀하의 휴대폰이 Stagefright에 취약합니까? 귀하의 휴대폰이 Stagefright 패치를 받게 될 것이라고 생각하십니까? 아래 댓글로 알려주세요!