garoeda	(log note: start translation)
garoeda	onze volgende spreker is Seth Arnold
garoeda	hij is een security researcher en expert van de VS
garoeda	hij werkt bij Wirex en is ook betrokken bij de ontwikkeling van de Immunix Distributie
garoeda	hij is tevens betrokken bij de organisatie van deze conferentie
garoeda	zonder hem zou deze conferentie zeker anders geweest zijn (en niet beter)
garoeda	Hij gaat vertellen over een interessant project ivm security auditing
garoeda	open source code: "Sardonix: making the most of our open source"
garoeda	We danken hem omdat hij deze presentatie heeft voorbereidt en
garoeda	jullie om hier te komen
garoeda	Mr. Arnold
garoeda	bedankt fernand0 :-)
garoeda	ik zou willen zeggen dat vragen en opmerkingen in #qc komen
garoeda	je mag ze op ieder moment stellen
garoeda	ik zou ook garoeda en Arardor willen bedanken om on the fly in het nederlands en spaans te wilen vertalen voor mij. heel cool. :-)
garoeda	ik zou willen beginnen met te zeggen dat ik RMS niet disrespecteer wanner ik over Open SOurce spreek
garoeda	ik denk dat hij veel goede dingen zegt, ook al zijn ze soms irritant :-)
garoeda	maar ik wil niet specifiek zeggen met "open source" vs "free software"
garoeda	dit gezegd zijnde
garoeda	er is een quote: "with enough eyes, all bugs are shallow"
garoeda	dit werd toegekend aan eric s raymond en linus torvalds
garoeda	misschien hebben beiden het wel gezegd :-)
garoeda	maar het probleem is, er zijn *niet genoeg* ogen
garoeda	de meeste software die we gebruiken in de open source gemeenschap heeft geen goede audit gehad
garoeda	het meeste ervan was geschreven voor het plezier door liefhebbers
garoeda	wat heel goed is, maar, programmeurs maken fouten
garoeda	en zonder de goede infrastructuur om deze fouten te verbeteren kunnen serieuze security fouten ontstaan
garoeda	er zijn _sommige_ georganiseerde auditing projecten, zoals het OpenBSD project, Solar Designers Openwall project en de SuSE en Caldera security teams
garoeda	maar de security teams van caldera en suse hebben drastische veranderingen ondergaan recentelijk, ze hebben niet langer evenveel tijd als vroeger om security audits te doen
garoeda	vraag: en debian en the hurd?
garoeda	debian heeft een actief security team maar, voor zover ik weet, ze zijn vooral gericht op reageren, nl de package maintainers security fixes laten maken
garoeda	voor zover ik weet doet de hurd geen audit, misschien doen ze het, ik weet het niet
garoeda	vraag: en microsoft. :)
garoeda	de transistie van Microsoft naar C# zou ze binnenkort serieuze security voordelen kunnen opleveren
garoeda	maar het grootste probleem van Microsoft is dat ze met ee immense complexiteit moeten rekening houden
garoeda	microsoft kan het betalen om duizenden en duizenden programmeurs in te huren enkel en alleen om source code te lezen en kwetsbaarheden te vinden..misschien hebben ze er wel enkele gehuurd voor hun laatste security offensief
garoeda	de opensource gemeenschap kan het niet betalen om tientallen programmeurs te huren die elkaars werk checken
garoeda	wat ons terug naar sardonix brengt :-)
garoeda	de sterkte van de open source gemeenschap is dat vele mensen trots en eigendom nemen van de programma's die we iedere dag gebruiken
garoeda	vraag: er is een ander probleem, code auditen is niet makkelijk
garoeda	fernand0 heeft dit goed gezien
garoeda	programmeurs zijn jaar na jaar geleerd om onveilige programmeermethoden te gebruiken
garoeda	en veel fouten zijn subtiel verborgen
garoeda	als iemand zoals al viro een blik werpt op source code, eender welke, voor neem nu 5 minuten, gaat hij al exploitable gebreken vinden
garoeda	al viro is uniek, maar niet noodzakelijk in een manier die niet onderwezen kan worden
garoeda	het feit dat niet iedereen zo snel fouten kan vinden wil zeggen dat we nog een weg te gaan hebben
garoeda	we hebben een manier nodig om de mensen aan te moedigen fouten te vinden
garoeda	en dit op een manier dat er geen bergen geld nodig zijn
garoeda	mijn baas, cripin cowan, was jaren onder de indruk van slashdot
garoeda	meer specifiek, hoe mensen veel tijd spenderen om 'karma points' te verdienen met hun berichten
garoeda	mensen gaan zinvolle en nuttige commentaar schrijven en hun geschiedenis van nuttige bericthen gaat geadverteerd worden
garoeda	dus mijn baas dacht 'laat deze "karma whores' eveneens software auditené
garoeda	sardonix was geboren
garoeda	maak een verzamelpunt om security audits in op te slaan
garoeda	verbind de audits met de auteurs zodat we scores kunnen maken met hoe goed de verschillende auteurs werken
garoeda	door een goede scoringsfunctie te gebruiken kunnen we helpen schrijvers te laten kijken naar software en ze _precies_ leren zijn in hun audits
garoeda	vraag: een ander open-source specifiek probleem is dat wanneer ik een bug vind, ze niet rapporteer maar zelf oplos vermits ik de source code heb, om te voorkomen dat ik te nauw verbonden raak met het project
garoeda	ja, dat is een probleem
garoeda	maar een misschien eenvoudige oplossing is dat je de bug eerst aan iemand meedeelt en ze dat _zelf_ oplost  :-)
garoeda	op die manier, als je zelf een patch schrijft, gaat ze getest worden (altijd een pluspunt) en de mensen gaan bugreports van jou met graagte ontvangen in de toekomst :)
garoeda	vraag: geeft sardonix ook een score aan verkopers, bv -1 : reageert niet of +5: werkt zeer nauw samen met de gemeenschap om een fix te verkrijgen
garoeda	nee, niet op dit ogenblik, om helemaal eerlijk te zijn, het score systeem werkt nog niet op dit moment :)
garoeda	we hadden plannen om specifiek programma's een score te geven, rekening houdende met hun bug geschiedenis
garoeda	het idee is dat slashdot's karma systeem bijna volledig automatisch is. we zoude sardonix helemaal willen automatiseren... een score gebaseerd op reactie tijd zou de zaken ietwat compliceren maar het is waarschijnlijk de moeite waard om te onderzoeken :)
garoeda	vraag: er zou heel wat moeite gestopt moeten worden om bestaande/nieuwe programmeurs te vertellen hoe ze nieuwe code moeten schrijven met een basis van security in het achterhoofd (in toevoeging tot het fixen van bugs die iemand in het verleden gemaakt heeft)
garoeda	ik ga daar volledig mee akkoord. mijn eigen opvoedkundig ervaring leert me dat security problemen bijna niet besproken worden in het schoolsysteem
garoeda	een van mijn proffen was geschokt een race conditie in werking te zien. stel je voor dat zij een applacitiet moet schrijven waar mogelijk niet te vertrouwen input aan gegeven kan worden. het resultaat zou niet goed zijn
garoeda	zoals jose_n zegt, er is geen gebrek aan resources maar omdat, gedeeltelijk, de computer industrie godomineerd wordt door features ipv betrouwbaarheid
garoeda	dus , het aanleren aan programmeurs om snel code te schrijven is meer belangrijk gebleken dan corect programmeren
garoeda	me de te verwachten gevolgen :)
garoeda	vraag: er is een ander probleem, code auditen is niet makkelijk
garoeda	fernand0 kan het misschien niet geweten hebben  (of misschien toch) als hij het zei, maar bewijzen dat code geen security flaws heeft is een onoplosbaar probleem
garoeda	het is bewezen dat het bewijzen dat code geen fouten heeft een isomorfisch probleem is (het zelfde probleem als het 'Turing halting' probleem willen oplossen
garoeda	vraag: een probleem dat ik zie is dat veel mensen code copieren met security bugsvan boeken en online voorbeelden. Ken je een project dat probeert een audit te doen van educationeel materiaal ?
garoeda	ik ken zo geen projecten, ze zouden in elk geval moeilijk zijn, omdat er honderen programmeerboeken zijn met verrassend veel (en duidelijke) security bugs erin
garoeda	ik hou ervan om unix boeken van midden jaren tachtig te lezen, en het is redelijk deprimerend om te zien hoe ze functies onveilig gebruiken
garoeda	en practisch iedere pagina van elk (populair) boek dat ik heb staat vol met security flaws
garoeda	vraag: zowel ik (riel) als jose_n hebben verschillende fouten gevonden in code voorbeelden in linux magazines, we schreven beide klachten naar de editors maar dit was niet echt een 'effort'
garoeda	vraag: was het niet Stevens die betaalde als je fouten in zijn boeken kon tonen
garoeda	ik weet niet zeker of Stevens echt betaalde voor fouten, maar knuth gaf een beloning van 2.56$ per gevonden bug aan de eerste persoon die ze raporteerde
garoeda	ik vraag me wel af of er echt iemand geld gekregen heeft
garoeda	gegeven het feit dat security audits moeilijk zijn, geen enkele auteur zal alle bugs vinden, dus we moeten _veel_ mensen aanmoedigen audits te doen en hopen dat we tesamen de meeste bugs kunnen vinden
garoeda	een deel van sardonix is een research aspect, als we mensen _kunnen_ aanmoedigen om software te auditen door ze de spreekwoordelijke wortel voor te houden hopen we dat de mensen zich 'karma whore' en aan de zaak
garoeda	vraag: betreffende de bugs in online voorbeelden en/of boeken, misschien kunen sommige mensen rond sardonnix verzamelen en vrijwilliger zijn voor de audit van code die voor publicatie bedoeld is
garoeda	dat is geen goed idee, ik denk dat we in contact moeten treden met een groote uitgever en zien wat we kunnen doen :)
garoeda	vraag: soms is secure programmeren niet belangrijk
garoeda	vraag: of is het niet makkelijk een grens te hebben tussen secure en buggy
garoeda	Iván Arce, of CORE-SDI heeft hierover een wonderbaarlijke filosofie: "betrouwbaarheid is wanneer een programma doet wat het moet doen, security is wanneer programma's doen wat ze moeten doen en niets anders"
garoeda	en je hebt gelijk, in sommige gevallen moet software niet secure zijn
garoeda	spelletjes zijn hiervan een bekend voorbeeld
garoeda	maar, veel systemen zijn gecompromiteerd door spelletjes, ofwel trojaanse paarden die root-accounts installeren wanneer ze door een system administrator gedraaid worden of de "high score" bestanden die gebruikt kunnen worden als exploit
garoeda	vraag: sommie spelletjes, zoals quake kunnen over het netwerk draaien, elke gebruiker op het netwerk kan een slecht geformatteerde input ernaar sturen en het andere code laten uitvoeren
garoeda	alhoewel sommige programma's  niet echt secure geprogrammeerd dienen te worden, als ze _enige_ input ontvangen van bronnen die niet geheel te betrouwen zijn moet ze herschreven worden met security in het achterhoofd
garoeda	vraag: in feite, spelletjes machines kunnen een excellent zombie leger worden  voor een Dos aanval
garoeda	ja, dat is waarom zelfs spelletjes secure geprogrammeerd moeten worden
garoeda	in het algemeen, een defensief programmeur zijn is al wat nodig is om  secure software te schrijven
garoeda	de gedachte bij iedere functie moet zijn: "hoe kan dit fout gaan, als iemand de slimmerik wil uithangen"
garoeda	vraag: ik vind het niet kritisch als software niet secure is  als het  dood of beschadiging kan veroorzaken aan andere levensvormen
garoeda	vraag: definieer security in applicaties
garoeda	software die critisch is voor de ene persoon kan onbelangrijk zijn voor iemand anders
garoeda	en in het algemeen, open source software wordt niet echt gebruikt in de fly-by-wire systemen van vliegtuigen of in de life-support systemen van hospitalen
garoeda	en, een van de voordelen van open source software is dat mensen wie erop moeten betrouwen hun eigen security audits kunnendoen
garoeda	ik denk dat we op dit punt genoeg gesproken hebben over security auditing
garoeda	ik hoop dat ik heb kunnen duidelijk maken dat security audits een belangrijk aspect vormen van software ontwikkeling
garoeda	en we hopen te ontdekken dat door het sardonix project of het "karma whore' effect mensen kan aanzetten om auditing te doen
garoeda	(zoals mijn baas zegt: "daarom dat het 'research' heet. :)
garoeda	vraag: ik denk dat auditing niet het belangrijkste punte is
garoeda	vraag: software zou een een beter design moeten hebben)
garoeda	vraag: sorry dat ik geen clue heb waarover het gaat, maar wat bedoel je met "karma" whore
garoeda	karma whore: een slasdhot poster die  zinnige commentaar gaat schrijven...enkel voor de erkenning
garoeda	de man die "the mythical man month" schreef verdeelt bugs in 2 categoriën
garoeda	"incidental" en "intrinsic"
garoeda	incidentele bugs zijn de buffer overflows en de printf bugs van deze wereld. bugs die misschien vermeden kunnen worden door andere toolsets te gebruiken (zoals type-safe talen: java, ml, haskell, etc)
garoeda	intrinsieke bugs ontstaan door de complexiteit van de software
garoeda	zulke bugs halen de krantenkoppen "yet another outlook virus", "yet another IE security bug collected out of three non-problems"
garoeda	auditing kan beide klassen ontdekken, de xinetd audit van Solar Designer (100KB + patch) ging over beide klasses
garoeda	maar intrinsic bugs vinden duurt langer...vandaar de nood aan een beter opleiding
garoeda	en, nu we over opleiding spreken, deze presentatie zou interessant zijn als ik ook iets vertel over gebruikelijk (incidentele) fouten die in software terecht komen
garoeda	de meest populaire vorm van security problemen is de Buffer Overflow
garoeda	dit werd zeer makkelijk gemaakt in C omdat  strings gerepresenteerd werden door null-getermineerde character arrays
garoeda	dus, heel simpele (en vaak gebruikte) code zoals het volgende geeft een aanvaller complete controle over het programma
garoeda	char buf[MAX]
garoeda	strcpy(bug,input)
garoeda	afhankelijk van de lengt van de character array in 'input'' kan een kwaadwillend persoon  de 'buf' buffer overflowen, dit kan variabelen, return adressen en ander programma ellementen overschrijven
garoeda	dit stuk zou herschreven moeten worden zodat alleen MAX-1 characters van de input in bug gecopieerd worden of  er gestoprt wordt als de input te lang is
garoeda	(gebruik makende van strncpy, strlcpy, of strlen)
garoeda	vraag: strlcpy ?
garoeda	strclpy werd geintroduceerd door het openbsd project als vervanger voor strcncpy...die inconsistente semantiek heeft
garoeda	vrrag: is er ergens een website waarop staat hoe we clean code moeten schrijven (ik bedoel met clean en goede commentaar...vooral hoe commentaar te schrijven)
garoeda	er is een lijst hiervan beschikbaar op  https://sardonix.org/Auditing_Resources.html
garoeda	en betreffende het schrijven van commentaren, de korte regel is: "beschrijf niet wat je code doet, dat zou duidelijk moeten zijn, maar beschrijf _waarom_ jouw code iets doet"
garoeda	het volgende type van veel voorkomende fout is de "printf" bug
garoeda	vele jaren leefden de mensen in de veronderstelling dat printf een 'veilige' functie was
garoeda	maar in de lente/zomer van van 2000 toonde iemand dat je met printf naar het geheugen kan schrijven
garoeda	en _veel_ programmeurs laten kwaadwillige input toe
garoeda	code die lijkt op
garoeda	printf(foo) is mogelijk kwetsbaar aan misbruiken
garoeda	het zou herschreven moeten woden als printf("%s", foo);
garoeda	er zijn meerdere complexe problemen met printf, maar deze worden best besproken in een forum specifiek voor printf (zoals KF's INFOSEC presentaties een paar maanden geleden)
sarnold	(any questions?)
garoeda	een andere klasse van fouten is de bestandssysteem race
garoeda	dit is viro's s specialiteit
garoeda	dit kan ies eenvoudig zijn als het gebruik van van access(2) in een geprivilegeerd programma om te bepalen of bestandstoegang toegelaten mag worden in een open call die voor de gebruiker gemaakt is
garoeda	(het gebruik gaat meestal als volgt, if (access("/etc/shadow", S_IWUSR)) open("/etc/passwd", O_WR);)
garoeda	het probleem is dat iemand de /etc/shadow file kan veranderen tussen de access(2) en open(2)
garoeda	dit is gekend als de "time of check to time of use" vulnerability
garoeda	de oplossing van dit probleem is complexer, het gebruik van setuid(2) en setgid(2) en setgroups(2) om er zeker van te zijn dat de kernel de checks _doet_
garoeda	linux introduceerde een aardig feature fsuid dat  een programma toelaat om de bestandssysteem privileges van een bepaalde gebruiker te emuleren, zonder de volledige privileges te laten vallen
garoeda	dit was oorspronkelijk geimplementeerd voor de nfs daemon maar kan door andere programma's zoals sendmail gebruikt worden om er zeker van te zijn dat de mail aflevering in orde is
garoeda	andere problemen met niet gecontroloreerde input houdt de system(3) functie in
garoeda	deze functie draait een commando met /bin/sh , dus is het extreem krachtig en eenvoudig te gebruiken, met het nadeel dat als willekeurige invoer gegeven kan worden door de gebruiker men omzicht moet omspringen met  shell metacharacters
garoeda	als een gebruiker een deel van het commando kan manipuleren/input kan meegeven zoals ;rm -rf /; is je dag geruineerd :)
garoeda	een probeel waar weinig mensen aan denken is de omgeving !
garoeda	de lader laat toe om bibliotheken op voorhand te linken met een programma, hierbij de systeem bibliotheken te vervangen, gebruik makende van LD_PRELOAD
garoeda	dus, gebruikers kunnen zelfs functies vervangen door hun eigen functies
garoeda	dit wordt minder in glibc doordat de omgeving 'gekuist' worddt voor een exec() uit te voeren maar dit is niet de perfecte manier
garoeda	PATH is ook populair om te misbruiken, veel systemen gebruikten (CWD) in de PATH variabele, een /tmp/mail  programma hieraan gevende, zou iemand heel blij kunnen worden als de root zijn mail leest vanuit /tmp^:)
garoeda	vraag: wat kan iemand doen om LD_PRELOAD problemen te voorkomen, buiten statisch te compileren
garoeda	er is niet veel wat men kan doen, LD_PRELOAD wordt meestal behandeld door glibc op linux systemen, maar het probleem indiceert de speciale natuur van omgevings variabelen
garoeda	gisteren ontving ik een email van Steven Christey, van het MITRE CVE project, met daarin een lijst van security gevoelige code fouten, het telde 60 categoriën en veel ingangen hadden 12 of meer sub categoriën
garoeda	we zullen de lijst op de sardonix website plaatsen als gids om auditers te helpen wanneer ze software auditen.  het ziet ernaar uit dat auditers een goede bron hebben om naar te kijken :-)
garoeda	heeft er iemand vragen?
garoeda	vraag: hoeveel mensen kijken er naar de standaard open source tools (zoals basis GNU tools) en worden ze geaudit
garoeda	niet genoeg, mensen vinden nog altijd fouten in tar, rm etc...
garoeda	ik dacht dat 18 jaar lang genog was om tar en rm stabiel en bugvrij te maken...ik was verkeerd :)
garoeda	vraag: de lijst van Steven Christley is uitgebreider dan de lijst die sardonix heeft
garoeda	ja, ik heb enkel een paar voorbeelden gegeven, de lijst is lang en heel uitgebreidt
garoeda	vraag: ik zou een open source audit groep/consortium willen zien
garoeda	dat is de hoop van sardonix, door gebruik te maken van het slashdot "karma whore" effect hopen we mensen te kunnen aanmoedigen om software te auditen met erkenning als betaalmiddel
garoeda	vraag: bestaan er tools om naar bugs te zoeken?
garoeda	https://sardonix.org/Auditing_Resources.html  bevat links naar tools die je kunnen helpen teneinde probleem code te onderzoeken
garoeda	er is een nadeel, fouten zoeken is turing equivalent, deze tools gebruiken heuristieken en van tijd tot tijd zijn deze niet zo goed. het is een afweging tussen echte en niet echte fouten rapporteren
garoeda	vraag: het zou een goed idee zijn om een 'sandbox' te gebruiken voor applicaties zoals browers en icq/irc clients
garoeda	ja, dit kan echt helpen, projecten ozals LSM http://lsm.immunix.org geven een framework voor security modules  in de kernel om zulke sandboxes mogelijk te maken (TrustedBSD voor de FreeBSD fans)
garoeda	vraag: kent er iemand selinux
garoeda	het grootste probleem van SELinux is , zoals ik het zie, de complexitiet van hun policy regels is heel hoog
garoeda	er is een andere afweging die je moet maken, sandboxes kunnen  zeer expliciet en dicht zijn, maar lang duren om ze te maken en valideren, of ze kunnen simpel zijn en een granulair zijn maar eenvoudiger om tte maken en valideren
garoeda	vraag: bewijzen dat code geen security problemen heeft is niet oplosbaar: het is enkel niet bewijsbaar zolang je er vanuit gaat dat features belangrijker zijn dan correctheid
garoeda	well, dit is eigenlijk bewezen het geval te zijn, de security eigenschappen van een willekeurig programma bepalen is onmogelijk
garoeda	voor specifieke programma's heb je gelijk, maar zelfs kleine en simpele programma's (zoals fingerd) hebben een slechte security achtergrond
garoeda	vraag: als je voorzichtig bent vanaf het begin (zoals  DJB) kan je 100% secure software schrijven
garoeda	inderdaad, je hebt gelijk, sommige auteurs letter er echt op om een goed security geschieden is te hebben
garoeda	met het probleem dat er functionaliteit ontbreekt (bv recursieve dns moet mogelijk zijn)
garoeda	als er geen verder vragen zijn beschouw ik deze presentatie als ten einde zijnde
garoeda	bedankt iedereen
garoeda	(log note: end of translation)
viZard	hooray
Geryon	nice one :)
garoeda	pfoooooooooooooo
Geryon	sebiet terug?
viZard	plas plas plas plas plas plas
viZard	plas plas plas plas plas plas
viZard	plas plas plas plas plas plas
garoeda	thnx viZard :)
* viZard bows to garoeda
Geryon	clap clap clap clap clap clap
Geryon	clap clap clap clap clap clap
garoeda	kweet niet, mijn poten zijn nogal om zeep, we zullen zien
viZard	garoeda, dont´t fo anything else, i´ll manage the log
viZard	take a break

Generated by irclog2html.pl 2.1 by Jeff Waugh - find it at freshmeat.net!