- One mobilszolgáltatások
- Yettel topik
- Apple iPhone 16 Pro - rutinvizsga
- Samsung Galaxy A56 - megbízható középszerűség
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- Mi nincs, grafén akku van: itt a Xiaomi 11T és 11T Pro
- VoLTE/VoWiFi
- Mobil flották
- Xiaomi 15 - kicsi telefon nagy energiával
- Google Pixel 8a - kis telefon kis késéssel
Új hozzászólás Aktív témák
-
-
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...
-
modeller
aktív tag
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!
-
modeller
aktív tag
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) -
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.
-
modeller
aktív tag
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.
-
modeller
aktív tag
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.
-
modeller
aktív tag
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.
Új hozzászólás Aktív témák
Hirdetés
- DDR5 GAMER PC: Új RYZEN 7 8700F +RTX 4060/5060/4070/5070 +16-32GB DDR5! GAR/SZÁMLA! 50 FÉLE HÁZ!
- Dell Latitude 7410 Strapabíró Ütésálló Profi Ultrabook 14" -80% i7-10610U 16/512 FHD
- Szép! HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 32/512 Iris Xe FHD Magyar
- HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 8/512 Iris Xe FHD Magyar
- 512 Gb-os NVME-k
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest