Nhóm bảo mật của 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 của Android tìm ra các lỗ hổng bảo mật thông qua nghiên cứu nội bộ cũng như phản hồi các lỗi do bên thứ ba báo cáo. Nguồn gây ra lỗi bên ngoài bao gồm các sự cố đã báo cáo thông qua biểu mẫu về lỗ hổng bảo mật, nghiên cứu học thuật đã được công bố và xuất bản trước, công ty bảo trì dự án nguồn mở thượng nguồn, thông báo của các đối tác nhà sản xuất thiết bị của chúng tôi và các 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
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 đều có thể thông báo cho nhóm bảo mật của Android về các vấn đề bảo mật tiềm ẩn thông qua biểu mẫu về lỗ hổng bảo mật.
Lỗi được đánh dấu là có vấn đề bảo mật sẽ không hiển thị ra bên ngoài, nhưng sau cùng có thể vẫn xuất hiện hiển thị sau khi vấn đề được đánh giá hoặc giải quyết. Nếu bạn định gửi bản vá hoặc Bài kiểm tra 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 kiểm tra này vào lỗi báo cáo và đợi 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 đề, thành phần này sẽ xác định người sửa lỗi, người nhận thông báo và cách triển khai bản sửa lỗi cho người dùng.
Loại bối cảnh
Bảng này trình bày đị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 theo độ nhạy cảm của dữ liệu mà công cụ này thường xử lý hoặc vùng mà chương trình chạy. Không phải mọi ngữ cảnh bảo mật đều áp dụng cho tất cả hệ thống. Bảng này được sắp xếp theo thứ tự từ ít đến nhiều nhất bí mật về mặt pháp lý.
Loại bối cảnh | Định nghĩa kiểu |
---|---|
Ngữ cảnh ràng buộc |
Một môi trường thực thi bị hạn chế trong đó chỉ có tối thiểu các quyền
đã 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 hộp cát môi trường. |
Bối cảnh không có đặc quyền |
Một môi trường thực thi thông thường mà mã không có đặc quyền mong đợi. Ví dụ: một ứng dụng Android chạy trong miền SELinux có phần tử Thuộc tính untrusted_app_all .
|
Ngữ cảnh được ưu tiê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 cấp cao, xử lý
nhiều PII 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 tính năng bị cấm bởi SELinux untrusted_app hoặc có quyền truy cập vào
Quyền privileged|signature .
|
Nhân hệ điều hành |
Chức năng:
|
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 có trên SoC, cung cấp chức năng thiết yếu vào 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à công nghệ học máy bộ xử lý). |
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 đó truyền quyền kiểm soát sang 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ế để bảo vệ khỏi cả một nhân hệ điều hành gây hại (ví dụ: TrustZone và các trình điều khiển ảo hoá (chẳng hạn như pKVM) giúp bảo vệ Máy ảo khỏi hệ điều hành nhân hệ điều hành). |
Mạng lưới bảo mật / Phần tử bảo mật (SE) |
Là một thành phần phần cứng tuỳ 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ị của bạn và bị tấn công thân thể, như được định nghĩa trong
Giới thiệu về các phần tử bảo mật. Trong đó có cả 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 lỗi thường phản ánh tác hại tiềm ẩn có thể xảy ra nếu lỗi đó đã được khai thác thành công. Hãy sử dụng các tiêu chí sau đây để xác định mức độ nghiêm trọng.
Rating | Hậu quả của việc khai thác thành công |
---|---|
Nghiêm trọng |
|
Cao |
|
Trung bình |
|
Thấp |
|
Tác động không đáng tin cậy về bảo mật (NSI) |
|
Công cụ sửa đổi điểm xếp hạng
Mặc dù mức độ nghiêm trọng của lỗ hổng bảo mật thường dễ xác định, nhưng điểm xếp hạng có thể thay đổi dựa trên hoàn cảnh.
Lý do | Hiệu ứng |
---|---|
Yêu cầu chạy dưới dạng ngữ cảnh đặc quyền để thực thi cuộc tấn công (không áp dụng cho TEE, SE, và trình điều khiển ảo hoá như pKVM) | -1 Mức độ nghiêm trọng |
Thông tin chi tiết về lỗ hổng bảo mật cụ thể sẽ giới hạn mức độ ảnh hưởng của vấn đề | -1 Mức độ nghiêm trọng |
Phương pháp bỏ qua xác thực bằng sinh trắc học đòi hỏi 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ảm thiểu lỗ hổng bảo mật trong mã nguồn | Mức độ nghiêm trọng trung bình nếu lỗ hổng bảo mật cơ bản là Trung bình hoặc cao hơn |
Yêu cầu truy cập vào bộ phận bên trong thiết bị và vẫn có thể dùng được nếu thiết bị đang tắt hoặc chưa được mở khoá kể từ khi được bật nguồn | -1 Mức độ nghiêm trọng |
Yêu cầu phải truy cập vào bộ phận bên trong thiết bị khi thiết bị đang bật và trước đó đã đã được mở khoá | -2 Mức độ nghiêm trọng |
Cuộc tấn công cục bộ yêu cầu bạn phải mở khoá chuỗi trình tải khởi động | Không cao hơn Thấp |
Cuộc tấn công cục bộ đòi hỏi Chế độ nhà phát triển hoặc bất kỳ chế độ cài đặt liên tục nào cho chế độ nhà phát triển 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 thao tác theo SEPolicy do Google cung cấp | Tác động an ninh không đáng kể |
Cục bộ, gần và 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 mà không cần tiếp cận vật lý vào một 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 tới trang web, đọc email, nhận tin nhắn SMS hoặc kết nối với một mạng thù địch.
Vectơ tấn công gần được coi là từ xa. Những lỗi này bao gồm cả những lỗi chỉ có thể bị lợi dụng bởi kẻ tấn công ở gần thiết bị mục tiêu (ví dụ: một lỗi yêu cầu đang gửi các gói Wi-Fi hoặc Bluetooth không đúng định dạng. Chúng tôi cân nhắc sử dụng băng tần siêu rộng (UWB) và NFC tấn công gần và 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 khi tiếp cận nạn nhân. Trong tình huống giả định ví dụ chỉ về phần mềm, hành vi này có thể là thông qua một ứng dụng độc hại mà nạn nhân đã cài đặt, hoặc Ứng dụng tức thì mà họ có đồng ý chạy.
Các thiết bị đã ghép nối thành công (chẳng hạn như các thiết bị đồng hành Bluetooth) được coi là thiết bị cục bộ. T4 phân biệt một thiết bị đã ghép nối và một thiết bị tham gia vào quá trình ghép nối luồng.
- Các lỗi làm giảm khả năng của người dùng trong việc xác định thiết bị khác đang được ghép nối (ví dụ: xác thực) được coi là gần và do đó là từ xa.
- Lỗi xảy ra trong quy trình ghép nối nhưng trước khi người dùng đồng ý (tức là ủy quyền) đã xảy ra được thiết lập là ở gần và do đó được thiết lập ở xa.
- Các lỗi xảy ra sau khi người dùng đã thiết lập sự đồng ý của họ vẫn được coi là lỗi cục bộ, ngay cả khi cuối cùng thì ghép nối không thành công.
Vectơ tấn công vật lý được coi là cục bộ. Đó là những lỗi chỉ có thể khai thác kẻ tấn công có quyền truy cập vật lý vào thiết bị, ví dụ như lỗi trên màn hình khoá hoặc yêu cầu cắm cáp USB. Vì thông thường, các thiết bị sẽ được mở khoá khi cắm vào USB, thì các cuộc tấn công yêu cầu kết nối USB đều có mức độ nghiêm trọng như nhau bất kể xem có cần mở khoá thiết bị hay không.
Bảo mật mạng
Android giả định rằng tất cả các mạng đều có tính thù địch và có thể thực hiện các cuộc tấn công hoặc do thám lưu lượng truy cập. Trong khi cơ chế bảo mật lớp liên kết (ví dụ: mã hoá Wi-Fi) bảo mật hoạt động giao tiếp giữa một thiết bị và Điểm truy cập được kết nối với thiết bị đó, công cụ này 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 giao tiếp.
Ngược lại, HTTPS thường bảo vệ toàn bộ quá trình giao tiếp hai đầu, mã hoá dữ liệu tại nguồn, sau đó chỉ giải mã và xác minh mã khi đã đến đích cuối cùng. Do đó, các lỗ hổng bảo mật ảnh hưởng đến tính bảo mật của mạng lớp liên kết sẽ được đánh giá thấp hơn nghiêm trọng hơn lỗ hổng bảo mật trong HTTPS/TLS: chỉ mã hoá Wi-Fi là khô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 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 gần khớp (xem Blog dành cho nhà phát triển Android: Cải tiến tính năng xác thực và màn hình khoá trong Android 11). Các mức phân loại mức độ nghiêm trọng này phân biệt giữa hai loại tấn công và nhằm rủi ro thực tế cho người dùng cuối.
Loại tấn công thứ nhất cho phép bỏ qua bước xác thực bằng sinh trắc học theo một cách có thể khái quát hoá, mà không có 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 trên cảm biến vân tay rồi cấp quyền truy cập vào thiết bị dựa trên dư lượng 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 bất kỳ thiết bị dễ bị tấn công nào. Chiến dịch mà không đòi hỏi chủ sở hữu thiết bị phải biết. Do đó, nó có thể khái quát hoá và có thể ảnh hưởng đến nhiều người dùng hơn, cuộc tấn công này sẽ nhận được mức đánh giá mức độ nghiêm trọng đầy đủ (ví dụ: Cao, đối với lượt bỏ qua Màn hình khoá).
Loại tấn công khác thường liên quan đến công cụ tấn công giả mạo (giả mạo) 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 (cho ví dụ: nếu ảnh hồ sơ của một người trên mạng xã hội đủ để đánh lừa xác thực sinh trắc học, thì lượt bỏ qua bằng sinh trắc học sẽ nhận được mức phân loại 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 của khuôn mặt của họ), đó là một rào cản đáng kể để hạn chế số người bị ảnh hưởng nên có 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à hành vi bẻ khoá,
xem thông tin về "Lỗ hổng Tapjacking/lớp phủ SYSTEM_ALERT_WINDOW trên màn hình không quan trọng về bảo mật" thuộc Đại học BugHunter
Lỗi không ảnh hưởng đến tính bảo mật
.
Bảo mật cho 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 kiểu dáng thiết bị khác. Mỗi người dùng Android đều hướng đến một một người. Ví dụ: người dùng khách tạm thời có thể được chỉ định cho một người bạn mượn chiếc xe của chủ sở hữu chiếc 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 phải 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ư Wi-Fi và mạng di động phần cài đặt.
Thành phần bị ảnh hưởng
Nhóm phát triển chịu trách nhiệm sửa lỗi phụ thuộc vào thành phần của lỗi. Đó có thể là 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 được cung cấp bởi phiên bản gốc nhà sản xuất thiết bị (OEM) hoặc một trong những ứng dụng tải trước trên thiết bị Pixel.
Nhóm kỹ thuật Android đã khắc phục các lỗi trong mã AOSP (Dự án nguồn mở Android). Lỗi có mức độ nghiêm trọng thấp, lỗi trong một số thành phần hoặc lỗi đã được công khai có thể được khắc phục trực tiếp trong nhánh chính của AOSP (Dự án nguồn mở Android) công khai; nếu không, chúng sẽ được khắc phục trong các kho lưu trữ nội bộ của chúng tôi đầu tiên.
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 bản 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 đẩy. Lỗi trong ứng dụng hoặc thư viện phát hành trong Google Play (ví dụ: Gmail, Dịch vụ Google Play hoặc WebView) có thể là gửi cho người dùng Android dưới dạng bản cập nhật qua Google Play.
Thông báo cho đối tác
Khi bạn khắc phục một lỗ hổng bảo mật trong AOSP (Dự án nguồn mở Android) trong một Bản tin về bảo mật Android, chúng tôi sẽ thông báo Các đối tác Android chuyên cung cấp thông tin chi tiết về vấn đề và cung cấp bản vá. Danh sách các phiên bản được điều chỉnh cho phiên bản cũ thay đổi với 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ị của bạn để biết danh sách thiết bị được hỗ trợ.
Phát hành mã cho AOSP (Dự án nguồn mở Android)
Nếu lỗi bảo mật nằm trong một thành phần AOSP (Dự án nguồn mở Android), thì bản sửa lỗi sẽ được chuyển sang AOSP (Dự án nguồn mở Android) sau khi OTA được được phát hành cho người dùng. Bạn có thể gửi trực tiếp các bản sửa lỗi cho các vấn đề mức độ nghiêm trọng thấp đến nền tảng chính của AOSP (Dự án nguồn mở Android) trước khi bản sửa lỗi được cung cấp 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 phân phối đến các thiết bị thông qua gói cập nhật qua mạng không dây (OTA). Các bản cập nhật này có thể đến từ OEM (Nhà sản xuất thiết bị gốc) sản xuất thiết bị hoặc nhà mạng cung cấp dịch vụ cho thiết bị. Bản cập nhật cho thiết bị Google Pixel do nhóm Google Pixel cung cấp sau khi thông qua quy trình thử nghiệm chấp nhận kỹ thuật của nhà mạng (TA). Google cũng phát hành Hình ảnh gốc trên Pixel có thể cài đặt không qua cửa hàng ứng dụng đến các thiết bị.
Đang 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 các lỗi bảo mật, nhóm bảo mật Android còn xem xét vấn đề bảo mật để xác định xem có cách nào khác giúp bảo vệ người dùng hay không. Ví dụ: Google Play quét tất cả và xoá mọi ứng dụng tìm cách khai thác lỗi bảo mật. Đối với các ứng dụng được cài đặt từ ngoài Google Play, các 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 cho người dùng về các ứng dụng có thể 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 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. Tốt nơi để bắt đầu:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Báo cáo
Đôi khi, nhóm Bảo mật Android sẽ 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.