Remote root kódfuttatás sebezhetőség az apt-ban

 ( trey | 2019. január 22., kedd - 19:16 )

Részletek itt. Debian figyelmeztető itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Akit érdekelnek a technikai részletek az ezt olvassa:

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1812353
és van benne debdiff is egy testcase-sel ami dokumentálja a hibát.

> This vulnerability could be used by an attacker located as a man-in-the-middle between APT and a mirror to inject malicous content in the HTTP connection.

Akkor lehet, hogy mégse olyan jó ötlet alapesetben http-n keresztül tölteni az APT csomagokat?

Elvileg a 2 ok a https ellen:

> providing a huge worldwide mirror network available over SSL is not only a complicated engineering task (requiring the secure exchange and storage of private keys), it implies a misleading level of security and privacy to end-users as described above.

> A switch to HTTPS would also mean you could not take advantage of local proxy servers

Hát nemtudom, egyik se tűnik meggyőzőnek...

Mondjuk tény, hogy a https csatlakozást kezelő kódban is lehet hasonló jellegű hiba.

szerintem elég lenne a hash-eket https-en letölteni és úgy már megbízható lenne...

Akár, de mondjuk a mostani problémától az nem védett volna meg. Szerintem a felsorolt két érv ma már nem releváns: se nem nehéz a https-t beállítani, se nem jellemző a cache-elő http proxy-k használata.

SSL extra komplexitas, hulye certificate kell a vhost-nak, stb... Macera.

A proxy meg hogyne lenne elterjedt; akamai, netflare es tarsai? Max. nem latod, de ott vannak mindenhol.

> SSL extra komplexitas, hulye certificate kell a vhost-nak, stb... Macera.

Azért ma már fél óránál többet nem kell rászánni egy ssl kompatibilis httpszerver beállítására.

> akamai, netflare es tarsai?

Ezek saját ssl cert-et raknak a kapcsolatra, szóval ez nem akadály.

Ezek saját ssl cert-et raknak a kapcsolatra

Egy "tisztességes" http(s) proxy is így szokott csinálni.
--

Akkor a probléma megoldva. De szerintem aki nagy mennyiségű gépet akar apt-n keresztül karban tartani és spórolni akar a sávészélességgel, akkor a akár egy saját repository felhúzása stabilabb megoldás, mint a transzparens http proxy.

> A switch to HTTPS would also mean you could not take advantage of local proxy servers

Azért ez elég meggyőző, ha több tucat szervert akarsz frissen tartani. A csomag hitelességét a GPG aláírás bizonyítja, ehhez nem kell https. Ha a letöltőben bug van, az egy dolog. A https-es letöltőben is lehet. Ha elromlik az ajtókilincsed, akkor egyből másik házat veszel?

cstamas linkjét még nem olvastam, csak a DSA-t.
De szöget ütött a fejembe: hogy a pékbe lehet egy http redir-rel kijátszani az apt-ot?

A repo-ban a release fájl gpg-vel alá van írva.
Abban van hash, meg minden ami kell a packages fájlokra, hogy azok sértetlenségében is biztosak lehessünk.
A packages fájlokban meg van mindenféle hash magukra a csomagfájlokra egyenként, hogy azok sértetlenségét is ellenőrizni lehessen.

Akkor most egy nyűves eltérített http redir ezt hogy fogja tudni keresztbeverni?

elso linken van a pelda, ha jol ertem akkor location redir stringet, visszakuldi, ha abban ujsor van akkor is
viszont a aptgetnek az ujsor mar mast jelet, hogy locationban lehet kamuvalaszokat adni. namost a letoltott package hash szamolast is a http gyerekprocess vegzi (demiert?), es csak a kiszamolt hash kuldi vissza. kamuvalasz kozott meg lehet egy kamuhash is.

apt kamuvalasz miatt azt hiszi hogy helyes packages.gz-t toltott le, mikozben abban marmi lehet.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Úgy van, jól mondod.

Spéci header-t küldve csapja be, mert olyan sorokat tud előállítani ami felülbírálja a hash-t amit a program is készít később, de az első sor (ami a hamis) "nyer".

Továbbra is az ubuntu-s bugreport az ami használhatóan leírja, hogy miről van szó. (nem linkelem megegyszer)

(aki elolvasta és megérette a fentieket, az azt is fogja tudni, hogy a http miért csak részben védene a fenti támadás ellen :)

Igen. Kozben elolvastam a buguntus-t is. Az valoban egybevag a fent leirttal.

De ez...
Ez...

More, ez nagyon kiiigyo/ facepalm!

Ezzel érdemes kezdeni szerintem a megértést: https://justi.cz/security/2019/01/22/apt-rce.html

Ez alapján a Location http header-el be tud injektálni egy valid aláírásokat tartalmazó fájl letöltésének tűnő visszatérési értéket. Vagy ilyesmi :)