Vấn đề backdoor xz như một mô hình thu nhỏ của các tương tác trong dự án mã nguồn mở

 (robmensching.com)
21 điểm bởi GN⁺ 2024-03-31 | 1 bình luận | Chia sẻ qua WhatsApp
  • Có lẽ đã có rất nhiều phân tích về lỗ hổng xz/liblzma, nhưng phần lớn có xu hướng bỏ qua giai đoạn đầu tiên của cuộc tấn công
    • Người bảo trì ban đầu bị kiệt sức, và chỉ kẻ tấn công là người đề nghị giúp đỡ (vì vậy kẻ tấn công thừa hưởng lòng tin mà người bảo trì ban đầu đã gây dựng).
  • Lưu trữ chuỗi email đã ghi lại tình hình vào thời điểm giai đoạn 0 này diễn ra

Sự kiệt sức của người bảo trì và sự xuất hiện của kẻ tấn công

  • Một yêu cầu nghe có vẻ hợp lý đã được đưa ra với người bảo trì

    • "XZ for Java vẫn còn được bảo trì chứ? Tôi đã đăng câu hỏi từ một tuần trước mà chưa thấy phản hồi"

  • Câu hỏi này khiến người bảo trì cảm thấy mình phải thừa nhận một "thất bại"
    • Thực tế thì người bảo trì không nợ ai điều gì và cũng không hề thất bại, nhưng lại có cảm giác như vậy
    • Vì việc làm cộng đồng thất vọng là điều rất khủng khiếp
  • Người bảo trì thừa nhận mình đang "tụt lại" và phát đi tín hiệu như đang cầu viện sự giúp đỡ
  • Nhưng trong chuỗi thảo luận đó, sự giúp đỡ đã không đến; thay vào đó, kẻ tấn công xz/liblzma xuất hiện và giới thiệu rằng mình đã giúp anh ấy

    • "Jia Tan (kẻ tấn công lần này) đã giúp tôi... và trong tương lai có thể đảm nhận vai trò lớn hơn... nguồn lực của tôi quá hạn chế, nên rõ ràng về lâu dài sẽ phải có điều gì đó thay đổi."

  • Người bảo trì cũng nhắc rằng nguồn lực của mình có hạn nên về lâu dài cần có sự thay đổi

Sự xuất hiện của người dùng thiếu hợp tác

  • Một người dùng thiếu hợp tác đã đưa ra những lời chỉ trích nhắm vào người bảo trì

    • "Có lẽ sẽ không có tiến triển gì cho đến khi có người bảo trì mới. ... người quản lý hiện tại đã mất hứng thú hoặc không còn quan tâm đến việc bảo trì nữa. Thật buồn khi nhìn thấy một kho mã như thế này."

  • Người bảo trì tự bảo vệ mình rằng anh ấy không hề mất hứng thú, nhưng khả năng quản lý bị hạn chế do các vấn đề sức khỏe tinh thần và những lý do tương tự
  • Người bảo trì cũng nhắc lại rằng đây là một dự án sở thích không được trả công

Yêu cầu ngày càng gia tăng

  • Một tuần sau, người dùng thiếu hợp tác lại xuất hiện và tiếp tục chỉ trích người bảo trì.

    • "Bạn đang phớt lờ rất nhiều bản vá đang dần mục nát trong mailing list này."

    • "Tôi rất tiếc về các vấn đề sức khỏe tinh thần của bạn, nhưng điều quan trọng là phải nhận thức được giới hạn của bản thân. Tôi biết dự án này là một dự án sở thích cho mọi người đóng góp, nhưng cộng đồng muốn nhiều hơn thế."

  • Người đưa ra yêu cầu cũng có đề xuất, nhưng không hề có lời đề nghị sẽ trực tiếp giúp đỡ

    • "Hay là chuyển quyền bảo trì XZ for C để bạn có thể tập trung hơn vào XZ for Java? Hoặc chuyển XZ for Java cho người khác để bạn có thể tập trung vào XZ for C? Nếu cố duy trì cả hai thì có thể cả hai đều sẽ không được bảo trì tốt."

  • Người bảo trì giải thích rằng việc tìm một đồng bảo trì mới hoặc bàn giao hoàn toàn dự án không hề dễ dàng

Thực tế của các dự án mã nguồn mở

  • Các nhà phát triển phần mềm không phải là những bánh răng có thể tùy ý tháo ra lắp vào
  • Chuỗi email kết thúc khi người dùng chỉ biết phàn nàn tiếp tục đưa ra yêu cầu nhưng không hề cung cấp bất kỳ sự giúp đỡ nào, và chỉ còn lại kẻ tấn công

    • "Jia Tan có thể sẽ đảm nhận vai trò lớn hơn trong dự án thời gian tới. Anh ấy đã giúp đỡ rất nhiều ngoài danh sách thư, và trên thực tế gần như đã là đồng quản trị viên rồi. :-)"

  • Chuỗi email này cho thấy một mô hình thu nhỏ của các tương tác trong các dự án mã nguồn mở
  • Người dùng đưa ra các yêu cầu đối với người bảo trì, còn người bảo trì phản ứng theo nhiều cách khác nhau dưới áp lực, căng thẳng và kiệt sức
  • Cách vận hành như vậy cần phải thay đổi

Bài viết liên quan

1 bình luận

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

  • Có ý kiến cho rằng các nhà phát triển đang lãng phí rất nhiều năng lượng tinh thần khi cố tỏ ra thân thiện với người dùng và luôn cố nhìn nhận thiện chí của người viết bình luận. Những ý kiến như vậy chủ yếu xuất hiện ở các dự án phụ làm vì vui (trình giả lập, bản làm lại game, v.v.). Các dự án này tránh nhắc đến quyên góp để né các vấn đề về tiền quyên góp hoặc bản quyền. Dù có nhiều sự quan tâm dành cho dự án, nhưng sự quan tâm có tay nghề và có thể đóng góp thực tế lại cực kỳ hạn chế. Các cuộc trò chuyện của người dùng được cho phép và khuyến khích, nhưng đôi khi có thể bị cảm nhận như những "đề xuất" hay "yêu cầu" làm giảm động lực của nhà phát triển. Việc duy trì cộng đồng là quan trọng, nhưng cũng có lo ngại về việc không loại trừ những người không trực tiếp đóng góp.

  • Vấn đề bắt đầu từ một cuộc tấn công social engineering, trong đó nhà phát triển của dự án nguồn mở bị gây áp lực phải trao thêm quyền kiểm soát kho mã cho kẻ tấn công.

  • Với tư cách là người bảo trì một thư viện nguồn mở thiên về bảo mật, mỗi lần đọc PR lại thấy nặng nề với sự nghi ngờ: "Người này thực sự muốn giúp đỡ, hay đang muốn lợi dụng mình?" Tôi nghĩ cách giải quyết duy nhất là làm chậm tốc độ phát triển, nhưng cảm giác mà điều đó mang lại cũng giống như những gì bài viết mô tả. Nếu có một cách đơn giản để nhờ đến sự trợ giúp từ một cộng đồng chuyên gia đáng tin cậy, tôi sẽ luôn hoan nghênh.

  • Cũng như tiền mã hóa, AI và vụ việc lần này, vấn đề lớn nhất cuối cùng vẫn quy về niềm tin. Tiền mã hóa cố giải quyết vấn đề niềm tin bằng mã nguồn, LLM thì cố đánh lừa bằng vẻ hào nhoáng để giành được niềm tin, còn kẻ tấn công đã phần nào thành công trong việc "rửa" niềm tin. Những kỹ sư quan trọng nhất lại đang không suy nghĩ đúng mức về niềm tin. Trong trường hợp này, có thể hiểu được cho nhà phát triển nguồn mở kiệt sức và không được trả công.

  • Có câu hỏi liệu một máy chủ SSH được cấu hình port knocking có an toàn trước backdoor này hay không. Vì RCE chỉ có thể được thực thi sau khi kết nối đến máy chủ SSH, nên nếu cổng được ẩn sau một chuỗi gõ cửa TCP/UDP hợp lý thì có vẻ sẽ không phát sinh vấn đề. Port knocking không thay thế cho cấu hình SSH đúng cách, nhưng nó hữu ích như một lớp phòng thủ bổ sung để phòng ngừa hoặc kéo dài thời gian ứng phó khi xuất hiện lỗ hổng SSH.

  • Có một liên kết nói về vấn đề liên quan đến bản vá dành riêng cho Linux của OpenSSH. Nếu không có bản vá này thì sự cố đã không xảy ra. Đây không phải vấn đề của OpenSSH mà là của Linux.

  • Có ý kiến cho rằng ngay cả sau sự cố left-pad, mọi người vẫn đang xem nhẹ sự phụ thuộc cứng và độ phức tạp. OpenSSH là một bức tường mã khổng lồ. Các hệ thống phức tạp vốn dĩ khó để tin cậy, bất kể chúng được viết bằng ngôn ngữ nào.

  • Nếu một hacker Trung Quốc muốn làm điều ác ý, tại sao lại dùng tên/handle Trung Quốc? Để có được nhiều niềm tin hơn từ các maintainer nguồn mở, dùng tên tiếng Anh/châu Âu sẽ tốt hơn. Ngược lại, nếu một hacker không phải người Trung Quốc muốn làm điều ác ý, thì dùng tên Trung Quốc lại hợp lý hơn (kiểu như Trung Quốc là cái ác, v.v.).

  • Tài khoản Jigar Kumar có vẻ là một phần của cuộc tấn công social engineering và lẽ ra phải bị xem là cực kỳ đáng ngờ.

  • Lập trình viên không phải là những bộ phận có thể thay thế cho nhau, và có người đang nghĩ đến việc hạn chế quyền bình luận hoặc tham gia trong cộng đồng. Ví dụ, nếu GitHub đưa vào một "cổng", thì cổng đầu tiên có thể là thêm vào bộ test một bài kiểm tra tạo ra số phiên bản và hash của đầu ra test. Khi thêm con số này vào hồ sơ, GitHub có thể tin rằng người dùng ít nhất đã tải về và chạy make test. Điều này cho thấy một mức độ cam kết nhất định.