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. Nguồn của lỗi bên ngoài bao gồm các sự cố được báo cáo thông qua biểu mẫu lỗ hổng , nghiên cứu học thuật được xuất bản và xuất bản trước, các nhà bảo trì dự án nguồn mở ngược dòng, thông báo từ các đối tác nhà sản xuất thiết bị của chúng tôi và các sự cố được tiết lộ công khai được đăng 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 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ài kiểm tra Bộ kiểm tra 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 sự cố 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 bối 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 mức độ 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ả 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 bối cảnh | định nghĩa kiểu |
---|---|
Bối cảnh hạn chế | Một môi trường thực thi bị hạn chế trong đó 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ộ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ý PII của nhiều 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 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 . |
Hạt 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 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ư băng 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 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ế để bảo vệ ngay cả khỏi 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, 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 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 sự tấn công vật lý, như được định nghĩa trong Giới thiệu về các phần tử 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 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. Sử dụng các tiêu chí sau để xác định mức độ nghiêm trọng.
Xếp hạng | Hậu quả của việc khai thác thành công |
---|---|
Phê bình |
|
Cao |
|
Vừa phải |
|
Thấp |
|
Tác động bảo mật không đáng kể (NSI) |
|
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 sẽ 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 |
Cấu hình trình biên dịch hoặc 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ể thực hiện được 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à đã được mở khóa trước đó | -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 bootloader | 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 phải được bật trên thiết bị (và bản thân nó 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 Chính sách SEP do Google cung cấp | Tác động bảo mật không đáng kể |
Cục bộ so với gần và từ xa
Một 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 tới 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 đó là từ xa.
Các cuộc tấn công cục bộ yêu cầu nạn nhân chạy một ứng dụng, bằng cách cài đặt và chạy một ứ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 trên 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 có tính chất thù địch và có thể thực hiện các cuộc tấn công hoặc theo dõi 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) đảm bảo an toàn cho hoạt động 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 không có tác dụng 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 các lỗ hổng trong HTTPS/TLS: Chỉ riêng mã hóa Wi-Fi là không đủ cho hầu hết 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 lĩnh vực đầ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 một kết quả gần trùng khớp (xem Blog dành cho nhà phát triển Android: 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.
Lớp 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 khái 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 dấu 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ị nhạy cảm 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ó tính khái quát và có khả năng tác độ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 đánh giá 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 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 bỏ qua sinh trắc học sẽ nhận được đánh giá 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 để hạn chế số người bị ảnh hưởng bởi cuộc tấn công, do đó, có công cụ sửa đổi -1 .
SYSTEM_ALERT_WINDOW
và khai thác
Để 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à hack, hãy xem phần " Lỗ hổng 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 Automotive áp dụng mô hình bảo mật nhiều người dùng khác với các hệ số dạng khác. Mỗi người dùng Android dự định sẽ được sử dụng bởi một người thực tế khác nhau. 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 xe từ chủ xe. Để đá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ư 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 sẽ tùy thuộc vào thành phần nào gây ra lỗi. Lỗi này có thể là thành phần cốt lõi của nền tảng Android, trình điều khiển hạt 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 .
Các lỗi trong mã AOSP đã được nhóm kỹ thuật Android sửa. Các lỗi ở mức độ nghiêm trọng thấp, lỗi trong một số thành phần nhất định hoặ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 thì chúng sẽ được sửa trong kho 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 kernel yêu cầu bản cập nhật chương trình cơ sở qua mạng (OTA) mà mỗi OEM cần phải cập nhật. 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 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 sự cố và cung cấp các bản vá. Danh sách các phiên bản được hỗ trợ backport thay đổi theo mỗi 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, 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. 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 chi 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 tới các 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à 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à cung cấp dịch vụ. Google cũng xuất bản hình ảnh nhà máy Pixel có thể được tải phụ vào 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á 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ả ứng dụng và xóa mọi ứng dụng cố gắng 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 Nhà phát triển và Nguồn mở Android. Những nơi tốt để 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 xuất bản các báo cáo hoặc báo cáo nghiên cứu chuyên sâu. Xem Báo cáo bảo mật để biết thêm chi tiết.