image

"Beveiligingsonderzoek is onethisch"

zaterdag 24 mei 2008, 10:18 door Redactie, 8 reacties

Draagt beveiligingsonderzoek bij aan veiligere software? volgens beveiligingsexpert Marcus Ranum is dit niet het geval. Ranum gaat de discussie aan met Bruce Schneier, die er wel van overtuigd is dat dit soort onderzoek nodig is. "Onderzoek naar beveiligingslekken is vitaal, omdat het onze nieuwe generatie beveiligingsexperts traint. Natuurlijk zorgen nieuw ontdekte lekken in software en op vliegvelden ervoor dat we risico lopen, maar ze geven ons ook realistische informatie over hoe goed de security daadwerkelijk is. En natuurlijk zijn er meerdere manieren om met kwetsbaarheden om te gaan. Aanvallers zijn echter ook continu op zoek naar lekken, en als we onze systemen willen beveiligen, dan moeten de verdedigers tenminste net zo goed zijn."

Ranum merkt op dat de theorie van Schneier niet klopt, omdat we nog steeds met buffer overflows te maken hebben, ook al werden die 20 jaar geleden al ontdekt. Er is zelfs geen enkele categorie beveiligingsproblemen compleet verdwenen. "Daar gaan voorstanders van beveiligingsonderzoek de mist in. Als je dingen wilt verbeteren, moet je zoeken naar een medicijn voor verschillende problemen, niet voor een enkel geval. Beveiligingsonderzoek bestaat globaal genomen uit: 'zoek een lek in belangrijke software, zodat ik mijn 15 seconden van beroemdheid krijg, een bedankbriefje dat je bij de vendor weet af te persen en een beloning op de markt voor lekken.' Dat heeft niets met onderzoek te maken, dat is gewoon zoeken."

Bijna alle onderzoekers vergeten aan te geven hoe de software beter gemaakt kan worden. En het onderzoek heeft ook een schaduwzijde, want de software is dan niet verbeterd, hij is wel duurder geworden. Door het zoeken naar lekken hebben vendors een nieuwe manier gevonden om klanten aan zich te binden. Wie geen contract voor upgrades afneemt, loopt ernstig risico om gehackt te worden. En de situatie wordt alleen maar erger, want veilig programmeren is nog lang geen gemeengoed en software wordt alsmaar complexer.

Reacties (8)
24-05-2008, 14:45 door Anoniem
(...) en software wordt alsmaar
complexer.
Vraag je af of die toegevoegde
complexiteit ook functioneel is, meerwaarde heeft of niet
gewoon ordinaire bload. Het weglaten van een overdaad aan
overbodige 'features' scheelt natuurlijk enorm aan
potentiële risico's.
24-05-2008, 20:27 door PolaMan
Het grote probleem is dus een groot deel van de oplossing al
meer dan 40 jaar bestaat, en dat figuren zoals Schneier,
ondanks dat ze bekend moeten zijn met die oplossingsrichting
(het OCAP model), het veel belangrijker vinden om zelf
geregeld in de media te komen, dan uit te dragen dat al die
onderzoekers gewoon al decenia lang bezig zijn om het
verkeerde probleem op te lossen.

Het probleem is namelijk niet dat software lek is !

Het probleem is dat (al dan niet lekke) software/code draait
met veel te veel rechten. De oplossing daarvoor is het
structureel en op diverse niveaus toepassen van POLA.

M.a.w Bugtraq en verwanten adreseren het verkeerde probleem,
virusscanners adreseren het verkeerde probleem, en zelfs
anti spam filters adreseren het verkeerde probleem. Het is
allemaal namelijk niets meer dan symptoon bestreiding,
waarbij een groot deel van de zogenaamde EXPERTS niet eens
begrijpen dat ze niet met het echte probleem bezig zijn maar
met randverscheinselen die op zichzelf gezien geen
oplossing hebben.

Het echte probleem: "Hoe komen we tot een migratie pad van
de huidige achterhaalde ambient authority en MAC modellen,
naar een model dat POLA effectief toepast."

POLA is namelijk op zich niet lastig, ware het niet voor de
enorme legacy die we met MS en POSIX achter ons aanslepen.
Zonder een goed doordacht migratie plan komen we nergens,
want opnieuw beginnen lijkt vandaag de dag niet echt meer
een optie, hoewel het technisch gezien absoluut te
prefereren zou zijn.

Gooi MS, OSX, etc allemaal gewoon weg met het idee van 'leuk
geprobeert maar jammer', pomp een berg met geld om hetgeen
OLPC/bitfrost bedacht hebben te implementeren in een
desktop+smartphone OS, en zog dat de grote OCAP namen als
architect aan het traject verbonden zijn. Zal nooit gebeuren
natuurlijk, en dat is voor velen hier ook maar goed ook,
anders hadden jullie over een paar jaar geen droge boterham
meer als security deskundige :-)
25-05-2008, 01:22 door Anoniem
Door PolaMan
(...)
Het probleem is dat (al dan niet lekke) software/code draait
met veel te veel rechten. De oplossing daarvoor is het
structureel en op diverse niveaus toepassen van POLA.
(...)
Strikt genomen, in de reële praktijk, is de werkelijk minste
privilege niet definieerbaar noch af te dwingen. Er bestaat
bij mijn weten geen methode voor de evaluatie van een proces
om de minste hoeveelheid privileges, die zij ooit voor het
uitvoeren van haar taken nodig zal hebben, te kunnen definiëren.

Dit, omdat het niet mogelijk is om alle waarden van
variabelen te weten die het zal verwerken, alle adressen die
het nodig zal hebben, de exacte verwerkingstijd die zij
nodig heeft, enzovoort.

Het beste wat we kunnen doen is het beperken van privileges,
door wat algemeen voorspelbaar niet nodig is uit te sluiten.
Deze beperking vermindert de effectiviteit van
POLP/POMP/POLA/LUA aanzienlijk.

Daarnaast is het bijna nooit mogelijk om van een proces de
toegang tot het geheugen (volledig) te beheersen, evenals de
verwerkingstijd, apparaat modi en I/O-adressen, enzovoort,
met de precisie die nodig is om de juiste minimale set
privileges samen te kunnen stellen, dusdanig dat we er zeker
van kunnen zijn dat van het proces uitgesloten privileges
inderdaad niet nodig zijn. Dit reduceert het nut van
POLP/POMP/POLA/LUA zelfs meer.

Het heeft in deze dus geen zin om bestaande systemen af te
danken, maar het principe in werkbare vorm in bestaande
systemen te integreren. Voorbeelden daarvan zijn onder
andere SELinux en Vista's UAC.
25-05-2008, 21:38 door [Account Verwijderd]
[Verwijderd]
26-05-2008, 02:01 door PolaMan
Anoniem/Jos,

POLA gaat over minimale 'authority', niet over minimale
'permissies'.
Een verwarring die overigens veel plaats heeft, zelfs onder
deskundigen.
Het OCAP model werkt volgens POLA met DELEGEERBARE
permissies, in tegen stelling tot POLP, in tegen stelling
tot MAC mechanismen zoals SELINUX, en in tegenstelling tot UAC.

Een krachtig mechanisme om van POLP tot POLA te komen is een
zogenaamde powerbox, waar o.a. Capdesk, Plash en Polaris op
voortbouwen.

De kracht van POLA t.o.v. ACL,MAC etc is juist het
dynamische karakter, en de mogelijkheid om het op diverse
granulariteitsniveaus toe te passen, tot op het laagste
granulariteitsniveau van componenten in een software product.

Op taal niveau is er o.a. Joe-E wat een enorm goed, maar
zoals veel POLA zaken sterk onder hyped initatief is om van
Java een OCAP tamed subset te maken die volledig POLA
compliant is.

POLA gaat uit van het idee dat bijna alles start met (bijna)
geen rechten, maar dat alle rechten ten aller tijden
delegeerbaar zijn tussen entiteiten die met elkaar kunnen
comuniceren. Wat we met MAC zien is dat het energie stoppen
in het tegen gaan van delegatie contra productief is, en
zorgt voor beheer nachtmeries die uiteindelijk hun doel
voorbij schieten. Helaas zorgt het falen van statische POLP
gecombineerd met mensen die de klok ergens hebben horen
luiden er voor dat er grote groepen mensen zijn die POLA
niet begrijpen als model en denken dat het een soort MAC is,
terwijl het dat dus juist totaal niet is.

Even een lijstje dat de grondregels van pola duidelijk maakt, en duidelijk maakt dat POLA niet het statische gebeuren is waar jullie naar revereren:


* Never give an object more authority than it needs
* No Global Namespaces.
* Minimize Authentication. Focus on Authorization.
* Do Not Prohibit What You Cannot Prevent.
* Embrace Delegation.
* Bundle Authority with Designation.
26-05-2008, 07:32 door SirDice
Ranum merkt op dat de theorie van Schneier niet klopt, omdat we nog steeds met buffer overflows te maken hebben, ook al werden die 20 jaar geleden al ontdekt.
20 jaar geleden werd ook ontdekt wat je er aan kan doen. Gek genoeg zijn er dus nog steeds programmeurs die dit niet begrijpen...

Een stuk software die een fout bevat waar al 20 jaar een oplossing voor is mogen ze van mij aan de schandpaal nagelen.
26-05-2008, 13:24 door Anoniem
<i>Zal nooit gebeuren natuurlijk, en dat is voor velen hier ook maar goed ook,
anders hadden jullie over een paar jaar geen droge boterham meer als
security deskundige :-)</i>

Security is geen techniek maar een proces, en ook met een veiliger OS zal er
ten alle tijde werk zijn voor security professionals, al zullen misschien
sommigen taken veranderen of verdwijnen bij het invoeren van POLA.
27-05-2008, 16:19 door Anoniem
wil ie nou echt zeggen dat omdat er nog altijd stomme fouten
gemaakt worden er maar geen poging meer gedaan moet worden
om deze te vinden? Zodat alleen de blackhats er van weten?

lekker.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.