mboost-dp1
Microsoft Corporation
buchi (1) skrev:Se, det er jo det alle altid har hafft mulighed for med open source produkter...
Måske har MS indset det :D
A Matter of National Security: Microsoft Government Security Program Provides National Governments with Access to Windows Source Code
Q&A: A new Microsoft initiative provides government agencies with the technical information they need to be confident in the security features of the Microsoft Windows platform.
Craig Mundie, senior vice president and chief technical officer of advanced strategies and policies
REDMOND, Wash., Jan. 14, 2003
http://www.microsoft.com/presspass/features/2003/J...
#4: hvorfor det? En lille konspirationsteori?
"Aftalen er gratis for den danske stat og er kommet i stand, fordi it har fået en stadig mere kritisk rolle i samfundet, for eksempel i styringen af elkraftværker og som infrastruktur i sundhedssektoren." http://www.version2.dk/artikel/14440-microsoft-giv...
"Aftalen er gratis for den danske stat og er kommet i stand, fordi it har fået en stadig mere kritisk rolle i samfundet, for eksempel i styringen af elkraftværker og som infrastruktur i sundhedssektoren." http://www.version2.dk/artikel/14440-microsoft-giv...
#8
Man kan jo overveje hvorfor Microsoft ikke allerede har fundet sikkerhedshullerne og fixed dem, hvis det var så nemt at finde dem.
Kode er ligesom når man stiller dominobrikker op på række... Når det hele kører, og der er noget der ikke vælter rigtigt, så er det nemt at se der var noget der ikke virkede... Men står man inden er det altså rimeligt svært at se om det hele nu lige vil falde rigtigt...
Man kan jo overveje hvorfor Microsoft ikke allerede har fundet sikkerhedshullerne og fixed dem, hvis det var så nemt at finde dem.
Kode er ligesom når man stiller dominobrikker op på række... Når det hele kører, og der er noget der ikke vælter rigtigt, så er det nemt at se der var noget der ikke virkede... Men står man inden er det altså rimeligt svært at se om det hele nu lige vil falde rigtigt...
TormDK (9) skrev:Windows er jo et spindelvæv uden lige af ting og sager.
"Security through obscurity" er sjældent nogen god strategi. Hackere har gennem tiden fundet tonsvis af huller i Windows uden at kunne se kildekoden, så hvorfor skulle man ikke have lettere mulighed for det med adgang til koden?
#8
Vi lever jo i demokrati. Staten er styret af politikere som du og jeg har valgt (hvis du er over 18 :P). Tror ikke man skal være bange for at blive overvåget af staten - men nærmere hvis personlige oplysninger falder i hænder på de forkerte folk.
Staten er blevet helt vild med at overvåge borgerne de seneste år.
Vi lever jo i demokrati. Staten er styret af politikere som du og jeg har valgt (hvis du er over 18 :P). Tror ikke man skal være bange for at blive overvåget af staten - men nærmere hvis personlige oplysninger falder i hænder på de forkerte folk.
kr00z0r (5) skrev:
Så får staten mulighed for at opdage sikkerhedshuller de kan udnytte til at overvåge borgerne, uden at alnindelige brugere ved at de eksisterer. Betryggende.
Hvordan skulle adgang til kildekoden lige hjælpe på det?
Spyware virker fint når det er udviklet uden adgang til til kildekoden, og størstedelen af danske internet forbindelser bruger alligevel en NAT enhed som er i vejen for at kunne udnytte huller direkte.
Integration med sikkerhedssoftware til eget brug lyder meget mere sandsynligt.
kr00z0r (8) skrev:
2. Man har større mulighed for at opdage sikkerhedshuller hvis man har adgang til kildekoden.
det er lidt af en påstand som du da gerne må underbygge med lidt fakta... Du ved bare sådan for sjovs skyld eller så det er muligt at andet du kommer med bare en smule seriøst.
#22 Jamen for fanden..........
Har du nogensinde prøvet at sidde i IDA og reverse engineere C++ der benytter sig af klasser, virtuelle funktioner, polimorphisme, stl algoritmer, templates og boost?!??
Det er logik at det er nemmere at finde sikkerheds fejl når man har c++ koden istedet for assembly koden.
Har du nogensinde prøvet at sidde i IDA og reverse engineere C++ der benytter sig af klasser, virtuelle funktioner, polimorphisme, stl algoritmer, templates og boost?!??
Det er logik at det er nemmere at finde sikkerheds fejl når man har c++ koden istedet for assembly koden.
moveax1ret (23) skrev:#22 Jamen for fanden..........
Har du nogensinde prøvet at sidde i IDA og reverse engineere C++ der benytter sig af klasser, virtuelle funktioner, polimorphisme, stl algoritmer, templates og boost?!??
Det er logik at det er nemmere at finde sikkerheds fejl når man har c++ koden istedet for assembly koden.
Ja jeg har prøvet IDA pro. Ommend i demo versionen og derfor en ret skrabet version. Men det ændrer ikke på at du stadig ikke har dokumenteret din påstand..?
#24 selv med pluginnet fra hexrays er det stadigtvæk et mareridt at regne ud hvad fanden der foregår( den kan give hints).
Vi er ovre den periode hvor at buffer overflows var den eneste måde man kunne exploite software( hvilket er nemt at finde med en simpel statisk analyse).
For at finde fejl i det logiske flow i et program har du altså brug for source kode....medmindre du læser assembly ligeså nemt som c++.
Det er altså ikke noget man kan dokumentere....regner du med at jeg lige trækker en undersøgelse ud af ærmet hvor man har bedt 400 testpersoner om at finde sikkerheds fejl i en test applikation- og den ene halvdel har sourcekoden, den anden har ikke.
Det er aldrigt undersøgt da det er logik.
Vi er ovre den periode hvor at buffer overflows var den eneste måde man kunne exploite software( hvilket er nemt at finde med en simpel statisk analyse).
For at finde fejl i det logiske flow i et program har du altså brug for source kode....medmindre du læser assembly ligeså nemt som c++.
Det er altså ikke noget man kan dokumentere....regner du med at jeg lige trækker en undersøgelse ud af ærmet hvor man har bedt 400 testpersoner om at finde sikkerheds fejl i en test applikation- og den ene halvdel har sourcekoden, den anden har ikke.
Det er aldrigt undersøgt da det er logik.
Hvis du kan assembly og c++ synes jeg at du skal prøve at compile denne challenge: http://chargen.matasano.com/chargen/2009/10/9/a-c-...
og så prøve at finde og exploite vulnerabilitien uden at kigge på sourcen.
Så bagefter(hvis det lykkes) prøv uden sourcen.
og så prøve at finde og exploite vulnerabilitien uden at kigge på sourcen.
Så bagefter(hvis det lykkes) prøv uden sourcen.
moveax1ret (25) skrev:#24 selv med pluginnet fra hexrays er det stadigtvæk et mareridt at regne ud hvad fanden der foregår( den kan give hints).
Vi er ovre den periode hvor at buffer overflows var den eneste måde man kunne exploite software( hvilket er nemt at finde med en simpel statisk analyse).
For at finde fejl i det logiske flow i et program har du altså brug for source kode....medmindre du læser assembly ligeså nemt som c++.
Det er altså ikke noget man kan dokumentere....regner du med at jeg lige trækker en undersøgelse ud af ærmet hvor man har bedt 400 testpersoner om at finde sikkerheds fejl i en test applikation- og den ene halvdel har sourcekoden, den anden har ikke.
Det er aldrigt undersøgt da det er logik.
Det er så godt nok undersøgt. Jeg kan desværre ikke lige finde undersøgelsen. Godt nok på en noget mindre skala end 400 folk. Der var så vidt jeg lige husker 15 med i undersøgelsen. De fandt 4 ud af 25 fejl ved at se på koden. Så skal vi ikke lige overveje hvorvidt det er logisk alligevel..?
Den undersøgelse vil jeg gerne se, da jeg er sikker på at enten har du misforstået noget og draget forkerte konklusioner- eller også har testgruppen været så lille at det eneste det kom an på var skills ved de personer der lavede testen, og tilfældigtvis faldt det ud til dem uden sources fordel.
Det skal lige siges at den challenge jeg har linket til er et simpelt POC, forestil dig at source koden er 10000 gange større, det er simpelthen umuligt at finde rundt i alt det assembly, især hvis det er statisk linket med andre libaries.
Måden alle exploit finders gør den slags på er ved at stille og roligt reverse engineere det til læsbart c eller c++, for at danne sig et overblik, og så leder efter sårbarhederne.
Alene problemet med at assembly er virkeligt svært at danne sig et overblik over uden virkeligt verbose comments er svært- men du har også mistet alle navne på alle funktioner, objekter, variabler etc.
Du har brug for noget læsbart.
Måden alle exploit finders gør den slags på er ved at stille og roligt reverse engineere det til læsbart c eller c++, for at danne sig et overblik, og så leder efter sårbarhederne.
Alene problemet med at assembly er virkeligt svært at danne sig et overblik over uden virkeligt verbose comments er svært- men du har også mistet alle navne på alle funktioner, objekter, variabler etc.
Du har brug for noget læsbart.
#9
Jeps.
Jeg har lidt svært ved at se hvad den danske IT og Tele Styrelse vil med noget i størrelsesordenen 100 millioner linie source code.
Et simpelt review af hele koden vil tage ca. 1500 mand år.
Man kan naturligvis nøjes med bare at kigge på det mest relevante fra et sikkerhedsperspektiv, men det tager også lang tid at udvælge dette.
Jeps.
Jeg har lidt svært ved at se hvad den danske IT og Tele Styrelse vil med noget i størrelsesordenen 100 millioner linie source code.
Et simpelt review af hele koden vil tage ca. 1500 mand år.
Man kan naturligvis nøjes med bare at kigge på det mest relevante fra et sikkerhedsperspektiv, men det tager også lang tid at udvælge dette.
#source & bugs
Selvfølgelig er det nemmere at finde bugs i source code. Af de 3 muligheder:
A) læse source code
B) kigge på assembler produceret af disassembler
C) black box test
er A langt den hurtigste.
Det er det som er fordelen ved at offentliggøre koden!
Bugs bliver hurtigere fundet.
Det forudsætter naturligvis at der er flere good guys end bad guys som læser koden.
Men det er uden tvivl tilfældet i IT og Tele Styrelsen (medmindre man er til konspiratiosn teorier omkring den fæle danske stat).
Og det er også tilfældet i mange af de mest brugte open source applikationer.
Selvfølgelig er det nemmere at finde bugs i source code. Af de 3 muligheder:
A) læse source code
B) kigge på assembler produceret af disassembler
C) black box test
er A langt den hurtigste.
Det er det som er fordelen ved at offentliggøre koden!
Bugs bliver hurtigere fundet.
Det forudsætter naturligvis at der er flere good guys end bad guys som læser koden.
Men det er uden tvivl tilfældet i IT og Tele Styrelsen (medmindre man er til konspiratiosn teorier omkring den fæle danske stat).
Og det er også tilfældet i mange af de mest brugte open source applikationer.
#fortsat fra 32
Mere specifikt så synes de open source produkter som henvender sig til IT professionelle at have en god track record. For Linux, *BSD, Apache, PHP, MySQL etc. synes good guys generelt at være i stand til at finde og lukke hullerne hurtigere end bad guys er i stand til at finde og udnytte hullerne.
Det er lidt mere grumset, når vi snakker open source produkter som henvender sig til folk uden speciel IT viden. Her tænker jeg bl.a. på diverse PHP CMS & fora apps. En del af disse har vist sig hullede som en si. Formentligt fordi at de typiske brugere af den slags download, udpak, ret config.inc.php og du har en kørende app hverken har evner eller interesse for at checke koden.
Mere specifikt så synes de open source produkter som henvender sig til IT professionelle at have en god track record. For Linux, *BSD, Apache, PHP, MySQL etc. synes good guys generelt at være i stand til at finde og lukke hullerne hurtigere end bad guys er i stand til at finde og udnytte hullerne.
Det er lidt mere grumset, når vi snakker open source produkter som henvender sig til folk uden speciel IT viden. Her tænker jeg bl.a. på diverse PHP CMS & fora apps. En del af disse har vist sig hullede som en si. Formentligt fordi at de typiske brugere af den slags download, udpak, ret config.inc.php og du har en kørende app hverken har evner eller interesse for at checke koden.
#Hulbert
Jeg kom lige i tanke om et andet eksempel i badet.
Forestil dig at du får en exe fil der er lavet i c++ og statisk linker til xerces, xmlsec og openssl. Forestil dig så at skulle med en disassembler/debugger at finde ud af om en xmlsignerings subrutine bruger RC4 eller AES.
Forestil dig nu det samme i c++.
Det ene kan tage en halv dag til 2, det andet 10-30 minutter.
Jeg kom lige i tanke om et andet eksempel i badet.
Forestil dig at du får en exe fil der er lavet i c++ og statisk linker til xerces, xmlsec og openssl. Forestil dig så at skulle med en disassembler/debugger at finde ud af om en xmlsignerings subrutine bruger RC4 eller AES.
Forestil dig nu det samme i c++.
Det ene kan tage en halv dag til 2, det andet 10-30 minutter.
Noget jeg sad og tænkte over, som man måske kan starte en debat på;
Ville det være ok hvis nogen i GovCert el. lign. lækkede kildekoden til nettet? evt. gennem wikileaks?
Ville det være ok hvis nogen i GovCert el. lign. lækkede kildekoden til nettet? evt. gennem wikileaks?
#36 Nej
Om det faktisk ville ændre på noget i forhold til indtægter for microsoft er en helt anden diskussion- men det er ikke ok.
Om det faktisk ville ændre på noget i forhold til indtægter for microsoft er en helt anden diskussion- men det er ikke ok.
#36
MS kunne formentligt få det fjernet da det er en klokkeklar overtrædelse af copyright.
Det ville skade GovCert og Danmarks ry.
Det vil næppe have den store betydning.
Formentlig vil den lille betydning være negativ. Good guys vil mene at det er MS som skal betale for at checke koden ikke brugerne, når de nu betaler for produktet.
Så det lyder ikke som en specielt god ide.
(Der er vist allerede lækket kopier af Windows koden tidligere=
MS kunne formentligt få det fjernet da det er en klokkeklar overtrædelse af copyright.
Det ville skade GovCert og Danmarks ry.
Det vil næppe have den store betydning.
Formentlig vil den lille betydning være negativ. Good guys vil mene at det er MS som skal betale for at checke koden ikke brugerne, når de nu betaler for produktet.
Så det lyder ikke som en specielt god ide.
(Der er vist allerede lækket kopier af Windows koden tidligere=
#39- Enig. Der er ingen grund til at microsoft holder kilden lukket der kan retfærdiggøres, men det er deres valg. Derfor er en leak ikke ok
moveax1ret (28) skrev:Den undersøgelse vil jeg gerne se, da jeg er sikker på at enten har du misforstået noget og draget forkerte konklusioner- eller også har testgruppen været så lille at det eneste det kom an på var skills ved de personer der lavede testen, og tilfældigtvis faldt det ud til dem uden sources fordel.
Jeg har gengivet det som jeg lige huskede det. Jeg er ikke helt sikker på antallet af folk der skulle se på koden men jeg er 00% sikker på at der var 25 fejl og at de kun fandt de 4 af dem. Jeg har ikke selv draget konklusioner ud af rapporten. Jeg har kun fået den refereret af en anden.
arne_v (32) skrev:#source & bugs
Selvfølgelig er det nemmere at finde bugs i source code. Af de 3 muligheder:
A) læse source code
B) kigge på assembler produceret af disassembler
C) black box test
er A langt den hurtigste.
Det er det som er fordelen ved at offentliggøre koden!
Bugs bliver hurtigere fundet.
Det forudsætter naturligvis at der er flere good guys end bad guys som læser koden.
Men det er uden tvivl tilfældet i IT og Tele Styrelsen (medmindre man er til konspiratiosn teorier omkring den fæle danske stat).
Og det er også tilfældet i mange af de mest brugte open source applikationer.
Er det ikke ved at være en skrøne at fejl bliver fundet på grund af at source koden er tilgængeligt..?
Vi kan jo se på ssl adæsen hos Debian. Var det ikke 2 år der gik?
Hubert (41) skrev:Jeg har gengivet det som jeg lige huskede det. Jeg er ikke helt sikker på antallet af folk der skulle se på koden men jeg er 00% sikker på at der var 25 fejl og at de kun fandt de 4 af dem. Jeg har ikke selv draget konklusioner ud af rapporten. Jeg har kun fået den refereret af en anden.
Du konkluderede at det var relevant i source vs ikke-source diskussionen.
Hvilket det åbenlyst ikke er.
Der er nemlig ingen som har påstået at code review finder alle fejl.
Påstanden er at de 15 (eller hvormange det nu er) ville have fundet færre fejl end de 4 ved brug af samme mængde tid på andre metoder end source code review.
#42
Det virker som om du konkluderer at fordi en eller anden ikke kan finde alle fejl ved at kigge i sourcekoden hjælper det ikke at kunne se sourcekoden. Hvilket er forkert.
Angående debian fejlen skete fejlen jo da en knold ved debian kørt en valgrind på ssh sourcekoden, og så at valgrind/lint opdagede at noget memory ikke blev sat til 00000 etc. inden det blev taget i brug.
der stod så en kommertar ca. sådan her # DO NOT TOUCH THIS UNLESS YOU REALLY KNOW WHAT YOU ARE DOING
alligevel lavede debian fjolset en memset på hukommelses området der blev brug til en random seed i en pseudo random algoritme.
Fejlen har altså intet at gøre med om sourcekoden kan ses eller ej, men ren sjusk og idioti ved debian.
Og grunden til at det ikke blev opdaget( og dit argument for source access ikke gør det nemmere at opdage fejl) var at det skete helt ude ved debian- ikke inde ved dem der udvikler ssh.
Så der var ingen der reviede de rettelser, og ingen der læste koden inden den nåede ud til slutbrugerne.
Det kan ikke bruges som et argument.
Det virker som om du konkluderer at fordi en eller anden ikke kan finde alle fejl ved at kigge i sourcekoden hjælper det ikke at kunne se sourcekoden. Hvilket er forkert.
Angående debian fejlen skete fejlen jo da en knold ved debian kørt en valgrind på ssh sourcekoden, og så at valgrind/lint opdagede at noget memory ikke blev sat til 00000 etc. inden det blev taget i brug.
der stod så en kommertar ca. sådan her # DO NOT TOUCH THIS UNLESS YOU REALLY KNOW WHAT YOU ARE DOING
alligevel lavede debian fjolset en memset på hukommelses området der blev brug til en random seed i en pseudo random algoritme.
Fejlen har altså intet at gøre med om sourcekoden kan ses eller ej, men ren sjusk og idioti ved debian.
Og grunden til at det ikke blev opdaget( og dit argument for source access ikke gør det nemmere at opdage fejl) var at det skete helt ude ved debian- ikke inde ved dem der udvikler ssh.
Så der var ingen der reviede de rettelser, og ingen der læste koden inden den nåede ud til slutbrugerne.
Det kan ikke bruges som et argument.
Hubert (42) skrev:
Er det ikke ved at være en skrøne at fejl bliver fundet på grund af at source koden er tilgængeligt..?
Vi kan jo se på ssl adæsen hos Debian. Var det ikke 2 år der gik?
????
Fejlen blev vel fundet ved at kigge i source koden!?
Hvis det havde været closed source, så kunne fejlen have eksisteret endnu.
Så selvom 2 år er lang tid, så er sent jo stadig bedre end aldrig.
arne_v (43) skrev:Du konkluderede at det var relevant i source vs ikke-source diskussionen.
Hvilket det åbenlyst ikke er.
Der er nemlig ingen som har påstået at code review finder alle fejl.
Påstanden er at de 15 (eller hvormange det nu er) ville have fundet færre fejl end de 4 ved brug af samme mængde tid på andre metoder end source code review.
Nej... Jeg bad om underbyggende fakta for at man kunne finde fejl ved at have adgang til koden. SSL fadæsen (nu med 'f') viser jo meget godt at det nok kræver lidt kendskab. Andre steder er det kommet frem at der er i omegnen af en milliard så mon ikke der går noget tid inden de finder den første fejl..?
Det her handler forresten slet ikke om open source......det handler ene og alene om det er nemmere at finde fejl når man har sourcekoden end når man har en binær fil. Hvilket der ikke kan være tvivl om.
Hubert (46) skrev:Jeg bad om underbyggende fakta for at man kunne finde fejl ved at have adgang til koden.
Det er som at bede om underbyggende fakta for at 2+2 er 4.
Alle udviklere finder fejl i kode ved at kigge på koden.
Hubert (46) skrev:SSL fadæsen (nu med 'f') viser jo meget godt at det nok kræver lidt kendskab.
Et godt resultat af code review kræver at dem der reviewer både har viden om programmering og om den specifikke logik der skal implementeres.
Men det er ret generelt at det giver bedst resultater hvis dem der udfører arbejdet ikke er totalt clueless.
Hubert (46) skrev:Andre steder er det kommet frem at der er i omegnen af en milliard så mon ikke der går noget tid inden de finder den første fejl..?
Hvis du mener at Windows plus MS Office skulle have en milliard linier kode tilsammen, så er der nogen der har misforstået noget. 100 millioner er et langt bedre gæt.
Man regner med at som udgangspunkt er der 1 fejl per 1000 linier kode. Med 100 millioner linie kode, så er der 100000 fejl at finde. Selvom MS skulle have fundet 90% er der stadig masser at komme efter.
Hvis IT & Tele Styrelsen altså har nogen folk at sætte til at lede.
Hvilke jeg tvivler på.
#49
Jeg vil nærmere sige 1-5 bugs per tusind linier når min kode bliver shipped. Jeg ville tit ønske jeg havde mere tid til at gøre det perfekt, men det har jeg ikke.
Men jeg kan heller ikke udelukke at jeg bare er en ringe/langsom programmør.
Jeg vil nærmere sige 1-5 bugs per tusind linier når min kode bliver shipped. Jeg ville tit ønske jeg havde mere tid til at gøre det perfekt, men det har jeg ikke.
Men jeg kan heller ikke udelukke at jeg bare er en ringe/langsom programmør.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund