tisdag 21 oktober 2008
Ny bok om säker C
En bekant, Robert Seacord på Carnegie Mellon Software Engineering Institute i Pittsburgh, har tillsammans med en rad experter tagit fram en ny bok om säker C - CERT C Secure Coding Standard.
OWASP + webbläsare = sant
Fick nyligen följande på leaders-listan:
"OWASP, the Open Web Application Security Project, is teaming up with browser development teams to increase the security of the World Wide Web. All popular browser teams (Internet Explorer, Firefox, Safari, Opera, Chrome) have been invited to take a seat at the OWASP European Summit, which will take place in Portugal in November."
Jag berättade i somras på OWASP Swedens mejlinglista om den nystartade arbetsgruppen Intrinsic Security som fokuserar på säkerhet i webbläsare. Webben och våra läsare har blivit den nya plattformen för applikationer vilket gör att arbete med t.ex. tekniska policys måste involvera just webbläsarna.
Målet med workshopen i Portugal nu i november är att ta fram en önskelista för webbläsarsäkerhet som sen ska framföras till World Wide Web Consortium.
Läs mer om OWASP EU Summit 2008
/John
"OWASP, the Open Web Application Security Project, is teaming up with browser development teams to increase the security of the World Wide Web. All popular browser teams (Internet Explorer, Firefox, Safari, Opera, Chrome) have been invited to take a seat at the OWASP European Summit, which will take place in Portugal in November."
Jag berättade i somras på OWASP Swedens mejlinglista om den nystartade arbetsgruppen Intrinsic Security som fokuserar på säkerhet i webbläsare. Webben och våra läsare har blivit den nya plattformen för applikationer vilket gör att arbete med t.ex. tekniska policys måste involvera just webbläsarna.
Målet med workshopen i Portugal nu i november är att ta fram en önskelista för webbläsarsäkerhet som sen ska framföras till World Wide Web Consortium.
Läs mer om OWASP EU Summit 2008
/John
torsdag 9 oktober 2008
Oktoberföredrag: Simon Josefsson, SJD och Yubico
Simon leder utveckling av fri mjukvara som GnuTLS, GSASL och GSS. Han har tidigare arbetat på RSA. Hans föredrag kretsade kring fyra ledstjärnor för säkrare applikationer:
Säkerhet är inte ett mål utan en ständigt pågående process. Du blir aldrig "klar" med säkerhet. I processen kan man vara reaktiv och proaktiv. Gällande den reaktiva delen så behöver man inte ta höjd för zero-day exploits eftersom de är rätt ovanliga idag. Vanligare är rapporter om krascher som kan vara tecken på säkerhetshål och rapporter från analysverktyg såsom Coverity eller Fortify.
Simon berättade att arbetet med att utreda en kraschrapport är så pass arbetsamt att han och de andra kärnutvecklarna inte alltid hinner med. Strategin har därför blivit att öppet bjuda in communityn att granska huruvida ett rapporterat fel har säkerhetsbärighet eller inte. Det betyder också att Simons säkerhetsarbete är mer öppet än Daniels arbete med libcurl.
Simons strategi har varit att tolka kraschrapporter konservativt, dvs att om det kan vara ett säkerhetshål så ska det hanteras så. Nackdelen är att stora organisationer som är beroende av din kod inte uppskattar den hållningen. För dem är en onödig säkerhetspatch en dyr historia.
#2 Arbeta proaktivt
Simon förordar öppna, tydliga kontaktvägar för att få mer information om problem. Att projektet är väl dokumenterat är också viktigt för att inflödet av feedback ska funka. Och med kvalitativ dokumentation menas en separat manual, inte bara kommenterad kod och projektwiki. Dra igång manualarbetet direkt även om det bara är en A4-sida. Då växer den organiskt.
Bidrag från communityn är viktiga men kräver lite mer än mottagande av kod. Simon kör konsekvent med copyright assignments på alla bidrag över tio rader kod. Sådana avtal reglerar att ett företag inte kan hävda copyright på ditt projekt bara för att person X arbetade för dem när X bidrog med kod. Dessutom poängterade Simon vikten av att faktiskt träffas i verkligheten och inte bara via nätet. Skaffa ansikten på kärntruppen så funkar samarbetet mycket bättre, även om det kräver en utomlandsresa eller två.
För att uppnå god kvalitet på koden så gillar Simon analysverktyg och metriker såsom cyklomatisk komplexitet och kodtäckning för enhetstester (det är inte utan att man minns sina gamla datalogitentor :). Manuell granskning är väldigt bra men dyrt i arbetstimmar. Och precis som Daniel så ser Simon storleken på funktioner som en mycket viktig faktor - små funktioner bra, stora funktioner dåligt.
Öppen källkod leder ofta till scratch your own itch vilket betyder att var och en patchar koden för egna husbehov. Enligt Simon leder det ofta till ruttnande design på sikt. Med för för små och isolerade bidrag så finns helt enkelt inte tid eller intresse för att förstå designen. Det är svårt att råda bot på men man bör vara medveten om fenomenet. Ett sätt att få fokus på styrningen av projektet är att ha bokade släpp, dvs så kallade timed releases. Inför ett bokat släpp skärper man upp projektet.
#3 Bjud in kritik
En fara inom fri mjukvara är att utvecklare inte alltid tar emot kritik på ett bra sätt. De är ofta är väldigt personligt involverade och lägger mycket prestige i sina projekt. Detta tillsammans med att säkerhetshål ofta hittas av okända personer som kanske aldrig bidrar med något mer kan leda till att kritik avfärdas eller behandlas styvmoderligt. Simon uppmanar till att bjuda in kritik och släppa på prestigen.
#4 Tag ansvar för koordinering av uppgraderingar/patchar
Bland det viktigaste för att uppnå kvalitet i mjukvara är att någon/några verkligen tar ansvar för att följa upp rapporterade problem och implementera och distribuera uppgraderingar och patchar. Tyvärr brister det i många fria mjukvaruprojekt. CERT-organisationer runt om i världen kan hjälpa till men de löser det inte nödvändigtvis, som Simon kunde visa med ett tydligt exempel. Samordningen i vendor-sec är tyvärr lite för sluten men kan hjälpa till att analysera om en rapporterad bugg verkligen är säkerhetsrelevant.
/John
- Säkerhet som process
- Proaktivt arbete
- Öppenhet för kritik
- Ansvar för förvaltning
Säkerhet är inte ett mål utan en ständigt pågående process. Du blir aldrig "klar" med säkerhet. I processen kan man vara reaktiv och proaktiv. Gällande den reaktiva delen så behöver man inte ta höjd för zero-day exploits eftersom de är rätt ovanliga idag. Vanligare är rapporter om krascher som kan vara tecken på säkerhetshål och rapporter från analysverktyg såsom Coverity eller Fortify.
Simon berättade att arbetet med att utreda en kraschrapport är så pass arbetsamt att han och de andra kärnutvecklarna inte alltid hinner med. Strategin har därför blivit att öppet bjuda in communityn att granska huruvida ett rapporterat fel har säkerhetsbärighet eller inte. Det betyder också att Simons säkerhetsarbete är mer öppet än Daniels arbete med libcurl.
Simons strategi har varit att tolka kraschrapporter konservativt, dvs att om det kan vara ett säkerhetshål så ska det hanteras så. Nackdelen är att stora organisationer som är beroende av din kod inte uppskattar den hållningen. För dem är en onödig säkerhetspatch en dyr historia.
#2 Arbeta proaktivt
Simon förordar öppna, tydliga kontaktvägar för att få mer information om problem. Att projektet är väl dokumenterat är också viktigt för att inflödet av feedback ska funka. Och med kvalitativ dokumentation menas en separat manual, inte bara kommenterad kod och projektwiki. Dra igång manualarbetet direkt även om det bara är en A4-sida. Då växer den organiskt.
Bidrag från communityn är viktiga men kräver lite mer än mottagande av kod. Simon kör konsekvent med copyright assignments på alla bidrag över tio rader kod. Sådana avtal reglerar att ett företag inte kan hävda copyright på ditt projekt bara för att person X arbetade för dem när X bidrog med kod. Dessutom poängterade Simon vikten av att faktiskt träffas i verkligheten och inte bara via nätet. Skaffa ansikten på kärntruppen så funkar samarbetet mycket bättre, även om det kräver en utomlandsresa eller två.
För att uppnå god kvalitet på koden så gillar Simon analysverktyg och metriker såsom cyklomatisk komplexitet och kodtäckning för enhetstester (det är inte utan att man minns sina gamla datalogitentor :). Manuell granskning är väldigt bra men dyrt i arbetstimmar. Och precis som Daniel så ser Simon storleken på funktioner som en mycket viktig faktor - små funktioner bra, stora funktioner dåligt.
Öppen källkod leder ofta till scratch your own itch vilket betyder att var och en patchar koden för egna husbehov. Enligt Simon leder det ofta till ruttnande design på sikt. Med för för små och isolerade bidrag så finns helt enkelt inte tid eller intresse för att förstå designen. Det är svårt att råda bot på men man bör vara medveten om fenomenet. Ett sätt att få fokus på styrningen av projektet är att ha bokade släpp, dvs så kallade timed releases. Inför ett bokat släpp skärper man upp projektet.
#3 Bjud in kritik
En fara inom fri mjukvara är att utvecklare inte alltid tar emot kritik på ett bra sätt. De är ofta är väldigt personligt involverade och lägger mycket prestige i sina projekt. Detta tillsammans med att säkerhetshål ofta hittas av okända personer som kanske aldrig bidrar med något mer kan leda till att kritik avfärdas eller behandlas styvmoderligt. Simon uppmanar till att bjuda in kritik och släppa på prestigen.
#4 Tag ansvar för koordinering av uppgraderingar/patchar
Bland det viktigaste för att uppnå kvalitet i mjukvara är att någon/några verkligen tar ansvar för att följa upp rapporterade problem och implementera och distribuera uppgraderingar och patchar. Tyvärr brister det i många fria mjukvaruprojekt. CERT-organisationer runt om i världen kan hjälpa till men de löser det inte nödvändigtvis, som Simon kunde visa med ett tydligt exempel. Samordningen i vendor-sec är tyvärr lite för sluten men kan hjälpa till att analysera om en rapporterad bugg verkligen är säkerhetsrelevant.
/John
Oktoberföredrag: Daniel Stenberg, haxx.se
Daniel Stenberg inledde kvällens seminarier genom att berätta om cURL eller mer specifikt libcurl som han leder utvecklingen av.
Produkten libcurl
Libcurl (fri mjukvara) är ett kommandobaserat verktyg för filöverföring enligt en drös med protokoll (FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP ...). De har flera hundra på utvecklarlistan men en kärna på en handfull dedikerade utvecklare.
Libcurl (alltså bilbioteksvarianten), används i en massa mjukvaruprodukter och operativsystem, proprietära såväl som öppna eller fria. Och då snackar vi de stora drakarna. En stor och krävande användarbas med andra ord. Allt distribueras som källkod för att slippa underhålla femtioelva distributioner och byggen.
Rapportering av säkerhetsfel
När det gäller hantering av säkerhetsfel så är inrapporteringen sluten för att ge utvecklarna en chans att komma med en patch. De har haft åtta sådana incidenter. En del av rapporterna har kommit den rätta vägen och tillåtit en veckas arbete med en patch. Andra rapporter har gått parallellt till både utvecklarna och någon publik lista. Tyvärr finns det också incidenter som bara gått till någon publik lista varpå Daniel hört det ryktesvägen. Inte en särskilt seriös variant av full disclosure enligt mig.
En intressant poäng var att många av dem som använder libcurl gör så kallad statisk länkning. De bygger alltså in biblioteket i binären. Det gör att en opatchad version av libcurl kan överleva länge inuti applikationer.
Frågan om dynamisk versus statisk länkning är ju intressant tycker jag. I det dynamiska fallet är det enklare att patcha (till och med slutanvändaren kan göra det) medan det i det statiska fallet är enklare att ha kontroll på vad ens applikation kör för kod. Det är ju en läskig attackvektor att injicera sårbar kod via libbar ...
Bidrag från communityn
Daniel kommenterade the many eyeballs som att det oftast bara är några få som bryr sig. Han granskar själv alla bidrag från communityn. Gällande så kallade copyright assignments så använde Daniel inte såna förutom för riktigt stora commits. Det är helt enkelt för mycket jobb för att göra det jämt.
Daniels tips för säker kod
Utan att presentera någon magi så tydliggjorde Daniel vilka principer han tycker leder till säkrare kod:
• Enkel kod - förstår du inte koden så skriv om den
• Manuell granskning - tar tid men ger kvalitet
• Förbjudna funktioner - vissa C-funktioner får helt enkelt inte användas i cURL
• Små funktioner - har att göra med enkel kod - 10 rader är bra, 100 rader är dåligt
/John
Produkten libcurl
Libcurl (fri mjukvara) är ett kommandobaserat verktyg för filöverföring enligt en drös med protokoll (FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP ...). De har flera hundra på utvecklarlistan men en kärna på en handfull dedikerade utvecklare.
Libcurl (alltså bilbioteksvarianten), används i en massa mjukvaruprodukter och operativsystem, proprietära såväl som öppna eller fria. Och då snackar vi de stora drakarna. En stor och krävande användarbas med andra ord. Allt distribueras som källkod för att slippa underhålla femtioelva distributioner och byggen.
Rapportering av säkerhetsfel
När det gäller hantering av säkerhetsfel så är inrapporteringen sluten för att ge utvecklarna en chans att komma med en patch. De har haft åtta sådana incidenter. En del av rapporterna har kommit den rätta vägen och tillåtit en veckas arbete med en patch. Andra rapporter har gått parallellt till både utvecklarna och någon publik lista. Tyvärr finns det också incidenter som bara gått till någon publik lista varpå Daniel hört det ryktesvägen. Inte en särskilt seriös variant av full disclosure enligt mig.
En intressant poäng var att många av dem som använder libcurl gör så kallad statisk länkning. De bygger alltså in biblioteket i binären. Det gör att en opatchad version av libcurl kan överleva länge inuti applikationer.
Frågan om dynamisk versus statisk länkning är ju intressant tycker jag. I det dynamiska fallet är det enklare att patcha (till och med slutanvändaren kan göra det) medan det i det statiska fallet är enklare att ha kontroll på vad ens applikation kör för kod. Det är ju en läskig attackvektor att injicera sårbar kod via libbar ...
Bidrag från communityn
Daniel kommenterade the many eyeballs som att det oftast bara är några få som bryr sig. Han granskar själv alla bidrag från communityn. Gällande så kallade copyright assignments så använde Daniel inte såna förutom för riktigt stora commits. Det är helt enkelt för mycket jobb för att göra det jämt.
Daniels tips för säker kod
Utan att presentera någon magi så tydliggjorde Daniel vilka principer han tycker leder till säkrare kod:
• Enkel kod - förstår du inte koden så skriv om den
• Manuell granskning - tar tid men ger kvalitet
• Förbjudna funktioner - vissa C-funktioner får helt enkelt inte användas i cURL
• Små funktioner - har att göra med enkel kod - 10 rader är bra, 100 rader är dåligt
/John
Vi bloggar från seminariekvällarna
Vi börjar blogga från OWASP Swedens seminariekvällar! Vill man blogga så är det bara att säga till John.
Måndag 6/10 hade OWASP Sweden seminariekväll på Hotel Clarion Stockholm. Robert Malmgren AB sponsrade med lokal och förtäring. Anmälningarna följde ketchupmönstret så det blev lite trångt i lokalen. The more the merrier?
Måndag 6/10 hade OWASP Sweden seminariekväll på Hotel Clarion Stockholm. Robert Malmgren AB sponsrade med lokal och förtäring. Anmälningarna följde ketchupmönstret så det blev lite trångt i lokalen. The more the merrier?
Prenumerera på:
Inlägg (Atom)