Új hozzászólás Aktív témák
-
sghc_toma
senior tag
bambano (#8): valoban ismert volt ket hete a bug, de csak a mult heten keszult ra exploit..
ddekany (#17): DEP az adatteruletrol valo kodfuttatast akadalyozza meg.. ebben a hibaban egyetlen regiszter erteket kontrollalja a tamado, abba meg nem nagyon fer shellcode szoval szerintem itt valami return-to-libc moka van..
in asm we trust
-
sghc_toma
senior tag
pontosan hogyan lehet szerinted itt meghivni egy valid fuggvenyt rossz parameterezessel? en nem latom, hogy lehetne modositani az EBX regisztert..
azt sem fogjuk tudni, hogy a táblázat határait illegálisan megszegve, az ott levő adatokat függvényre mutató mutatóként értelmezve mire lehet rávenni a szervert, mert túl sok a variációs lehetőség.
na, tobbek kozott ezert volt egy het, mire bizonyitva lett, hogy tenylegesen es megbizhatoan meg lehet csinalni azert ezt a hibat nem trivialis rendesen kihasznalni..elobbi hsz-emhez: hulyeseget irtam.. nem 32 bit a mienk, ott az egesz packet, amiben mar lehet, hogy elfer valami aranyos payload.. csak hat ugye ha kozvetlenul ezt akarjuk futtatni, azt megfogja a DEP..
in asm we trust
-
sghc_toma
senior tag
bambano (#42): OK, es honnan tudod, hogy az az ertek, ami az EBX-ben van, nem volt validalva? egyedul a Process ID High mezorol tudjuk, hogy nincs ellenorizve..
ddekany (#43):
de, biztos, hogy csak egy van neki.. nezd meg a forrast!
tudom, hogy leteznek modszerek a DEP megkerulesere (ezert volt ott a kozvetlenul szo), lattam is mar parat mukodni.. lesz metasploit modul, meg fogjuk tudni, ImmunitySec-ek hogyan trukkoztek..in asm we trust
-
sghc_toma
senior tag
dabadab (#45): de, nyilvan leteszteltek mar, es senki nem szolt, hogy haho, ott meg valami mas validalatlan cucc is van.. eppen ezert hajlando vagyok feltetelzni, hogy nincs..
ddekany (#46): na jo, persze, meghivhatok egy akarmilyen fuggvenyt, akarhany parameterrel, aztan valamit majdcsak leszed a stack-rol, de azert ez egy kicsit overkill egy esetleges BSOD eloidezeshez..
in asm we trust
-
sghc_toma
senior tag
-
sghc_toma
senior tag
ok, tehat akkor te nem errol a bugrol beszelsz, hanem egy olyanrol, ami legjobb tudomasunk szerint nincs, de akar elofordulhat az is, hogy van.. nem mellesleg a hiba letezesenek lehetosege arra a feltetelezesre alapul, hogy az SMB packet, illetve az EBX altal mutatott struktura* tartalmat nem lehet validalni..
*en is felteteleztem, hogy EBX egy strukturara mutato pointer, megneztem, tenyleg annak tunik.. megprobalom kideriteni, hogy mi is van benne pontosan, de igy hullafardtan eleg kuszanak tunik a kod..
in asm we trust
-
sghc_toma
senior tag
ez a bug konkretan arrol szol, hogy az SMB2 header egyetlen 16 bites mezoje (Process ID High) egyetlen helyen nincs ellenorizve hasznalat elott.. nem a pontatlansag a gond, hanem az, hogy gyakorlatilag alaptalanul feltetelezed, hogy van mas ellenorizetlen dolog is..
ennyi erovel en is mondhatnam, hogy mondjuk a FreeBSD TCP/IP stack-je bugos, mert elkepzelheto, hogy nincsenek ellenorizve rendesen mondjuk az IP packetek.. persze nem lattam meg kozelrol FreeBSD-t, csak tippelek..
in asm we trust