Keresés: - [Re:] Továbbra is a Java a legsebezhetőbb

Legfrissebb anyagok

PROHARDVER! témák

Mobilarena témák

IT café témák

GAMEPOD témák

LOGOUT témák

Keresés

Új hozzászólás Aktív témák

#29 modeller aktív tag floatr #26

Új Válasz 2014-08-14 23:13:34 #29
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

modeller

aktív tag

válasz floatr #26 üzenetére

"De akkor meg rettegjetek, mert a bankok vakmerően használják "
Ti meg ne patcheljétek a javas dolgokat szerveren, mert felesleges, nincs benne hiba és/vagy nem lehet távolról kihasználni.
Ehhez nincs mit már hozzátenni.
#21 modeller aktív tag

Új Válasz 2014-08-14 20:23:55 #21
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

modeller

aktív tag

De lehet mindjárt kiderül, hogy a szerver oldali java sebezhetetlen, ott nem kell patchelni soha, mert nem lehet exploit-olni a hibákat, vagy nincsenek is hibák a frameworkben. Méltó társa lehet az unbreakable linuxnak...
Vagy inkább /o\ mert mégiscsak szakmai fórum...
#18 modeller aktív tag dtracer #17

Új Válasz 2014-08-14 19:58:40 #18
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

modeller

aktív tag

válasz dtracer #17 üzenetére

Szerintem te nem egészen érted miről van szó, de talán mindegy is.
Még jó, hogy gyorsan leszedted a hogyan triggerelhet user input egy lyukat kérdésedet, mert már éppen irtam volna egy LMGIFY-et, hogy tovább növeljem a szinvonalat...
"persze az általad linkelt cikk az egy osztály engedélyeinek kijátszásáról szól, nem pedig programozási hibáról"
Értem, tehát, ha az osztály engedélyei kijátszhatóak és ezáltal az egész java sandboxból ki lehet törrni és bármit csinálni az nem programozási hiba. Nyilván feature. Nem tudom miért kaphatta a legmagsabb veszélyességi besorolást az oracle-től, de tudod mit: nem is akarom tudni!
#15 modeller aktív tag dtracer #13

Új Válasz 2014-08-14 19:36:08 #15
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

modeller

aktív tag

válasz dtracer #13 üzenetére

Nem kell bevninni bytecode-ot, rosszindulatú user input (vagy, ha api-t/service-t publikálsz, akkor egy service hivás is) triggelrelheti a lyukat.
(a lyuk már eleve ott van, hogy pl. egy hibás fgv-t hivsz, ami a frameworkben hibás. Tehát nem a lyukat kell kintről beletenni a kódba, hanem csak triggerelni, a framework hibáját)
#14 modeller aktív tag Gregorius #12

Új Válasz 2014-08-14 19:33:55 #14
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

modeller

aktív tag

válasz Gregorius #12 üzenetére

Láttam már olyat, hogy ritka csillagegyüttállás esetén 10 byte-ot tudott kiirni egy tempfile-ba, amit időnként amúgy is törölt egy job. Önmagában ez bagatel, mert ezzel nem törsz be sehova, sőt még dos-olni se tudsz, mert nem fog betelni a temp drive, de kombinálva más hibákkal már csúnya dolog is lehet belőle.
#10 modeller aktív tag floatr #9

Új Válasz 2014-08-14 18:11:23 #10
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

modeller

aktív tag

válasz floatr #9 üzenetére

Ne vicceljünk már ezzel. Ennyi erővel minden szerver tűzfal mögött van, meg DMZ-ben és csak másik szerver hivja és hasonlók. Tökmindegy. Ilyenkor szokták még előhozni, hogy "ó csak local exploit, távolról nem lehet kihasználni". Aztán nagy szemekkel néznek, amikor egy önmagában bagatel remote exploit-al kombinálva szanaszét törnek mindent.
Ezen nincs mit szépiteni, a java hibák a szerveren használt java-s dolgokat is érintik.
"szintén ritka, hogy problémás júzerek támadnának."
Ezt egy biztonsági szakértő meghallja, sirva futna el. Nem önmagában kell vizsgálni a hibákat, hanem rendszerszinten, ahol az apróbb hibák hatványozódnak és a végén átjáróház az egész rendszer.
" Elég gáz ez is, de JRE/plugin probléma, nem a "nyelvé"."
De hát ugyanazt a JRE-t használják szerveren is ami ezer sebből vérzik. A "nyelv" szón meg felesleges pörögni, mindenki tudja, hogy miről van szó, mint irtam .net hiba esetén sem a nyelv a hibás és php hiba esetén sem a nyelv a hibás, hanem a framework.
#8 modeller aktív tag floatr #4

Új Válasz 2014-08-14 17:19:20 #8
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

modeller

aktív tag

válasz floatr #4 üzenetére

Tessék
Ez egy nagyon durva java hiba, mind kliens mind szerver oldalon működött, simán ki lehet lépni vele a sandbox-ból és bármit művelni a gépen. Ha a szerver oldali kódod használta az MBeanInstantiator-t és a runtime-od a lyukas szériából volt (mivel 0day exploit, ezért mindenkinek az volt) akkor lyukas is lett tőle az alkalmazásod.
Szerintem amiket te kliens oldali hibáknak gondolsz annak nagyon nagy százaléka pont ugyanúgy érint szerveroldalon is és ilyenből végtelen mennyiségű van. Más kérdés, hogy szerveren általában jobban felügyelve van a környezet, a futatott dolgok, de ettől még a java hibák ott is nagyon súlyosak. Aki nem patcheli folyamatosan a java-t szerveren, mert elhiszi, hogy az a kliens oldalt meg a böngészőket érinti az konkrétan hülye.
#2 modeller aktív tag floatr #1

Új Válasz 2014-08-14 16:18:57 #2
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

modeller

aktív tag

válasz floatr #1 üzenetére

Messze nem csak a böngésző pluginról van szó. Keress rá a java-s CVE-kre, csak a JRE-t több mint 130 hiba érintette tavaly. Ezek a hibák nem csak a böngészőből használhatók ki, hanem desktopos alkalmazásokból és persze szerver oldalon is, ami JRE-t használ.
"Nem a java nyelvről van szó, hanem a böngésző pluginről."
Igen, a .net hibák, meg nem a .net nyelvet érintik, hanem csak egy adott .net framework-öt.
A helyzet az, hogy valóban iszonyat lyukas a java. Nálunk az összes gépről tiltva van, kivéve aki ányk-zik, mert ott sajnos muszáj ezt a hulladékot használni. Egyébként érdemes rákeresni, épp nemrég lett használhatatlan több bank java-s ebankja, az ügyfélkapus filefeltöltés és még sok más egy új java frissitéstől. Vissza kellett rakni egy még lyukasabb verziót az archiv letöltésekből. Vicc az egész.