Jouw reacties is ook erg simpel
Software producenten moeten de fouten fixen En de oplossing delen.
Securety patches zijn taken van de OS. atans de Meeste besturings systemen/Distro's hebben dit.
Ik snap jouw redenering niet helemaal. Ja je hebt gelijk in het feit dat security moet worden opgelost in het OS. Maar dit geldt alleen voor het OS gedeelte. We spreken hier echter niet over een OS probleem maar over een Applicatie probleem. Dit is een totaal andere tier binnen het begrip desktop.
Een systeem is opgebouwd uit een aantal componenten te weten:
- Operating systeem.
- Applicaties.
Hiernaast heb je soms een backoffice tier welke behoord tot je infrastructuur. Simpele voorbeelden zijn:
- Groupware.
- File sharing.
- Database.
- Applicatie servers.
Ook deze systemen bestaan uit meerdere lagen zoals een desktop waarbij Unix (achtigen) een wat mooiere scheiding hebben dan Windows systemen. Maar ook hier geldt:
- Operating systeem.
- Applicaties/Services.
Binnen deze entiteiten (server, werkplek) zit nog een stukje security en controles. Je zou in theorie de hele boel uit kunnen kleden volgens het ISO model met haar 7 lagen en hiernaast de OS en Applicatie tiers kunnen leggen.
Zo heeft het OS inderdaad de verantwoording dat deze controle's moet uitvoeren op data die haar wordt aangeboden. Bijvoorbeeld een malformed datachunk die naar de IP stack wordt gezonden of naar de hardware abstractie laag. Maar in dit geval zit het totaal anders.
De reden dat dit totaal anders zit en geen verantwoordelijkheid rust bij het OS is als volgt: Op disk staat ergens een blok data, te identificeren als een Binary/TIFF bestand. Dit is gewoon een stream aan bytes. De interpretatie van deze bytes zit op applicatieniveau, voor het OS is het gewoon een stream binaire data, zonder enige structuur. De structuur wordt bepaald door de applicatie. Onder Windows zie je in explorer dat het een TIFF bestand is, maar dat komt omdat de Explorer ook een applicatie is die toevallig de link kan leggen tussen extensie en het soort data wat met deze extensie wordt beschreven. Een TIFF bestand hoeft tenslotte geen TIFF te heten maar mag ook JPG heten of TXT. Het afhandelen geschied echter in de applicatie en daar heeft het OS geen weet van. De applicatie leest dus het bestand in, het OS geeft de bytes terug als een rauwe chunk data. Het OS mag dan ook totaal niet ingrijpen in de vraag van de applicatie, manipulatie van de data en checks liggen volledig bij de applicatie die de data moet verwerken. Dat deze applicatie er niet goed mee omgaat en er een eventuele security breach is is het probleem van deze applicatie. Het enige wat mag gebeuren is een virusscanner die tussen applicatie en OS in zit, deze zou mogen ingrijpen, maar geen data mogen manipuleren.
Dit soort problemen zijn dus altijd Applicatie problemen en de verantwoording ligt dus altijd bij de schrijver van de applicatie. Hierbij is echter één uitzondering te maken en dat is wanneer het fout gaat bij een API die integraal onderdeel uitmaakt van het OS, bijvoorbeeld een hypotetische OS API call ConvertTag(*Compressed data, *Uncompressed data). Wanneer deze call de mist in zou gaan dan is het een OS probleem, helaas is dit bij deze bug niet het geval en praten we gewoon over beroerd programmeren met verkeerde checks. Neem bijvoorbeeld de simpele pseudocode:
B= Buffersize
Buffer= GetMem(Buffersize)
P= 0
Herhaal
X=Lees volgende byte
U=Unpack byte (variabele lengte)
Buffer[P]= U
P=P+Lengte(U)
Tot Laatste byte is gelezen
Bovenstaande code is vragen om probleem. Onderstaande code echter:
Buffer= GetMem(Buffersize)
P= 0
Herhaal
X=Lees volgende byte
U=Unpack byte (variabele lengte)
Als P+Lengte(U)>(BufferSize) dan Exceptie "Bufferoverflow"
Buffer[P]= U
P=P+Lengte(U)
Tot Laatste byte is gelezen