Cập nhật bảo mật và tài nguyên

Nhóm bảo mật Android chịu trách nhiệm quản lý các lỗ hổng bảo mật được phát hiện trong nền tảng Android và nhiều ứng dụng Android cốt lõi đi kèm với thiết bị Android.

Nhóm bảo mật Android tìm thấy các lỗ hổng bảo mật thông qua nghiên cứu nội bộ và cũng phản hồi các lỗi do bên thứ ba báo cáo. Các nguồn lỗi bên ngoài bao gồm các vấn đề được báo cáo thông qua biểu mẫu lỗ hổng , nghiên cứu học thuật đã xuất bản và xuất bản trước, những người bảo trì dự án nguồn mở ngược dòng, thông báo từ các đối tác sản xuất thiết bị của chúng tôi và các vấn đề được tiết lộ công khai được đăng trên blog hoặc phương tiện truyền thông xã hội.

Báo cáo vấn đề bảo mật

Bất kỳ nhà phát triển, người dùng Android hoặc nhà nghiên cứu bảo mật nào cũng có thể thông báo cho nhóm bảo mật Android về các vấn đề bảo mật tiềm ẩn thông qua biểu mẫu lỗ hổng .

Các lỗi được đánh dấu là sự cố bảo mật không hiển thị bên ngoài nhưng cuối cùng chúng có thể hiển thị sau khi sự cố được đánh giá hoặc giải quyết. Nếu bạn dự định gửi bản vá hoặc bản kiểm tra Bộ kiểm tra khả năng tương thích (CTS) để giải quyết vấn đề bảo mật, vui lòng đính kèm bản vá đó vào báo cáo lỗi và đợi phản hồi trước khi tải mã lên AOSP.

Xử lý lỗi

Nhiệm vụ đầu tiên trong việc xử lý lỗ hổng bảo mật là xác định mức độ nghiêm trọng của lỗi và thành phần nào của Android bị ảnh hưởng. Mức độ nghiêm trọng xác định mức độ ưu tiên của vấn đề và thành phần xác định ai sửa lỗi, ai được thông báo và cách triển khai bản sửa lỗi cho người dùng.

Các loại ngữ cảnh

Bảng này bao gồm các định nghĩa về bối cảnh bảo mật phần cứng và phần mềm. Bối cảnh có thể được xác định bởi độ nhạy cảm của dữ liệu mà nó thường xử lý hoặc khu vực mà nó chạy. Không phải tất cả các bối cảnh bảo mật đều có thể áp dụng cho tất cả các hệ thống. Bảng này được sắp xếp từ ít nhất đến đặc quyền nhất.

loại ngữ cảnh định nghĩa loại
Bối cảnh ràng buộc Một môi trường thực thi bị hạn chế, nơi chỉ cung cấp các quyền tối thiểu nhất.

Ví dụ: các ứng dụng đáng tin cậy xử lý dữ liệu không đáng tin cậy trong môi trường hộp cát.
Bối cảnh không có đặc quyền Một môi trường thực thi điển hình được mong đợi bởi mã không có đặc quyền.

Ví dụ: một ứng dụng Android chạy trong miền SELinux có thuộc tính untrusted_app_all .
bối cảnh đặc quyền Môi trường thực thi đặc quyền có thể có quyền truy cập vào các quyền nâng cao, xử lý nhiều PII người dùng và/hoặc duy trì tính toàn vẹn của hệ thống.

Ví dụ: một ứng dụng Android có các khả năng sẽ bị cấm bởi miền untrusted_app của SELinux hoặc có quyền truy cập vào các quyền privileged|signature .
nhân hệ điều hành Chức năng mà:
  • là một phần của hạt nhân
  • chạy trong cùng ngữ cảnh CPU với nhân (ví dụ: trình điều khiển thiết bị)
  • có quyền truy cập trực tiếp vào bộ nhớ kernel (ví dụ: các thành phần phần cứng trên thiết bị)
  • có khả năng tải tập lệnh vào thành phần nhân (ví dụ: eBPF)
  • là một trong số ít các dịch vụ người dùng được coi là tương đương với nhân (chẳng hạn như apexd , bpfloader , init , ueventd và vold ).
Cơ sở phần cứng đáng tin cậy (THB) Các thành phần phần cứng riêng biệt, thường là trên SoC, cung cấp chức năng quan trọng cho các trường hợp sử dụng cốt lõi của thiết bị (chẳng hạn như dải cơ sở di động, DSP, GPU và bộ xử lý ML).
Chuỗi bộ nạp khởi động Một thành phần định cấu hình thiết bị khi khởi động và sau đó chuyển quyền điều khiển cho HĐH Android.
Môi trường thực thi đáng tin cậy (TEE) Một thành phần được thiết kế để được bảo vệ khỏi cả Nhân hệ điều hành thù địch (ví dụ: TrustZone và các trình ảo hóa, chẳng hạn như pKVM, bảo vệ Máy ảo khỏi Nhân hệ điều hành).
Vùng an toàn / Phần tử bảo mật (SE) Một thành phần phần cứng tùy chọn được thiết kế để bảo vệ khỏi tất cả các thành phần khác trên thiết bị và khỏi tấn công vật lý, như được định nghĩa trong Giới thiệu về các Thành phần Bảo mật .

Điều này bao gồm chip Titan-M có trong một số thiết bị Android.

mức độ nghiêm trọng

Mức độ nghiêm trọng của một lỗi thường phản ánh tác hại tiềm tàng có thể xảy ra nếu một lỗi được khai thác thành công. Sử dụng các tiêu chí sau để xác định mức độ nghiêm trọng.

Xếp hạng Kết quả của việc khai thác thành công
Phê bình
  • Thực thi mã tùy ý trong TEE hoặc SE
  • Bỏ qua các cơ chế phần mềm được thiết kế để ngăn các thành phần phần cứng hoặc phần mềm liên quan đến an toàn hoạt động sai (ví dụ: bảo vệ nhiệt)
  • Truy cập từ xa vào thông tin đăng nhập nhạy cảm được sử dụng để xác thực dịch vụ từ xa (ví dụ: mật khẩu tài khoản hoặc mã thông báo mang)
  • Thực thi mã tùy ý từ xa trong ngữ cảnh băng cơ sở di động mà không có sự tương tác của người dùng (ví dụ: khai thác lỗi trong dịch vụ vô tuyến di động)
  • Thực thi mã tùy ý từ xa trong ngữ cảnh đặc quyền, chuỗi bộ nạp khởi động, THB hoặc Nhân hệ điều hành
  • Bỏ qua từ xa các yêu cầu tương tác của người dùng khi cài đặt gói hoặc hành vi tương đương
  • Bỏ qua từ xa các yêu cầu tương tác của người dùng đối với cài đặt quyền riêng tư, bảo mật hoặc nhà phát triển cốt lõi
  • Từ chối dịch vụ liên tục từ xa (vĩnh viễn, yêu cầu khởi động lại toàn bộ hệ điều hành hoặc khôi phục cài đặt gốc)
  • Bỏ qua khởi động an toàn từ xa
  • Truy cập trái phép vào dữ liệu được bảo mật bởi SE, bao gồm quyền truy cập được kích hoạt bởi các khóa yếu trong SE.
Cao
  • Bỏ qua hoàn toàn tính năng bảo mật cốt lõi (ví dụ: SELinux, FBE hoặc seccomp )
  • Một đường vòng chung để phòng thủ theo chiều sâu hoặc công nghệ giảm thiểu khai thác trong chuỗi bộ nạp khởi động, TEE hoặc SE
  • Một cách bỏ qua chung cho các biện pháp bảo vệ hệ điều hành tiết lộ bộ nhớ hoặc nội dung tệp trên ranh giới ứng dụng, người dùng hoặc hồ sơ
  • Các cuộc tấn công vào một SE dẫn đến việc hạ cấp xuống một triển khai kém an toàn hơn
  • Bỏ qua bảo vệ thiết bị/bảo vệ khôi phục cài đặt gốc/hạn chế nhà cung cấp dịch vụ
  • Bỏ qua các yêu cầu tương tác của người dùng được bảo mật bởi TEE
  • Lỗ hổng mã hóa cho phép thực hiện các cuộc tấn công nhằm vào các giao thức đầu cuối, bao gồm các cuộc tấn công nhằm vào bảo mật tầng vận chuyển (TLS) và Bluetooth (BT).
  • Quyền truy cập cục bộ vào thông tin đăng nhập nhạy cảm được sử dụng để xác thực dịch vụ từ xa (ví dụ: mật khẩu tài khoản hoặc mã thông báo mang)
  • Thực thi mã tùy ý cục bộ trong ngữ cảnh đặc quyền, chuỗi bộ nạp khởi động, THB hoặc Nhân hệ điều hành
  • Bỏ qua khởi động an toàn cục bộ
  • Bỏ qua màn hình khóa
  • Bỏ qua cục bộ các yêu cầu tương tác của người dùng đối với cài đặt quyền riêng tư, bảo mật hoặc nhà phát triển cốt lõi
  • Bỏ qua cục bộ các yêu cầu tương tác của người dùng khi cài đặt gói hoặc hành vi tương đương
  • Từ chối dịch vụ liên tục cục bộ (vĩnh viễn, yêu cầu khởi động lại toàn bộ hệ điều hành hoặc khôi phục cài đặt gốc)
  • Truy cập từ xa vào dữ liệu được bảo vệ (nghĩa là dữ liệu được giới hạn trong ngữ cảnh đặc quyền)
  • Thực thi mã tùy ý từ xa trong ngữ cảnh không có đặc quyền
  • Ngăn chặn từ xa quyền truy cập vào dịch vụ di động hoặc Wi-Fi mà không có sự tương tác của người dùng (ví dụ: làm hỏng dịch vụ vô tuyến di động với một gói không đúng định dạng)
  • Bỏ qua các yêu cầu tương tác của người dùng từ xa (quyền truy cập vào chức năng hoặc dữ liệu cần có sự khởi tạo của người dùng hoặc sự cho phép của người dùng)
  • Mục tiêu ngăn chặn truy cập vào các dịch vụ khẩn cấp
  • Truyền thông tin nhạy cảm qua giao thức mạng không an toàn (ví dụ: HTTP và Bluetooth không được mã hóa) khi người yêu cầu mong đợi truyền an toàn. Lưu ý rằng điều này không áp dụng cho mã hóa Wi-Fi (chẳng hạn như WEP)
  • Truy cập trái phép vào dữ liệu được TEE bảo mật, bao gồm quyền truy cập được kích hoạt bởi các khóa yếu trong TEE
Vừa phải
  • Một đường vòng chung để bảo vệ theo chiều sâu hoặc công nghệ giảm thiểu khai thác trong ngữ cảnh đặc quyền, THB hoặc Nhân hệ điều hành
  • Một cách bỏ qua chung cho các biện pháp bảo vệ hệ điều hành tiết lộ trạng thái quy trình hoặc siêu dữ liệu trên ranh giới ứng dụng, người dùng hoặc hồ sơ
  • Bỏ qua mã hóa hoặc xác thực Wi-Fi
  • Lỗ hổng mã hóa trong các nguyên mẫu tiền điện tử tiêu chuẩn cho phép rò rỉ văn bản gốc (không phải nguyên thủy được sử dụng trong TLS)
  • Quyền truy cập cục bộ vào dữ liệu được bảo vệ (nghĩa là dữ liệu bị giới hạn trong ngữ cảnh đặc quyền)
  • Thực thi mã tùy ý cục bộ trong ngữ cảnh không có đặc quyền
  • Bỏ qua cục bộ các yêu cầu tương tác của người dùng (quyền truy cập vào chức năng hoặc dữ liệu thường yêu cầu người dùng bắt đầu hoặc sự cho phép của người dùng)
  • Truy cập từ xa vào dữ liệu không được bảo vệ (nghĩa là dữ liệu thường có thể truy cập được đối với mọi ứng dụng được cài đặt cục bộ)
  • Thực thi mã tùy ý từ xa trong ngữ cảnh bị ràng buộc
  • Từ chối dịch vụ thiết bị tạm thời từ xa (treo hoặc khởi động lại từ xa)
Thấp
  • Một cách bỏ qua chung để bảo vệ ở cấp độ người dùng theo chiều sâu hoặc khai thác công nghệ giảm thiểu trong bối cảnh không có đặc quyền
  • Bỏ qua quyền cấp bảo vệ bình thường
  • Lỗ hổng mật mã trong việc sử dụng không chuẩn
  • Bỏ qua chung các tính năng cá nhân hóa trên thiết bị như Voice Match hoặc Face Match
  • Tài liệu không chính xác có thể dẫn đến lỗ hổng bảo mật
  • Thực thi mã tùy ý cục bộ trong ngữ cảnh bị ràng buộc
  • Văn bản do hệ thống xác định bao gồm mô tả gây hiểu nhầm tạo ra kỳ vọng bảo mật sai
Tác động an ninh không đáng kể (NSI)
  • Lỗ hổng bảo mật có tác động đã được giảm nhẹ bằng một hoặc nhiều công cụ sửa đổi xếp hạng hoặc kiến ​​trúc dành riêng cho phiên bản thay đổi sao cho mức độ nghiêm trọng thực tế ở dưới mức Thấp, mặc dù vấn đề về mã cơ bản có thể vẫn còn
  • Bất kỳ lỗ hổng nào yêu cầu hệ thống tệp không đúng định dạng, nếu hệ thống tệp đó luôn được chấp nhận/mã hóa trước khi sử dụng.

Công cụ sửa đổi xếp hạng

Mặc dù mức độ nghiêm trọng của các lỗ hổng bảo mật thường dễ xác định nhưng xếp hạng có thể thay đổi tùy theo hoàn cảnh.

Lý do Tác dụng
Yêu cầu chạy dưới dạng bối cảnh đặc quyền để thực hiện cuộc tấn công (không áp dụng cho TEE, SE và các trình ảo hóa như pKVM) -1 Mức độ nghiêm trọng
Các chi tiết cụ thể về lỗ hổng hạn chế tác động của vấn đề -1 Mức độ nghiêm trọng
Bỏ qua xác thực sinh trắc học yêu cầu thông tin sinh trắc học trực tiếp từ chủ sở hữu thiết bị -1 Mức độ nghiêm trọng
Trình biên dịch hoặc cấu hình nền tảng giảm thiểu lỗ hổng trong mã nguồn Mức độ nghiêm trọng vừa phải nếu lỗ hổng cơ bản là Trung bình hoặc cao hơn
Yêu cầu quyền truy cập vật lý vào bên trong thiết bị và vẫn có thể nếu thiết bị tắt hoặc chưa được mở khóa kể từ khi bật nguồn -1 Mức độ nghiêm trọng
Yêu cầu quyền truy cập vật lý vào bên trong thiết bị khi thiết bị đang bật và trước đó đã được mở khóa -2 Mức độ nghiêm trọng
Một cuộc tấn công cục bộ yêu cầu mở khóa chuỗi bộ nạp khởi động Không cao hơn Thấp
Một cuộc tấn công cục bộ yêu cầu Chế độ nhà phát triển hoặc bất kỳ cài đặt chế độ nhà phát triển liên tục nào hiện được bật trên thiết bị (và không phải là lỗi trong Chế độ nhà phát triển). Không cao hơn Thấp
Nếu không có miền SELinux nào có thể tiến hành hoạt động theo SEPolicy do Google cung cấp Tác động bảo mật không đáng kể

Cục bộ so với Gần so với Từ xa

Vectơ tấn công từ xa chỉ ra rằng lỗi có thể bị khai thác mà không cần cài đặt ứng dụng hoặc không có quyền truy cập vật lý vào thiết bị. Điều này bao gồm các lỗi có thể được kích hoạt bằng cách duyệt một trang web, đọc email, nhận tin nhắn SMS hoặc kết nối với mạng thù địch. Với mục đích xếp hạng mức độ nghiêm trọng của chúng tôi, chúng tôi cũng coi các vectơ tấn công "gần" là từ xa. Chúng bao gồm các lỗi chỉ có thể bị khai thác bởi kẻ tấn công ở gần thiết bị mục tiêu, chẳng hạn như lỗi yêu cầu gửi các gói Wi-Fi hoặc Bluetooth không đúng định dạng. Chúng tôi coi các cuộc tấn công dựa trên băng thông siêu rộng (UWB) và NFC là gần và do đó từ xa.

Các cuộc tấn công cục bộ yêu cầu nạn nhân chạy ứng dụng, bằng cách cài đặt và chạy ứng dụng hoặc bằng cách đồng ý chạy Ứng dụng tức thì . Các thiết bị đồng hành được ghép nối sẽ được coi là cục bộ. Với mục đích xếp hạng mức độ nghiêm trọng, nhóm bảo mật Android cũng coi các vectơ tấn công vật lý là cục bộ. Chúng bao gồm các lỗi chỉ có thể bị khai thác bởi kẻ tấn công có quyền truy cập vật lý vào thiết bị, chẳng hạn như lỗi trong màn hình khóa hoặc lỗi yêu cầu cắm cáp USB.

An ninh mạng

Android giả định rằng tất cả các mạng đều là thù địch và có thể đang thực hiện các cuộc tấn công hoặc do thám lưu lượng truy cập. Mặc dù bảo mật lớp liên kết (ví dụ: mã hóa Wi-Fi) bảo vệ liên lạc giữa thiết bị và Điểm truy cập được kết nối với thiết bị đó, nhưng bảo mật lớp liên kết không làm gì để bảo mật các liên kết còn lại trong chuỗi giữa thiết bị và máy chủ mà thiết bị đang liên lạc.

Ngược lại, HTTPS thường bảo vệ toàn bộ giao tiếp từ đầu đến cuối, mã hóa dữ liệu tại nguồn, sau đó giải mã và xác minh dữ liệu đó chỉ khi dữ liệu đến đích cuối cùng. Do đó, các lỗ hổng làm tổn hại đến bảo mật mạng lớp liên kết được đánh giá là ít nghiêm trọng hơn so với các lỗ hổng trong HTTPS/TLS: Chỉ riêng mã hóa Wi-Fi là không đủ đối với hầu hết các giao tiếp trên internet.

xác thực sinh trắc học

Xác thực sinh trắc học là một không gian đầy thách thức và ngay cả những hệ thống tốt nhất cũng có thể bị đánh lừa bởi sự trùng khớp gần đúng (xem Blog dành cho nhà phát triển Android: Các cải tiến về màn hình khóa và xác thực trong Android 11 ). Các xếp hạng mức độ nghiêm trọng này phân biệt giữa hai loại tấn công và nhằm phản ánh rủi ro thực tế đối với người dùng cuối.

Loại tấn công đầu tiên cho phép bỏ qua xác thực sinh trắc học một cách tổng quát mà không cần dữ liệu sinh trắc học chất lượng cao từ chủ sở hữu. Ví dụ: nếu kẻ tấn công có thể đặt một miếng kẹo cao su lên cảm biến vân tay và nó cấp quyền truy cập vào thiết bị dựa trên dư lượng còn sót lại trên cảm biến, thì đó là một cuộc tấn công đơn giản có thể được thực hiện trên bất kỳ thiết bị dễ bị tấn công nào. Nó không yêu cầu bất kỳ kiến ​​​​thức nào về chủ sở hữu thiết bị. Vì nó có thể khái quát hóa và có khả năng ảnh hưởng đến số lượng người dùng lớn hơn nên cuộc tấn công này nhận được xếp hạng mức độ nghiêm trọng đầy đủ (ví dụ: Cao, đối với bỏ qua Màn hình khóa).

Loại tấn công khác thường liên quan đến một công cụ tấn công trình bày (giả mạo) dựa trên chủ sở hữu thiết bị. Đôi khi thông tin sinh trắc học này tương đối dễ lấy (ví dụ: nếu ảnh hồ sơ của ai đó trên mạng xã hội đủ để đánh lừa xác thực sinh trắc học, thì việc vượt qua sinh trắc học sẽ nhận được xếp hạng mức độ nghiêm trọng đầy đủ). Nhưng nếu kẻ tấn công cần lấy dữ liệu sinh trắc học trực tiếp từ chủ sở hữu thiết bị (ví dụ: quét hồng ngoại khuôn mặt của họ), thì đó là một rào cản đủ quan trọng để giới hạn số người bị ảnh hưởng bởi cuộc tấn công, do đó, có một công cụ sửa đổi -1 .

SYSTEM_ALERT_WINDOW và Tapjacking

Để biết thông tin về các chính sách của chúng tôi liên quan đến SYSTEM_ALERT_WINDOW và tapjacking, hãy xem phần " Tapjacking/overlay SYSTEM_ALERT_WINDOW trên màn hình không quan trọng về bảo mật " trên trang Lỗi không ảnh hưởng đến bảo mật của Đại học BugHunter.

Bảo mật nhiều người dùng trong Android Automotive OS

Hệ điều hành Android cho ô tô áp dụng mô hình bảo mật nhiều người dùng khác với các yếu tố hình thức khác. Mỗi người dùng Android được dự định sẽ được sử dụng bởi một người thực tế khác. Ví dụ: một người dùng khách tạm thời có thể được chỉ định cho một người bạn mượn xe từ chủ xe. Để phù hợp với các trường hợp sử dụng như thế này, theo mặc định, người dùng có quyền truy cập vào các thành phần cần thiết để sử dụng phương tiện, chẳng hạn như cài đặt mạng di động và Wi-Fi.

thành phần bị ảnh hưởng

Nhóm phát triển chịu trách nhiệm sửa lỗi tùy thuộc vào lỗi nằm trong thành phần nào. Đó có thể là thành phần cốt lõi của nền tảng Android, trình điều khiển nhân do nhà sản xuất thiết bị gốc (OEM) cung cấp hoặc một trong các ứng dụng được tải sẵn trên thiết bị Pixel .

Nhóm kỹ sư Android đã sửa các lỗi trong mã AOSP. Các lỗi có mức độ nghiêm trọng thấp, lỗi trong một số thành phần nhất định hoặc các lỗi đã được công khai có thể được sửa trực tiếp trong nhánh chính AOSP có sẵn công khai; nếu không, chúng sẽ được cố định trong kho lưu trữ nội bộ của chúng tôi trước tiên.

Thành phần này cũng là một yếu tố trong cách người dùng nhận được các bản cập nhật. Một lỗi trong khung hoặc nhân yêu cầu cập nhật chương trình cơ sở qua mạng (OTA) mà mỗi OEM cần đẩy. Lỗi trong ứng dụng hoặc thư viện được xuất bản trên Google Play (ví dụ: Gmail, Dịch vụ của Google Play hoặc WebView) có thể được gửi tới người dùng Android dưới dạng bản cập nhật từ Google Play.

Thông báo cho đối tác

Khi một lỗ hổng bảo mật trong AOSP được khắc phục trong Bản tin bảo mật Android, chúng tôi sẽ thông báo cho các đối tác Android về chi tiết vấn đề và cung cấp các bản vá. Danh sách các phiên bản hỗ trợ backport thay đổi theo từng bản phát hành Android mới. Liên hệ với nhà sản xuất thiết bị của bạn để biết danh sách các thiết bị được hỗ trợ.

Phát hành mã cho AOSP

Nếu lỗi bảo mật nằm trong thành phần AOSP, thì bản sửa lỗi sẽ được chuyển sang AOSP sau khi OTA được phát hành cho người dùng. Các bản sửa lỗi cho các sự cố ở mức độ nghiêm trọng thấp có thể được gửi trực tiếp đến nhánh chính của AOSP trước khi bản sửa lỗi có sẵn cho các thiết bị thông qua OTA.

Nhận bản cập nhật Android

Các bản cập nhật cho hệ thống Android thường được gửi đến các thiết bị thông qua các gói cập nhật OTA. Các bản cập nhật này có thể đến từ OEM đã sản xuất thiết bị hoặc nhà cung cấp dịch vụ cung cấp dịch vụ cho thiết bị. Các bản cập nhật thiết bị Google Pixel đến từ nhóm Google Pixel sau khi trải qua quy trình kiểm tra chấp nhận kỹ thuật (TA) của nhà mạng. Google cũng xuất bản hình ảnh nhà máy Pixel có thể được tải bên cạnh thiết bị.

Cập nhật các dịch vụ của Google

Ngoài việc cung cấp các bản vá lỗi bảo mật, nhóm bảo mật Android còn xem xét các lỗi bảo mật để xác định xem có cách nào khác để bảo vệ người dùng hay không. Ví dụ: Google Play quét tất cả các ứng dụng và xóa mọi ứng dụng cố khai thác lỗi bảo mật. Đối với các ứng dụng được cài đặt từ bên ngoài Google Play, các thiết bị có Dịch vụ của Google Play cũng có thể sử dụng tính năng Xác minh ứng dụng để cảnh báo người dùng về các ứng dụng có thể gây hại.

Các nguồn lực khác

Thông tin dành cho nhà phát triển ứng dụng Android: https://developer.android.com

Thông tin bảo mật tồn tại trên khắp các trang web dành cho Nhà phát triển và Nguồn mở Android. Những nơi tốt để bắt đầu:

Báo cáo

Đôi khi, nhóm Bảo mật Android xuất bản các báo cáo hoặc sách trắng. Xem Báo cáo bảo mật để biết thêm chi tiết.

,

Nhóm bảo mật Android chịu trách nhiệm quản lý các lỗ hổng bảo mật được phát hiện trong nền tảng Android và nhiều ứng dụng Android cốt lõi đi kèm với thiết bị Android.

Nhóm bảo mật Android tìm thấy các lỗ hổng bảo mật thông qua nghiên cứu nội bộ và cũng phản hồi các lỗi do bên thứ ba báo cáo. Các nguồn lỗi bên ngoài bao gồm các vấn đề được báo cáo thông qua biểu mẫu lỗ hổng , nghiên cứu học thuật đã xuất bản và xuất bản trước, những người bảo trì dự án nguồn mở ngược dòng, thông báo từ các đối tác sản xuất thiết bị của chúng tôi và các vấn đề được tiết lộ công khai được đăng trên blog hoặc phương tiện truyền thông xã hội.

Báo cáo vấn đề bảo mật

Bất kỳ nhà phát triển, người dùng Android hoặc nhà nghiên cứu bảo mật nào cũng có thể thông báo cho nhóm bảo mật Android về các vấn đề bảo mật tiềm ẩn thông qua biểu mẫu lỗ hổng .

Các lỗi được đánh dấu là sự cố bảo mật không hiển thị bên ngoài nhưng cuối cùng chúng có thể hiển thị sau khi sự cố được đánh giá hoặc giải quyết. Nếu bạn dự định gửi bản vá hoặc bản kiểm tra Bộ kiểm tra khả năng tương thích (CTS) để giải quyết vấn đề bảo mật, vui lòng đính kèm bản vá đó vào báo cáo lỗi và đợi phản hồi trước khi tải mã lên AOSP.

Xử lý lỗi

Nhiệm vụ đầu tiên trong việc xử lý lỗ hổng bảo mật là xác định mức độ nghiêm trọng của lỗi và thành phần nào của Android bị ảnh hưởng. Mức độ nghiêm trọng xác định mức độ ưu tiên của vấn đề và thành phần xác định ai sửa lỗi, ai được thông báo và cách triển khai bản sửa lỗi cho người dùng.

Các loại ngữ cảnh

Bảng này bao gồm các định nghĩa về bối cảnh bảo mật phần cứng và phần mềm. Bối cảnh có thể được xác định bởi độ nhạy cảm của dữ liệu mà nó thường xử lý hoặc khu vực mà nó chạy. Không phải tất cả các bối cảnh bảo mật đều có thể áp dụng cho tất cả các hệ thống. Bảng này được sắp xếp từ ít nhất đến đặc quyền nhất.

loại ngữ cảnh định nghĩa loại
Bối cảnh ràng buộc Một môi trường thực thi bị hạn chế, nơi chỉ cung cấp các quyền tối thiểu nhất.

Ví dụ: các ứng dụng đáng tin cậy xử lý dữ liệu không đáng tin cậy trong môi trường hộp cát.
Bối cảnh không có đặc quyền Một môi trường thực thi điển hình được mong đợi bởi mã không có đặc quyền.

Ví dụ: một ứng dụng Android chạy trong miền SELinux có thuộc tính untrusted_app_all .
bối cảnh đặc quyền Môi trường thực thi đặc quyền có thể có quyền truy cập vào các quyền nâng cao, xử lý nhiều PII người dùng và/hoặc duy trì tính toàn vẹn của hệ thống.

Ví dụ: một ứng dụng Android có các khả năng sẽ bị cấm bởi miền untrusted_app của SELinux hoặc có quyền truy cập vào các quyền privileged|signature .
nhân hệ điều hành Chức năng mà:
  • là một phần của hạt nhân
  • chạy trong cùng ngữ cảnh CPU với nhân (ví dụ: trình điều khiển thiết bị)
  • có quyền truy cập trực tiếp vào bộ nhớ kernel (ví dụ: các thành phần phần cứng trên thiết bị)
  • có khả năng tải tập lệnh vào thành phần nhân (ví dụ: eBPF)
  • là một trong số ít các dịch vụ người dùng được coi là tương đương với nhân (chẳng hạn như apexd , bpfloader , init , ueventd và vold ).
Cơ sở phần cứng đáng tin cậy (THB) Các thành phần phần cứng riêng biệt, thường là trên SoC, cung cấp chức năng quan trọng cho các trường hợp sử dụng cốt lõi của thiết bị (chẳng hạn như dải cơ sở di động, DSP, GPU và bộ xử lý ML).
Chuỗi bộ nạp khởi động Một thành phần định cấu hình thiết bị khi khởi động và sau đó chuyển quyền điều khiển cho HĐH Android.
Môi trường thực thi đáng tin cậy (TEE) Một thành phần được thiết kế để được bảo vệ khỏi cả Nhân hệ điều hành thù địch (ví dụ: TrustZone và các trình ảo hóa, chẳng hạn như pKVM, bảo vệ Máy ảo khỏi Nhân hệ điều hành).
Vùng an toàn / Phần tử bảo mật (SE) Một thành phần phần cứng tùy chọn được thiết kế để bảo vệ khỏi tất cả các thành phần khác trên thiết bị và khỏi tấn công vật lý, như được định nghĩa trong Giới thiệu về các Thành phần Bảo mật .

Điều này bao gồm chip Titan-M có trong một số thiết bị Android.

mức độ nghiêm trọng

Mức độ nghiêm trọng của một lỗi thường phản ánh tác hại tiềm tàng có thể xảy ra nếu một lỗi được khai thác thành công. Sử dụng các tiêu chí sau để xác định mức độ nghiêm trọng.

Xếp hạng Kết quả của việc khai thác thành công
Phê bình
  • Thực thi mã tùy ý trong TEE hoặc SE
  • Bỏ qua các cơ chế phần mềm được thiết kế để ngăn các thành phần phần cứng hoặc phần mềm liên quan đến an toàn hoạt động sai (ví dụ: bảo vệ nhiệt)
  • Truy cập từ xa vào thông tin đăng nhập nhạy cảm được sử dụng để xác thực dịch vụ từ xa (ví dụ: mật khẩu tài khoản hoặc mã thông báo mang)
  • Thực thi mã tùy ý từ xa trong ngữ cảnh băng cơ sở di động mà không có sự tương tác của người dùng (ví dụ: khai thác lỗi trong dịch vụ vô tuyến di động)
  • Thực thi mã tùy ý từ xa trong ngữ cảnh đặc quyền, chuỗi bộ nạp khởi động, THB hoặc Nhân hệ điều hành
  • Bỏ qua từ xa các yêu cầu tương tác của người dùng khi cài đặt gói hoặc hành vi tương đương
  • Bỏ qua từ xa các yêu cầu tương tác của người dùng đối với cài đặt quyền riêng tư, bảo mật hoặc nhà phát triển cốt lõi
  • Từ chối dịch vụ liên tục từ xa (vĩnh viễn, yêu cầu khởi động lại toàn bộ hệ điều hành hoặc khôi phục cài đặt gốc)
  • Bỏ qua khởi động an toàn từ xa
  • Truy cập trái phép vào dữ liệu được bảo mật bởi SE, bao gồm quyền truy cập được kích hoạt bởi các khóa yếu trong SE.
Cao
  • Bỏ qua hoàn toàn tính năng bảo mật cốt lõi (ví dụ: SELinux, FBE hoặc seccomp )
  • Một đường vòng chung để phòng thủ theo chiều sâu hoặc công nghệ giảm thiểu khai thác trong chuỗi bộ nạp khởi động, TEE hoặc SE
  • Một cách bỏ qua chung cho các biện pháp bảo vệ hệ điều hành tiết lộ bộ nhớ hoặc nội dung tệp trên ranh giới ứng dụng, người dùng hoặc hồ sơ
  • Các cuộc tấn công vào một SE dẫn đến việc hạ cấp xuống một triển khai kém an toàn hơn
  • Bỏ qua bảo vệ thiết bị/bảo vệ khôi phục cài đặt gốc/hạn chế nhà cung cấp dịch vụ
  • Bỏ qua các yêu cầu tương tác của người dùng được bảo mật bởi TEE
  • Lỗ hổng mật mã cho phép thực hiện các cuộc tấn công nhằm vào các giao thức đầu cuối, bao gồm các cuộc tấn công nhằm vào bảo mật tầng vận chuyển (TLS) và Bluetooth (BT).
  • Quyền truy cập cục bộ vào thông tin đăng nhập nhạy cảm được sử dụng để xác thực dịch vụ từ xa (ví dụ: mật khẩu tài khoản hoặc mã thông báo mang)
  • Thực thi mã tùy ý cục bộ trong ngữ cảnh đặc quyền, chuỗi bộ nạp khởi động, THB hoặc Nhân hệ điều hành
  • Bỏ qua khởi động an toàn cục bộ
  • Bỏ qua màn hình khóa
  • Bỏ qua cục bộ các yêu cầu tương tác của người dùng đối với cài đặt quyền riêng tư, bảo mật hoặc nhà phát triển cốt lõi
  • Bỏ qua cục bộ các yêu cầu tương tác của người dùng khi cài đặt gói hoặc hành vi tương đương
  • Từ chối dịch vụ liên tục cục bộ (vĩnh viễn, yêu cầu khởi động lại toàn bộ hệ điều hành hoặc khôi phục cài đặt gốc)
  • Truy cập từ xa vào dữ liệu được bảo vệ (nghĩa là dữ liệu được giới hạn trong ngữ cảnh đặc quyền)
  • Thực thi mã tùy ý từ xa trong ngữ cảnh không có đặc quyền
  • Ngăn chặn từ xa quyền truy cập vào dịch vụ di động hoặc Wi-Fi mà không có sự tương tác của người dùng (ví dụ: làm hỏng dịch vụ vô tuyến di động với một gói không đúng định dạng)
  • Bỏ qua các yêu cầu tương tác của người dùng từ xa (quyền truy cập vào chức năng hoặc dữ liệu cần có sự khởi tạo của người dùng hoặc sự cho phép của người dùng)
  • Mục tiêu ngăn chặn truy cập vào các dịch vụ khẩn cấp
  • Truyền thông tin nhạy cảm qua giao thức mạng không an toàn (ví dụ: HTTP và Bluetooth không được mã hóa) khi người yêu cầu mong đợi truyền an toàn. Lưu ý rằng điều này không áp dụng cho mã hóa Wi-Fi (chẳng hạn như WEP)
  • Truy cập trái phép vào dữ liệu được TEE bảo mật, bao gồm quyền truy cập được kích hoạt bởi các khóa yếu trong TEE
Vừa phải
  • Một đường vòng chung để bảo vệ theo chiều sâu hoặc công nghệ giảm thiểu khai thác trong ngữ cảnh đặc quyền, THB hoặc Nhân hệ điều hành
  • Một cách bỏ qua chung cho các biện pháp bảo vệ hệ điều hành tiết lộ trạng thái quy trình hoặc siêu dữ liệu trên ranh giới ứng dụng, người dùng hoặc hồ sơ
  • Bỏ qua mã hóa hoặc xác thực Wi-Fi
  • Lỗ hổng mã hóa trong các nguyên mẫu tiền điện tử tiêu chuẩn cho phép rò rỉ văn bản gốc (không phải nguyên thủy được sử dụng trong TLS)
  • Quyền truy cập cục bộ vào dữ liệu được bảo vệ (nghĩa là dữ liệu bị giới hạn trong ngữ cảnh đặc quyền)
  • Thực thi mã tùy ý cục bộ trong ngữ cảnh không có đặc quyền
  • Bỏ qua cục bộ các yêu cầu tương tác của người dùng (quyền truy cập vào chức năng hoặc dữ liệu thường yêu cầu người dùng bắt đầu hoặc sự cho phép của người dùng)
  • Truy cập từ xa vào dữ liệu không được bảo vệ (nghĩa là dữ liệu thường có thể truy cập được đối với mọi ứng dụng được cài đặt cục bộ)
  • Thực thi mã tùy ý từ xa trong ngữ cảnh bị ràng buộc
  • Từ chối dịch vụ thiết bị tạm thời từ xa (treo hoặc khởi động lại từ xa)
Thấp
  • Một cách bỏ qua chung để bảo vệ ở cấp độ người dùng theo chiều sâu hoặc khai thác công nghệ giảm thiểu trong bối cảnh không có đặc quyền
  • Bỏ qua quyền cấp bảo vệ bình thường
  • Lỗ hổng mật mã trong việc sử dụng không chuẩn
  • Bỏ qua chung các tính năng cá nhân hóa trên thiết bị như Voice Match hoặc Face Match
  • Tài liệu không chính xác có thể dẫn đến lỗ hổng bảo mật
  • Thực thi mã tùy ý cục bộ trong ngữ cảnh bị ràng buộc
  • Văn bản do hệ thống xác định bao gồm mô tả gây hiểu nhầm tạo ra kỳ vọng bảo mật sai
Tác động an ninh không đáng kể (NSI)
  • Lỗ hổng bảo mật có tác động đã được giảm nhẹ bằng một hoặc nhiều công cụ sửa đổi xếp hạng hoặc kiến ​​trúc dành riêng cho phiên bản thay đổi sao cho mức độ nghiêm trọng thực tế ở dưới mức Thấp, mặc dù vấn đề về mã cơ bản có thể vẫn còn
  • Bất kỳ lỗ hổng nào yêu cầu hệ thống tệp không đúng định dạng, nếu hệ thống tệp đó luôn được chấp nhận/mã hóa trước khi sử dụng.

Công cụ sửa đổi xếp hạng

Mặc dù mức độ nghiêm trọng của các lỗ hổng bảo mật thường dễ xác định nhưng xếp hạng có thể thay đổi tùy theo hoàn cảnh.

Lý do Tác dụng
Yêu cầu chạy dưới dạng bối cảnh đặc quyền để thực hiện cuộc tấn công (không áp dụng cho TEE, SE và các trình ảo hóa như pKVM) -1 Mức độ nghiêm trọng
Các chi tiết cụ thể về lỗ hổng hạn chế tác động của vấn đề -1 Mức độ nghiêm trọng
Bỏ qua xác thực sinh trắc học yêu cầu thông tin sinh trắc học trực tiếp từ chủ sở hữu thiết bị -1 Mức độ nghiêm trọng
Trình biên dịch hoặc cấu hình nền tảng giảm thiểu lỗ hổng trong mã nguồn Mức độ nghiêm trọng vừa phải nếu lỗ hổng cơ bản là Trung bình hoặc cao hơn
Yêu cầu quyền truy cập vật lý vào bên trong thiết bị và vẫn có thể nếu thiết bị tắt hoặc chưa được mở khóa kể từ khi bật nguồn -1 Mức độ nghiêm trọng
Yêu cầu quyền truy cập vật lý vào bên trong thiết bị khi thiết bị đang bật và trước đó đã được mở khóa -2 Mức độ nghiêm trọng
Một cuộc tấn công cục bộ yêu cầu mở khóa chuỗi bộ nạp khởi động Không cao hơn Thấp
Một cuộc tấn công cục bộ yêu cầu Chế độ nhà phát triển hoặc bất kỳ cài đặt chế độ nhà phát triển liên tục nào hiện được bật trên thiết bị (và không phải là lỗi trong Chế độ nhà phát triển). Không cao hơn Thấp
Nếu không có miền SELinux nào có thể tiến hành hoạt động theo SEPolicy do Google cung cấp Tác động bảo mật không đáng kể

Cục bộ so với Gần so với Từ xa

Vectơ tấn công từ xa chỉ ra rằng lỗi có thể bị khai thác mà không cần cài đặt ứng dụng hoặc không có quyền truy cập vật lý vào thiết bị. Điều này bao gồm các lỗi có thể được kích hoạt bằng cách duyệt một trang web, đọc email, nhận tin nhắn SMS hoặc kết nối với mạng thù địch. Với mục đích xếp hạng mức độ nghiêm trọng của chúng tôi, chúng tôi cũng coi các vectơ tấn công "gần" là từ xa. Chúng bao gồm các lỗi chỉ có thể bị khai thác bởi kẻ tấn công ở gần thiết bị mục tiêu, chẳng hạn như lỗi yêu cầu gửi các gói Wi-Fi hoặc Bluetooth không đúng định dạng. Chúng tôi coi các cuộc tấn công dựa trên băng thông siêu rộng (UWB) và NFC là gần và do đó từ xa.

Các cuộc tấn công cục bộ yêu cầu nạn nhân chạy ứng dụng, bằng cách cài đặt và chạy ứng dụng hoặc bằng cách đồng ý chạy Ứng dụng tức thì . Các thiết bị đồng hành được ghép nối sẽ được coi là cục bộ. Với mục đích xếp hạng mức độ nghiêm trọng, nhóm bảo mật Android cũng coi các vectơ tấn công vật lý là cục bộ. Chúng bao gồm các lỗi chỉ có thể bị khai thác bởi kẻ tấn công có quyền truy cập vật lý vào thiết bị, chẳng hạn như lỗi trong màn hình khóa hoặc lỗi yêu cầu cắm cáp USB.

An ninh mạng

Android giả định rằng tất cả các mạng đều là thù địch và có thể đang thực hiện các cuộc tấn công hoặc do thám lưu lượng truy cập. Mặc dù bảo mật lớp liên kết (ví dụ: mã hóa Wi-Fi) bảo vệ liên lạc giữa thiết bị và Điểm truy cập được kết nối với thiết bị đó, nhưng bảo mật lớp liên kết không làm gì để bảo mật các liên kết còn lại trong chuỗi giữa thiết bị và máy chủ mà thiết bị đang liên lạc.

Ngược lại, HTTPS thường bảo vệ toàn bộ giao tiếp từ đầu đến cuối, mã hóa dữ liệu tại nguồn, sau đó giải mã và xác minh dữ liệu đó chỉ khi dữ liệu đến đích cuối cùng. Do đó, các lỗ hổng làm tổn hại đến bảo mật mạng lớp liên kết được đánh giá là ít nghiêm trọng hơn so với các lỗ hổng trong HTTPS/TLS: Chỉ riêng mã hóa Wi-Fi là không đủ đối với hầu hết các giao tiếp trên internet.

xác thực sinh trắc học

Xác thực sinh trắc học là một không gian đầy thách thức và ngay cả những hệ thống tốt nhất cũng có thể bị đánh lừa bởi sự trùng khớp gần đúng (xem Blog dành cho nhà phát triển Android: Các cải tiến về màn hình khóa và xác thực trong Android 11 ). Các xếp hạng mức độ nghiêm trọng này phân biệt giữa hai loại tấn công và nhằm phản ánh rủi ro thực tế đối với người dùng cuối.

Loại tấn công đầu tiên cho phép bỏ qua xác thực sinh trắc học một cách tổng quát mà không cần dữ liệu sinh trắc học chất lượng cao từ chủ sở hữu. Ví dụ: nếu kẻ tấn công có thể đặt một miếng kẹo cao su lên cảm biến vân tay và nó cấp quyền truy cập vào thiết bị dựa trên dư lượng còn sót lại trên cảm biến, thì đó là một cuộc tấn công đơn giản có thể được thực hiện trên bất kỳ thiết bị dễ bị tấn công nào. Nó không yêu cầu bất kỳ kiến ​​​​thức nào về chủ sở hữu thiết bị. Vì nó có thể khái quát hóa và có khả năng ảnh hưởng đến số lượng người dùng lớn hơn nên cuộc tấn công này nhận được xếp hạng mức độ nghiêm trọng đầy đủ (ví dụ: Cao, đối với bỏ qua Màn hình khóa).

Loại tấn công khác thường liên quan đến một công cụ tấn công trình bày (giả mạo) dựa trên chủ sở hữu thiết bị. Đôi khi thông tin sinh trắc học này tương đối dễ lấy (ví dụ: nếu ảnh hồ sơ của ai đó trên mạng xã hội đủ để đánh lừa xác thực sinh trắc học, thì việc vượt qua sinh trắc học sẽ nhận được xếp hạng mức độ nghiêm trọng đầy đủ). But if an attacker would need to acquire biometric data directly from the device owner (for example, an infrared scan of their face), that's a significant enough barrier that it limits the number of people affected by the attack, so there's a -1 modifier.

SYSTEM_ALERT_WINDOW and Tapjacking

For information about our policies regarding SYSTEM_ALERT_WINDOW and tapjacking, see the " Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen " section of BugHunter University's Bugs with no security impact page.

Multi-user security in Android Automotive OS

Android Automotive OS adopts a multi user security model different from the other form factors. Each Android user is intended to be used by a different physical person. For example, a temporary guest user can be assigned to a friend who borrows the vehicle from the car's owner. To accommodate use cases like this, users by default have access to necessary components needed to use the vehicle, such as Wi-Fi and cellular network settings.

Affected component

The development team responsible for fixing the bug depends on which component the bug is in. It could be a core component of the Android platform, a kernel driver supplied by an original equipment manufacturer (OEM), or one of the preloaded apps on Pixel devices.

Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs, bugs in certain components, or bugs that are already publicly known may be fixed directly in the publicly available AOSP main branch; otherwise they're fixed in our internal repositories first.

The component is also a factor in how users get updates. A bug in the framework or kernel requires an over-the-air (OTA) firmware update that each OEM needs to push. A bug in an app or library published in Google Play (for example, Gmail, Google Play Services, or WebView) can be sent to Android users as an update from Google Play.

Notifying partners

When a security vulnerability in AOSP is fixed in an Android Security Bulletin, we'll notify Android partners of issue details and provide patches. The list of backport-supported versions changes with each new Android release. Contact your device manufacturer for the list of supported devices.

Releasing code to AOSP

If the security bug is in an AOSP component, the fix is pushed out to AOSP after the OTA is released to users. Fixes for low-severity issues may be submitted directly to the AOSP main branch before a fix is available to devices through an OTA.

Receiving Android updates

Updates to the Android system are generally delivered to devices through OTA update packages. These updates may come from the OEM who produced the device or the carrier who provides service to the device. Google Pixel device updates come from the Google Pixel team after going through a carrier technical acceptance (TA) testing procedure. Google also publishes Pixel factory images that can be side-loaded to devices.

Updating Google services

In addition to providing patches for security bugs, the Android security team reviews security bugs to determine if there are other ways to protect users. For example, Google Play scans all apps and removes any app that attempts to exploit a security bug. For apps installed from outside of Google Play, devices with Google Play Services may also use the Verify Apps feature to warn users about apps that may be potentially harmful.

Other resources

Information for Android app developers: https://developer.android.com

Security information exists throughout the Android Open Source and Developer sites. Good places to start:

Reports

Sometimes the Android Security team publishes reports or whitepapers. See Security Reports for more details.