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

 (daniel.haxx.se)
1 điểm bởi GN⁺ 2024-03-10 | 1 bình luận | Chia sẻ qua WhatsApp
  • curl do Apple đóng gói trên macOS xử lý tùy chọn --cacert khác với bản dựng mã nguồn mở, làm phá vỡ kỳ vọng xác thực TLS rằng chỉ CA do người dùng chỉ định mới được tin cậy
  • --cacert là tùy chọn buộc chứng chỉ máy chủ chỉ được xác thực bằng tập chứng chỉ CA đã chỉ định, và nếu xác thực thất bại thì curl phải trả về lỗi
  • curl do Apple cung cấp dường như còn kiểm tra thêm kho CA hệ thống ngay cả khi việc xác thực bằng CA đã chỉ định thất bại; hành vi này không được yêu cầu và cũng không được tài liệu hóa
  • Apple Product Security trả lời rằng LibreSSL, bản OpenSSL của Apple, cố ý dùng kho tin cậy hệ thống tích hợp làm nguồn tin cậy mặc định, nên đây không phải đối tượng cần sửa
  • Đây không phải lỗ hổng trong bản phân phối của dự án curl nên không có CVE nào được cấp, nhưng kết quả xác thực CA của curl đi kèm macOS có thể khác với tài liệu

Khởi đầu của issue 12604

  • Ngày 28/12/2023, bugreport 12604 được tạo trên trình theo dõi issue của curl
  • Tiêu đề issue là “flag --cacert behavior isn’t consistent between macOS and Linux”, do Yuedong Wu báo cáo
  • Ngay cả khi chạy cùng một phiên bản curl trên cùng một máy macOS, hành vi của curl do Apple đóng gói và file nhị phân curl được build từ mã nguồn mở vẫn khác nhau

Những đảm bảo mà --cacert khiến người dùng kỳ vọng

  • Tùy chọn dòng lệnh --cacert của curl là cách để các lần truyền sau đó chỉ tin cậy chính xác tập chứng chỉ CA đã được chỉ định
  • Nếu máy chủ TLS không cung cấp chứng chỉ có thể được xác thực bằng tập chứng chỉ đó, curl phải thất bại và trả về lỗi
  • Tùy chọn này được thêm vào curl từ tháng 12/2000, là tính năng để người dùng xác nhận họ đang giao tiếp với máy chủ mà họ biết và tin cậy
  • Cuối cùng, nó chạm trực tiếp tới vai trò cốt lõi mà TLS phải cung cấp

Hành vi ngoại lệ của curl đi kèm macOS

  • curl cho macOS do Apple cung cấp dường như sẽ kiểm tra thêm kho CA hệ thống nếu việc xác thực bằng tập chứng chỉ CA đã chỉ định thất bại khi dùng --cacert
  • Việc kiểm tra bổ sung này không phải hành vi người dùng yêu cầu và cũng không có trong tài liệu, nên rất khó dự đoán
  • Ngay cả khi người dùng cố xác thực bằng một file chứng chỉ CA chuyên dụng đã được thu gọn, nếu kho CA hệ thống có chứng chỉ có thể xác thực máy chủ thì yêu cầu vẫn không thất bại
  • Kết quả là xác thực chứng chỉ lẽ ra không được thông qua vẫn có thể được thông qua, nên đây được xem là một vấn đề bảo mật

Phản hồi từ Apple Product Security

  • Vào 08:30 UTC ngày 29/12/2023, email báo cáo vấn đề bảo mật đã được gửi tới Apple Product Security
  • Apple Product Security phản hồi vào ngày 08/03/2024
  • Phản hồi của Apple có thể tóm tắt thành hai ý
    • LibreSSL, bản OpenSSL của Apple, cố ý sử dụng kho tin cậy hệ thống tích hợp 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, Apple không xem đây là vấn đề cần được xử lý trên nền tảng của họ
  • Apple đã đóng trường hợp này

Đánh giá từ phía dự án curl và ảnh hưởng tới người dùng

  • Tính năng không được tài liệu hóa này trên macOS khiến việc xác thực chứng chỉ CA của curl không còn nhất quán với tài liệu
  • Người dùng kỳ vọng chỉ tập chứng chỉ CA được chỉ định bằng --cacert mới được sử dụng, nhưng curl do Apple cung cấp lại hoạt động khác với kỳ vọng đó
  • Vấn đề này không phải lỗ hổng bảo mật của phiên bản curl do dự án curl phát hành
    • Dự án curl không cấp CVE cho vấn đề này
    • Nguyên nhân không nằm ở mã curl mà xuất phát từ phiên bản LibreSSL mà Apple cung cấp trên nền tảng và dùng để build curl
  • Khi sử dụng curl do Apple cung cấp trên macOS, kết quả xác thực dựa trên --cacert có thể khác với bản dựng curl mã nguồn mở

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-10
Ý kiến trên Hacker News

  • Hành vi đó hoàn toàn ngớ ngẩn. Nếu tôi tự chỉ định CA, lý do chỉ có một trong hai: CA của tôi không có trong gói của hệ điều hành, hoặc tôi muốn chỉ xác thực với một CA cụ thể
    Tức là “tính năng” này của Apple hoặc chỉ thêm tính toán vô ích, hoặc phá vỡ mô hình xác thực mà tôi kỳ vọng. Cả hai đều không phải kết quả đáng mong đợi

    • Đính chính nhỏ: khi lần kiểm tra đầu tiên thất bại, nó fallback sang kho CA của Apple. Vì vậy có lẽ nó không thêm tính toán vô ích
      Dù vậy, tôi vẫn đồng ý đây là hành vi tệ vì không phải kết quả mong đợi. Xét việc Apple thường thích các thay đổi phá vỡ tương thích ngược, và việc tính năng này được thêm vào curl, có vẻ Apple còn có lý do nào đó chưa nói ra. Có thể nó được dùng cho công cụ chẩn đoán của nhà phát triển hoặc xác thực AppStore
    • Có câu đừng quy cho ác ý những gì có thể giải thích bằng sự ngu ngốc, nhưng nếu một tác nhân độc hại dùng dao cạo Hanlon làm lập luận phòng vệ thì càng phải đặc biệt cẩn trọng

  • Đáng tiếc là hành vi kiểu này, nơi chính sách của Apple luôn được ưu tiên bất kể “chủ sở hữu” thiết bị Apple muốn làm gì, không có gì đáng ngạc nhiên và là điều nên luôn dự liệu ở Apple

    • Đó là lý do tôi không dùng Apple nữa. Thiết bị của họ có vẻ được chế tạo rất tốt và hệ điều hành cũng được trau chuốt, nhưng việc nhốt bạn vào cách làm và hệ sinh thái của họ, rồi còn chặn cả quyền truy cập phần cứng của chính bạn, không phù hợp với việc sống như một hacker theo nghĩa của HN
      Ít nhất là không phù hợp ở phần đó của đời sống số, và xét giá cả thì cũng khó mua chỉ để đặt thêm một thiết bị bên cạnh. Tôi vẫn luôn cân nhắc thử sản phẩm Apple, gần đây cả headset AR cũng vậy, nhưng cho đến giờ chúng trông quá thù địch với lập trình viên hoặc người thích mày mò
    • Nếu chạy curl mã nguồn mở, bạn sẽ có hành vi mong muốn
    • Đáng tiếc là luôn có những người diễn giải quá mức các quyết định kỹ thuật cấp thấp để “chứng minh” định kiến của mình
      Cho rằng một công ty lớn như Apple đưa ra quyết định này vì một tầm nhìn lớn hơn là “sở hữu thiết bị của người dùng” tức là đang gán cho Apple năng lực tổ chức và điều phối khổng lồ. Ở các tổ chức chỉ bằng 1/10 Apple tôi còn chưa từng nghe mức đó. Nhưng vì là Apple mà, đúng không!?
    • Chủ sở hữu là Apple, bạn chỉ là người dùng thôi ;)

  • Có lẽ Apple đang thiết lập cái này chăng?[0] phần nhấn mạnh là của tôi
    CURLSSLOPT_NATIVE_CA
    Yêu cầu libcurl dùng kho CA mặc định của hệ điều hành để xác thực chứng chỉ. Nếu đặt tùy chọn này đồng thời cũng đặt tệp chứng chỉ CA hoặc thư mục, thì trong quá trình xác thực, các chứng chỉ đó cũng được tìm kiếm cùng với kho CA mặc định
    Khi --cacert được kết hợp với tùy chọn này, có vẻ libcurl cố tôn trọng cả hai. Chẳng phải hai thứ này nên loại trừ lẫn nhau sao?

    • Không, trường hợp đó không phải vậy. Binary curl biết cách gọi thư viện libcurl

  • Đây là backdoor
    Tôi không nói là có chủ ý hay ác ý. Nhưng trên thực tế nó đúng là backdoor. Nếu bắt đầu thêm khóa vào hệ thống chứng thực của người dùng, thì tức là bạn đã thêm backdoor

    • Trông chính xác giống kiểu việc NSA có thể gây sức ép để các công ty công nghệ lớn của Mỹ làm

  • Hành vi mặc định đúng là đáng ngờ, nhưng tôi không hoàn toàn đồng ý với đánh giá này. Thực ra đây là vấn đề tài liệu hóa của curl
    curl là thư viện đa giao thức nên không tự triển khai mọi giao thức; trong hầu hết trường hợp nó dựa vào các “backend” phụ thuộc bắc cầu, giao việc diễn giải bit ở mức thấp cho bên ngoài. Một số giao thức có hỗ trợ nhiều thư viện thay thế vì những lý do hợp lý
    Nhược điểm của cách tiếp cận này là khó hoặc không thể đảm bảo hành vi chung giữa các backend độc lập. Chúng có thể không cung cấp cùng một tập tính năng, API có thể không đầy đủ, hoặc như lần này, có thể không cung cấp cách vá một phần hành vi mặc định. LibreSSL không phải là bản tái triển khai OpenSSL chính xác đến từng bit, và cũng không có nghĩa vụ mô phỏng hoàn toàn API đó
    Trong trường hợp như vậy, nếu upstream không muốn sửa, curl còn hai lựa chọn: bỏ hỗ trợ thư viện đó, hoặc tài liệu hóa hành vi đặc thù ấy. Cái trước có thể làm hỏng mã của người dùng, nên ít nhất phải làm cái sau
    Dù vậy, tôi đồng ý với ý chính lớn hơn rằng cách này là một khiếm khuyết từ góc nhìn bảo mật của LibreSSL, và có lẽ có lý do để mở CVE. Chỉ là đối tượng nên là LibreSSL

    • Nếu nguyên nhân gốc nằm ở thư viện SSL của hệ thống, tôi không hiểu lắm việc build curl từ source lại tránh được vấn đề này như thế nào

  • Làm tôi nhớ đến vụ F_BARRIERFSYNC của SQLite
    Đơn giản là họ không quan tâm
    https://bonsaidb.io/blog/acid-on-apple/

    • Tôi nhớ trước đây Apple từng làm hỏng một trong những công cụ Unix cũ mà họ thực sự phân phối kèm bằng cách nhét một tùy chọn vào một cách cẩu thả
      Thái độ bảo trì của họ còn thấp hơn khoảng hai bậc so với việc người Debian làm hỏng OpenSSL

  • Nếu Daniel nói curl của các anh bị hỏng thì cứ sửa đi, Apple. Đơn giản vậy thôi

    • Daniel cũng có thể sai. Thậm chí có thể sai cả về curl
      Ở đây, sau 2 phút kiểm tra thì có lẽ ông ấy đúng, nhưng “vì là Daniel nên đúng” là kiểu lập luận tệ nhất
      Nó làm tôi nhớ đến cuộc trao đổi cũ quanh lịch sử của C, đặc biệt là “đóng góp” của Eric S. Raymond: https://scienceblogs.com/deltoid/2011/10/14/dennis-ritchie-h...

  • Cảm ơn vì cảnh báo. Nhân tiện, tôi đang dùng MacPorts để thay thế khá nhiều công cụ đi kèm macOS. curl cũng là một trong số đó
    Các công cụ đi kèm nhìn chung đã cũ hoặc bị hỏng theo cách nào đó. Tôi đã mất niềm tin vào phần mềm Apple đóng gói từ lâu

  • Tôi tự hỏi liệu Apple có đang phụ thuộc vào hành vi này cho một thứ quan trọng nào đó không

    • Không rõ bạn có đang mỉa mai không, nhưng điều này rõ ràng rất quan trọng
      Việc ai đó viết script để chỉ dùng CA nội bộ riêng là hoàn toàn hợp lý. Khi chạy lệnh này, họ biết rằng vì đó là CA nội bộ của công ty nên nó chỉ giao tiếp với tài nguyên nội bộ của công ty
      Thế nhưng Apple lại thêm vào đây một backdoor lớn ngang với xác thực tên miền
      Hơn nữa, việc dùng một tên giả và chỉ dựa vào sự thật rằng CA của công ty đã ký để xác nhận rằng bạn đang kết nối tới máy chủ công ty cũng hoàn toàn hợp lý. Nhưng Apple đã phá vỡ giả định rất hợp lý này và tạo ra lỗ hổng bảo mật. Không ổn chút nào
    • Có thể là để giúp nghe lén TLS trong doanh nghiệp/chính phủ dễ hơn
    • Hoặc là cực kỳ ngu ngốc, hoặc là độc ác

  • Hóa ra việc nói Apple quan tâm đến bảo mật người dùng cũng chỉ đến mức này thôi