Thorsten Kukuk, pamimpin Tim Téknologi Masa Depan di SUSE (Tim Téhnologi Masa Depan, ngembangkeun openSUSE MicroOS sareng SLE Micro), anu sateuacana mingpin proyék SUSE LINUX Enterprise Server salami 10 taun, ngusulkeun ngaleungitkeun file /var/run/utmp dina distribusi pikeun pinuh alamat masalah Y2038 di Glibc. Sadaya aplikasi anu nganggo utmp, wtmp, sareng lastlog diusulkeun pikeun dipindahkeun ka kéngingkeun daptar pangguna anu nganggo systemd-logind.
Dina tanggal 19 Januari 2038, konter waktu epoch anu ditetepkeun ku jinis time_t 32-bit bakal ngabahekeun. Dina Glibc, sanajan bubuka tipe time_t 64-bit, pikeun ngajaga kasaluyuan jeung aplikasi spasi pamaké 32-bit, tipe time_t 64-bit masih dipaké dina sababaraha kasus dina platform 32-bit. Hiji kasus sapertos nyaéta file /var/run/utmp, anu nyimpen data ngeunaan pangguna anu ayeuna asup kana sistem. Widang waktos di utmp diatur nganggo nilai time_t 32-bit.
Kantun ngarobah hiji widang di utmp kana waktu ti 32-bit kana tipe 64-bit moal jalan, sabab ieu bakal ngarobah Glibc ABI (tipe bakal robah dina fungsi kawas login (), getutid () sarta utmpname ()) sarta megatkeun kasaluyuan jeung aplikasi nu make utmp, kaasup w, saha, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, manajer tampilan xterm, emacs, openssh, qemu, samba, rsyslog, jsb. Kusabab seueur kamungkinan pitfalls sareng laboriousness, ideu pikeun ngagentos panjang bit tina jinis time_t dina utmp ditolak ku pamekar Glibc. Pikeun alesan anu sami, pilihan pikeun ngagunakeun rohangan anu sayogi dina struktur utmp pikeun nambihan médan waktos 64-bit tambahan dileungitkeun.
Sajaba ti éta, ngarobah jero bit sahiji tipe di utmp teu ngajawab masalah sejenna aya, nu kuring ogé hoyong meunang leupas tina. Contona, nulis ka utmp merlukeun idin husus, nu merlukeun hak husus tambahan pikeun dibikeun ka prosés. Masalah sanésna nyaéta yén arsitéktur utmp ngamungkinkeun para pangguna lokal pikeun ngalakukeun serangan DoS anu ngarobih jasa utmp ngaliwatan manipulasi konci file, sahingga teu mungkin pikeun mastikeun yén eusi utmp ngagambarkeun kaayaan nyata dina sistem. Diusulkeun ngagunakeun prosés latar tukang tambahan pikeun nanganan aksés ka utmp, tapi pikeun tugas-tugas sapertos kitu parantos aya prosés login-systemd sareng ngamimitian prosés khusus anu sanés henteu disarankeun (aplikasi kedah nransfer data ka dua pawang dina waktos anu sami) .
Dina waktos anu sami, bahkan nalika ngarengsekeun masalah sareng serangan DoS, eusi utmp tetep ngan ukur inpormasi, henteu ngajamin cerminan kanyataan. Contona, émulator terminal béda jeung multiplexer ngagambarkeun kaayaan maranéhanana béda - ngajalankeun lima terminal GNOME bakal ngakibatkeun hiji pamaké reflected di utmp, bari ngajalankeun lima konsole atanapi xterm terminal di KDE bakal ngahasilkeun genep. Nya kitu, paripolah layar sareng tmux béda, dina kasus anu kahiji unggal sési diitung salaku pangguna anu misah, sareng dina kadua ngan ukur hiji pangguna anu ditingali pikeun sadaya sesi.
Hasilna, salaku solusi pangbasajanna, diusulkeun pikeun nransferkeun sadaya aplikasi pikeun nganggo jasa sistemd-login alternatif anu tos aya sareng, saatos teu aya program aktual anu ngaksés utmp, lirén nyerat ka utmp. Pikeun ngaganti wtmp, diusulkeun nyiapkeun API pikeun nyerat sareng maca inpormasi ngeunaan pangguna anu nganggo systemd-journald. The codebase pikeun release saterusna systemd 254 geus ngawengku fungsi perlu nyadiakeun ngagantian data utmp via libsystemd ngagunakeun sd-login.h API atanapi via DBUS.
sumber: opennet.ru