Biztonsági hibák a Java környezetben

Java

Az idei Devoxx Java fejlesztői konferencia egyik érdekes előadása Adam Gowdiak nevéhez fűződik, a bemutató vázlatát a Security vulnerabilities in Java SE linket követve olvashatjuk el, a PDF formátumú prezentációt pedig a se-2012-01-devoxx.pdf letöltésével tekinthetjük meg.

Az előadás központi témája az SE-2012-01 projekt, amely a Java futtatókörnyezet sandbox mechanizmusát veszi górcső alá, ebből "esett ki" nyáron a hírhedt Java sebezhetőség is (Java 7 sebezhetőség). Úgy gondolom, hogy tapasztalt Java fejlesztőknek nem okoz meglepetést, hogy a homokozóból való kitörés leginkább a Reflection API segítségével lehetséges, így az előadás nagyobb részét tekintve erről olvashatunk.

Bővebben itt.

( mrev | 2012. 11. 26., h – 17:06 )

Állandósult a Java biztonsági hibáival kapcsolatos szóbeszéd. Ez mára oda vezetett, hogy vállalati alkalmazásokban sok helyen tiltják a Java klienseken történő használatát. Helyette böngésző + javascript alapú megoldásokat erőltetnek. Rendben, de ha ezt a biztonságra hivatkozva teszik, az meglehtősen nevetséges. Szerintem a Java az összes hibájával együtt biztonságosabb, mint egy böngésző, ami a Javahoz képest egy óriási backdoor. Amúgy nem értem, hogy egy vállalati alkalmazás szempontjából miért olyan izgalmas, ha a Java program ki tud törni a homokozóból. Nem alkalmazunk, pláne nem írunk olyan programot, ami ki akar törni, és annyi.
--
ulysses.co.hu

Kód végrehajtásról van szó. Fejtsd ki, hogy te milyen alkalmazást készítenél, ami usertől származó kódot hajt végre. Az egész blogposzt is arról szól, hogy milyen JVM biztonsági hibák vannak, mind-mind végrehajtható kódról van szó.
Nem SQL injectionről, és nem XSS-ről, sőt nem CSRF-ről.

Lol. Szerintem nálad áll fenn megértési nehézség: Nem magáról a biztonsági hibáról írtam, hogy nevetséges, hanem arról, hogy erre hivatkozva a Javát letiltják, és helyett böngésző alapú megoldásokat erőltetnek. Vagyis a bicikli elől ijedtükben a villamos elé ugranak.

A másik, hogy miért gondolom, hogy vállalati környezetben nem túl érdekesek ezek a biztonsági hibák: Csak megbízható forrásból származó programot alkalmazunk. Mi a megbízható? Hát az, amit magam fejlesztek. Arról biztosan tudom, hogy nem akar kitörni a homokozóból.

--
ulysses.co.hu

"Csak megbízható forrásból származó programot alkalmazunk. Mi a megbízható? Hát az, amit magam fejlesztek. Arról biztosan tudom, hogy nem akar kitörni a homokozóból."

Ezek szerint nem sikerült megérteni a probléma lényegét... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Mimimi?

Az vilagos, hogy nem arrol van szo, hogy a megbizhato forrasbol futo kodbol kitorjunk, hanem arrol, hogy van egy sandbox, amely arra szolgal, hogy ne tudjon kitorni onnan semmi e ezt a Java megis engedi. Picit se gaz gondolom, ha mondjuk a beszallitodtol ilyen modon tudnal csak rendelni, o meg kozben sunyiban vegez egy ki ipari kemkedest.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Köszi, de régóta nem pkg-zok, mert ekkora nagyságú könyvtárakat sqsh-val összenyomorítok, majd fstab-bal olvastatok be bootoláskor. Ilyet meg slapt-get nem old meg
De megoldottam (jól emlékeztem)...

Amúgy a tárolókat sosem tudtam rendesen beállítani, csak néhny éve az ubuntuknál. Ezért szoktam rá a kézi telepítésre.

root[lib]# slapt-get -search jre
jre-6u25-i586-1 [inst=no]: Java(TM) 2 Platform Standard Edition Runtime Environment.
root[lib]#

(ez mán' régi..)

---
--- A gond akkor van, ha látszólag minden működik. ---
---