DE19846673A1 - Verfahren zur Verbindung von Stackmanipulationsangriffen bei Funktionsaufrufen - Google Patents

Abstract

Hardwareunterstütztes Verfahren zur Verhinderung von Stackmanipulationsangriffen bei Funktionsaufrufen, bei dem der Stackzugriff bei einem Aufruf einer unsicheren Funktion durch Hardware auf den Stackbereich dieser Funktion beschränkt wird.

Description

Auf zukünftigen Chipkarten sollen voneinander abhängige Soft­ waremodule verschiedener Hersteller installiert werden. Un­ terschiedliche Module unterschiedlicher Hersteller haben da­ bei unterschiedliche Zugriffsrechte auf Ressourcen der Chip­ karte. Beispielsweise hat nur das Betriebssystem Zugriff auf bestimmte Speicherbereiche im NVRAM, die von anderen Modulen nicht manipuliert werden dürfen.

Eine solche Zugriffsbeschränkung zum Schutz der Arbeitsspei­ cherbereiche einzelner Programme vor veränderndem Zugriff durch andere auf der Chipkarte ablaufende Programme, ist bei­ spielsweise in dem U.S.-Patent 5,754,726 beschrieben. Das dort beschriebene Verfahren stellt zwar sicher, daß von einem auf der Chipkarte aktiven Programm keine Arbeitsspeicherbe­ reiche anderer Programme manipuliert werden können. Eine wei­ tere Angriffsmöglichkeit besteht jedoch darin, nicht den Ar­ beitsspeicher, sondern den Stapelspeicher mit den jeweiligen Rücksprungadressen der Unterprogramme zu verändern. Ein sol­ cher Manipulationsangriff auf den Stapelspeicher (Stack) des Prozessors, kann mit dem Verfahren der U.S.-PS 5,754,762 nicht abgewehrt werden.

Aus Speichereffizienz- und Performancegründen liegen die Stacks von aufgerufener und aufrufender Funktion nämlich phy­ sikalisch im selben Speicherbereich hintereinander. Da kon­ zeptionell nicht ausgeschlossen werden kann, daß eine Biblio­ theksfunktion auf hohem Sicherheitsniveau eine Funktion einer Applikation mit niedrigem Sicherheitsniveau aufruft, besteht ein mögliches Angriffsszenario darin, daß die aufgerufene Funktion der Applikation durch Zugriff auf den Programmstack den Datenbereich der Bibliotheksfunktion auf dem Stack mani­ puliert.

Auf Chipcard Controllern ist eine Lösung im Stand der Technik bisher nicht vorhanden. Die Problemstellung ist neu, da bis­ her ein Hersteller für die gesamte Software zuständig war.

In modernen Prozessoren wird z. B. eine Page Table oder Seg­ ment Decriptor Table (MMU) verwendet, in die das Multitas­ king-Betriebssystem den für die Applikation gültigen Spei­ cherbereich einträgt. Die Prozeßkommunikation und -überwa­ chung wird dabei vom Betriebssystem durchgeführt.

Funktionsaufrufe zwischen Funktionen auf unterschiedlichen Sicherheitsniveaus gehen bei Chipkarten aus Performancegrün­ den nicht über das Betriebssystem, sondern werden direkt aus­ geführt.

Es ist daher Aufgabe der Erfindung, die direkte und indirekte Manipulation des Stack-Speicherbereichs als sicher bewerteter Funktionen durch als unsicher bewertete Funktionen zu verhin­ dern.

Erfindungsgemäß wird diese Aufgabe durch ein Verfahren ge­ löst, bei dem der Stackzugriff bei einem Aufruf einer unsi­ cheren Funktion durch Hardware auf deren Stackbereich be­ schränkt wird.

Es ist dabei besonders bevorzugt, zur Beschränkung des Stack­ zugriffs vor dem Aufruf der unsicheren Funktion die Referenz auf den Stackframe der aufrufenden Funktion zu speichern. Weiter ist es dabei bevorzugt, einen Mechanismus vorzusehen, durch den verhindert wird, daß die aufgerufene Funktion den Wert der Referenz auf den Stackframe verändern kann. Weiter ist es bevorzugt, durch einen Schutzmechanismus sicherzustel­ len, daß der Stackpointer nicht den gültigen Stackbereich der aktuellen Funktion überschreitet.

Besonders bevorzugt ist es, bei dem Rücksprung aus der unsi­ cheren Funktion den ursprünglichen Zustand auf den Stack wie­ derherzustellen.

Das erfindungsgemäß günstigste Verfahren läuft so ab, daß beim Funktionsaufruf zunächst auf dem Stack ein Speicherbe­ reich für zu schützende Funktionsdaten reserviert und optio­ nal die Funktionsargumente dahinter auf den Stack gelegt wer­ den und die im geschützten Bereich liegende Referenz auf den Stackframe der aufrufenden Funktion auf den zuvor reservier­ ten Bereich des Stacks gelegt und die Referenz auf den Stack­ frame der aufgerufenen Funktion in den geschützten Bereich geschrieben wird.

Im folgenden wird die Erfindung anhand des in den beigefügten Zeichnungen dargestellten Ausführungsbeispiels näher erläu­ tert. Es zeigen:

Fig. 1 die Belegung des Stacks und der zugehörigen Register vor und nach dem Funktionsaufruf; und

Fig. 2 schematisch den Ablauf der Aufrufe bei einem abgesi­ cherten Funktionsaufruf.

Bisher lieferte ein einziger Chipkartenhersteller sowohl das Betriebssystem der Chipkarte als auch die Anwendungsprogram­ me. Das Betriebssystem der Chipkarte konnte also als ein Teil des Anwendungsprogramms gesehen werden. Das Chipkartenbe­ triebssystem und die Anwendungsprogramme wurden auf speziell hergestellten Masken für das ROM (Nurlesespeicher) der Chip­ karten-IC's geliefert. Es handelte sich also bisher um Lösun­ gen, bei denen die Programme im wesentlichen hardwaremäßig, also fest verdrahtet, vorgegeben waren.

Die vorliegende Erfindung behandelt demgegenüber eine Situa­ tion, bei der verschiedene Hersteller Bibliotheken und Anwen­ dungsprogramme liefern können, die dann auf einer Karte ko­ existieren müssen. Aus Sicherheitsgründen hat die Programmar­ chitektur der Chipkarte dann zu ermöglichen, das Betriebssy­ stem und die Bibliotheken gegen Manipulationen von deren ei­ genen "privaten" Daten, Programmcode und Stack durch ein lau­ fendes Programm zu schützen. Dies kann bei einem Ausführungs­ beispiel der Erfindung durch verschiedene Maßnahmen erreicht werden:

1. Segmentierte Adressierung

Der physikalische Adreßraum von 2²⁴ Bit wird über maximal 256 Daten- und 255 Programmsegmente zugänglich gemacht. Die Läncre des physikalischen Adreßraums, der von einem Segment adres­ siert werden kann, kann zwischen 4 Byte und 2¹⁶ Byte liegen. Ein Segment wird durch seine Länge und seine physikalische Anfangsadresse definiert. Die Adresse (Pointer) eines Spei­ cherplatzes besteht dann aus 8 Bit, die die Adresse des Seg­ ments darstellen und einem Offset aus 16 Bit. Dies bildet die direkte Adresse.

2. Speicherverwaltungseinheit (Memory Management Unit = MMU)

Eine Speicherverwaltungseinheit (MMU) unterhält eine Liste aller Segmente, die von den laufenden Programmen benötigt werden. Jedes dieser Segmente verfügt über zusätzliche Attri­ bute in der MMU, wie seine Eigenschaft als "Programmsegment" oder "Datensegment", Identifizierung des Programms, zu dem es gehört, und Vertrauensklasse. Verschiedene Programme, die zur gleichen Zeit laufen, werden durch unterschiedliche Programm­ identifizierungen unterschieden. Programmzähler und Daten­ adressen beziehen sich immer auf Segmenteinträge in der MMU mit der gleichen Programmidentifizierung. Weiterhin verweist das Segment des Programmzählers auf einen Eintrag in der MMU mit der gleichen Segmentidentifikation und dem Attribut "Pro­ grammsegment". Andererseits können alle Datenadressen in der MMU-Eintragungsliste über die gleiche Programmidentifizierung und das Attribut "Datensegment" gefunden werden.

3. Vertrauensklassen

Wenn ein Hersteller ein Programm A schreibt, das auf ein an­ deres Programm B eines anderen Herstellers zugreift, dann vertraut der erste Hersteller automatisch dem Code des zwei­ ten Herstellers. Andernfalls würde er nicht auf dieses Pro­ gramm zugegriffen haben. Andererseits wissen die Hersteller des Programms B nicht notwendigerweise irgend etwas über das Programm A. Daher müssen sie ihren Programmcode, den Stackin­ halt und die Daten gegen schädliche Manipulationen durch Pro­ gramm A schützen. Dies muß insbesondere deshalb garantiert werden, weil die Bibliothek B auch von anderen Anwendungspro­ grammen benutzt werden kann, die sich auf eine korrekte Funk­ tion der Bibliothek B verlassen. Erfindungsgemäß wird dieser Schutz durch vier Vertrauensklassen (0 bis 3) die zusätzliche Attribute der Segmenteinträge in der MMU darstellen, unter­ stützt. Ein Programmabschnitt auf einer niedrigeren Vertrau­ ensklasse genießt größeres Vertrauen als ein anderer Pro­ grammabschnitt mit einer höheren Vertrauensklasse. So können Gerätetreiber auf einem Segment mit der Vertrauensklasse 0 liegen, das Kartenbetriebssystem auf Segmenten mit einer Ver­ trauensklasse 1, Bibliotheken auf der Vertrauensklasse 2 und Anwendungen auf der Vertrauensklasse 3. Die Vertrauensklassen spielen eine wichtige Rolle beim Aufstellen von Regeln für Funktionsaufrufe zwischen Segmenten (ferne Aufrufe) und dem Datenzugriff.

4. Funktionseintrittstore

Nur Funktionen, die von dem selben Hersteller einer Biblio­ thek oder Anwendung hergestellt worden sind, werden in ein Segment gepackt. Deshalb braucht ein Segment keine Schutzmaß­ nahmen für Funktionsaufrufe innerhalb des Segments (nahe Auf­ rufe) vorzusehen. Andererseits sind ferne Aufrufe potentiell gefährlich. Einem Anwendungsprogramm darf es nicht erlaubt werden, einen Programmcodeabschnitt des Kartenbetriebssystems an einer beliebigen Eintrittsadresse anzuspringen. Wenn dies nämlich nicht verhindert wird, können unvorhersehbare Vorgän­ ge ablaufen. Die derzeit bevorzugte Lösung besteht darin, Adressen für ferne Aufrufe nicht als Funktionseintrittsadres­ sen, sondern als Funktionstore zu definieren. Ein Segment kann maximal 255 solcher Tore besitzen. Wenn ein Fernaufruf erfolgt, besteht die Toradresse aus einem Wort von zwei Byte Länge: Das höherwertige Byte enthält die Segmentidentifizie­ rung und das niedrigere Byte das Tor der Funktion, das ange­ sprungen werden soll. Der Fernaufruf liest das Wort automa­ tisch mit dem unter 2. definierten Offset des entsprechenden. Segments und interpretiert es als Funktionseintrittsadresse. Trotzdem ist die Rückkehr von einem fernen Funktionsaufruf möglicherweise gefährlich, weil die Rückkehradresse eine di­ rekte Adresse auf dem Stapelspeicher (Stack) darstellt, die von der aufgerufenen Funktion verändert worden sein kann. Deshalb werden üblicherweise nur Fernaufrufe von höheren Ver­ trauensklassen auf niedrigere Vertrauensklassen erlaubt. Um­ gekehrt sind nur Fernrücksprünge von niedrigeren Vertrauens­ klasse auf höhere Vertrauensklassen zulässig. Eine Ausnahme sind die Fernaufrufe von den Vertrauensklassen 0 oder 1, die im folgenden diskutiert werden.

Obwohl es sich bei den Funktionsaufrufen üblicherweise um Funktionsaufrufe innerhalb des Segments oder Funktionsaufrufe auf derselben oder einer niedrigeren Vertrauensklasse handeln wird, wäre es zu restriktiv, Fernaufrufe von höheren auf niedrigere Vertrauensklassen vollständig zu verbieten: Das Kartenbetriebssystem muß in der Lage sein, ein Anwendungspro­ gramm zu starten. Auch das Protokoll zum Laden von Anwen­ dungsprogrammen kann Rückrufe benötigen, bei denen ein Funk­ tionszeiger einer Funktion A auf einer höheren Vertrauens­ klasse an eine Funktion B auf einer niedrigeren Vertrauens­ klasse übergeben wird und Funktion B nachher Funktion A auf­ ruft. Aufrufe von niedrigeren auf höhere Vertrauensklassen werden im folgenden kurz als "Rückrufe" bezeichnet. Ebenso benötigt die virtuelle Javamaschine (JVM) solche Rückrufe, um ein Javakärtchen zu starten. Grundsätzlich erlauben wir jeden fernen Aufruf, verbieten aber ferne Rücksprünge von einer hö­ heren Vertrauensklasse in eine niedrigere Vertrauensklasse. Da auch Fernaufrufe von dem Kartenbetriebssystem auf ein An­ wendungsprogramm oder eine Bibliothek inhärent unsicher sind, muß das Kartenbetriebssystem einen speziellen Mechanismus vorsehen, um sichere Rückrufe auszuführen. Dazu wird eine Kartenbetriebssystemfunktion INT-SAVE-CALL (FUNC, ARG1, ARG2 . . .) definiert, die aufgerufen werden muß, um einen Rückruf durchzuführen. Die Aufgabe von SAVE-CALL, ist es, die Daten auf dem Stapelspeicher (Stack) einschließlich des Rücksprung­ vektors zu der Funktion, die SAVE-CALL aufgerufen hat, aber ausgenommen der Werte von FUNC, ARG1, ARG2 . . . von Lese- und. Schreibzugriffen innerhalb der Funktion FUNC zu schützen.

Grundsätzlich gibt es drei Lösungen für SAVE-CALL:

• 1. SAVE-CALL öffnet ein neues Stacksegment; das Kartenbe­ triebssystem verwaltet den Stackzugriff;
• 2. SAVE-CALL beschränkt den Schreib- und Lesezugriff auf das laufende Stack-Segment.

Dabei gibt es wieder zwei Möglichkeiten, nämlich:

• 1. 2.1. Das Kartenbetriebssystem verwaltet den Stackzugriff.
• 2. 2.2. Die Fernaufruf- und Fernrückkehrinstruktionen verwalten den Stackzugriff.

Fig. 2 zeigt die Ausführung eines sicheren Rücksprungs auf eine Funktion FUNC () in Vertrauensklasse 3 von einem Aufru­ fer in Vertrauensklasse 2. FUNC und seine Parameter werden als Parameter zu einer Betriebssystemfunktion SAVE-CALL über­ geben. SAVE-CALL übergibt FUNC und seine Argumente weiter zu einer Betriebssystemfunktion ACTUAL SAVE CALL in Vertrauens­ klasse 3. Dieser Rücksprung ist nur zulässig, da sich SAVE- CALL in Vertrauensklasse 1 befindet. ACTUAL SAVE CALL besitzt bereits einen geschützten Stack, wenn es FUNC aufruft. Nach­ dem FUNC zu ACTUAL SAVE CALL zurückgekehrt ist, wird RETURN SAVE CALL auf dem Kartenbetriebssystem mit Vertrauensklasse 1 aufgerufen. RETURN SAVE CALL gibt den Stack frei und ersetzt seinen Rücksprungvektor durch den Rücksprungvektor von SAVE CALL, der in einer Datei des Kartenbetriebssystems durch SAVE CALL selbst gespeichert worden ist. Sodann kehrt RETURN SAVE CALL zu der aufrufenden Funktion in der Bibliothek LIB zu­ rück.

Erfindungsgemäß gibt es für die Realisierung der Funktion SAVE CALL zwei verschiedene Möglichkeiten:

1. SAVE CALL eröffnet einen neuen Stack oder ein neues Stack­ segment.

Beim Aufruf von SAVE CALL übernimmt diese Funktion den Stack mit folgenden Inhalten:
Operanden, Argumente, Name der Funktion FUNC, Rücksprunga­ dresse zu dem aufrufenden Programm in LIB.

Das Programm SAVE CALL führt dann folgende Aktionen aus: Es wird ein neues Datensegment DS eröffnet, die Argumente und der Name der Funktion FUNC werden in das neue Datensegment kopiert, die derzeitige Rücksprungadresse für den fernen Rücksprung SP mit 24 Bit Länge wird in eine Datei des Karten­ betriebssystems gespeichert, SP wird zu DS:LÄNGE gesetzt und die Funktion ACTUAL SAVE CALL wird aufgerufen.

Die Funktion ACTUAL SAVE CALL übernimmt daher folgenden Stackinhalt bevor die Funktion FUNC aufgerufen wird:
Argumente, Name der Funktion FUNC, Rücksprungadresse zu dem Programm SAVE CALL.

Das Programm ACTUAL SAVE CALL führt nun folgende Aktionen durch:
Hole den Rücksprungvektor vom Stack, lade die Adresse von FUNC in den Akku, rufe die Funktion FUNC indirekt auf.

Nachdem die Funktion FUNC ausgeführt worden ist, ist der Stack von ACTUAL SAVE CALL leer. Es wird sodann die Funktion RETURN SAVE CALL aufgerufen. Diese lädt das Register für die Fernrücksprungadresse SP mit den ursprünglichen Werten, die in einer Kartenbetriebssystemdatei zwischengespeichert worden sind und löscht den zwischenzeitlich geschaffenen Stack oder das zwischenzeitlich geschaffene Stacksegment. Die Funktion RETURN SAVE CALL übergibt sodann den Stack wieder in der an­ fänglichen Belegung mit den Operanden, Argumenten, dem Namen der Funktion FUNC und dem Rücksprungvektor an das aufrufende Programm in LIB. Diese Rücksprungadresse wird nun in den Ak­ kumulator geladen und damit springt der Programmablauf in das aufrufende Programm zurück. Diese Vorgehensweise hat den Vor­ teil, daß sie bei allen denkbaren Strukturen des Stacks ange­ wendet werden kann. Es müssen jedoch die Argumente von FUNC kopiert werden und es muß eine Kartenbetriebssystemdatei zur Zwichenspeicherung der Rücksprungadresse angelegt werden.

2. Eine weitere erfindungsgemäße Lösung für sichere Rück­ sprungaufrufe führt eine Schreib/Lesebarriere auf dem Stack ein, die den Rücksprungvektor zu dem aufrufenden Programm vor Veränderungen schützt und ebenso den gesamten Stackinhalt des aufrufenden Programms von Schreib- und Lesezugriffen schützt. Das kann durch eine geeignete Verminderung der Länge des Stacksegments oder durch ein zusätzliches Register in der Speicherverwaltung (MMU) erreicht werden. Ein Problem, wel­ ches dabei gelöst werden muß, ist, daß die Argumente einer Funktion vor dem Rücksprungvektor liegen, wenn das konventio­ nelle C-Stack-Layout benutzt wurde. Eine Lösung dazu ergibt sich durch eine Neuordnung des C Stacks in einer solchen Wei­ se, daß Platz für den Rücksprungvektor reserviert werden muß, bevor die Argumente auf den Stack gelegt werden. Dies führt zu einigem zusätzlichen Programmieraufwand für einen Funktio­ saufruf im Vergleich mit dem üblichen Stack Layout.

Im einzelnen erfolgt dieser weitere erfindungsgemäße Verfah­ rensablauf wie folgt:
Der Stack wird an SAVE CALL übergeben. SAVE CALL setzt eine Lese- und Schreibsperre zwischen den Rücksprungvektor und die Parameter von SAVE CALL. Der Stack hat dann folgenden Aufbau:
Operanden, Rückkehrvektor zu dem aufrufenden Programm in LIB, Rücksprung- Lese- und Schreibsperre, Argumente, Name der Funktion FUNC.

Sodann wird das Programm ACTUAL SAVE CALL aufgerufen. Vom Programm ACTUAL SAVE CALL aus gesehen, besteht der Stackin­ halt damit nur noch aus den Argumenten und dem Namen der Funktion FUNC, bevor die Funktion FUNC aufgerufen wird, da die Funktion ACTUAL SAVE CALL nicht über die Lese- und Schreibsperre hinauslesen kann.

Sodann wird zur Ausführung der Funktion FUNC der Rücksprung­ vektor vom Stack geholt, die Adresse der Funktion FUNC in den Akku geladen und die Funktion FUNC indirekt aufgerufen.

Bei Rückkehr aus der Funktion FUNC ist der Stack für die Funktion ACTUAL SAVE CALL leer. Die Funktion ACTUAL SAVE CAhL ruft dann die Funktion RETURN SAVE CALL auf. Die Funktion RETURN SAVE CALL löscht oder entfernt die Lese- und Schreib­ sperre für den Stack, so daß der Stack für die Funktion RETURN SAVE CALL wieder folgenden Inhalt hat:
Operanden, Rücksprungvektor zu dem aufrufenden Programm in LIB, Rücksprungvektor zu ACTUAL SAVE CALL. Von dem Programm RETURN SAVE CALL wird dann der Rücksprungvektor zu dem Pro­ gramm ACTUAL SAVE CALL vom Stack geholt und die Stackrahmen­ zeiger werden zurückgesetzt. Das Programm ACTUAL SAVE CALL übergibt die Kontrolle dann an das aufrufende Programm in LIB.

Hierbei ist zu beachten, daß diese Vorgehensweise nur mit ei­ ner besonderen Struktur des Stacks möglich ist. Diese Vorge­ hensweise hat jedoch den Vorteil, daß die Argumente von FUNC nicht kopiert werden müssen, und keine zusätzlichen Dateien vom Betriebssystem angelegt werden müssen.

Weiter ist erfindungsgemäß noch die Lösung denkbar, daß eine bestimmte Anzahl von Argumenten in Register übergeben werden. Ein sicherer Rücksprungaufruf würde dann lediglich diese An­ zahl von Argumenten als Maximum erlauben. Der Rücksprungvek­ tor eines sicheren Rücksprungaufrufs besteht dann aus dem Rücksprungvektor eines normalen Funktionsaufrufs und zusätz­ lich aus der Länge des alten Stacksegments.

Weiterhin wäre es erfindungsgemäß auch möglich, den Rück­ sprungvektor auf einem separaten Stack zwischenzuspeichern. Dann kann die Lese- und Schreibsperre einfach installiert werden, bevor das erste Funktionsargument auf den normalen Stack abgelegt wird.

Weiterhin ist noch eine erfindungsgemäße Lösung denkbar, bei der die gleiche Stackstruktur wie bei der vorstehenden Lösung 2 angewendet wird. Im Gegensatz zu den ersten beiden Lösungen schützt jedoch nicht das Kartenbetriebssystem, sondern das aufrufende Programm selbst den Stack des aufrufenden Pro­ gramms durch einen besonderen Befehl SEC CALL gegen Lese- und Schreibzugriff. Bei der Ausführung des Rücksprungbefehls muß dann geprüft werden, ob der Rücksprungvektor hinter der Lese- und Schreibbarriere liegt. Wenn dies der Fall ist, kann die alte Lese- und Schreibbarriere, die auf dem Stack hinter der aktuellen Barriere gespeichert worden ist, wieder hergestellt werden und der übliche Rücksprung ausgeführt werden. Andern­ falls wird nur der übliche Rücksprung ausgeführt. Im Hinblick auf die Struktur des Stacks entspricht diese Lösung der vor­ her beschriebenen Lösung mit der besonderen Stackstruktur.

Die Fig. 1 zeigt das einfachste Grundprinzip aller dieser er­ findungsgemäßen Lösungen:
Der Stackzugriff muß bei einem Aufruf einer unsicheren Funk­ tion auf deren Stackbereich durch Hardware beschränkt werden. Man erreicht dies durch Speichern des Stackframepointers der aufrufenden Funktion. Dabei ist ein Schutzmechanismus zu im­ plementieren, so daß die aufgerufene Funktion den Wert des gespeicherten Stackframepointers nicht verändern kann. Außer­ dem ist beim Schreiben auf den Stack sicherzustellen, daß der Stackpointer nicht den gültigen Stackbereich der aktuellen Funktion überschreitet.

Der Schutzmechanismus kann automatisch aktiviert werden oder von der aufrufenden Funktion direkt angestoßen werden.

Beim RETURN aus der unsicheren Funktion wird dabei durch eine Hardwareimplementation der ursprüngliche Zustand auf dem Stack wieder hergestellt.

Entsprechend zeigt die linke Darstellung in Fig. 1 den Zu­ stand vor dem Funktionsaufruf. Der Stackpointer SP zeigt auf die oberste belegte Speicherzelle im Stack. Unterhalb davon ist der Stack belegt, es darf aber auf den Stack zugegriffen werden. Der Stackframepointer SFP ist nicht belegt oder ent­ hält einen Wert für eine Sperre aus einem früheren Aufruf.

Die rechte Darstellung der Fig. 1 zeigt den Zustand nach dem Funktionsaufruf. Der Stackpointer zeigt nun auf eine Spei­ cherzelle weiter oben, die als letzte belegt ist. Nach dieser oder diesen belegten Speicherzellen liegt als letztes die aufgerufene Funktion FN und ihre Argumente (ARG). Der Frame­ pointer zeigt auf ein Feld, in dem der alte Wert des Stack­ framepointers zwischengespeichert ist (im Falle von mehrfa­ chen geschützten Funktionsaufrufen), oder das leer ist. Die Speicherzelle, auf die der Stackframepointer zeigt, ist auto­ matisch für den Zugriff gesperrt, da Zugriffe nur zulässig sind, wenn SP < SFP. Damit ist diese Speicherzelle und alle darunter folgenden auch gegen Manipulationen gesichert.

Beim Funktionsaufruf wird zunächst auf dem Stack ein Spei­ cherbereich für zu schützende Funktionsdaten reserviert (Rücksprungadresse, etc). Anschließend werden die Funktions­ argumente auf den Stack gelegt. Schließlich wird beim Funkti­ onsaufruf der im geschützten Speicherbereich liegende SFP (mit dem Stackframepointer der aufrufenden Funktion der aktu­ ellen Funktion) auf den zuvor reservierten Bereich des Stacks gelegt und der Stackframepointer der aktuellen Funktion in den geschützten Bereich geschrieben (SFP). Dies erfolgt ent­ weder durch Betriebssystemaufruf oder durch einen Hardwareme­ chanismus.

Bei Stackmanipulationen wird der Stackpointer stets mit dem abgespeicherten Wert SFP im geschützten Bereich verglichen, um zu verhindern, daß der Stackbereich der aufrufenden Funk­ tion manipulierbar wird.

Erfindungsgemäß handelt es sich also um eine Hardware unter­ stützte Lösung zur Absicherung des Stacks der aufrufenden Funktion gegen Überschreiben. Der Rücksprung in die sichere Funktion und optional auch der Aufruf der unsicheren Funktion kann dabei ohne Interaktion mit dem Betriebsystem erfolgen. Dies bedeutet einen Geschwindigkeitsvorteil bei unsicheren Funktionsaufrufen.

Die Alternative wäre, den Funktionsaufruf nicht direkt auszu­ führen, sondern den Funktionspointer und die Argumente der Funktion an das Betriebssystem zu übergeben, das den bisheri­ gen Stack absichert und anschließend die Funktion aufrufe. Dies ist jedoch sehr kompliziert und rechenzeitaufwendig.

Durch die vorliegende Erfindung wird also die Implementation eines sicheren Callbacks in C und für die Java Virtual Machi­ ne auf eine Chipkarte deutlich erleichtert. Unter anderem kann der Umweg über das Betriebssystem, der meist ein großes Handicap darstellt, erspart werden.

Claims (6)

1. Verfahren zur Verhinderung von Stackmanipulationsangriffen bei Funktionsaufrufen, dadurch gekennzeich­ net, daß der Stackzugriff bei einem Aufruf einer unsicheren Funktion durch Hardware auf den Stackbereich dieser unsiche­ ren Funktion beschränkt wird.

2. Verfahren nach Anspruch 1, dadurch gekenn­ zeichnet, daß zur Beschränkung des Stackzugriffs vox dem Aufruf der unsicheren Funktion eine Referenz auf den Stackframe der aufrufenden Funktion gespeichert wird.

3. Verfahren nach Anspruch 2, dadurch gekenn­ zeichnet, daß ein Mechanismus vorgesehen ist, durch den verhindert wird, daß die aufgerufene Funktion auf den Wert der Referenz auf den Stackframe und alle davor auf dem Stack liegenden Daten zugreifen kann.

4. Verfahren nach einem der Ansprüche 1, 2 oder 3, da­ durch gekennzeichnet, daß durch einen Schutzmechanismus sichergestellt wird, daß der Stackpointer nicht den gültigen Stackbereich der aufgerufenen Funktion überschreitet.

5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß bei dem Rücksprung aus dex unsicheren Funktion der ursprüngliche Zustand auf dem Stack wieder hergestellt wird.

6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß beim Funktionsaufruf zu­ nächst auf dem Stack ein Speicherbereich für zu schützende Funktionsdaten reserviert und optional dahinter die Funkti­ onsargumente auf den Stack gelegt werden können und die im geschützten Bereich liegende Referenz auf den Stackframe der aufrufenden Funktion auf den zuvor reservierten Bereich des Stacks gelegt und die Referenz auf den Stackframe der aufge­ rufenen Funktion in den geschützten Bereich geschrieben wird.