Äskettäin tuli tunnetuksi kautta blogikirjoitus, testaustyökalujen tulokset haavoittuvuuksien tunnistamiseksi ei korjaustiedostoa ja tunnista turvallisuusongelmat yksittäisissä Docker-konttikuvissa.
Testi osoitti, että neljä kuudesta skannerista tunnetut Docker-kuvat oli kriittisiä haavoittuvuuksia joka antoi mahdollisuuden hyökätä itse skanneriin ja suorittaa sen koodi järjestelmässä, joissakin tapauksissa (esimerkiksi Snykin avulla) root-oikeuksilla.
Hyökkäystä varten hyökkääjän täytyy vain alkaa tarkistaa Docker-tiedostonsa tai manifest.json, joka sisältää erityisesti alustetut metatiedot, tai laita podfile- ja gradlew-tiedostot kuvan sisään.
Pystymme valmistelemaan prototyyppejä WhiteSource-, Snyk-, Fossa- ja ankkurijärjestelmiin.
El paquete Clair alun perin kirjoitettu turvallisuutta ajatellen, osoitti parasta turvallisuutta.
Trivy-paketissa ei havaittu ongelmia ja sen seurauksena pääteltiin, että Docker-konttiskannereita tulisi käyttää erillisissä ympäristöissä tai käyttää vain omien kuviensa tarkistamiseen, ja oltava myös varovaisia yhdistettäessä tällaisia työkaluja automaattisiin jatkuviin integrointijärjestelmiin.
Nämä skannerit tekevät monimutkaisia ja alttiita virheille. He ovat tekemisissä telakointiaseman kanssa, purkavat kerroksia / tiedostoja, ovat vuorovaikutuksessa pakettien hallinnan kanssa tai analysoivat erilaisia muotoja. Niiden puolustaminen on erittäin vaikeaa, samalla kun yritetään sovittaa kaikki kehittäjien käyttötapaukset. Katsotaanpa, miten eri työkalut yrittävät ja onnistuvat tekemään se:
Vastuullinen tiedonantopiste heijastaa henkilökohtaista mielipidettäni: mielestäni on tärkeää, että ohjelmistotoimittajien on reagoitava heille ilmoitettuihin turvallisuuskysymyksiin, oltava rehellisiä ja avoimia haavoittuvuuksien suhteen varmistaakseen, että tuotteitaan käyttäville ihmisille annetaan asianmukaiset tiedot päivitystä koskevat päätökset. Tämä sisältää tärkeimmät tiedot siitä, että päivityksessä on tietoturvaan liittyviä muutoksia, CVE: n avaaminen ongelman seuraamiseksi ja kommunikoimiseksi sekä mahdollisesti asiakkaille ilmoittamiseksi. Mielestäni tämä on erityisen järkevää olettaa, jos tuotteessa on kyse CVE: stä, mikä antaa tietoja ohjelmistojen haavoittuvuuksista. Lisäksi minua rauhoittaa nopea reagointi, kohtuulliset korjausajat ja avoin kommunikaatio hyökkäyksestä ilmoittavan henkilön kanssa.
FOSSA, Snyk ja WhiteSource haavoittuvuus liittyi soittamalla ulkoiselle paketinhallinnalle määrittää riippuvuudet ja antaa sinun järjestää koodisi suorittaminen määrittämällä kosketus- ja järjestelmäkomennot gradlew- ja Podfile-tiedostoissa.
En Snyk ja WhiteSource löysivät myös käynnistysjärjestelmän komentoihin liittyvän haavoittuvuuden organisaatio, joka jäseni Dockerfile-tiedoston (esimerkiksi Snykissä Dockefile-ohjelman kautta, voit korvata skannerin aiheuttaman apuohjelman ls (/ bin / ls), ja WhiteSurcessa voit korvata koodin argumenttien avulla "kaiun" muodossa; napauta / tmp / hakkeroitu_valkolähteen_pip; = 1.0 '«).
Anchoressa haavoittuvuus johtui skopeo-apuohjelman käytöstä työskennellä telakointikuvien kanssa. Operaatio supistettiin lisäämällä muotoon '»os»: «$ (touch hacked_anchore)»' parametrit manifest.json-tiedostoon, jotka korvataan kutsuttaessa skopeoa ilman asianmukaista pakoa (vain merkit «; & <poistettiin > ", Mutta rakenna" $ () ").
Sama kirjoittaja teki tutkimuksen haavoittuvuuden havaitsemisen tehokkuudesta ei paikattu turvakannerien kautta telakkasäiliöiden määrä ja vääriä positiivisia tuloksia.
Kirjoittajan lisäksi väittää, että useat näistä työkaluista suoraan riippuvuuksien selvittämiseen pakettien hallinnan avulla. Tämä tekee heistä erityisen vaikea puolustaa. Joillakin riippuvuudenhallinnoijilla on määritystiedostot, jotka sallivat shell-koodin sisällyttämisen.
Vaikka näitä yksinkertaisia tapoja hoidettaisiin jollakin tavalla, näiden pakettien ylläpitäjien kutsuminen merkitsee väistämättä rahan kuorintaa. Tämä ei lievästi sanottuna helpota hakemuksen puolustamista.
Testitulokset 73 haavoittuvuutta sisältävälle kuvalle tunnettu, samoin kuin arvio tehokkuudesta tyypillisten sovellusten läsnäolon määrittämiseksi kuvissa (nginx, tomcat, haproxy, gunicorn, redis, ruby, solmu), voi kuulla tehdyn julkaisun sisällä Seuraavassa linkissä.