Có lẽ tạm thời bạn không nên cài phần mềm mới
(xeiaso.net)- Sau copy.fail, đã có thêm lỗ hổng nhân Linux được công bố
- Hiện tại được đánh giá là thời điểm tấn công chuỗi cung ứng NPM dễ gây thiệt hại lớn
- Có khuyến nghị ngoại lệ với các bản vá nhân Linux do bản phân phối cung cấp
- Ngoài ra, tốt hơn hết là tạm ngừng cài phần mềm mới khoảng một tuần
- Có lưu ý rằng sau khi bài được đăng, tình hình hoặc các dữ kiện thực tế có thể đã thay đổi, nên nếu có điểm nào sai hoặc chưa rõ thì hãy liên hệ trước khi đưa ra kết luận
1 bình luận
Ý kiến trên Hacker News
Đây vốn là cơn ác mộng sớm muộn gì cũng bùng nổ. Số lượng package quá nhiều, và cùng với đó là bề mặt tấn công chuỗi cung ứng đã phình ra đến mức sớm muộn gì cũng sẽ đổ ập lên tất cả mọi người
Nhưng nó quá tiện lợi. Những người cố cảnh báo hoặc giảm thiểu rủi ro thường bị phớt lờ bởi những người chưa từng làm theo cách nào khác, và
"import antigravity"thì quá dễ để từ bỏCó vẻ như giờ chúng ta đã bước vào giai đoạn “trả giá”
Gần như mọi thứ, bao gồm compiler, kernel, v.v., đều được build từ source; server/infrastructure build hoàn toàn không có truy cập Internet, và có quy trình riêng để đưa thay đổi vào. Các CVE liên quan đều được rà soát khi công bố để xác định có ảnh hưởng đến chúng tôi hay không, và sẽ giảm thiểu hay xử lý ra sao
Sau đó tôi chuyển sang một công ty khác, nơi build có truy cập Internet và nâng cấp ngay khi có phiên bản mới. Mọi người xem đó là thực tiễn tốt vì sẽ nhận được bản sửa lỗi mới nhất, còn việc rà soát CVE do đội bảo mật phụ trách
Rồi đến startup tiếp theo thì có sự pha trộn của nhiều cách làm. Có những phần rất tốt, nhưng cũng có nợ CVE lớn. Ví dụ, họ triển khai secure boot và ổ đĩa mã hóa trên server, đồng thời cũng nắm khá tốt bảo mật liên lạc giữa các thành phần
Ai cũng nghĩ mình đang làm đúng. Gần như không thể thuyết phục những người “nâng cấp thường xuyên” rằng họ đang có nguy cơ đưa vấn đề mới vào. Ngành này cần một bộ thực hành tốt hơn, và cá nhân tôi cho rằng cách quản lý dependency của công ty đầu tiên tốt hơn. Nhìn tổng thể, các thực hành bảo mật ở đó rất vững, và sản phẩm cũng thực sự an toàn
Khi đó mọi phần mềm hữu ích đều đã trải qua fuzzing, property testing và formal verification, khiến tất cả những ai đi tìm lỗ hổng đều phải quay lại vạch xuất phát
Tất nhiên điều đó giả định là trong khoảng trống trước mắt, chúng ta chịu đựng được giai đoạn các quốc gia ném những gì còn lại vào kẻ thù tồi tệ nhất của họ. Nếu không thì cuối cùng có lẽ chúng ta sẽ lại lấy xương động vật đập nhau
Ở cấp hệ điều hành, chương trình khi chạy sẽ được shell hoặc nơi gọi nó truyền các token quyền, và mọi system call đều phải nhận capability làm đối số đầu tiên. Vì vậy
"open path /foo"sẽ thànhopen(cap, "/foo"). Capability này có thể là filesystem giả, một nhánh của filesystem thật, filesystem mạng, hay bất cứ gì khác; chương trình không cần biết nó đang sống trong sandbox nàoỞ cấp thư viện/ngôn ngữ cũng vậy: khi import thư viện bên thứ ba như module npm, bạn phải truyền capability ở thời điểm import hoặc tại vị trí gọi. Thư viện đó không nên có quyền đọc/ghi mọi byte trong không gian địa chỉ của chương trình tôi, cũng không nên có thể làm mọi thứ trên máy tôi như thể nó là tôi. Câu hỏi cốt lõi là “bán kính nổ của đoạn code này là bao nhiêu?”. Khi thư viện bạn dùng là mã độc hoặc có lỗ hổng, ta cần các mặc định hợp lý về mức độ thiệt hại. Một lệnh gọi
lib::add(1, 2)không nên dẫn tới việc máy tính của tôi bị xâm nhập lâu dài trên diện rộngSeL4 từ lâu đã cung cấp capability ở cấp hệ điều hành rất nhanh và hiệu quả, và nó hoạt động tốt. Trong nhiều trường hợp còn nhanh hơn Linux, và cực kỳ hữu ích cho sandbox minh bạch, driver không gian người dùng, giao tiếp liên tiến trình, cải thiện bảo mật, v.v. Thậm chí có thể chạy Linux như một tiến trình trên SeL4. Tôi muốn có một hệ điều hành vừa có đầy đủ tính năng của desktop Linux vừa hoạt động như SeL4
Đáng tiếc là có vẻ chưa có ngôn ngữ lập trình nào có capability ở cấp ngôn ngữ đúng theo kiểu tôi muốn. Rust khá gần, nhưng cần cách để hạn chế crate bên thứ ba không được gọi bất kỳ đoạn unsafe code nào, kể cả unsafe do dependency không đáng tin cậy gọi đến. Cũng cần sửa các bug soundness tồn tại lâu nay của Rust, và cần cả standard library dựa trên capability. Những thứ như
open()/listen()toàn cục nên biến mất, chỉ nên cònopenat()và các dạng tương đương tương ứng với những phần khác của hệ điều hànhNếu LLM tiếp tục tiến bộ, trong vài năm nữa nếu không ai làm trước, tôi sẽ bảo LLM xây dựng toàn bộ thứ này. Bảo mật của các hệ điều hành desktop hiện đại đúng là trò cười
Code cũng cần một văn hóa vệ sinh, và điều đó thực ra không khác mấy những chuẩn mực mà phần lớn nền văn hóa đã phát triển quanh đồ ăn. Đó là sự kết hợp của nhiều heuristic thô ráp, nhưng cái cảm giác “ghê quá” đã cứu sống hàng tỷ người
Giờ đây tôi đang giảm mức độ phơi nhiễm dependency hơn bao giờ hết, đặc biệt với những thứ có thể tự triển khai chỉ trong vài trăm dòng. Đây đúng là một chuyển dịch mô hình
Cách “đợi một tuần rồi mới cài phần mềm” là không hiệu quả. Mới vài tháng trước thôi đã có một lỗ hổng quy mô lớn quét qua web, đó là một cuộc tấn công trì hoãn thời gian: nó nằm im hơn một tháng rồi mới kích hoạt
Nếu ai cũng bắt đầu đợi một tuần, kẻ tấn công sẽ đợi hai tuần. Tội phạm mạng không cần khai thác ngay lập tức; chỉ cần khai thác được vào một lúc nào đó là đủ. Nhiều kiểu lỗ hổng như typosquatting cũng chẳng thay đổi vì cách này
Vì rất có thể vẫn chưa có bản vá cho các lỗ hổng này, và kể cả có thì khả năng cao là sẽ sớm phát hiện thêm những lỗ hổng đáng sợ hơn
Nhưng nếu không có độ trễ nào, bạn có thể dính một exploit mà chưa ai kịp nhìn thấy
Hơn nữa, việc phát hiện các vụ xâm phạm kiểu này hoàn toàn không phụ thuộc vào chuyện chúng có bị khai thác thực tế hay không. Vì vậy tôi không hiểu câu “nếu ai cũng đợi một tuần thì kẻ tấn công sẽ đợi hai tuần”
Một lựa chọn khác là chuyển sang hệ điều hành như FreeBSD, nơi không tiếp cận bảo mật theo kiểu YOLO
Các bản sửa bảo mật không bị quăng thẳng vào kernel FreeBSD mà không có điều phối. Chúng đi qua đội bảo mật FreeBSD, và chỉ vài phút sau khi patch vào cây src, các bản cập nhật nhị phân được phát hành qua FreeBSD Update và pkgbase cho 15.0-RELEASE
Đại khái chỉ mất vài giây để có tin nhắn trên Slack kiểu “đã push patch”, 10–30 giây để upload patch, và tối đa khoảng 1 phút để mirror đồng bộ
Công bằng mà nói, báo cáo của tôi liên quan đến thứ không phải thành phần cốt lõi và cũng không dễ khai thác, nhưng Debian, OpenBSD, SUSE và Gentoo đều vá trong vòng một tuần https://www.maxchernoff.ca/p/luatex-vulnerabilities#timeline
Dù vậy, tôi không muốn đánh giá cả hệ điều hành chỉ từ cách xử lý một báo cáo lẻ và tương đối nhỏ. Bởi những gì khác tôi thấy đều nghiêng về việc FreeBSD khá nghiêm túc với các báo cáo bảo mật. Nhưng cùng logic đó cũng có thể áp dụng cho bug kernel Linux. Những vụ quản lý patch tệ như vậy cũng khá hiếm trên Linux
Nó có xu hướng ưu tiên tính dễ dùng hơn bảo mật. Một ví dụ nổi tiếng ở đây: https://vez.mrsk.me/freebsd-defaults
Tôi trân trọng việc đóng góp cho dự án, nhưng chừng nào còn những mặc định tệ như thế thì tôi không thể có lương tâm mà khuyên người khác chuyển sang
Nếu muốn FreeBSD và bảo mật, tốt hơn nên dùng HardenedBSD của Shawn Webb
Ngay cả các chuyên gia bảo mật giờ cũng phải chấp nhận rằng thế giới của chúng ta đang đứng trên một trạng thái cân bằng cực kỳ mong manh. Tôi nghĩ mọi người thực sự đang đánh giá thấp điều này
Không chỉ thế giới IT, mà cả toàn bộ thế giới cũng được xây trên vô số trạng thái cân bằng rất mong manh. Exploit bảo mật sẽ luôn tồn tại. Không chỉ trong phần mềm mà cả ngoài đời thật cũng vậy. Có người thậm chí còn lẻn được vào hội nghị bảo mật, mà còn chỉ là một YouTuber. Dĩ nhiên đó không phải sự kiện siêu an ninh, nhưng đó là ví dụ tôi nghĩ ra ngay lúc này. Về cơ bản, trong phần lớn trường hợp, việc vượt qua bảo mật thật sự rất dễ
Điều tôi muốn nói là, về bản chất, thế giới của chúng ta vận hành được ít nhất là vì phần lớn mọi người không đi khai thác các điểm đó. Xã hội loài người từ trước đến nay vẫn luôn hoạt động như vậy, và có lẽ sau này cũng thế
Tôi nhớ là YouTuber Max Fosh đã liên tiếp vào được International Security Expo. Ở Anh là https://www.youtube.com/watch?v=qM3imMiERdU, ở Mỹ là https://www.youtube.com/watch?v=NmgLwxK8TvA, dùng các bí danh lần lượt là “Rob Banks” và “Nick Everything”
Tôi từng học về văn hóa bảo mật, và phần lớn cuối cùng đều quy về một thang trượt với bảo mật ở một đầu và tiện lợi/khả năng tiếp cận ở đầu kia. Càng an toàn thì càng kém dễ tiếp cận, và ngược lại cũng thế
Các cuộc tấn công chuỗi cung ứng nhắm vào trình quản lý dependency như npm, PyPI, Cargo thực ra đã có một giải pháp khá ổn. Đó là cấu hình để chỉ cài các phiên bản package đã tồn tại quá vài ngày
Tất cả các cuộc tấn công lớn gần đây đều bị phát hiện và rollback trong vòng một ngày, nên nếu làm vậy thì đã tránh được an toàn. Hành vi này nên là mặc định. Hãy để những beta tester tự nguyện và các công ty quét bảo mật dùng thử phiên bản package mới nhất trước một ngày. Cách làm ở đây: https://cooldowns.dev/
Đây là trình quản lý artifact. Nó cho phép chỉ lấy những gì bạn đã phê duyệt. Khi cần thì có thể cập nhật nhanh, còn lúc khác thì dùng các phiên bản ổn định đã được xác minh nhất quán. Cần override cấu hình một chút nhưng đó là việc dễ
Tôi từng tự làm một công cụ hơi chắp vá cho mục đích tương tự, và đây là một dự án tốt
Tất nhiên ngoài môi trường doanh nghiệp thì điều này tự nhiên là khó áp dụng
Một khi đã bị phát hiện, exploit sẽ bùng nổ ngay, và cập nhật chậm chỉ cho những kẻ tấn công đang hưng phấn thêm thời gian
Một mô hình khác là CPAN của Perl, nơi chỉ phân phối source file
Những ai tương đối gần đây mới áp dụng continuous integration và build trong container nên kiểm tra hệ thống xem có đang kéo
latesttừ nhiều package trong mỗi lần build hay khôngChúng tôi tạo sẵn một container cơ sở chứa toàn bộ dependency bên ngoài, và chỉ làm mới nó một cách tường minh khi thấy đã đến lúc cập nhật
Như vậy có thể chậm hơn một chút so với mũi nhọn công nghệ, nhưng cũng đỡ phải gánh rủi ro để lỗ hổng chuỗi cung ứng ngẫu nhiên lập tức được triển khai ra toàn cầu
Đây là một bài ý kiến có hại một cách tích cực. Khó mà hiểu được logic của nó
Chỉ mất 45 giây để kiểm tra copyfail và dirtyfrag thực sự đã tồn tại bao lâu. Thậm chí còn lâu hơn thời gian đọc bài. Dirtyfrag có thể liên quan đến cả các hệ thống từ tận năm 2017
Thứ bị ảnh hưởng không phải phần mềm “mới”. Và phần mềm thực sự cũ thì còn tệ hơn nhiều vì đã có nhiều thời gian hơn để tìm ra vấn đề
Một ngày nào đó sẽ có ai đó xây dựng lại toàn bộ stack từ hệ điều hành đến ứng dụng bằng các bản nâng cấp proof-carrying code
Cách duy nhất để chạy code đáng tin là đồng thiết kế và đồng xây dựng proof cùng với code
Điều này không chỉ áp dụng cho phần mềm, mà thực ra gần như áp dụng cho mọi thứ
Tôi không nhớ đọc ở đâu, nhưng cuối cùng nó quy về khác biệt giữa nhu cầu và ham muốn
Tôi đã dùng quy tắc này khi quyết định mua xe mới hay xe cũ, mua máy hút bụi cao cấp hay loại cơ bản. Điều đó cũng đúng với những thiết bị mới bóng bẩy, việc đưa một thứ mới vào tech stack, hay chọn một tech stack mới
Tôi muốn được giúp hiểu copyfail là gì và nó liên hệ với package NPM ra sao
Tóm lại thì có vẻ copyfail là một bug kernel cho phép package npm độc hại giành quyền root trên server Linux
Vì vậy thời điểm hiện tại, khi vẫn còn các server chưa được vá, là lúc hoàn hảo để kẻ tấn công nhắm vào package NPM
Có phải lý do lời khuyên không đơn giản là “hãy cập nhật kernel” là vì những vấn đề mới liên quan vẫn đang tiếp tục được phát hiện?
Nếu một package NPM phổ biến bị xâm phạm và chứa exploit copy.fail, rất nhiều hệ thống sẽ dễ bị leo thang đặc quyền lên root