'Meer gaten in Firefox, maar sneller gedicht'

Anonymous Coward op Vrijdag 6 Maart 2009 13:06

In de vergelijking op de firefox site ( http://www.mozilla-europe.org/img/nl/3-riskdays-security.png ) ( mijn favoriete browser trouwens) is toch wat oneerlijk dat Firefox alleen de dagen telt in de eigen meest recente versie terwijl ze bij IE alle gebruikte versies op een hoop gooien. Dat is een oneerlijke vertekening van het beeld. Dan zou men ook alle Firefox versies moeten telen om tenminste de indruk te wekken dat je een representatieve vergelijking maakt.
Belangrijker nog is dat alle browsers duidelijk op de goede weg zijn en dat onderlinge verschillen gelukkig afnemen ipv toenemen.

4 / 12

Anonymous Coward op Vrijdag 6 Maart 2009 14:35

Oude browserversies (FF 1.x en 2.x) zijn bij Firefox niet meer supported.
Op zich is het niet zo gek dat ze alleen supported versies meetellen omdat vunerabilities in unsupportedversies nooit meer gepatched zullen worden.

Het vertekent inderdaad wel de cijfers iets maar dat zou ook het geval zijn als je ze wel mee zou tellen

-1 / 11

bokkie20000 op Vrijdag 6 Maart 2009 23:39

Het zou pas echt leuk zijn als alle browserbouwers zich eens aan 1 standaard zouden houden en als alle webbuilders diezelfde standaard zouden gebruiken want ik vind het nog steeds een zootje en ben niet van plan om steeds maar weer van browser te wisselen om bepaalde pagina's te kunnen bekijken :-(

3 / 3

Janno op Vrijdag 6 Maart 2009 13:29

Goed dat er nog maar eens op wordt gewezen dat IE vulns potentieel gevaarlijker zijn omdat deze browser zo innig is vervlochten met Windows.

11 / 15

Gregorius op Vrijdag 6 Maart 2009 13:33

Belangrijker nog is dat alle browsers duidelijk op de goede weg zijn
IE pas sinds kort. De andere browsers zitten al jaren op de goede weg.
en dat onderlinge verschillen gelukkig afnemen ipv toenemen.
De onderlinge verschillen tussen de diverse browsers was al klein.
Uitgezonderd IE, die wil altijd alles anders doen en incompatibel zijn.
Pas met IE8 komt daar wat verandering in.

4 / 10

xfinxr2i op Vrijdag 6 Maart 2009 13:58

Gregorius, IE8 loopt nog steeds ver achter. Alle browsers zijn flink aan het klussen aan hun JS-engine... behalve...

6 / 10

Anonymous Coward op Vrijdag 6 Maart 2009 15:00

De nieuwe IE8 javascript engine is ook sterk verbeterd.

-5 / 13

Gregorius op Vrijdag 6 Maart 2009 15:01

... aldus onze microsoft medewerker.

-1 / 19

Anonymous Coward op Vrijdag 6 Maart 2009 15:18

...beweert de altijd onjuiste Gregorius onbenul.

-12 / 20

Anonymous Coward op Vrijdag 6 Maart 2009 18:33

Is je toetsenbord stuk dat je weer moet beginnen met je handelsmerk : lomp schelden...?

Iedereen weet hier toch al lang dat je M$-werknemer bent die de fora moet afschuimen om M$ in een leugenachtig zo positief mogelijk daglicht te stellen. Lukt wel voor geen millimeter...

Heel doorzichtig hoor ;-)

6 / 16

Anonymous Coward op Zaterdag 7 Maart 2009 10:45

nog een onbenul die er weer naast zit (zoals meestal).

-4 / 10

Anonymous Coward op Zaterdag 7 Maart 2009 12:50

Het ligt deze keer duidelijk niet aan het toetsenbord, maar duidelijk aan het onbenul achter het toetsenbord ;-)

0 / 8

Anonymous Coward op Zaterdag 7 Maart 2009 13:15

Blij dat je dat zelf inziet.
Het kostte in het verleden wel eens meer moeite je te overtuigen.

-4 / 10

Karel van Santen op Vrijdag 6 Maart 2009 13:59

Bij de veiligheid rondom browsers speelt de controleerbaarheid van de browser zelf (broncode) een belangrijke rol in het vertrouwen van een gebruiker in een browser. Ik ben niet technisch genoeg om dit te doen maar heb meer vertrouwen in de veiligheid van Firefox dan IE. Bij Firefox kunnen zowel de ontwikkelaars van Firefox, als onafhankelijke derden en zelfs de ontwikkelaars van IE de (on)veiligheid controleren. Het leuke in dit proces is dat in het geval ontwikkelaars van b.v. IE willen aantonen dat er bugs/onveiligheden in Firefox zitten en dezen melden (zie je wel het is onveilig, daar en daar zit z'n bug) zij automatisch helpen aan het verbeteren van Firefox.

7 / 11

Anonymous Coward op Vrijdag 6 Maart 2009 14:21

De meestgebruikte browser heeft ook het meeste kans op een gevonden lek en voortbouwende op jouw stelling is dus IE de betere dan ;) Daar worden lekker sneller gevonden en zijn de belangen ook groter.

-6 / 14

Gregorius op Vrijdag 6 Maart 2009 14:29

Je vergeet voor het gemak even dat IE closed source is. Hoeveel meer lekken zullen er gevonden worden als de broncode van IE vrijgegeven zou worden...

Dan zou de balans voor IE wel eens vele malen slechter kunnen uitpakken.

6 / 16

Anonymous Coward op Vrijdag 6 Maart 2009 14:42

Dan zou [...sed]kunnen uitpakken. Ja speculeren kun je daar natuurlijk altijd over. Open source is echter niet per definitie veiliger in de praktijk. Ik denk wel dat de oude trdent zou kunnen profiteren van nieuwe inzichten. Waarschijnlijker is echter dat er op termijn een nieuwe engine komt of dat men een open engine neemt als basis, zoals ook safari doet.

-6 / 12

Anonymous Coward op Vrijdag 6 Maart 2009 17:37

Het is best wel leuk om daarover te speculeren, we hebben het hier wel altijd over "gevonden" lekken, maar dat wordt toch voorafgegaan door "zoeken".
Nu is er in het verleden wel eens gesteld dat Windows meer aangevallen wordt omdat er meer gebruikers zijn, dan is het ietwat vreemd dat er bij Ff meer lekken zouden zitten.
Wordt er meer gezocht ondanks het kleinere markt aandeel?
Wordt er meer door de betrokkenen gezocht om "hun" eigen product beter te maken?
Wordt er meer openbaar gevonden tegenover M$ met het "gesloten" systeem?
Zijn er inderdaad Windows veiligheid issues inherent aan het "ingebakken" IE die dus theoretisch tot de IE telling horen?

Het aantal regels code in IE zelf en in Windows ten opzichte van Ff om de theoretische foutmarge te kunnen berekenen vind ik wel een aardige wetenswaardigheid, maar dat gaat niet lukken bij CS.

9 / 9

Anonymous Coward op Vrijdag 6 Maart 2009 14:57

Lekken in gereleasde software worden helemaal niet gevonden via de sources.
Ook niet bij Firefox.

Sources zijn wel handig bij XSS scripting issues in websites omdat je dan eenvoudig beschikt over de juist entiteit en veldnamen in je scripting

-9 / 15

Anonymous Coward op Vrijdag 6 Maart 2009 17:47

Closed source lijkt mij potentieel gevaarlijker omdat een lek, gevonden word door een misbruiker, minder kans heeft opnieuw door een ander gevonden te worden. Bij open source wordt er door meerder gebruikers "gezocht" en gekeken, ik denk dat "lekken" daardoor eerder gevonden worden.
Daarnaast is M$ een commercieel bedrijf, hoeveel budget en manuren geven ze uit aan het "op voorhand" zoeken en door wie, de programmeurs die het gemaakt hebben lopen de kans hun eigen "fouten" opnieuw te maken, bij open source zijn de verschillende ogen op andermans werk weer een voordeel.

8 / 10

EuroMaverick op Vrijdag 6 Maart 2009 23:19

Hoeveel meer lekken zullen er gevonden worden als de broncode van IE vrijgegeven zou worden...
Wil je daarmee zeggen dat closed source per definitie veiliger is ?

De hele discussie van welke browser het meeste lekken heeft, is compleet irrelevant. Het gaat hem erom op welke wijze en hoe snel er met die lekken omgegaan wordt. FireFox mag voor mijn part 10 keer meer lekken hebben als Internet Explorer. Als ze snel en accuraat gepatched worden dan is wat veiligheid betreft dit product even valabel als het Microsoft-alternatief...

Mav.

3 / 7

NLsandman op Vrijdag 6 Maart 2009 23:41

Wil je daarmee zeggen dat closed source per definitie veiliger is ?

Nee, security through obscurity

8 / 8

Anonymous Coward op Zaterdag 7 Maart 2009 09:03

Als ze snel en accuraat gepatched worden dan is wat veiligheid
Omndat helaas veel gebruikers hun software niet patchen zijn lekken altijd een risico.
Het rapport van secunia geeft ook aan dat 7% van de IE7 en 10% van de FF3 installaties niet gepatched is. Dat zijn tientallen mijoenen kwetsbare installaties.

-4 / 6

Kaiser Söze op Vrijdag 6 Maart 2009 15:25

Ik ben niet technisch genoeg om dit te doen maar heb meer vertrouwen in de veiligheid van Firefox dan IE.

Er is toch geen hond die de FF source code gaat doorlopen om vulnerabilities te zoeken, knurft... Als dat wel zou gebeuren zouden er niet zoveel bugs worden gevonden.

-13 / 15

swhnld op Vrijdag 6 Maart 2009 15:35

Er worden wel degelijk bugs gevonden in source codes. Hierbij een eclipse forum discussie over het rapporteren daarvan:
http://dev.eclipse.org/newslists/news.eclipse.newcomer/msg14189.html

10 / 10

MvO op Vrijdag 6 Maart 2009 15:42

Er is toch geen hond die de FF source code gaat doorlopen om vulnerabilities te zoeken
Een kwaadwillende ook niet?

12 / 12

Anonymous Coward op Vrijdag 6 Maart 2009 15:55

Het is voor experts tegenwoordig makkelijker om lekken te vinden in de binary code. Daar kunnen zich ook lekken voordoen die je niet kan zien in de source code maar die je met debugging tools wel kan vinden.

-9 / 15

Gregorius op Vrijdag 6 Maart 2009 16:10

Daar kunnen zich ook lekken voordoen die je niet kan zien in de source code
Dat is interessant, kun je een voorbeeldje geven van een lek wat niet zichtbaar is in de sourcecode?
En als het niet te zien is in de code, hoe kun je het dan patchen?

2 / 12

Anonymous Coward op Vrijdag 6 Maart 2009 16:38

heap overflow vunerabilities bijvoorbeeld. Vaak de gevaarlijkste soort lekken.

Ook al kun je de vunerability niet zien in de code dan kun je nog wel de code aanpassen zodat de situatie waarin de vunerability zich voordoet niet kan voorkomen.

-7 / 15

Gregorius op Vrijdag 6 Maart 2009 16:49

Ook al kun je de vunerability niet zien in de code
Dat kun je wel zien in de code. Een heap overflow treedt op wanneer je je input niet goed genoeg checkt of wanneer de hoeveelheid geheugen die je gereserveerd hebt niet groot genoeg is voor wat je er mee wil doen. In beide gevallen een fout van de programmeur en terug te vinden in de code.

Like all buffer overflows, a heap overflow may be introduced accidentally by an application programmer, or it may result from a deliberate exploit. In either case, the overflow occurs when an application copies more data into a buffer than the buffer was designed to contain.

A routine is vulnerable to an accident or an exploit if it copies data to a buffer without first verifying that the source will fit in the destination.

Bron: http://en.wikipedia.org/wiki/Heap_overflow

7 / 11

Anonymous Coward op Zaterdag 7 Maart 2009 08:59

Dus jij kan door code te lezen zien hoeveel geheugen een applicatie op runtime zal gebruiken en hoe deze door de compiler zal worden ingedeeld ?

-7 / 9

Gregorius op Zaterdag 7 Maart 2009 09:48

Dus jij kan door code te lezen zien hoeveel geheugen een applicatie op runtime zal gebruiken en hoe deze door de compiler zal worden ingedeeld ?
Je kunt zien hoeveel geheugen een applicatie tijdens runtime maximaal zal gebruiken, tenzij je je input niet voldoende checkt.

5 / 7

Gregorius op Zaterdag 7 Maart 2009 10:08

Verander "applicatie" in "buffer".

6 / 8

Anonymous Coward op Zaterdag 7 Maart 2009 10:43

Verander "applicatie" in "buffer".

En laat vervolgens 'maximaal' en het stuk vanaf 'tenzij' weg.

Maar verder klopt het :)

4 / 6

Anonymous Coward op Zaterdag 7 Maart 2009 10:54

Je kunt zien hoeveel geheugen een applicatie tijdens runtime maximaal zal gebruiken

Ik denk niet dat iemand die code leest op byte niveau runtime geheugengebruik kan voorspellen en zelfs nog heb je daar bar weinig aan. Het gaat erom hoe het geheugen wordt gevuld en dat wordt niet bepaald door desource maar door de compiler en door de runtime omgeving waarin runtime gedraaid wordt.

-9 / 11

Gregorius op Zaterdag 7 Maart 2009 11:57

Ik denk ...
Ga eens in de leer bij iemand die echt verstand heeft van programmeren (iemand die weet hoe pointers naar pointers werken b.v.).

In het simpelste geval controleer je iedere keer wanneer je naar een buffer schrijft/leest of je niet buiten je buffer terecht komt.
Maar er zijn ook geavanceerdere methodes om dat te controleren.

Alles staat of valt met het controleren van je input, of dat nu een bestand, gebruikersinvoer of een http-sessie is.
Veel fouten worden gemaakt doordat een programmeur aanneemt dat b.v. een bestand is geschreven volgens het daarvoor geldende formaat. Op het moment dat dat niet het geval is, kunnen er problemen ontstaan.
M.a.w., wanneer je een bestand inleest zal je programma het bestand of eerst helemaal moeten valideren of alle variabelen die gevuld worden met enige inhoud van dat bestand en gebruikt wordt om geheugen te alloceren en/of geheugen te vullen streng moeten controleren. Of een programma dat doet kun je zien in de broncode.

6 / 8

Anonymous Coward op Zaterdag 7 Maart 2009 13:03

Ga zelf eens in de leer bij iemand.
Om bijvoorbeeld de inhoud van een binair bestand te valideren moet je het eerst in het geheugen zetten en eventueel zelfs ook nog omzetten naar valideerbare data. En zelf dan kan ook heel valide data nog steeds malware code bevatten. Zo kan een image viewer niet vooraf bepalen of de image data in een bestand een echt plaatje is of executable code.

-8 / 10

Anonymous Coward op Zaterdag 7 Maart 2009 13:51

Ga zelf eens in de leer bij iemand. Om bijvoorbeeld de inhoud van een binair bestand te valideren moet je het eerst in het geheugen zetten en eventueel zelfs ook nog omzetten naar valideerbare data. En zelf dan kan ook heel valide data nog steeds malware code bevatten. Zo kan een image viewer niet vooraf bepalen of de image data in een bestand een echt plaatje is of executable code.

Hou maar op Baseline, je hebt echt geen flauw idee waar je het over hebt. Dit is gewoon genant.

Een image viewer hoeft niet te weten of de 'image data' eigenlijk 'executable code' is. In het laatste geval laat het gewoon een heel vreemd plaatje zien door 'executable code' als 'image data' te behandelen.

Er ontstaat een probleem als de image viewer een 'unchecked buffer' bevat waardoor de 'image data' via een truuk zichzelf als executable kan laten beschouwen *). Welnu, of er wel of niet een 'unchecked buffer' aanwezig is kun je prima in de source van de image viewer zien.

*) Heel kort door de bocht, ik probeer het op hAL-niveau te houden.

5 / 7

Gregorius op Zaterdag 7 Maart 2009 13:54

Ga zelf eens in de leer bij iemand.
Dat heb ik gedaan, daarom weet ik dat je door de broncode uit te pluizen, kan zien of er een mogelijke bufferoverflow kan plaatsvinden.

Om bijvoorbeeld de inhoud van een binair bestand te valideren moet je het eerst in het geheugen zetten...
Bepaal hoeveel bytes je wil inlezen. Alloceer voldoende geheugen voor je buffer. Copieer niet meer binaire data naar de buffer dan de buffer groot is.
Geen vuiltje aan de lucht.

... en eventueel zelfs ook nog omzetten naar valideerbare data. En zelf dan kan ook heel valide data nog steeds malware code bevatten.
Begrijp ik hier uit dat je uitvoerbare code inleest en dan uitvoert? Daar is geen kruid tegen gewassen, dan ben leg je je lot in de handen van degene die de uitvoerbare code geschreven heeft.
Dat is nergens voor nodig. Voor normale data overdracht en communicatie hoef je geen uitvoerbare code te gebruiken.

Zo kan een image viewer niet vooraf bepalen of de image data in een bestand een echt plaatje is of executable code.
Hier mee geef je duidelijk aan dat je geen kaas gegeten hebt van programmeren.
Een viewer voert de imagedata niet uit. Hij interpreteert de data, dat is heel iets anders.

3 / 7

Anonymous Coward op Zaterdag 7 Maart 2009 15:10

Ik gaf alleen aan dat het heel eenvoudig is om uitvoerbare code in delen van het geheugen te krijgen en niet alles in het geheugen dus gevalideerd de data is wat een programma denkt dat het is ook als je het bij het inlezen hebt 'gevalideerd'.

-7 / 9

Anonymous Coward op Zaterdag 7 Maart 2009 17:47

Jij doet deze bewering:

Het is voor experts tegenwoordig makkelijker om lekken te vinden in de binary code. Daar kunnen zich ook lekken voordoen die je niet kan zien in de source code maar die je met debugging tools wel kan vinden.

Die bewering klopt niet.

Ter ondersteuning kom je met de volgende 'argumenten':

heap overflow vunerabilities bijvoorbeeld. Vaak de gevaarlijkste soort lekken. Ook al kun je de vunerability niet zien in de code dan kun je nog wel de code aanpassen zodat de situatie waarin de vunerability zich voordoet niet kan voorkomen.

Wartaal. Natuurlijk kun je een heap overflow wel vinden in de broncode van een programma.

Ik denk niet dat iemand die code leest op byte niveau runtime geheugengebruik kan voorspellen en zelfs nog heb je daar bar weinig aan.

Wartaal. De code lezen op 'byte niveau'? Wat bedoel je daar precies mee? En wie behalve jijzelf heeft het daar precies over?

Het gaat erom hoe het geheugen wordt gevuld en dat wordt niet bepaald door desource maar door de compiler en door de runtime omgeving waarin runtime gedraaid wordt.

Wartaal. Het gaat erom of een kwetsbaarheid aanwezig is in een programma. En dat wordt niet bepaald door de compiler of door de 'runtime omgeving waarin runtime gedraaid wordt' maar door de broncode van het programma. Vandaar ook dat een eventuele kwetsbaarheid in de broncode is te vinden.

Ga zelf eens in de leer bij iemand. Om bijvoorbeeld de inhoud van een binair bestand te valideren moet je het eerst in het geheugen zetten en eventueel zelfs ook nog omzetten naar valideerbare data.

Wartaal. Het gaat hier om het vinden van kwetsbaarheden in een programma, niet om het omzetten van een 'binair bestand' naar 'valideerbare data' om het te 'valideren'.

En zelf dan kan ook heel valide data nog steeds malware code bevatten. Zo kan een image viewer niet vooraf bepalen of de image data in een bestand een echt plaatje is of executable code.

Wartaal. Het gaat er helemaal niet om wat de image viewer wel of niet vooraf kan bepalen. Het gaat er om of je aan de hand van de broncode van de image viewer kunt bepalen of er in de image viewer een lek zit. En dat is inderdaad het geval.

Ik gaf alleen aan dat het heel eenvoudig is om uitvoerbare code in delen van het geheugen te krijgen en niet alles in het geheugen dus gevalideerd de data is wat een programma denkt dat het is ook als je het bij het inlezen hebt 'gevalideerd'.

Wartaal. Afgezien van dat wat je daar beweert op zichzelf al onzinnig is gaf je dat helemaal niet alleen maar aan. Jij gaf aan dat een lek in een bepaald applicatie niet te vinden zou zijn in de broncode van die applicatie. En dat is onzin.

Het is was mij al eens eerder opgevallen, dat je geen flauw idee hebt waar je het over hebt. Dat is ook helemaal niet erg, maar laat dat badinerende toontje dan wel liever zitten.

Het is ook wel erg naïef om te veronderstellen dat jij door wat technische klinkende termen aan elkaar te rijgen een fantasie verhaal kan neerzetten (naar voorbeeld van SED, Meltdown etc) dat voor iedereen hier maar geloofwaardig is.

4 / 6

Anonymous Coward op Zondag 8 Maart 2009 21:37

Ik denk dat jij geen flauw idee hebt waar je het over hebt.
Ik kan namelijk wel gewoon binaries analyseren en daarin de mogelijk aanvalpunten opsporen. Daar is ook goede ondersteuennde programmatuur voor en dat is veel eenvoudiger dan source code analyse.
En over mijn kennis kan ik slecht zeggen dat ik ook nog compilers/interpreters in een assembly taal heb geschreven.

-4 / 6

karloe op Zondag 8 Maart 2009 21:51

huh, Ik ben in eens zwaar onder de indruk, hAl.

vooral je kennis
mijn kennis kan ik slecht zeggen dat ik ook nog compilers/interpreters in een assembly taal heb geschreven.
laat je nog al duidelijk blijken in je gereaguur.

Dag dag..

1 / 5

Anonymous Coward op Zondag 8 Maart 2009 22:09

ga je weg ?

-3 / 5

karloe op Zondag 8 Maart 2009 22:43

Wat zei je, hAl?

2 / 4

Anonymous Coward op Zondag 8 Maart 2009 22:16

Ik kan namelijk wel gewoon binaries analyseren en daarin de mogelijk aanvalpunten opsporen.

Door 'wel' te gebruiken suggereer je dat er iemand is die beweert dat dat 'niet' zo is. Dat is een 100% haldraai, er is namelijk niemand die beweert dat je aan de hand van de binaries geen lekken zou kunnen vinden (de dagelijkse praktijk rond menig MS product is ook wel anders).

Jij beweert daarentegen dat bepaalde lekken in de broncode niet zichtbaar zouden zijn:

Het is voor experts tegenwoordig makkelijker om lekken te vinden in de binary code. Daar kunnen zich ook lekken voordoen die je niet kan zien in de source code maar die je met debugging tools wel kan vinden.

heap overflow vunerabilities bijvoorbeeld. Vaak de gevaarlijkste soort lekken.

Ook al kun je de vunerability niet zien in de code dan kun je nog wel de code aanpassen zodat de situatie waarin de vunerability zich voordoet niet kan voorkomen.

Dat is onzin en daar probeer je je nu uit te haldraaien.

Daar is ook goede ondersteuennde programmatuur voor en dat is veel eenvoudiger dan source code analyse.

Dat een hoop mensen erg handig zijn geworden in het vinden van lekken in de binaries van Microsoft wil niet zeggen dat het niet makkelijker is om er de broncode bij te hebben. En dat is ook niet zo.

En over mijn kennis kan ik slecht zeggen dat ik ook nog compilers/interpreters in een assembly taal heb geschreven.

Die conclusie had ik ook al bereikt.

1 / 5

Anonymous Coward op Zondag 8 Maart 2009 22:35

De source code erbij hebben is wel handig maar dat heb ik ook niet onkent. De sourcecode is vermoedelijk met name nuttig als je een exploit will bakken
Het kijken door de source code is echter niet de makkelijkste manier om de vunerabilties op te sporen.

-5 / 5

Anonymous Coward op Zondag 8 Maart 2009 22:57

De source code erbij hebben is wel handig maar dat heb ik ook niet onkent.

Wat jij hebt ontkend is dat bepaalde lekken zichtbaar zijn in de broncode en daar probeer je je nu opnieuw uit te haldraaien. Dan laat ik je onzinnige wartaal ter 'onderbouwing' daarvan nog even buiten beschouwing.

De sourcecode is vermoedelijk met name nuttig als je een exploit will bakken

Dat is zeker handig. Net zoals het handig is voor het überhaupt vinden van een lek.

4 / 4

Anonymous Coward op Maandag 9 Maart 2009 10:33

Wat jij hebt ontkend is dat bepaalde lekken zichtbaar zijn in de broncode onjuist, als je zijn bijdrage leest ( in plaats van af te zeiken) dan lees je dat hij zegt dat niet alle lekken in de broncode te vinden zijn.
Daar kunnen zich ook lekken voordoen die je niet kan zien in de source code maar die je met debugging tools wel kan vinden

Kortom, beter lezen ipv scoren.

-6 / 8

Anonymous Coward op Maandag 9 Maart 2009 11:20

"Wat jij hebt ontkend is dat bepaalde lekken zichtbaar zijn in de broncode"

onjuist, als je zijn bijdrage leest ( in plaats van af te zeiken) dan lees je dat hij zegt dat niet alle lekken in de broncode te vinden zijn.

"Daar kunnen zich ook lekken voordoen die je niet kan zien in de source code maar die je met debugging tools wel kan vinden"

Kijk nog eens goed SED.

Het eerst vetgedrukte stuk bevat mijn weergave van de woorden van hAL/Baseline/Blingux/etc/etc, het tweede vetgedrukte bevat jouw interpretatie van zijn woorden en het derde vetgedrukte stuk bevat de woorden van Baseline zelf.

Heel goed kijken SED. Misschien kun je het zien dan.

Dat laat ik voor het gemak nog even het door jou opgeworpen onderscheid tussen 'vindbaar' en 'zichtbaar' buiten beschouwing. Maar dat is op zichzelf natuurlijk al een uiterst wanhopig woordspelletje om recht te praten wat krom is.

Kortom, beter lezen ipv scoren.

Humor.

5 / 5

Anonymous Coward op Maandag 9 Maart 2009 11:38

dus scoren is toch belangrijker dan inhoudelijke discussie. oke, kan ik mijn tijd dus beter besteden ;)

ps,
Ik haal de woorden van Blingux aan, dat was een letterlijke quote.

-7 / 7

Anonymous Coward op Maandag 9 Maart 2009 13:00

Ik haal de woorden van Blingux aan, dat was een letterlijke quote.

Dat weet ik. Jij claimt dat ik de woorden van hAL/Blingux/Baseline 'onjuist' zou weergeven. Maar de enigste die beter moet 'lezen ipv scoren' ben jijzelf.

Dat kun je eenvoudig nagaan door je eigen post (klik) waarin je die foutieve claim doet grondig door te lezen, mijn reactie daarop (klik) te lezen en/of door mijn voorgaande reacties (klik klik klik klik) beter te lezen.

Het zal wel pijnlijk voor je zijn dat je een reactie plaats waarin je claimt dat iemand verkeerd leest en dat uit diezelfde reactie al duidelijk blijkt dat je zelf verkeerd hebt gelezen. Ik ben benieuwd wat je gaat bedenken om daar de aandacht van af te leiden, maar wat mij betreft is deze discussie nu gesloten.

5 / 5

Anonymous Coward op Maandag 9 Maart 2009 14:08

discussie nu gesloten. gelukkig maar ( was er dan een discussie?) want onder Firefox zie ik alleen nog maar kantlijn in webwereld 2.1.

Jammer toch dat je een aardig gestarte en vriendelijk lopende discussie door scoorgedrag weer verpest. maar dat zul je wel nodig hebben vermoed ik ;)\

-6 / 6

Gregorius op Zaterdag 7 Maart 2009 20:17

Ik gaf alleen aan dat het heel eenvoudig is om uitvoerbare code in delen van het geheugen te krijgen
Nee, je gaf nog veel meer aan. Voornamelijk dingen die niet kloppen.

1 / 7

Kaiser Söze op Zaterdag 7 Maart 2009 16:14

Je kunt zien hoeveel geheugen een applicatie tijdens runtime maximaal zal gebruiken, tenzij je je input niet voldoende checkt.

Dat kun je niet zien, want om dit soort fouten (stack overflow, heap overflow, memory leaks) te detecteren is gespecialiseerde tooling nodig die sources scant. Of jij moet geniaal zijn en het met het blote oog zien, dat kan ook natuurlijk...

-5 / 7

Anonymous Coward op Zaterdag 7 Maart 2009 17:38

"Je kunt zien hoeveel geheugen een applicatie tijdens runtime maximaal zal gebruiken, tenzij je je input niet voldoende checkt."

Dat kun je niet zien, want om dit soort fouten (stack overflow, heap overflow, memory leaks)

In de eerste plaats vind ik het flauw om te reageren op de originele uitspraak van Gregorius terwijl hij zichzelf vrijwel meteen corrigeert. Ten tweede klopt het strikt genomen niet eens wat je zegt.

te detecteren is gespecialiseerde tooling nodig die sources scant. Of jij moet geniaal zijn en het met het blote oog zien, dat kan ook natuurlijk...

Dat hangt er maar net van af. Sommige problemen zijn met 'gespecialiseerde tooling' te vinden, andere juist weer beter met 'het blote oog'.

3 / 7

Kaiser Söze op Zaterdag 7 Maart 2009 18:04

Dat hangt er maar net van af. Sommige problemen zijn met 'gespecialiseerde tooling' te vinden, andere juist weer beter met 'het blote oog'.

Ik zou verwachten dat de meest nasty bugs die men vind in FF dan wel IE eerder van het eerste karakter zijn dan van het tweede...
Als er inderdaad voor de hand liggende fouten in de source zitten, en als er inderdaad zoveel mensen door die source aan het ploegen zijn, alleen al om het feit dat ie beschikbaar is, dan zouden er niet zoveel fouten gevonden worden in de gebruiksfase.

-4 / 6

Anonymous Coward op Zaterdag 7 Maart 2009 18:17

Ik zou verwachten dat de meest nasty bugs die men vind in FF dan wel IE eerder van het eerste karakter zijn dan van het tweede

Nee dat is niet zo. Die redenering is ook niet logisch. Als bugs met een automatische source-checker gevonden kunnen worden, juist dan waren ze wel al eerder gevonden.

Als er inderdaad voor de hand liggende fouten in de source zitten, en als er inderdaad zoveel mensen door die source aan het ploegen zijn, alleen al om het feit dat ie beschikbaar is, dan zouden er niet zoveel fouten gevonden worden in de gebruiksfase.

Maar ik zeg ook niet dat die bugs dan perse zo voor de hand liggend zijn, ik zeg dat het vinden/oplossen daarvan handwerk is.

3 / 7

Gregorius op Zaterdag 7 Maart 2009 20:34

Als er inderdaad voor de hand liggende fouten in de source zitten...
Het feit dat fouten in de code te achterhalen zijn door de code te lezen, reviewen, of wat dan ook, wil nog niet zeggen dat het om voor de handliggende fouten gaat. Soms is dat het geval wanneer een programmeur lui of makkelijk of gewoon dom is of door stress vanwege een deadline van de opdrachtgever. Andere fouten zijn moeilijker te doorgronden en vereisen een zeer diepgaande kennis van de betreffende programmeertaal en de specifieke eisen waaraan het programma moet voldoen.

2 / 6

Gregorius op Zaterdag 7 Maart 2009 20:27

Dat kun je niet zien, want om dit soort fouten (stack overflow, heap overflow, memory leaks) te detecteren is gespecialiseerde tooling nodig die sources scant.
Voor sommige zaken is dat zo ja, maar nog steeds heb je dan de broncode nodig. En daarmee zijn we weer terug bij het verschil van mening tussen albert/hAl/blinux en ik. Ik denk dat je m.b.v de broncode bufferoverflows kan detecteren, al dan niet m.b.v. tools. Albert/hAl/blinux denkt van niet:
Daar kunnen zich ook lekken voordoen die je niet kan zien in de source code...
Die kun je dus wel zien (al dan niet m.b.v. tools).

2 / 6

Anonymous Coward op Zaterdag 7 Maart 2009 10:41

Het is voor experts tegenwoordig makkelijker om lekken te vinden in de binary code. Daar kunnen zich ook lekken voordoen die je niet kan zien in de source code maar die je met debugging tools wel kan vinden.

heap overflow vunerabilities bijvoorbeeld. Vaak de gevaarlijkste soort lekken.

Ook al kun je de vunerability niet zien in de code dan kun je nog wel de code aanpassen zodat de situatie waarin de vunerability zich voordoet niet kan voorkomen.

Woorden schieten te kort, wat een onzin.

6 / 12

Anonymous Coward op Zaterdag 7 Maart 2009 10:57

Tuurlijk joh

-10 / 10

Anonymous Coward op Zaterdag 7 Maart 2009 11:05

Ik denk niet dat iemand die code leest op byte niveau runtime geheugengebruik kan voorspellen en zelfs nog heb je daar bar weinig aan. Het gaat erom hoe het geheugen wordt gevuld en dat wordt niet bepaald door desource maar door de compiler en door de runtime omgeving waarin runtime gedraaid wordt.

Wederom verschrikkelijke onzin.

3 / 9

Anonymous Coward op Maandag 9 Maart 2009 10:35

fijn dat je technische uitleg hier ook zo toereikend is voor je mening ;)

-6 / 6

Anonymous Coward op Maandag 9 Maart 2009 11:24

klik klik klik klik

5 / 5

Anonymous Coward op Maandag 9 Maart 2009 11:40

leuk je kunt linken maken.. maar in de reactie waar ik op reageerde kwam je niet verder dan een banaal: Wederom verschrikkelijke onzin.
dat neem ik niet serieus als argument, jij kennelijk wel.
Scoor lekker door en vermaak je zou ik zeggen.

-6 / 6

ArjenB op Maandag 9 Maart 2009 12:28

Hier begon het mee, Kaiser Söze op vrijdag 15:25:Er is toch geen hond die de FF source code gaat doorlopen om vulnerabilities te zoeken

Blingux even later:Het is voor experts tegenwoordig makkelijker om lekken te vinden in de binary code. Daar kunnen zich ook lekken voordoen die je niet kan zien in de source code maar die je met debugging tools wel kan vinden.Weer later:Ook al kun je de vunerability niet zien in de code
Daar las ik in dat blingux de analyse van binaries als primair gereedschap ziet bij het zoeken van lekken, en de analyse van broncode als maar ietsje meer dan nice-to-have. In Alon's bijdragen is uitgebreid te lezen waarom Alon het daarmee oneens is. Dat Alon het na ettelijke herhalingen zat is om dat standpunt nog een keer uiteen te zetten vind ik begrijpelijk. Dat hij in reactie op je reactie de links geeft naar zijn redenaties: doe er je voordeel mee.

Mijn kijk op de zaak:
Bij open-source heb je als buitenstaander de keus tussen broncode-analyse en binary-analyse, bij closed-source heb je de keus niet.
Given enough eyes, all bugs are shallow

Zelfs als binary-analyse net-zo-goed-is-als/beter-is-dan broncode-analyse bij het opsporen van fouten/lekken (wat ik uit persoonlijke ervaring bestrijd), dan zijn de blote feiten dat het gereedschap voor binary-analyse een beperkte verspreiding kent en er een menigte geïnteresseerden om-wat-voor-reden-dan-ook dagelijks in de code van (bijvoorbeeld) Firefox kan kijken en dat ook doet er volgens mij oorzaak van dat fouten in Firefox waarschijnlijk eerder zullen worden opgemerkt door analyse van broncode dan door analyse van binaries. Los daarvan zal binary-analyse je ook niet de vertellen waar/hoe de reparatie van een fout moet gebeuren.

MSIE heeft die menigte meekijkers in de broncode niet, en daarom zal een fout in MSIE volgens mij in de regel langer onontdekt blijven dan een fout in Firefox. Je kunt vertrouwen op de kwaliteit van je ontwikkelaars, maar om een ouwe kraker van Josef Stalin aan te halen:Vertrouwen is goed, controle is beter

5 / 5

Anonymous Coward op Maandag 9 Maart 2009 13:01

ArjenB++

3 / 7

Anonymous Coward op Maandag 9 Maart 2009 14:13

Stalin verzamelde vooral ja-knikkers om zich heen en sloeg iedere vorm van discussie letterlijk dood. Scoorgedrag van sommigen hier ( ja Alon, jij onder andere) doet daar wel aan denken. Leuke analogie inderdaad ;)

Meer on topic.
Ik vraag me af of code die in de praktijk zeer sterk geevalueerd wordt en waar alleen al door het massale gebruik snel fouten aan het licht komen niet beter is dan code die weliswaar in te zien is maar die slechts door een beperkt groepje liefhebbers bekeken wordt. waarbij dan ook nog het risico opdoemt dat er een fikse tunnelvisie in de code sluipt.

Nogmaals Open source is niet per definitie beter dan closed source.

-5 / 5

ArjenB op Maandag 9 Maart 2009 14:23

Ik denk dat het voordeel van buitenstaanders is dat ze nou net niet in groepsdenken vervallen.
De kans op tunnelvisie lijkt me groter bij ontwikkelaars die niet door de buitenwereld op hun vingers gekeken worden.

4 / 4

Anonymous Coward op Maandag 9 Maart 2009 17:49

Dus de vele miljoenen die elke IE ontwikkeling bekijken, testen proberen te doorbreken en hacken voorkomen da tinderdaad.
De kleine groep OSS ontwikkelaars die zich op projecten werpt worden vaak geleidt door slechts een trekker. Als er ruzie komt ( komt vaak voor!) dan krijg je een afscheiding en dat is vaak net zo vies als het klinkt ;)

-3 / 5

ArjenB op Maandag 9 Maart 2009 14:31

Stalin verzamelde vooral ja-knikkers om zich heen en sloeg iedere vorm van discussie letterlijk dood. Scoorgedrag van sommigen hier ( ja Alon, jij onder andere) doet daar wel aan denken. Leuke analogie inderdaad ;)Deze maar even apart afhandelen, anders wordt het zo'n rommeltje.

Het is me in deze draad opgevallen dat Alon keurig aangeeft wat hem beweegt. Je vergelijking van Alon met Stalin of een Stalin-volgeling vind ik hoogst ongepast.

De smiley aan het eind van de alinea zou ik op kunnen vatten als aanmoediging om de inhoud niet al te serieus op te vatten, maar ik heb dat bij jouw reacties afgeleerd.

Ik probeerde een zakelijke reactie op je bijdrage te leveren, ik heb geen zin in een nieuwe ronde vliegen afvangen. Ik zou het waarderen als je on-topic zou blijven.

5 / 5

Anonymous Coward op Maandag 9 Maart 2009 17:52

Ik stoor me aan de diverse denigrerende opmerkingen die Alon maakt tov van AC. Inderdaad heeft hij hier en daar uitgebreidere stukken maar ook daar veel nodeloze arrogantie. Dat is een kenmerk van Alon in veel van zijn zijn reacties die niet altijd door de inhoudelijke nauwkeurigheid gerechtvaardigd worden. Hij verpest hier in toch al lastige discussie weer.
Daar laten we het maar bij.

-2 / 4

ArjenB op Maandag 9 Maart 2009 20:27

AC/blingux/hAl had al eerder de toon gezet, en gaandeweg werd de draad grimmiger.

Ik heb AC/blingux/hAl nu een tijdje gevolgd, op verschillende sites (wikipedia, tweakers, om er een paar te noemen), en het is telkens hommeles. Met verschillende reageerders, de constante is AC/blingux/hAl. Die heeft een probleem met andere meningen, of het over Microsoft, privacybeleid of open standaarden gaat. Je kunt er op wachten dat hij uit de bocht vliegt. Hij irriteert, het is net alsof hij dat nodig heeft.

Ik heb er langzaamaan genoeg van, de onversneden minachting die hij keer op keer toont voor andere meningen dan de zijne. Je kunt beginnen met argumenteren, als je je standpunt blijft verdedigen eindigt het in gescheld van AC/blingux/hAl, of een stille aftocht. AC/blingux/hAl zal nooit toegeven. Daar reageert de rest van de wereld op, en meestal nogal onvriendelijk.

Over een poosje is hij weer terug en begint het feest weer van voren af aan. Ik weet niet of ik dat nog mee wil maken.

Wat Stalin aangaat: die heb ik er zelf bijgehaald, om er indirect aan te herinneren dat de waarheid van een uitspraak niet aan de ideologie van de persoon die 'm doet moet worden afgemeten.

Stalin was een massamoordenaar. Hitler en Pol Pot kun je met 'm vergelijken, maar de reageerders hier verdienen die vergelijking niet.

2 / 4

Dax op Zondag 8 Maart 2009 13:59

nou met opensource kun je dus als je de redenering van blinux volgt 2x checken...zowel source als binary ;)

3 / 5

Gregorius op Zondag 8 Maart 2009 16:07

*** reactie verwijderd ***

0 / 2

Anonymous Coward op Zondag 8 Maart 2009 19:12

*** reactie verwijderd ***

-5 / 7

ArjenB op Zondag 8 Maart 2009 19:47

Je moet niet zo dom uit je nek l****n. Waarvoor een min.
Zoek hulp. Of neem een maandje vrij.

On-topic: na enige tientallen jaren ervaring met programmeren meen ik met gezag te mogen stellen dat beschikbaarheid van de broncode het opsporen van fouten/lekken wezenlijk eenvoudiger maakt.

Dat iemand op een IT-site iets anders zegt zou ik van iedere andere reageerder dan jij als een poging tot humor beschouwen.

7 / 7

Anonymous Coward op Zondag 8 Maart 2009 20:43

Gregorius die al een keer of dertig mij ten onrechte uitmaakt voor microsoft medewerker of astroturfer kan ik moeilijk voor iets anders uitmaken.
Als je hem iets duidelijk maakt blijkt hij het blijkbaar maanden later nog niet te begrijpen.

-5 / 7

Anonymous Coward op Zondag 8 Maart 2009 21:14

Je moet niet zo dom uit je nek l****n

Jij bent helemaal niet in een positie om mensen op dusdanige wijze aan te spreken.

4 / 6

Gregorius op Zondag 8 Maart 2009 23:15

Redactie, mag ik weten waarom mijn reactie verwijderd is?

-1 / 3

Kaiser Söze op Vrijdag 6 Maart 2009 16:25

Een kwaadwillende ook niet?

Dat lijkt me juist een groot gevaar van OSS!!!

-10 / 14

bekhof op Vrijdag 6 Maart 2009 21:32

Nee, dat is het grootste voordeel. Niemand kan doen alsof er niets aan de hand is...

7 / 13

Anonymous Coward op Vrijdag 6 Maart 2009 14:25

Microsoft doet langer over ‘zijn’ 0-day gaten, openstaande lekken waarvoor dus al malware is. Volgens Secunia heeft de Windows-leverancier maar liefst 100 dagen erover gedaan om met patches te komen voor de drie 0-day IE-gaten van vorig jaar

Dat is niet wat het rapport van secunia rapporteerd.
This table only displays those vulnerabilities
publicly disclosed by a reporter prior to
vendor notification. The numbers do not
include vulnerabilities responsibly disclosed or
discovered internally by the vendor.
Ze zijn publicly disclosed maar dat hoeft niet te betekenen dat er malware voor is.
Sterker nog, van de enige critical vunerabuility in die lijst van 6 publicly disclosed vunerabilties (die na 110 dagen werd gepatched) staat in de securuty bulletin waarbij de patch wordt aangekondigd nog heel expliciet dat er nog geen malware vvoor is aangetroffen.

Overigens is 100 dagen ook niet juist want Microsoft had 3 weinig risicovolle vunerabilites (van de publicly disclosed 6 vunerabilities) ook op 1 januari nog niet gepatched. in feite staan die dus veel langer open dan 100 dagen.

-6 / 14

Gregorius op Vrijdag 6 Maart 2009 14:32

Ze zijn publicly disclosed maar dat hoeft niet te betekenen dat er malware voor is.
Slaap zacht...

6 / 14

Anonymous Coward op Vrijdag 6 Maart 2009 14:40

Het ging wel ook om vunerabilties die niet of nauwelijks risicovol waren. Die zijn vermoedelijk niet eens te exploiteren. De kas op malware is daarbij sowiso al zo geod als nul.

Er zat maar 1 critical vunerability bij en daarvoor was geen malware gedetecteerd

Microsoft maar ook vrijwel alle security bedrijven hebben uitgebreide detectie methodes van malware.
Zelden zal een nieuw malware verspreiding meer dan een paar dagen niet gedetecteerd worden door al deze partijen.

De informatie in het webwereld artikel is daarom misleidend want die suggereert dat er al die tijd malware is terwijl er dus geen malware was.

-6 / 12

Anonymous Coward op Vrijdag 6 Maart 2009 16:05

Het blijft gewoon een appels en peren verhaal. Lekken zullen er zijn en we kunnen alleen maar hopen dat ze snel en adequaat verholpen worden.
Het is best belangrijk dat het snel gebeurt, daar is Ff in het voordeel, kleiner en minder afhankelijkheden.
Bij M$ kunnen er lekken in het os waarschijnlijk te relateren zijn aan de ingebakken IE, daar is het zoeken/vinden moeilijker, daar heeft M$/IE weer een voordeel.
Ik gebruik Ff omdat ik het goed vind werken, zeker toen het ten opzichte van de oude IE écht beter was. Ik heb het gevoel dat het veiliger is omdat het "op" Windows draait in plaats van "in". De nieuwe IE's zie ik alleen bij klanten, heb gewoon geen zin om terug te gaan.
Bewijs heb ik er niet voor, en de eeuwige tel oorlog geloof ik niet in, daar zijn ze gewoon te verschillend voor.

8 / 12

Anonymous Coward op Vrijdag 6 Maart 2009 16:43

Het blijft gewoon een appels en peren verhaal. een veelgebruikte dooddoener. Beide zijn applicaties met eenzelfde doel en vrijwel elke applicatie doet dat op zijn eigen wijze. Die appels en peren heb je dus altijd. Ik verwacht dat je deze reactie dus ook had toen het FF "'onderzoek"" als reclame gebruikt werd?

-8 / 14

Anonymous Coward op Vrijdag 6 Maart 2009 16:50

Inderdaad, de tekst was misschien anders, maar de strekking gelijk. Het kan van maand tot maand verschillen, overeenkomsten of afwijkingen van nu zijn geen garantie voor de toekomst.
Ik mag een groot voorstander van OS-OSS genoemd worden, maar beide soorten hebben hun eigen voor en nadelen en dat kan van toepassing ook nog sterk verschillen, zoals gelijksoortige programma's zijn voor en nadelen heeft. Meningen, smaken en budget's verschillen nu eenmaal.

5 / 11

Anonymous Coward op Vrijdag 6 Maart 2009 17:16

P.S. Ik heb wel eens iets geroepen over lezen van reacties, heb jij toen ook de boel dan maar overgeslagen? Of is het al uit het geheugen? Ik heb dat namelijk meer gesteld.

2 / 8

diocletianus op Zaterdag 7 Maart 2009 00:07

Appel en peren heb je overal. Maar het gaat over de beeldvorming en daar scoort IE wel wat slechter en dat is niet mijn schuld :)

4 / 4

eerde op Vrijdag 6 Maart 2009 21:31

Zodra ik de naam van Internetclown Jeff Jones zie kap ik met lezen...

2 / 10

JanW op Zondag 8 Maart 2009 11:36

Leuk stukje reclame verwerkt in het secunia PDF-je, trouwens. (Voor Secunia's PSI...) :-)

Wat me even opvalt is:
Hoewel IE 31 kwetsbaarheden heeft, er tegelijkertijd ook voor de (IE-only) Active-X plugin er welgeteld 366(!) bestaan.

Mijn favo-browser kan (gelukkig) Active-X niet ondersteunen, en daarmee win ik dus al een hoop. Maar, er blijven helaas genoeg lekken over met de andere plug-in's (Flash, JAVA & Quicktime, o.a.).

Dus, ook al is je browser (om het even welke) goed en op tijd ge-patched, hou dan ook rekening met de evt. geïnstalleerde plug-in's...

Aansluitend daarop, dan maar even Firefox tipje: De extensie NoScript kan standaard scripts en eventuele startende plug-in's blokkeren. De extensie kent een actieve ontwikkeling en zorgt zelfs bij tijd en wijle voor bescherming tegen kwetsbaarheden die op een andere manier nog niet zijn gerepareerd of opgelost.

Extra stukje veiligheid, zeg maar.

Misschien bestaat er ook zoiets voor IE, maar dat weet ik niet. (Misschien iemand anders wel.)

3 / 3