Những gì đã biết về cửa hậu xz Utils suýt lây nhiễm gần như toàn thế giới

 (arstechnica.com)
3 điểm bởi GN⁺ 2024-04-02 | 1 bình luận | Chia sẻ qua WhatsApp
  • Andres Freund của Microsoft khi lần theo bất thường hiệu năng SSH trên hệ thống Debian đã phát hiện ra cửa hậu được cài vào xz Utils, công cụ được dùng trên gần như mọi môi trường Linux/Unix
  • Mã độc đã được đưa vào xz Utils 5.6.0 và 5.6.1, được thiết kế để kẻ tấn công sở hữu khóa riêng cụ thể có thể giấu mã trong chứng chỉ đăng nhập SSH và thực thi nó trên thiết bị có cửa hậu
  • Kẻ tấn công tìm cách móc vào quy trình xác thực của sshd thông qua liblzma, sử dụng release tarball thay vì mã nguồn GitHub, các tệp kiểm thử, script build và glibc IFUNC
  • Cửa hậu kiểm tra các điều kiện build gói như amd64/x86_64, glibc, Debian hoặc họ Red Hat, và đã xuất hiện trong Fedora Rawhide, Fedora 41, Debian testing/unstable/experimental, openSUSE Tumbleweed/MicroOS, cùng một số bản phát hành Kali Linux trong một khoảng thời gian nhất định
  • Nhân vật nhà phát triển Jia Tan đã tham gia bảo trì xz Utils trong nhiều năm, vụ việc được theo dõi với mã CVE-2024-3094, và đã xuất hiện các công cụ phát hiện/phân tích như trang kiểm tra Binarly và xzbot

Phát hiện và phạm vi ảnh hưởng

  • Andres Freund là nhà phát triển và kỹ sư tại Microsoft làm việc liên quan đến PostgreSQL, đã phát hiện dấu hiệu bất thường khi điều tra hiện tượng đăng nhập SSH trên hệ thống Debian dùng CPU quá mức và gây lỗi valgrind
  • Nguyên nhân là bản cập nhật xz Utils, và Freund đã công bố trên Open Source Security List rằng bản cập nhật này là một cửa hậu được cài có chủ đích vào phần mềm nén
  • xz Utils cung cấp khả năng nén và giải nén dữ liệu không mất mát trên gần như mọi hệ điều hành họ Unix, bao gồm Linux, và cũng hỗ trợ định dạng .lzma legacy
  • Filippo Valsorda đánh giá đây có thể là “ví dụ được thực hiện tốt nhất trong số các cuộc tấn công chuỗi cung ứng từng được mô tả công khai, và là kịch bản ác mộng về một upstream độc hại, có năng lực và có đặc quyền của một thư viện được dùng rộng rãi”

Hành vi mà cửa hậu nhắm tới

  • Mã độc được thêm vào xz Utils 5.6.0 và 5.6.1 để thay đổi cách phần mềm hoạt động
  • Cửa hậu thao túng sshd, tệp thực thi được dùng cho các kết nối SSH từ xa
  • Người sở hữu khóa mã hóa được định trước có thể giấu mã mong muốn trong chứng chỉ đăng nhập SSH, tải nó lên rồi thực thi trên thiết bị có cửa hậu
  • Do chưa xác nhận được mã nào thực sự đã được tải lên, nên chưa rõ kẻ tấn công định chạy loại mã gì
  • Về lý thuyết, gần như có thể làm bất cứ việc gì, từ đánh cắp khóa mã hóa đến cài mã độc

Con đường thư viện nén chạm tới SSH

  • Thư viện có thể thao túng hoạt động nội bộ của tệp thực thi được liên kết với nó
  • Triển khai sshd tiêu biểu của OpenSSH mặc định không liên kết với liblzma
  • Debian và nhiều bản phân phối Linux đã thêm bản vá để kết nối sshd với systemd
    • systemd là chương trình nạp nhiều dịch vụ trong lúc khởi động
    • systemd được liên kết với liblzma
    • Chính đường liên kết này khiến xz Utils có thể ảnh hưởng tới sshd

Dấu hiệu chuẩn bị trong nhiều năm

  • Năm 2021, người dùng JiaT75 để lại commit đầu tiên được biết đến trong một dự án mã nguồn mở
    • Đó là thay đổi trong dự án libarchive chuyển hàm safe_fprint sang một biến thể vốn давно được biết là kém an toàn hơn, nhưng khi đó không ai nhận ra
  • Năm 2022, JiaT75 gửi bản vá lên mailing list của xz Utils
    • Không lâu sau, một người tham gia mới tên Jigar Kumar gây áp lực rằng Lasse Collin không cập nhật xz Utils đủ thường xuyên hoặc đủ nhanh
    • Dennis Ens và các người tham gia mới khác cũng gây sức ép để Collin bổ sung thêm maintainer
  • Tháng 1/2023, JiaT75 để lại commit đầu tiên trong xz Utils và tham gia sâu hơn vào công việc của dự án dưới tên Jia Tan
    • Thay thông tin liên hệ của Collin trong oss-fuzz bằng thông tin của mình
    • Yêu cầu thay đổi để vô hiệu hóa tính năng IFUNC trong các bài kiểm thử oss-fuzz, khiến các thay đổi độc hại sau này trong xz Utils không bị phát hiện
  • Tháng 2/2024, Tan thực hiện các commit cho xz Utils 5.6.0 và 5.6.1, và các bản cập nhật này triển khai cửa hậu
  • Sau đó, Tan hoặc những người khác đã yêu cầu các nhà phát triển Ubuntu, Red Hat và Debian hợp nhất bản cập nhật này vào hệ điều hành

Các bản phân phối bị ảnh hưởng và điều kiện thực thi

  • Theo Tenable, phiên bản có cửa hậu hoặc bản cập nhật liên quan đã vào các bản phát hành sau
    • Fedora Rawhide: bản phân phối phát triển của Fedora Linux
    • Fedora 41
    • Debian testing, unstable, experimental: từ 5.5.1alpha-0.1 đến 5.6.1-1
    • openSUSE Tumbleweed và openSUSE MicroOS: chứa phiên bản xz có cửa hậu trong khoảng từ ngày 7/3 đến 28/3
    • Kali Linux: chứa xz-utils 5.6.0-0.2 trong khoảng từ ngày 26/3 đến 28/3
  • Theo phân tích của Sam James, script độc hại kiểm tra xem mục tiêu build có phải amd64/x86_64 hay không, có dùng tên linux-gnu hay không, và có dùng GCC cùng GNU ld hay không
  • Ngoài ra, nó cũng kiểm tra xem đây có phải bản build gói Debian hay RPM_ARCH có phải x86_64 hay không
  • Cuộc tấn công dường như nhắm vào môi trường dùng glibc trên hệ thống amd64 và build các bản phân phối phái sinh từ Debian hoặc Red Hat
  • Khi đó chưa rõ các hệ thống khác có dễ bị tấn công hay không

Cách triển khai và kỹ thuật che giấu

  • Sam James tóm tắt rằng cửa hậu gồm nhiều thành phần
    • release tarball do upstream phát hành không giống với mã trên GitHub
    • build-to-host.m4 trong release tarball khác biệt đáng kể với bản upstream trên GitHub
    • Thư mục tests/ trong kho git chứa các tệp kiểm thử đã bị thao túng
      • tests/files/bad-3-corrupt_lzma2.xz
      • tests/files/good-large_compressed.lzma
    • Script được build-to-host.m4 gọi ra giải nén dữ liệu kiểm thử độc hại và chỉnh sửa quy trình build
    • IFUNC của glibc được dùng để hook hoặc chuyển hướng quy trình xác thực của OpenSSH lúc runtime
  • HD Moore xác nhận giai đoạn cửa hậu cuối cùng chỉ chạy khi build thư viện trên amd64 và tạo gói Debian hoặc RPM
  • Theo phân tích của các nhà nghiên cứu, trong quá trình xác minh khóa công khai SSH, nếu một hàm fingerprint cụ thể và khóa công khai khớp, nội dung khóa sẽ được giải mã bằng khóa chia sẻ trước trước khi bước xác minh khóa thực sự diễn ra
  • Nội dung sau giải mã, nếu khớp với định dạng nhất định, sẽ được chuyển thẳng tới system
  • Nếu fingerprint không khớp hoặc nội dung giải mã không đúng định dạng, hệ thống quay lại xác minh khóa thông thường và người dùng rất khó nhận ra khác biệt

Chuỗi thực thi do Akamai tổng hợp

  • Các nhà nghiên cứu của Akamai cho rằng cửa hậu chỉ được đưa vào bản phát hành tarball mã nguồn, chứ không có trong kho GitHub của xz, nhằm né tránh việc bị phát hiện
  • Cửa hậu được cấu thành qua nhiều commit
    • Trong quá trình build, nó dùng IFUNC để cho phép mã độc chặn hàm phân giải symbol
    • Giấu shared object đã bị làm rối trong các tệp kiểm thử
    • Chạy script trích xuất shared object trong quá trình build thư viện
    • Vô hiệu hóa landlocking, tính năng bảo mật dùng để hạn chế quyền của tiến trình
  • Chuỗi thực thi diễn ra qua nhiều bước
    • build-to-host.m4 được thực thi khi build thư viện và giải mã bad-3-corrupt_lzma2.xz thành một script bash
    • Script bash này tiếp tục giải mã good-large_compressed.lzma theo cách phức tạp hơn để tạo ra một script khác
    • Script đó trích xuất shared object liblzma_la-crc64-fast.o và thêm nó vào quá trình biên dịch liblzma
  • Shared object này được biên dịch vào liblzma và thay thế quy trình phân giải tên hàm thông thường
  • Thư viện độc hại có thể thay con trỏ hàm RSA_public_decrypt của OpenSSH bằng hàm độc hại do nó tạo ra
  • Theo phân tích của Filippo Valsorda, hàm độc hại này trích xuất lệnh từ chứng chỉ của client xác thực, xác nhận đó là tác nhân đe dọa, rồi chuyển cho system() để đạt được thực thi mã từ xa trước khi xác thực

Jia Tan và những câu hỏi còn lại

  • Có rất ít thông tin được biết về Jia Tan
  • Nhân vật nhà phát triển này cũng đã tham gia hàng chục phần mềm mã nguồn mở khác trong vài năm qua
  • Chưa rõ đằng sau tên người dùng Jia Tan có phải là một con người thật hay là một nhân vật hoàn toàn được dựng lên
  • Có thể xem thêm phân tích kỹ thuật trong thread Bluesky của Filippo Valsorda, bài phân tích của Kevin Beaumont và tài liệu công bố hôm thứ Sáu của Freund

CVE và công cụ xác minh

  • Mã định danh theo dõi của lỗ hổng này là CVE-2024-3094
  • Trang xz.fail của Binarly phát hiện triển khai IFUNC và dựa trên phân tích hành vi
    • Nó có thể tự động phát hiện các điều kiện bất biến ngay cả khi một cửa hậu tương tự được cài ở nơi khác
  • xzbot cung cấp các tính năng phục vụ phân tích và thử nghiệm
    • honeypot: máy chủ giả dễ bị tấn công để phát hiện nỗ lực khai thác
    • ed448 patch: vá liblzma.so để dùng khóa công khai ED448 của riêng bạn
    • backdoor format: định dạng payload của cửa hậu
    • backdoor demo: CLI kích hoạt RCE với giả định biết khóa riêng ED448

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-02
Các ý kiến trên Hacker News

  • Mục tiêu là dùng một framework kiểm thử đã được chuẩn hóa để giúp việc viết test cho XZ dễ dàng hơn
    Vì vẫn còn nhiều tính năng chưa được kiểm thử, Jia từng viết vào ngày 2022-06-17 rằng việc này sẽ giúp tăng số lượng test để bảo đảm tính ổn định lâu dài của dự án
    Nói cách khác, đây là một thay đổi đã được chuẩn bị từ lâu

  • Có vẻ cơ chế liên kết cho phép lib chen vào RSA_public_decrypt chưa được bàn luận nhiều
    Có nhiều trao đổi về chuyện tách tiến trình, nhưng ít người nói về việc chuyển hướng lời gọi hàm đó
    Tôi nghĩ có thể liên kết các thành phần cốt lõi, như mã xử lý kết nối SSH đi vào, với thư viện theo một mô hình tin cậy phân tầng, kiểu như “tôi tin ở vị trí tôi gọi, nhưng không cho phép nó tự chen vào ở các điểm gọi khác”
    Điều này có thể kích hoạt phản xạ kiểu “bảo mật bằng che giấu” rằng vì có cách обход nên vô nghĩa, nhưng dù sao vẫn có thể xem là giảm bề mặt tấn công

    • Một mô hình giống actor của Erlang, trong đó các thành phần con của chương trình mỗi bên có ngữ cảnh bảo mật riêng và gọi nhau bằng truyền thông điệp, cũng có thể hoạt động
      Tuy nhiên trong hệ điều hành có nhiều ngữ cảnh bảo mật chồng lấn nhau. Liên quan đến backdoor XZ thì chủ yếu là bảo mật dựa trên capability ở cấp module, nhưng còn có capability cấp chương trình, cách ly cấp bộ nhớ (paging), cách ly cấp vi kiến trúc, v.v.
      Làm cho các yếu tố này hoạt động cùng nhau mà vẫn đạt hiệu năng là khá khó, và việc các hệ Unix chuyển sang mô hình như vậy gần như bất khả thi vì phải thay thế chính khái niệm tiến trình
    • Theo tôi, vấn đề là việc glibc dùng IFUNC
      Nó đã làm hỏng các test của XZ, rồi đột nhiên xuất hiện những tài khoản vận động để vô hiệu hóa các test đó, và kết quả là exploit trở nên khả thi
    • Về bản chất, mã này bí mật sửa một file C tại thời điểm build (khi chạy ./configure && make) để vá ifunc resolver, khiến nó gọi một object độc hại được cung cấp
      Object file bị can thiệp được liên kết cùng cờ linker now, nên ifunc được phân giải ngay khi thư viện được nạp; lúc đó bảng liên kết của tiến trình vẫn còn có thể ghi được, nên resolver đã bị vá được gọi
      Đây chính là điểm quan trọng: khi thư viện được nạp, nó có thể đơn giản chiếm quyền hàm RSA_public_decrypt trong bộ nhớ
      Bài phân tích rất kỹ về quá trình chèn backdoor: https://research.swtch.com/xz-script
    • systemd gần đây đã merge thay đổi dùng dlopen cho các thư viện nén: https://github.com/systemd/systemd/pull/31550
      Theo nghĩa đó thì đây là cách liên kết an toàn hơn
    • Tôi tự hỏi liệu cách giám sát các symbol mà ltrace gọi có đủ hay không

  • Tôi không hiểu tại sao lại nói là “suýt” lây nhiễm cả thế giới
    Ít nhất 3 bản phân phối Linux khá phổ biến, Arch, Gentoo, openSUSE Tumbleweed, đã phân phối backdoor trong vài tuần, và trên Tumbleweed thì chắc chắn nó đang hoạt động
    SSH có backdoor suốt vài tuần như vậy thì nói “suýt” nghe hơi nhẹ

    • Trên các bản phân phối đó, exploit thực tế không được thực thi
      Nó chỉ hoạt động với mục tiêu deb/rpm, nên về thực chất đã bị chặn trước khi chạm tới production
    • Arch và Gentoo khá phổ biến trong nhóm distro dùng như sở thích, nhưng ít gặp hơn nhiều trong môi trường vận hành chuyên nghiệp kiểu các máy chủ SSH mà cuộc tấn công này nhắm tới
      Nói vậy không có nghĩa là ổn; nếu nó không bị phát hiện đủ lâu để lọt vào RHEL hoặc Debian/Ubuntu stable, thì có lẽ chúng ta đã nhận được cảnh báo từ những nơi như ngân hàng hay cơ sở y tế
      Với thực thi mã từ xa trước xác thực, trừ khi có giới hạn mạng rất chặt và ghi log luồng tốt, sẽ khó nói rằng mình “không bị ảnh hưởng”
    • Có vẻ nó thực ra không được đưa vào gói binary của Arch, vì chính hệ thống build backdoor đã không cài backdoor cho Arch
      So sánh liblzma.so.5.6.1 của xz-5.6.1-1 và xz-5.6.1-2 bằng cmp -l chỉ thấy khác biệt rất nhỏ
      Có vẻ người ta chưa biết điều này trước khi viết khuyến cáo
      https://github.com/QubesOS/qubes-issues/issues/9067#issuecom...
    • Tôi nghĩ phần lớn máy Linux chạy sshd sẽ dùng bản phân phối LTS chứ không phải rolling release
      Tuy nhiên tôi không biết làm sao có dữ liệu để chứng minh điều này
    • Tôi hy vọng các maintainer mã nguồn mở và các tập đoàn lớn nhận được thông điệp này. Cần thay đổi triển vọng tài chính của việc bảo trì mã nguồn mở

  • Tôi cược 101 đô la rằng trong 12 tháng tới sẽ có thứ gì đó tương tự được phát hiện trong môi trường thực tế
    Vì các maintainer sẽ bắt đầu nghi ngờ và rà soát các commit cũ của nhau

    • Tôi cho rằng các cuộc tấn công kiểu này đã tăng lên trong 10 năm qua
      Chỉ cần nhìn vào các codebase quan trọng nhưng ít được biết đến và có rất ít maintainer
    • Tôi tự hỏi liệu có thể tìm ra các trường hợp đã được thực thi và sử dụng rồi hay không
      Nếu tôi có một thứ như vậy và nó hoạt động tốt, có lẽ sau này tôi sẽ dùng một tài khoản khác để “phát hiện” và khiến nó được sửa

  • Kết luận cá nhân rút ra từ vụ này có nhiều điểm
    Thứ nhất, tarball phân phối mã nguồn chứa mã khác với kho mã nguồn là không tốt và nên tránh xa. Một cuộc tấn công chuỗi cung ứng lớn khác là event-stream cũng đã lợi dụng điểm tương tự
    Hệ quả là các sản phẩm được tạo tự động phải luôn được commit
    Thứ hai, các sản phẩm được tạo tự động mà ai cũng bấm Page Down bỏ qua khi review mã là một vấn đề. Nếu những tệp như vậy có trong kho, cũng cần có test tự động để kiểm tra xem có ai thao túng chúng hay không, đồng thời giúp không bỏ mặc các tệp tạo tự động đã lỗi thời
    Thứ ba, như hệ quả của 1 và 2, autotools là tệ và văn hóa autotools cũng tệ
    Thứ tư, Libsystemd là một vấn đề đối với hệ sinh thái. Nói điều này thì sẽ bị quy là kẻ ghét systemd, nhưng nó lớn, phức tạp, có nhiều phụ thuộc, trong khi hầu hết chương trình chỉ dùng một phần rất nhỏ. Khuyến khích mọi service phụ thuộc vào nó chỉ để thông báo khởi tạo là chuyện điên rồ
    Thứ năm, có một văn hóa cho rằng tái sử dụng mã luôn tốt và phụ thuộc vào một thư viện lớn vì một tính năng nhỏ cũng ổn, nhưng điều đó không đúng. Phụ thuộc là gánh nặng bảo trì và rủi ro bảo mật, cần phải cân nhắc với chức năng mà nó mang lại
    Thứ sáu, việc maintainer của bản phân phối áp các bản vá lớn vào package cũng là vấn đề. Nó tạo ra các fork thực tế được dùng rộng rãi của thư viện và ứng dụng mà maintainer thật sự không xem xét
    Thứ bảy, từ góc nhìn developer, OSS phải trở nên bền vững về tài chính. Liblzma và xz-utils hẳn có hàng chục triệu lượt cài đặt, nhưng lại dựa vào một maintainer duy nhất đang gặp vấn đề sức khỏe tâm thần
    Thứ tám, dù không muốn nói, nhưng hiện nay khi review mã và chuyển giao quyền bảo trì cũng phải tính đến yếu tố địa chính trị

    • Cân nhắc địa chính trị không giúp ích gì
      Không có bằng chứng Jia Tan là tên thật, thậm chí cũng không có bằng chứng đó là một người thật
      Nếu các dự án bắt đầu không nhận đóng góp từ những cái tên nghe giống người châu Á, thì cuộc tấn công tiếp theo chỉ cần dùng tên Richard Jones là xong
    • Về Libsystemd thì hoàn toàn đồng ý
      Nếu đến từ thế giới BSD, systemd thật gây sốc, giống quái vật và vươn vòi khắp nơi
    • Tôi còn có thêm một quan sát cá nhân
      Người tiêu dùng ngây thơ, nhưng bản thân ngành phần mềm cũng ngây thơ trước các mối đe dọa bảo mật
      Khai thác xã hội là một phần của khai thác mã
      Nguyên tắc của FOSS rằng “càng nhiều con mắt xem mã càng tốt” là đúng, nhưng chỉ hoạt động khi những con mắt đó đã được đào tạo. FOSS cần sự hỗ trợ vật chất từ ngành
      Một kỹ sư MSFT đã bắt được exploit này, nhưng nó vẫn đã lọt vào các bản phát hành công khai thông thường của Fedora 41, openSUSE, Kali
      Chuỗi công cụ phát triển và quy trình test chưa từng được thiết kế để kiểm thử bảo mật. SolarWinds cũng là một ví dụ đáng tham khảo: https://www.wired.com/story/the-untold-story-of-solarwinds-t...
    • Nói rằng nên ngừng phân phối tarball là hoàn toàn bỏ qua lý do vì sao tồn tại artifact phát hành
      Artifact phát hành không chỉ chứa script autoconf
      Có nhiều lý do để đưa binary blob vào archive phát hành. Chẳng hạn tài nguyên game, image firmware, test case. Từng có chuyện mpv đưa vào một số tệp media do encoder độc quyền tạo ra làm test case, và đó không phải chuyện xấu mà là chuyện tốt
      sqlite được bảo trì tốt, được dùng ở khắp nơi và có bộ test tuyệt vời. Mỗi bản phát hành không chỉ phát hành một tarball mà là hai tarball theo từng giai đoạn biên dịch. Dừng việc này thì dễ, nhưng chỉ làm tăng việc cho maintainer package và không giúp cải thiện bảo mật
      Lý do Debian build từ tarball đã được tuyển chọn là vì nó được con người tuyển chọn và ký bằng khóa nổi tiếng. Tất nhiên cũng có thể build từ git, nhưng không chắc điều đó có cải thiện tình hình không. Không phải dự án nào cũng ký release tag, và kể cả có ký thì nhiều khả năng việc đó được tự động hóa
      Chúng ta muốn thay đổi được upstream maintainer review trước, rồi đến maintainer package review, và muốn hai bên này độc lập với nhau
      Lần này một upstream maintainer bị tha hóa đã tấn công quy trình đó, nhưng điều đó không có nghĩa là nên loại bỏ upstream maintainer. Trong vài năm qua cấu trúc này đã chặn nhiều nỗ lực cài backdoor, và đây không phải quy trình nên vứt bỏ nếu chưa xem xét thận trọng
      Hướng cải thiện vẫn là điều vẫn được nói từ trước đến nay. Phải theo đuổi build có thể tái lập hơn nữa, nếu có thể thì giảm bề mặt tấn công và độ phức tạp của build, tin tưởng maintainer nhưng phải xác minh công việc
    • Các maintainer systemd chưa từng khuyến khích mọi service phụ thuộc vào libsystemd
      Trái lại, họ còn tỏ ra bối rối ở điểm đó và đang bổ sung tài liệu về cách triển khai datagram đơn giản mà không cần libsystemd
      Số lượt cài đặt liblzma và xz-utils có lẽ còn nhiều hơn hàng chục triệu rất nhiều. Nhiều ngôn ngữ như Python, PHP, Ruby phụ thuộc vào libxml2, và libxml2 dùng liblzma. Còn nhiều phụ thuộc khác nữa
      Cân nhắc địa chính trị không phải việc của maintainer. OSS được cung cấp không kèm bảo đảm
      Hơn nữa, “Jia Tan” có khả năng là hoàn toàn giả. Nhìn vào timestamp commit, ngay trong cùng một ngày múi giờ cũng đổi từ Đông Âu sang châu Á. Ít nhất chắc chắn là đã có trò chơi danh tính

  • Tôi không biết người phát hiện vấn đề này là một kỹ sư Microsoft làm ở Azure Postgres
    Cảm ơn Microsoft, giờ thì tôi thấy Azure đáng mến hơn rồi

    • Giờ tôi nghĩ mọi người phải xem xét tất cả dấu hiệu bất thường của Valgrind
      Vì vấn đề này đã được phát hiện theo cách đó
      Sau đó cần nhìn vào thư viện có vấn đề và tìm các outlier tương tự, nơi một persona giả chiếm quyền kiểm soát dự án
      Có vẻ như việc bỏ qua những lỗi kiểu này là thông lệ phổ biến
    • Đó là một kỹ sư PostgreSQL PGDG do Microsoft tuyển dụng
      Tôi thật sự không chịu nổi kiểu đóng khung như vậy

  • Có vẻ như maintainer ban đầu của xz đã chuyển giao trách nhiệm cho Jia Tan mà không gặp trực tiếp, hoặc ít nhất là không gọi điện với người này
    Tôi tự hỏi liệu việc chỉ giao tiếp qua email hoặc GitHub có phổ biến không
    Sau vụ này, có lẽ một số maintainer dự án mã nguồn mở sẽ cẩn trọng hơn

    • Việc chỉ giao tiếp qua email/GitHub là hoàn toàn phổ biến
      Chính tôi cũng từng giao tiếp chỉ bằng văn bản, không hề biết người thật là ai, rồi nhận bàn giao hoặc chuyển giao việc duy trì thư viện
      Nhưng tôi cho rằng kết luận “maintainer phải cẩn thận hơn” trong vụ này là hoàn toàn sai
      Trách nhiệm về những gì người ta đưa vào dự án của mình không thuộc về maintainer, mà thuộc về những người làm việc trong dự án đó
      Hoặc là tin maintainer, hoặc là không tin; và ngay khi bắt đầu phụ thuộc vào một thư viện, về cơ bản bạn đã ngầm đồng ý rằng mình sẽ liên tục cập nhật xem mình đang tin ai
    • Cấu trúc hiện tại thực tế là như vậy
      Hàng triệu công ty đang đi nhờ miễn phí trên công sức của các lập trình viên mã nguồn mở không được trả lương
      Vì vậy không có gì đáng ngạc nhiên khi họ rời đi và vấn đề phát sinh
    • Tôi không nghĩ một cuộc gọi điện thoại thì tạo ra khác biệt gì
      Nó sẽ bổ sung thêm niềm tin nào về ý định của người đó chứ?
    • Đúng là chỉ giao tiếp qua email/GitHub
      Tôi đã tham gia khoảng sáu dự án mã nguồn mở với quy mô khác nhau, từ 100 đến 30.000 sao GitHub, nhưng chưa từng gọi điện với ai; giao tiếp dựa trên văn bản là tiêu chuẩn
    • Khi nhiều người thúc ép về tốc độ làm việc, cũng không lạ nếu maintainer cảm thấy chính mình là vấn đề và chuyển giao dự án cho người mà lúc đó họ nghĩ là lựa chọn tốt nhất
      Nhưng biết cá nhân nhau cũng không nhất thiết giải quyết được vấn đề
      Từ lâu tôi từng làm việc ẩn danh trong một dự án mã nguồn mở, và không muốn nêu tên ở đây. Lập trình viên trưởng có một co-maintainer mà có vẻ như ông ấy biết khá rõ
      Co-maintainer đó liên tục gaslight, hạ thấp và đổ lỗi cho tôi cùng các maintainer sau này vì những lỗi rất nhỏ, khiến chúng tôi rời đi. Nếu bỏ phần xúc phạm ra, nó cũng không giống kiểu quát mắng mang tính giáo dục của Linus Torvalds
      Maintainer trưởng đồng tình với cốt lõi kỹ thuật trong các lập luận đó nên đã tiếp tay cho anh ta
      Vài năm sau, co-maintainer đó cố gắng thâu tóm dự án theo cách thù địch, và mọi chuyện không diễn ra như dự tính. Không lâu sau, nhiều thư từ riêng tư bị công khai, cho thấy anh ta luôn muốn điều đó và việc gaslight các maintainer khác cũng là một phần của mục tiêu ấy
      Chuyện này vẫn xảy ra dù hai người đó biết nhau

  • Mọi người đều nghĩ backdoor này đã bị phát hiện sớm, nhưng có thể nó đã đạt được mục đích rồi
    Đặc biệt nếu mục tiêu là các lập trình viên dùng bản phân phối rolling release như Kali hoặc Debian

  • Meme kiểu “Lasse Collin đã không cập nhật xz Utils đủ thường xuyên hoặc đủ nhanh” là một sai lầm

  • Tôi không hiểu vì sao SSH lại dùng xz
    Có cần phải vậy không? Nó thật sự quan trọng đến thế à?

    • OpenSSH không dùng xz
      OpenSSH kéo libsystemd vào để cung cấp thông báo khởi động, còn libsystemd kéo liblzma vào. Thông thường mã của liblzma không đi vào OpenSSH
      Nhưng vì nó được build như một dependency của libsystemd, script build được chạy trong cùng môi trường với libsystemd và OpenSSH
      Payload tấn công được giấu trong thư mục test của liblzma dưới dạng một blob nhị phân bị làm rối, ngụy trang như một test case nén
      Khi biên dịch lzma từ source git và tạo script build bằng autotools thì không có gì đáng ngờ. Nhưng trong source tarball mà các packager của bản phân phối dùng, autotools đã được chạy sẵn, và kẻ tấn công đã tráo đổi đầu ra script được tự động sinh ra, vốn khó đọc
      Script đó kiểm tra xem liblzma có được biên dịch trong cùng môi trường với OpenSSH hay không, và có được biên dịch để đưa vào gói .deb hoặc .rpm hay không; nếu cả hai đều đúng, nó cấy payload tấn công vào OpenSSH
      Sau đó payload thực hiện nhiều kiểm tra, chẳng hạn OpenSSH có được khởi động bình thường bằng init script hay được chạy thủ công, có các công cụ debug phổ biến hay không; nó chỉ bám vào tiến trình đang chạy khi trông giống một lần boot “tự nhiên” và không có công cụ debug
      Khi chạy, nó hook vào bước xác minh khóa riêng; nếu khóa riêng đúng cố gắng đăng nhập, nó gọi phần còn lại của gói tin đi vào bằng system, cung cấp khả năng thực thi mã từ xa với quyền root
    • OpenSSH không dùng xz, nhưng trong một số bản phân phối, xz được dùng khi tích hợp với systemd