"Check compiler whether correct deal with sizeof operator"
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
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?
veiligere programma's
dat is vragen om problemen
zou kunnen zorgen? ik kan zo snel niet iets bedenken... vrij vergezocht lijkt
me.
toch het verwachte gedrag van de compileroutput simpelweg
testen? Auditten van compilers op security bugs is next too
nutteloos. Gebruik gewoon de ANSI C compatible test suite of
de andere standaard specificaties die er voor de
desbetreffende programmeer taal staan.
@Anoniem: In sommige gevallen ja, in de example code boeit
het geen reet of het een signed of unsigned int is. Die int
heeft nog steeds dezelfde grootte in bytes in het geheugen.
Als een sizeof() een waarde die te groot is rapporteert heb
je enorm veel kans op bounds checks die verkeerd gaan. Als
erachter interessante data ligt (saved instruction pointer,
saved frame pointer, of gewoon een variabele waarmee je
execution flow toch kan aanpassen) kun je veel dingen kapot
maken.
Zo vergezocht is het niet. Helemaal niet eigenlijk.
> Dit is (in mijn ogen) onverwacht gedrag omdat ik
> zou verwachten dat de (signed) integer 'i'
> gepromote wordt naar een unsigned int
gepromote? Je bedoelt dat 0xFFFFFFFF in het geheugen
ineens niet als -1 maar als +4294967295 zou moeten worden
gelezen, en dat dan wel verwacht gedrag en geen
(security) fouten zou opleveren?
Wel hebben alert7 (de FD poster) en jij gelijk dat Borland
zich niet aan haar eigen handleiding houdt. Je hebt echter
geen IDA nodig, gewoon een breakpoint zetten en een CPU
window openen werkt ook:
0040116C C745FCFFFFFFFF mov [ebp-0x04],0xffffffff
Unit1.cpp.10: if(i < sizeof(int)) printf("tsja!n);
00401173 837DFC04 cmp dword ptr [ebp-0x04],0x04
00401177 7D0B jnl +0x0b
00401179 68A4204000 push 0x004020a4
0040117E E87D010000 call CC3260._printf
omdat -1 kleiner is dan 4).
Uit de online manual:
...
Standard arithmetic conversions
When you use an arithmetic expression, such as a + b, where
a and b are different arithmetic types, C++Builder performs
certain internal conversions before the expression is
evaluated. These standard conversions include promotions of
"lower" types to "higher" types in the interests of accuracy
and consistency.
...
7. Otherwise, if either operand is of type unsigned, then
the other operand is converted to unsigned.
Vertrouwen op een dergelijke conversie is m.i. fundamenteel
fout (maakt niet uit welke kant op), doodeenvoudig omdat er
slechts voor de helft van alle mogelijke getallen een
overlap is tussen beide types; unsigned is dus helemaal geen
"higher" type dan signed. Normaal gesproken levert dit dan
ook een warning op: "W8012 Comparing signed and unsigned
values" (maar van mij had dit een foutmelding mogen zijn).
Het grootste probleem van deze compiler bug ("vergeten" dat
sizeof() unsigned teruggeeft) is m.i. niet het op
onverwachte wijze evalueren van de expressie, maar het feit
dat de programmeur er niet d.m.v. een warning op gewezen
wordt dat hij een fout gemaakt heeft.
De kans op security fouten door deze compiler bug is denk ik
klein; sizeof wordt meestal gebruikt om de grootte van
structs te bepalen en daarbij zal het meestal om unsigned
vergelijkingen gaan.
> 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.
Ja, maar ik maak me meer zorgen over libraries.
Erik van Straten
> klein; sizeof wordt meestal gebruikt om de grootte van
> structs te bepalen en daarbij zal het meestal om unsigned
> vergelijkingen gaan.
Hahaha, daar zit je erg fout. De kans is behoorlijk groot.
Er is superveel code die vulnerable is voor dergelijke bugs.
Het enige wat daartegen pleit is het feit dat mensen
voornamelijk gcc, en icc (intel compiler suite) gebruiken
en die vertonen dit gedrag afaik niet. Zo moeilijk is het
ook niet om een compiler te bouwen die aan specs voldoet.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.