Eine der ersten beiden Schutzmaßnahmen gegen Angriffe auf
Pufferüberlauf-Schwachstellen
ist die
Data Execution Prevention
(DEP). Aber die lässt sich umgehen, reicht also als alleiniger Schutz
nicht aus.
Angriff trotz DEP
“Schutzmaßnahmen: ASLR gegen Pufferüberlauf-Schwachstellen” vollständig lesen
Es gibt einen Test von Mac-Virenscannern. Auch wenn es immer noch keine
Viren für Mac OS X gibt. Dass musste ich einfach kommentieren.
Außerdem gibt es noch ein paar interessante Links, die diesmal aber
ohne Kommentar.
Schadsoftware für den Mac
“Ein Kommentar zu Mac-Virenscannern, und ein paar Links” vollständig lesen
Was ein Pufferüberlauf (Buffer Overflow) ist und wie er ausgenutzt
wird, wurde bereits
beschrieben.
Nun geht es um die Frage, wie man diese Angriffe verhindern oder zumindest
erschweren kann.
Der Pufferüberlauf ist Entwickler-Sache
“Schutzmaßnahmen: Canary und DEP gegen Pufferüberlauf-Schwachstellen” vollständig lesen
Heute gibt mal wieder “nur” ein paar mehr oder weniger kommentierte Links statt
eines “Standpunkts” zu einem Thema. Los geht es mit einem Text von Paul
Ducklin von Sophos:
“Anatomy of a brute force attack – how important is password complexity?”.
Das Ergebnis könnte man mit “Brute force ist relativ”
umschreiben. Oder: Für die einen ist es unerreichbare Brute force, für
andere nur ein Mausklick. Oder so.
“Ein paar kommentierte Links zum Wochenanfang” vollständig lesen
Ab dieser Folge geht es um Schutzmaßnahmen, die Angriffe über
Pufferüberlauf-Schwachstellen wenn schon nicht verhindern, dann doch
zumindest erschweren sollen. Aber zuvor muss geklärt werden, was ein
Pufferüberlauf (Buffer Overflow) überhaupt ist. Es handelt sich
dabei um eine vor allem in C-Programmen schnell entstehende Schwachstelle,
die für IT-Verhältnisse uralt ist. Die erste ausführliche
Beschreibung wurde von Aleph One nach einer Reihe entsprechender Angriffe
1996 veröffentlicht:
Smashing The Stack For Fun And Profit.
Der Pufferüberlauf im Schnelldurchlauf
“Schutzmaßnahmen: Der Pufferüberlauf im Überblick” vollständig lesen
Im
windows.developer Magazin 9.2013
ist ein Artikel über die Sicherheit von Natural User Interfaces
erschienen. Vorgestellt werden theoretische und praktische Angriffe,
außerdem werden zwei Gerüchte auf ihren Wahrheitsgehalt untersucht.
Es gibt erste Ansätze, Angriffe auf bzw. über NUIs zu entwickeln.
Zumindest bisher erfordern die aber keine besonderen Gegenmaßnahmen,
wenn man vom üblichen Clickjacking-Schutz gegen TapJacking-Angriffe
absieht.
Und hier noch die Links und Literaturverweise aus dem Artikel:
“Drucksache: windows.developer Magazin 9.2013 – Naturally Secure UIs” vollständig lesen
Der sichere E-Mail-Anbieter
Lavabit,
der unter anderem von Edward Snowden genutzt wurde, hat seinen Betrieb
eingestellt: Der Betreiber, Ladar Levison, hatte anscheinend die Wahl, den
Betrieb einzustellen oder Abhöranweisungen der US-Behörden zu
befolgen und darüber zu schweigen und hat sich für die
Einstellung entschieden. Sein
Fazit:
“Anstand oder Shareholder Value?” vollständig lesen
Nach der
allgemeinen Einführung
in die Content Security Policy, dem Überblick über die
Anweisungen
und
Schlüsselwörter sowie Inline-Code und -Styles
geht es in dieser Folge zuerst um die Möglichkeit, mittels
eval() und ähnlichen Funktionen harmlosen Text in im
Falle eines Angriffs meist bösen Code umzuwandeln.
eval() ist bekanntlich evil!
“Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 4” vollständig lesen
Heute gibt es mal wieder eine bunte Mischung an Lesetipps. Und weil mich
GMX und Co. gerade mit Info-Mails nerven, das “meine” De-Mail-Adresse
demnächst anderweitig vergeben wird: Nur zu, ich will die nicht.
Erst mal
grundsätzlich nicht,
und seit dem Bekanntwerden von PRISM und Co. erst recht nicht. Da haben
wohl ein paar Leute den sprichwörtlichen Schuss nicht gehört.
Was soll ich mit einer “sicheren” E-Mail, die auf den Servern der Betreiber
entschlüsselt wird? Wieso eigentlich? Damit die Schnüffler die
Daten leichter abgreifen können? Und die Bundesregierung fördert
das auch noch, indem sie das unsichere System für Behörden
einfach als sicher definiert. Eine “sichere” E-Mail-Lösung, bei der
auf den Servern der Betreiber Mails ausgespäht, manipuliert oder gar
eingeschleust werden können? Ein Schelm, der böses dabei denkt?
Sorry, aber De-Mail kommt mir nicht ins Haus.
Aber kommen wir zu den Lesetipps.
“Lesetipps und ein Kommentar zur De-Mail” vollständig lesen
Nach der
allgemeinen Einführung
in die Content Security Policy und dem
Überblick über die Anweisungen
geht es in dieser Folge zuerst um die Schlüsselwörter, die von der CSP
erkannt werden.
Die Quelle (des Guten, in diesem Fall)
“Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 3” vollständig lesen