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 |
---|---|---|
Oracle | 31 | 17 |
IBM | 17 | 10 |
Apple | 2 | 1 |
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...
3 Comments
Lehel Sipos
És ugyanakkor nem árt alá is írni az appleteket.
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).
Lehel Sipos
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.