0104755 NTFS attēlā dod root: ntfs3 ielāpa nav divus mēnešus pēc ziņojuma

NTFS sējuma galvenajā failu tabulā var ierakstīt trīs skaitļus: 0, 0 un 0104755. Linux ntfs3 draiveris tos nolasa pieslēgšanas brīdī un parāda attiecīgo failu kā setuid-root programmu. Neviens neizsauc setxattr. Vērtības jau guļ diskā un draiveris tām tic bez pārbaudes.

Kļūdu atrada Vova Tokarevs. Ziņojumu kodola izstrādātājiem viņš aizsūtīja jūnijā, atbildi nesaņēma un 22. augustā publiskoja gan aprakstu, gan strādājošu paraugkodu ntfs3 vēstkopā. Phoronix ziņu pamanīja tajā pašā sestdienas rītā. Mainline kodolā ielāpa joprojām nav.

Trīs atribūti, ko draiveris atnesa no WSL

NTFS glabā paplašinātos atribūtus pašā diskā. Trīs no tiem, $LXUID, $LXGID un $LXMOD, Windows apakšsistēma Linux videi izmanto, lai atcerētos Unix īpašnieku un tiesību bitus failiem, kas izveidoti WSL iekšienē. ntfs3 tos prot nolasīt, lai tie paši faili Linux pusē izskatītos tāpat.

Nolasīšana notiek funkcijā ntfs_get_wsl_perm(). To izsauc ntfs_read_mft() katru reizi, kad inode ierakstā ir atribūts ATTR_EA_INFO. Mount opcijas, kas šo uzvedību izslēgtu, ntfs3 nav. Funkcijas vidū stāv rinda, kas visu izšķir:

inode->i_mode = le32_to_cpu(value[2]);

Vērtība nāk no diska. i_mode saņem arī S_ISUID un S_ISGID bitus tieši tādus, kādus tos ierakstījis attēla autors. Pārbaude pret CAP_SYS_ADMIN draiverī ir, taču tā sargā setxattr ceļu, kur lietotājs atribūtu maina jau pieslēgtā sējumā. Uzbrucējam tas ceļš nav vajadzīgs. Rindu var apskatīt fs/ntfs3/xattr.c 1048. rindā, kur maskas joprojām nav.

Uzbrucēja darbs ir sagatavošanas darbs. Attēlu veido uz savas mašīnas: uzliek NTFS, iekopē tajā mazu programmu, kas izsauc setuid(0) un palaiž čaulu, tad ieraksta failam trīs paplašinātos atribūtus ar nullēm un 0104755. Uz mērķa datora vairs neko darīt nevajag. Pietiek panākt sējuma pieslēgšanu un tad palaist to pašu failu no pieslēgšanas vietas.

Iepriekš sagatavots NTFS attēls ar $LXUID=0, $LXGID=0 un $LXMOD=0104755 galvenajā failu tabulā rada setuid-root bināro failu brīdī, kad sējums tiek pieslēgts. Man ir pilns paraugkods ar demonstrāciju. (Vova Tokarevs ntfs3 vēstkopā)

Vai darbvirsma tiešām ir apdraudēta

Tokarevs raksta, ka darbvirsmas automātiskie pieslēdzēji NTFS pieslēdz ar suid pēc noklusējuma un tāpēc jebkurš vietējais lietotājs ar sagatavotu zibatmiņu iegūst euid=0. Šī daļa pārbaudi neiztur. udisks2, uz kuru paļaujas gan GNOME, gan KDE, mount opciju virkni sāk veidot ar fiksētu nodev,nosuid un tikai pēc tam pievieno pārējo. Kodu var izlasīt udiskslinuxmountoptions.c 1162. rindā. Atļauto opciju sarakstā, ko udisks2 pieņem no lietotāja, suid nav vispār.

Ar nosuid kodols setuid bitus ignorē neatkarīgi no tā, ko apgalvo sējums. Parasts Ubuntu vai Fedora klēpjdators ar iespraustu svešu zibatmiņu tātad paliek neskarts. Tas nepadara kļūdu par nebūtisku, tikai pārceļ to no darbvirsmas uz serveru pusi.

Kur risks ir reāls

Bīstamas ir vietas, kur nosuid pazūd. Ar roku rakstīta fstab rinda, kurā šī opcija aizmirsta. NAS vai multivides kaste, kas pieslēdz visu, ko lietotājs tai iedod. Konteineru resursdators. Kriminālistikas darbstacija, kur analītiķis pieslēdz svešu attēlu, lai tajā ieskatītos. Rezerves kopiju skripts, kas dara to pašu automātiski katru nakti.

Visur, kur nepriviliģēts lietotājs var panākt sveša NTFS sējuma pieslēgšanu bez nosuid, tā ir tieša vietējā tiesību paaugstināšana. Sacensību apstākļu nav. Atmiņas bojāšanas nav. Ir tikai skaitlis diskā, kam draiveris notic.

Otra lieta, kas šajā stāstā izceļas, ir laiks. Ziņojums pie kodola izstrādātājiem nogulēja divus mēnešus bez atbildes. Kodola drošības komandas parastais solījums ir septiņas dienas līdz ielāpam publiskiem gadījumiem un līdz nedēļām sarežģītākiem. Šeit labojums ir viena rinda bez saderības sekām, tāpēc gaidīšana grūti izskaidrojama. Tokarevs publiskoja aprakstu ar paraugkodu tieši tāpēc, ka privātais ceļš beidzās klusumā.

Ielāps aizņem vienu rindu

Tokarevs piedāvāja labojumu: inode->i_mode = le32_to_cpu(value[2]) & ~(S_ISUID | S_ISGID);. Setuid un setgid biti tiek nodzēsti, pārējā WSL loģika ar īpašnieku un parastajām tiesībām strādā tālāk. Sestdien un svētdien mainline kokā šī izmaiņa neparādījās.

ntfs3 kodu kodolā ievietoja Paragon Software un ar 5.15 laidienu 2021. gadā tas izspieda FUSE balstīto ntfs-3g no vairuma distributīvu noklusējuma. Uzturēšanas temps kopš tā laika ir bijis lēns un vēstkopā par to sūdzas regulāri. Maijā tika publicēts CVE-2026-46062 ar novērtējumu 7,8: vesela skaitļa pārpilde funkcijā run_unpack(), kur sējuma robežu pārbaude lcn + len > sbi->used.bitmap.nbits pārsviežas pāri. Atradējs to ieguva ar fuzzing rīku LibAFL un QEMU. Uzbrukuma forma tur ir tāda pati: pieslēdz naidīgu attēlu, salauz kodolu.

Phoronix norāda, ka jaunākais NTFS draiveris, kas kodola kokā aug paralēli, šo problēmu, visticamāk, neskar.

Ko darīt līdz ielāpam

Pārskati katru fstab rindu ar ntfs vai ntfs3 un pievieno tai nosuid kopā ar nodev. Skriptiem, kas pieslēdz nezināmus attēlus, tās pašas opcijas jāpadod tieši mount izsaukumā. Ja mašīnai NTFS lasīt nav vajadzīgs, moduli var neveidot vispār vai bloķēt ar blacklist ntfs3 modprobe konfigurācijā.

23. augusta rītā fs/ntfs3/xattr.c 1048. rinda Torvaldsa kokā ir nemainīta.

Avoti

• Phoronix: Specially Crafted NTFS File-System Image Allows Root Access On Linux With NTFS3 Driver
• Linux kodola pirmkods: fs/ntfs3/xattr.c, ntfs_get_wsl_perm()
• udisks2 pirmkods: mount opciju veidošana
• CVE-2026-46062: ntfs3 integer overflow in run_unpack()
• Hardware Busters: A Crafted NTFS Image Hands Out Root Through Linux’s NTFS3 Driver

Titulbildes foto: Sandisk vietnē Unsplash.