| lea eax, [ebp+var_44] push eax ; hMem call ds:__imp__LocalFree@4 ; LocalFree(x) |
Quelqu'un peut-il me dire:
- Pourquoi c'est "mal"?
- Quelle est l'erreur du programmeur qui a mene a ce code?
- Comment exploiter cela?
5 new protections on Google Messages to help keep you safe
-
Posted by Jan Jedrzejowicz, Director of Product, Android and Business
Communications; Alberto Pastor Nieto, Sr. Product Manager Google Messages
and RCS Spa...
1 week ago
2 comments:
1. LEA EAX instead of MOV EAX so LocalFree will end up trying an address that is part of the allocated stack (as opposed to a variable held on that stack).
2. Probably something like this:
void bug( HLOCAL mem )
{
LocalFree( &mem );
}
void foo()
{
HLOCAL addr;
bug( addr );
}
So the programmer used 'LocalFree( &mem )' instead of 'LocalFree( mem )' (hence the LEA instead of MOV).
3. ...something to do with decrementing the HLOCAL's lock count?, or maybe if EAX is a valid handle (to satisfy RtlIsValidHandle in LocalFree) then you could force the free of [EAX+4] which may be attacker controllable, ....but I really have no idea :)
lea eax, [ebp+var_44]
push eax ; hMem
call ds:__imp__LocalFree@4 ; LocalFree(x)
Quelqu'un peut-il me dire:
1. Pourquoi c'est "mal"?
Je ne connais rien en faille, toutefois, on pourrait passer un bit/octet a NULL puis forger une saloperie qui attaque un autre truc du systeme ! par contre, il faut faire attention a la canary que visual ou un autre compilateur peut generer pour contre carrer un buffer overflow ? Peut-on remonter dans la pile pour chopper une adresse de Kernel32 ?
2. Quelle est l'erreur du programmeur qui a mene a ce code?
Comme l'a dit William c'est un LocalFree(&ptrVersZoneMemoire)
3. Comment exploiter cela?
J'en ai pas la moindre idee. Balancer dans ebp+var44 00 puis l'equivalent d'un en hexa
call a
db "coucou",0
:a
pop esi
xor edi,edi
push edi
push esi
push esi
push edi
call MessageBoxA
push edi
Call ExitProcess
Post a Comment