V linuxovém jádru od Allwinneru byla nalezena chyba umožňující lokální eskalaci práv

V linuxovém jádru 3.4 od společnosti Allwinner pro její SoC H3, A83T a H8 používané například v tabletech a jednodeskových počítačích byla nalezena chyba umožňující lokální eskalaci práv spuštěním příkazu 'echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug'. Dle oficiálního vyjádření se jedná o zapomenutý kód použitý při ladění [reddit].

13.5.2016 19:15 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[a10]

OMG :-oooooooo

[JoHnY]

Sranda je, ze opravu realizovali tak, ze udelali jeden velkej push kterej meni kvanta kodu a premazali s nim historii repa vcetne filu ve kterym bylo rootmydevice udelatko. Asi programtori dostali od marketaku narizeno uklidit stopy.

Commity jsou prece pro sraby

[hermelin]

ona je chyba a "chyba"

[pc2005]

Jako zapomenutá vývojová funkce to je docela blbost, já embedded kernely vyvíjím s init=/bin/sh a pokud už jo, tak jako root s nějakým 12345 heslem. Tenhle příkaz pak IMO (kód jsem nestudoval) funguje jako sudo a žádný inženýr by nepsal ten šílenej příkaz při přihlašování každejch 10 minut (kvůli kernel panicu). Po pár resetech přestane člověka bavit i ten root/12345.

[Bedňa]

Tak možno tam mal skript s menom "r" a ten to echo spravil, skript zmazal a zabudol na ten hack.

[pc2005]

Jakože programátor si radši naprogramuje kus kernelu než aby si nakonfiguroval sudo/ssh?

[Cabrón]

v embedded prostředí určitě, funkční síť je docela high level závislost a na sudo se taky ve většině systémů nenarazí (např. i na Androidech není, a to jsou jedny z těch vyspělejších embedded systémů)

[pc2005]

Konzole na UARTu?

[Bedňa]

Tak keď si niečo potrebuješ otestovať, spravíš všelijaké zhovadilosti, sa deje denne

[aceman]

Ale zase vyhovorky. Ladiaci kod predsa mozu mat v ifdefe DEBUG_ALLWINNER a potom ak ho aj nahodou zabudnu a nahraju do oficialneho repozitara, nikto si ho omylom neskompiluje do produkcneho systemu.

[xkucf03]

Už dvakrát jsem zažil, že se kolegům stalo něco podobného¹, takže i tohle klidně mohla být neúmyslná chyba.

_{[1] chtěli si usnadnit neustálé přihlašování do systému… naštěstí se to nedostalo do produkce}

[pc2005]

Jaký měli důvod nepoužít init=/bin/sh ?

[xkucf03]

Tam zrovna nešlo o jádro, ale to je jedno… takový nápad dostane někdy každý programátor.

Co se týče init=/bin/sh – pak ti nenabíhají služby nebo nabíhají jiným způsobem než, jak se to v praxi bude používat.

Správné řešení je takovéhle zkratky nepoužívat vůbec – případně, když to musí být, tak použít podmíněnou kompilaci a nějakou „debug“ volbu – a hlavně to zdokumentovat a říct ostatním, aby to tam nebylo, až se bude dělat produkční sestavení.

[pc2005]

Aha tak to u mě nehrozí, já jsem vyvíjel hlavně na busyboxu a tam se prostě spustí /bin/sh na UARTu v /etc/inittab (služby se spustí předtím).

[xkucf03]

Válečné hry (1983) [31:10]:

Když vytvářím systém, vložím do něj jednoduchý kód, který znám jenom já.
Takže když se chci do něj vrátit, můžu obejít jakékoli zajištění, který tam přidali.

Koukám, že se za těch 33 let zase tak moc nezměnilo

[Václav "Darm" Novák]

No... Sice vím že konspirační teorie jsou v módě, ale pokud bych chtěl vytvořit backdoor pro třípísmenkové organizace, nepojmenuju ten debug "soubor" tak okatě.

[Jendа]

Hlavně local privilege escalation ještě k tomu na embedded systému nikoho nezajímá…

Ale je to užitečný argument až se zase pod nějakou zprávičkou o RaspberryPi objeví nějaký troll s tím, že přece všichni okolo mají mnohem levnější a výkonnější hardware, jehož výrobce sice na podporu kernelu a mainlinování kašle, ale to přece nikoho nezajímá.

[yada]

Problem neni ani tak ten bug, ale spis to ze z tech postihnutych zarizeny bude updatnutych tak 0.1%

Buhvikolik dalsich vyrobcu ma podobne bugy. Cele to krasne ukazuje ze svet ARMu (nebo spis cely embedded) je jedna obrovska zumpa...