보안 업데이트 및 리소스

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

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

보안 문제 신고

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

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

버그 분류

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

컨텍스트 유형

아래 표는 하드웨어와 소프트웨어 보안 컨텍스트의 정의를 나열한 것입니다. 컨텍스트는 해당 컨텍스트에서 일반적으로 처리되는 데이터의 민감도 또는 컨텍스트가 실행되는 영역으로 정의할 수 있습니다. 모든 보안 컨텍스트가 모든 시스템에 적용되지는 않습니다. 이 표는 가장 낮은 권한에서 가장 높은 권한순으로 정렬되어 있습니다.

컨텍스트 유형 유형 정의
제한된 컨텍스트 최소한의 권한만 제공되는 제한된 실행 환경입니다.

샌드박스 환경에서 신뢰할 수 없는 데이터를 처리하는 신뢰할 수 있는 애플리케이션을 예로 들 수 있습니다.
권한이 없는 컨텍스트 권한이 없는 코드에 사용되는 일반적인 실행 환경입니다.

untrusted_app_all 속성을 사용하여 SELinux 도메인에서 실행되는 Android 애플리케이션을 예로 들 수 있습니다.
권한이 있는 컨텍스트 승격된 권한에 액세스할 수 있거나 여러 사용자 PII를 처리하거나 시스템 무결성을 유지하는 등 권한에 따라 실행 범위가 결정되는 환경입니다.

SELinux untrusted_app 도메인에 의해 금지될 것 같은 기능이 있거나 privileged|signature 권한에 액세스할 수 있는 Android 애플리케이션을 예로 들 수 있습니다.
OS 커널 다음과 같은 기능
  • 커널의 일부입니다.
  • 커널과 동일한 CPU 컨텍스트에서 실행됩니다(예: 기기 드라이버).
  • 커널 메모리에 직접 액세스할 수 있습니다(예: 기기의 하드웨어 구성요소).
  • 커널 구성요소(예: eBPF)에 스크립트를 로드하는 기능이 있습니다.
  • 커널과 동등한 것으로 간주되는 소수의 사용자 서비스 중 하나(예: apexd, bpfloader, init, ueventd, vold)입니다.
신뢰할 수 있는 하드웨어 기반(THB) 주로 SoC에 있는 개별 하드웨어 구성요소로, 기기의 핵심 사용 사례에 중요한 기능을 제공합니다(예: 셀룰러 베이스밴드, DSP, GPU, ML 프로세서).
부트로더 체인 부팅 시 기기를 구성한 다음 제어를 Android OS로 넘기는 구성요소입니다.
신뢰할 수 있는 실행 환경(TEE) 적대적인 OS 커널로부터 보호되도록 설계된 구성요소입니다(예: OS 커널로부터 가상 머신을 보호하는 pKVM과 같은 하이퍼바이저, TrustZone).
보안 엔클레이브/보안 요소(SE) 보안 요소 소개에 정의된 대로 기기의 다른 모든 구성요소와 물리적 공격으로부터 보호되도록 설계된 선택적 하드웨어 구성요소입니다.

여기에는 일부 Android 기기에 있는 Titan M 칩도 포함됩니다.

심각도

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

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

등급 수정자

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

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

로컬 대 근접 대 원격

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

로컬 공격을 위해서는 피해자가 앱을 설치하여 실행하거나 인스턴트 앱 실행에 동의함으로써 앱을 실행해야 합니다. 페어링된 컴패니언 기기는 로컬로 간주됩니다. Android 보안팀은 심각도 평가 맥락에서 물리적 공격 벡터를 로컬로 간주합니다. 예를 들어 잠금 화면의 버그 또는 USB 케이블을 연결해야 하는 버그와 같이 기기에 물리적으로 액세스할 수 있는 공격자만 악용할 수 있는 버그가 여기에 해당됩니다.

네트워크 보안

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

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

생체 인식 인증

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

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

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

SYSTEM_ALERT_WINDOW 및 Tapjacking

SYSTEM_ALERT_WINDOW 및 tapjacking에 관한 Google 정책 정보는 BugHunter University의 Bugs with no security impact 페이지에서 'Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen' 섹션을 참고하세요.

Android Automotive OS의 멀티 사용자 보안

Android Automotive OS는 여느 폼 팩터와 다른 멀티 사용자 보안 모델을 채택합니다. 각 Android 사용자는 실제로 한 사람이 사용해야 합니다. 예를 들어 자동차 소유자에게서 차량을 빌려 쓰는 친구에게는 임시 게스트 사용자를 할당할 수 있습니다. 이러한 사용 사례를 수용하기 위해, 사용자는 차량을 사용하는 데 필요한 필수 구성요소(예: Wi-Fi, 셀룰러 네트워크 설정 등)에 기본적으로 액세스할 수 있습니다.

영향을 받는 구성요소

버그 수정을 담당하는 개발팀은 버그가 어느 구성요소에 있는지에 따라 달라집니다. 구성요소는 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 보안팀에서 보고서 또는 백서를 게시합니다. 자세한 내용은 보안 보고서를 참조하세요.