Max Kellermann, một nhà nghiên cứu bảo mật và lập trình viên cho các nhà sáng tạo phần mềm quản lý nội dung người Đức CM4all, vừa xuất bản một báo cáo hấp dẫn về một lỗi hạt nhân Linux đã được vá gần đây.

Anh ấy gọi là lỗ hổng Đường ống bẩn, bởi vì nó liên quan đến sự tương tác không an toàn giữa một Linux thực sự hồ sơ (một cái được lưu vĩnh viễn trên đĩa) và một cái Linux đường ống, là bộ đệm dữ liệu chỉ dành cho bộ nhớ có thể được sử dụng như một tệp.

Rất đơn giản hóa, nếu bạn có một đường dẫn mà bạn được phép ghi vào và một tệp mà bạn không…

… Sau đó, đôi khi, việc ghi vào bộ đệm bộ nhớ của đường ống cũng có thể vô tình sửa đổi các bản sao tạm thời trong bộ nhớ của hạt nhân - cái gọi là trang bộ nhớ cache - của các phần khác nhau của tệp đĩa.

Thật khó chịu, ngay cả khi tệp được chính hệ điều hành gắn cờ là "chỉ đọc", việc sửa đổi bộ đệm ẩn hạt nhân bên dưới của nó được coi là "ghi".

Kết quả là, bộ đệm cache đã sửa đổi sẽ được hạt nhân đẩy trở lại đĩa, cập nhật vĩnh viễn nội dung của tệp được lưu trữ, bất chấp bất kỳ quyền nào của hệ điều hành được áp dụng cho nó.

Ngay cả một tệp không thể ghi được về mặt vật lý, chẳng hạn như tệp trên CD-ROM hoặc thẻ SD bị tắt công tắc cho phép ghi, dường như đã được sửa đổi miễn là bộ đệm cache bị hỏng được nhân giữ trong bộ nhớ.

Những phiên bản nào bị ảnh hưởng?

Đối với những người đang chạy Linux muốn tiếp tục và kiểm tra xem chúng có được vá hay không, Kellermann báo cáo rằng lỗi này đã được đưa vào (ít nhất là ở dạng hiện tại, có thể khai thác dễ dàng) trong kernel 5.8.

Điều đó có nghĩa là ba hương vị hạt nhân được hỗ trợ chính thức chắc chắn có nguy cơ: 5.10, 5.15 và 5.16.

Lỗi đã được vá trong 5.10.102, 5.15.25 và 5.16.11, vì vậy nếu bạn có phiên bản bằng hoặc cao hơn một trong những phiên bản đó, thì bạn vẫn ổn.

Rõ ràng, Android cũng bị ảnh hưởng và mặc dù bản sửa lỗi cho lỗ hổng bảo mật đã được đưa vào mã nguồn hạt nhân vào ngày 2022-02-24, Bản tin Bảo mật Android của Google không dành cho tháng 2022, cũng không phải của công ty Ghi chú về pixel cụ thể, hãy đề cập đến lỗi này, hiện được đặt tên là CVE-2022-0847.

Tuy nhiên, trong số tất cả các thiết bị cầm tay Android được hỗ trợ chính thức mà chúng tôi đã khảo sát cho đến nay, chỉ có dòng Pixel 6 dường như sử dụng nhân 5.10, với hầu hết các thiết bị đều sử dụng một trong những Linux 5.4 hoặc 4 cũ hơn nhưng dường như không dễ bị tấn công. x phiên bản.

Tệp nhật ký thân thiện với người dùng

Thật thú vị, Kellermann đã phát hiện ra lỗ hổng do các tệp nhật ký HTTP bị hỏng liên tục trên mạng của công ty mình.

Anh ấy có một quy trình máy chủ thường xuyên lấy các tệp nhật ký hàng ngày, được nén bằng tiện ích gzip thân thiện với Unix và chuyển đổi chúng thành các tệp nhật ký hàng tháng ở định dạng ZIP thân thiện với Windows để khách hàng tải xuống.

Hỗ trợ tệp ZIP và thường sử dụng, nén gzip nội bộ, để tệp gzip thô thực sự có thể được sử dụng như các thành phần riêng lẻ bên trong tệp lưu trữ ZIP, miễn là dữ liệu điều khiển kiểu ZIP được thêm vào đầu và cuối tệp, và ở giữa mỗi đoạn được nén nội bộ.

Vì vậy, để tiết kiệm cả thời gian và sức mạnh CPU, Kellermann đã có thể tránh tạm thời giải nén tệp nhật ký hàng ngày cho mỗi khách hàng mà chỉ giải nén nó ngay lập tức thành tệp ZIP bao gồm tất cả.

Cuối cùng, anh ấy đã tạo ra một đường ống Linux có thể ghi được mà anh ấy có thể xuất ra kho lưu trữ ZIP tất cả trong một, và sau đó anh ấy sẽ đọc lần lượt từ từng tệp gzip, gửi từng tệp một vào đường dẫn đầu ra, nếu cần. đầu trang và đoạn giới thiệu được chèn vào đúng điểm.

Để tăng thêm hiệu quả, anh ấy đã sử dụng chức năng đặc biệt của Linux splice(), yêu cầu hạt nhân đọc dữ liệu từ một tệp và ghi nó vào một đường ống trực tiếp từ bộ nhớ hạt nhân, giúp tránh chi phí của một read()-và sau đó-write() Vòng lặp.

Đọc và viết bằng cách sử dụng truyền thống read() và write() các hàm có nghĩa là sao chép dữ liệu từ hạt nhân vào bộ đệm bộ nhớ do người dùng chỉ định, sau đó sao chép bộ đệm đó thẳng trở lại hạt nhân, vì vậy dữ liệu được sao chép xung quanh bộ nhớ ít nhất hai lần, mặc dù nó không được sửa đổi trong quá trình này. Để tránh chi phí này, splice() và chức năng đồng hành của nó sendfile() được đưa vào Linux để sử dụng khi các lập trình viên muốn di chuyển dữ liệu không bị thay đổi giữa hai đối tượng hệ thống tệp. Đối với các tệp lớn trên một máy chủ bận, điều này nhanh hơn và giảm tải.

Các byte bị hỏng, mỗi lần 8 byte

Tuy nhiên, thỉnh thoảng, Kellermann sẽ thấy rằng 8 byte cuối cùng của một trong những tệp gzip gốc sẽ bị hỏng, mặc dù anh ta chỉ đọc từ những tệp này.

Tất cả đầu ra của anh ấy sẽ đi vào “đường dẫn đầu ra” có thể ghi được dùng để tạo tệp ZIP kết hợp.

Không có thứ gì trong mã của anh ta thậm chí cố gắng ghi vào bất kỳ tệp đầu vào nào, tệp này được mở ở chế độ “chỉ đọc” và do đó lẽ ra phải được bảo vệ bởi hệ điều hành.

Một câu chuyện mà anh ấy đã phát hiện ra là 8 byte bị hỏng hầu như luôn xuất hiện trong tệp gzip cuối cùng của bất kỳ tháng nào và luôn 50 4B 01 02 1E 03 14 00 trong hệ thập lục phân.

Các nhà nghiên cứu về mối đe dọa sẽ nhận ra 50 4B 01 02 ngay lập tức, bởi vì 50 4B đi ra như PK bằng ký tự ASCII, viết tắt của Phil Katz, người tạo ra định dạng tệp ZIP.

Cũng thường thấy trong phân tích phần mềm độc hại liên quan đến tệp ZIP là những byte đó 01 02 ngay sau khi PK - đó là một điểm đánh dấu đặc biệt biểu thị "những gì tiếp theo là một khối dữ liệu trong đoạn giới thiệu ZIP cuối lưu trữ".

Các byte 1E 03, trong trường hợp bạn đang tự hỏi, biểu thị rằng tệp được tạo trên hệ thống giống Unix (0x03), tuân theo đặc điểm tệp zip 3 (0x1E là 30 ở dạng thập phân, được hiểu là phiên bản 3). Các 14 00 sau đó biểu thị rằng cần có PKZIP 2.0 trở lên để giải nén (0x14 là 20 ở dạng thập phân, được hiểu là 2.0).

Nói cách khác, Kellerman đã có thể suy luận rằng dữ liệu chảy vào phần cuối của các tệp gzip “chỉ đọc” không thường xuyên luôn là phần bắt đầu của dữ liệu bổ sung mà anh ta đã thêm vào cuối tệp ZIP tất cả trong một có thể ghi của mình. tập tin.

Tuy nhiên, cho dù anh ta có xem xét kỹ mã của mình đến đâu, anh ta cũng không thể thấy bằng cách nào anh ta có thể gây ra sự hỏng hóc này với một lỗi của riêng mình, ngay cả khi anh ta muốn.

Rốt cuộc, tác dụng phụ của lỗi là phần mềm của anh ấy đã bị hỏng 8 byte
ở cuối tệp mà bản thân hạt nhân được cho là sẽ ngăn anh ta ghi vào.

Như anh ấy viết về cảm xúc của anh ấy vào thời điểm đó:

Đổ lỗi cho nhân Linux (tức là mã của người khác) làm hỏng dữ liệu phải là phương án cuối cùng. Điều đó khó có thể xảy ra. Kernel là một dự án cực kỳ phức tạp được phát triển bởi hàng ngàn cá nhân với các phương pháp có vẻ hỗn loạn; mặc dù điều này, nó là cực kỳ ổn định và đáng tin cậy. Nhưng lần này, tôi tin rằng nó phải là một lỗi hạt nhân.

Nhưng với sự kiên trì, anh ấy đã có thể tạo ra hai chương trình tối giản, chỉ với ba và năm dòng mã tương ứng, tái tạo hành vi sai trái theo cách mà chỉ có thể đổ lỗi cho kernel.

Sau đó, anh ta có thể tạo ra một cuộc tấn công bằng chứng khái niệm cho phép người dùng không có đặc quyền sửa đổi ngay cả một tệp được khóa kỹ càng, chẳng hạn như danh sách các khóa SSH đáng tin cậy của bạn hoặc danh sách các chữ ký số “tốt được biết đến” của bạn. sẵn sàng kết nối để cập nhật.

Tệ hơn nữa, có vẻ như lỗi này, với tính chất cấp thấp, có thể được sử dụng bên trong một vùng chứa ảo hóa (nơi bất kỳ chương trình đang chạy nào không được phép có quyền ghi vào bất kỳ đối tượng nào bên ngoài “hộp cát” hoặc “nhà tù” của nó) để sửa đổi các tệp thường nằm ngoài giới hạn.

Tất nhiên, tin tốt là việc đào bới cẩn thận của Kellermans không chỉ giúp phát hiện ra lỗi và hiểu được nguyên nhân của nó mà còn giúp cộng đồng tìm ra bản vá để đóng lỗ hổng.

Phải làm gì?

• Nếu bạn là người dùng Linux 5.x. Kiểm tra phiên bản hạt nhân của bạn. Bạn muốn 5.10.102, 5.15.25 or 5.16.11 (hoặc ở trên). Nếu bản phân phối của bạn sử dụng các phiên bản hạt nhân cũ hơn với các bản vá bảo mật riêng được "báo cáo ngược", hãy kiểm tra với nhà sản xuất bản phân phối của bạn để biết chi tiết. Nếu không, chỉ cần chạy lệnh uname -r để in bản phát hành hạt nhân của bạn.
• Nếu bạn là người dùng Android. Chúng tôi không biết phải nói gì với bạn tại thời điểm viết bài [2022-03-08T17: 00Z], do có nhiều phiên bản hạt nhân đang được sử dụng bởi các sản phẩm và nhà cung cấp khác nhau. Cho đến nay, thiết bị chính duy nhất mà chúng tôi biết có kernel 5.10 là dòng Google Pixel 6, có vẻ như ở 5.10.43 và không có đề cập đến bản sửa lỗi mới nhất cho lỗi này Bản tin cập nhật pixel. Một số thiết bị khác (ví dụ như Google Pixel 5) đang sử dụng nhân 5.4, phần lớn các thiết bị còn lại của Google và các nhà cung cấp khác vẫn sử dụng phiên bản 4.x. Bạn có thể xem phiên bản hạt nhân của mình tại Cài đặt > Về điện thoại > Phiên bản android > Phiên bản hạt nhân - nếu bạn đang ở trên 5.10, chúng tôi khuyên bạn nên theo dõi Bản tin bảo mật Android trang tổng quan.
• Nếu bạn là một lập trình viên đang săn tìm lỗi. Khi theo dõi hành vi không thể giải thích khác, hãy phát triển nghệ thuật tạo ra "bản sao" nhỏ nhất mà bạn có thể - đó là thuật ngữ biệt ngữ để chỉ mã tái tạo hành vi không chính xác một cách đáng tin cậy để người khác có thể điều tra dễ dàng hơn. Loại bỏ càng nhiều biến số và sự không chắc chắn có thể có khỏi phương trình săn lỗi càng tốt trước khi giao nó cho người khác. Họ sẽ cảm ơn bạn vì điều đó.

• Coinsmart. Sàn giao dịch Bitcoin và tiền điện tử tốt nhất Châu Âu.
• Platoblockchain. Web3 Metaverse Intelligence. Khuếch đại kiến ​​thức. TRUY CẬP MIỄN PHÍ.
• CryptoHawk. Radar Altcoin. Dùng thử miễn phí.
• Nguồn: https://nakedsecurity.sophos.com/2022/03/08/dirty-pipe-linux-kernel-bug-lets-anyone-to-write-to-any-file/