Java bevat mogelijk opnieuw beveiligingsgat

Door Joost Schellevis, woensdag 16 januari 2013 16:31, 87 reacties • Feedback
Submitter: DRaakje

Java, dat de afgelopen tijd kampte met diverse beveiligingsproblemen, bevat mogelijk nog een beveiligingsprobleem. Op een cybercrime-forum zou een exploit voor het nog onopgeloste probleem zijn aangeboden. Of die claim klopt, is onbekend.

Java Beveiligingsjournalist Brian Krebs schrijft op zijn weblog dat op een 'exclusief cybercrimeforum' een administrator een exploit voor een zero day-beveiligingsprobleem te koop heeft aangeboden. De beheerder zei de exploit aan maximaal twee mensen te willen verkopen, tegen een prijs van 5000 dollar. Inmiddels is het topic verwijderd, wat er volgens Krebs op kan wijzen dat beide kopers zijn gevonden.

Details over het beveiligingsprobleem zijn onbekend, net als de implicaties van de bug. Het is op dit moment niet te zeggen of de claims van de beheerder kloppen. Het gebeurt vaker dat beveiligingsproblemen in software op de zwarte markt via fora worden verhandeld. Vooral zero day-problemen, die nog niet gepatcht zijn en vaak nog zelfs nog niet eens bekend zijn bij de ontwikkelaar van software, gaan voor veel geld van de hand.

Het zou de zoveelste keer in korte tijd zijn dat Java met een beveiligingsprobleem kampt. Maandag bracht Java-ontwikkelaar Oracle nog een patch uit die een eerder beveiligingsprobleem moest oplossen, maar volgens een beveiligingsbedrijf heeft de patch het probleem niet opgelost. Het afgelopen halfjaar kampte Java met diverse beveiligingsproblemen. Beveiligingsdeskundigen raden gebruikers aan om de software te verwijderen. Verouderde versies van Java worden door Firefox en Safari geblokkeerd.

Exploit kits zoals BlackHole gebruiken beveiligingsproblemen in plug-ins als Java om malafide software te installeren op computers van nietsvermoedende internetters. De software wordt bijvoorbeeld verspreid door advertentienetwerken te infecteren of in te breken op webservers, zoals bij NU.nl en De Telegraaf gebeurde. Met behulp van de exploit kits kunnen bijvoorbeeld banktrojans worden geïnstalleerd. Zulke trojans kunnen internetters geld afhandig maken.

Reacties (87)

+2 Dreamvoid

Oracle

16 januari 2013 16:34

Voor zover ik weet wordt aangeraden om de browser plugin (waarmee je willekeurige kwaadaardige code op internet kan draaien) uit te schakelen of te verwijderen, niet de JRE zelf.

OddesE
@Dreamvoid • 16 januari 2013 21:15

Tot nu toe dus steeds alleen bugs in de plugin.

plug-ins als Java

Ik begin me hier nu echt aan te ergeren. Schrijft steeds dezelfde persoon deze artikelen voor Tweakers? Of zijn er meerdere redacteuren bij Tweakers die niet het verschil weten tussen Java en de browser plugin die bij Java hoort?

Lezen ze de comments wel? In de comments is er al een paar keer op gewezen dat dit twee verschillende dingen zijn (Java en de plugin) maar toch blijft Tweakers de twee maar op één hoop gooien in de berichtgeving. Of negeert men dit bewust? Te ingewikkeld voor de lezer? Zelf vind ik het er juist onduidelijk en ingewikkeld door worden als verschillende zaken steeds met elkaar verward worden...

Blitzdoctor
@Dreamvoid • 16 januari 2013 16:43

Het is volkomen onduidelijk of het nou om telkens om de browser plugin of de JRE gaat die exploits bevat. Heeft iemand daar een eenduidig antwoord op?

In ieder geval heb je de browser plugin zo goed als nooit nodig (nou ja, bij mij staat Java uit in de browser, en ik kom nooit meldingen tegen), dus die uitzetten en klaar.

+3 DCK
@Blitzdoctor • 16 januari 2013 16:53

Het probleem zit in beide componenten: de browser plugin biedt simpelweg een mogelijkheid om (een subset van) de JRE in een browser te gebruiken.

Iedere website kan ergens verborgen op de pagina in een Java-applet daarmee de exploit gebruiken, zonder dat de bezoeker dit in de gaten heeft. Elke webpagina wordt met een lekke Java-plugin direct een gevaar.

Hoewel de JRE ook geexploiteerd kan worden heb je doorgaans veel meer controle over welke Java-programma's er op jouw systeem draaien. Daarom loop je dus net zoveel gevaar als vele andere lokale exploits die ook dikwijls (maar met minder publiciteit) verschijnen voor andere lokale runtimes. De reden voor deze ophef en extra voorzichtigheid is dan ook voornamelijk dat dit lek ook te exploiteren is via websites.

[Reactie gewijzigd door DCK op 16 januari 2013 16:55]

? ?
@DCK • 17 januari 2013 11:47

Daarom dat ik click-to-play voor alle plugins aan heb staan in Chrome.

Simpel !

Waarom zou ik Flash, Java of een andere plugin nodig hebben tijdens het surfen? Geen reden! Tenzij ik op youtube kom en dan zelf beslis een Flash filmpje te starten.
Of op een bankwebsite Java even toe te laten.

Waarom doen browsers dit niet standaard?

Net hetzelfde met THRID-PARTY troep. Waarom heb ik in mijn browser geen mogelijkheid om ALLE thridparty cookies, afbeeldingen, javascript standaard te blokkeren?
Als tweakers interessant wil doen door afbeeldingen te laten vanaf tweakimg.net is dat hun probleem. Doe dat mooi vanaf img.tweakers.net. Wil je je daar als site niet aan houden? Dan wordt het niet getoond in mijin browser. Zo zou het moeten zijn en zo zouden opeens 99% van alle internet exploits opgelost zijn.

+2 dis.pater
@? ? • 17 januari 2013 13:19

Als tweakers interessant wil doen door afbeeldingen te laten vanaf tweakimg.net is dat hun probleem. Doe dat mooi vanaf img.tweakers.net. Wil je je daar als site niet aan houden? Dan wordt het niet getoond in mijin browser. Zo zou het moeten zijn en zo zouden opeens 99% van alle internet exploits opgelost zijn.

Dit heeft nu eens niets met "interessant doen" te maken. Vanaf een subdomein versturen zorgt er nog steeds voor dat cookies ook verstuurd worden, wat je bij zekere schaal wil vermijden (of als good practice, de facto) en dan gebruik je dus een apart domein. Google doet het, Yahoo! doet het, Facebook doet het, etc. etc. Je zou nog bitter weinig zien op de meeste sites als browsers jouw voorstel zouden volgen.

Lees je hier eens in anders: https://developers.google...cs/best-practices/request

? ?
@dis.pater • 17 januari 2013 14:54

aarom zou je luisteren naar Google, een partij die héél veel te verliezen heeft mocht een browser dit mogelijk maken? Trouwens is het met allerlei plugins al mogelijk.

CDNs zijn leuk, maar het principe draagt bij tot onveilig gedrag.

Tuurlijk is rijden aan 200 km/u op de autosnelweg sneller, maar veiliger? Neen.
Google heeft een belangrijke reden om "200 km/u" te promoten. Hoe "veiliger" het internet: geen Google Analytics en andere brol meer.

[Reactie gewijzigd door ? ? op 17 januari 2013 14:56]

Teijgetje
@Blitzdoctor • 16 januari 2013 16:55

Het gaat al de hele tijd om plug-ins;

4e alinea,
Exploit kits zoals BlackHole gebruiken beveiligingsproblemen in plug-ins als Java om malafide software te installeren op computers van nietsvermoedende internetters.

Edit;
Grappig dat het nu lijkt of ik op DCK reageer ipv Blitzdoctor, waar ik op gereageerd heb.
De nieuwe layout blijft onduidelijk.

@DCK;

Als je de plug-in uitschakelt heb je geen last, mits je niet overal op klikt en zo iets anders naars binnenhaalt waar je in de laatste alinea aan refereert.
Imo kun je zonder plug-in niet de JRE op je computer infecteren, wel jouw computer en dan met name het geheugen dat een applicatie of runtime gebruikt.
De exploit komt binnen via de plug-in maar installeert zich niet in JRE maar op de pc zelf.
En wat dus voor al je software geldt ipv JRE standalone, op je pc.
JRE standalone voert gewoon Javascript uit van een programma op je pc dat geschreven is in Java.
Nu maak je een mooi verhaal in de laatste alinea om te besluiten met dat deze exploits ook via browsers gaan, inderdaad en dan om precies te zijn alleen, niet ook, via de Java plug-in.

Geef dan de tip om DEP voor alle software aan te zetten om je extra te beveiligen tegen virussen en andere beveiligingsrisico`s, deze staat standaard alleen voor Windows software aan.

Zoek naar "effecten" in instellingen (=kortste zoekterm (in W8)) of "de prestaties en weergave van windows aanpassen" > tabblad preventie van gegevensuitvoering (DEP)> "voor alle programma`s en services" aanvinken > toepassen >reboot

Dit zorgt dat hacks die geinjecteerd worden in de beschikbare geheugenruimte, voor de applicatie of runtime, niet uitgevoerd worden en de pc het programma of runtime afsluit, en vervolgens melding geeft dat er vanuit dat geheugendeel code geprobeerd wordt uit te voeren.
Natuurlijk moet de CPU dit ondersteunen, dit wordt dan onderaan dat tabblad aangegeven.

En zorg natuurlijk voor een goede real-time virusscanner.(of blijf van internet, nog veiliger.

)
En laat je Java browser plug-in voorlopig uit tot duidelijk is of het lek echt gedicht is, zoals veel gezegd heb je hem maar in enkele gevallen nodig.

[Reactie gewijzigd door Teijgetje op 16 januari 2013 18:36]

+1 DCK
@Teijgetje • 16 januari 2013 19:54

Op het eerste punt heb je gelijk - ik had eerst de rapportage van de bug met een andere ingewisseld en het blijkt dat dit een specifieke bug in de sandboxing features van Java applets is. Het gaat dus alleen om Java applets die een gevaar vormen - niet desktopapplicaties. Het gaat dus inderdaad niet om een algemene Java exploit (wat ik eerst dacht) maar om een exploit van het appletsysteem. De plugin uitschakelen is dus genoeg.

Wat je zegt over DEP is grote onzin. De payload van een exploit hoeft helemaal niet voorkomen te worden door Data Execution Prevention - er zijn heel veel manieren om dit te omzeilen. DEP is zeker geen wondermiddel dat allerhande exploits tegengaat.

Ten tweede heeft DEP juist geen enkel effect als het om Java gaat. Java wordt uitgevoerd in een JIT, en een JIT moet juist iets doen wat tegen JIT ingaat: dynamisch code in geheugen stoppen en uitvoeren. De geheugengebieden in een JIT worden juist dus niet behandeld door DEP, en exploits die in C/C++ door DEP zouden worden opgevangen werken in een door de JIT gemanagede omgeving ook nog. DEP aanzetten (staat het niet altijd al aan uberhaupt?!) is dus totaal niet nuttig om je te beschermen tegen Java exploits.

onox
@DCK • 16 januari 2013 23:17

DEP maakt gebruik van de NX bit en regelt dat pages of schrijfbaar óf uitvoerbaar zijn. De JVM zal om JIT te laten werken, waarschijnlijk gebruik maken van mprotect() (zo heet het iig in UNIX, maar voor Windows zal er vast ook wel zo iets dergelijks zijn).

Kernel patches als PaX (Linux) kunnen restricties opleggen aan mprotect() (http://en.wikipedia.org/wiki/PaX#Restricted_mprotect.28.29) zodat JIT niet meer mogelijk is. Voor sommige programma's (Java, LLVM, JavaScript engines in browsers) zul je deze restricties weer juist moeten disablen als je ze uberhaupt wilt kunnen gebruiken.

Voor meer veiligheid heb je dus NX én mprotect() restricties nodig.

Teijgetje
@onox • 17 januari 2013 07:41

Onzin is natuurlijk een relatief begrip.
Net als goed lezen.

Ik zeg ook niet dat je dan absoluut veilig bent, maar veiliger, er staat extra te beveiligen (tov niet voor alle software en services aan)
Alle beetjes helpen en met DEP aan voor alle software en services ben je "beter beschermd" van injecties in het toegekende programmageheugen die code uit willen voeren.
(@DCK; dat je vraagt of het niet altijd aan staat geeft eigenlijk weer dat het voor jou ook een goede tip is om dit soort problemen voor te zijn door het aan te zetten.

)
Dus nogmaals, je bent een beetje extra beveiligd tov virussen en ellende die van dat gat gebruik kunnen maken, niet tegen alles en het zit gewoon in Windows, alleen moet je het even aanzetten.
Daarnaast was deze tip eigenlijk gereageerd op jouw laatste alinea, waar je virussen in het algemeen betrekt, dit gaat dus over virussen en ellende in het algemeen, niet over de Java plug-in specifiek, daarvoor geldt uitzetten.

Quote Windows;
Wat is Preventie van gegevensuitvoering?

Preventie van gegevensuitvoering kan pc-schade als gevolg van virussen en andere aanvallen helpen voorkomen.

Toepassingen reserveren een deel van het geheugen voor gegevens en een ander deel voor instructies die door uw toepassingen worden gebruikt. Hackers proberen toepassingen om de tuin te leiden door schadelijke gegevens (feitelijk zijn dat instructies) in het geheugendeel voor de gegevens uit te voeren. Hierdoor kan een hacker de controle over uw pc mogelijk overnemen.

Preventie van gegevensuitvoering kan u helpen uw pc te beveiligen door te voorkomen dat toepassingen gegevens uitvoeren in het geheugendeel dat voor instructies wordt gebruikt. Als Preventie van gegevensuitvoering een toepassing detecteert die op deze wijze gegevens uitvoert, wordt de toepassing gesloten en wordt er een melding weergegeven.
end quote

Het kan dus helpen en zou imo dus beter aanstaan...
Daarnaast moet je natuurlijk goede beveiligingssoftware draaien, liefst real time. (staat er ook).

Tevens blijft het advies, ook in mijn post, om de browserplugin uit te schakelen tot duidelijk is dat het goed gepatched is in een volgende update en veilig is.
(Als de link niet naar jouw OS gaat, nu windows, dan moet je even via Downloads naar jouw OS gaan en in de linker kantlijn klikken voor info over hoe in jouw OS uitzetten.)
Dat zal echt niet tot mei duren zoals ik ook hier en daar op internet lees.
Deze patch (7u11) beveiligd iig tegen niet-vertrouwde certificaten, maar als je zelf doorklikt dan kan daar geen update tegen op.
Hier een oude exploit/malware in actie voor Linux, Apple en Windows als voorbeeld.

Inderdaad dus en, en , en , en , en dan nog zullen er altijd gaten in software naar boven komen, helaas de realiteit anno 2013.

Ik stoor me een beetje aan de bangmakerij dat heel Java verrot is.
Andere sites zoals deze hebben het wel gewoon over de plug-in die onveilig is en die je dus momenteel niet wil gebruiken, ook niet op vertrouwde sites, met als bron Sophos security
Daar wordt ook uitgelegd dat als je de Java plug-in uitschakeld de pc nog gewoon Javascript kan gebruiken waar het lek dus niet in zit, zodat sites qua opmaak gewoon getoond worden.
Een nuance die ik een beetje mis in al het gebash en op Tweakers .

[Reactie gewijzigd door Teijgetje op 17 januari 2013 08:06]

+1 hiostu
@Dreamvoid • 16 januari 2013 17:03

Ik heb gewoon beide niet meer op mijn systemen draaien. Ik heb echt geen hoge pet meer op van de kwaliteit van de JRE en Plugins van Sun/Oracle. Ik moet zeggen dat eigenlijk bijna nooit iets werkt omdat ik het niet geinstalleerd heb staan.

OddesE
@hiostu • 16 januari 2013 21:21

Ik heb echt geen hoge pet meer op van de kwaliteit van de JRE en Plugins van Sun/Oracle.

Auw. Twee-op-een-hoop. De plugin is en was altijd al ruk. Ok. Maar de JRE? Daar heb ik toch wel een hoge pet van op hoor. Gebeurt niet vaak dat daarin echt grote fouten zitten en hij crasht ook eigenlijk nooit. En door het automatische geheugenbeheer en wat andere standaard 'beveiliging' zitten in de meeste Java applicaties ook relatief weinig lekken vergeleken met normale software omdat dingen als buffer overflows, pointers naar vrijgegeven geheugen, geheugen lekken e.d. gewoon veel minder voorkomen.

Maar goed met de manier waarop Tweakers de berichtgeving over dit onderwerp aanpakt kan ik je niet kwalijk nemen dat je de JRE en de plugin op één hoop gooit.

Teijgetje
@hiostu • 16 januari 2013 19:43

"nooit iets niet werkt" bedoel je.
Als nooit iets werkt dan heb je het dus nodig.

rickboy333

@Dreamvoid • 16 januari 2013 16:59

Tja, Ik snap eigenlijk niet waarom het als plug-in in je browser zit. Ik heb hem nog wel maar nu uitgeschakeld sinds java 7 ubberhaupt op de markt kwam.

Maar ik snap ook niet Waarom Oracle niet alles zo snel mogelijk patcht. Oke een patch in elkaar knutselen duurt wel ff. Maar Als Oracle nu eens alles controleert. Of ze huren een paar HATs white HATs (white HATs hackers zijn zeg maar goede hackers geen slechte(die heten black HATs hackers)) in. Dan Patch alle problemen in een keer. En klaar ben je.

Ik denk dat Oracle veel marktaandeel verliest.

[Reactie gewijzigd door rickboy333 op 17 januari 2013 19:40]

+1 Dreamvoid

Oracle

@rickboy333 • 16 januari 2013 17:14

Oracle zal het werkelijk een worst wezen als niemand meer hun browser plugin gebruikt. De focus op de enterprise markt (en daarmee het droppen van Java applets als webplatform) was onder Sun al ingezet, en onder Oracle alleen maar sterker geworden. Er zitten niet voor niets zoveel bugs in die browser plugin, hij zit er alleen maar voor legacy redenen, de development ervan heeft gewoon geen prioriteit. En al hun partners in het OpenJDK project (IBM, SAP, Apple) denken er net zo over.

Wat Oracle eigenlijk had moeten doen was in 2010 bij de overname duidelijk zijn: wij zijn een enterprise bedrijf, de browser plugin boeit ons niet, we stoppen ermee, wil je een Java plugin ga dan zelf maar een port bouwen van IcedTea Web. Dit is 1 van de zeldzame keren dat Oracle juist niet bot en hard genoeg is geweest.

[Reactie gewijzigd door Dreamvoid op 16 januari 2013 17:20]

+1 Cobalt
@Dreamvoid • 17 januari 2013 00:41

Oracle is anders wel behoorlijk aan het investeren in JavaFX en ziet wel kansen in applets. http://www.oracle.com/tec...pdf?ssSourceSiteId=ocomen

0 Dreamvoid

Oracle

@Cobalt • 17 januari 2013 09:53

Ik vraag me af of ze er werkelijk nog in geloven. JavaFX (voor het grote publiek) is doomed, niet zozeer vanuit technisch oogpunt, maar politiek. Sun was al machteloos om het te pushen en Oracle heeft al helemaal geen vrienden. Platformonafhankelijkheid is alleen zinnig als vrijwel alle clients ook een JavaFX framework hebben, en dat doel is verder weg dan ooit. Microsoft en Apple blokkeren het bewust in hun nieuwste platforms (iOS, de OS X App Store en Windows Metro/Modern UI), en Google heeft zijn eigen Dalvik JVM en gaat zeker na de knokpartij met Oracle nooit JavaFX supporten. Met zo'n groot deel van de markt buiten bereik wordt JavaFX nooit een succes. De toekomst is helder, OSsen worden gesloten en platformonafhankelijkheid is (buiten simpele websites) dood.

[Reactie gewijzigd door Dreamvoid op 17 januari 2013 10:03]

0 gimbal
@Dreamvoid • 17 januari 2013 17:20

En -daar- ben ik het nu eens 100% mee eens. Weg met de browser plugins, weg met webstart.

SuBBaSS
@rickboy333 • 16 januari 2013 19:05

@rickboy333: Het is hartstikke goed om achtergrond info te geven (dat gedeelte tussen haakjes in je post) maar dan moet je natuurlijk wel correcte info geven, voordat mensen hier nav. je post gaan denken dat er ook al iets van racisme in de hackerswereld is over de huidskleur.

Je doelt op white HATs, net zoals grey HATs en black HAT hackers hebt, voornamelijk van elkaar onderscheiden door "goede bedoelingen"; white hats worden ook wel ethische hackers genoemd.
Zie het aub niet als een persoonlijke aanval!

Ik heb na dit zoveelste bericht besloten om ook maar die hele java-meuk te verwijderen en te kijken waar ik eventueel tegenaan loop. Oracle heeft de afgelopen tijd goed zijn best gedaan om het vertrouwen in hun software een beste knauw te laten krijgen. Foutje (~lek) kan gebeuren, maar nu al een aantal maal achter elkaar en dan ook nog eens vage verklaringen over de fix...
Daarbij heb ik persoonlijk absoluut geen medelijden met het bedrijf want er wordt grof geld verdiend daar (getuige oa. de uitspattingen van de CEO) en als er dan zo laks opgetreden wordt dan mag het van mij massaal geboycot worden. Power to the people!

BaszCore
@Dreamvoid • 16 januari 2013 16:45

En als je een beetje internet, muziek luistert/films kijkt, games speelt, download etc op je pc, heb je ook niet eens JRE nodig op je pc. Draai al maanden zonder JRE en nog nooit iets tegengekomen wat problemen geeft.

+1 MrOmegaForce
@BaszCore • 16 januari 2013 18:09

Ja, heb hem sinds het lek ook verwijderd en ook nog niks tegengekomen. Wat natuurlijk wel een probleem kan zijn is dat programmeurs die java nodig hebben een risico kunnen lopen.

+1 Dakreal
@Dreamvoid • 16 januari 2013 16:53

Deze plugin staat bij mij standaard uit, zo kunnen der ook geen scripts uitgevoerd worden zonder dat ik er erg in heb. Ik krijg nu telkens de vraag of ik de plugin wil inschakelen als ik een website benader welke hier gebruik van maakt.

+2 Rynus_Rein
17 januari 2013 13:34

Sowieso kan er geen 'bug' in 'Java' zitten. Java is de taal, de specificatie. Er zijn tal van implementaties van (Oracle's VM, OpenJDK, Microsoft's JVM, etc). De browser-plugin is weer een ander verhaal:

- Java (specificatie)
- JVM (Java Virtual Machine, implementatie, bijv. van Oracle) / JRE / JDK
- Java (browser) plugin

Meestal worden er gaten in de Java browerplugin gevonden, zelden in de JVM.

+2 gimbal
@Rynus_Rein • 17 januari 2013 17:24

Je hebt gelijk, maar Java is ook een platform net als .NET een platform is. Je hebt dan weer Java de taal welke gebruikt kan worden binnen Java het platform, net als een hele sloot andere programmeertalen overigens.

Wanneer men aan het roepen is over "Java" heeft men het meestal zonder het te weten over het Java platform. Ik zie de plugins ook als (jammerlijk) onderdeel van dat platform, dus het is op zich wel correct.

True
16 januari 2013 16:36

De andere kant op: contests waar je geld krijgt voor het vinden van het grooste lek: nieuws: Google looft 1 miljoen dollar uit voor Chrome-exploits Het is natuurlijk maar een beetje hoe je er mee omgaat...

+1 Dylan93
@True • 16 januari 2013 16:57

De andere kant op: contests waar je geld krijgt voor het vinden van het grooste lek: nieuws: Google looft 1 miljoen dollar uit voor Chrome-exploits Het is natuurlijk maar een beetje hoe je er mee omgaat...

Ik snap ook helemaal niet waarom meer bedrijven zoals Google te gang gaan, gewoon open zijn over je lekken en hackers uitnodigen en vervolgens een geld bedrag geven voor de hack en de hack fixen, zo lastig is het toch niet ? Oke niet elk bedrijf kan met miljoenen strooien maar you get the point.

0 hiostu
@Dylan93 • 16 januari 2013 17:05

Er zijn genoeg bedrijven die dit doen.

0 Adollar
@Dylan93 • 16 januari 2013 18:14

Je hoeft niet per see met miljoenen te gaan strooien, kan ook prima met duizenden ;p

Luukje01
16 januari 2013 23:02

"Met behulp van de exploit kits kunnen bijvoorbeeld banktrojans worden geïnstalleerd. Zulke trojans kunnen internetters geld afhandig maken."

jongens, jongens... op wat voor soort site zitten we? Dít vind ik niet echt meer Tweaker waardig...

Oorzaak -> gevolg bij dit soort opendeur-problemen snapt een tweaker toch wel?

[Reactie gewijzigd door Luukje01 op 16 januari 2013 23:02]

+1 exorbitex
@Luukje01 • 17 januari 2013 13:50

Ik ben het met je eens, maar dat is niet erg commercieel gedacht.

Tweakers verdient geld met advertenties, meer bezoekers betekent meer geld.
Meer bezoekers haal je niet door steeds hetzelfde pad te bewandelen, grofgezegd weten alle "traditionele" tweakers uit NL/BE de site wel te vinden dus daar zit de groei niet in.
Dus schrijf je voor een breder publiek.

Analogie waarschuwing!
Porsche is ook verschoven van hardcore/puristen 911's bouwen om nieuwe klanten te trekken. Landrover/BMW ook. Auto's zijn m.i. een aardige analogie omdat je daar ook redelijk uitgesproken meningen hebt van "goed" geinformeerden naast een general publiek wat significant minder geinformeerd is.

Of ik het uiteindelijk eens ben met het brede publiek aanspreken, ach ja dat is slechts een mening.

ArmadaOne
16 januari 2013 17:47

"De software wordt bijvoorbeeld verspreid door advertentienetwerken te infecteren of in te breken op webservers"

Sites die het meest vatbaar hier voor zijn / meeste worden misbruikt zijn gamer / cheat sites zoals gamecopyworld / gameburnworld etc. die downloadbare bestanden zoals patches, fixes, trainers e.d. aanbieden.
Bij het klikken op de download knop wordt je naar een pagina gestuurd (vaak in een nieuw browserwindow) met paginagrote reclame en een banner met "download wordt voorbereid" of "deze advertentie overslaan in X seconden".
Het is via dit soort (adf.ly in dit geval) advertentienetwerken dat bovenstaande exploit wordt gebruikt.
Mensen die vaak torrent sites bezoeken zullen bekend zijn met adroulette en 888, ook advertentienetwerken die paginagrote pop-ups op je scherm laten springen (vaak casino en sex/dating site advertenties).
Deze zijn ook vaak geinfecteerd.
Torrent sites als h33t, fenopy, torrenthound, piratebay etc maken vrijwel allemaal gebruik van deze advertentienetwerken.

majoh

16 januari 2013 18:10

Elke software bevat fouten, maar je zou toch denken dat Oracle hier wat meer prioriteit en aandacht aan schenkt aangezien het zo high profile in het nieuws komt elke keer.

Daarnaast vind ik het wel jammer van de verslaggeving dat er elke keer over 'Java' gepraat wordt. Het gaat hier om de browser plugin, en 'Java' is veel breder dan alleen dat...

mcDavid
16 januari 2013 17:28

Weet iemand in hoeverre OpenJDK ook vatbaar is voor ditsoort problemen? Het feit dat Oracle er niet tussen zit geeft me in ieder geval veel meer vertrouwen in OpenJDK.

+2 Dreamvoid

Oracle

@mcDavid • 16 januari 2013 17:50

OpenJDK *is* de codebase voor Oracle's Java RE.

+1 gimbal
@Dreamvoid • 17 januari 2013 17:21

Maar niet de plugins. Die zijn nog steeds closed source.

+2 jj71
@mcDavid • 17 januari 2013 08:32

Zoals boven al uitgelegd door een aantal mensen zit dit beveiligingsprobleem in de browser plug-in waarmee mensen Java applets in hun browser draaien. Niet in Oracle's Java virtual machine (JVM), Java runtime environment (JRE) of Java development kit (JDK).

Geen reden om je vertrouwen in Oracle's JDK of OpenJDK te verliezen.

+1 Phoenix_the_II
16 januari 2013 16:33

Hmm, gat in de markt? Zoek exploits en verkopen? Dat zijn dan een beste snelle 2x 5000$ verdiend...

[Reactie gewijzigd door Phoenix_the_II op 16 januari 2013 16:34]

himlims_
@Phoenix_the_II • 16 januari 2013 16:39

Ook legaal kun je er een leuk zakcentje mee verdienen, kijk Sergey Glazunov maar
http://www.google.com/about/appsecurity/hall-of-fame/reward/
http://www.chromium.org/Home/chromium-security/hall-of-fame

+1 locke960
@himlims_ • 16 januari 2013 19:52

"Ook legaal" ? Volgens mij is er niets illegaals aan het verkopen van informatie over een beveiligingslek. Moreel verwerpelijk wel, maar illegaal niet.

Titan_Fox
@Phoenix_the_II • 16 januari 2013 17:49

Java is nog nooit veilig geweest. Het heeft altijd volgezeten met veiligheidsgaten. Vraag me echt af wat ze bei Sun / Oracle gedaan hebben de afgelopen 10 jaar...

elmuerte
@Titan_Fox • 16 januari 2013 18:57

Noem eens 1 stuk populair en niet triviale software die wel veilig is geweest in de afgelopen 10 jaar?
Zelfs voor DJBs software zijn security bugs gevonden.

+1 tibi
@elmuerte • 16 januari 2013 20:54

klopt ZELFS openbsd niet:
'Slechts twee 'remote holes' in de standaardinstallatie in een verdraaid lange tijd!'

+1 MartijnGP
@Titan_Fox • 16 januari 2013 20:01

Geen enkele software is veilig te verklaren.

Er is wellicht een klein aantal softwarepakketen waar nog geen exploits in zijn gevonden, maar dan nog kun je niet uitsluiten dat ze er zijn.

+1 Athlon-pv
@MartijnGP • 17 januari 2013 00:46

Het is maar net hoe je het wil zien , het is gewoon belangrijk dat het programma bepaalde dingen absoluut niet doet. Tegenwoordig is het gewoon zonde van de tijd en geld (voor het btreffende bedrijf), Dus dan is het aantal regels code het voornaamste probleem, des te groter de code des te meer problemen er mee kunnen zijn.

Vandaar dat je van bloatware weg moet blijven enz...

jip_86
@Phoenix_the_II • 16 januari 2013 16:44

Het is maar net hoe veel werk daar in zit natuurlijk. Het is niet dat die dingen voor het oprapen liggen.

mcDavid
@Phoenix_the_II • 16 januari 2013 17:25

hate to burst your bubble, maar ik ben bang dat deze markt redelijk verzadigd is. Dit soort verkopen zijn echt aan de orde van de dag (zoals ook al in het artikel vermeld staat).

CMG
@Phoenix_the_II • 16 januari 2013 17:27

Uhm; voor een goede java 0-day met remote execution kun je 100-500k vangen; 5k is een koopje.

superrutger
@Phoenix_the_II • 16 januari 2013 16:38

http://bassistance.de/wp-content/problem-factory.jpeg

0 Argantonis
@Phoenix_the_II • 16 januari 2013 23:03

Ja want het vinden van exploits is supermakkelijk natuurlijk, ga gewoon een dagje aan de slag en je bent rijk...

Dograver
16 januari 2013 16:35

Dit is de zoveelste klap voor Java binnen korte tijd.

Gister ook al een melding dat de patch die ze uitbrachten het probleem niet oplost en nu weer een nieuwe melding. Ga Java er dan toch maar eens afgooien.

[Reactie gewijzigd door Dograver op 16 januari 2013 16:35]

CyBeRSPiN

@Dograver • 16 januari 2013 16:42

Mwah, "klap voor java", eerder zoveelste "ongenuanceerde gerucht op Tweakers.net over java".

Het gaat enkel over de java-plugin geintegreerd in de browser, niet over Java in het algemeen.
Opzich ook ernstig, maar er zijn zoveel andere lekken in bijv. IE en FireFox die ook nog actief gebruikt worden.

Niet iedereen update zn browser en software, dat is een nog veel groter probleem waar geen bedrijf wat aan kan doen.

Teijgetje
@CyBeRSPiN • 16 januari 2013 17:03

Idd Tweakers kan ook in het bericht zetten dat het niet om Java gaat die op je computer draait.
Maar dan krijg je natuurlijk veel minder reacties en hits van mensen die niet goed lezen.

Maar zo kun je zo`n artikel over alle software maken die veel gebruikt wordt want dan is het pas interessant om dat te proberen te hacken en er tijd in te steken.
Vrijwel overal zijn gaten in te vinden, de vraag is vaak of ze lucratief genoeg zijn om er veel tijd in te steken.

Deze heb ik namelijk niet voorbij zien komen op Tweakers en is twee dagen geleden gerepareerd.
http://webwereld.nl/nieuw...ie-lek-na-brakke-fix.html
De eerdere, naar nu blijkt brakke fix, stond hier wel;

Met je laatste zin sla je dus de spijker op zijn kop, veel mensen vinden auto-updates eng en zetten ze uit want het werkt toch, dus die hoort eigenlijk vet te staan, bij deze;

Niet iedereen update zijn browser en software, dat is een nog veel groter probleem waar geen bedrijf wat aan kan doen.

[Reactie gewijzigd door Teijgetje op 16 januari 2013 17:26]

0 sfranken
@Teijgetje • 16 januari 2013 17:27

Installeer Chrome, die auto-update!

+1 aileron
16 januari 2013 20:49

Ik wil niet de zoveelste zijn die Apple weer betrekt bij deze discussie over Java.
Maar wat me opvalt is dat Apple de vele mogelijkheden die het heeft gehad om te kiezen tussen verschillende technologieen achteraf eigenlijk altijd spot on is.

Apple heeft Java altijd links laten liggen hoe erg het ook onder de developers in de wereld werd geprezen als een robuuste taal om mee te ontwikkelen. Apple heeft eigenlijk een heleboel dingen laten vallen zoals Flash ondersteunen. Maar ook toen de discussie ontstond over video codecs en Apple vanaf het begin achter H264 heeft gestaan. En elke keer hadden ze gelijk.

Java is goed voor grote back-end systemen, niet front-end applicaties. Kun je nog de tijd herinneren van applets? troep was het

[Reactie gewijzigd door aileron op 16 januari 2013 20:51]

+2 Dreamvoid

Oracle

@aileron • 16 januari 2013 21:34

Da's niet het hele verhaal, opportunisme is ook Apple niet vreemd. toen OSX 10.0 uitkwam vond Apple Java nog belangrijk genoeg om zelf de JRE te ontwikkelen, en Java als 'first class citizen' op OSX te promoten. Logisch want er waren nog nul Obj-C/Cocoa apps dus moesten developers aan boord getrokken worden, met support voor zoveel mogelijk platforms. Bovendien was 2000/2001 het toppunt van de Java hype, de ultieme crossplatform omgeving waardoor het niet meer uit zou maken of je voor Apple, Microsoft of UNIX ontwikkelde: Java zou alles en overal draaien, op elke client ter wereld. Het onderliggende OS zou totaal irrelevant worden! Apple sprong voor de zekerheid toch maar ook op die kar. Het liep natuurlijk anders. Na het doorslaande succes van OS X en Cocoa is Apple inderdaad de grote schoonmaak gaan houden: Carbon eruit, X11 eruit, Java eruit: Als je de App Store in wilt is het Cocoa, or the highway. Is logisch, het maakt het OS een stuk cleaner (minder platforms = minder kans op exploits) plus Apple heeft itt bij Java de volledige controle over de hele Obj-C/Cocoa/CLang stack, maar developers hebben wel steeds minder te kiezen qua platform. In iOS is de restrictie nog verder doorgevoerd (alleen nog maar Cocoa, plus slechts 1 browser engine).

En bovendien, als je Apple de credits geeft, wat dan te denken van Microsoft die hun handen al in 2001 volledig van Java af hebben getrokken?

[Reactie gewijzigd door Dreamvoid op 16 januari 2013 22:30]

1 2 3 Volgende

Op dit item kan niet meer gereageerd worden.

Cookies op Tweakers

Java bevat mogelijk opnieuw beveiligingsgat

Lees meer over

Gerelateerde content

Sorteer op:

Weergave:

Reacties (87)