Hlavní navigace

Názor k článku NXNSAttack: zastavte nový druh útoku náhodnými dotazy, aktualizujte resolvery od Filip Jirsák - Doporučil bych zaměřit se na význam slova „někdy“...

  • Článek je starý, nové názory již nelze přidávat.
  • 22. 5. 2020 12:58

    Filip Jirsák

    Doporučil bych zaměřit se na význam slova „někdy“ a pochopit význam věty „když už to umíte pro tyhle případy, můžete to použít i pro ty ostatní“.

    Odstraneni podpory pro systemd sockety z kresd skutecne nesouvisi s opravou nejake bezpecnostni chyby.
    To je právě ten váš naivní pohled, že se o každé opravě bezpečnostní chyby dozvíte v nějakém přehledu. Podpora soketové aktivace nikoli nepodstatným způsobem komplikovala kód pro konfiguraci sítě. Situaci znám jen z release notes, takže netuším, jaká byla nálada mezi vývojáři – jestli třeba měli nějaké podezření, že tam chyby nebo dokonce bezpečnostní chyby mohou být; nebo jestli byli přesvědčení, že ten kód je v pořádku, jenom situaci zbytečně komplikuje. Na druhou stranu, nedovedu si představit situaci, kdy bych jako vývojář odstranil nějaký kód s odůvodněním, že je zbytečně komplikovaný, v situaci, kdy bych byl přesvědčený, že ten kód je v pořádku. Takovéhle úpravy se dělají v okamžiku, kdy víte, že tam něco smrdí, a chcete se potenciální chyby zbavit dřív, než se někde opravdu projeví.

    Takže ona to dost možná byla oprava nějaké bezpečnostní chyby, o které ale zatím nikdo nevěděl (ani vývojáři). Nebo tím mohli předejít vzniku chyby v budoucnosti. Protože tenhle typ kódu – zbytečně komplikovaný kód, který nikdo nechce – ve kterém vlastně žádná chyba není, akorát že ho někdo jednou použije jinak, než bylo zamýšleno, a teprve tou kombinací se vyrobí bezpečnostní díra. Což je mimochodem přesně ten mechanismus, který je nebezpečný pro backportování oprav – protože opravu přenesete do jiného kontextu, ve kterém s ní nikdo nepočítal. A ten, kdo to přenáší, si nemusí uvědomit všechny souvislosti.

    To je přesně ten případ, o kterém jsem psal, a který žádné backporty oprav nezachytí. Že chyby, včetně bezpečnostních, se opravují i při běžném vývoji (vylepšování) programu. prostě je to kód, o kterém nikdo neví, že je tam chyba. Nebo to někdo ví a tají to, aby ji mohl zneužívat. Ani vývojáři si nejsou vědomi toho, že by v kódu byla chyba. Ale ten kód se jim nezdá, nedali by za něj ruku do ohně, vyhýbají se mu, nelíbí se jim. Až jim jednoho dne dojde trpělivost a ten kód přepíšou nebo zahodí. Pokud tam ta chyba byla, tak ji takhle odstraní. Protože chyby nejsou kvantové jevy, chyba v programu je, i když ji nikdo nepozoroval.

    Jenze ani to Vy prokazatelne ovladate jen teoreticky, ale sve teze ani nedokazete uvest do praktickeho zivota.
    Právě že s vývojem trochu zkušeností mám. Takže vím, že zdaleka ne všechny opravy chyb (včetně bezpečnostních) jsou někde zaevidované – vývojář si to často ani neuvědomí, že to, co právě opravil, byla bezpečnostní chyba. A když to není nikde zaevidované, nemůže se o tom dozvědět distribuční správce, aby tu opravu backportoval. A také vím, že oprava spousty chyb se nedá izolovat do jednoho patche. Můžete mít dvě podobné funkce X a Y, v červnu někdo najde potenciální chybu ve funkci Y a opraví ji, za půl roku někdo zjistí bezpečnostní chybu ve funkci A, která volá X – a opraví to tak, že místo X bude nově volat Y. I zaraduje se distribuční správce, že má patch opravující bezpečnostní chybu a backportuje ho do své staré verze, takže i v jeho verzi bude funkce A volat nově funkci Y. Jenže volá starou funkci Y, která je v té distribuční verzi ta stará, bez oné červnové drobné opravy, která neřešila žádný bezpečnostní problém. No a v takové situaci jsou různé možnosti – nejpravděpodobnější je, že ta oprava i tak bude fungovat. Méně časté je, ale stává se to dost často, že ta oprava nebude mít žádný efekt nebo jen částečný, tj. pořád bude možné chybu zneužít, i když to bude komplikovanější. No a někdy se zadaří a tímhle způsobem se vyrobí mnohem závažnější chyba,než co ten patch opravoval. No ale tohle celé se neděje v upstreamu, ale v nějaké distribuci v rámci patchování, při kterém se přece nemůže nic stát, takže se to ani pořádně neotestuje.

    Je to naprosto identická situace, jako když vývojář vyrobí chybu při přidávání nové funkce programu. Backportování oprav totiž není nic jiného, přestože se neustále tváříte, že při backportování žádná chyba vzniknout nemůže. Může, ten princip je úplně stejný.

    „Drobný“ rozdíl tam ale je. Tu novou funkcionalitu píše typicky vývojář, který tu aplikaci zná, zná souvislosti toho, co dělá. Ten backport v distribuci často dělá někdo, kdo má na starosti desítky balíčků a ten kód jenom mechanicky přenese, aniž by rozuměl podstatě problému nebo dokonce dohlédl alespoň některé souvislosti. A pak je tam ještě ten rozdíl, že změna v upstreamu se bude testovat v upstreamu a pak ještě v distribucích, zatímco ten distribuční backport se bude testovat jenom v té jedné distribuci.

    Můžete hádat, jaká asi bude pravděpodobnost, že ty distribuční backporty budou stejně kvalitní, jako kód v upstreamu.