Blog
Skip to end of metadata
Go to start of metadata

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.

A Reflection API a Java 1.1 verzióban jelent meg, tervezésekor ügyeltek a biztonságos működésre, de az eltelt évek alatt ez a fegyelem fellazult, így jelenleg a Java futtató környezet tele van olyan kihasználható hibákkal, amelyek súlyos problémákat tudnak okozni, mivel a sandbox környezetből való kitörés után már nem abban az erősen szűkített környezetben fut, amelyre a felhasználó gondol.

A Project SE-2012-01 egy másik megállapítása a sebezhetőségek és a sandbox kitörési lehetőségek száma a három nagyobb Java implementátor futtató környezetében:

VENDOR

# ISSUES REPORTED# FULL SANDBOX BYPASS EXPLOITS
Oracle3117
IBM1710
Apple21

A tanulmány utolsó negyedét a kihasználható sebezhetőségek példával illusztrált listája foglalja el, illetve a cégek hibákhoz való hozzáállását – a fenti táblázatot magyarázandó:

  • Oracle
    • 31 hibából 29-et javított, meglehetősen lomha tempóban
    • Akkor adott ki rendkívüli hibajavítást, amikor a proof-of-concept mellé rosszindulatú kihasználás is terjedni kezdett
    • Kritikus sebezhetőség javítását ütemezte át 2013 februárra
    • A kommunikáció viszonylag részletes és rendszeres
  • IBM
    • Eleinte rendkívül formális jogi szövegekkel teli válaszok
    • A 17 hibát 2 hónapos átfutással javították
  • Apple
    • 5 hónapos átfutási idő
    • Csendes hibajavítás (nem kommunikálták a felhasználóik felé, hogy mit és miért javítottak)
    • Eltávolították a Java környezetet a böngészőkből

Összegezve

A Java sebezhetőségek okán ajánlott a böngészőben letiltani az Applet futtatás lehetőségét, és csak arra az időre engedélyezzük, amíg feltétlenül szükséges!

A tanulmány amúgy érdekes olvasmány, ajánlom minden Java fejlesztő és biztonsági szakember számára... (smile)

      
      
Page viewed times

3 Comments

  1. És ugyanakkor nem árt alá is írni az appleteket.

    1. Auth Gábor AUTHOR

      Itt alapvetően nem az a probléma, hogy alá van-e írva az applet (mondjuk én alapból tiltanám az aláíratlan appletek futtatását, legalább legyen egy plusz kattintás, mint amit a FlashBlock csinál).

  2. Igen, minden appletet alá kellene íratni és ne csak plusz kattintásról legyen szó, hanem a tanúsítvány igénylésére is(mindkét fél részéről), már ha egy böngészőben indul el a program. De kérdem én, melyik az a programozási nyelv amely segítségével olyan programot írhatunk, jelzem programot(mondjuk exe-t) és böngészőben fut mindenféle security kérdés nélkül. Alapvetően minden nyelvet lehet hackelni és minden nyelvvel lehet hackerkedni, főleg ha valaki a nagy világba ki a netre bocsátja. Az aláírott programocskák ha megfelelő tanúsítványt igényélnek igenis adhatnak egy biztonság érzetet bármi is a körülmény. Hackerek törtek már nem java rendszereket, és adatbázisokat is, akár úgy is, hogy nem voltak publikusak.

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))