Hlavní navigace

Názor ke zprávičce Bashware: nový útok využívá Windows Subsystem for Linux od ventYl - > Tak, bezpečnostní model tam je už dávno,...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 13. 9. 2017 22:02

    ventYl

    > Tak, bezpečnostní model tam je už dávno, ale holt si uživatelé zvykli jeho služeb pokud možno nevyužívat (protože na jejich oblíbených WIndows 9x nebyl přítomen).

    To sa bavime o sedeni pod non-admin pouzivatelom? To za relevantny bezpecnostny model nie velmi povazujem. Bol by som ochotny nazor zmenit v pripade, ze by vyuzivanie non-admin konta zamedzilo vsetkym hrozbam malware okrem pripadov, kedy sa jednoznacne jedna o bug v OS (nedokumentovane chovanie alebo chovanie v rozpore s dokumentaciou). Obaja ale vieme, ze toto riesenie je len ciastocne a principialne ani nemoze byt 100% uspesne.

    > Pokud myslíte modifikace knihoven v paměti procesu za účelem jeho monitorování,
    Mam na mysli akekolvek riesenie na urovni userspace. Ci uz je to IAT hooking, alebo prepisovanie kniznic priamo v pamati procesu (teraz narychlo neviem najst ako sa Microsoftne riesenie na prepisovanie za letu vola). Samozrejme si ziadne solidne AV riesenie cisto s tymto nevystaci, ale bezne sa to pouziva, pretoze to dava sancu heuristike zistit vysokourovnovu semantiku chovania aplikacie. Je zjavne ze ani monitorovanie na pomedzi kernelu tu nepomohlo, pretoze bud WSL pouziva iny entry point do kernelu, nez je chraneny antivirmi, alebo heuristika nie je schopna v scheme, ktorou pristupuje WSL k nativnemu kernelu rozpoznat ziadne divne chovanie.

    > Ale dlouho tam byl problém v tom, že některá rozhraní používaná pro monitorování/blo­kování se na ně prostě nevztahovala.
    Presne v tomto (a hlavne v tomto) je jadro problemu. Bezpecnost Windowsu je postavena na tom, ze k systemu je prilepene rozhranie, ktore umoznuje *dodatocne* blokovat potencialne nebezpecne chovanie. Cela bezpecnost systemu je potom funkciou schopnosti implementacie blokovania takeho chovania toto chovanie ako nebezpecne rozpoznat. Neviem, ci to ludia, ktori tomuto oponuju nevidia, alebo nechcu vidiet.

    Ak system uplne legitimne dovoluje spravit take invazivne akcie, ako zapis do pamate ineho procesu alebo dokonca spustenie syscallu / threadu v kontexte ineho procesu, tak z absolutneho principu veci nemoze byt o bezpecnosti ani slovo. To samo o sebe by nebolo zle, keby tento fundamentalny mechanizmus nebol tak siroko aplikovany (co znemoznuje jeho odstranenie). To, ze v systeme potom existuje obmedzenie, ktore nedovoli injectovat pamat alebo instrukcie do kritickych procesov je potom uz len chaba naplast.

    Nechutnym sideefektom potom je, ze celkovy pristup k bezpecnosti je taky, ze sa problemy riesia na mieste, kde sa vektor spusta namiesto toho aby sa riesili na mieste, kde vektor utoku ucinkuje. To potom rozbija veci, nici spatnu kompatibilitu a celkovo posobi tak trocha dost WTF.