Softwareindustrie wil richtlijnen voor melden van bugs

Een groep softwarefabrikanten en beveiligingsbedrijven heeft in februari de aanzet gegeven voor de oprichting van de Organization for Internet Safety (OIS). Ze hebben genoeg van verrassingen en willen richtlijnen voor het publiceren van bugs en veiligheidslekken. Inmiddels is de groep bedrijven gegroeid tot elf waaronder grote namen als Microsoft, Oracle, Symantec en Network Associates. De lijst van deelnemende bedrijven is echter nog niet compleet, op de eigen website worden andere organisaties aangemoedigd om zich aan te sluiten. De richtlijnen voor het openbaar maken van bugs zullen niet meer zijn dan een advies, zo zegt de organisatie. Het is niet de eerste keer dat de OIS met een voorstel voor richtlijnen komt, nieuw is wel de toevoeging dat de regels niet bindend zullen zijn, er zal geen controle op de naleving plaatsvinden:

Volgens de nu geformeerde OIS "compliceert het ontbreken van dit soort richtlijnen de oplossing van de problemen, waardoor uiteindelijk de risico's voor alle computergebruikers groter zijn". De groep benadrukt dat de geformuleerde richtlijnen niet meer zijn dan dat; er wordt geen manier verzonnen om de naleving ervan af te dwingen.

Deze laatste toevoeging komt niet zomaar uit de lucht vallen. Een aantal leden van de OIS probeerde eerder al soortgelijke richtlijnen op te stellen. Die moesten de softwarefabrikanten bijvoorbeeld dertig dagen de tijd geven om de zwakke plekken te dichten voordat andere partijen hierover publiceerden. Er werd een voorstel ingediend bij de Internet Engineering Task Force (IETF). Dit technisch orgaan wees het voorstel echter af, aangezien de kwestie volgens de IETF niet binnen zijn bevoegdheid viel.

Reacties (30)

[Ronald]

[e-mail] heeft al jaren prima richtlijnen waar de meeste bughunters zich aan houden.

0.1.8 What is the proper protocol to report a security vulnerability?

A sensible protocol to follow while reporting a security vulnerability is as follows:

1. Contact the product's vendor or maintainer and give them a one week period to respond. If they don't respond post to the list.
2. If you do hear from the vendor give them what you consider appropriate time to fix the vulnerability. This will depend on the vulnerability and the product. It's up to you to make and estimate. If they don't respond in time post to the list.
3. If they contact you asking for more time consider extending the deadline in good faith. If they continually fail to meet the deadline post to the list.

When is it advisable to post to the list without contacting the vendor?

1. When the product is no longer actively supported.
2. When you believe the vulnerability to be actively exploited and not informing the community as soon as possible would cause more harm then good.

All this being said, we rather have people report vulnerabilities to the list and not inform the vendors, whatever their reasons may be, than to have them keep the information to themselves.


Heel erg schappelijk dus.
Het probleem is bedrijven die zich onwillend opstellen tegenover bughunters.
(Recent voorbeeld is iemand die een waslijst HPUX vulnerabilities openbaar maakte >>>>NA<<<<< uitgebruide communicatie met HP waarna HP met de DMCA ging dreigen)

[Brahiewahiewa]

Er zijn net zo goed "bughunters" die zich onwelwillend opstellen tegenover bedrijven. Voorbeeld: Chris Paget met z'n shatter attacks. Hij identificeert een vulnerability, geeft zichzelf vervolgens ruim de tijd om een werkende exploit te schrijven en pleurt daarna de zaak op BugTraq onder het motto "ik ben het niet eens met de manier waarop Microsoft een melding van een andere bughunter heeft afgehandeld". Da's pure obstructie en het is niet meer dan logisch dat bedrijven een code of conduct willen afspreken waarmee ze in ieder geval een basis hebben om zich tegen dit soort onverantwoordelijk gedrag te verdedigen.

[Ronald]

Zeg vertel eens, wat zou NOG een code of conduct daar aan veranderen?

Dat Paget zich niet aan de huidige richtlijn houd betekent echt niet dat ie zich aan die nieuw op te stellen code gaat houden.
Verder zijn de verhalen dat MS zich halstarrig opsteld common dus dan roep je het als bedrijf over je af dat mensen niet meer aan je reporten en het gewoon op bugtraq/full-disclosure plempen. Terecht overigens als een bedrijf niet serieus omgaat met security problemen.

[deadinspace]

...wat? op bugtraq/full-disclosure plempen?

Serieus, leg eens uit want ik snap er niks van

Bugtraq is een security-mailinglist (de security-mailinglist mag je wel zeggen) van securityfocus. Als je serieus met security bezig bent volg je die list.

Full-disclosure is dat van een exploit *alle* informatie (dus wat de exacte bug is, hoe deze tot een exploit kan leiden, in welke versies/varianten de bug voorkomt, eventueel hoe hij te exploiten is, enz, enz) publiek bekend gemaakt wordt. Full-disclosure is imho de enige goede manier om met exploits om te gaan.

Dat neemt niet weg dat voor de publieke bekendmaking de vendor van het product geinformeerd mag worden en tijd mag krijgen om het te fixen, en dat is wat de policy van securityfocus en deze nieuwe richtlijnen over gaan.

Het protocol van BugTraq gaat er van uit dat er alleen maar bedrijven zijn die zich onwelwillend opstellen t.o.v. bughunters en dat de omgekeerde situatie - bughunters die zich onwelwillend opstellen t.o.v. een bedrijf - niet bestaat.

Jawel, maar waarom noemen we die mensen onwelwillend? Omdat ze zich niet aan dat - behoorlijk geaccepteerde - protocol van securityfocus houden.
Waarom zouden deze onwelwillende mensen zich dan plotseling wel aan deze nieuwe richtlijnen houden? Omdat ze ineens wel lief willen zijn? Lijkt me sterk.

[Tha Man]

.....wat? [i] op bugtraq/full-disclosure plempen? [\i]

Serieus, leg eens uit want ik snap er niks van

(geen troll ofzo dus)

[Brahiewahiewa]

Zeg vertel eens, wat zou NOG een code of conduct daar aan veranderen?

Het protocol van BugTraq gaat er van uit dat er alleen maar bedrijven zijn die zich onwelwillend opstellen t.o.v. bughunters en dat de omgekeerde situatie - bughunters die zich onwelwillend opstellen t.o.v. een bedrijf - niet bestaat.
Ondertussen is wel gebleken dat bughunters lang niet altijd edele motieven hebben. De code of conduct is een poging om een eenduidige beleidslijn voor die situatie vast te stellen.

[Woudloper]

Allereest moet ik zeggen dat ik dit een zeer goed idee vind, maar ik weet niet of het verstandig is om altijd bugs meteen te melden en op de website te zetten alvorens je er een oplossing voor hebt...

Persoonlijk vind ik hetgeen was Microsoft soms doet, nl. een patch uitbrengen voor een onbekende bug wel goed aangezien je dan meteen een oplossing hebt voor een potentiële bedreiging aan jouw software

[Bobco]

Persoonlijk vind ik hetgeen was Microsoft soms doet, nl. een patch uitbrengen voor een onbekende bug wel goed aangezien je dan meteen een oplossing hebt voor een potentiële bedreiging aan jouw software

Het probleem met deze manier van werken is dus dat je, voordat er een patch wordt uitgebracht, zelf niet weet dat je vulnerable bent. Als een softwareleverancier er erg lang over doet om een patch uit te brengen dan ben je dus, in ieder geval in theorie en soms ook in de praktijk, lange tijd kwetsbaar zonder dat je dat weet, en wat nog belangrijker is: zonder dat je er zelf iets aan kan doen.

Natuurlijk heeft een bugmelder een verantwoordelijkheid, maar op het moment dat vulnerabilities niet openbaar worden gemaakt heeft een leverancier minder prikkels om er snel iets aan te doen dan wanneer de vulnerability wel openbaar is.

Het grote probleem met de benadering van 'we houden het stil tot we een oplossing hebben' is dat er een behoorlijke periode kan zijn waarin iedereen die het produkt gebruik kwetsbaar is, zonder er van op de hoogte te zijn. Dit soort kennis is niet tot in het oneindige verborgen te houden, en als 1 iemand zo'n lek kan vinden kunnen meer mensen dat.

Die eerste kan zich best aan de hier voorgestelde regeling houden, de anderen doen dat misschien niet, met alle mogelijke gevolgen van dien...

[Verwijderd]

Nou, ik heb voorkeur voor Bugzilla... maar dat MS daar geen interesse in heeft zal niemand verbazen..

Wel is het de moeite waard om er even bij stil te staan:

http://www.bugzilla.org/about.html

[boner]

volgens Dykstra is er een verschil tussen een BUG en een programmeerfout.

Aangezient bug tegenwoordig niet meer kunnen, omdat er geen mechanische onderdelenen gebruikt worden waar diertjes tussen kunnen zitten is de term BUG dus niet meer te gebruiken.

Over programmeerfouten was Dykstra al helemaal duidelijk. Het komt er op neer dat elke programmeerfout een onvergeeflijke stupiditeit van de programmeer zou zijn, waar diegene door de juiste methoden te gebruiken zich tegen had kunnen wapenen.

voor diegenen die het niet weten: Dykstra is de 'uitvinder' van gestructureerd programmeren en heeft ook een wiskundig bewijsbare manier van programmeren uitgedacht.

RAD heeft hij altijd een gruwel gevonden......

[Pooh]

Dijkstra gebruikt 'bug' echt niet alleen voor mechanische onderdelen waar diertjes in kunnen zitten, maar voor elke fout die geen programmeerfout is. Dat komt nog regelmatig voor, maar noemen wij over 't algemeen "hardware-falen". Te denken valt aan brak geheugen, een processor die kuren heeft, en dergelijke...
Overigens denk ik dat compiler-fouten/incompatibiliteten ook als 'bug' kunnen worden opgevat. (Wanneer een programma correct geschreven is, maar de compiler er een zootje van maakt, kun je dat moeilijk een 'programmeerfout' noemen).

[Treenaks]

Programmeurs zijn mensen, en mensen maken fouten, hoe hard je ook controleert.

De beste oplossing lijkt mij zoals het is: meld het aan de fabrikant, en als die niet binnen een bepaalde tijd reageert (zo van 'we zijn bezig met de fix, en denken dan-en-dan klaar te zijn) de fout publiceren.

En dan is er natuurlijk nog het probleem met de inherente insecurity van enkele OSen.. maar da's een ander verhaal.

[deadinspace]

Stuurlui, wal?

Programmeren an sich is relatief eenvoudig, maar een groot programma met strenge eisen aan features, performance en betrouwbaarheid maken is moeilijk.
Dat komt omdat een groot programma met dergelijke eisen erg complex wordt, wat een typo of thinko verstrekkende maar onopvallende gevolgen kan geven.

[Verwijderd]

Alle extra aandacht voor veiligheid is een goede zaak.
Maar veiligheid wordt niet gegarandeerd via deze of gene publicatie-procedure. De aangesloten bedrijven moeten juist hun INTERNE software ontwikkelingsprocedures tegen het licht houden.
Microsoft is daar mee bezig en dat is een goede zaak. Maar ja, ze moeten natuurlijk ook van heel ver komen...

[Verwijderd]

Naar mijn idee heeft de software industrie toch alleen maar voordeel dat hackers de software proberen te kraken om te voorkomen dat crackers er misbruik van kunnen maken

[Raafz0r]

Het hele artikel (althans, de samenvatting, heb de rest nog niet gelezen) zegt niks over hackers/crackers. Alleen dat er een richtlijn moet komen over bugmeldingen.

En wat mij betreft is dat een zeer goed initiatief, zolang er na het melden van een bug ook meteen actie wordt ondernomen en de bugmelder op de hoogte wordt gehouden van de status.

Mocht dat niet gebeuren lijkt het mij gerechtvaardigd om de bug openbaar te maken na een maand (klokkenluider principe).

[Woudloper]

En wat mij betreft is dat een zeer goed initiatief, zolang er na het melden van een bug ook meteen actie wordt ondernomen en de bugmelder op de hoogte wordt gehouden van de status.

Zoals ik ook al zeg in onderstaande posting is dit wel erg belangrijk en daarom lijkt het mij in sommige gevallen een stuk beter te wachten met het bekend maken van een bug alvorens er een oplossing (c.q. patch) is voor dat specifieke probleem.

[KinkyClown]

Dan kom je op de nieuwe wet die ze willen aannemen (of hebben aangenomen?) dat je dan strafbaar bent. Men wil iedereen tegenhouden van dergelijke fouten openbaar maken. Als het bedrijf het lek niet dichten willen ze dat het gewoon niet bekend worden. Een tijdslimiet zou prima zijn. Maar uiteindelijke moet het wel bekend worden gemaakt dat er een lek in de software zit...

[Martien]

Leer eerst het verschil tussen hackers en crackers eens voordat je begint te blaaten...

[Verwijderd]

Het komt neer op dat als bijvoorbeeld iemand z'n voordeur niet goed op slot heeft zitten, dat je dat alleen aan de huiseigenaar verteld, en niet in de krant zet.

[Firefly III]

De richtlijnen voor het openbaar maken van bugs zullen niet meer zijn dan een advies, zo zegt de organisatie.

Er komt dus helemaal niks van terecht. Leuk initiatief, maar doe er dan ook iets aan.

[Tha Man]

Precies! Het is sowieso een beetje verdacht dat ze daar geen sancties op leggen. Komt denk ik doordat ze dan zelf ook veel te veel moeten gaan letten op eigen bugs. Microsoft spant daarmee namelijk wel de kroon dus zullen ze toch wel voorzichtig blijven met dit soort voorschriften.
Dat advies, zal dat een advies zijn in de trent van: "U kunt het beter zo of zo doen", of meer "Wij doen het zo, dus u moet het ook doen."?! Dat geet nogal een andere kijk op dit iniatief. Als dit namelijk een manier is om anderen te dwingen om hun richtlijnen na te volgen (door bijv. gezamelijk een standaard af te spreken en daarmee veel naam en faam verwerven, zoals Microsoft sowieso al heeft gedaan) is het erg fout. Dan krijg je nog meer vernouwing op de markt. Dan krijgen nog minder bedrijven kans om het op 'hun manier' te doen...
Ik verwacht er voorlopig niet veel goeds van. Laat ze het eerst maar wat verder uitdenken en dan zien we wel verder.

[deadinspace]

Precies! Het is sowieso een beetje verdacht dat ze daar geen sancties op leggen.

Hier sancties op leggen is extreem dom. Niet alleen druist het in tegen vrijheid van meningsuiting, het werkt op de lange termijn ook alleen maar averechts.

Als je bedrijven op deze manier in de watten legt mbt security-problemen, dan kweek je laksheid bij die bedrijven (nog erger dan al het geval is bij sommige bedrijven):
- "O, we moeten die exploit nog fixen!"
- "Ach, dat kan wachten... De ontdekker mag het toch niet openbaar maken."

Ook schrik je zo de mensen die dit soort bugs ontdekken en melden af. Zeg nou zelf, zou jij nog moeite doen om een exploit te melden als je het risico op een boete of zelfs gevangenisstraf loopt?

[Illegal_Alien]

Lijkt mij een goed initiatief, nu er nog geen richtlijn bestaat kan je gelijk alles in het publiek gooien... Eindelijk doen de amirikanen/de rest van de wereld iets goed

[Aetje]

Amerikanen stellen het publiek maken van exploits strafbaar op het moment... Was recent nog een headline over.

Ik ben dat bedrijven inzien dat andere initiatieven meer effect hebben.

[Rembert]

Waarom gaan ze niet gewoon allemaal een bugzilla achtig systeem gebruiken. Werkt prima, al mag er nog wel worden gesleuteld aan de userinterface.

[deadinspace]

Omdat het gaat over het feit dat je de vendor van een product de tijd hoort te geven het probleem op te lossen alvorens het publiek te maken, en dat heeft niks te maken met welke bugreporting/tracking software je gebruikt.

[Verwijderd]

Dykstra weet niet beter.. als ie nou de 'uitvinder' van Object Oriented Programming was, had ie nog recht van spreken