Nesen kļuva zināms ar emuāra ziņojums, testēšanas rīku rezultāti ievainojamības identificēšanai nav plākstera un identificējiet drošības problēmas atsevišķos Docker konteinera attēlos.
Pārbaude parādīja, ka 4 no 6 skeneriem zināmi Docker attēli bija kritiskas ievainojamības kas ļāva uzbrukt pašam skenerim un palaist tā kodu sistēmā, dažos gadījumos (piemēram, izmantojot Snyk) ar root tiesībām.
Par uzbrukumu uzbrucējam vienkārši jāsāk pārbaudīt savu Dockerfile vai manifest.json, kas ietver īpaši formatētus metadatus, vai ievietojiet podfile un gradlew failus attēla iekšpusē.
Mums izdodas sagatavot izmantojamos prototipus WhiteSource, Snyk, Fossa un enkuru sistēmām.
El paquete Clair sākotnēji rakstīts, ņemot vērā drošību, parādīja vislabāko drošību.
Trivy paketē nav konstatētas problēmas un rezultātā tika secināts, ka Docker konteineru skeneri ir jādarbina izolētā vidē vai jāizmanto tikai, lai pārbaudītu savus attēlus, kā arī jābūt piesardzīgiem, savienojot šādus rīkus ar automatizētām nepārtrauktas integrācijas sistēmām.
Šie skeneri veic sarežģītas un kļūdām raksturīgas lietas. Viņi nodarbojas ar dokotāju, slāņu / failu izgūšanu, mijiedarbību ar pakotņu pārvaldniekiem vai dažādu formātu analīzi. Viņu aizstāvēšana, cenšoties pielāgot izstrādātājiem visus lietošanas gadījumus, ir ļoti sarežģīta. Apskatīsim, kā dažādi rīki mēģina un izdodas to izdarīt:
Atbildīgais informācijas atklāšanas rādītājs atspoguļo manu personīgo viedokli: es domāju, ka programmatūras pārdevējiem ir svarīgi būt uzņēmīgiem pret tiem ziņotajiem drošības jautājumiem, būt godīgiem un pārredzamiem par ievainojamībām, lai nodrošinātu, ka cilvēki, kas lieto viņu produktus, ir pienācīgi informēti, lai pieņemtu lēmumus par atjauninājumu. Tas ietver visaugstāko informāciju par to, ka atjauninājumam ir ar drošību saistītas izmaiņas, atverot CVE, lai izsekotu un sazinātos par problēmu un, iespējams, informētu klientus. Es domāju, ka tas ir īpaši pamatoti pieņemt, ja produkts attiecas uz CVE, sniedzot informāciju par programmatūras ievainojamībām. Mani nomierina arī ātrā reaģēšana, saprātīgais korekcijas laiks un atklātā komunikācija ar personu, kas ziņo par uzbrukumu.
FOSSA, Snyk un WhiteSource ievainojamība bija saistīta ar zvanu ārējam pakotņu pārvaldniekam lai noteiktu atkarības un ļautu organizēt koda izpildi, gradlew un Podfile failos norādot pieskārienu un sistēmas komandas.
En Snyk un WhiteSource atrada arī ievainojamību, kas saistīta ar palaišanas sistēmas komandām organizācija, kas parsēja Dockerfile (piemēram, Snyk, izmantojot Dockefile, jūs varētu aizstāt utilītu ls (/ bin / ls), ko izraisīja skeneris, un programmā WhiteSurce kodu var aizstāt, izmantojot argumentus "atbalss" veidā; pieskarieties / tmp / hacked_whitesource_pip; = 1.0 '«).
Ankorā ievainojamību izraisīja skopeo utilītas izmantošana strādāt ar dokeru attēliem. Darbība tika samazināta līdz veidlapas '»os»: «$ (touch hacked_anchore)»' parametru pievienošanai manifest.json failam, kas tiek aizstāts ar skopeo izsaukšanu bez pienācīgas aizbēgšanas (tika noņemtas tikai rakstzīmes «; & < > ", Bet konstrukcija" $ () ").
Tas pats autors veica pētījumu par ievainojamības noteikšanas efektivitāti nav salāpīts izmantojot drošības skenerus dokeru konteineru daudzumu un viltus pozitīvo rādītāju līmeni.
Bez autora apgalvo, ka vairāki no šiem rīkiem tieši izmantojiet pakotņu pārvaldniekus, lai atrisinātu atkarības. Tas viņus padara īpaši grūti aizstāvēt. Dažiem atkarības pārvaldniekiem ir konfigurācijas faili, kas ļauj iekļaut čaulas kodu.
Pat ja šie vienkāršie veidi tiek kaut kā apstrādāti, šo pakotņu pārvaldnieku izsaukšana neizbēgami nozīmēs naudas izšļakstīšanu. Tas, maigi sakot, neveicina pieteikuma aizstāvību.
Pārbaudes rezultāti 73 attēliem, kuros ir ievainojamība zināms, kā arī efektivitātes novērtējums, lai noteiktu tipisku lietojumu klātbūtni attēlos (nginx, runcis, haproksi, gunicorn, redis, rubīns, mezgls), var konsultēties izveidotās publikācijas ietvaros Šajā saitē.