Trong SUSE, họ đề nghị ngừng sử dụng utmp để giải quyết vấn đề Y2038 trong Glibc

Y2038

Sự cố của năm 2038 có thể khiến một phần phần mềm bị lỗi trong năm đó. Sự cố ảnh hưởng đến các chương trình sử dụng biểu diễn thời gian dựa trên POSIX.

Thorsten Kukuk, trưởng nhóm từ SUSE Công nghệ Tương lai (Nhóm Công nghệ Tương lai, phát triển openSUSE MicroOS và SLE Micr ), người trước đây đã lãnh đạo dự án SUSE LINUX Enterprise Server trong 10 năm, đề xuất loại bỏ tệp /var/run/utmp trong các bản phân phối để giải quyết đầy đủ vấn đề Y2038 trong Glibc.

Với đề xuất di chuyển tất cả các ứng dụng sử dụng utmp, wtmp và lastlog để lấy danh sách người dùng sử dụng systemd-logind.

Vào ngày 19 tháng 2038 năm XNUMX, bộ hẹn giờ sẽ tràn trong khoảng thời gian xác định bằng loại time_t 32 bit. Trong Glibc, mặc dù đã giới thiệu loại time_t 64 bit, nhưng để duy trì khả năng tương thích với các ứng dụng không gian người dùng 32 bit, loại time_t 32 bit vẫn được sử dụng trong một số trường hợp trên nền tảng 64 bit.

Có hai vấn đề chính với utmp/utmpx với glibc trên ví dụ: x86-64:

Trường time_t 32 bit được sử dụng cho thời gian, trường này sẽ tràn vào năm 2038
Có các vấn đề về thiết kế cho phép tấn công DoS (chặn utmp/wtmp cho phép người dùng không có đặc quyền từ chối dịch vụ)
Một phân tích về vấn đề thứ hai của các nhà phát triển glibc cho thấy rằng một daemon bổ sung sẽ được yêu cầu để xử lý truy cập utmp/utmpx.

Mặc dù còn một số vấn đề nữa...

Một trong những trường hợp như vậy là tệp /var/run/utmp, lưu trữ dữ liệu về người dùng hiện đang kết nối với hệ thống. Trường thời gian trong utmp được đặt bằng giá trị time_t 32 bit.

Nó được đề cập rằng, chỉ cần thay đổi một trường trong utmp theo thời gian từ loại 32 bit sang loại 64 bit sẽ không hoạt động, vì điều này sẽ thay đổi Glibc ABI (loại sẽ thay đổi trong các chức năng như login(), getutid() và utmpname()) và phá vỡ khả năng tương thích với các ứng dụng sử dụng utmp, bao gồm w, who, uptime, login, su, sudo, useradd , systemd, sysvinit, tcsh, trình quản lý hiển thị xterm, emacs, openssh, qemu, samba, rsyslog, v.v.

Do có rất nhiều cạm bẫy tiềm ẩn và sự siêng năng, các nhà phát triển của Glibc bác bỏ ý tưởng thay thế độ dài bit của kiểu time_t trong utmp. Vì lý do tương tự, tùy chọn sử dụng không gian có sẵn trong cấu trúc utmp để thêm trường thời gian 64 bit bổ sung đã bị xóa.

Ngoài ra, việc thay đổi độ sâu bit của loại trong utmp không giải quyết được các vấn đề hiện có khác, ví dụ: ghi vào utmp yêu cầu các quyền đặc biệt, yêu cầu các quy trình phải được cấp các đặc quyền bổ sung. Một vấn đề khác là kiến ​​trúc utmp cho phép người dùng cục bộ thực hiện các cuộc tấn công DoS phá vỡ dịch vụ utmp bằng cách thao tác khóa tệp, khiến không thể chắc chắn rằng nội dung của utmp phản ánh trạng thái thực của hệ thống.

Nó đã được đề xuất sử dụng một quy trình nền bổ sung để xử lý quyền truy cập vào utmp, nhưng đối với những tác vụ như vậy đã có quy trình đăng nhập hệ thống và không nên bắt đầu một quy trình chuyên biệt khác (các ứng dụng sẽ phải chuyển dữ liệu đến hai bộ điều khiển cùng một lúc).

Đồng thời, ngay cả khi giải quyết được vấn đề tấn công DoS, nội dung của utmp vẫn chỉ mang tính chất cung cấp thông tin mà không đảm bảo phản ánh đúng thực tế.

Ví dụ: các trình giả lập và bộ ghép kênh thiết bị đầu cuối khác nhau phản ánh trạng thái của chúng khác nhau: chạy năm thiết bị đầu cuối GNOME sẽ dẫn đến một người dùng được sao chép trong utmp, trong khi chạy năm thiết bị đầu cuối konsole hoặc xterm trong KDE sẽ dẫn đến sáu thiết bị đầu cuối. Tương tự, hành vi của màn hình và tmux khác nhau, trong trường hợp đầu tiên, mỗi phiên được tính là một người dùng riêng biệt và trong trường hợp thứ hai, chỉ một người dùng được phản ánh cho tất cả các phiên.

Kết quả là, như một giải pháp đơn giản nhất, đề xuất chuyển tất cả các ứng dụng sang sử dụng dịch vụ systemd-logind thay thế đã tồn tại và sau khi không có chương trình thực nào đang truy cập utmp, hãy ngừng ghi vào utmp. Để thay thế wtmp, đề xuất chuẩn bị các API để viết và đọc thông tin về người dùng bằng systemd-journald.

Cuối cùng, điều đáng nói là cơ sở mã cho phiên bản tiếp theo của systemd 254 đã bao gồm các chức năng cần thiết để cung cấp dữ liệu utmp thay thế qua libsystemd bằng API sd-login.ho qua DBUS.

Nếu bạn quan tâm muốn biết thêm về nó, bạn có thể tham khảo chi tiết Trong liên kết sau đây.


Để lại bình luận của bạn

địa chỉ email của bạn sẽ không được công bố. Các trường bắt buộc được đánh dấu bằng *

*

*

  1. Chịu trách nhiệm về dữ liệu: AB Internet Networks 2008 SL
  2. Mục đích của dữ liệu: Kiểm soát SPAM, quản lý bình luận.
  3. Hợp pháp: Sự đồng ý của bạn
  4. Truyền thông dữ liệu: Dữ liệu sẽ không được thông báo cho các bên thứ ba trừ khi có nghĩa vụ pháp lý.
  5. Lưu trữ dữ liệu: Cơ sở dữ liệu do Occentus Networks (EU) lưu trữ
  6. Quyền: Bất cứ lúc nào bạn có thể giới hạn, khôi phục và xóa thông tin của mình.