Sự cố bảo mật Apple curl 12604

Sự cố bảo mật Apple curl 12604

• Vào ngày 28 tháng 12 năm 2023, báo cáo lỗi 12604 đã được gửi lên trình theo dõi issue của curl.
• Tiêu đề của vấn đề là "flag –cacert behavior isn’t consistent between macOS and Linux", chỉ ra rằng hành vi của cờ --cacert không nhất quán giữa macOS và Linux.
• Người báo cáo cho thấy phiên bản curl được đóng gói sẵn trên macOS hoạt động khác với binary curl được build hoàn toàn từ mã nguồn mở.

Phiên bản của Apple kiểm tra kho CA hệ thống như bước thứ hai

• Tùy chọn dòng lệnh --cacert cung cấp cách để người dùng yêu cầu curl chỉ tin cậy một tập chứng chỉ CA cụ thể.
• Khi dùng phiên bản curl do Apple cung cấp trên macOS, nếu việc xác thực bằng tập chứng chỉ CA được cung cấp thất bại thì dường như nó sẽ kiểm tra kho CA hệ thống như bước thứ hai.
• Điều này không được tài liệu hóa và là hành vi ngoài dự kiến đối với người dùng.

Đây là vấn đề bảo mật

• Khi người dùng chạy kiểm tra với tệp chứng chỉ CA do họ chỉ định, nếu trong kho CA hệ thống có chứng chỉ có thể xác thực máy chủ thì quá trình này sẽ không thất bại.
• Điều này tạo ra một vấn đề bảo mật khiến việc kiểm tra chứng chỉ lẽ ra không được thông qua lại vẫn được thông qua.

Apple nói rằng không có vấn đề

• Vào ngày 8 tháng 3 năm 2024, bộ phận bảo mật sản phẩm của Apple phản hồi rằng phiên bản OpenSSL của họ (LibreSSL) theo chủ đích sử dụng kho tin cậy hệ thống tích hợp sẵn làm nguồn tin cậy mặc định.
• Vì chứng chỉ máy chủ có thể được xác thực thành công bằng kho tin cậy hệ thống tích hợp sẵn, họ không xem đây là một vấn đề.

Không đồng ý

• Do tính năng không được tài liệu hóa này, việc xác thực chứng chỉ CA bằng curl trên macOS hoàn toàn không thể được tin cậy và không khớp với tài liệu.
• Điều này có thể gây nhầm lẫn cho người dùng.
• Vấn đề này không phải là lỗ hổng bảo mật trong phiên bản curl mà chúng tôi phân phối, nên sẽ không phát hành CVE.
• Xét một cách nghiêm ngặt, vấn đề không nằm trong mã curl mà nằm ở phiên bản LibreSSL do Apple cung cấp và dùng để build curl.

Ý kiến của GN⁺

• Sự việc này nhấn mạnh tầm quan trọng của bảo mật và độ tin cậy trong phần mềm. Khi người dùng muốn chỉ sử dụng các chứng chỉ CA mà họ tin cậy một cách tường minh, việc hệ thống ngầm chấp nhận các chứng chỉ khác có thể gây ra lo ngại bảo mật nghiêm trọng.
• Phản hồi của Apple cho thấy có một khoảng cách giữa tiêu chuẩn bảo mật do doanh nghiệp tự định nghĩa và kỳ vọng của cộng đồng mã nguồn mở. Điều này có thể khơi mào thảo luận về việc người dùng và nhà phát triển nên nhận thức và quản lý bảo mật trên nền tảng đó như thế nào.
• Những vấn đề như vậy nhấn mạnh các bài toán về phụ thuộc và tích hợp có thể phát sinh khi sử dụng phần mềm mã nguồn mở. Nhà phát triển cần nhận thức các khác biệt này và có phản ứng phù hợp khi sử dụng các thư viện và công cụ do nền tảng cụ thể cung cấp.
• Các dự án khác cung cấp chức năng tương tự gồm có OpenSSL và GnuTLS, và chúng có triết lý bảo mật cũng như cách triển khai riêng. Người dùng và nhà phát triển có thể cân nhắc những lựa chọn thay thế này.
• Khi áp dụng công nghệ, cần xem xét kỹ mô hình bảo mật của công nghệ đó và khả năng tương thích giữa các nền tảng. Sự việc này cho thấy cách triển khai LibreSSL của Apple hoạt động khác với hành vi chuẩn của curl, qua đó nhấn mạnh tầm quan trọng của việc lựa chọn công nghệ.

[GN⁺]

Ý kiến trên Hacker News

• Chỉ trích một "tính năng" cụ thể của Apple

  • Tính năng này có thể thêm các bước tính toán không cần thiết hoặc phá vỡ mô hình xác minh được kỳ vọng.
  • Lý do người dùng muốn cung cấp CA riêng có thể là vì CA đó không có trong gói CA của OS, hoặc vì họ muốn xác minh với một CA cụ thể.
  • Cách hành xử này của Apple không phải là kết quả được mong đợi.

• Chính sách của Apple được ưu tiên bất kể ý định của chủ sở hữu thiết bị Apple

  • Việc chính sách của Apple được đặt lên trên, bỏ qua điều mà "chủ sở hữu" thiết bị Apple muốn, là một hiện tượng phổ biến và không có gì đáng ngạc nhiên.

• Giải thích về việc libcurl sử dụng kho CA

  • Khi đặt tùy chọn CURLSSLOPT_NATIVE_CA, libcurl sẽ sử dụng kho CA mặc định của hệ điều hành để thực hiện xác minh chứng chỉ.
  • Nếu đã thiết lập tệp hoặc thư mục chứng chỉ CA, chúng sẽ được tìm kiếm cùng với kho CA mặc định.
  • Khi kết hợp với tùy chọn --cacert, libcurl có thể cố gắng tôn trọng cả hai thiết lập, điều này cho thấy chúng có thể loại trừ lẫn nhau.

• Tình huống tương tự vụ việc SQLite F_BARRIERFSYNC

  • Có vẻ như Apple không quan tâm.

• Cần chỉnh sửa curl theo chỉ ra của Daniel

  • Nếu Daniel chỉ ra vấn đề của curl thì Apple cần phải sửa nó.

• Vấn đề trong tài liệu curl và lỗ hổng bảo mật của libcurl

  • curl không tự triển khai trực tiếp mọi giao thức mà hỗ trợ nhiều thư viện khác nhau.
  • Nhược điểm của cách tiếp cận này là khó đảm bảo hành vi nhất quán giữa các backend độc lập.
  • libressl không phải là bản tái triển khai hoàn chỉnh của openssl và không có nghĩa vụ mô phỏng đầy đủ API của nó.
  • curl có hai lựa chọn: ngừng hỗ trợ thư viện đó hoặc ghi lại vấn đề trong tài liệu.
  • Để tránh làm hỏng mã người dùng, ít nhất cũng nên ghi lại vấn đề trong tài liệu.
  • Cách tiếp cận của libressl có khiếm khuyết về mặt bảo mật và có thể có lý do để mở CVE.

• Sự thiếu tin tưởng vào phần mềm đi kèm macOS

  • Dùng MacPorts để ghi đè các công cụ đi kèm macOS (ví dụ: curl), vì chúng thường cũ hoặc có vấn đề.

• Hành vi mặc định của Apple có thể bị xem là một cửa hậu

  • Không nói rằng đó là cố ý hay ác ý, nhưng trên thực tế nó có thể hoạt động như một cửa hậu.
  • Việc thêm khóa vào hệ thống xác thực của người dùng cũng giống như thêm một cửa hậu.

• Chỉ trích việc Apple không coi trọng bảo mật của người dùng

  • Hành vi mặc định và hành vi thay thế là khác nhau.
  • Điều này gợi ý rằng đội ngũ bảo mật của Apple có thể có vấn đề về khả năng đọc hiểu.