"Check compiler whether correct deal with sizeof operator"
12-02-2006,00:11 door
Eentje in het Nederlands dan; Tijdens het doorspitten van de full disclosure archives (altijd fun) viel deze posting op. Zo ver ik het volg komt het er op neer dat sommige compilers (BCB6+ent_upd4 en tcc-0.9.23 confirmed) onverwacht gedrag vertonen. De onderstaande code print 'tsja' indien gecompileerd met een 'vulnerable' compiler:
int main (int argc, char ** argv) {
int i = -1;
if(i < sizeof(int)) printf("tsja!n");
return 0;
}
Dit is (in mijn ogen) onverwacht gedrag omdat ik zou verwachten dat de (signed) integer 'i' gepromote wordt naar een unsigned int (dit omdat de sizeof normaal gesproken een unsigned return value heeft) en dan dus niet meer 'kleiner' is dan sizeof(int). De impact van dit onverwachte gedrag verschilt natuurlijk van applicatie tot applicatie.
Maar het punt is dat je een ultra-secure-evil-hacker-proof stuk C gecode kan hebben maar nog steeds 'onveilig' kan zijn als je compiler of interpreter 'lek' is. Moeten we nu allemaal aan de ida en bin-navi, gaan we er vanuit dat dit soort fouten niet veel voorkomen of gaan we allemaal compilers auditen?
int main (int argc, char ** argv) {
int i = -1;
if(i < sizeof(int)) printf("tsja!n");
return 0;
}
Dit is (in mijn ogen) onverwacht gedrag omdat ik zou verwachten dat de (signed) integer 'i' gepromote wordt naar een unsigned int (dit omdat de sizeof normaal gesproken een unsigned return value heeft) en dan dus niet meer 'kleiner' is dan sizeof(int). De impact van dit onverwachte gedrag verschilt natuurlijk van applicatie tot applicatie.
Maar het punt is dat je een ultra-secure-evil-hacker-proof stuk C gecode kan hebben maar nog steeds 'onveilig' kan zijn als je compiler of interpreter 'lek' is. Moeten we nu allemaal aan de ida en bin-navi, gaan we er vanuit dat dit soort fouten niet veel voorkomen of gaan we allemaal compilers auditen?
