TL; DR. En ĉi tiu artikolo, ni esploras la hardigajn skemojn, kiuj funkcias ekster la skatolo en kvin popularaj Linukso-distribuoj. Por ĉiu, ni prenis la defaŭltan kernan agordon, ŝarĝis ĉiujn pakaĵojn kaj analizis la sekurecajn skemojn en la kunigitaj binaroj. La distribuoj konsiderataj estas OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 kaj 7, same kiel Ubuntu 14.04, 12.04 kaj 18.04 LTS.
La rezultoj konfirmas, ke eĉ bazaj skemoj kiel stakigado de kanarioj kaj pozicio-sendependa kodo ankoraŭ ne estas adoptitaj de ĉiuj. La situacio estas eĉ pli malbona por kompililoj se temas pri protekti kontraŭ vundeblecoj kiel stack-kolizio, kiu aperis en la spoto en januaro post publikigo. . Sed ne ĉio estas tiel senespera. Signifa nombro da binaroj efektivigas bazajn protektajn metodojn, kaj ilia nombro kreskas de versio al versio.
La revizio montris, ke la plej granda nombro da protektaj metodoj estas efektivigita en Ubuntu 18.04 ĉe la OS kaj aplikaĵaj niveloj, sekvata de Debian 9. Aliflanke, OpenSUSE 12.4, CentOS 7 kaj RHEL 7 ankaŭ efektivigas bazajn protektajn skemojn kaj stakprotekton kontraŭ kolizio. estas uzata eĉ pli vaste kun multe pli densa aro de defaŭltaj pakoj.
Enkonduko
Estas malfacile certigi altkvalitan programaron. Malgraŭ la granda nombro da altnivelaj iloj por statika koda analizo kaj dinamika rultempa analizo, same kiel signifa progreso en la evoluo de kompililoj kaj programlingvoj, moderna programaro ankoraŭ suferas de vundeblecoj, kiuj estas konstante ekspluatataj de atakantoj. La situacio estas eĉ pli malbona en ekosistemoj, kiuj inkluzivas heredan kodon. En tiaj kazoj, ni ne nur alfrontas la eternan problemon trovi eblajn ekspluateblajn erarojn, sed ni ankaŭ estas limigitaj de striktaj postkongruaj kadroj, kiuj ofte postulas nin konservi limigitan, aŭ eĉ pli malbonan, vundeblan aŭ bugan kodon.
Jen kie metodoj por protekti aŭ hardi programojn eniras. Ni ne povas malhelpi iujn tipojn de eraroj, sed ni povas malfaciligi la vivon de la atakanto kaj parte solvi la problemon malhelpante aŭ malhelpante. ekspluatado ĉi tiuj eraroj. Tia protekto estas uzata en ĉiuj modernaj operaciumoj, sed la metodoj multe diferencas en komplekseco, efikeco kaj rendimento: de stakaj kanarioj kaj al plena protekto и . En ĉi tiu artikolo, ni rigardos kiajn protektajn metodojn estas uzataj en la plej popularaj Linuksaj distribuoj en la defaŭlta agordo, kaj ankaŭ ekzamenos la ecojn de la binaroj, kiuj estas distribuitaj per la pakaj administradsistemoj de ĉiu distribuo.
CVE kaj sekureco
Ni ĉiuj vidis artikolojn kun titoloj kiel "La Plej Vundeblaj Aplikoj de la Jaro" aŭ "La Plej Vundeblaj Operaciumoj". Kutime ili provizas statistikojn pri la tuta nombro da rekordoj pri vundeblecoj kiel , akirita de el kaj aliaj fontoj. Poste, ĉi tiuj aplikoj aŭ OS estas vicigitaj laŭ la nombro da CVEoj. Bedaŭrinde, dum CVE-oj estas tre utilaj por spuri problemojn kaj informi vendistojn kaj uzantojn, ili malmulte diras pri la reala sekureco de la programaro.
Ekzemple, konsideru la totalan nombron da CVE-oj dum la lastaj kvar jaroj por la Linukso-kerno kaj la kvin plej popularaj servilaj distribuoj, nome Ubuntu, Debian, Red Hat Enterprise Linux kaj OpenSUSE.
Fig. Xnumx
Kion ĉi tiu grafikaĵo rakontas al ni? Ĉu pli alta nombro da CVE signifas, ke unu distribuo estas pli vundebla ol alia? Neniu Respondo. Ekzemple, en ĉi tiu artikolo vi vidos ke Debian havas pli fortajn sekurecmekanismojn kompare kun, ekzemple, OpenSUSE aŭ RedHat Linukso, kaj tamen Debian havas pli da CVE-oj. Tamen, ili ne nepre signifas malfortigitan sekurecon: eĉ la ĉeesto de CVE ne indikas ĉu vundebleco estas. ekspluatita. Severecpoentoj donas indikon pri kiel probable ekspluato de vundebleco, sed finfine ekspluatebleco dependas peze de la protektoj ĉeestantaj en la tuŝitaj sistemoj kaj la rimedoj kaj kapabloj de la atakantoj. Cetere, la foresto de CVE-raportoj diras nenion pri aliaj neregistrita aŭ nekonata vundeblecoj. La diferenco en CVE povas ŝuldiĝi al faktoroj krom softvarkvalito, inkluzive de la resursoj asignitaj al testado aŭ la grandeco de la uzantbazo. En nia ekzemplo, la pli alta nombro de CVE-oj de Debian povas simple indiki ke Debiano sendas pli da programaro-pakaĵoj.
Kompreneble, la CVE-sistemo provizas utilajn informojn, kiuj ebligas al vi krei taŭgajn protektojn. Ju pli bone ni komprenas la kialojn de fiasko de la programo, des pli facile estas identigi eblajn metodojn de ekspluatado kaj evoluigi taŭgajn mekanismojn. detekto kaj respondo. En Fig. 2 montras la kategoriojn da vundeblecoj por ĉiuj distribuoj dum la lastaj kvar jaroj (). Tuj estas klare, ke la plej multaj CVE-oj falas en la sekvajn kategoriojn: neo de servo (DoS), koda ekzekuto, superfluo, memorkorupto, informforfluo (eksfiltriĝo) kaj privilegia eskalado. Kvankam multaj CVE-oj estas nombritaj plurfoje en malsamaj kategorioj, ĝenerale la samaj aferoj daŭras jaron post jaro. En la sekva parto de la artikolo, ni taksos la uzon de diversaj protektaj skemoj por malhelpi la ekspluaton de ĉi tiuj vundeblecoj.
Fig. Xnumx
taskoj
En ĉi tiu artikolo ni intencas respondi la jenajn demandojn:
- Kio estas la sekureco de malsamaj Linukso-distribuoj? Kiuj protektaj mekanismoj ekzistas en la aplikaĵoj de kerno kaj uzantspaco?
- Kiel la adopto de sekurecaj mekanismoj ŝanĝiĝis laŭlonge de la tempo inter distribuoj?
- Kio estas la averaĝaj dependecoj de pakaĵoj kaj bibliotekoj por ĉiu distribuo?
- Kiuj protektoj estas efektivigitaj por ĉiu duuma?
Elekto de distribuoj
Montriĝas, ke estas malfacile trovi precizajn statistikojn pri distribuaj instalaĵoj, ĉar plejofte la nombro da elŝutoj ne indikas la nombron da realaj instalaĵoj. Tamen, Unikso-similaj variantoj konsistigas la plimulton de servilsistemoj (sur retserviloj 69,2%, de W3techs kaj aliaj fontoj), kaj ilia parto konstante kreskas. Tiel, por nia esplorado ni koncentriĝis pri distribuoj disponeblaj el la skatolo en la platformo . Aparte, ni elektis la sekvan OS:
Distribuo/versio
La kerno
Konstruu
OpenSUSE 12.4
4.12.14-95.3-defaŭlta
#1 SMP mer Dec 5 06:00:48 UTC 2018 (63a8d29)
Debian 9 (streĉado)
4.9.0-8-amd64
numero 1 SMP Debian 4.9.130-2 (2018-10-27)
CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP Tue Jan 15 17:07:28 UTC 2019
CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP Ven Feb 1 14:54:57 UTC 2019
Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP mer Nov 21 15:08:21 EST 2018
Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Thu Nov 15 17:36:42 UTC 2018
Ubuntu 14.04 (Fida Tahr)
4.4.0–140-genera
#166~14.04.1-Ubuntu SMP Sat Nov 17 01:52:43 UTC 20...
Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP ven 7 Dec 09:59:47 UTC 2018
Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27-Ubuntu SMP Thu Dec 6 18:27:01 UTC 2018
Tablo 1
Анализ
Ni studu la defaŭltan kernan agordon, same kiel la ecojn de pakaĵoj disponeblaj per la pakaĵadministrilo de ĉiu distribuo el la skatolo. Tiel, ni nur konsideras pakaĵojn de la defaŭltaj speguloj de ĉiu distribuo, ignorante pakaĵojn de malstabilaj deponejoj (kiel ekzemple Debianaj "testantaj" speguloj) kaj triajn pakaĵojn (kiel Nvidia-pakaĵojn de normaj speguloj). Aldone, ni ne konsideras kutimajn kernkompilojn aŭ sekurec-harditajn agordojn.
Kernel-Agorda Analizo
Ni aplikis analizan skripton bazitan sur . Ni rigardu la eksterordinarajn protektajn parametrojn de la nomitaj distribuoj kaj komparu ilin kun la listo de (KSPP). Por ĉiu opcio de agordo, Tabelo 2 priskribas la deziratan agordon: la markobutono estas por distribuoj kiuj konformas al la rekomendoj de KSSP (vidu la sekvan por klarigo de terminoj). ; En estontaj artikoloj ni klarigos kiom multaj el ĉi tiuj sekurecaj metodoj estiĝis kaj kiel pirati sistemon en ilia foresto).
Ĝenerale, la novaj kernoj havas pli striktajn agordojn el la skatolo. Ekzemple, CentOS 6.10 kaj RHEL 6.10 sur la 2.6.32 kerno malhavas la plej multajn el la kritikaj funkcioj efektivigitaj en pli novaj kernoj kiel ekzemple , striktaj RWX-permesoj, adres-hazardigo aŭ copy2usr-protekto. Oni devas rimarki, ke multaj el la agordaj elektoj en la tabelo ne haveblas en pli malnovaj versioj de la kerno kaj ne estas aplikeblaj en la realeco - tio ankoraŭ estas indikita en la tabelo kiel manko de taŭga protekto. Same, se agorda opcio ne ĉeestas en antaŭfiksita versio, kaj sekureco postulas ke tiu opcio estu malŝaltita, tio estas konsiderita akceptebla agordo.
Alia punkto por konsideri dum interpretado de la rezultoj: iuj kernaj agordoj, kiuj pliigas la ataksurfacon, ankaŭ povas esti uzataj por sekureco. Tiaj ekzemploj inkluzivas subprobes kaj kprobes, kernmodulojn, kaj BPF/eBPF. Nia rekomendo estas uzi la ĉi-suprajn mekanismojn por provizi realan protekton, ĉar ili estas ne bagatela uzi kaj ilia ekspluatado supozas, ke malicaj agantoj jam establis piedtenejon en la sistemo. Sed se ĉi tiuj opcioj estas ebligitaj, la sistemadministranto devas aktive monitori por misuzo.
Rigardante plu la enskribojn en Tabelo 2, ni vidas, ke modernaj kernoj provizas plurajn eblojn por protekti kontraŭ ekspluatado de vundeblecoj kiel informforfluo kaj stak/saksuperfluoj. Tamen, ni rimarkas, ke eĉ la plej lastatempaj popularaj distribuoj ankoraŭ ne efektivigis pli kompleksan protekton (ekzemple, kun flikoj ) aŭ moderna protekto kontraŭ kodaj reuzaj atakoj (ekz. ). Por plimalbonigi la aferojn, eĉ ĉi tiuj pli altnivelaj defendoj ne protektas kontraŭ la tuta gamo da atakoj. Tial, estas kritike por sistemadministrantoj kompletigi inteligentajn agordojn per solvoj kiuj ofertas rultempajn ekspluatdetekton kaj preventadon.
Analizo de aplikaĵo
Ne surprize, malsamaj distribuoj havas malsamajn pakaĵkarakterizaĵojn, kompilopciojn, bibliotekdependecojn, ktp. Diferencoj ekzistas eĉ por distribuoj kaj pakaĵoj kun malgranda nombro da dependecoj (ekzemple, korutiloj en Ubuntu aŭ Debiano). Por taksi la diferencojn, ni elŝutis ĉiujn disponeblajn pakaĵojn, ĉerpis ilian enhavon kaj analizis la binarojn kaj dependecojn. Por ĉiu pakaĵo, ni spuris la aliajn pakaĵojn de kiuj ĝi dependas, kaj por ĉiu duuma, ni spuris ĝiajn dependecojn. En ĉi tiu sekcio ni mallonge resumas la konkludojn.
distribuoj
Entute ni elŝutis 361 556 pakaĵojn por ĉiuj distribuoj, ĉerpante nur pakaĵojn el defaŭltaj speguloj. Ni ignoris pakaĵojn sen ELF-ruleblaj, kiel fontoj, tiparoj, ktp. Post filtrado restis 129 569 pakaĵoj, enhavantaj entute 584 457 binarojn. La distribuado de pakaĵoj kaj dosieroj tra distribuoj estas montrita en Fig. 3.
Fig. Xnumx
Vi eble rimarkos, ke ju pli moderna la distribuo, des pli da pakaĵoj kaj binaroj ĝi enhavas, kio estas logika. Tamen, Ubuntu kaj Debian-pakaĵoj inkluzivas multe pli da binaroj (kaj ruleblaj kaj dinamikaj moduloj kaj bibliotekoj) ol CentOS, SUSE kaj RHEL, kiu eble influas la ataksurfacon de Ubuntu kaj Debian (oni devas rimarki, ke la nombroj reflektas ĉiujn binarojn de ĉiuj versioj). pakaĵo, tio estas, iuj dosieroj estas plurfoje analizitaj). Ĉi tio estas precipe grava kiam vi konsideras dependecojn inter pakaĵoj. Tiel, vundebleco en ununura pakaĵbinaro povas influi multajn partojn de la ekosistemo, same kiel vundebla biblioteko povas influi ĉiujn binarojn kiuj importas ĝin. Kiel deirpunkto, ni rigardu la distribuadon de la nombro da dependecoj inter pakaĵoj en malsamaj operaciumoj:
Fig. Xnumx
En preskaŭ ĉiuj distribuoj, 60% de pakaĵoj havas almenaŭ 10 dependecojn. Krome, kelkaj pakaĵoj havas signife pli grandan nombron da dependecoj (pli ol 100). La sama validas por inversaj pakaj dependecoj: kiel atendite, kelkaj pakaĵoj estas uzataj de multaj aliaj pakaĵoj en la distribuo, do vundeblecoj en tiuj elektitaj malmultaj estas alta risko. Kiel ekzemplo, la sekva tabelo listigas la 20 pakaĵojn kun la maksimuma nombro da inversaj dependecoj en SLES, Centos 7, Debian 9 kaj Ubuntu 18.04 (ĉiu ĉelo indikas la pakaĵon kaj la nombron da inversaj dependecoj).
Tablo 3
Interesa fakto. Kvankam ĉiuj OS-oj analizitaj estas konstruitaj por la arkitekturo x86_64, kaj la plej multaj pakaĵoj havas la arkitekturon difinitan kiel x86_64 kaj x86, pakaĵoj ofte enhavas binarojn por aliaj arkitekturoj, kiel montrite en Figuro 5. XNUMX.
Fig. Xnumx
En la sekva sekcio, ni enprofundiĝos en la karakterizaĵojn de la analizitaj binaroj.
Binaraj dosieraj protektostatistikoj
Ĉe la absoluta minimumo, vi devas esplori bazan aron de sekurecaj elektoj por viaj ekzistantaj binaroj. Pluraj Linukso-distribuoj venas kun skriptoj, kiuj plenumas tiajn kontrolojn. Ekzemple, Debian/Ubuntu havas tian skripton. Jen ekzemplo de lia laboro:
$ hardening-check $(which docker)
/usr/bin/docker:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: no, only unprotected functions found!
Read-only relocations: yes
Immediate binding: yesLa skripto kontrolas kvin :
- Position Independent Executable (PIE): Indikas ĉu la tekstsekcio de programo povas esti movita en memoro por atingi hazardigon se ASLR estas ebligita en la kerno.
- Stack Protected: Ĉu stakaj kanarioj estas ebligitaj por protekti kontraŭ stakaj kolizio-atakoj.
- Fortikigi Fonton: ĉu nesekuraj funkcioj (ekzemple, strcpy) estas anstataŭigitaj per siaj pli sekuraj ekvivalentoj, kaj vokoj kontrolitaj ĉe rultempo estas anstataŭigitaj per siaj nekontrolitaj ekvivalentoj (ekzemple, memcpy anstataŭe de __memcpy_chk).
- Nurlegeblaj translokiĝoj (RELRO): Ĉu translokigaj tabeleniroj estas markitaj nurlegeblaj se ili estas ekigitaj antaŭ ol ekzekuto komenciĝas.
- Tuja ligado: Ĉu la rultempa ligilo permesas ĉiujn movojn antaŭ ol programekzekuto komenciĝas (ĉi tio estas ekvivalenta al plena RELRO).
Ĉu la supraj mekanismoj sufiĉas? Bedaŭrinde ne. Estas konataj manieroj preteriri ĉiujn ĉi-suprajn defendojn, sed ju pli malmola la defendo, des pli alta la stango por la atakanto. Ekzemple, pli malfacile apliki se PIE kaj tuja ligado validas. Same, plena ASLR postulas plian laboron por krei funkciantan ekspluatadon. Tamen, sofistikaj atakantoj jam pretas renkonti tiajn protektojn: ilia foresto esence akcelos la hakon. Tial estas esence, ke ĉi tiuj mezuroj estu konsiderataj necesaj minimumo.
Ni volis studi kiom da binaraj dosieroj en la koncernaj distribuoj estas protektitaj per ĉi tiuj kaj tri aliaj metodoj:
- Neefektivebla bito () malhelpas ekzekuton en iu ajn regiono kiu ne devus esti plenumebla, kiel ekzemple la stakmaso, ktp.
- indikas la ekzekutvojon uzatan de la dinamika ŝargilo por trovi kongruajn bibliotekojn. La unua estas deviga por iu ajn moderna sistemo: ĝia foresto permesas al atakantoj arbitre skribi la utilan ŝarĝon en memoron kaj ekzekuti ĝin tia. Por la dua, malĝustaj ekzekutvojagordoj helpas en enkonduko de nefidinda kodo kiu povas konduki al kelkaj problemoj (ekz. Kaj ).
- Staka kolizioprotekto disponigas protekton kontraŭ atakoj kiuj igas la stakon interkovri aliajn areojn de memoro (kiel ekzemple la amaso). Donita lastatempaj heroaĵoj misuzado , ni sentis, ke estas konvene inkluzivi ĉi tiun mekanismon en nia datumaro.
Do, sen pli da diro, ni iru al la nombroj. Tabeloj 4 kaj 5 enhavas resumon de la analizo de ruleblaj dosieroj kaj bibliotekoj de diversaj distribuoj, respektive.
- Kiel vi povas vidi, NX-protekto estas efektivigita ĉie, kun maloftaj esceptoj. Aparte, oni povas rimarki ĝian iomete pli malaltan uzon en Ubuntu kaj Debian-distribuoj kompare kun CentOS, RHEL kaj OpenSUSE.
- Multloke mankas stakaj kanarioj, precipe en distribuoj kun pli malnovaj kernoj. Iom da progreso estas vidata en la plej novaj distribuoj de Centos, RHEL, Debian kaj Ubuntu.
- Kun la escepto de Debian kaj Ubuntu 18.04, la plej multaj distribuoj havas malbonan PIE-subtenon.
- Protekto pri stakkolizio estas malforta en OpenSUSE, Centos 7 kaj RHEL 7, kaj preskaŭ neekzistanta en aliaj.
- Ĉiuj distribuoj kun modernaj kernoj havas iom da subteno por RELRO, kun Ubuntu 18.04 gvidanta la vojon kaj Debian venanta en la dua.
Kiel jam menciite, la metrikoj en ĉi tiu tabelo estas la mezumo por ĉiuj versioj de la binara dosiero. Se vi rigardas nur la plej novajn versiojn de dosieroj, la nombroj estos malsamaj (ekzemple, vidu ). Plie, plej multaj distribuoj tipe nur testas la sekurecon de kelkaj funkcioj en la binaro dum kalkulado de statistiko, sed nia analizo montras la veran procenton de funkcioj, kiuj estas malmoligitaj. Tial, se 5 el 50 funkcioj estas protektitaj en duuma, ni donos al ĝi poentaron de 0,1, kio respondas al 10% de la funkcioj plifortigitaj.
Tablo 4. Sekurecaj trajtoj por la plenumeblaj dosieroj montritaj en Fig. 3 (efektivigo de koncernaj funkcioj kiel procento de la totala nombro de ruleblaj dosieroj)
Tabelo 5. Sekurecaj karakterizaĵoj por la bibliotekoj montritaj en Fig. 3 (efektivigo de koncernaj funkcioj kiel procento de la totala nombro de bibliotekoj)
Ĉu do estas progreso? Nepre ekzistas: ĉi tio videblas el la statistiko por individuaj distribuoj (ekzemple, ), same kiel de la supraj tabeloj. Kiel ekzemplo en Fig. Figuro 6 montras la efektivigon de protektaj mekanismoj en tri sinsekvaj distribuoj de Ubuntu LTS 5 (ni preterlasis statistikojn pri protekto de stakaj kolizioj). Ni rimarkas, ke de versio al versio pli kaj pli da dosieroj subtenas stakkanariojn, kaj ankaŭ pli kaj pli da binaroj estas sendataj kun plena RELRO-protekto.
Fig. Xnumx
Bedaŭrinde, kelkaj ruleblaj dosieroj en malsamaj distribuoj ankoraŭ ne havas iujn el ĉi-supraj protektoj. Ekzemple, rigardante Ubuntu 18.04, vi rimarkos la ngetty-binaron (anstataŭaĵo de getty), same kiel la mksh kaj lksh-ŝelojn, la picolisp-interpretilon, la nvidia-cuda-toolkit-pakaĵojn (populara pako por GPU-akcelitaj aplikoj). kiel maŝinlernadkadroj), kaj klibc -utils. Same, la mandos-kliento binaro (administra ilo kiu permesas vin aŭtomate rekomenci maŝinojn kun ĉifritaj dosiersistemoj) same kiel rsh-redone-client (reefektivigo de rsh kaj rlogin) ekspediĝas sen NX-protekto, kvankam ili havas SUID-rajtojn: (. Ankaŭ, Pluraj suid binaroj mankas baza protekto kiel stack canaries (ekzemple, la Xorg.wrap duuma de la Xorg pako).
Resumo kaj Finaj Rimarkoj
En ĉi tiu artikolo, ni emfazis plurajn sekurecajn funkciojn de modernaj Linukso-distribuoj. La analizo montris, ke la plej nova Ubuntu LTS-distribuo (18.04) efektivigas, averaĝe, la plej fortan OS kaj aplikaĵnivelan protekton inter distribuoj kun relative novaj kernoj, kiel Ubuntu 14.04, 12.04 kaj Debian 9. Tamen, la ekzamenitaj distribuoj CentOS, RHEL kaj OpenSUSE en nia aro defaŭlte ili produktas pli densan aron da pakaĵoj, kaj en la plej novaj versioj (CentOS kaj RHEL) ili havas pli altan procenton de staka kolizioprotekto kompare kun Debian-bazitaj konkurantoj (Debian kaj Ubuntu). Komparante CentOS kaj RedHat-versiojn, ni rimarkas grandajn plibonigojn en la efektivigo de stakaj kanarioj kaj RELRO de versioj 6 ĝis 7, sed averaĝe CentOS havas pli da funkcioj efektivigitaj ol RHEL. Ĝenerale, ĉiuj distribuoj devus atenti specialan al PIE-protekto, kiu, kun la escepto de Debian 9 kaj Ubuntu 18.04, estas efektivigita en malpli ol 10% de la binaroj en nia datumaro.
Fine, oni devas rimarki, ke kvankam ni faris la esploradon permane, ekzistas multaj sekurecaj iloj disponeblaj (ekz. , , ), kiuj faras analizon kaj helpas eviti nesekurajn agordojn. Bedaŭrinde, eĉ forta protekto en raciaj agordoj ne garantias la foreston de ekspluatoj. Tial ni firme kredas, ke estas esenca certigi , temigante padronojn de ekspluatado kaj malhelpante ilin.
fonto: www.habr.com