Neue Chip-Technologie soll Viren stoppen

Antwort auf den Kommentar von [3dfx]: Programmierer machen Fehler, ich denke nicht, dass du es schaffen würdest, keine Fehler reinzuprogrammieren, auf denen Buffer Overruns möglich sind.

AWie ich schon sagte, totaler Quatsch. Was sie mit diesem Feature bezwecken wollen, ist, dass auf dem Stack kein Code mehr ausgeführt werden kann. Ein jeder Assemblerprogrammierer kennt das noch von Zeiten des 386er her als GDT.Page]n].Flags.Page_Not_Executeable. Linux und FreeBSD nutzen dieses Feature schon seit Ewigkeiten, nur Microsoft meint halt, dass es sich ohne dieses Feature leichter programmieren ließe... Was eine lahme Ausrede ist.

Antwort auf den Kommentar von Rika: I'm sorry, aber wenn Linux & Co. das verwenden, warum gibts dann dort auch immer wieder Buffer Overruns?

Antwort auf den Kommentar von PartySchlumpf. "Was sie mit diesem Feature bezwecken wollen, ist, dass auf dem Stack kein Code mehr ausgeführt werden kann" Auf dem Stack wird und wurde noch nie Code ausgeführt :-) Rika Halbwissen ist schädlich und verleitet einen viel Unsinn zu verzapfen. Zu der Neuerung von AMD kann man nur sagen, dass die Sache garantiert auch wieder umgangen werden kann, denn wenn ein Betriebssystem das erst aktivieren muss kann es auch wieder umgangen bzw deaktiviert werden. es wird halt wieder etwas schwieriger.
P.S. Da hier scheinbar selbst unser Oberguru Rika nicht weis was ein Bufferoverflow ist hier ne kurze Erklärung, auf dem Stack eines jeweiligen Programmes befinden sich z.B. Rücksprungadressen, die auf die Adresse des als nächsten einzulesenden Befehls zeigen. Der Prozessor holt sich nach abarbeiten eines Befehls den nächsten Befehl, bei einem Bufferoverflow versucht man nun den Speicherbereich eines Programmes zu überschreiben um die dortige Rücksprungadresse auf eine Adresse zeigen zu lassen, in der der eigene böse Code liegt. Warum ist das so gefährlich, normalerweise wird ja während des Betriebs eines OS geprüft was darf ein Programm etc, hat es nicht die nötigen Rechte, würde es nie ausgeführt werden und somit auch keinen Schaden anrichten können, sozusagen dessen Befehle würden nie abgearbeitet werden, ersetzt man aber die Adresse eines Befehls von einem Programm, das schon das ganze PipaPo durchlaufen hat und kurz vor der Ausführung steht, darf man alles machen, denn dann wird der eigene Code ausgeführt :-) Ziel ist es also, zu verhindern, dass ein Programm die Rückspungadressen von anderen Prozessen überschreibt und diese Strategie verfolgt AMD mit dem Execution Protection Schutz, aber das hat auch zur Folge, das bestimmte Programme Probleme bekommen werden, solche nämlich, die notwendigerweise bestimmte Operationen ausführen z.B. JIT Compiler.

Ich würde eher sagen, bei dir ist es Halbwissen! Stack, Code Segment und die Datensegmente sind nix weiter als Speichergrenzen. Setzst du beispielsweise das Datensegment auf das Stack Segment, dann kannst du auch direkt auf den Stack zugreifen. Ebenso kannst du auch Code auf dem Stack ausführen. UND GENAU DAS SOLLTE MAN EIGENTLICH NICHT MACHEN. Und niemand macht es - außer Microsoft! Jetzt schau dir den Buffer Overflow an: Der Buffer liegt auf dem Stack. Ebenso wie die Rücksprungadresse. Wird der Buffer absichtlich überladen, dann wird die Rücksprungadrese überschrieben, damit sie auf den eigenen mailicious Code verweist. Und wie bringt man diesen Code überhapt im Speicher unter? Ja genau, man steckt ihn in den Buffer = in den Stack. Ein Buffer Overflow erfolgt mit MALCODE+FÜLLBYTES+RÜCKSPRUNGADRESSE. Der Code ist Teil der Daten im Buffer und wird dort auch ausgeführt. Der Execution Schutz kann nicht verhindern, dass die Rücksprungadresse überschrieben wird - sondern nur, dass der Code dann auch ausgeführt wird - und dass kann jeder billige 386er! Gegen das Überschreiben des Buffers hilft nur eins - saubere Prüfung der Buffergrenze. Damit das einfacher von Hand geht, kompiliert Microsoft ja für XP SP2 alles mit neuesten Compilern neu. Bei FreeBSD gehen sie sogar soweit, dass sie nicht nur die Exeuction Prtection nutzen und vorher die Bufferlänge prüfen, sondern zusätzlich nach jedem Rücksprung auch noch schauen, ob die Rücksprungadresse nicht verändert wurde......... Was die Exeuction Protection angeht, die ist eher eine konsequente Wieterentwicklung der bisherigen Technik. Konnte man bisher nur einzelne 4KB-Pages als nicht ausführbar deklarieren, kann man nun automatisiert direkt sagen "Alle Pages, die den Stack umfassen."

Antwort auf den Kommentar von PartySchlumpf. Rika, wenn ich lese das du schreibst, "Ebenso kannst du auch Code auf dem Stack ausführen", dann muss ich gar nicht mehr weiter lesen, das ist absoluter Unsinn, den du da erzählst. Stack ist ein Teil des Speichers wie du ja selbst sagst, aber Code(Befehle) werden nur in der CPU(ums grob zu sagen) ausgeführt sonst nirgend wo. Da müssen wir uns gar nicht mehr weiter unterhalten, wobei der Rest den du jetzt geschrieben hast ganz gut ist, aber für die meisten hier nichts sagend ist, deswegen hab ich meine Version auch etwas lapidarer formuliert, damit sich auch ein Normalsterblicher etwas unter einem Buffer Overflow vorstellen kann. Aber ich rate dir, sag zu keinem deiner Professoren irgendwann mal was von wegen "Code auf dem Stack ausführen", der lacht sich in Grund und Boden.

Aus der Sicht der CPU liegt der Code sehr wohl im Stack, nämlich einem _virtuellen Speicherbereich_, was _nahezu jeder_ Programmierer lapidar als "auf dem Stack ausführen" nennt. Und wie schon gesagt, man kann es machen, sollte es aber nicht. Und dass Code sich in jedem beliebigen Segment, auch im Datensegment ausführen lässt, liegt ganz einfach daran, dass die CPU zwischen Code und Daten nicht unterscheiden kann, wie alle Von-Neumann-Architekturen und alle Turing-Maschinen. Du kannst Code wie Daten behandeln und bearbeiten, und du kannst versuchen Daten als Code zu interpretieren - was selten funktioniert und damit auch der Grund ist, warum ein Buffer Overflow mit Zufallsdaten nur zu einem Absturz führt. Richtig angewendet hat das sowohl in dynamisch generiertem Code als auch bei polymorphen Viren eine sehr große Bedeutung. Daten, die auf dem Stack lagern, können als Code interpretiert werden und im Falle von Buffer Overflows werden sie das auch... Und warum muss ich nur die Feststellung machen, dass du gerade die Unvollständigkeit deiner Erläuterung gerade als Gegenargument gegen das Funktionieren der vollständigen Erklärung betrachtest...

Antwort auf den Kommentar von PartySchlumpf. Rika der kleine Unterschied ist, du bist ein Erstsemestler, der glaubt schon alles zu Wissen, aber sich trotzdem immer wieder große Schnitzer bei seinen Erklärungen liefert, teilweise sagst du ja die Wahrheit, dann aber wieder kommen so Sachen wie: Aus der Sicht der CPU liegt der Code sehr wohl im Stack nämlich einem _virtuellen Speicherbereich_. Das ist doch schon wieder völliger Quatsch, virtueller Speicherbereich ist doch was ganz anderes :-) Und das ein Programmierer auch mal lapidar sagt "Code auf dem Stack ausführen" das höre ich zum ersten mal und ich bin schon lange dabei. P.S. um genau zu sein liegt der Maschinencode eben nicht auf dem Stack, da liegt nur die Rücksprungadresse, aber das eist du ja eh alles :-) Ich hab jetzt auf jedenfall genug Zeit verplämpert. Ich habs dir schon mal gesagt, ich hab die 8 Semester schon hinter mir und dir fehlen einige Vorlesungen um bei sowas mitreden zu können, ich weis ja nicht ob du noch nen speziellen Zweig gewählt hast, bei mir was es Technik, sprich ich hatte Microcontrollerprogrammierung Kernelprogrammierung, OS-Design etc, ich kenne mich bestens damit aus, deshalb hast du hier nicht den geringsten Hauch einer Chance mir irgendeinen Unsinn zu verzapfen, ich erkenne sofort ob da jemand hunderprozentig weis von was er redet oder ob er sich aus verschiedenen Quellen schnelle was zusammenbastelt.

Also langsam wirst du immer unglaubwürdiger. Eine Buffer Overflow Attacke basiert doch gerade darauf, dass der Code auf dem Stack liegt, weil er in dem überlaufenden Buffer mittransportiert wird. Und so arrogant brauchst du dich auch nicht zu verhalten - ich hab komplett Assembler auf 'nem 386er gelernt und selbst auf 'nem PII noch weiter in Assembler gecodet. Und es ist kein Wunder, dass ich im Infostudium in dieser Hinsicht ganz gewiss nix neues und erst recht nix anderes lernen werde. Um es dir nochmal deutlicher zu erklären: Beim Rücksprung wird die Adresse vom Stack gelesen und entsprechend ihres Inhaltes Codesegment und Codepointer CS:IP gesetzt. Beim Buffer Overflow wird sie so geändert, dass sie auf eine Stelle in dem Buffer (bevorzugt natürlich auf seinen Anfang) verweist, und der Rücksprung genau dorthin erfolgt. Dann liegt der Buffer innerhalb des Codesegmentes! Und wenn der Buffer im Stack liegt, dann verweist das Codesegment auf einen Teil des Stacks! Bzw. wenn der Stack direkt hinter dem Datensegment liegt, dann verweist das Codesegment auf einen Teil des Datensegmentes! In allen Fällen hat der Compiler bzw. der Programmierer extrem gepfuscht: Die CPU kann zwar auch Daten als Code interpretieren, und Code wird ja auch durch Daten dargestellt - und genau deshalb sollte man Code von Daten strikt trennen. Zum einen durch getrennte Segmente (in letzterem Falle dass das Datensegment nicht direkt an das Codesegment grenzt), und zum anderen dass Daten im Speicherbereich des Stack- und Datensegmentes liegen als Non Executeable deklariert werden. Genau das wollen AMD und Intel mit dieser Technik bewerkstelligen, aber die grundlegende Technik dafür enthält bereits der 80386 - dessen einziges Manko ist nur, dass er das nicht segmentweise sondern pageweise festlegt und man sich um die Zuordnung Segment Pages selber kümmern muss. Linux und FreeBSD machen das schon seit Jahren, nur Microsoft ist zu faul.

Antwort auf den Kommentar von PartySchlumpf Rika auch für ungläubige wie dir: http://www.cse.wustl.edu/~cdgill/courses/cs342/c++_memory_management.pdf , hier sieht man wo der Code liegt, eben nicht auf dem Stack, ich denke für jeden anderen hier ist das jetzt nachvollziehbar dankt der netten Grafik. Ansonsten überlasse ich es deinen Professoren dich aufzuklären.

Das ist ja alles andere als ein Gegenbeweis. Eher ein Beweis - nämlich dass Code _normalerweise_ auf dem Stack nix zu suchen hat. Es geht ja auch nicht um den vorhanden Code, sondern um den Code, der über den Buffer eingeschleust wird! und der kann Codesegment durch das Überschreiben der Speicheradresse verschieben wie er will. Und jetzt mal als Demo ein Code Sample:
MOV CX, AX: LOOP CX: PUSH EBX: LOOPNZ: NOP: CALL FUNCTION irgendwas.: MOV CX,DX: LOOP CX, MOV SS:SP, DS:DI+CX, LOOPNZ. irgendwas: RET. - ein typischer ungeprüfter Buffer. Zuerst werden alle alle gepushten EBX überschrieben, und anschließend die Rücksprungadresse. Wird die jetzt so gesetzt, dass sie auf den Beginn des Buffer verweist, dann wird beim RET die geänderte Adresse zurückgelesen und in CS:IP gepackt. Die Ausführung setzt genau dort fort - am Beginn des Buffers, das Code-Segment liegt jetzt so, dass der Buffer darin enhalten ist. Herrje, ich habe schon Buffer Overflow's für Linux gecodet, da war ich noch nicht mal am Gymmi!

Warum solle das nicht gehen? Es geht nur darum, dass die Daten im Stack nicht im Stack als Code interpretiert werden - aus Sicht der CPU musst du einfach nur verweigern, dass der Code-Segment innerhalb des Stack-Segmentes gesetzt wird.