code:De uitleg die hieraan gegeven wordt is dat current->uid op 0 wordt gezet alleen als options gelijk is aan (__WCLONE|__WALL). Maar dat is naar mijn idee echt onzin. Ten eerste worden expressies van rechts naar links gevalueerd, (current->uid = 0) wordt dus eerder bekeken dan (options == (__WCLONE|__WALL)).if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;
Ten tweede als ik in een vergelijking een toewijzing neer zou zetten dan mag ik toch hopen dat die ook wordt uitgevoerd. Denk bijvoorbeeld aan het gebruik van ++. Oftewel de current->uid zou altijd op 0 gezet moeten worden met bovenstaande code en dat zou dus simpelweg betekenen dat de programmeur van dit stukje per abuis = heeft neergezet ipv ==
Misschien dat iemand ziet wat er schort aan mijn uitleg want ik ga er dan maar ff vanuit dat al die security experts het bij het juiste eind hebben. 
[Dit bericht is gewijzigd door Najra op 07-11-2003 15:09]
quote:of ik nou
Op vrijdag 7 november 2003 15:04 schreef Najra het volgende:
Het zou gaan om deze codecode:De uitleg die hieraan gegeven wordt is dat current->uid op 0 wordt gezet alleen als options gelijk is aan (__WCLONE|__WALL). Maar dat is naar mijn idee echt onzin. Ten eerste worden expressies van rechts naar links gevalueerd, (current->uid = 0) wordt dus eerder bekeken dan (options == (__WCLONE|__WALL)).if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;
if (blaat == blaat && bla == bla)
bladiebla
of
if (bla == bla && blaat == blaat)
bladiebla
neerzet, het resultaat is hetzelfde. In PHP tenminste.
Nog wat dingen:
quote:Naar mijn weten is er geen speciale Linux Code, er wordt gewerkt met C, C++, whatever. En reken maar dat Gates daar wat van af weet. Maar lijkt me niet dat iemand van Microsoft dit heeft gedaan. Als dat zou uitkomen is dat hele erge publiciteit voor ze.
Op vrijdag 7 november 2003 11:47 schreef BladE-l----- het volgende:Duh, lees die quote dan. Niet iedereen weet genoeg van linux-code om een dergelijke backdoor erin te zetten.
Voor de rest: Dat 1 keer zo iets wordt gedaan, wil niet zeggen dat er gelijk tig van dit soort dingen zijn. Deze fout is relatief snel aan het licht gekomen. Reken maar dat de code gecontroleerd wordt, er zijn duizenden mensen mee bezig.
Ik vraag me wel af hoe dit er uberhaupt in gekomen is. Ik weet niet hoe de kernel precies wordt ontwikkeld, maar het lijkt me toch niet dat iedereen zomaar de officiele versie van de kernel kan veranderen. Voordat er een verandering doorgevoerd wordt moet daar toch wel over gesproken worden op nieuwsgroepen oid? Lijkt me toch dat er ingebroken is op een server.
quote:Niet helemaal waar. Bekijk het volgende stukje code:
Op vrijdag 7 november 2003 15:28 schreef yootje het volgende:
of ik nou
if (blaat == blaat && bla == bla)
bladieblaof
if (bla == bla && blaat == blaat)
bladieblaneerzet, het resultaat is hetzelfde. In PHP tenminste.
php:Vervang (onwaar() && waar()) maar eens door (waar() && onwaar()) en bekijk de uitvoer.<?
Header("Content-type: text/plain");
function waar() {
print "waar\n";
return true;
}
function onwaar() {
print "onwaar\n";
return false;
}
if (onwaar() && waar()) {
print "dus...\n";
}
?>
[Dit bericht is gewijzigd door Hiawatha op 07-11-2003 16:08]
quote:Dat is allemaal heel leuk en aardig. Maar
Op vrijdag 7 november 2003 15:28 schreef yootje het volgende:[..]
of ik nou
if (blaat == blaat && bla == bla)
bladieblaof
if (bla == bla && blaat == blaat)
bladieblaneerzet, het resultaat is hetzelfde. In PHP tenminste.
1. het gaat hier om C
2. het gaat om de volgorde van de uitkomst van een vergelijking en een toewijzing. Waarin je overigens gelijk hebt dat de volgorde er niet toe hoort te doen, ik meld enkel dat als dat al een argument zou zijn dan nog klopt het niet omdat er van rechts naar links wordt gewerkt.
3. dit spreekt mijn verhaal helemaal niet tegen
Ik begrijp dat het een issue is dat men niet zo snel kan verklaren hoe de code er gekomen is. Maar dat het een hack zou zijn klopt niet.
quote:True maar voordat je bij een core team terecht komt... Ik bedoel, daar kom je niet zomaar even in te zitten.
Op vrijdag 7 november 2003 12:30 schreef Hiawatha het volgende:
Niet alleen in de Linux kernel, maar in source code in het algemeen. Zeker in de Open Source wereld kan iedereen meewerken aan code. Wat nou als een kwaad willende persoon zich inzet voor een project en bij het core-team wordt geplaatst. Een aanpassing is dan zo gemaakt. Zeker een subtiele verandering zoals die net in de Linux kernel is gemaakt (== vervangen door =). Dat zie je snel over het hoofd. Ik denk dat uit dit voorval een goede les geleerd kan worden.
Ik maak ook soms nog wel eens de fout een =je te vergeten in een if (leuk is dat als je in een recursieve functie zit), mi zou de compiler er over moeten zeuren, maar ansi denkt daar anders over, mede door het ontbreken van datatype bool in C.
op if(x=5) geeft de gcc compiler met -Wall de foutmelding (zonder Wall geen problemen):
warning: suggest parentheses around assignment used as truth value
dus als we if((x=5)) doen dan krijgen we de warning niet meer. Die dubbele haken zouden een codereviewer dan wel moeten alerten, alhoewel bij meerdere nested haken is het overzicht al snel zoek. Liever zou ik gezien hebben dat er a een bool datatype zou zijn b, als je een niet booleaanse expressie gebruikt in een if/switch/while ed, dat je het dan expliciet naar bool moet casten.
quote:Het wordt van links naar rechts geevalueerd. Dus als de eerste expressie onwaar is dan wordt de tweede niet geevalueerd, dit is gedaan om de snelheid op te schroeven, waarom zou je in een && de tweede expressie ook gaan evualueren als het nooit meer true gaat worden?
Op vrijdag 7 november 2003 15:04 schreef Najra het volgende:
Het zou gaan om deze codecode:De uitleg die hieraan gegeven wordt is dat current->uid op 0 wordt gezet alleen als options gelijk is aan (__WCLONE|__WALL). Maar dat is naar mijn idee echt onzin. Ten eerste worden expressies van rechts naar links gevalueerd, (current->uid = 0) wordt dus eerder bekeken dan (options == (__WCLONE|__WALL)) .if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;Ten tweede als ik in een vergelijking een toewijzing neer zou zetten dan mag ik toch hopen dat die ook wordt uitgevoerd. Denk bijvoorbeeld aan het gebruik van ++. Oftewel de current->uid zou altijd op 0 gezet moeten worden met bovenstaande code en dat zou dus simpelweg betekenen dat de programmeur van dit stukje per abuis = heeft neergezet ipv ==
Misschien dat iemand ziet wat er schort aan mijn uitleg want ik ga er dan maar ff vanuit dat al die security experts het bij het juiste eind hebben.
code:output:#include <stdio.h> int waar(){
printf("%s","waar\n");
return 1;
}
int onwaar(){
printf("%s","onwaar\n");
return 0;
}
int main(){
printf("%s","onwaar(),waar()\n");
if((onwaar()) && (waar())){
//bla;
}
printf("%s","waar(),onwaar()\n");
if((waar()) && (onwaar())){
//bla
}
return 0;
}
code:Edit:onwaar(),waar()
onwaar
waar(),onwaar()
waar
onwaar
Ohja en waarom het hier om een bewuste hack ging en niet om een typo van een programmeur:
quote:
However sophisticated, the hack fell apart Wednesday, when a routine file integrity check told McVoy that someone had manually changed a copy of a kernel source code file that's normally only modified by an automated process, specifically one that pulls the code from BitMover's BitKeeper software collaboration tool and repackages it for the open source CVS system still favored by some developers.
[Dit bericht is gewijzigd door Pharkus op 08-11-2003 16:59]
quote:Nou ja, afhankelijk van instellingen van de compiler, kan het zijn dat er maar 1 element ge-evalueerd wordt, indien het gaat om een AND. Immers, als 1 element false is, heeft het voor de waarde van de totale AND geen zin om nog andere elementen te evalueren. Dat kan bugs opleveren die moeilijk te vinden zijn.
Op vrijdag 7 november 2003 15:28 schreef yootje het volgende:[..]
of ik nou
if (blaat == blaat && bla == bla)
bladieblaof
if (bla == bla && blaat == blaat)
bladieblaneerzet, het resultaat is hetzelfde. In PHP tenminste.
Weak coffee is only fit for lemmas. - Pál Turán (1910-1976)
quote:De code heeft nooit in released kernels gezeten. Alleen heel even in CVS, en toen ze de boel in BitKeeper gingen importeren kwam deze fout aan het licht.
Op vrijdag 7 november 2003 13:09 schreef Skinkie het volgende:
nu heb ik net 2.4.22 en 2.6.0-test9 nagelopen en current_uid wordt niet 0... dus iemand mag mij ff verlichten...
Of in ieder geval, dat is wat ik uit de thread begrepen heb. Wat best lastig is, want het development model van Linux is tegenwoordig zo te zien nog ingewikkelder dan de kernel zelf... 
Maar goed, dus nog even voor alle duidelijkheid: Deze backdoor heeft het daglicht niet tot amper gezien!
quote:Tsja, dat is op zich in de meeste gevallen waar, maar helaas zijn er steeds meer server beheerders die het belang van security patches niet inzien en dus veel te laat zijn met de installatie ervan. Niet alleen op Windows servers, ook op Linux servers.
Op vrijdag 7 november 2003 12:17 schreef Hiawatha het volgende:
Zo'n virus zal geen lang leven hebben. De Open Source wereld is ook open in het vermelding van fouten. Fout wordt gefixed en dag dag virus.
Want om eerlijk te zijn, als alle Windows beheerders wisten waar ze mee bezig waren zou een gemiddelde worm ook veel meer moeite hebben met z'n verspreiding.
quote:Vertel het nog maar eens, ik volg jouw argumentatie nog steeds niet...
Op vrijdag 7 november 2003 12:12 schreef markvleth het volgende:[..]
Dit soort uitspraken heb ik een stukje terug al beargumenteerd waarom deze aanname niet gemaakt mag worden.
quote:In ieder geval stukken moeilijker dan bij Windows, aangezien het aantal ontwikkelaars veel groter en de openheid bij die ontwikkeling zelfs 100% groter is dan bij het gesloten Windows. God mag weten hoeveel backdoors er al in Windows zitten, die er moedwillig door MS ingebouwd zijn. Nee, het is niet te bewijzen dat ze er zijn. Maar ook niet dat ze er niet zijn...
Op vrijdag 7 november 2003 12:26 schreef Pharkus het volgende:
Hoe moeillijk zou het zijn om daadwerkelijk onopgemerkt zulke veranderingen in de linux kernel toe te voegen?
quote:Ik wil niet weer discussie win-linux oprakelen, maar het is voor een bedrijf zeer onwenselijk als dit soort backdoors naar buiten komen (ook voor open source). In een bedrijf kan het op verschillende niveau's gebeuren, een programmeur die voor zichzelf een backdoor in bouwt en dit geheim houdt en ook nog eens langs de controle/review board weten te loodsen.
Op zaterdag 8 november 2003 18:16 schreef Jalu het volgende:
In ieder geval stukken moeilijker dan bij Windows, aangezien het aantal ontwikkelaars veel groter en de openheid bij die ontwikkeling zelfs 100% groter is dan bij het gesloten Windows. God mag weten hoeveel backdoors er al in Windows zitten, die er moedwillig door MS ingebouwd zijn. Nee, het is niet te bewijzen dat ze er zijn. Maar ook niet dat ze er niet zijn...
Tweede is zoals jij suggereert dat er moedwillige vanuit bedrijfspolicy backdoors worden in gebouwd. Dan moeten er dus meerdere mensen (hoge personen) zijn die er van af weten. Dus deze mensen moet je koste wat kost in dienst houden en tevreden houden, want als ze dat gaan lekken dan is het eind van (in dit geval). Niet te vergeten wat mensen die er van af weten wel niet kunnen roepen op een nieuwjaarsborrel
quote:Ik suggereer helemaal niets... Ik zeg alleen dat ik dat bij een closed-source OS als dat van Microsoft op geen enkele wijze kan achterhalen. Terwijl ik dat bij een open-source kernel als die van Linux of MacOSX zelf kan controleren, als ik dat wil.
Op zaterdag 8 november 2003 18:32 schreef Pharkus het volgende:[..]
Ik wil niet weer discussie win-linux oprakelen, maar het is voor een bedrijf zeer onwenselijk als dit soort backdoors naar buiten komen (ook voor open source). In een bedrijf kan het op verschillende niveau's gebeuren, een programmeur die voor zichzelf een backdoor in bouwt en dit geheim houdt en ook nog eens langs de controle/review board weten te loodsen.
Tweede is zoals jij suggereert dat er moedwillige vanuit bedrijfspolicy backdoors worden in gebouwd. Dan moeten er dus meerdere mensen (hoge personen) zijn die er van af weten. Dus deze mensen moet je koste wat kost in dienst houden en tevreden houden, want als ze dat gaan lekken dan is het eind van (in dit geval). Niet te vergeten wat mensen die er van af weten wel niet kunnen roepen op een nieuwjaarsborrel
Zeg nou zelf, hoeveel waarde zou jij hechten aan een dergelijke verklaring van een oud MS medewerker? Ook daarvan kun je nooit controleren of het waar is, want weer heb je nog steeds geen zicht op de source, op dezelfde manier zou je ook een ontkenning van MS niet kunnen controleren.
De code is tijdens een van de standaardchecks eruit gevist.
Het heeft nooit de main tree bereikt, het enkel development deel (als ik het zo goed uitleg). Dat de poging in een vroeg stadium is gevonden bewijst dat het systeem werkt.
Trouwens de hack was een local exploit.
Correct me if I'm wrong, ben geen expert op het gebied.
De grootste security risico's lijkem gerelateerd aan de vele app's die er beschikbaar zijn en die niet zo goed gecontroleerd worden als de kernel, maar ja, deze risico's heb je ook bij andere os'en.
quote:Inderdaad, en dat zijn dan ook geen OS-gebonden risico's maar applicatie-gebonden risico's.
Op zaterdag 8 november 2003 18:52 schreef nipeng het volgende:
Dit is wat ik ervan begrijp:De code is tijdens een van de standaardchecks eruit gevist.
Het heeft nooit de main tree bereikt, het enkel development deel (als ik het zo goed uitleg). Dat de poging in een vroeg stadium is gevonden bewijst dat het systeem werkt.Trouwens de hack was een local exploit.
Correct me if I'm wrong, ben geen expert op het gebied.
De grootste security risico's lijkem gerelateerd aan de vele app's die er beschikbaar zijn en die niet zo goed gecontroleerd worden als de kernel, maar ja, deze risico's heb je ook bij andere os'en.
quote:Omdat er in de tweede expressie een toewijzing plaats vindt. Als die toewijzing later gebruikt moet worden dan loopt je hele programma in de soep omdat die nooit heeft plaatsgevonden. Maar die optimalisatie wordt dus wel uitgevoerd.
Op zaterdag 8 november 2003 16:50 schreef Pharkus het volgende:[..]
Het wordt van links naar rechts geevalueerd. Dus als de eerste expressie onwaar is dan wordt de tweede niet geevalueerd, dit is gedaan om de snelheid op te schroeven, waarom zou je in een && de tweede expressie ook gaan evualueren als het nooit meer true gaat worden?
Ten tweede zie ik in waar ik fout zit. Het is niet volgorde van expressie behandeling waar je naar moet kijken maar simpelweg naar operator precedence de associativiteit van de operator. Bij een && is die links-rechts dus links wordt als eerste behandeld.
[Dit bericht is gewijzigd door Najra op 11-11-2003 00:03]
quote:In Linux zitten ook genoeg "stomme fouten" hoor
Op vrijdag 7 november 2003 10:09 schreef BladE-l----- het volgende:
Er is natuurlijk wel een verschil tussen stomme fouten van Microsoft en opzettelijke sabotage in de opensource-gemeenschap.
En wie zegt dat Microsoft niet opzettelijk sabotage pleegd? 
"Beer is proof that God loves us" - Benjamin Franklin.
-
"Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety" - Benjamin Franklin
quote:Ik vind toewijzingen zo ie zo niet horen in if's while's etc (dat het wel veel gebruikt wordt ok). Dit is dus ook een van de redenen om toewijzingen dus ook niet in if's te doen, er is een kans dat ze niet toegewezen worden. Plus dat het duidelijker is om de toewijzing eerder of later te doen.
Op maandag 10 november 2003 23:54 schreef Najra het volgende:
Omdat er in de tweede expressie een toewijzing plaats vindt. Als die toewijzing later gebruikt moet worden dan loopt je hele programma in de soep omdat die nooit heeft plaatsgevonden. Maar die optimalisatie wordt dus wel uitgevoerd.
quote:Vooropgesteld een optimalisatie zou eigenlijk nooit syntactisch en semantisch correcte code onwerkbaar mogen maken. Hoe vies die code dan ook geschreven is. Dat optimalisaties soms niet helemaal de regels volgen om een grote winst te kunnen boeken is dan een noodzakelijk kwaad denk ik. Maar dat is zeker geen reden om dat als argument te gebruiken. Code wordt minder netjes als het voor de lezer minder overzichtelijk is, niet omdat de compiler dan de code kan verneuken. Verder kan je natuurlijk ook code beter maken door het meer gericht te schrijven voor een optimalisatie.
Op dinsdag 11 november 2003 12:32 schreef Pharkus het volgende:[..]
Ik vind toewijzingen zo ie zo niet horen in if's while's etc (dat het wel veel gebruikt wordt ok). Dit is dus ook een van de redenen om toewijzingen dus ook niet in if's te doen, er is een kans dat ze niet toegewezen worden. Plus dat het duidelijker is om de toewijzing eerder of later te doen.
Dan erbij gaat in sommige gevallen het argument niet eens op. Bijvoorbeeld bij het gebruik van de ++ en -- operators. Net zo goed toewijzingen.
|
|
