Alle Artikel unter dem Schlagwort memory

mx_security_border

Wenn es um Buffer Overflow geht, reden die meisten Leuten von einem Überlauf im Stack Segment. Aber was ist mit dem Heap – dem Speicher, in dem dynamische Variablen zur Laufzeit eines Programms abgelegt werden?

In meinem ersten Video habe ich über Buffer Overflow im Stack Speicher gesprochen. Dabei habe ich gezeigt, wie die Datenstruktur aufgebaut ist und wie Variablen dort verarbeitet werden. Ich erkläre auf einfache Art und Weise, wie es zum einem Überlauf kommt und wie dieser ausgenutzt werden kann.

Über Stack Overflow findet man recht viele Informationen im Netz – allerdings fast nichts zu Heap Overflow. Wodurch wird diese Lücke verursacht und wie kann sie exploited werden?

Buffer Overflow ist die Folge einer Schwachstelle in Computer Software: Indem über Speichergrenzen heraus geschrieben wird, wird dieser Exploit von Angreifern benutzt, um das verwundbare Programm zum Absturz zu bringen. Und sogar Schadcode – der sogenannte Payload – kann hierdurch in das betroffene System eingefügt und ausgeführt werden.

In diesem Video Tutorial erkläre ich zunächst die Struktur des Heap- und des Stack-Segments und wie diese sich unterscheiden. Anschließend exploite ich mein eigenes Demo-Programm und erkläre, was zur Laufzeit des Programms im Speicher passiert.

Erfahren Sie in meinem Video, warum Usereingaben abgesichert werden müssen und wie ein potentieller Hacker diese Schwachstelle ausnutzen kann.

Weiterlesen

Autor: Miriam Wiesner
Miriam Wiesner arbeitet seit Dezember 2013 für Proact Deutschland. Dort war sie zunächst als System Engineer für die internen Systeme verantwortlich. Aktuell ist sie als Consultant mit Fokus auf IT-Security tätig. Neben der Consulting-Tätigkeit führt sie IT-Sicherheit Audits und Penetrationstests durch, um Kundensysteme auf potentielle Schwachstellen zu prüfen. Vor ihrer Zeit bei teamix konnte sie bereits Erfahrungen als Systemadministrator sowie als Softwareentwickler sammeln.

mx_security_borderBuffer Overflow ist die Folge einer Schwachstelle in Computer Software: Indem über Speichergrenzen heraus geschrieben wird, wird dieser Exploit von Angreifern benutzt, um das verwundbare Programm zum Absturz zu bringen. Und sogar Schadcode – der sogenannte Payload – kann hierdurch in das betroffene System eingefügt und ausgeführt werden.

Im Stack Segment werden lokale Funktionsvariablen abgelegt, welche zum Beispiel durch User-Eingaben gefüllt werden. Die Architektur des Stacks erlaubt es Angreifern, wichtige Adressen zu überschreiben. Wird die User-Eingabe nicht vom Programm abgefangen und überprüft, kann das Programm beeinflusst werden, so dass Fremdcode eingefügt werden kann.

In diesem Video Tutorial reverse engineere ich meinen Demo Code mit dem Programm Immunity Debugger und zeige, wie das Programm verarbeitet wird:
Wie werden Variablen im Stack verarbeitet und wie reagiert das Programm zur Laufzeit? Weiterlesen

Autor: Miriam Wiesner
Miriam Wiesner arbeitet seit Dezember 2013 für Proact Deutschland. Dort war sie zunächst als System Engineer für die internen Systeme verantwortlich. Aktuell ist sie als Consultant mit Fokus auf IT-Security tätig. Neben der Consulting-Tätigkeit führt sie IT-Sicherheit Audits und Penetrationstests durch, um Kundensysteme auf potentielle Schwachstellen zu prüfen. Vor ihrer Zeit bei teamix konnte sie bereits Erfahrungen als Systemadministrator sowie als Softwareentwickler sammeln.

Wenn aus RAM plötzlich RAMsch wird…

Kategorien: mynetapp.de
Kommentare: No

Man kennt das: spontan crashende Rechner haben oft defektes oder schlechtes RAM als Ursache. Auf den NetApp Systemen ist das Problem bedingt durch die Verwendung Chipkill-ECC RAM nicht so gravierend, da bei defekten Zellen einfach einzelne Chips ausgeblendet werden und ECC meistens für die Fehlerkorrektur sorgt, so dass das System einfach weiterläuft.

Aber wenn einfach alles weiter funktioniert, wie merkt man dann, dass man schlechtes RAM („RAMsch“) hat? Das System triggert bei dieser Gelegenheit keinen Autosupport, die bequeme Variante entfällt also auch… Trotzdem hilft der Autosupport in diesem Fall weiter. In der ASUP Mail einfach ‚mal nach „ECC MEMORY SCRUBBER STATS“ suchen (alles groß):

===== ECC MEMORY SCRUBBER STATS =====

Main memory
-----------
Scrub range: 100000 --> 480000000
Current scrub is 0% complete
Last full scrub completed at: Thu Oct 8 13:11:22 CEST 2009 Main
memory ECC errors since last reboot: 492

Die letzte Zeile ist entscheidende Hinweis. Um dann mehr Details zu bekommen, geht man in das CLI und setzt folgende Befehle ab:

Filer> priv set advanced
Filer*> memerr
Correctable ECC memory errors:
Errors on DIMM 1: 0
Errors on DIMM 2: 0
Errors on DIMM 3: 0
Errors on DIMM 4: 0
Errors on DIMM 5: 0
Errors on DIMM 6: 0
Errors on DIMM 7: 492
Errors on DIMM 8: 0
Errors on DIMM 9: 0
Errors on DIMM 10: 0
Errors on DIMM 11: 0
Errors on DIMM 12: 0
Errors on DIMM 13: 0
Errors on DIMM 14: 0
Errors on DIMM 15: 0
Errors on DIMM 16: 0
Multiple errors at the same address; replace DIMM 7 soon.

Und so sieht man dann, dass in diesem System DIMM7 ausgetauscht werden sollte.

Frohes Durchforsten der ASUPs… 😉

Autor: mynetapp.de
MyNetApp war unsere deutschsprachige NetApp Community Plattform, welche wir von 2007 bis 2019 betrieben haben. Im Zuge der Konsolidierung von Plattformen haben wir die Artikel in unser Proact Blog integriert.