Nhiều lỗ hổng mới cho phép thoát sandbox trên macOS

 (jhftss.github.io)
1 điểm bởi GN⁺ 2024-11-09 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong quá trình nghiên cứu thoát sandbox trên macOS, dịch vụ XPC miền PID vốn ít được chú ý hơn đã lộ ra như một bề mặt tấn công, dẫn tới việc phát hiện hơn 10 lỗ hổng mới
  • Mục tiêu chính không phải là các dịch vụ Mach ở miền System/User, mà là các dịch vụ XPC kiểu Application được đăng ký vào miền PID khi ứng dụng hoặc framework được nạp
  • Các trường hợp dễ bị tấn công gồm CVE-2023-27944, CVE-2023-32414, CVE-2023-32404, CVE-2023-41077, CVE-2023-42961, CVE-2024-27864, CVE-2023-42977; một số liên quan tới vượt qua TCC, quyền liên quan đến SIP, và cả ảnh hưởng tới iOS
  • Điểm thất bại lặp đi lặp lại là các dịch vụ không bị cô lập xử lý tệp, thư mục, archive và DMG nhưng không xử lý an toàn thuộc tính mở rộng quarantine, chuỗi đường dẫn và việc xác minh quyền của client
  • Cách Apple ứng phó gồm loại bỏ các dịch vụ XPC dễ bị tấn công, chuẩn hóa đầu vào, chuyển việc xác minh sang phía máy chủ, và yêu cầu private entitlement; tuy vậy vẫn còn 5 báo cáo đang chờ vá lỗi

Mô hình sandbox trên macOS và mục tiêu thoát ra

  • Trên macOS, nhiều tiến trình bao gồm dịch vụ của chính Apple và ứng dụng bên thứ ba chạy trong môi trường sandbox bị hạn chế
  • Ngay cả khi kẻ tấn công giành được thực thi mã từ xa (RCE) trong một tiến trình sandbox, khả năng thực thi và quyền truy cập tệp vẫn bị giới hạn, nên bước tiếp theo là thoát sandbox để giành quyền rộng hơn

  • App Sandbox

    • Theo yêu cầu của Mac App Store, nhiều ứng dụng chạy dưới các ràng buộc của App Sandbox
    • Ứng dụng sandbox phải có entitlement com.apple.security.app-sandbox
    • Các hạn chế được áp dụng ở giai đoạn khởi tạo dyld, trước hàm main của ứng dụng
    • Khi vào App Sandbox, ứng dụng sẽ bị container hóa và các thao tác với tệp bị giới hạn trong đường dẫn data container
    • Các tệp do ứng dụng sandbox tạo ra mặc định sẽ được gắn thuộc tính mở rộng com.apple.quarantine
    • Hồ sơ sandbox có các quy tắc ngăn việc xóa thuộc tính mở rộng này
    • Quyền chi tiết của App Sandbox được định nghĩa trong /System/Library/Sandbox/Profiles/application.sb
    • Mạng, phần cứng, hệ thống tệp và các dịch vụ Mach có thể truy cập đều bị hạn chế
    • Tiến trình con được fork sẽ kế thừa các hạn chế App Sandbox của tiến trình cha
    • Các tiến trình được khởi chạy qua LaunchService.framework không kế thừa các hạn chế đó; ví dụ có thể trực tiếp chạy ứng dụng không sandbox bằng lệnh hệ thống open

  • Service Sandbox

    • Nhiều dịch vụ daemon của Apple chạy trong ngữ cảnh Service Sandbox
    • Hồ sơ Service Sandbox chủ yếu nằm ở /System/Library/Sandbox/Profiles/*.sb và /usr/share/sandbox/*.sb
    • Các hạn chế Service Sandbox được áp dụng thủ công trong hàm main của dịch vụ bằng cách gọi API sandbox_init_XXX
    • Dịch vụ sau khi vào Service Sandbox thường không bị container hóa
    • Khác biệt quan trọng là các tệp được tạo trong Service Sandbox mặc định không bị đánh dấu quarantine
    • Nếu không gọi thủ công các API liên quan đến quarantine, các tệp được tạo ra sẽ không có quarantine

Các đường thoát sandbox macOS đã biết trước đây

  • Tấn công LaunchService.framework

    • Một trong những cách phổ biến trước đây là tấn công các ứng dụng không sandbox thông qua LaunchService.framework
    • CVE-2021-30864 là trường hợp thao túng biến môi trường $HOME đối với Terminal.app, một ứng dụng hệ thống không sandbox
    • Khi Terminal chạy, payload độc hại dưới $HOME/.profile do kẻ tấn công kiểm soát sẽ được thực thi mà không chịu ràng buộc sandbox
    • Một kịch bản khác là thả một ứng dụng không sandbox mới rồi chạy nó
    • Tuy nhiên, ứng dụng mới do ứng dụng sandbox thả xuống sẽ bị đánh dấu quarantine nên không thể chạy
    • Nếu có thể thả tệp hoặc thư mục mà không có quarantine, có thể vượt qua hoàn toàn App Sandbox
    • CVE-2023-32364 là trường hợp thả một thư mục không có quarantine bằng cách lợi dụng việc devfs không hỗ trợ thuộc tính mở rộng

  • Tấn công các dịch vụ Mach có thể truy cập

    • Cách phổ biến thứ hai là tấn công các dịch vụ Mach được liệt kê trong hồ sơ App Sandbox
    • Thông tin về các dịch vụ Mach của hệ thống được lưu trong /System/Library/xpc/launchd.plist
    • Có thể dùng API bootstrap_look_up để kiểm tra từ ứng dụng sandbox xem có thể truy cập một dịch vụ Mach cụ thể hay không
    • Các dịch vụ Mach này tồn tại trong miền System hoặc miền User
    • Điểm khởi đầu của nghiên cứu này là việc ngoài hai miền đó vẫn còn các dịch vụ XPC có thể truy cập được từ App Sandbox

Bề mặt tấn công mới: dịch vụ XPC miền PID

  • Các dịch vụ XPC bị bỏ sót nằm trong miền PID
  • Khác với các dịch vụ XPC ở miền System/User thường thấy trước đây, chúng có kiểu dịch vụ là Application
  • Dịch vụ XPC kiểu Application sẽ được khởi chạy khi ứng dụng yêu cầu và sẽ kết thúc cùng lúc khi ứng dụng yêu cầu thoát
  • Các dịch vụ XPC ở miền System/User chỉ có thể được truy cập từ ứng dụng sandbox khi được định nghĩa trong application.sb
  • Mọi dịch vụ XPC mà ứng dụng và framework cần đều sẽ xuất hiện trong miền PID của ứng dụng đó
  • Nhiều dịch vụ XPC ở miền PID không dự liệu việc bị gọi từ ứng dụng sandbox, nên có thể không kiểm tra entitlement hoặc trạng thái sandbox của XPC client gửi vào

  • Trường hợp SystemShoveService.xpc

    • SystemShoveService.xpc là một bundle XPC bên trong ShoveService.framework private của hệ thống
    • Kiểu dịch vụ trong Info.plist là Application, và bundle identifier là com.apple.installandsetup.shoveservice.system
    • Khi một ứng dụng sandbox nạp /System/Library/PrivateFrameworks/ShoveService.framework, dịch vụ XPC tương ứng sẽ tự động được đăng ký vào miền PID
    • SystemShoveService.xpc không kiểm tra XPC client yêu cầu nên có thể bị lạm dụng để thoát App Sandbox
    • Dịch vụ này có entitlement liên quan đến SIP rất mạnh là com.apple.rootless.install, nên còn có thể dẫn tới vượt qua cơ chế bảo vệ SIP
    • Lỗ hổng này được gán mã CVE-2022-26712, chi tiết được tổng hợp trong bài viết trước

  • Cách tìm kiếm

    • Mọi dịch vụ XPC có Service Type là Application đều là mục tiêu tiềm năng cho việc thoát App Sandbox
    • Có thể liệt kê và tìm chúng trong các framework hệ thống và private framework
      • /System/Library/Frameworks
      • /System/Library/PrivateFrameworks
    • Nếu tồn tại một dịch vụ XPC miền PID không kiểm tra XPC client gửi vào, có thể thử tấn công theo các cách sau
      • thả thư mục ứng dụng mà không có quarantine để đạt được thoát sandbox hoàn toàn
      • thả tệp ZIP hoặc DMG chứa ứng dụng không sandbox mà không có quarantine

2 lỗ hổng chỉ tồn tại trên bản beta

  • Beta-No-CVE-1: Thực thi lệnh tùy ý trong StorageKit

    • Apple đã ghi nhận lỗ hổng này trong additional recognitions nhưng không gán CVE
    • Theo Apple, CVE chỉ được gán cho các lỗ hổng trong phần mềm đã phát hành chính thức, và không áp dụng cho lỗ hổng trong phần mềm chỉ có trên bản beta
    • Phạm vi ảnh hưởng chỉ giới hạn ở các bản macOS Sonoma Beta
    • Đường dẫn dịch vụ XPC dễ bị tấn công là /System/Library/PrivateFrameworks/StorageKit.framework/XPCServices/storagekitfsrunner.xpc
    • Dịch vụ này có thể chạy mà không bị ràng buộc sandbox và chấp nhận mọi XPC client trong phương thức delegate
    • Phương thức duy nhất của SKRemoteTaskRunnerProtocol, runTask:arguments:withReply:, được thiết kế để thực thi lệnh tùy ý với đường dẫn tệp thực thi và đối số được chỉ định
    • Vì XPC client trong sandbox có thể kiểm soát đường dẫn tệp thực thi và đối số, có thể thực thi các lệnh hệ thống tùy ý mà không bị giới hạn bởi sandbox
    • Apple đã xóa hoàn toàn dịch vụ XPC dễ bị tấn công khỏi hệ điều hành trước khi macOS Sonoma 14.0 được phát hành chính thức

  • Beta-No-CVE-2: Lạm dụng việc tạo ZIP trong AudioAnalyticsHelperService

    • Lỗ hổng này cũng không được gán CVE vì cùng lý do chỉ tồn tại trên bản beta
    • Đường dẫn dịch vụ XPC dễ bị tấn công là /System/Library/PrivateFrameworks/AudioAnalyticsInternal.framework/XPCServices/AudioAnalyticsHelperService.xpc
    • Dịch vụ này có thể chạy mà không bị ràng buộc sandbox và chấp nhận mọi XPC client
    • Phương thức createZipAtPath:hourThreshold:withReply: sẽ nén một đường dẫn tùy ý do XPC client chỉ định
    • Nếu không có thư mục compressed trong đường dẫn được chỉ định, nó sẽ tạo thư mục này, tìm các tệp .json, di chuyển chúng vào thư mục đó rồi tạo tệp ZIP
    • Kẻ tấn công có thể thay thư mục compressed bằng symlink để di chuyển tệp tùy ý đến vị trí tùy ý
    • Nội dung tệp nguồn không bị kiểm tra, và đường dẫn tệp đích phải có hậu tố .json
    • Tệp ZIP mới tạo sẽ không bị gắn quarantine vì dịch vụ này không bị sandbox
    • Apple đã vá lỗ hổng trước khi phát hành macOS Sonoma 14.0 bằng cách kiểm tra entitlement com.apple.audioanalytics.helper.service của XPC client kết nối vào
    • Trên các bản macOS mới nhất, private AudioAnalyticsInternal.framework và dịch vụ XPC tương ứng đã bị xóa hoàn toàn

CVE-2023-27944: TrialArchivingService

  • Dịch vụ dễ bị tấn công là /System/Library/PrivateFrameworks/TrialServer.framework/XPCServices/TrialArchivingService.xpc
  • Dịch vụ này chạy trong Service Sandbox với profile /System/Library/Sandbox/Profiles/com.apple.trial.TrialArchivingService.sb
  • Vì là Service Sandbox, các tệp được thả xuống sẽ không bị gắn quarantine
  • Dịch vụ chấp nhận mọi XPC client kết nối vào
  • Phương thức extractArchiveFromHandle:withArchiveName:toDirectory:destDirExtension:postExtractionCompression:completion: sẽ giải nén tệp archive do ứng dụng sandbox truyền vào đến vị trí được chỉ định
  • Thuộc tính mở rộng quarantine không được truyền sang nội dung đã giải nén, nên có thể dẫn đến việc thả tệp không có quarantine

  • Điều kiện khai thác và cách vượt qua

    • Khi lạm dụng phương thức này, các tệp Mach-O bên trong archive sẽ mất quyền thực thi sau khi giải nén nên không thể chạy ngay
    • Có thể dùng symlink làm cách vượt qua, tương tự kỹ thuật trong CVE-2021-30990
    • Tuy nhiên, phương thức XPC này chỉ giải nén thư mục và tệp thông thường, không cho phép giải nén symlink từ archive
    • Một cách vượt qua là giải nén ứng dụng payload vào đường dẫn app container của ứng dụng sandbox
    • Ứng dụng sandbox có quyền đọc/ghi tại đường dẫn đó, nên có thể tự tạo symlink hoặc cấp quyền thực thi bằng chmod
    • Một cách khác là đóng gói ứng dụng payload hai lần
      • Dùng phương thức XPC dễ bị tấn công để giải nén ZIP bên ngoài
      • Dùng lệnh hệ thống open để giải nén ZIP bên trong

  • Bản vá

    • Apple đã vá lỗ hổng trong macOS Ventura 13.3 bằng cách kiểm tra entitlement com.apple.TrialArchivingService.internal của XPC client kết nối vào
    • Nếu không có entitlement đó, kết nối XPC sẽ bị từ chối

CVE-2023-32414: ArchiveService

  • Dịch vụ dễ bị tấn công là /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/XPCServices/ArchiveService.xpc
  • Dịch vụ này chạy trong Service Sandbox nhưng các tệp được thả xuống không bị gắn quarantine
  • Dịch vụ chấp nhận mọi XPC client
  • Phương thức unarchiveItemWithURLWrapper:… sẽ giải nén mục do ứng dụng sandbox truyền vào đến vị trí được chỉ định
  • Vì không truyền thuộc tính mở rộng quarantine sang nội dung đã giải nén, ứng dụng sandbox có thể thả tệp tùy ý mà không có quarantine
  • XPC client đã được triển khai sẵn trong lớp Objective-C DSArchiveService của DesktopServicesPriv.framework

  • Bản vá

    • Apple đã vá lỗ hổng trong macOS Ventura 13.4 bằng cách kiểm tra entitlement com.apple.private.ArchiveService.XPC của XPC client kết nối vào
    • Nếu không có entitlement đó, kết nối XPC sẽ bị từ chối

CVE-2023-32404: ShortcutsFileAccessHelper

  • Dịch vụ dễ bị tấn công là /System/Library/PrivateFrameworks/WorkflowKit.framework/XPCServices/ShortcutsFileAccessHelper.xpc
  • Dịch vụ này có thể chạy mà không bị giới hạn sandbox, nên có thể bị lạm dụng để thoát App Sandbox
  • Chữ ký mã còn bao gồm entitlement TCC đặc biệt cho Full Disk Access
  • Vì vậy, lỗ hổng này cũng có thể bị lạm dụng để vượt qua hoàn toàn cơ chế bảo vệ TCC
  • Dịch vụ chấp nhận mọi XPC client
  • Phương thức duy nhất của WFFileAccessHelperProtocol, extendAccessToURL:completion:, được thiết kế để cấp quyền đọc/ghi đối với URL tùy ý cho XPC client
    • Bên trong, nó gọi API sandbox_extension_issue_file để cấp token truy cập tệp
    • URL tùy ý này do XPC client trong sandbox chỉ định

  • Bản vá

    • Apple đã vá lỗ hổng trong macOS Ventura 13.4 bằng cách kiểm tra entitlement com.apple.shortcuts.file-access-helper của XPC client kết nối vào
    • Nếu không có entitlement đó, kết nối XPC sẽ bị từ chối

CVE-2023-41077: mscamerad-xpc và các lần vượt qua bản vá lặp lại

  • Dịch vụ dễ bị tấn công là /System/Library/Frameworks/ImageCaptureCore.framework/XPCServices/mscamerad-xpc.xpc
  • Dịch vụ này có thể chạy không bị giới hạn sandbox nên có thể bị lợi dụng để thoát App Sandbox
  • Chữ ký mã có entitlement TCC đặc biệt cho phép truy cập Photos và Removable Volumes mà không cần lời nhắc người dùng
  • Vì vậy cũng có thể vượt qua lớp bảo vệ TCC tương ứng

  • Luồng khai thác

    • Tên dịch vụ mặc định là com.apple.mscamerad-xpc
    • Dịch vụ cho phép mọi XPC client
    • openDevice:withReply: của ICXPCDeviceManagerProtocol mở và cấu hình một MSCameraDevice mới
    • Trong lúc khởi tạo thiết bị mới, một dịch vụ XPC ẩn danh khác được mở để cung cấp routine dịch vụ cho thiết bị camera
    • Dịch vụ XPC ẩn danh đó cũng cho phép mọi XPC client
    • Phương thức requestReadDataFromObjectHandle:options:withReply: của ICCameraDeviceProtocol đọc nội dung của mục tệp được yêu cầu và trả về cho XPC client
    • Đường dẫn tệp được yêu cầu có thể bị XPC client kiểm soát, nên ứng dụng sandbox có thể đọc tệp tùy ý ngoài container
    • Do dịch vụ có entitlement TCC mạnh, nó cũng có thể đọc Photos của người dùng mà không cần lời nhắc

  • Cấu hình thiết bị camera giả

    • MSCameraDevice có thể được giả lập bằng cách tạo và mount một tệp DMG
    • Nếu đường dẫn tệp trong volume DMG khớp với một biểu thức chính quy cụ thể thì mục tệp sẽ được lập chỉ mục thành ICCameraFile
    • Ví dụ tên thư mục: 123abcde, DCIM, dcIm
    • Ví dụ tên tệp: abcd1234.mp3, 1234E5678.HEIC
    • Ứng dụng sandbox có thể kích hoạt vấn đề bằng cách thả tệp DMG, mở và mount nó
    • XPC client đã được triển khai sẵn trong framework ImageCaptureCore

  • Bản vá và cách vượt qua

    • Apple đã thêm một kiểm tra mới vào acceptConnection: trên macOS Sonoma 14
    • Cho phép nếu client có private entitlement com.apple.private.imagecapturecore.authorization_bypass
    • Hoặc cho phép nếu client là platform binary
    • Điều kiện platform binary có thể bị vượt qua bằng cách chèn thư viện động vào một binary do Apple ký
      • Chọn /bin/ls, một binary do Apple ký nhưng không có entitlement
      • Chèn một dylib chứa mã exploit trước đó bằng biến môi trường DYLD_INSERT_LIBRARIES
      • Sau đó giao tiếp với dịch vụ XPC như cũ
    • Apple đã gán CVE-2024-23253 cho báo cáo vượt qua này
    • Trên macOS 14.4, điều kiện thứ hai được siết chặt hơn: XPC client không chỉ phải là platform binary mà còn phải được ký với cờ CS_REQUIRE_LV hoặc CS_FORCED_LV
    • Bản vá này cũng có thể bị vượt qua
      • Chèn dylib vào /bin/ls
      • Đặt thủ công các cờ bắt buộc lúc chạy bằng API csops
      • Sau đó vượt qua được bước kiểm tra của dịch vụ XPC
    • Apple đã gán CVE-2024-40831 cho lần vượt qua thứ hai này
    • Trên macOS Sequoia 15, bản vá lại được điều chỉnh để chỉ cho phép XPC client có private entitlement com.apple.private.imagecapturecore.authorization_bypass

CVE-2023-42961: intents_helper

  • Lỗ hổng này cũng có thể bị khai thác trên iOS
  • Dịch vụ dễ bị tấn công là /System/Library/Frameworks/Intents.framework/XPCServices/intents_helper.xpc
  • Dịch vụ có thể chạy không bị giới hạn sandbox và cho phép mọi XPC client
  • Do lỗi path traversal trong hàm filePathForImageWithFileName, có thể truy cập đường dẫn tùy ý
  • Tham số fileName là chuỗi tùy ý do XPC client kiểm soát

  • Các phương thức bị ảnh hưởng

    • Hàm dễ bị tấn công có thể được gọi tới từ hai phương thức XPC
    • retrieveImageWithIdentifier:completion: có thể bị lợi dụng để đọc tệp tùy ý có phần mở rộng .png
    • Dữ liệu đọc được được lưu vào biến thành viên của một instance INImage và trả về cho XPC client
    • purgeImageWithIdentifier:completion: có thể bị lợi dụng để xóa đường dẫn tệp tùy ý

  • Bản vá

    • Apple đã vá trên macOS Sonoma 14.0 bằng cách chuẩn hóa chuỗi đầu vào từ XPC client
    • Cắt bỏ các ký tự đặc biệt được dùng cho path traversal

CVE-2024-27864: diskimagescontroller

  • Mục CVE vẫn đang chờ công bố tại thời điểm bài viết được viết
  • Dịch vụ dễ bị tấn công là /System/Library/PrivateFrameworks/DiskImages2.framework/XPCServices/diskimagescontroller.xpc
  • Dịch vụ này có entitlement com.apple.diskimages.creator-uc trong chữ ký mã nên có thể thực hiện các hành vi mạnh
  • Có hai chức năng chính của entitlement này
    • Giao tiếp với /usr/libexec/diskimagesiod, tiến trình có FDA entitlement và thực hiện thao tác attach thực tế
    • Kết nối tới dịch vụ IOKit AppleDiskImagesController để tạo thiết bị cho tệp DMG và áp dụng quarantine

  • Nguyên nhân lỗ hổng

    • Dịch vụ cho phép mọi XPC client
    • Phương thức attachWithParams:reply: của DIControllerProtocol là điểm tấn công
    • Bên trong có gọi checkAttachEntitlementWithError, nhưng trái với tên gọi, hàm này luôn trả về TRUE
    • DiskImages2.framework đã có sẵn XPC client với lớp Objective-C DIAttachParams
    • Mã client của framework kiểm tra xem URL đầu vào có ở trạng thái quarantine hay không
    • Nếu URL đầu vào đang ở trạng thái quarantine thì trước khi attach, nó thiết lập tham số quarantine, và tham số này báo cho dịch vụ XPC rằng cần áp dụng quarantine cho thiết bị đích
    • Nếu tự tạo XPC client riêng, có thể bỏ qua bước thiết lập tham số quarantine và gọi trực tiếp attachWithParams:reply:
    • Kết quả là có thể attach một tệp DMG đang bị quarantine mà không áp dụng quarantine cho thiết bị tương ứng

  • Bản vá

    • Apple đã chuyển logic xác minh từ phía client sang phía server trên macOS Sonoma 14.4
    • Nếu đường dẫn tệp đầu vào đang ở trạng thái quarantine thì server sẽ trực tiếp áp dụng quarantine cho thiết bị tương ứng

CVE-2023-42977: PerfPowerServicesSignpostReader

  • Dịch vụ dễ bị tấn công là /System/Library/PrivateFrameworks/PowerlogCore.framework/XPCServices/PerfPowerServicesSignpostReader.xpc
  • Dịch vụ có thể chạy mà không bị ràng buộc sandbox và chấp nhận mọi XPC client
  • XPCSignpostReaderProtocol có 6 phương thức, nhưng Apple chỉ triển khai submitSignpostDataWithConfig:withReply:, còn 5 phương thức còn lại là triển khai rỗng
  • Logic cốt lõi của phương thức này là thu thập dữ liệu log và lưu trữ thành tệp gzip
  • Chuỗi tagUUID do XPC client kiểm soát có thể bị lợi dụng để chiếm quyền điều hướng đường dẫn powerlog sang đường dẫn tùy ý

  • Xóa đường dẫn tùy ý

    • Bên trong hàm có lời gọi archiveDirectoryAt:deleteOriginal: để xóa đường dẫn powerlog
    • Nếu chèn chuỗi duyệt đường dẫn vào TagUUID, có thể thu được primitive xóa đường dẫn tùy ý

  • Tạo thư mục tùy ý và thoát sandbox hoàn toàn

    • Hàm createSignpostFile: tạo thư mục tại đường dẫn powerlog
    • Qua đó có thể tạo thư mục tùy ý không có thuộc tính mở rộng quarantine
    • Primitive tạo thư mục tùy ý không có quarantine có thể dẫn tới thoát sandbox hoàn toàn
    • Bài viết sử dụng kỹ thuật của CVE-2023-32364
      • Tạo thư mục .app không có quarantine
      • Tạo symlink tới /bin/bash bên dưới Contents/MacOS
      • Đặt BASH_ENV trong LSEnvironment
      • Chạy bằng open ./poc.app

  • Bản vá

    • Apple đã vá trong macOS Sonoma 14.0 bằng cách chuẩn hóa chuỗi UUID của XPC client
    • Nếu chuỗi đầu vào không phải UUID hợp lệ thì hàm sẽ thoát ra

Mẫu lặp lại

  • Bề mặt tấn công cốt lõi không phải là các XPC service ở System hoặc User domain, mà là PID domain XPC service bên trong các framework hệ thống và private
  • XPC service có Service Type là Application có thể được đăng ký vào PID domain của ứng dụng sandbox chỉ bằng việc nạp framework
  • Nhiều dịch vụ có lỗ hổng không dự tính lời gọi từ sandbox client nên đã bỏ qua các kiểm tra sau
    • Kiểm tra entitlement của XPC client
    • Kiểm tra có phải sandbox client hay không
    • Chuẩn hóa đường dẫn đầu vào
    • Xác minh trạng thái quarantine ở phía máy chủ
  • Các điều kiện bị khai thác lặp đi lặp lại gồm có
    • Thả tệp hoặc thư mục không có quarantine có thể dẫn tới thoát sandbox hoàn toàn
    • Nếu thuộc tính mở rộng quarantine biến mất trong lúc giải nén, có thể dẫn tới vượt qua Gatekeeper và thoát sandbox
    • Các tệp được tạo bởi Service Sandbox mặc định không bị gắn quarantine
  • Vẫn còn 5 báo cáo đang chờ vá

Ý kiến bổ sung về App Sandbox và Service Sandbox

  • Với một báo cáo, Apple cho rằng đây là hành vi như mong đợi vì ứng dụng được khởi chạy mới không nằm trong ngữ cảnh của tiến trình hiện tại và không thể chia sẻ entitlement hay quyền hạn của tiến trình hiện tại
  • Trong App Sandbox, các tệp được thả xuống mặc định sẽ bị gắn quarantine
  • Trong Service Sandbox, các tệp được thả xuống mặc định sẽ không bị gắn quarantine
  • Tác giả kết luận rằng bản thân việc tiến trình mới khởi chạy không nằm trong ngữ cảnh thực thi của dịch vụ hiện tại, nên không chia sẻ entitlement hay privilege của dịch vụ đó, không phải là flaw
  • Ngược lại, việc kẻ tấn công có thể giành được RCE trong ngữ cảnh dịch vụ bị giới hạn bởi sandbox, sau đó thả và chạy một ứng dụng mới không bị sandbox để thoát khỏi các ràng buộc sandbox của dịch vụ mục tiêu, có thể được xem là flaw
    • Ví dụ được nhắc tới là IMTranscoderAgent, mục tiêu của exploit 0-click của NSO Group
  • com.apple.WebDriver.HTTPService.xpc được nêu như một ví dụ tự gọi thủ công API WBSEnableSandboxStyleFileQuarantine
  • Việc thoát từ App Sandbox sang Service Sandbox trên macOS về thực chất được xem là đi tới trạng thái Non Sandbox

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-11-09
Các ý kiến trên Hacker News

  • Cách phản ứng bằng việc vá riêng lẻ từng dịch vụ XPC ở đây hơi kỳ lạ
    Trông giống vấn đề thiết kế của chính sandbox hơn, và tôi thắc mắc tại sao nhiều dịch vụ XPC có vẻ dùng nội bộ cho ứng dụng lại có thể được ứng dụng sandbox truy cập đến vậy

    • Đúng vậy. Rất có thể đây là một sự thỏa hiệp khi macOS nhét thêm cơ chế này vào sau, nhằm tránh phá vỡ những thứ kế thừa từ UNIX và NeXTSTEP
      Phía Windows cũng có nhiều cơ chế tương tự như sandbox WinRT, sandbox ứng dụng Win32, kernel bảo mật, bảo vệ driver, nhưng nếu muốn chạy một file thực thi duy nhất xuyên qua nhiều cấu hình, sẽ xuất hiện các khe hở do tương thích ngược
      Hệ điều hành di động thì dễ hơn nhiều, vì không có gánh nặng tương thích ngược và có thể hạn chế mạnh mô hình thực thi

  • MacOS cần thứ gì đó như container Darwin dựa trên capability, thay vì cách trông như một đống danh sách chặn khổng lồ

    • https://github.com/darwin-containers
      https://news.ycombinator.com/item?id=37655477
      Không có mô hình bảo mật nào hoạt động tốt trên desktop
      Như bình luận khác nói, iOS không có đống di sản cũ nên mới có thể cung cấp một mô hình bảo mật hợp lý
      Ngược lại, nếu Telegram yêu cầu chia sẻ toàn bộ danh bạ và ảnh, người dùng thực sự sẽ cho phép

  • Công trình tốt
    Tuy vậy tôi nghi ngờ liệu kiểu kiến trúc này có phải hướng đi đúng không. Mỗi lần tạo ra một framework bảo mật để ngăn một kiểu tấn công nào đó, dường như một loại vấn đề hoàn toàn mới lại xuất hiện, và cuối cùng tôi không có cảm giác mọi thứ an toàn hơn
    Nó giống cấu trúc luật thuế Hà Lan, nơi các bản vá để ngăn lạm dụng cứ chồng chất lên nhau, và có lẽ nó đã có ý thức rồi cũng nên

    • Vì khá nhiều hệ thống như vậy ngay từ đầu đã không được thiết kế an toàn đúng nghĩa từ đầu đến cuối
      Cách làm đúng thường thất bại trên thị trường vì tương thích ngược hoặc vì nhà phát triển từ chối áp dụng tính năng. Sandbox WinRT là một ví dụ
      Bảo mật trên điện thoại dễ hơn vì không phải lo tương thích ngược, và cho đến nay nhờ cơ chế gác cổng của app store, các nhà phát triển muốn tham gia buộc phải tuân theo
    • Rốt cuộc bảo mật khó dung hòa với tương thích ngược
      Mọi hệ điều hành đang vận hành ngày nay, nếu muốn an toàn đến thế kỷ tới, đều phải được làm lại từ đầu, và trong quá trình đó phải bỏ đi rất nhiều mã. Đó là cái giá phải trả
    • Nhắc đến luật thuế Hà Lan thú vị đấy. Tôi nghĩ cũng không quá gây tranh cãi nếu nói một số “lỗ hổng để lạm dụng” đó được đưa vào một cách có chủ ý
      Có thể suy đoán rằng cũng có những thế lực mạnh muốn nhét thêm nhiều lỗ hổng hơn vào điện toán tiêu dùng
      Các ví dụ nổi tiếng tương ứng là
      https://en.wikipedia.org/wiki/Dutch_Sandwich
      https://en.wikipedia.org/wiki/Intel_Management_Engine#Assert...

  • MacOS, tức NeXTstep, ngay từ đầu đã được tạo ra như một hệ điều hành mở và cực kỳ dễ mở rộng
    Có vô số cách để thêm tiện ích mở rộng hoặc hook của bên thứ ba, và phần mềm có thể được truy cập từ nhiều runtime, nên vào thời đó việc tất cả những thứ này hoạt động trơn tru cùng nhau tự nó đã là một thành tựu kỹ thuật ấn tượng
    Java, Mac cổ điển, X11 và codebase NeXTstep chạy cùng nhau không vấn đề gì nhờ nhiều điểm vào mở rộng của kernel
    Hơn nữa, nền tảng này còn có API cho phép các ứng dụng giao tiếp với nhau mà không gặp trở ngại
    Nhưng Apple đã dần rút lui khỏi triết lý đó và tiếp tục khép hệ thống lại. Đó là một hành trình khá thú vị

  • SBPL (sandbox profile language) khá thú vị. Chi tiết ở đây: https://github.com/0xbf00/simbple
    Tôi tự hỏi liệu có một trình thông dịch Scheme ở đâu đó trong macOS để xử lý thứ này không
    Tái bút: có vẻ sandbox-exec là thứ làm việc này. Tham khảo: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...

  • Phát hiện ấn tượng. Như bài viết cũng ám chỉ, có vẻ khả năng rất cao là vẫn còn những lỗi tương tự ngoài thực tế
    Nếu Apple không thiết kế lại cách tiếp cận tăng cứng các dịch vụ này, có lẽ các CVE liên quan đến XPC sẽ tiếp tục xuất hiện đều đều

  • Vừa thích vừa ghét sandbox
    Nó là tuyến phòng thủ thứ hai tuyệt vời, nhưng các tổ chức lớn có xu hướng từ chối sửa lỗ hổng thực thi mã từ xa nếu không thể thoát sandbox để làm việc gì đó có ý nghĩa. Vì thế sandbox lại bị dùng như tuyến phòng thủ chính, và điều đó thật đáng buồn

    • Tôi không rõ câu “từ chối sửa lỗ hổng thực thi mã từ xa nếu không thể thoát sandbox” là nói về ai
      Theo tôi biết, Apple, Microsoft, Google đều có bug bounty, và dù trả thưởng cao hơn cho lỗi thoát sandbox, họ vẫn trả thưởng cho các lỗ hổng bị sandbox chặn lại
      Ai cũng biết rõ rằng kẻ tấn công sẽ tích trữ các lỗ hổng thực thi mã từ xa hiện chưa dùng được, rồi khi phát hiện lỗi thoát sandbox thì dùng kèm với nhau

  • Hơi lệch khỏi chủ đề một chút, nhưng nếu có chuyên gia sandbox nào biết chiến lược vượt qua giới hạn maximum "pattern serialization length" thì tôi đã đau đầu khá lâu vì vấn đề này: https://github.com/NixOS/nix/issues/4119
    Đáng tiếc là sandbox-exec hầu như không có tài liệu, lại còn nghe nói sẽ bị loại bỏ, nên việc giải quyết khá nhức đầu

  • Trên macOS, các cách vượt qua cứ xuất hiện không dứt. Vì ngay từ đầu hệ điều hành này chưa từng được thiết kế cho kiểu quyền hạn chi tiết như vậy
    Không thể cứ về sau ghép nó lên trên các công nghệ Mac OS kế thừa và NeXTSTEP được
    Tôi không phải nhà nghiên cứu bảo mật, chỉ là một lập trình viên ứng dụng lâu năm, nhưng cũng tự tìm ra nhiều cách vượt qua. Có thể nói là tôi biết xác được chôn ở đâu
    Nhưng cuối cùng tôi đã từ bỏ việc tìm kiếm. Hệ thống báo cáo lỗ hổng bảo mật của Apple hoàn toàn hỗn loạn, và họ có vẻ chỉ quan tâm đến việc bịt miệng người báo cáo càng lâu càng tốt. Phí thời gian
    Nhìn chung, macOS có cảm giác đã trở thành nạn nhân của màn kịch bảo mật. Nó gây hại cho cả người dùng lẫn các nhà phát triển hợp pháp bằng phần mềm bị suy yếu và vô số yêu cầu cấp quyền, trong khi kẻ tấn công thực sự có thể dễ dàng vượt qua khi muốn. Khá giống các quảng cáo nhại Windows Vista ngày xưa của Apple

    • Có vẻ nhà nghiên cứu viết bài này đã thành công trong việc khiến khá nhiều lỗ hổng được vá kèm ghi công. Tuy vậy, một số CVE trong này trông có vẻ đã tồn tại vài năm
      Việc công ty muốn có nhiều thời gian nhất có thể để sửa lỗi cũng là một phần của cuộc chơi. Liệu các công ty khác có thật sự muốn các lỗ hổng được phát hiện bị công bố càng nhanh càng tốt không? Vì không thể kiểm soát người dùng sẽ nâng cấp nhanh đến mức nào, nên trì hoãn công bố luôn tốt hơn cho người dùng cuối, và điều đó nên được ưu tiên hơn nhu cầu quảng bá của nhà nghiên cứu
      Kiến trúc sandbox của Apple thường trông được thiết kế khá tốt. Trong trường hợp này, có vẻ đã có vấn đề ở đâu đó trong kiến trúc hoặc khâu giao tiếp
      Việc tồn tại các cách vượt qua cũng là vì chúng ta đòi hỏi quá nhiều chức năng ở hệ điều hành desktop. Có thể xem hệ điều hành desktop là loại hệ điều hành tinh vi và phức tạp hơn rất nhiều so với nền tảng server. Trình duyệt web có nhiều CVE cũng vì cùng lý do. Vì chúng ta muốn cả bảo mật lẫn tính năng, nên tất yếu sẽ có điểm giao nhau nơi hai thứ xung đột
    • Trái với câu “không thể cứ về sau ghép nó lên trên các công nghệ Mac OS kế thừa và NeXTSTEP”, Apple sở hữu toàn bộ stack nên họ có thể làm, và thực tế đã làm
      Bằng chứng là việc họ đã dần dần gia cố phần mềm và phần cứng macOS trong 20 năm qua
      Quá trình này diễn ra từ từ đến mức hầu hết người dùng cuối không nhận ra, nhưng các nhà phát triển macOS thì hiểu rất rõ những vấn đề liên quan đến bảo mật phải gánh trong cả các bản cập nhật lớn lẫn nhỏ. Ví dụ như sau
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/09/…
    • Kiểu gánh nặng di sản này có vẻ tồn tại trong mọi hệ điều hành phổ biến
      Có các hệ thống dựa trên capability, nhưng không có hệ thống nào thật sự được dùng rộng rãi
      Tôi cũng không rõ giải pháp là gì. Dù vậy, nỗ lực bổ sung bảo mật vẫn có vẻ tốt hơn là không làm gì, để rồi một lỗ hổng ứng dụng lập tức dẫn tới việc chiếm toàn bộ tài khoản người dùng
    • Nếu “không thể thêm về sau lên trên Mac OS kế thừa”, thì SELinux đã làm được; vậy điều gì về cơ bản ngăn cản MacOS?
    • Lý do của các hạn chế này là để khiến nhà phát triển bên thứ ba khó cạnh tranh với sản phẩm của Apple hơn

  • Các XPC service bị bỏ sót trong miền pid là một cách khéo léo để vượt qua hạn chế sandbox của macOS
    Thủ thuật tiêm dyld để né kiểm tra quyền hạn cũng rất mượt
    Bản vá của Apple ở đây có cảm giác chỉ là giải pháp tạm thời, và có lẽ cần chỉnh lại đúng cách cơ chế hoạt động của việc kế thừa sandbox