Recyclen van code maakt software kwetsbaar
Afgelopen woensdag werd er een zeer ernstig lek in de software van Symantec ontdekt. Door een fout in het bestand Dec2Rar.dll kon een aanvaller, door de gebruiker een .RAR bestand te laten scannen, de computer overnemen. Dit bestand wordt door bijna alle Symantec produkten gebruikt, waardoor de security aanbieder een waarschuwing voor maar liefst 63 produkten moest afgeven. Zelden kwam het voor dat één lek zoveel programma's wist te treffen, wat het gevaar van het hergebruik van code laat zien. Vooral bij grote software aanbieders, die vaak allerlei versies en varianten van dezelfde software aanbieden, is dit een risico. Onze stelling luidt derhalve: Recyclen van code maakt software kwetsbaar
ms03-026 (bron voor blaster) nt4 t/m 2003 was daar gevoelig voor.
natuurlijk wel aanzienlijk groter. Afwegend tegen een systeem waarbij je
alles van de grond opnieuw opbouwd, met de bijbehorende kosten en
eigen problemen, lijkt het mij toch een fijn idee wanneer een bepaald
stukje code veelvuldig gebruikt wordt.
Het is ook sneller en makkelijker te fixen dan.
een klap 63 afzonderlijke programma's...
Bekijk het van de andere kant: Als die 63 verschillende programma's
allemaal zelf een implementatie hadden moeten schrijven, is de kans op
verschillende fouten vele malen groter dan bij het gebruik van een en
dezelfde bibliotheek.
Ik ben het dus niet eens met de stelling.
is het 1 fix, en omdat de code veel vaker gebruikt en
bekeken wordt is hij dus ook veel beter getest en vrij zeker
veiliger dan als alles elke keer opnieuw wordt gemaakt.
Alleen als de code steeds gecopypaste wordt, dan moeten alle
programma's geupdate worden.
1 lek liet al zien dat het veel erger kan, te weten zlib.
code zijn vaak prima te herbruiken. Wel reviewen voor je ze
opnieuw maakt. Bij het schrijven van nieuwe code maak je
weer nieuwe fouten. Bij het reviewen kan je controleren of
de code werkelijk aan de eisen voldoet, dat kost aanzienlijk
minder tijd dan het wiel opnieuw uitvinden.
Het is uiteraard niet populair: programmeurs hebben zo
minder werk, detacheringsbedrijven derven inkomsten en
managers denken dat ze tweedehands programma's hebben.
hogere programmeertaal maakt gebruik van gedeelde low-level
subroutines.
Als je geen code wilt recyclen dan moet je uitsluitend
programmeren in assembler, en zelfs dan maak je nog gebruik
van shared code die word geleverd door de bios of het
operating systeem.
Conclusie: de bovenstaande stelling is overbodig.
Integendeel, recyclen maakt software beter. Goede stukken
code zijn vaak prima te herbruiken. Wel reviewen voor je ze
opnieuw maakt. Bij het schrijven van nieuwe code maak je
weer nieuwe fouten. Bij het reviewen kan je controleren of
de code werkelijk aan de eisen voldoet, dat kost aanzienlijk
minder tijd dan het wiel opnieuw uitvinden.
Het is uiteraard niet populair: programmeurs hebben zo
minder werk, detacheringsbedrijven derven inkomsten en
managers denken dat ze tweedehands programma's hebben.
Het Windows platform is waarschijnlijk het minst vernieuwende platform en dus bestaat deze grotendeels uit 2ehands hergebruikte code....
Door Anoniem op vrijdag 23 december 2005 11:08
Slechte code recyclen maakt software kwetsbaar. Neem als voorbeeld
ms03-026 (bron voor blaster) nt4 t/m 2003 was daar gevoelig voor.
- Q -
Hoewel hergebruik inderdaad tot gevolg heeft dat elke fout
een grotere impact en (financieele) consequenties heeft, zou
juist dat gegeven moeten rechtvaardigen dat
onwikkelaars meer tijd aan de ontwikkeling besteden (en
bijv. door anderen laten reviewen) en dat het product
intensiever getest wordt. Door bijvoorbeeld de bedrijven in
te huren die nu deze bugs vinden en publiceren,
vanzelfsprekend onder een NDA (Non-Disclosure Agreement).
Behalve een beetje gezichtsverlies is er echter geen enkele
reden voor software producenten om actief naar fouten te
zoeken die onder normale omstandigheden niet optreden; dat
kost alleen maar tijd en geld. En de (meetbare) praktijk is
kennelijk dat klanten na dergelijke blunders niet naar de
concurrent vertrekken, mogelijk omdat die geen haar beter is.
De iX (nu ook in het Nederlands, is een zusterblad van c't)
nr 1. van 2006 vermeldt dat Bruce Schneier op de RSA
conferentie in Wenen (18-19 oktober j.l.), ervoor pleitte
dat software producenten wettelijk (dus financieel)
aansprakelijk gesteld moeten kunnen worden voor security
fouten in hun producten. Ik ben het met hem eens, met
name waar het om producten gaat die je zouden moeten
beschermen, en die daarom vaak in de "first line of defense"
draaien.
Erik van Straten
keer kan gebruiken. Echter kan het ook voorkomen dat het
samenvoegen van die code voor problemen kan zorgen. Het zal
dus altijd opletten blijven met "gebruikte" code.
beperkingen van ontwikkelaars om de kwetsbaarheden op te
sporen en te elimineren.
software gaat niet op. OUDE fouten worden interessanter en
makkelijker te exploiten. Vind een bug in Windows 1.0 en
grote kans dat je in Vista nog steeds die vulnerability
tegenkomt. En zolang JOUW exploit niet gevonden is, heb je
een wereld vol zombies... Het NIET hergebruiken van
bestaande code zorgt ervoor dat vulnerabilities in slechts 1
programma zitten. Dan wordt het veel minder interessant...
Bovendien, niemand kijkt oude code na. 'wat niet kapot is,
niet repareren... Nieuwe code wel. En als iemand dezelfde
code nog een keer uitvindt, wordt misschien die vuln WEL
gevonden... Nee, recyclen code maakt software (meer)
kwetsbaar...
Het punt is meer dat hergebruikte code niet moet worden overgeslagen bij
een code review.
De kwaliteit is waarschijnlijk beter dan nieuwe code, maar het risico is voor
alle code hetzelfde.
... Het NIET hergebruiken van bestaande code zorgt ervoor
dat vulnerabilities in slechts 1 programma zitten. Dan wordt
het veel minder interessant...
... Nee, recyclen code maakt software (meer)
kwetsbaar...
niemand 'per ongeluk' tegen jouw zelfgemaakte fouten aanloopt?
Bovendien laten allerlei onderzoeken zien dat er patronen
zitten in fouten die programmeurs maken, dus hoe uniek kan
je zijn?
dichten, dat is toch niet onaardig.
Trouwens, hoe verhindert men dat code hergebruikt wordt? Onvermijdelijk
zullen ontwikkelaars eerder gebruikte oplossingen hergebruiken. Het is
immers de beste oplossing die ze kunnen verzinnen, want als ze een
betere zouden kennen dan hadden ze die de eerste keer ook gebruikt.
De enige manier die hergebruik voorkomt is de 1001-nacht-methode: na
elk project alle medewerkers afdanken en voor het volgende project met
een nieuwe ploeg beginnen. Of je daarmee betere codes krijgt...?
werkt daarmee als mest voor de rest.
;-)
Nee hoor, er is niets mis met hergebruik! Zoals een fout zich in 63
applicaties kan bevinden kan een fix er ook 63 verbeteren
dat een frisse kijk veel goeds kan doen aan de code, is het
tijdrovend en (daardoor economisch) nutteloos. Veel beter is
het om de kosten die je bespaart door hergebruik, voor een
deel te investeren in code reviews. Daardoor houd je een
betaalbaar product waarvan de kwalitieit bij ieder
hergebruik fiks gecontroleerd kan worden.
Arno F
keer de lekke band opnieuw uitvinden.
JohnPC
Het niet hergebruiken van code is (bijna) onmogelijk. Elke
hogere programmeertaal maakt gebruik van gedeelde low-level
subroutines.
Als je geen code wilt recyclen dan moet je uitsluitend
programmeren in assembler, en zelfs dan maak je nog gebruik
van shared code die word geleverd door de bios of het
operating systeem.
Conclusie: de bovenstaande stelling is overbodig.
uuhm ja :P hoe krijg je strax anders Ai (5de)taal ? die
hergebruikt toch ook kennis van vorige(4/3) taal
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?