Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Apple aktualisiert Malware-Definition

Erst Ende letzter Woche hatte F-Secure von einer neuen Malware berichtet, die sich gegen Mac-Anwender richtete und das System mit einer Hintertür ausstatte, über die Angreifer die Kontrolle über Computer und Daten erlangen konnten. Zwar war "OSX/Revir.A" in dem von F-Secure untersuchten Datensatz nicht optimal als PDF-Dokument getarnt, doch konnten die Sicherheitsexperten nicht ausschließen, dass dank der Resource Forks von Mac OS X eine bessere Tarnung aktiv war, die mit der Übermittlung des Datensatzes verloren ging. Laut Mac Rumors hat Apple aber reagiert und seine Malware-Definition für Mac OS X Snow Leopard und OS X Lion aktualisiert, mit der Malware schon beim Download erkannt werden kann. Indes berichtet Intego von einem Trojaner "OSX/flashback.A", der sich als Adobes Flash Installer ausgibt, heimlich laufende Sicherheitssysteme von Mac OS X für eine Hintertür (~/Library/Preferences/Preferences.dylib) ausschaltet und damit laufende Programme des Nutzers infiziert. Apple wird hierfür voraussichtlich eine weitere Aktualisierung der Malware-Definition durchführen.

Weiterführende Links:

Kommentare

sierkb27.09.11 16:10
MTN
Laut Mac Rumors hat Apple aber reagiert und seine Malware-Definition für Mac OS X Snow Leopard und OS X Lion aktualisiert, mit der Malware schon beim Download erkannt werden kann.

Bzgl. des ersten Teils dieses aus zwei verschiedenen Schadprogrammen bestehenden Gespanns (der eine Teil, OSX/Revir.A, ist der "Türöffner", der den zweiten Teil, OSX/iMuler-A, nachladen soll; OSX/Revir.A ist also die Vorhut, OSX/iMuler-A die Nachhut, der eigentliche Hauptbestandteil dieses Zweiergespanns) hat Apple reagiert: OSX/Revir.A.
Für OSX/iMuler-A existiert noch keine Signatur in XProtect.plist. Sinnvoll wäre es aber. Weil sich OSX/iMuler-A sicher auch durch einen anderen Türöffner nachladen ließe/lässt als nur und ausschließlich durch den von Apple gesehenen OSX/Revir.A-Trojaner. Es ist also sinnvoll, beide zu erkennen, für beide jeweils eine Signatur vorzuhalten.

Zusammen mit einer Signatur gegen den gestern entdeckten/bekanntgegebenen Flash-Installer-Fake wären/sind dieser Tage also noch 2 XProtect-Signaturen anhängig: jene noch für OSX/iMuler-A und die nun neue bzgl. OSX/flashback.A.
0
eiq
eiq27.09.11 16:15
sierkb
Es ist also sinnvoll, beide zu erkennen.
Ist es nicht so, dass die OS X-eigene Erkennung nur anschlägt, wenn etwas mit Safari heruntergeladen wurde? Da der "Türöffner" sicher nicht Safari nutzt, würde es nichts bringen, diese Signatur mit aufzunehmen.
0
sierkb27.09.11 16:34
eiq:
Ist es nicht so, dass die OS X-eigene Erkennung nur anschlägt, wenn etwas mit Safari heruntergeladen wurde?

XProtect ist Teil des Quarantäne-Funktion von MacOSX. Seit längerem bekannt durch diese Art von Nachfrage: "'Example.app' ist ein Programm, das aus dem Internet geladen wurde. Möchten Sie es wirklich öffnen?" und seit Snow Leopard verbunden mit XProtect, das sich da einklinkt.

XProtect.plist kommt seit Snow Leopard also grundsätzlich dann zum Einsatz, wenn die MacOSX' Quarantäne-Funktion genutzt wird und diese in die Dateiattribute einer heruntergeladenen Datei ihr com.apple.quarantine-Bit setzt bzw. reinschreibt. Und diese Quarantäne-Funktion wird nicht nur von Safari bei Downloads und/oder Abspeichern von Inhalten benutzt, sondern auch von Mail.app, iChat.app, Finder.app und diversen anderen Programmen von Drittherstellern ebenso (z.B. Firefox, Opera, Chrome, Thunderbird, Cyberduck, etc. pp.).

Siehe dazu auch:

Apple Support Dokument HT3662: Informationen zur Dateiquarantäne in Mac OS X 10.5 und 10.6

Apple Support Dokument HT4651: Mac OS X Snow Leopard und Malware-Erkennung
Da der "Türöffner" sicher nicht Safari nutzt, würde es nichts bringen, diese Signatur mit aufzunehmen.

Der von Apple bereits in seine XProtect.plist aufgenommene Trojaner OSX/Revir.A IST der Türöffner. Der Türöffner, der was nachladen soll, in diesem Fall OSX/iMuler-A. Aber es ist eben "nur" ein durch einen anderen Trojaner gut und billig austauschbarer Türöffner. OSX/iMuler-A kann/könnte sich durch jeden anderen Türöffner, der nicht OSX/Revir.A heißt, reinschleusen lassen.

Und abgesehen vom Browser Safari gibt es ja noch andere Programme, die direkte Berührung mit dem Internet haben. Z.B. ein anderer Browser, zum Beispiel auch Mail.app.
0
eiq
eiq27.09.11 16:50
OK, anders gefragt: warum sollte der "Türöffner" das Quarantäne-Bit setzen?
0
sierkb27.09.11 17:10
eiq:
OK, anders gefragt: warum sollte der "Türöffner" das Quarantäne-Bit setzen?

Ich glaube, Du setzt Dich nochmal damit auseinander, was MacOSX' Quarantäne-Funktion überhaupt ist (Links zum Nachlesen habe ich Dir oben grad' gegeben). Das hat mit dem "Türöffner" nicht das Geringste zu tun. Das ist eine fest eingebaute Funktion des Betriebssystems seit Leopard. Und seit Snow Leopard ergänzt um die XProtect-Funktionalität.

Die Quarantäne-Funktion wird vom Betriebssystem bzw. von den Programmen selber ausgeführt bzw. aufgerufen. Automatisch. Völlig ohne Dein Zutun. Das Quarantäne-Bit wird bei aus dem Internet bezogenen Dateien grundsätzlich gesetzt. Hinzugekommen seit Snow Leopard ist der Umstand, dass automatisch und im Zuge dieser Quarantäne-Funktionalität noch zusärzlich die XProtect-Funktion aufgerufen wird, sprich die betreffende Datei gegen die AV-Signaturliste XProtect.plist (sie liegt unter /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist) gegengeprüft und nachgeschaut wird, ob von den in der XProtect.plist angegebenen AV-Signaturen eine auf die von der Quarantäne-Funktion festgehaltenen Datei zurifft oder nicht. Trifft eine Signatur zu, wirft MacOSX per Pop-Up-Meldung eine entsprechende Warnung aus und speichert die betreffende Datei oder speichert sie nicht bzw. bietet Dir bei übereinstimmendem Befund bzgl. einer in XProtect.plist befindlichen Signatur ggf. auch das sofortige löschen (in den Papierkorb legen) an -- je nachdem, wie Du die Meldung quittierst. Trifft keine der Signaturen zu, geht die betreffende Datei als "sauber" durch und wird abgespeichert oder geöffnet.

Ein potentielles oder tatsächliches Schadprogramm setzt hier null und nichts, setzt kein Quarantäne-Bit und hat mit der Quarantäne-Funktion und ihrer Arbeitsweise überhaupt nichts zu tun. Das macht alles MacOSX höchstselbst, das ist seit Leopard bzw. Snow Leopard eine Grundfunktion des Betriebssystems.
0
sierkb27.09.11 17:19
eiq:

Nachtrag:

Das Quarantäne-Dateiattribut (richtigerweise benannt ist es ein erweitertes Dateiattribut und kein irgendwie gesetztes Bit) com.apple.quarantine wird grundsätzlich bei via GUI-Programmen heruntergeladenen Dateien gesetzt. Bei via Shell/Terminal initiierten Berührungen mit dem Internet bzw. initiierten Downloads (z.B. mit /usr/bin/curl) wird die Quarantäne-Funktion leider bisher nicht genutzt, da geht das alles an diesem Mechanismus vorbei, es wird kein Quarantäne-Dateiattribut gesetzt und weil die Quarantäne-Funktion nicht durchlaufen worden ist, wird in der Folge auch keine XProtect.plist auf eine ggf. übereinstimmende Malware-Signatur zum Vergleich herangezogen/befragt.
0
rene204
rene20427.09.11 17:31
sierkb

ich will einfach mal Danke sagen, für die Hintergrundinfos, die Du uns immer so zusammenträgst.
Leider verstehe ich sie in englisch nicht so wirklich, aber oft genug sind ja auch deutsche Texte dabei..

Deshalb Danke.
Gelassenheit und Gesundheit.. ist das wichtigste...
0
Gerhard Uhlhorn27.09.11 17:38
Ja, ich will mich hier auch mal bei sirkb bedanken, auch wenn wir uns sonst gerne in den Haaren haben. Aber dieser Beitrag war interessant.
0
eiq
eiq27.09.11 18:26
sierkb
Bei via Shell/Terminal initiierten Berührungen mit dem Internet bzw. initiierten Downloads (z.B. mit /usr/bin/curl) wird die Quarantäne-Funktion leider bisher nicht genutzt, da geht das alles an diesem Mechanismus vorbei, es wird kein Quarantäne-Dateiattribut gesetzt und weil die Quarantäne-Funktion nicht durchlaufen worden ist, wird in der Folge auch keine XProtect.plist auf eine ggf. übereinstimmende Malware-Signatur zum Vergleich herangezogen/befragt.
Genau das meinte ich, und genau deshalb bringt es mMn keinen nennenswerten Vorteil, OSX/iMuler-A auch in die Liste aufzunehmen. Natürlich spricht nichts dagegen, es doch zu tun, aber wie du selbst schreibst: es bringt aktuell nichts.
0
user_tron27.09.11 18:37
war dann bei mir gestern der Flashupdater ein Fake? Ich hab ihn noch nicht installiert
Ich erwarte von niemanden Zustimmung für meine persönlichen Ansichten ;-)
0
user_tron27.09.11 18:39
und wie kann ich bitte überprüfen, ob ich das Ding auf dem Mac habe? danke.
Ich erwarte von niemanden Zustimmung für meine persönlichen Ansichten ;-)
0
pm27.09.11 19:32
Habe gestern auch ein Flash-Update gemacht. Es kam plötzlich als ich die Facebook-Seite aufgerufen habe, vermutlich weil er ein Flash-Inhalt geladen hat.
0
Thunderbolt27.09.11 19:42
Wer Flash installiert, hat eine Strafe verdient. Nutzt doch einfach Google Chrome, der hat Flash integriert. Flash kann man dann deinstallieren.

Google aktualisiert den in Chrome enthaltenden Flash dann selbst.
0
sierkb27.09.11 20:08
eiq:
Genau das meinte ich

Aber ich NICHT! Du missverstehst mich anscheinend komplett!
und genau deshalb bringt es mMn keinen nennenswerten Vorteil, OSX/iMuler-A auch in die Liste aufzunehmen.

Natürlich gibt es da einen Vorteil! OSX/iMuler-A ist das eigentliche Zeugs, um das es geht!!!! Wer das nun wie auf den Rechner des Benutzers schaufelt und nachlädt, ist im Grunde völlig zweitranging! In diesem Fall ist es der Trojaner namens OSX/Revir.A, der das tun soll. Es könnte aber auch jeder x-beliebige anders benannte Trojaner diese Aufgabe übernehmen oder ein leicht abgewandelter OSX/Revir.A, der dann meinetwegen OSX/Revir.B heißt. Völlig piepegal. OSX/iMuler-A ist die das eigentliche Schadprogramm, das installiert werden soll, die Backdoor, die verankert werden soll. Und die blockt XProtect bisher NICHT ab, weil es sie NICHT KENNT, weil diesbzgl. noch keine betreffende Signatur in XProtect.plist zur Erkennung hinterlegt ist.

XProtect warnt also bisher nur vor OSX/Revir.A, vor einem evtl. OSX/Revir.B oder OSX/Revir.C, die möglicherweise ebenfalls OSX/iMuler-A nachladen wollen/sollen, warnt XProtect nicht. Und vor OSX/iMuler-A selber warnt XProtect erst recht nicht.

Würde XProtect sowohl vor OSX/Revir.A als auch vor OSX/iMuler-A warnen, dann wäre es, weil XProtect eben auch über die eigentliche Fracht, OSX/iMuler-A, um die es eigentlich geht und die nachgezogen werden soll, schon informiert ist, bevor sie überhaupt von wem auch immer angelandet werden kann, vergebene Liebesmüh für den Angreifer, sich hier neue Türöffner auszudenken, solange die nachzuladene Fracht in Gestalt von OSX/iMuler-A bekannt und erfolgreich geblockt werden kann.

Aber XProtect kennt die eigentliche Fracht namens OSX/iMuler-A (noch) nicht. XProtect kennt nur den einen relativ unbedeutenden Türöffner namens OSX/Revir.A.

Wenn dieser nachzuladende Teil namens OSX/iMuler-A der XProtect-Funktion per Signatur ebenfalls bekannt ist, dann wird der eben geblockt, völlig egal, welcher Türöffner xyz das nun nachladen will.
aber wie du selbst schreibst: es bringt aktuell nichts.

Erstens schreibe ich das so nicht.
Zweitens hast Du mich anscheinend komplett missverstanden. Lies bitte nochmal, was ich im zuvorigen Absatz versucht habe, zu erklären.

Die Backdoor OSX/Revir.B ist das Eigentliche, das Wesentliche, um das es geht. Es ist nicht der Türöffner, der das Wesentliche ist. Es ist die Backdoor, die das Wesentliche ist! Und von der Existenz dieser Backdoor hat XProtect bisher null Ahnung, weiß überhaupt nicht, dass sie existiert und da draußen darauf wartet inklusive entsprechend schon vorkonfiguriertem Steuer-Server (dessen Aktivität laut Verlautbarungen derzeit wohl noch ruht), von irgendjemandem, irgendeinem Türöffner, abgerufen und nachgeladen zu werden!

Würde XProtect auch eine Signatur für OSX/Revir.B bereithalten, dann wäre das eigentliche Schadprogramm, die Backdoor OSX/Revir.B dem System bekannt und könnte ggf. Alarm ausgelöst werden -- völlig egal, von welchem Türöffner aus eingeschleppt. Es soll ja auch vorkommen, dass derlei Türöffner nicht so leicht und so schnell erkannt werden können, wie das z.B. bzgl. OSX/Revir.A geschehen ist. Und wenn XProtect mal so eine Erkennung eines Türöffners nicht rechtzeitig gelingen sollte? Was dann? Dann lauert da draußen immer noch die Backdoor OSX/Revir.B, die von XProtect nicht gekannt wird, und sie könnte auf beliebige Weise den Weg in Richtung Anwender finden. Wenn nicht durch Trojaner A, dann eben durch Trojaner B oder was auch immer es da für Möglichkeiten gibt.

Noch sind diese Türöffner alle relativ trivial gebaut und einfach zu erkennen. Noch.

Aber der Phantasie sind da keine Grenzen gesetzt, anderes zusammenzubauen als nun gerade diesen trivialen als Türöffner fungierenden Trojaner namens OSX/Revir.A, das geeignet ist, eine solche Backdoor entweder von vornherein Huckepack im gepäck zu haben oder zu gegebener Zeit auf Befehl nachzuladen. Dieses "auf Befehl" ist wörtlich zu nehmen, das geschieht i.d.R. von zentralen Steuerungs-Servern aus. Solange sind derlei Trojaner und Backdoors oft genug lediglich erstmal "Schläfer", die auf ihren Weckruf zu gegebener Zeit warten und dann auf Kommando tätig werden.
0
sierkb27.09.11 20:16
user_tron
war dann bei mir gestern der Flashupdater ein Fake? Ich hab ihn noch nicht installiert

Lies:

CNET: MacFixIt: Another OS X Trojan imitates Adobe Flash installer
und
CNET: MacFixIt: Apple tackles malware threats with XProtect update

und schau Dir da vor allem die Screenshots an, wie der diesbzgl. Flash-Fake-Installer und wie der Original Flash-Installer von Adobe aussieht.

Wenn Du sowas runterlädtst, dann immer von vertrauenswürdigen Quellen, am Besten nur direkt von Adobes Downloadseiten.
0
eiq
eiq27.09.11 21:04
sierkb
Du verstehst scheinbar nicht, worum es mir geht.
Du schreibst, dass via Shell/Terminal herunter geladene Dateien nicht überprüft werden. Wenn ich also einen Trojaner schreiben würde, wäre genau das meine Vorgehensweise.

Wo genau ist dann der Nutzen, wenn man OSX/iMuler-A in XProtect aufnimmt, wenn es über die "richtigen" Wege (Shell/Terminal) sowieso nicht erkannt wird? Das ist von Anfang an meine Frage.

Eine Kurze, aber auf die Frage bezogene Antwort würde mir schon reichen. Romane, die an der Frage vorbei gehen, sind nicht nötig.
0
user_tron27.09.11 21:26
sierkb

danke
Ich erwarte von niemanden Zustimmung für meine persönlichen Ansichten ;-)
0
sierkb27.09.11 22:01
eiq:
Du verstehst scheinbar nicht, worum es mir geht.

Oder Du nicht.
Du schreibst, dass via Shell/Terminal herunter geladene Dateien nicht überprüft werden. Wenn ich also einen Trojaner schreiben würde, wäre genau das meine Vorgehensweise.

Wie bezieht denn die Masse der Mac-Anwender Dateien via Internet? Via Webbrowser, per email-Programm (Mail.app, Thunderbird, Postbox etc.pp.) und per iChat, Adium, Trillian, Skype etc.pp?

Oder ist die große Berührungsfläche mit dem großen weiten Internet und mit dem großen WWW der Unix-Unterbau, erreichbar nur über das "Guckfenster" namens Terminal.app? Nutzt die Masse der Mac-Benutzer curl, wget, ftp, w3m, lynx, mail oder pine?

Natürlich ist das, was Du da benennst, eine der großen Schwachstellen von Apples Quarantäne- und XProtect-Konzept überhaupt! Weil eben solche Programme und Schnittstellen zum Internet wie die gerade Genannten eben davon leider nicht abgedeckt werden!
Denn es wirkt nicht grundsätzlich komplett alle Ebenen des Betriebssystems abdeckend. Sondern nur die grafische Benutzungsoberfläche (GUI) betreffend mit dem Finder in der Mitte und Programmen, die das Quarantäne-Framework explizit einbinden (z.B. hat man bei dem FTP-Programm Cyberdock per Konfiguration sogar die Möglichkeit, das Schreiben der Quarantäne-Dateieigenschaft beim Download von Dateien explizit abzuschalten).

Diese große Schwäche von Quarantine und somit von XProtect habe ich nicht in Abrede gestellt. Das habe ich sogar schon in früheren Threads mal das eine oder andere Mal angemerkt, dass das im Grunde nur eine Minimal-Lösung ist. Eine Minimal-Lösung, die durch Zusatzprogramme (wie eben z.B. AV-Programme) entweder sinnvoll ergänzt werden kann oder auch komplett ersetzt werden kann, eben weil sie i.d.R. leistungsfähiger sind, einen größeren Wissensumfang bzgl. existierender Schadprogramme haben und unterm Strich mehr können und auch mehr Wahlmöglichkeiten bei Befall anbieten als das XProtect anbietet. XProtect arbeitet trotzdem nach dem gleichen Prinzip wie andere AV-Programme von Drittherstellern auch. Nur eben auf einem deutlich niedrigeren Leistungsniveau, es deckt gewisse Grundbedürfnisse gerade mal so eben ab, zeigt aber auch schnell seine Grenzen.

Komplett voll funktionsfähige AV-Programme wie z.B. Clamav oder andere können diese Versorgungs- und Informationslücken füllen, die XProtect als Minimal-Lösung anbietet. Sogar Apple formuliert das so in seinen einschlägigen Security Guidelines, dass vollwertige AV-Programme auf einem Mac durchaus ihren Sinn haben und deren Einsatz deshalb auch von Apple empfohlen wird.

Clamav und andere AV-Programme kennen derzeit beide derzeit in Rede stehenden Schadprogramme: OSX/Revir.A UND OSX/iMuler-A.
MacOSX' XProtect kennt von diesem Doppelgespann bisher nur den Türöffner OSX/Revir.A.

Clamav könnte hier z.B. diese Informationslücke füllen: was XProtect mangels Signatur-Hashes nicht erkennt, erkennt dann eben Clamav (oder ein anderes AV-Programm).
Wo genau ist dann der Nutzen, wenn man OSX/iMuler-A in XProtect aufnimmt, wenn es über die "richtigen" Wege (Shell/Terminal) sowieso nicht erkannt wird?


Weil eben der normale, durchschnittliche Mac-Nutzer sich mit seinen Programmen auf dem Desktop bewegt (und nicht im Terminal) und GUI-gestützte Programme verwendet, die direkte Berührung mit dem Internet haben? Und im Code von Türöffnern wie OSX/Revir.A einer ist, in der Regel Hinweise auf eine evtl. nachzuladene Backdoor zu finden sind? Und auch dieser diesbzgl. Code charakteristische Züge hat und erkennungstechnisch in eine Signatur gepackt und dann natürlich auch wieder durch diese charakteristischen Eigenschaften erkannt werden kann im Datenstrom -- völlig egal, in welchem Türöffner oder anderem Programm er sich befindet?
Sprich: wenn der Türöffner möglicherweise selber nicht erkannt wird, dann aber diese charakteristische Struktur, die die Backdoor nachladen soll. Vorausgesetzt, die betreffende charakteristische Struktur ist XProtect oder irgendeinem anderen AV-Programm bekannt.
Und woher soll XProtekt dies wissen, wenn dies nicht in der XProtect.plist per Fingerabdruck/Hash (=Signatur) abgelegt ist? XProtect würde es wissen, wenn ein diesbzgl. Hash dort abgelegt wäre. Ist es bisher aber nicht. Sprich: XProtect erkennt bisher nur einen der Träger/Vorboten. Aber er erkennt bislang nicht, was dieser in sich trägt -- nämlich charakteristischen Lade-Code für andere, nachzuladende Malware.
Das ist von Anfang an meine Frage.

Und warum stellst Du sie dann nicht von Anfang an so glasklar, dass man sie nicht missverstehen kann? Evtl. überprüfst Du in dieser Hinsicht auch mal Deine eigene Fragestellung?
0
dannyinabox
dannyinabox27.09.11 22:43
Aber den Leihen-Consumer-Kundschaft noch schön versichern es gäbe keine Malware für OSX. Muhaha..
0
sierkb27.09.11 22:56
Apple hat heute abend die XProtect.plist um einen weiteren Signatur-Hash ergänzt: für den in dieser MTN-Meldung genannten Trojaner OSX.FlashBack.A.

Last Modification: Tue, 27 Sep 2011 20:06:59 GMT.
Version: 25 (Snow Leopard)
Version: 1004 (Lion)
0
Thunderbolt28.09.11 01:11
dannyinabox

Verglichen mit den 10 000 jeden Tag neu entdeckten Schadprogrammen für Windows, sind die paar Dinger für OS X vernachlässigbar.

Das stammt übrigens nicht von mir, sondern vom bekannten OS X Hacker Charlie Miller (Black Hat etc.). Und der hat mehr drauf als du, danny mit deinen armseligen Kommentaren, die dem Niveau eines fünfjährigen entsprechen und überhaupt nie was zur Sache beitragen.
0
sierkb28.09.11 02:11
Thunderbolt:
Das stammt übrigens nicht von mir, sondern vom bekannten OS X Hacker Charlie Miller (Black Hat etc.). Und der hat mehr drauf als du ...

Der hat mehr drauf als wir alle zusammen. Und er hat mehr drauf als MacMark. Von dem stammt dieser Hinweis nämlich, auf den Du Dich hier stützt. Auf einmal ist Charlie Miller bei MacMark der große Held. Er dreht sich's wie er's gerade braucht. In zahlreichen Wortgefechten, an denen MacMark beteiligt gewesen ist, hat er an Charlie Miller kein gutes Haar gelassen, hat ihn versucht zu widerlegen, wo es geht und hat ihn einen Schaumschläger, Wichtigtuer und Selbstdarsteller geziehen hier bei MTN und vor allem auf seinen privaten Webseiten, wenn dieser mal wieder Sicherheitslücken in Safari oder iOS oder MacOSX entdeckt und dort erfolgreich reinkommen konnte, hatte.
Charlie Millers Name findet sich immer wieder in den Credits von Apples Security Release Notes. Der Name/Realname eines MacMark ist dort nicht zu finden.

Und auf einmal, wenn mal Positives bzgl. MacOSX/iOS von Charlie Miller geäußert wird, ist dieser auf einmal auch für MacMark plötzlich der Held und jemand, den er, statt ihn wie gewohnt zu diffamieren, widerlegen und sezieren, dann sogar zitierenswert findet?

Wie denn nun?
Entweder ist Charlie Miller ein As, und die Dinge, die er von sich gibt, sind richtig und haben Hand und Fuß, oder er ist kein As, und er verbreitet dann nur völligen Blödsinn.

Wenn Charlie Miller sich jetzt geäußert hat, dass im Gegenzug täglich 10.000 andere Malware für das Windows-System das Licht der Welt erblickt, dann sagt der damit absolut nichts Neues und wiederholt damit eh nur, was eine Binsenweisheit ist. Jener Charlie Miller hat auch Folgendes sinngemäß gesagt: "Hacking Windows is work, hacking MacOSX is fun". Und er hatte das in der Vergangenheit so einige Male dann auch demonstriert, wie er sich in MacOSX reingehackt hatte. Zum großen Missfallen von MacMark, der darüber dann gante Kollummnen verfasste und Charlie Miller zu widerlegen versuchte.

Schau Dir den weltweiten Marktanteil von Windows an, schau Dir den weltweiten Marktanteil von MacOSX an. Wen wundert da, dass das Betriebssystem mit der höheren Verbreitung völlig folgerichtig auch das am ehesten ausgesuchte Ziel für Schadprogramme ist, weil damit am meisten erreicht werden kann an Schaden und damit verbunden Umsatz und Rendite für die betreffenden Auftraggeber. Und das Gegenargument iOS mit seinem Verbreitungsgrad zieht insofern nicht, weil iOS eine in sich geschlossene Plattform durch das AppStore-Konzept ist. Aus diesem Grund kommt da schlecht Malware drauf. Weil's im AppStore eben keine Malware gibt und auch nix von den Apple-Wächtern an der Eingangspforte durchgelassen wird. Ein solches verbarrikadiertes Konzept ist aus aus diesem Grund sicherer gegen Malware. Und nicht trotz seiner Verbreitung oder weil die Plattform selber so mit Sicherheit glänzt. Die Plattform selber komplett zusichern, das hat Apple erst mit der jüngsten Iteration von iOS geschafft. Sicher auch Dank des Know-Hows des vom OLPC-Projekt herübergeholten Ivan Krstić , . Zuvor war der vorherrschende Schutz unter iOS diesbzgl. vor allem der AppStore mit seinen scharfen Kontrollen.

Sprich: wenn ich mich in meinem Haus einschließe und draußen Wachposten aufbaue, die jeden kontrollieren, der rein und rausgeht, dann ist es sonnenklar, dass ich weniger anfällig bin für irgendwelche Unbill.
Die Frage ist, ob das noch so der Begriff von Freiheit ist, den der Benutzer auf Dauer gerne haben oder sich dem bereitwillig fügen will. "Walled garden", "Goldener Käfig" eben. es gibt gute Seiten, und es gibt schlechte Seiten an so einem "Goldenen Käfig". Die gute ist schon viel genug gelobt worden. Die schlechte: die DDR-Führung hatte auch mal von so einem goldenen Käfig geträumt und wollte für seine Bevölkerung nur das Beste. Deswegen gab's ja auch den sog. "Antifaschistischen Schutzwall" (Mauer). Um angeblich Unbill und schlechte Einflüsse von draußen (dem Westen) auch draußen zu lassen. Wie den Menschen diese staatliche "Fürsorge" bekommen ist, das wissen wir. Zu Freiheit gehört eben auch Risiko. Und Verantwortung.

Siehe dazu passend auch:

Infoworld: Apple iOS: Why it's the most secure OS, period

Abgesehen davon ist es ja nicht so, dass iOS inzwischen nicht auch schon seine (teilweise eklatanten) Sicherheitslücken gehabt hätte, die Apple schleuniges Handeln abverlangt haben.

Und abgesehen davon: Androids Verbreitung wächst und ist jetzt schon gut doppelt so groß wie die von iOS, die von iOS stagniert derzeit:

The Register (27.09.2011): Android outsells Apple 2:1
But BlackBerry is the real loser
danny mit deinen armseligen Kommentaren, die dem Niveau eines fünfjährigen entsprechen und überhaupt nie was zur Sache beitragen.

Als ob Dein jetzt hier abgegebener Kommentar inhaltlich und niveaumäßig das vorzeigbare Sahneschnittchen wäre! Dein eher beleidigender Kommentar gegenüber dannyinabox ist eher das Gegenteil: unterste Schublade, niveaulos und von fehlender Reife. Versuch's mal mit Inhalt und Wissen, statt einfach nur stumpf nachzuplappern und in den beleidigenden und persönlich werdenden Gegenangriff überzugehen, nur weil Dir die Meinung eines anderen nicht passt bzw. sie wie in diesem Fall eine Dir wehtuende, aber vielleicht doch nicht so falsche Meinung oder gar Wahrheit ist.
0
Thunderbolt28.09.11 07:16
sierkb

Aha, der doof und nur auf reiner Schadenfreude aufbauende Kommentar von Danny ist also niveauvoll? Das wäre mir neu.

Aber da du offenbar sein Fürsprecher bist, messe ich dich an deinen eigenden Anforderungen.

Hier nochmals sein Kommentar zur besseren Übersicht:
Aber den Leihen-Consumer-Kundschaft noch schön versichern es gäbe keine Malware für OSX. Muhaha..

Bitte erklär mir, was an seinem Beitrag niveauvoll ist. Ich brenne darauf.

Und erklär auch gleich, was daran inhaltlich bemerkenswert und Inhalt und Wissen ist. Und was daran nicht einfach nachgeplappert ist.

Bitte erklär mir im speziellen was das "Muhaha" aussagen soll? Ist das das "Wissen" was du forderst?

Ich gehe sogar so weit so behaupten, sein Kommentar ist gelogen. Apple sagt auch nicht, dass es keine Malware für OS X gibt, sondern dass der Nutzer sie nicht fürchten muss. Da Apple die Xprotect Liste aktualisiert hat, muss er das auch nicht. Apple empfiehlt auch den Einsatz von AV-Software.

So und nun bist du dran. Wenn du mir die obigen Fragen glaubhaft erläuterst, nehme ich alles zurück und entschuldige mich bei Danny, wenn nicht, dann bleibe ich bei meiner Aussage.

PS Deine Kommentare sind zu lang. Versuch doch mal, dich kürzer zu fassen.
0
sierkb28.09.11 08:54
Thunderbolt:

Und wenn der Kommentar von dannyinabox eher weniger Schadenfreude war, sondern im Grunde bittere und bissige Enttäuschung aus dem Gefühl heraus, über diese sich inzwischen entwickelnden Sachverhalte jahrelang getäuscht worden zu sein?

Soll ich Dir einen ins gleiche Horn stoßenden Kommentar eines enttäuschten Nutzers raussuchen (ich muss jetzt erstmal weg zu einem Termin), der sich angesichts dieser ganzen Problematik hier bei MTN mal vor wenigen Monaten zu Wort gemeldet hatte als Antwort auf eine recht unwirsche und persönlich wirklich beleidigende Aussage seitens eines anderen Nutzers hier? Der sich ein wenig verscheißert fühlte, weil man ihm beim Kauf des Macs eigentlich mal was ganz anderes erzählt habe, und nun fühle er sich irgendwie wie ein dummer Schuljunge, dem man gewisse Informationen vorenthalten habe bzw. ihm sinngemäß immer schön mit auf den Weg gegeben habe: Nein, nein, nein, das Thema, das beträfe Macs grundsätzlich nicht und würde sie auch nie betreffen, das Thema sei ausschließlich nur ein Thema, mit dem sich ausschließlich Windows-Nutzer auseinandersetzen müssten, bei einem Mac gäbe es nie und nimmer und nicht und keinesfalls diesbzgl. irgendwas dieser Art...

0
Gerhard Uhlhorn28.09.11 10:25
eiq: Benutzer, die in der Lage sind über das Terminal Dateien herunterzuladen, die wissen i.d.R. auch was sie tun. Es geht ja schließlich um Trojaner, nicht um Viren oder Würmer.

Nichts desto trotz sollte Apple trotzdem den Schutz auch auf’s Terminal ausweiten. Aber das hat nicht unbedingt die höchste Prioriät.
0
Thunderbolt28.09.11 10:40
Muhaha ist also keine Schadenfreude? Ist Danny wirklich so naiv, dass er sich in dieser Sache von Apple getäuscht fühlt könnte? Wer hat ihn denn so getäuscht?

Oh mein Gott, wurde der arme Junge so traumatisiert. Das ist ja schrecklich, wie dem armen Jungen übel mitgespielt wurde. Diese fiesen Verkäufer. Gibt es da nicht ein Beratungsstelle, die ihm wieder auf die Beine hilft. Sonst wird er am Schluss noch depressiv und springt von der Brücke. Oh nein.



Und wo behauptet denn Apple so was überhaupt? Kannst du das mal belegen? Wer wurde wie getäuscht? Welche Aussage von Apple stimmt nicht?

Fakt ist nunmal, dass es für OS X fast keine Schadsoftware gibt. Apple verbessert ausserdem laufend die Sicherheit, zum Beispiel mit der neuen Lion-Architektur, Xprotect, der Anheuerung von verschiedenen SIcherheitsspezialisten etc.


0
sierkb29.09.11 07:07
Aktueller Stand XProtect.plist:

Last Modification: Thu, 29 Sep 2011 04:16:18 GMT
Version: 28 (Snow Leopard)
Version 1007 (Lion)

Allein für OSX.FlashBack.A zum jetzigen Zeitpunkt 8 verschiedene Signatur-Hashes, davon 7 neu hinzugekommen in den zurückliegenden 48 Stunden und auf einen Schlag ganze 6 in den zurückliegenden 4 Stunden.

Anscheinend kann man gar nicht so schnell gucken und Signatur-Hashes erstellen, wie davon immer wieder neue Abwandlungen auftauchen. Apples Security-Abteilung dürfte derzeit davon gut auf Trab gehalten werden, um immer wieder neue Signaturen in die XProtect.plist einzupflegen und die für die User auf deren Servern bereitzustellen.

Wenn das Tempo weiter anhält, dann dürfte das bislang voreingestellte Aktualisierungsintervall von 24h für den XProtectUpdater von MacOSX wohl ein wenig zu großzügig bemessen sein, und Apple sollte überlegen, ob sie MacOSX' diesbzgl. launchd-Dienst (/System/Library/LaunchDaemons/com.apple.xprotectupdater.plist) nicht häufiger auf Apples Servern nach Aktualisierungen für XProtect.plist nachschauen lassen als nur alle 24 Stunden (stattdessen zum Beispiel alle 12, 8, 6 oder gar alle 4 oder 3 Stunden).
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.