Valóban biztonságosabb a nyílt forráskódú szoftver?

A nyílt forráskódú szoftvereket biztonságosabbnak tartják, mint a védett szoftvereket – de ez tényleg igaz? Végezzük a gyakorlati ellenőrzést.

kijelző

Legyen őszinte: pontosan tudja, mit csinál az Ön által használt böngésző? A szoftverfejlesztéssel kapcsolatos ismeretei mellett ez elsősorban attól függ, hogy éppen melyik böngészőt használja. Mert: Ha nyílt forráskódú böngészőt, például Mozilla Firefoxot használ, megtekintheti a forráskódot, és részletesen ellenőrizheti, hogy mi történik például egy webhely meghívásakor. A zárt böngészők, például a Microsoft Edge vagy az Apple Safari nem kínálják ezt a lehetőséget. Valójában csak a nyílt forráskódú programokkal lehet igazán tudni, mi van benne.

  • Az átláthatóság mint biztonsági koncepció
  • Nincs biztonsági garancia
  • vegyes számítás
  • bizalmi kérdések

Az átláthatóság mint biztonsági koncepció

Az az elképzelés, hogy a mindenki által megtekinthető forráskód nagyobb biztonságot nyújthat, első pillantásra paradoxnak tűnik: a támadók nem tudták ellenőrizni a kódot és kihasználni a biztonsági réseket? Igen, megtehetik, és továbbra is így tesznek. De egy aktív fejlesztői közösség ugyanolyan gyorsan tudja biztosítani a megfelelő problémák megoldását. Mindenekelőtt a biztonság szempontjából releváns eszközök, például a titkosító programok profitálnak ebből a koncepcióból. Az ún biztonsági auditok a nagy nyílt forráskódú programokat ellenőrzik, hogy vannak-e problémák – ez a folyamat zárt forráskódú programokkal nem lehetséges a forráskód hiánya miatt.

Ha egy program forráskódja látható, mindig ellenőrizheti, hogy pontosan mit csinál és hogyan működik. ×

A nyílt forráskódú koncepció potenciális előnye, hogy a kódot más fejlesztőcsapatok is felvehetik, és önállóan továbbfejleszthetik – ezt "Villa". Ez történt a 2014-ben leállított titkosító eszközzel TrueCrypt. Miután az eredeti programot a biztonság hiánya miatt már nem fejlesztették, egy másik csapat VeraCrypt néven folytatta a programbázist (igazából a VeraCrypt fejlesztése még a TC vége előtt elkezdődött, de a nyílt forráskódú ötlet nélkül ez nem lehetséges ). A VeraCrypt példát is mutat a sikeres auditra: a forráskódban talált biztonsági hiányosságokat a fejlesztői közösség gyorsan bezárta.

Nincs biztonsági garancia

Akár nyílt, akár zárt forráskódú: mindkét koncepciónak vannak támogatói, akik a biztonságot propagálják. Azonban egyik sem tud garanciát nyújtani a tökéletes biztonságra.
Talán a "legegyszerűbb" példát arra, hogy a zárt kód nem eredményez automatikusan nagyobb biztonságot a Microsoft Windows operációs rendszerével. Hónapról hónapra jönnek az újak, nem ritka komoly biztonsági rések a Windowsban megjelenni. A Microsoft erre a Patch kedd, ahol a redmondi fejlesztők havi rendszerességgel terjesztik a javításokat. A Windows-felhasználóknak támaszkodniuk kell a Windows-gyártók jó munkájára – például a Linuxszal ellentétben a szenvedélyes fejlesztőknek nincs esélyük arra, hogy maguk javítsák ki a Windows kódhibáit. Ettől függetlenül soha nem lehet biztos abban, hogy a Windows mit csinál a háttérben. Nem utolsósorban a Windows 10 és a még mindig nem teljesen átlátható adatgyűjtés miatt ez a nem nyitott szoftverek nagy hátránya. Természetesen ugyanez nem a Microsoft kizárólagos problémája, hanem bármely zárt forráskódú programra alkalmazható.

Felhasználóként a Microsoftra kell támaszkodnia, hogy megbízhatóan bezárja a Windows hiányosságait. ×

Az ellenkező példát kínálják a nyílt forráskódú rendszerek, például a Linux vagy a BSD. Elméletileg minden fejlesztő saját maga is bezárhatja a biztonsági hiányosságokat – természetesen a megfelelő változtatásokat a "hivatalos" kódban is szerepeltetni kell. A tapasztalat azt mutatja, hogy a Linux kernel hibáit és biztonsági hiányosságait gyorsan kiküszöböli a fejlesztői közösség Rögzített. De ez még csak a csata fele: Ha a javítások nem jutnak el a felhasználóhoz, annak nem sok haszna van. Itt is egy jelentős operációs rendszer kínál negatív példát, mégpedig az Android. Okostelefonok millióin futnak a Google Linux-alapú mobilrendszerének teljesen elavult verziói. Nemcsak a javítatlan Linux biztonsági rések, hanem a Google hiányzó biztonsági koncepciói is problémát jelentenek. Elvégre legalább elméletileg megvan a lehetőség új Android-verziók létrehozására az Android nyílt forráskódú projektjén keresztül – az olyan fejlesztői közösségek, mint az XDA-Devs, úgynevezett egyedi ROM-okkal ugranak be itt a törésbe –, de a ráfordítás óriási, és a az eredmények nem mindig kielégítőek. Ráadásul még nyílt forráskóddal sem lehet biztos abban, hogy a belőle generált programok valóban ebből a forráskódból származnak, és nem manipulálták őket időközben.

Az Android nyílt forráskódú, de a biztonság nem garantált. ×

vegyes számítás

A nagy, szabadalmaztatott programok gyakran nyílt forráskódú projekteket is integrálnak bizonyos funkciókhoz. Példa erre a népszerű okostelefonos WhatsApp üzenetküldő. Míg a WhatsApp alapkódja le van zárva, a 2014-ben bevezetett kód alapú Végpontok közötti titkosítás az Open Whisper Systems nyílt forráskódú szolgáltatásaiban. Valójában az alternatív üzenetküldő jelben is használt üzenetkódolást eddig figyelembe vették feltörhetetlen, bár az alkalmazott protokollok nyitottak az ellenőrzésre. Hogy pontosan mit csinál a Facebook által 2014-ben megvásárolt WhatsApp az üzenetek titkosításán túl, azt nem könnyű kideríteni – legalábbis addig, amíg a WhatsApp gyártói nem fedik fel az alkalmazás kódját.

A védett WhatsApp titkosítása nyílt forráskódú protokollokon alapul. × Kijelző

Függetlenül attól, hogy nyílt forráskódú vagy sem: az, hogy egy program mennyire biztonságos és megbízható, mindig attól függ, hogy ki a felelős a fejlesztésért. Egy olyan biztonsági szempontból releváns programra, amelyen évek óta nem dolgoztak, legalább szkepticizmussal kell tekinteni, még akkor is, ha nyílt forráskóddal rendelkezik. Ha viszont a kód megfelelően van dokumentálva, sok programozó foglalkozik a további fejlesztéssel, akkor legalább nagy az esélye annak, hogy egy biztonságos nyílt forráskódú projekt áll előtted.

bizalmi kérdések

ragaszkodunk: Miután a forráskódot ellenőrizték, és a talált biztonsági hiányosságokat a fejlesztői közösség gyorsan kijavította, az aktív nyílt forráskódú projektek teljesen biztonságosak. vagy? Sajnos nem, legalábbis nem korlátozások nélkül. Ha letölt egy "kész" nyílt forráskódú programot, bíznia kell abban, hogy a tiszta forráskódot nem manipulálták. Egy példa: Ha a fent említett Firefoxot esetleg kétes forrásból tölti le, akkor nagyon valószínű, hogy valaki rosszindulatú programot integrált a kódba. Hiszen a forráskódot használat előtt kész programmá kell konvertálni, azaz fordítóval le kell fordítani. Mivel nem tudja könnyen megtekinteni az eredeti forráskódot.

Még ha nyílt forráskódot ír is, meg kell tudni bízni a forrásban. ×

Tehát a megoldás a szkeptikusok számára a következőket jelentheti: Állítsd össze magad. Csak töltse le a bevált tiszta forráskódot, futtassa a választott fordítón keresztül, és máris van egy biztonságos nyílt forráskódú program. De itt is van egy "de": Természetesen a fordítóban is bízni kell. A hátteret az ún Ken Thompson Hack. Az 1980-as években az informatikus bebizonyította, hogy egy sérült fordító veszélyes hátsó ajtót tud telepíteni egy tiszta forráskóddal rendelkező programba – bár ebből semmi nem látszik a fordító forráskódjában. Elméletileg nem csak a 100%-os biztonság kedvéért kellene lefordítani a programot, hanem a hozzá használt fordítót is meg kell írni, persze teljesen "tiszta" rendszerrel. Ezeket a gondolatokat tetszés szerint lehetne folytatni, még akkor is, ha most vannak tesztkoncepciók a Ken Thompson hack ellen.
Igaz, lassan eljutunk arra a szintre, ahol a biztonság gondolata már-már a paranoiával határos. A gyakorlatban azonban kiderül, hogy A fekete-fehér gondolkodás nyílt vagy zárt forráskódú szoftverekkel kapcsolatban nem a legjobb ötlet van. A nyílt forráskód sem biztonságosabb, sem a szabadalmaztatott szoftverek nem ködösek. Az igazság, mint oly sokszor, valahol középen van.

Bővebben a témáról: