Willkommen |
|
myGully |
|
Links |
|
Forum |
|
|
|
 |
28.08.12, 11:54
|
#1
|
Auf den Punkt
Registriert seit: Feb 2011
Ort: Deutschland
Beiträge: 1.903
Bedankt: 2.107
|
Schwerwiegende Sicherheitslücke in Java 7
Zitat:
Die derzeit aktuelle Java-Version enthält eine schwerwiegende Sicherheitslücke, durch die man sein System beim Besuch einer speziell präparierten Webseite mit Schadcode infizieren kann. Die Lücke wird bereits aktiv ausgenutzt – bislang nur für gezielte Angriffe. Da aber ein Exploit im Umlauf ist, dürfte es nicht lange dauern, bis Cyber-Ganoven sie auch für breit angelegte Angriffswellen ausnutzen.
Beim Aufruf unserer Demoseite startet Java beliebige Prozesse. Im Ernstfall wäre das System jetzt mit Schadcode infiziert. heise Security konnte das Problem nachvollziehen. Anhand der öffentlich zugänglichen Informationen ließ sich eine Proof-of-Concept-Seite erstellen: Beim Aufruf der Seite hat das Java-Plug-in ohne Rückfrage einen Prozess, in diesem Fall die calc.exe, ausgeführt. Statt des Taschenrechners hätte die Webseite aber auch einen Schädling herunterladen und ausführen können.
Betroffen sind alle 7er Versionen von Java. In unserem Test funktionierte der Exploit unter Windows in Verbindung mit allen verbreiteten Browsern einschließlich Google Chrome. Das widerspricht den Aussagen der Sicherheitsexperten von DeepEnd Research, laut denen sich die Schwachstelle nicht unter Chrome ausnutzen lässt.
Wer Java auf seinem System installiert hat, sollte die Browser-Plug-ins umgehend deaktivieren – zumindest solange, bis Oracle einen Patch herausgibt.
Geringer Aufwand, großer Sicherheitsgewinn: Unter Firefox deaktiviert man Java über Add-ons, Plugins. Generell ist es eine Überlegung Wert, das Browser-Plug-in von Java in den Ruhestand zu schicken. Schließlich ist die Wahrscheinlichkeit gering, noch auf eine Webseite zu stoßen, die Java für legitime Zwecke einsetzt. Für Webseiten, die nach wie vor unvermeidbar Java einsetzen, kann man einen Zweitbrowser bereithalten. Lokale Java-Anwendungen starten auch mit deaktivierten Plug-ins wie gewohnt.
Bei den bisher beobachteten gezielten Angriffen wird die Lücke zur Installation des Trojaner Poision Ivy genutzt. Die Malware wird dabei auf einem Server in Singapur gehostet. Oracle hat sich bislang noch nicht zu dem Problem geäußert. Daher ist noch völlig unklar, wann die Schwachstelle geschlossen wird. Das nächste reguläre Update würde erst am 16. Oktober erscheinen. (rei)
|
[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]
|
|
|
29.08.12, 09:19
|
#2
|
Chuck Norris sein Vater
Registriert seit: Aug 2009
Beiträge: 5.157
Bedankt: 3.130
|
Mal sehen, ob die reakieren, oder wirklich bis zum 16. Okt. warten werden um die Sicherheitslücke zu schliessen.
Mfg
|
|
|
29.08.12, 13:15
|
#3
|
Eskapistin
Registriert seit: Apr 2009
Beiträge: 2.713
Bedankt: 3.573
|
Hier kann man ganz leicht prüfen, ob Java im Browser aktiviert ist:
[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]
|
|
|
29.08.12, 14:21
|
#4
|
Erfahrenes Mitglied
Registriert seit: Oct 2009
Beiträge: 639
Bedankt: 228
|
Also dank HTML5 und Javas*****, sollte es schon möglich sein, auf Java komplett zu verzichten. Die Verwendung wird als genau so elegant empfunden, wie die Verwendung von Flash oder Silverlight. Es kann schon möglich sein dass es Dinge gibt, die mit Java (und/oder andere bereits genannten Dingen) "leichter" zu realisieren sind, aber es sollte nicht zwingend notwendig sein.
Der Sicherheitsgewinn des Zweitbrowser soll darin bestehen, dass man diesen nur auf Seiten verwendet, welche (warum auch immer ...) Java unbedingt voraussetzen UND (wesentlich wichtiger!) auf Seiten denen man vertraut (die "sicher" sind ...). Somit sollte der Zweitbrowser so gut wie nie eingesetzt werden, außer es geht halt einfach wirklich nicht anders ... für alles andere verwendet man den "normalen" Browser (wo Java deaktiviert ist).
So kann man die Chance verringern, dass man mal vergisst Java wieder zu deaktivieren und sich auf einer "unsicheren" Seite per Drive-By zu infizieren.
Das ganze hat also so ca. den selben Sinn wie die Trennung von User und Admin/Root. Eines wo man ohne viel nachdenken seine täglichen Dinge erledigen kann und das andere wo man einfach höllisch aufpassen muss und lieber tausendmal nachdenkt ob man das wirklich tun sollte.
|
|
|
30.08.12, 22:32
|
#5
|
Erfahrenes Mitglied
Registriert seit: Oct 2009
Beiträge: 639
Bedankt: 228
|
xDD Sorry, aber du sprichst von "sauberer Lösung" und "ohne Plugins" und von "Java" ... das kann doch nur ein Witz sein xD Schon mal versucht Java ohne Plugin im Browser zu verwenden? Gibt es noch Browser die Java direkt im Browser drin haben?
Aber jetzt mal wieder etwas ernster (noch mal sorry für den Lacher). Wir Sprechen hier doch von Java Applets (denn diese sind ja des Problem der aktuellen Sicherheitslücke in den Webbrowsern). Java Appletes waren zu der Anfangszeit von Dynamischen Webseiten noch bitter notwendig, da es eben keine andere Lösung gab. Aber Javas***** hat Java immer mehr den Rang abgelaufen. Jetzt mit HTML5 sieht die Lage noch viel schlimmer aus für Java.
Java lebt noch, weil Firmen einfach nie mit der zeit gehen. Es wäre ja auch verschwendetes Geld und Zeit, würde man jetzt plötzlich sagen ... "Hey Leute, jetzt gibt es was "besseres", lasst uns das verwenden" ... Zudem gilt das alte Motto der IT - "Es funktioniert, warum sollten wir also etwas ändern". Aber Java wird langsam aber sicher (zumindest wenn da nichts neues mehr kommt) auch aus dem Business-Bereich verschwinden. Sieh dir z.B. an welche Web-Anwendungen Google (und auch noch viele andere) aus dem Boden stampft (ohne Java).
Wozu soll HTML5 ein E2EE bereitstellen? HTML5 ist eine Auszeichnungssprache und ist beschreiben der Darstellung da. Auch Javas***** muss so was nicht können. Javas***** ist für das DOM-S*****ing zuständig, also für das Dynamische ändern der Darstellung. Wenn du E2EE haben willst, dann frag doch bitte bei Übertragungsprotokollen nach. Da bietet sich z.B. HTTPS (also HTTP + SSL/TLS) an.
Authentifizieren ist wie auch schon oben erklärt wieder nicht Aufgabe von HTML oder Javas*****. Auch da muss sich wieder um das Übertragungsprotokoll darum kümmern. Auch dazu hat HTTP seit 1996 im RFC 1945 eine geeignete Methode entwickelt. Das ganze nennt sich dann [ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ].
|
|
|
30.08.12, 23:16
|
#6
|
Banned
Registriert seit: Aug 2012
Beiträge: 223
Bedankt: 68
|
Wie kommst du auf diese Theorie?
Im Businessbereich ist Java berechtigterweise eine Macht.
HTML5 ist für Webdesigner ja ne schöne Puppenkiste, aber nichts für reine Businessanwendungen.
Das ist so als würdest du einen getunten Opel Corsa mit einem Benz vergleichen, und den Corsa als Gewinner dastehen lassen, weil er cool aussieht.
Javas***** als Grundlagen für komplexe Projekte ist auch ziemlich unsinnig. Schau dir mal die Anforderungen bei sehr grossen Unternehmen an: Java, C#
Und das hat nichts damit zu tun, dass man dort nur Schlipsträger findet, die HTML5 nicht "fancy" finden.
SSL ist eben keine EndToEnd-Verschlüsselung sondern nur für den Tunnel. Das kann bei Banktransaktionen nicht ausreichend sein!
Wo und als was bist du denn im IT-Bereich tätig? Webdesigner?
|
|
|
30.08.12, 23:53
|
#7
|
Erfahrenes Mitglied
Registriert seit: Oct 2009
Beiträge: 639
Bedankt: 228
|
Wenn ihr Tunnel und "mehr Sicherheit" wollte, dann verwendet halt VPN (mit IPSec oder SSL (halt, das mögt ihr ja nicht ...  ) oder ...). Jedoch hat das dann nichts mehr mit Java oder HTML oder was weiß ich für ein Ding auf dem Layer 7 zu tun ... Ihr vergesst wohl, dass wir vom Browser sprechen und nicht von Server, Desktop Anwendungen, ...
Erklärt mir mal was Java zum verschlüsseln verwendet? Glaubt ihr das fällt vom Himmel? Bei Java mit Sicherheit argumentieren, wo gerade solch ein großes Problem bekannt ist, hat schon etwas von Ironie
Zudem ist es ja echt toll, wenn man Java dann mal von zeit zu zeit nicht verwenden kann, weil mal wieder eine gröbere Sicherheitslücke klafft, wo man sich auf das ach so gütige Team von Oracle verlassen kann, dass sie es bald Fixen ... Was bringt denn bitte eine Sandbox die nicht Funktioniert?
Aber lassen wir das, Java ist echt toll, ihr habt gewonnen -.-
|
|
|
31.08.12, 06:36
|
#8
|
Banned
Registriert seit: Aug 2012
Beiträge: 223
Bedankt: 68
|
Slahn... Du argumentierst so kindisch, dass mir die Haare zu Berge stehen.
Kryptographie ist anscheinend ein Gebiet, wo du dich nicht auskennst. Kein Grund patzig zu werden (so zeigt es doch auf welchem geistigen Niveau du dich befindest).
Sicherheitslücken findet man in Betriebssystemen, Browser und und und...sollen Betriebssysteme also dann solange nicht mehr verwendet werden bis ein Patch draussen ist?
Und du differenzierst ja selbst zwischen Browser und Desktopapplikation. Ein Eingeständnis, dass man also nicht alles ohne Plugin im Browser machen kann!
Bevor du das nächste mal riesige Antworten schreibst, solltest du dich also besser informieren. Kann mich da nur meinem Vorredner anschliessen. Es ist schon ein wenig unverständlich viel über ein Thema zu schreiben, in welchem man sich absolut nicht auskennt, slahn. Wenn man dann noch patzig und argumentationslos ist, dann wird man sogar als peinlich und kindisch empfunden...
|
|
|
01.09.12, 11:28
|
#9
|
Erfahrenes Mitglied
Registriert seit: Oct 2009
Beiträge: 639
Bedankt: 228
|
Zitat:
Das von Oracle verteilte Java 7 Update 7, das eine kritische Sicherheitslücke schließen sollte, enthält einen weiteren Fehler, der ebenso gefährlich ist. Anwender sollten deshalb selbst nach dem Einspielen des Updates die Java-Plugins im Browser deaktivieren.
|
[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]
|
|
|
Forumregeln
|
Du kannst keine neue Themen eröffnen
Du kannst keine Antworten verfassen
Du kannst keine Anhänge posten
Du kannst nicht deine Beiträge editieren
HTML-Code ist Aus.
|
|
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:47 Uhr.
().
|