Google은 흑인 공동체를 위한 인종 간 평등을 진전시키기 위해 노력하고 있습니다. Google에서 어떤 노력을 하고 있는지 확인하세요.

보안 업데이트 및 리소스

Android 보안팀은 Android 플랫폼, Android 기기와 함께 번들로 제공되는 여러 핵심 Android 앱에서 발견되는 보안 취약점을 관리할 책임이 있습니다.

Android 보안팀은 내부 조사를 통해 보안 취약점을 찾아내고 타사가 신고한 버그에도 대응합니다. 외부 버그의 소스로는 Android 보안 문제 템플릿, 게시되었거나 게시되기 전인 학술 연구, 업스트림 오픈소스 프로젝트 관리자, Google의 기기 제조업체 파트너가 보낸 알림을 통해 신고된 문제와 블로그 또는 소셜 미디어에 공개적으로 게시된 문제를 들 수 있습니다.

보안 문제 신고

개발자, Android 사용자 또는 보안 연구원은 보안 취약점 신고 양식을 통해 잠재적 보안 문제를 Android 보안팀에 알릴 수 있습니다.

보안 문제로 표시된 버그는 외부에서 볼 수 없고 문제가 평가되거나 해결되고 나서야 볼 수 있습니다. 보안 문제를 해결하기 위해 패치 또는 호환성 테스트 도구 모음(CTS) 테스트를 제출하려면 AOSP에 코드를 업로드하기 전에 버그 신고에 첨부하고 응답을 기다려 주세요.

버그 분류

보안 취약점 처리를 위한 첫 번째 작업은 버그의 심각도와 영향을 받는 Android 구성요소를 식별하는 것입니다. 심각도에 따라 문제의 우선순위가 결정되고, 구성요소에 따라 누가 버그를 수정할지, 누구에게 알릴지, 수정 사항을 사용자에게 어떻게 배포할지 결정됩니다.

프로세스 유형

아래 표는 프로세스 유형의 정의를 나열한 것입니다. 프로세스 유형은 앱 또는 프로세스의 유형, 또는 애플리케이션이나 프로세스가 실행되는 영역에 따라 정의할 수 있습니다. 이 표는 가장 낮은 권한에서 가장 높은 권한 순으로 정렬되어 있습니다.

프로세스 유형 유형 정의
제한된 프로세스 고도로 제한된 SELinux 도메인에서 실행되는 프로세스
또는
일반 앱보다 훨씬 더 많이 제한된 프로세스입니다.
권한이 없는 프로세스 untrusted_app_all 속성을 사용하여 SELinux 도메인에서 실행되거나 이와 동등하게 제한된 애플리케이션 또는 프로세스입니다.
권한이 있는 프로세스 SELinux untrusted_app 도메인에서 금지될 기능이 있는 앱 또는 프로세스
또는
타사 앱에서 얻을 수 없는 중요한 권한을 보유한 앱 또는 프로세스
또는
신뢰할 수 있는 컴퓨팅 기반(TCB)에 속하지 않는 기기의 내장 하드웨어 구성요소입니다.
신뢰할 수 있는 컴퓨팅 기반(TCB) 커널의 일부이거나, 커널과 동일한 CPU 컨텍스트에서 실행되거나(예: 기기 드라이버), 커널 메모리에 직접 액세스하거나(예: 기기의 하드웨어 구성요소), 커널 구성요소인 베이스밴드 프로세서에 스크립트를 로드할 수 있는(예: eBPF) 기능입니다. 또는 커널과 동등한 것으로 간주되는 몇 가지 사용자 서비스인 init, ueventd, vold 중 하나인 기능입니다.
부트로더 부팅 시 기기를 구성한 다음 제어를 Android OS로 넘기는 구성요소입니다.
신뢰할 수 있는 실행 환경(TEE) 적대적인 커널로부터 보호되도록 설계된 구성요소입니다(예: TrustZone 및 하이퍼바이저).
보안 요소(SE) 보안 요소 소개에 정의된 대로 기기의 다른 모든 구성요소와 물리적 공격으로부터 보호되도록 설계된 선택적 구성요소입니다.

심각도

일반적으로 버그의 심각성은 버그가 악용되었을 때 발생할 수 있는 잠재적 피해를 반영합니다. 다음 기준을 사용해 심각도를 결정합니다.

등급 악용으로 인한 결과
심각
  • SE에서 보호하는 데이터에 무단으로 액세스
  • TEE 또는 SE에서 임의 코드 실행
  • 권한이 있는 프로세스, 부트로더 또는 TCB에서 원격 임의 코드 실행
  • 원격 영구 서비스 거부(기기 작동 불능: 완전히 영구적으로 지속되거나, 전체 운영체제를 다시 플래시하거나 초기화해야 함)
  • 패키지 설치 또는 이와 동등한 동작에 관한 사용자 상호작용 요구사항 원격 우회
  • 개발자, 보안 또는 개인정보 보호 설정에 관한 사용자 상호작용 요구사항 원격 우회
  • 안전한 부팅 원격 우회
  • 핵심 하드웨어 구성요소의 오작동을 방지하도록 설계된 안전 메커니즘(예: 열 보호 기능) 우회
높음
  • 안전한 부팅 로컬 우회
  • 핵심 보안 기능(예: SELinux, FDE 또는 seccomp)을 완전히 우회
  • 권한이 없는 프로세스에서 원격 임의 코드 실행
  • 권한이 있는 프로세스, 부트로더 또는 TCB에서 로컬 임의 코드 실행
  • TEE로 보호되는 데이터에 무단으로 액세스
  • 더 낮은 보안 수준 구현으로 다운그레이드되는 결과를 낳는 SE 대상 공격
  • 패키지 설치 또는 이와 동등한 동작에 관한 사용자 상호작용 요구사항 로컬 우회
  • 보호되는 데이터(권한이 있는 프로세스로 제한된 데이터)에 원격 액세스
  • 로컬 영구 서비스 거부(기기 작동 불능: 영구적으로 지속되거나, 전체 운영체제를 다시 플래시하거나 초기화해야 함)
  • 사용자 상호작용 요구사항 원격 우회(일반적으로 사용자 시작 또는 사용자 권한이 필요한 기능 또는 데이터에 액세스)
  • 요청자가 안전한 전송을 기대할 때 안전하지 않은 네트워크 프로토콜(예: HTTP 및 암호화되지 않은 블루투스)을 통해 민감한 정보 전송(WEP와 같은 Wi-Fi 암호화에는 적용되지 않음)
  • 부트로더, TEE 또는 SE의 심층 방어 또는 악용 완화 기술을 일반적으로 우회
  • 앱 데이터 또는 사용자 프로필을 서로 분리하는 운영체제 보호를 일반적으로 우회
  • 개발자, 보안 또는 개인정보 보호 설정에 관한 사용자 상호작용 요구사항 로컬 우회
  • 경로별 공격자를 허용하는 표준 TLS(전송 계층 보안)의 암호화 취약점
  • 잠금 화면 우회
  • 기기 보호/초기화 보호/이동통신사 제한사항 우회
  • 응급 서비스 액세스를 선별적으로 차단
  • TEE로 보호되는 사용자 상호작용 요구사항 우회
보통
  • 제한된 프로세스에서 원격 임의 코드 실행
  • 원격 임시 기기 서비스 거부(원격 중단 또는 재부팅)
  • 권한이 없는 프로세스에서 로컬 임의 코드 실행
  • 권한이 있는 프로세스 또는 TCB의 심층 방어 또는 악용 완화 기술을 일반적으로 우회
  • 제한된 프로세스에 관한 제한사항 우회
  • 보호되지 않는 데이터(로컬에 설치된 모든 앱에서 통상적으로 액세스할 수 있는 데이터)에 원격 액세스
  • 보호되는 데이터(권한이 있는 프로세스로 제한된 데이터)에 로컬 액세스
  • 사용자 상호작용 요구사항 원격 우회(일반적으로 사용자 시작 또는 사용자 권한이 필요한 기능 또는 데이터에 액세스)
  • TLS에서 사용되는 프리미티브가 아닌 일반 텍스트의 누출을 허용하는 표준 암호화 프리미티브의 암호화 취약점
  • Wi-Fi 암호화 또는 인증 우회
낮음
  • 제한된 프로세스에서 로컬 임의 코드 실행
  • 비표준 사용 시 암호화 취약점
  • 권한이 없는 프로세스의 사용자 수준 심층 방어 또는 악용 완화 기술을 일반적으로 우회
미미한 보안 영향(NSI)
  • 기본 코드 문제가 여전히 있을 수 있지만 하나 이상의 등급 수정자 또는 버전별 아키텍처 변경으로 영향이 완화되어 결과적인 심각도가 낮음 이하인 취약점
  • 잘못된 형식의 파일 시스템을 필요로 하는 취약점. 단, 파일 시스템이 사용 전에 반드시 채택/암호화되는 경우에 한함.

등급 수정자

보안 취약점의 심각도를 쉽게 식별할 수 있는 경우가 많지만 상황에 따라 등급이 달라질 수 있습니다.

이유 결과
공격을 실행하려면 권한이 있는 프로세스로 실행해야 합니다. 심각도 1 감소
취약점별 세부정보로 인해 문제의 영향력이 제한됨 심각도 1 감소
기기 소유자에게 생체 인식 정보를 직접 요구하는 생체 인식 인증 우회 심각도 1 감소
컴파일러 또는 플랫폼 구성으로 인해 소스 코드의 취약점 완화 기본 취약점이 보통 이상 등급이라면 보통 심각도
전화가 꺼져 있거나 전원을 켠 이후 잠금 해제되지 않았더라도 기기 내부에 물리적으로 액세스하는 것이 필요하고 액세스할 수 있음 심각도 1 감소
전화가 켜져 있거나 이전에 잠금 해제된 상태에서 기기 내부에 물리적으로 액세스하는 것이 필요함 심각도 2 감소
부트로더를 잠금 해제해야 하는 로컬 공격 낮음 이하 등급
기기에서 개발자 모드 또는 영구 개발자 모드 설정을 현재 사용하도록 설정해야 하는 로컬 공격(개발자 모드 자체에서는 버그가 아님) 낮음 이하 등급
어떤 SELinux 도메인도 Google 제공 SEPolicy에서 작업을 할 수 없는 경우 미미한 보안 영향

로컬 대 근접 대 원격

원격 공격 벡터는 앱을 설치하거나 기기에 물리적으로 액세스하지 않고도 버그를 악용할 수 있음을 의미합니다. 여기에는 웹페이지 둘러보기, 이메일 읽기, SMS 메시지 수신, 적대적인 네트워크에 연결 등으로 인해 발생할 수 있는 버그가 포함됩니다. 또한 Google의 심각도 평가를 위해 Android 보안팀은 Android '근접' 공격 벡터를 원격 공격으로 간주합니다. 예를 들어 형식이 잘못된 Wi-Fi 또는 블루투스 패킷을 전송해야 하는 버그와 같이 물리적으로 대상 기기 근처에 있는 공격자만이 악용할 수 있는 버그가 여기에 해당됩니다. Android 보안팀은 NFC 기반 공격을 근접 및 원격으로 간주합니다.

로컬 공격을 위해서는 피해자가 앱을 설치하여 실행하거나 인스턴트 앱 실행에 동의함으로써 앱을 실행해야 합니다. 또한 심각도 평가를 위해 Android 보안팀은 물리적 공격 벡터를 로컬로 간주합니다. 예를 들어 잠금 화면의 버그 또는 USB 케이블을 연결해야 하는 버그와 같이 기기에 물리적으로 액세스할 수 있는 공격자만 악용할 수 있는 버그가 여기에 해당됩니다. USB 연결이 필요한 공격은 기기를 잠금 해제해야 하는지 여부와 상관없이 심각도가 동일합니다. USB에 연결되어 있는 동안 기기가 잠금 해제되는 일은 흔하게 일어납니다.

Wi-Fi 보안

Android에서는 모든 네트워크가 적대적이고 공격을 주입하거나 트래픽을 염탐할 수 있다고 가정합니다. 링크 레이어 보안(예: Wi-Fi 암호화)이 기기와 이 기기에 연결된 Wi-Fi 액세스 포인트 간의 통신은 보호하지만, 기기와 이 기기가 통신하는 서버 간의 체인에 남아 있는 링크를 보호해 주지는 못합니다.

이와 반대로, HTTPS는 일반적으로 전체 통신을 엔드 투 엔드로 보호하기 때문에 소스의 데이터를 암호화한 다음 최종 목적지에 도달할 때만 복호화하고 확인합니다. 이로 인해 Wi-Fi 보안을 훼손하는 취약점이 HTTPS/TLS의 취약점보다 덜 심각한 것으로 등급이 지정됩니다. 하지만 Wi-Fi 암호화만으로는 인터넷상의 대부분 통신에 충분하지 않습니다.

생체 인식 인증

생체 인식 인증은 까다로운 영역입니다. 최고의 시스템이라 할지라도 그에 버금가는 상대의 속임수에 넘어갈 수 있습니다. 다음의 심각도 등급은 최종 사용자에게 실제로 가해지는 위험을 반영하기 위해 두 유형의 공격을 구분해 놓은 것입니다.

첫 번째 유형의 공격에서는 공격자가 소유자의 고급 생체 인식 데이터가 없더라도 일반화 가능한 방식으로 생체 인식 인증을 우회할 수 있습니다. 예를 들어 공격자가 지문 센서에 껌을 붙일 수 있고 이로 인해 센서에 있는 잔여물로 기기에 대한 액세스 권한이 부여된다면, 이는 취약한 기기에서 얼마든지 수행할 수 있는 간단한 공격에 해당합니다. 이 공격에서는 기기 소유자에 대한 어떠한 정보도 필요하지 않습니다. 이 공격이 일반화가 가능하고 더 많은 사용자에게 영향을 미칠 가능성을 감안해 이 공격에는 최고 심각도 등급(예: 잠금 화면 우회에서는 높음)이 지정됩니다.

다른 유형의 공격에는 일반적으로 기기 소유자를 기반으로 한 프레젠테이션 공격 도구(스푸핑)가 사용됩니다. 이 생체 인식 정보를 비교적 쉽게 얻을 수 있는 경우도 있습니다(예: 누군가의 소셜 미디어 프로필 사진이 생체 인식 인증을 속이기에 충분한 경우 생체 인식 우회에는 최고 심각도 등급이 지정됨). 하지만 공격자가 기기 소유자의 생체 인식 데이터를 직접 확보해야 하는 경우(예: 적외선으로 스캔한 소유자의 얼굴) 이 점은 공격의 영향을 받는 사용자 수를 제한하기에 충분한 중요 장애 요소가 됩니다. 따라서 a -1 수정자가 있습니다.

영향을 받는 구성요소

버그 수정을 담당하는 개발팀은 버그가 어느 구성요소에 있는지에 따라 달라집니다. 구성요소는 Android 플랫폼의 핵심 구성요소, OEM에서 제공하는 커널 드라이버 또는 Pixel 기기에 미리 로드된 앱 중 하나일 수 있습니다.

AOSP 코드의 버그는 Android 엔지니어링팀에서 수정합니다. 심각도가 낮은 버그, 특정 구성요소의 버그 또는 이미 공개적으로 알려진 버그는 공개적으로 제공되는 AOSP 마스터 브랜치에서 직접 수정할 수 있습니다. 또는 먼저 Google 내부 저장소에서 수정됩니다.

또한 구성요소는 사용자가 업데이트를 받는 방식의 한 가지 요소이기도 합니다. 프레임워크나 커널의 버그에는 각 OEM에서 푸시해야 하는 무선(OTA) 펌웨어 업데이트가 필요합니다. Google Play에 게시된 앱 또는 라이브러리(예: Gmail, Google Play 서비스, WebView)의 버그는 Google Play에서 Android 사용자에게 업데이트로 전송할 수 있습니다.

파트너에게 알림

Android 보안 게시판에서 AOSP의 보안 취약점이 수정되면 Google에서는 Android 파트너에게 문제의 세부정보를 알리고 패치를 제공합니다. 백포트를 지원하는 버전의 목록은 새로운 Android 버전마다 변경됩니다. 지원되는 기기의 목록은 기기 제조업체에 문의하세요.

AOSP에 코드 출시

보안 버그가 AOSP 구성요소에 있다면 수정 사항은 OTA가 사용자에게 출시된 후에 AOSP에 푸시됩니다. 수정 사항이 OTA를 통해 기기에서 사용 가능해지기 전에 심각도가 낮은 문제의 수정 사항을 AOSP 마스터 브랜치에 직접 제출할 수 있습니다.

Android 업데이트 수신

Android 시스템 업데이트는 일반적으로 OTA 업데이트 패키지를 통해 기기에 제공됩니다. 이러한 업데이트는 기기를 생산한 OEM 또는 기기에 서비스를 제공하는 이동통신사에서 제공할 수 있습니다. Google Pixel 기기 업데이트는 이동통신사 기술 수용(TA) 테스트 절차를 거친 후 Google Pixel팀에서 제공합니다. Google에서는 기기에 사이드로드할 수 있는 Pixel 공장 출고 시 이미지도 게시합니다.

Google 서비스 업데이트

Android 보안팀은 보안 버그에 패치를 제공할 뿐만 아니라 보안 버그를 검토하여 다른 사용자 보호 방법이 있는지도 확인합니다. 예를 들어 Google Play에서는 모든 앱을 검사하여 보안 버그를 악용하려는 앱을 모두 삭제합니다. Google Play 외부에서 설치한 앱의 경우 Google Play 서비스를 사용하는 기기에서도 앱 인증 기능을 사용하여 해를 끼칠 가능성이 있는 앱에 관해 사용자에게 경고할 수 있습니다.

기타 자료

Android 앱 개발자를 위한 정보: https://developer.android.com

보안 정보는 Android 오픈소스 및 개발자 사이트 전체에 존재합니다. 먼저 다음 자료를 검토해 볼 것을 추천합니다.

보고서

때때로 Android 보안팀에서 보고서 또는 백서를 게시합니다. 자세한 내용은 보안 보고서를 참조하세요.