Blog
Skip to end of metadata
Go to start of metadata

A tavaly és tavaly előtt kiderült biztonsági hibák kapcsán nem lehet elégszer mondani: a Java futtatókörnyezet legyen friss vagy legyen kikapcsolva a böngészőben, mivel egyre több rosszindulatú program használja ki a Java környezetben meglévő biztonsági hibákat. Legutóbb a Java7 update 21 alatti verziókat támadó programra (malware-re) találtak rá a Kaspersky munkatársai, amely DDoS támadásokra felhasználható multiplatformos botnetet telepít a megfertőzött gépre.

Ideje lecserélni a Java7 update 51 alatti Java verziókat a munkaállomásokon, mivel a víruskeresők mindig egy kicsit le vannak maradva a hibát kihasználó programok mögött és már nem nyújt védelmet az se, hogy kevéssé elterjedt operációs rendszert használunk.

Szóval: frissíteni, frissíteni, frissíteni! (smile)

      
      
Page viewed times
  • No labels

5 Comments

  1. Főleg azért jó a frissítés, mert pl. local Network Derby DB esetén pl. nem indul el a NetworkServer.

    (https://issues.apache.org/jira/browse/DERBY-6438)

    Ugyanis az Update 51-ben van egy "jól" publikált biztonsági megszorítás. Az 1024 alatti portok korlátozva vannak. (Mint linuxon)

    Ami érdekes, hogy Win8.1 esetén ez a 49152 port alattiakra vonatkozik. (A release note szerint op. rendszerenként változó!)

    Ahhoz, hogy működjön, kell egy kiegészítő policy file.

    Ezzel csak 2 problémám van:

    1. Pl. egy amerikai egységsugarú usernek hogyan magyarázod el, hogy a win8.1-re rakjon fel egy plusz file-t, konfigurálja be és rakja bele az indító BAT-be?
    2. Ha megszorítás, akkor pl. 49152 port felett miért működik policy nélkül?

    Ez azért vicces, mert egy pilot bemutató előtt 2 nappal szopunk ilyenekkel. A frissítéskor persze nem hívja fel a figyelmet: "Hülyegyerek, ha frissítesz, nem biztos, hogy menni fog minden, ami eddig ment!"

    Értem én, hogy kell a frissítés, de a JRE-t nem szakemberek kezelik.

    Miért nem lehet egy popup ablak pl.: "A frrissítés olyan változásokat okoz, amely befolyásolja a rendszere működését! Kérem vegye fel a kapcsolatot a rendszergazdával!" vagy ilyesmi.

    :-@

     

     

    1. Auth Gábor AUTHOR

      Kevéssé hiszem, hogy desktop alkalmazáshoz ezek fontosak, ha pedig nem desktop alkalmazást akarsz bemutatni, akkor ne kliens gépen demózzál, hanem szerveren (vagy kliens gépen virtualizált szerveren), arra nem vonatkoznak ezek a változások.

  2. Főleg, hogy ez egy letölthető desktop alkalmazás volt. (smile)

    A demo nem a desktop alkalmazásra vonatkozott alapvetően, de az volt a lényege, hogy a szoftvert "bármilyen" meglévő alkalmazásból lehet használni. 

    Ennek ellenére a "bármilyen" opensource letöltött alkalmazással szoptunk, mert a "gyári" beállításokkal nem tudott a szintén letöltött telepített saját adatbázisával kommunikálni.

    A másik vicces dolog az, hogy van egy köztes alkalmazás (agent, demon, stb.) ami szintén TCP socketen kommunikál. Az működik, nem rinyál. Mi írtuk, JNA-t, sqlite-ot használ (smile).

    A gyors megoldás az JRE 7u25 downgrade volt.

     

    1. Auth Gábor AUTHOR

      Mostanában az Applet az igazi kihívás, hogy működjön Java7u45 felett és alatt is egyszerre, mert a legegyszerűbb módszer az, hogy két külön Applet-et fordít az ember különböző security beállításokkal és akkor nem kap ideggörcsöt egyik JRE se... meg a felhasználó se... (smile)

      1. Tudom, hogy rossz gyakorlat, de en mar annyit szivtam a kulonbozo appletekkel, hogy nalam telepites utan elso dolgom lehuzni a security szintet mediumra. Ami java appletet hasznalok (foleg kulonbozo remote konzolok), azoknal letszukseg, hogy mukodjon, es hogy senki ne pofazzon bele a mukodokepessegbe, ami mas applet meg futni akar, es nem en inditom el (marmint, nem tudom, hogy ott, azon az oldalon el kell indulnia egy Java appletnek), azt meg folyamatosan ESC-vel elhajtom a francba.

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