Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 87, views: 20.800 •
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.

JavaBeveiligingsjournalist 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)

Reactiefilter:-187085+165+219+31
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]

"Ook legaal" ? Volgens mij is er niets illegaals aan het verkopen van informatie over een beveiligingslek. Moreel verwerpelijk wel, maar illegaal niet.
Het is maar net hoe veel werk daar in zit natuurlijk. Het is niet dat die dingen voor het oprapen liggen.
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).
Uhm; voor een goede java 0-day met remote execution kun je 100-500k vangen; 5k is een koopje.
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...
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.
klopt ZELFS openbsd niet:
'Slechts twee 'remote holes' in de standaardinstallatie in een verdraaid lange tijd!'
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.
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...
Ja want het vinden van exploits is supermakkelijk natuurlijk, ga gewoon een dagje aan de slag en je bent rijk...
Hier is meer te lezen over de verkoop prijs:
http://krebsonsecurity.co...t-fetches-5000-per-buyer/

Wel erg dat Oracle steeds zo slecht in het nieuws komt mbt Java.
Dacht dat ze wel dingen testen voor ze het uitrollen.

Heb net maar java van me pc gegooit. Jammer dat HP voor hun procurve's een java omgeving gebruikt. Maar goed, dan maar ouderwets via de console alles instellen.

Die 500 was een typo :+

[Reactie gewijzigd door Brantje op 16 januari 2013 16:39]

$5000 ja, idd net als in bericht van tweakers staat.
New Java 0day, selling to 2 people, 5k$ per person
Ben ik nou gek of lees ik dat er gewoon 5000 dollar per koper verkocht is? En geen 500 zoals je zegt?
Sun? Oracle bedoel je denk ik. ;)
Helaas niet alleen HP, maar ook Cisco voor web-based management. Hopelijk komt hier verandering in.
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.
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.
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]

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.
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
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]

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. 8)7

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]

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.
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.
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]

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.
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.
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.
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]

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]

Oracle is anders wel behoorlijk aan het investeren in JavaFX en ziet wel kansen in applets. http://www.oracle.com/tec...pdf?ssSourceSiteId=ocomen
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]

En -daar- ben ik het nu eens 100% mee eens. Weg met de browser plugins, weg met webstart.
@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! }>
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.
"nooit iets niet werkt" bedoel je.
Als nooit iets werkt dan heb je het dus nodig. ;)
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.
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...
Dit is nog net iets minder fijn dat afgelopen berichten :S Omdat dit op zwarte markt wordt verkocht duurt het waarschijnlijk nog wel even voordat die lek gevonden wordt.
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]

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.
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]

Installeer Chrome, die auto-update! :D
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...
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.
Er zijn genoeg bedrijven die dit doen.
Je hoeft niet per see met miljoenen te gaan strooien, kan ook prima met duizenden ;p
Dat software een beveiligingslek bevat is nog tot daaraan toe maar het probleem bij Java is dat het te vaak lekken bevat, deze vaak kritiek zijn en vervolgens slecht of langzaam worden gedicht.
Wat een gatenkaas zeg. Vraag me af hoelang het duurt voor ze weer wat gevonden hebben.
Ik ben bang dat alle exploits nooit opgelost zullen en kunnen worden, niet in Java of alle programmatuur die ooit op de markt is gekomen en nog zal komen. Natuurlijk zal in de toekomst 99,999999% opgelost kunnen worden, maar daar gaat het nooit om (in het hele leven niet en alle andere dingen op deze wereld), het gaat in alles en met alles om die 0,000001% die overblijft, dat is zo met software maar ook met b.v. raketten, auto's en noem maar op. ;)

Men moet zich ook niet druk maken om die 99%, maar om die ene overgebleven %

[Reactie gewijzigd door Athalon1951 op 16 januari 2013 17:08]

Java hoort niet in een browser, op een paar uitzonderingen na (interactieve full hd streaming bijvoorbeeld).
Java hoort op een server of als standalone applicatie zonder toegang vanuit internet.
Dat java in browsers wordt ondersteund is nog een relikwie uit het applet tijdperk. En wie gebruikt er nou nog applets? :?
Java hoort niet in een browser, op een paar uitzonderingen na (interactieve full hd streaming bijvoorbeeld).
Indedaad tegenwoordig heb je html5 en canvas waar je heel veel mee kunt. En voor full hd streaming heb je ook geen Java nodig.
zonder te weten wat het is is het natuurlijk weer makkelijk schreeuwen hier.

ook die andere post van "het gat is nog niet echt dicht" dan lees ik dat nee het is nog niet dicht als het om code gaat wat gesignd is.. Ehhhh die code kan sowieso alle rechten hebben op het moment dat het certificaat geldig is! Dat is nu net het hele idee, dat je dus code kunt runnen als ze je maar 100% weet van wie het is..

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013