soviele Lücken wurden noch nie auf einmal geschlossen, oder?

Vor einem Jahr waren es noch mehr:

Kann mal ein Programmierer einfach erklären, wie es zu Sicherheitslücken kommt? Wenn ich in einem Programm schreibe "VariableA = 100" dann ist das noch keine Sicherheitslücke. Es geht mir auch nicht um Schädlingsversäuchte Programme. Es geht um Programme die sauber programmiert sind und trotzdem Sicherheitslücken aufweisen. Was wird da falsch gemacht? oder noch schlimmer, was macht da Apple falsch?

Beispiel:
Ein Programmierer entwirft ein Skript, das aus einer Webseite alle Grafiken auf dem Mac in einem Verzeichnis speichert und in Vorschau öffnet. Ein "Bösewicht" findet heraus, dass das Skript die Dateien einfach nur speichert und als ausführenden Befehl an das System übergibt.
Gleichzeitig stellt er fest, dass wer eine Grafik in eine Webseite einbauen kann, die Grafik.jpg heißt, es aber eine Grafik.app Datei ist.
Bei der Übergabe ins System wird dann die Datei ausgeführt. Ggf. zwar noch nach Rückfrage eines Admins, was der Benutzer vielleicht unbedacht bestätigt.
D.h. mit einer speziell dafür gebauten Webseite könnte ein Bösewicht die Sicherheitslücke ausnützen.

Der Programmierer erkennt das und untersucht die Dateien inhaltlich, bevor er sie ans das System zur Ausführung (Vorschau) übergibt => FIX

Ist jetzt nicht sehr Praxisrelevant, aber vielleicht eher verständlich als eine echt Sicherheitslücke.

"VariableA = 100" wird dir auch kein vernünftiger Entwickler schreiben, denn sowas wird als Konstante definiert und ist damit sicher.

Aber als Entwickler, kann man oft nur grob abschätzen welche Daten von einer Anwendung eingelesen werden und so kann ein Angreifer versuchen, durch manipulierte Daten einen Speicherüberlauf zu erzeugen und damit versuchen eingeschleusten Code zum ausführen zu bringen.

Oder, weil xkcd es mal schön als comic hat: Eine App greift auf eine SQL-Datenbank zu. Nun gibt jemand einen Wert ein, der die Datenbank löscht …

Ok, wäre es dann nicht sinnvoller für Skript/Programmaufrufe und ich nenne es mal Contentaufrufe eine unterschiedliche Aufrufe zu integrieren? Nach dem Schema, Content ist nicht Programm/Skript und Programm/Skript ist nicht Content also Bild, Video, Text, Tabelle usw. Sollte sowas nicht vom Betriebssystem ebenso abgefangen werden? Beispiel: Programme dürfen nur aus dem Programmeordner gestartet werden.

Grob gesagt ist halt das Problem wie oben schon angemerkt das eine Sicherheitslücke nicht gleich bedeutet, dass jemand nicht sauber programmiert hat oder ihm dabei Fehler passiert sind (auch wenn so etwas das ganze natürlich deutlich begünstigt). Es gibt halt wie bei vielen Dingen immer wieder Möglichkeiten und Wege, an die der Programmierer nicht gedacht hat und die man dann vielleicht ausnützen kann.

Ist ja so wie bei anderen Sachen auch, egal ob Sicherheitsschloss oder Fenster und Türen in einem Haus. Egal wie findig und gut sich da jemand beim Bauen Konzepte etc überlegt hat. Ein Bösewicht findet am Ende dann vielleicht doch einen Weg um diese Dinge zu umgehen/auszuhebeln, an die so einfach keiner gedacht hat.

Daher wird's halt immer auch in der Softwareentwicklung immer mal Patches und Updates geben, weil wieder was auftaucht, was auch der beste Entwickler einfach nicht hätte kommen sehen. Kreativität kennt keine Grenzen, besonders bei 'Hackern'.

Mit weißer Voraussicht, Sorgfalt und dem Wissen aus der Vergangenheit kann man schon viel tun um dem entgegen zu wirken, aber 100% Sicherheit wird es trotzdem nie geben.

Bilddatei enthält im Header: „Dieses Bild ist 100 Bytes lang“.

In Wahrheit ist die Bilddatei aber 200MB lang und enthält gar kein Bild, sondern immer nur das Byte, das für „No Operation“ steht (Tu nix).

Das Programm, das die Bilddatei lädt, „glaubt“ die falsche Information mit den 100 Bytes, reserviert sich diese Menge Speicher und lässt das OS die Datei da hin laden.

Das OS lädt die Datei und überschreibt über das Ende des reservierten Bereiches hinaus 200 MB Speicher.

Teile dieses Speichers enthielten ausführbaren Code.

Das Betriebssystem ist fertig mit dem Laden der 200 MB und führt nun weiter den Code der Applikation aus — der wurde aber gerade überschrieben mit 200 MB tu-nix-Befehlen.

Am Ende der 200 MB tu-nix-Befehle befindet sich Schadcode.

Andere Möglichkeit:
Eine normale HTML-Seite lädt ein Bild nach von „http://example.com/bild.jpg“.
Gültig wären bei URLs aber nicht nur http(s), ftp und so weiter, sondern zum Beispiel auch „file:///etc/DateiMitPasswoertern.txt“. Der Browser muss das also abfangen, das dieser Zugriff fehlschlägt, obwohl er technisch eigentlich problemlos funktioniert.

Wenn der Programmierer des Browser abfragt, ob die ersten 5 Zeichen der Adresse „file:“ ist, hat er das abgefangen und kann es blockieren.

Jetzt merkt ein findiger Mensch, dass URL-Zugriffe auch dann noch funktionieren, wenn am Anfang ein paar Leerzeichen stehen. Also greift er auf „ file:///…“ zu. Der Browser prüft die ersten fünf Zeichen, aber die sind nicht „file:“, sondern „ file“, also erlaubt er den Zugriff.

Oder: Ein Programm bekommt einen Dateinamen übergeben und führt einen Shellbefehl darauf aus:
touch $dateiname
Jetzt übergibt jemand als Dateiname einfach „egal.txt; download "someScript.sh"; exec someScript.sh“, so entsteht aus dem eigentlich gewünschten einzelnen Befehl eine Sequenz von dreien.

Es mag jetzt arrogant klingen, so ist es aber nicht gemeint, aber allgemeinen gilt:
Bevor man eine Lösung zu einem Problem "anbietet", sollte man erstmal das Problem vollständig verstehen!
In deinem Fall würde es bedeutet, dass Du dich erstmal intensiv mit Softwareentwicklung, Betriebsystemen und Kompilerbau gefasst.

Frage stellen != Lösungsvorschlag

Ich denke LoCal meint es nicht böse. Es war von mir ja auch nur so in den Raum geworfen. Ich kann mir selbst kein genaues Bild machen, wieviele dieser Einbruchsmöglichkeiten durch die Anwendung oder das Betriebssystem prozentual jeweils abfangen werden können und wie man dies ggf. sicherer bekommt. Ohne den Programmierern auf die Füße treten zu wollen glaube ich, dass das Hauptaugenmerk eben nicht auf Sicherheitslücken sondern eher dem Programm selbst sowie reinem Nutzerverhalten gilt. Der Anwender selbst wird wohl immer das größte Problem sein.

@ratti, Danke für das Beispiel!

Diese IT-Apologetik ist genauso alt wie sie falsch ist. Ja, der Benutzer kann einiges versauen; systematische Attacken wegen Sicherheitsschwächen sind aber das eigentlich Problem. Daran kann ein Benutzer oftmals nicht viel machen.