Bản cập nhật và tài nguyên bảo mậ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 những vấn đề được báo cáo thông qua biểu mẫu báo cáo lỗ hổng, nghiên cứu học thuật đã xuất bản và chưa xuất bản, người duy trì dự án nguồn mở thượng nguồn, thông báo từ các đối tác là nhà sản xuất thiết bị và những vấn đề được công bố công khai trên blog hoặc mạng xã hội.

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

Mọi nhà phát triển, người dùng Android hoặc nhà nghiên cứu bảo mật đều 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 báo cáo lỗ hổng.

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

Phân loại lỗi

Nhiệm vụ đầu tiên khi xử lý một 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 cách ưu tiên vấn đề, còn thành phần xác định người khắc phục lỗi, người được thông báo và cách triển khai bản sửa lỗi cho người dùng.

Loại ngữ cảnh

Bảng này trình bày định nghĩa về các ngữ 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ằng độ nhạy 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 ngữ cảnh bảo mật đều áp dụng cho mọi hệ thống. Bảng này được sắp xếp theo thứ tự từ ít đặc quyền nhất đến nhiều đặc quyền nhất.

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

Ví dụ: các ứng dụng đáng tin cậy xử lý dữ liệu không đáng tin cậy trong một môi trường hộp cát.
Ngữ cảnh không có đặc quyền Môi trường thực thi thông thường mà mã không có đặc quyền dự kiế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ột 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 thông tin nhận dạng cá nhân của 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 chức năng bị miền SELinux untrusted_app cấm hoặc có quyền truy cập vào privileged|signature.
Nhân hệ điều hành Chức năng:
  • là một phần của nhân hệ điều hành
  • chạy trong cùng một 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 một thành phần hạt nhân (ví dụ: eBPF)
  • là một trong số ít 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 rời rạc, thường nằm 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ư băng tần cơ sở di động, DSP, GPU và bộ xử lý ML).
Chuỗi trình tải khởi động Một thành phần định cấu hình thiết bị khi khởi động, sau đó chuyển quyền kiểm soát cho hệ điều hành 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ệ ngay cả khỏi một nhân hệ điều hành thù địch (ví dụ: TrustZone và trình giám sát siêu vi, chẳng hạn như pKVM, giúp bảo vệ Máy ảo khỏi nhân hệ điều hành).
Vùng bảo mật / Phần tử bảo mật (SE) Một thành phần phần cứng không bắt buộc được thiết kế để bảo vệ khỏi mọi thành phần khác trên thiết bị và khỏi các cuộc tấn công vật lý, như được xác định trong Giới thiệu về các phần tử bảo mật.

Trong đó có cả chip Titan-M trên 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 mức độ thiệt hại tiềm ẩn có thể xảy ra nếu lỗi đó bị khai thác thành công. Hãy sử dụng các tiêu chí sau để xác định mức độ nghiêm trọng.

Rating Hậu quả của việc khai thác thành công
Quan trọng
  • Thực thi mã tuỳ ý trong TEE hoặc SE
  • Bỏ qua các cơ chế phần mềm được thiết kế để ngăn chặn các thành phần phần mềm hoặc phần cứng liên quan đến an toàn bị trục trặc (ví dụ: biện pháp bảo vệ nhiệt)
  • Truy cập từ xa vào thông tin đăng nhập nhạy cảm dùng để xác thực dịch vụ từ xa (ví dụ: mật khẩu của tài khoản hoặc mã thông báo truy cập)
  • Thực thi mã tuỳ ý từ xa trong bối cảnh băng tần cơ sở di động mà không có sự tương tác của người dùng (ví dụ: khai thác một lỗi trong dịch vụ vô tuyến di động)
  • Thực thi mã tuỳ ý từ xa trong một ngữ cảnh đặc quyền, chuỗi trình tải khởi động, THB hoặc nhân hệ điều hành
  • Bỏ qua từ xa các yêu cầu về lượt 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 về lượt tương tác của người dùng đối với chế độ cài đặt cốt lõi của nhà phát triển, bảo mật hoặc chế độ cài đặt quyền riêng tư
  • Từ chối dịch vụ từ xa liên tục (vĩnh viễn, yêu cầu cài đặt lại toàn bộ hệ điều hành hoặc đặt lại về trạng thái ban đầu)
  • Bỏ qua quy trình 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ằng SE, bao gồm cả quyền truy cập do các khoá yếu trong SE cho phép.
Cao
  • Hoàn toàn bỏ qua một tính năng bảo mật cốt lõi (ví dụ: SELinux, FBE hoặc seccomp)
  • Một phương thức bỏ qua chung cho công nghệ phòng thủ theo chiều sâu hoặc giảm nhẹ khai thác trong chuỗi trình tải khởi động, TEE hoặc SE
  • Một phương thức bỏ qua chung cho các biện pháp bảo vệ của hệ điều hành, giúp tiết lộ nội dung bộ nhớ hoặc tệp trên các 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 chế độ triển khai kém an toàn hơn
  • Chuyển từ chương trình cơ sở kim loại trần bị xâm nhập có thể truy cập từ xa (ví dụ: băng tần cơ sở, Bộ xử lý truyền thông (CP)) sang nhân hệ điều hành Bộ xử lý ứng dụng (AP) hoặc bỏ qua các cơ chế được thiết kế để tách chương trình cơ sở kim loại trần khỏi nhân hệ điều hành AP
  • Bỏ qua chế độ bảo vệ thiết bị, chế độ bảo vệ khi đặt lại về trạng thái ban đầu (trong Android 15 trở lên) hoặc các hạn chế của nhà mạng
  • Bỏ qua các yêu cầu về lượt tương tác của người dùng được bảo mật bằng TEE (Môi trường thực thi đáng tin cậy)
  • Lỗ hổng về mật mã học cho phép tấn công các giao thức đầu cuối, bao gồm cả các cuộc tấn công chống lại bảo mật tầng truyền tải (TLS) và Bluetooth (BT).
  • Quyền truy cập cục bộ vào thông tin xác thực nhạy cảm được dùng để xác thực dịch vụ từ xa (ví dụ: mật khẩu của tài khoản hoặc mã thông báo truy cập)
  • Thực thi mã tuỳ ý cục bộ trong một ngữ cảnh đặc quyền, chuỗi trình tải khởi động, THB hoặc nhân hệ điều hành
  • Bỏ qua quy trình khởi động an toàn cục bộ
  • Bỏ qua màn hình khoá
  • Bỏ qua cục bộ các yêu cầu về lượt tương tác của người dùng đối với các chế độ cài đặt cốt lõi của nhà phát triển, bảo mật hoặc quyền riêng tư
  • Bỏ qua cục bộ các yêu cầu về lượt 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 flash lại toàn bộ hệ điều hành hoặc đặt lại về trạng thái ban đầu)
  • Truy cập từ xa vào dữ liệu được bảo vệ (tức là dữ liệu chỉ giới hạn trong một ngữ cảnh đặc quyền)
  • Thực thi mã tùy ý từ xa trong một ngữ cảnh không có đặc quyền
  • Từ chối dịch vụ từ xa đối với dịch vụ di động hoặc Wi-Fi, kéo dài cho đến khi người dùng can thiệp, được kích hoạt mà không có lượt tương tác của người dùng (ví dụ: dịch vụ radio di động gặp sự cố với một gói dữ liệu bị lỗi không tự động khôi phục và yêu cầu khởi động lại theo cách thủ công hoặc khởi động lại thiết bị).
  • Bỏ qua từ xa các yêu cầu về lượt 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 mà lẽ ra phải yêu cầu người dùng bắt đầu hoặc sự cho phép của người dùng)
  • Ngăn chặn có mục tiêu việc truy cập vào dịch vụ khẩn cấp
  • Truyền thông tin nhạy cảm qua một giao thức mạng không an toàn (ví dụ: HTTP và Bluetooth chưa mã hoá) khi người yêu cầu mong đợi một quá trình truyền an toàn. Xin lưu ý rằng điều này không áp dụng cho phương thức mã hoá Wi-Fi (chẳng hạn như WEP)
  • Truy cập trái phép vào dữ liệu được bảo mật bằng TEE, bao gồm cả quyền truy cập do các khoá yếu trong TEE cho phép
Trung bình
  • Một giải pháp bỏ qua chung cho công nghệ giảm thiểu khai thác hoặc phòng thủ theo chiều sâu trong một ngữ cảnh đặc quyền, THB hoặc nhân hệ điều hành
  • Một quy trình bỏ qua chung đối với các biện pháp bảo vệ hệ điều hành, giúp tiết lộ trạng thái quy trình hoặc siêu dữ liệu trên các ranh giới ứng dụng, người dùng hoặc hồ sơ
  • Bỏ qua bước mã hoá hoặc xác thực Wi-Fi
  • Lỗ hổng bảo mật mật mã trong các nguyên tắc mật mã tiêu chuẩn cho phép rò rỉ văn bản thuần tuý (không phải các nguyên tắc được dùng trong TLS)
  • Quyền truy cập cục bộ vào dữ liệu được bảo vệ (tức là dữ liệu chỉ được giới hạn trong một bối cảnh đặc quyền)
  • Thực thi mã tuỳ ý cục bộ trong một ngữ cảnh không có đặc quyền
  • Bỏ qua cục bộ các yêu cầu về lượt 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 mà thông thường sẽ 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ệ (tức là dữ liệu mà mọi ứng dụng cần cài đặt cục bộ thường có thể truy cập)
  • Thực thi mã tuỳ ý từ xa trong một ngữ cảnh bị hạn chế
  • Từ chối dịch vụ tạm thời từ xa đối với thiết bị (treo hoặc khởi động lại từ xa)
Thấp
  • Một phương pháp bỏ qua chung cho lớp phòng thủ theo chiều sâu cấp người dùng hoặc công nghệ giảm thiểu khai thác trong một ngữ cảnh không có đặc quyền
  • Bỏ qua quyền có cấp độ bảo vệ thông thường
  • Lỗ hổng bảo mật mật mã ở lần sử dụng phi chuẩn
  • Bỏ qua các tính năng cá nhân hoá trên thiết bị nói chung, chẳng hạn 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ã tuỳ ý cục bộ trong một ngữ cảnh bị hạn chế
  • Văn bản do hệ thống xác định có nội dung mô tả gây hiểu lầm, tạo ra kỳ vọng sai lệch về tính bảo mật
Tác động không đáng kể đến tính bảo mật (NSI)
  • Một lỗ hổng mà tác động của nó đã được giảm thiểu bằng một hoặc nhiều hệ số sửa đổi điểm xếp hạng hoặc các thay đổi về cấu trúc dành riêng cho phiên bản, sao cho mức độ nghiêm trọng hiệu quả thấp hơn mức Thấp, mặc dù vấn đề về mã cơ bản có thể vẫn còn
  • Mọi lỗ hổng bảo mật yêu cầu một hệ thống tệp bị lỗi, nếu hệ thống tệp đó luôn được áp dụng/mã hoá trước khi sử dụng.
  • Từ chối dịch vụ tạm thời cục bộ, chẳng hạn như khi bạn có thể giải quyết vấn đề bằng cách khởi động lại thiết bị hoặc gỡ cài đặt ứng dụng kích hoạt.

Đối tượng sửa đổi mức độ nghiêm trọ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 mức phân loại có thể thay đổi tuỳ theo hoàn cảnh.

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

Cục bộ so với lân cận so với từ xa

Vectơ tấn công từ xa cho biết lỗi có thể bị khai thác mà không cần cài đặt ứng dụng hoặc không cần truy cập vật lý vào thiết bị. Điều này bao gồm cả những lỗi có thể xảy ra khi bạn duyệt một trang web, đọc email, nhận tin nhắn SMS hoặc kết nối với một mạng độc hại.

Các vectơ tấn công lân cận được coi là từ xa. Những lỗi này bao gồm cả những lỗi mà chỉ kẻ tấn công ở gần thiết bị mục tiêu về mặt vật lý mới có thể khai thác, chẳng hạn như lỗi yêu cầu gửi các gói Wi-Fi hoặc Bluetooth bị lỗi. Chúng tôi coi các cuộc tấn công dựa trên Băng tần siêu rộng (UWB) và NFC là ở gần và do đó là từ xa.

Các cuộc tấn công cục bộ yêu cầu kẻ tấn công phải có quyền truy cập trước vào nạn nhân. Trong ví dụ giả định chỉ có phần mềm, điều này có thể xảy ra thông qua một ứng dụng độc hại mà nạn nhân đã cài đặt hoặc một Ứng dụng tức thì mà họ đã đồng ý chạy.

Các thiết bị đã ghép nối thành công (chẳng hạn như thiết bị đồng hành Bluetooth) được coi là thiết bị cục bộ. Chúng tôi phân biệt giữa thiết bị đã ghép nối và thiết bị đang tham gia vào quy trình ghép nối.

  • Những lỗi làm giảm khả năng xác định thiết bị khác đang được ghép nối (tức là xác thực) của người dùng được coi là lỗi gần và do đó là lỗi từ xa.
  • Những lỗi xảy ra trong quy trình ghép nối nhưng trước khi sự đồng ý của người dùng (tức là uỷ quyền) được thiết lập được coi là lỗi gần và do đó là lỗi từ xa.
  • Các lỗi xảy ra sau khi sự đồng ý của người dùng đã được thiết lập được coi là lỗi cục bộ, ngay cả khi cuối cùng quá trình ghép nối không thành công.

Các vectơ tấn công vật lý được coi là cục bộ. Những lỗi này 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 trên màn hình khoá hoặc lỗi yêu cầu cắm cáp USB. Vì các thiết bị thường được mở khoá khi cắm vào USB, nên các cuộc tấn công yêu cầu kết nối USB có mức độ nghiêm trọng như nhau, bất kể thiết bị có cần được mở khoá hay không.

Bảo mật mạng

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

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

Xác thực bằng sinh trắc học

Xác thực bằng sinh trắc học là một lĩnh vực đầy thách thức, ngay cả những hệ thống tốt nhất cũng có thể bị đánh lừa bởi một mẫu gần giống (xem Blog dành cho nhà phát triển Android: Cải thiện màn hình khoá và quy trình xác thực trong Android 11). Các 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 quy trình xác thực bằng sinh trắc học theo cách có thể khái quát hoá mà không cần dữ liệu sinh trắc học chất lượng cao của 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à miếng kẹo cao su đó cấp quyền truy cập vào thiết bị dựa trên dấu vết còn 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 mọi thiết bị dễ bị tấn công. Thao tác này không yêu cầu bạn phải biết thông tin về chủ sở hữu thiết bị. Vì có thể khái quát hoá và có khả năng ảnh hưởng đến nhiều người dùng hơn, nên cuộc tấn công này sẽ nhận được mức độ nghiêm trọng đầy đủ (ví dụ: Cao đối với trường hợp bỏ qua Màn hình khoá).

Loại tấn công còn lại thường liên quan đến một công cụ tấn công giả mạo (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 một người trên mạng xã hội đủ để đánh lừa tính năng xác thực sinh trắc học, thì hành vi bỏ qua sinh trắc học sẽ nhận được mức độ nghiêm trọng tối đa). Nhưng nếu kẻ tấn công cần thu thập dữ liệu sinh trắc học trực tiếp từ chủ sở hữu thiết bị (ví dụ: quét khuôn mặt bằng tia hồng ngoại), thì đó là một rào cản đủ lớn để hạn chế số người bị ảnh hưởng bởi cuộc tấn công, vì vậy, có một hệ số điều chỉnh là -1.

SYSTEM_ALERT_WINDOW và hành vi tấn công bằng cách giả mạo thao tác nhấn

Để 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à hành vi nhấp tặc, hãy xem phần "Lỗ hổng bảo mật SYSTEM_ALERT_WINDOW do hành vi nhấp tặc/lớp phủ trên màn hình không quan trọng đối với bảo mật" trên trang Lỗi không ảnh hưởng đến bảo mật của BugHunter University.

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

Android Automotive OS áp dụng mô hình bảo mật nhiều người dùng khác với các hệ số hình dạng khác. Mỗi người dùng Android được dự định sử dụng bởi một người dùng thực tế khác. Ví dụ: bạn có thể chỉ định một người dùng khách tạm thời cho một người bạn mượn xe của chủ sở hữu. Để đáp ứng 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 xe, chẳng hạn như chế độ cài đặt Wi-Fi và mạng di động.

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

Nhóm phát triển chịu trách nhiệm sửa lỗi tuỳ thuộc vào thành phần chứa lỗi đó. Đó có thể là một thành phần cốt lõi của nền tảng Android, một 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 những ứng dụng được tải sẵn trên thiết bị Pixel.

Nhóm kỹ thuật Android sẽ khắc phục các lỗi trong mã AOSP trong các kho lưu trữ nội bộ của chúng tôi.

Thành phần này cũng là một yếu tố ảnh hưởng đến cách người dùng nhận được thông tin cập nhật. Lỗi trong khung hoặc nhân hệ điều hành yêu cầu bản cập nhật chương trình cơ sở qua mạng không dây (OTA) mà mỗi OEM cần phải đẩy. Lỗi trong ứng dụng hoặc thư viện được xuất bản trong Google Play (ví dụ: Gmail, Dịch vụ Google Play hoặc WebView) có thể được gửi đến 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 về bảo mật Android, chúng tôi sẽ thông báo cho các đối tác Android về thông tin chi tiết của vấn đề và cung cấp các bản vá. Danh sách các phiên bản được hỗ trợ backport sẽ thay đổi theo mỗi bản phát hành Android mới. Hãy liên hệ với nhà sản xuất thiết bị để 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 một thành phần AOSP, thì bản sửa lỗi sẽ được chuyển đến AOSP sau khi bản cập nhật qua mạng được phát hành cho người dùng.

Nhận thông tin cập nhật về Android

Các bản cập nhật cho hệ thống Android thường được cung cấp cho thiết bị thông qua các gói cập nhật OTA. Những bản cập nhật này có thể đến từ OEM đã sản xuất thiết bị hoặc nhà mạng cung cấp dịch vụ cho thiết bị. Các bản cập nhật cho thiết bị Google Pixel do nhóm Google Pixel cung cấp sau khi trải qua quy trình kiểm thử chấp nhận kỹ thuật (TA) của nhà mạng. Google cũng xuất bản hình ảnh gốc của Pixel mà bạn có thể tải lên 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á cho 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ó những 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ả ứng dụng và xoá mọi ứng dụng cố gắng khai thác một 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, những thiết bị có Dịch vụ 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ề những ứng dụng có khả năng gây hại.

Tài nguyên 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 có trên toàn bộ trang web Nguồn mở Android và trang web dành cho nhà phát triển. Những nơi phù hợp để 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. Hãy xem Báo cáo bảo mật để biết thêm thông tin chi tiết.