Vlákno názorů k článku Nástroj apt-key končí. Jak dál spravovat klíče balíčkovacího systému? od Snipercze - Nejak asi nechapu, co se tim resi. Pokud...

Nejak asi nechapu, co se tim resi. Pokud budu mit repozitar repo.example.com a do repo file mu pridam dany klic, porad tomu klici verim pro vsechny baliky daneho repa. Co zabrani tomu, aby se v tom repu neobjevil treba balik linux-image-10.0.0.deb, ktery bude obsahovat skodlivy kod a system ho bude povazovat za upgrade kernelu? Na to preci mame pinning, abychom vazali baliky na konkretni repo, ne klice. Ano, asi to resi situaci, kdy nekdo ukradne klic repozitare A, podepise tim svuj balik a nahraje ho do repozitare B, ale proc by to nekdo delal, kdyz uz ma pristup k repozitari A? Vlastne by to byla i kravina - lidi co maji klic k repu A maji pravdepodobne i repo A, lidi co maji pouze repo B pravdepodobne nemaji ani klic k repu A a apt zarve chybu podpisu.

22. 6. 2021, 08:30 editováno autorem komentáře

Dejme tomu, že repozitář A půjde přes HTTP, ale nebudu k němu mít klíč. Repozitář B půjde přes HTTPS, ale budu k němu mít klíč. Co mohu z pozice útočníka?

Dnes mohu udělat MITM k repozitáři A a podepsat to klíčem repozitáře B. Analogická situace nastává, když z nějakého důvodu sice nemohu udělat MITM (HTTPS, nemám přístup k síti, …), ale kompromitoval jsem infrastrukturu jiného repozitáře, než ke kterému mám klíč.

Bude-li klíč vázaný k repozitáři, podobný útok nebude možný – musel bych kompromitovat spojení nebo infrastrukturu ke stejnému repozitáři.

Taky nechápu, co tím řeší.

Jsem padouch, nabořím server hostující repo a zmocním se klíče k repu, vyberu nějaký modul dostupný i se zdrojákem, zvýším číslo revize, do instalačního skriptu dopíšu "apt-get install -y super-ransom-crypto". Nebo, protože ten skript valí pod rootem, se povrtat v databázi klíčů a vyměnit tam cokoliv.

V tu chvíli je úplně šumák, že nemůžu napadnout žádný jiný repo, protože na stroji oběti jsem na chvíli root a není, co bych nemohl...

Výměnu klíče jinýho repa skriptem by řešilo jenom mít extra uživatele na update a dát mu klíče jako read only... A to by šlo i se stávajícím řešením.

Da se to zkombinovat s apt pinningem (/etc/apt/pre­ferences.d), imho by mely mit vsechny 3rd party repozitáře nižší prioritu by default a třeba pomocí pinningu si určit, které balíky z toho repozitáře nainstalovat. Viděl jsem balíky, které "v dobrém umyslu" v postinstu bez vědomí uzivatele přidali apt klíč a cron na automatické updaty. To mi třeba vadí hodně. To, že v takovém případě ten klíč nebude platný globálně, mě pomůže, protože zbytek umím vyřešit právě pinningem. (Ještě by to ten pinning chtělo nějak chytře automatizovat.)

Napr. apt by si mohlo pamatat, ze z ktoreho repa je balik nainstalovany a by defult brat update aj dependencie z rovnakeho repa. Spolu s tym, ze podpis je platny len pre jedno repo to uz aj realne trochu obmedzi moznosti utoku.