[go: up one dir, main page]

EP1119811A1 - Verfahren zur verbindung von stackmanipulationsangriffen bei funktionsaufrufen - Google Patents

Verfahren zur verbindung von stackmanipulationsangriffen bei funktionsaufrufen

Info

Publication number
EP1119811A1
EP1119811A1 EP99959185A EP99959185A EP1119811A1 EP 1119811 A1 EP1119811 A1 EP 1119811A1 EP 99959185 A EP99959185 A EP 99959185A EP 99959185 A EP99959185 A EP 99959185A EP 1119811 A1 EP1119811 A1 EP 1119811A1
Authority
EP
European Patent Office
Prior art keywords
function
stack
call
return
program
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP99959185A
Other languages
English (en)
French (fr)
Inventor
Christian May
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Infineon Technologies AG
Original Assignee
Infineon Technologies AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infineon Technologies AG filed Critical Infineon Technologies AG
Publication of EP1119811A1 publication Critical patent/EP1119811A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
    • G06F12/1441—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block for a range
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4482—Procedural
    • G06F9/4484—Executing subprograms

Definitions

  • Interdependent software modules from different manufacturers are to be installed on future chip cards. Different modules from different manufacturers have different access rights to resources of the chip card. For example, only the operating system has access to certain memory areas in NVRAM that other modules must not manipulate.
  • the stacks of the called and calling function are physically one after the other in the same memory area. Since it cannot be ruled out conceptually that a library function with a high security level calls a function of an application with a low security level, a possible attack scenario is that the called function of the application manipulates the data area of the library function on the stack by accessing the program stack.
  • a solution in the prior art has not yet been available on chipcard controllers. The problem is new since one manufacturer was previously responsible for the entire software.
  • processors e.g. uses a page table or segment decriptor table (MMU) in which the multitasking operating system enters the memory area valid for the application. Process communication and monitoring is carried out by the operating system.
  • MMU segment decriptor table
  • this object is achieved by a method in which the stack access is restricted to the stack area when an unsafe function is called by hardware.
  • the cheapest method according to the invention proceeds in such a way that when a function is called, a memory area for function data to be protected is initially reserved on the stack and optionally the function arguments are placed behind it on the stack and the reference to the stack frame of the calling function in the protected area is in the previously reserved area of the stack and the reference to the stack frame of the called function is written in the protected area.
  • Fig. 2 shows schematically the sequence of calls in a secured function call.
  • the present invention deals with a situation in which different manufacturers can supply libraries and application programs which can then be stored on a card. must exist.
  • the program architecture of the chip card must then enable the operating system and the libraries to be protected against manipulation of their own “private" data, program code and stack by a running program. In one embodiment of the invention, this can be achieved by various measures:
  • the physical address space of 2 24 bits is made accessible via a maximum of 256 data and 255 program segments.
  • the length of the physical address space that can be addressed by a segment can be between 4 bytes and 2 16 bytes.
  • a segment is defined by its length and its physical start address.
  • the address (pointer) of a memory location then consists of 8 bits that represent the address of the segment and an offset of 16 bits. This is the direct address.
  • MMU Memory Management Unit
  • a memory management unit maintains a list of all segments that are required by the running programs. Each of these segments has additional attributes in the MMU, such as its property as a "program segment” or "data segment”, identification of the program to which it belongs, and trust class. Different programs that run at the same time are distinguished by different program identifications. Program counters and data addresses always refer to segment entries in the MMU with the same program identification. Furthermore, the segment of the program counter refers to an entry in the MMU with the same segment identification and the attribute "program segment”. On the other hand, all data addresses in the MMU entry list can be found using the same program identification and the attribute "data segment”. 3. Confidence classes:
  • the function calls will usually be function calls within the segment or function calls on the same or a lower trust class, it would be too restrictive to completely ban remote calls from higher to lower trust classes: the card operating system must be able to run an application program to start.
  • the protocol for loading application programs may also require callbacks, in which a function pointer of a function A on a higher trust class is transferred to a function B on a lower trust class and function B subsequently calls function A. Calls from lower to higher trust classes are referred to as "callbacks" in the following.
  • the Java virtual machine Java virtual machine (JVM) needs such callbacks to to start a java card. Basically, we allow any remote call, but prohibit remote jumps back from a higher trust class to a lower trust class.
  • a card operating system function INT-SAVE-CALL (FUNC, ARG1, ARG2 7) is defined, which must be called in order to carry out a callback.
  • the task of SAVE-CALL is to transfer the data on the stack including the return vector to the function that SAVE-CALL called, but excluding the values of FUNC, ARG1, ARG2 ... from read and write access protect within the FUNC function.
  • SAVE-CALL opens a new stack segment; the card operating system manages stack access;
  • SAVE-CALL limits write and read access to the current stack segment.
  • the card operating system manages stack access.
  • the remote call and remote return instructions manage stack access.
  • SAVE CALL opens a new stack or a new stack segment.
  • the SAVE CALL program then performs the following actions: A new data segment DS is opened, the arguments and the name of the FUNC function are copied into the new data segment, the current return address for the remote return SP with a length of 24 bits is saved in a file of the Card operating system saved, SP is set to DS: LENGTH and the ACTUAL SAVE CALL function is called.
  • the ACTUAL SAVE CALL function therefore takes over the following stack content before the FUNC function is called:
  • the stack of ACTUAL SAVE CALL is empty.
  • the RETURN SAVE CALL function is then called. This loads the register for the remote return address SP with the original values that have been temporarily stored in a card operating system file and deletes the stack or stack segment that has been created in the meantime.
  • the RETURN SAVE CALL function then passes the stack back to the calling program in LIB in the initial assignment with the operands, arguments, the name of the FUNC function and the return vector. This return address is now loaded into the accumulator and the program sequence jumps back into the calling program.
  • This procedure has the advantage that it can be applied to all conceivable structures of the stack. However, the arguments from FUNC must be copied and a card operating system file must be created to temporarily store the return address.
  • Another solution according to the invention for secure return calls introduces a read / write barrier on the stack, which protects the return vector to the calling program from changes and also protects the entire stack content of the calling program from write and read accesses. This can be achieved by a suitable reduction in the length of the stack segment or by an additional register in the memory management (MMU).
  • MMU memory management
  • One problem that needs to be solved is that the arguments of a function come before the return vector if the conventional C-stack layout was used.
  • One solution to this is to rearrange the C stack in such a way that space must be reserved for the return vector, before the arguments are put on the stack. This leads to some additional programming effort for a function call compared to the usual stack layout.
  • SAVE CALL sets a read and write lock between the return vector and the parameters of SAVE CALL.
  • the stack then has the following structure:
  • the ACTUAL SAVE CALL program is then called. Seen from the ACTUAL SAVE CALL program, the stack contents only consist of the arguments and the name of the FUNC function before the FUNC function is called, since the ACTUAL SAVE CALL function cannot read beyond the read and write lock.
  • the return vector is fetched from the stack, the address of the FUNC function is loaded into the battery and the FUNC function is called indirectly.
  • the stack for the ACTUAL SAVE CALL function When returning from the FUNC function, the stack for the ACTUAL SAVE CALL function is empty. The ACTUAL SAVE CALL function then calls the RETURN SAVE CALL function. The function RETURN SAVE CALL deletes or removes the read and write lock for the stack, so that the stack for the function RETURN SAVE CALL again has the following content:
  • the stack access When an unsafe function is called, the stack access must be restricted to its stack area by hardware. This is achieved by storing the stack frame pointer of the calling function. A protection mechanism must be implemented so that the called function cannot change the value of the stored stack frame pointer. When writing to the stack, it must also be ensured that the stack pointer does not exceed the valid stack area of the current function.
  • the protection mechanism can be activated automatically or triggered directly by the calling function.
  • the hardware is used to restore the original state on the stack.
  • the left representation in FIG. 1 shows the state before the function call.
  • the stack pointer SP points to the uppermost occupied memory cell in the stack. Below this, the stack is occupied, but the stack may be accessed.
  • the stack frame pointer SFP is not occupied or contains a value for a lock from an earlier call.
  • Fig. 1 shows the state after the function call.
  • the stack pointer now points to a memory cell above, which is the last to be occupied.
  • the function FN called and its arguments (ARG) are the last ones after this or these occupied memory cells.
  • the frame pointer points to a field in which the old value of the stack frame pointer is temporarily stored (in the case of multiple protected function calls), or that is empty.
  • the memory cell to which the stack frame pointer points is automatically blocked for access, since access is only permitted if SP ⁇ SFP. This means that this memory cell and all those below it are also secured against manipulation.
  • a memory area for function data to be protected is initially reserved on the stack (return address, etc.). Then the function arguments are put on the stack. Finally, when the function is called, the SFP in the protected memory area (with the stack frame pointer of the calling function of the current function) is placed on the previously reserved area of the stack and the stack frame pointer of the current function is written to the protected area (SFP). This is done either by operating system call or by a hardware mechanism.
  • the stack pointer is always compared with the stored value SFP in the protected area in order to prevent the stack area of the calling function from being manipulated.
  • Overwrite function The return to the safe function and optionally also the call of the unsafe function can take place without interaction with the operating system. This means a speed advantage for unsafe function calls.
  • the alternative would be not to execute the function call directly, but to pass the function pointer and the arguments of the function to the operating system, which secures the previous stack and then calls the function.
  • This is very complicated and takes a lot of computing time.
  • the present invention thus significantly simplifies the implementation of a secure callback in C and for the Java Virtual Machine on a chip card.
  • the detour via the operating system which usually represents a major handicap, can be spared.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Executing Machine-Instructions (AREA)
  • Storage Device Security (AREA)

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

Beschreibung
Verfahren zur Verbindung von Stackmanipulationsangriffen bei Funktionsaufrufen
Auf zukünftigen Chipkarten sollen voneinander abhängige Softwaremodule verschiedener Hersteller installiert werden. Unterschiedliche Module unterschiedlicher Hersteller haben dabei 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 beispielsweise 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 weitere Angriffsmöglichkeit besteht jedoch darin, nicht den Arbeitsspeicher, sondern den Stapelspeicher mit den jeweiligen Rücksprungadressen der Unterprogramme zu verändern. Ein solcher 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 konzeptionell nicht ausgeschlossen werden kann, daß eine Bibliotheksfunktion 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 manipuliert . Auf Chipcard Controllern ist eine Lösung im Stand der Technik bisher nicht vorhanden. Die Problemstellung ist neu, da bisher ein Hersteller für die gesamte Software zuständig war.
In modernen Prozessoren wird z.B. eine Page Table oder Segment Decriptor Table (MMU) verwendet, in die das Multitasking-Betriebssystem den für die Applikation gültigen Speicherbereich 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ünden 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- dem.
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren gelöst, bei dem der Stackzugriff bei einem Aufruf einer unsicheren Funktion durch Hardware auf deren Stackbereich be- schränkt wird.
Es ist dabei besonders bevorzugt, zur Beschränkung des Stackzugriffs 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 sicherzustellen, daß der Stackpointer nicht den gültigen Stackbereich der aktuellen Funktion überschreitet. Besonders bevorzugt ist es, bei dem Rücksprung aus der unsicheren Funktion den ursprünglichen Zustand auf den Stack wiederherzustellen.
Das erfindungsgemäß günstigste Verfahren läuft so ab, daß beim Funktionsaufruf zunächst auf dem Stack ein Speicherbereich für zu schützende Funktionsdaten reserviert und optional die Funktionsargumente dahinter auf den Stack gelegt werden 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 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äutert. 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 abgesicherten Funktionsaufruf.
Bisher lieferte ein einziger Chipkartenhersteller sowohl das Betriebssystem der Chipkarte als auch die Anwendungsprogramme. Das Betriebssystem der Chipkarte konnte also als ein Teil des Anwendungsprogramms gesehen werden. Das Chipkartenbetriebssystem und die Anwendungsprogramme wurden auf speziell hergestellten Masken für das ROM (Nurlesespeicher) der Chipkarten-IC 's geliefert. Es handelte sich also bisher um Lösungen, bei denen die Programme im wesentlichen hardwaremäßig, also fest verdrahtet, vorgegeben waren.
Die vorliegende Erfindung behandelt demgegenüber eine Situation, bei der verschiedene Hersteller Bibliotheken und Anwendungsprogramme liefern können, die dann auf einer Karte ko- existieren müssen. Aus Sicherheitsgründen hat die Programmarchitektur der Chipkarte dann zu ermöglichen, das Betriebssystem und die Bibliotheken gegen Manipulationen von deren eigenen "privaten" Daten, Programmcode und Stack durch ein laufendes Programm zu schützen. Dies kann bei einem Ausführungsbeispiel der Erfindung durch verschiedene Maßnahmen erreicht werden:
1. Segmentierte Adressierung:
Der physikalische Adreßraum von 224 Bit wird über maximal 256 Daten- und 255 Programmsegmente zugänglich gemacht. Die Länge des physikalischen Adreßraums, der von einem Segment adressiert werden kann, kann zwischen 4 Byte und 216 Byte liegen. Ein Segment wird durch seine Länge und seine physikalische Anfangsadresse definiert. Die Adresse (Pointer) eines Speicherplatzes besteht dann aus 8 Bit, die die Adresse des Segments 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 Attribute 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 Datenadressen 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 zweiten Herstellers. Andernfalls würde er nicht auf dieses Programm zugegriffen haben. Andererseits wissen die Hersteller des Programms B nicht notwendigerweise irgend etwas über das Programm A. Daher müssen sie ihren Programmcode, den Stackinhalt und die Daten gegen schädliche Manipulationen durch Programm A schützen. Dies muß insbesondere deshalb garantiert werden, weil die Bibliothek B auch von anderen Anwendungsprogrammen 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, unterstützt. Ein Programmabschnitt auf einer niedrigeren Vertrauensklasse 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 Vertrauensklasse 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 Bibliothek 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 v/erden, einen Programmcodeabschnitt des Kartenbetriebssystems an einer beliebigen Eintrittsadresse anzuspringen. Wenn dies nämlich nicht verhindert wird, können unvorhersehbare Vorgänge 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 Segmentidentifizierung und das niedrigere Byte das Tor der Funktion, das ange- Spr ngen werden soll. Der Fernaufruf liest das Wort automatisch 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 Vertrauensklassen auf niedrigere Vertrauensklassen erlaubt. Umgekehrt 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 Anwendungsprogrammen kann Rückrufe benötigen, bei denen ein Funktionszeiger einer Funktion A auf einer höheren Vertrauensklasse an eine Funktion B auf einer niedrigeren Vertrauensklasse ü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ücksprungvektors 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 Kartenbetriebssystem 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:
2.1. Das Kartenbetriebssystem verwaltet den Stackzugriff.
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 Vertrauensklasse 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. Nachdem 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 Stacksegment .
Beim Aufruf von SAVE CALL übernimmt diese Funktion den Stack mit folgenden Inhalten:
Operanden, Argumente, Name der Funktion FUNC, Rücksprungadresse 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 Kartenbetriebssystems 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 Akkumulator 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 angewendet 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ücksprungaufrufe 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, welches 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 Weise, 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 Verfahrensablauf 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 Stackinhalt 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ücksprungvektor 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 CALL ruft dann die Funktion RETURN SAVE CALL auf. Die Funktion RETURN SAVE CALL löscht oder entfernt die Lese- und Schreibsperre 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 Programm 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 einer besonderen Struktur des Stacks möglich ist. Diese Vorgehensweise 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 Anzahl von Argumenten als Maximum erlauben. Der Rücksprungvek- tor eines sicheren Rücksprungaufrufs besteht dann aus dem
Rücksprungvektor eines normalen Funktionsaufrufs und zusätzlich 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. Andernfalls wird nur der übliche Rücksprung ausgeführt. Im Hinblick auf die Struktur des Stacks entspricht diese Lösung der vorher 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 Funktion auf deren Stackbereich durch Hardware beschränkt werden. Man erreicht dies durch Speichern des Stackframepointers der aufrufenden Funktion. Dabei ist ein Schutzmechanismus zu implementieren, so daß die aufgerufene Funktion den Wert des gespeicherten Stackframepointers nicht verändern kann. Außerdem 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 enthä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 Speicherzelle 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 automatisch 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 Speicherbereich für zu schützende Funktionsdaten reserviert (Rücksprungadresse, etc) . Anschließend werden die Funktions- argumente auf den Stack gelegt. Schließlich wird beim Funktionsaufruf der im geschützten Speicherbereich liegende SFP (mit dem Stackframepointer der aufrufenden Funktion der aktuellen Funktion) auf den zuvor reservierten Bereich des Stacks gelegt und der Stackframepointer der aktuellen Funktion in den geschützten Bereich geschrieben (SFP) . Dies erfolgt entweder durch Betriebssystemaufruf oder durch einen Hardwaremechanismus .
Bei Stackmanipulationen wird der Stackpointer stets mit dem abgespeicherten Wert SFP im geschützten Bereich verglichen, um zu verhindern, daß der Stackbereich der aufrufenden Funktion 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 auszufü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 Machine auf eine Chipkarte deutlich erleichtert. Unter anderem kann der Umweg über das Betriebssystem, der meist ein großes Handicap darstellt, erspart werden.

Claims

Patentansprüche
1. Verfahren zur Verhinderung von Stackmanipulationsangriffen bei Funktionsaufrufen, d a d u r c h g e k e n n z e i c h- n e t, daß der Stackzugriff bei einem Aufruf einer unsicheren Funktion durch Hardware auf den Stackbereich dieser unsicheren Funktion beschränkt wird.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n- z e i c h n e t, daß zur Beschränkung des Stackzugriffs vor dem Aufruf der unsicheren Funktion eine Referenz auf den Stackframe der aufrufenden Funktion gespeichert wird.
3. Verfahren nach Anspruch 2, d a d u r c h g e k e n n- z e i c h n e t, 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, d a- d u r c h g e k e n n z e i c h n e t, 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, d a d u r c h g e k e n n z e i c h n e t, daß bei dem Rücksprung aus der unsicheren Funktion der ursprüngliche Zustand auf dem Stack wieder hergestellt wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, d a d u r c h g e k e n n z e i c h n e t, daß beim Funktionsaufruf zunä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 aufgerufenen Funktion in den geschützten Bereich geschrieben wird.
EP99959185A 1998-10-09 1999-10-06 Verfahren zur verbindung von stackmanipulationsangriffen bei funktionsaufrufen Withdrawn EP1119811A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE19846673 1998-10-09
DE19846673A DE19846673A1 (de) 1998-10-09 1998-10-09 Verfahren zur Verbindung von Stackmanipulationsangriffen bei Funktionsaufrufen
PCT/DE1999/003226 WO2000022533A1 (de) 1998-10-09 1999-10-06 Verfahren zur verbindung von stackmanipulationsangriffen bei funktionsaufrufen

Publications (1)

Publication Number Publication Date
EP1119811A1 true EP1119811A1 (de) 2001-08-01

Family

ID=7884002

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99959185A Withdrawn EP1119811A1 (de) 1998-10-09 1999-10-06 Verfahren zur verbindung von stackmanipulationsangriffen bei funktionsaufrufen

Country Status (5)

Country Link
US (1) US20020013907A1 (de)
EP (1) EP1119811A1 (de)
CN (1) CN1322316A (de)
DE (1) DE19846673A1 (de)
WO (1) WO2000022533A1 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2836569B1 (fr) * 2002-02-28 2005-02-25 Gemplus Card Int Espace memoire pour donnees d'application telechargees dans une carte a puce
US20040168078A1 (en) * 2002-12-04 2004-08-26 Brodley Carla E. Apparatus, system and method for protecting function return address
US7971255B1 (en) * 2004-07-15 2011-06-28 The Trustees Of Columbia University In The City Of New York Detecting and preventing malcode execution
US7607122B2 (en) * 2005-06-17 2009-10-20 Microsoft Corporation Post build process to record stack and call tree information
US7562755B2 (en) 2006-07-07 2009-07-21 Dt Swiss, Inc. Rear wheel hub, in particular for bicycles
US8423974B2 (en) 2009-08-12 2013-04-16 Apple Inc. System and method for call replacement
US8302210B2 (en) 2009-08-24 2012-10-30 Apple Inc. System and method for call path enforcement
US9721120B2 (en) 2013-05-14 2017-08-01 Apple Inc. Preventing unauthorized calls to a protected function
FR3009735B1 (fr) * 2013-08-14 2018-09-28 Intermas Nets Sa Panneau d'occultation
CN105204855B (zh) * 2015-09-15 2019-05-28 浪潮(北京)电子信息产业有限公司 一种调度方法及装置

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4104721A (en) * 1976-12-30 1978-08-01 International Business Machines Corporation Hierarchical security mechanism for dynamically assigning security levels to object programs
US4545012A (en) * 1981-05-22 1985-10-01 Data General Corporation Access control system for use in a digital computer system with object-based addressing and call and return operations
JPS61166652A (ja) * 1985-01-19 1986-07-28 Panafacom Ltd 記憶保護例外による割込み発生方式
JPS62232054A (ja) * 1986-04-02 1987-10-12 Nec Corp スタツクフレ−ム記述子の管理方式
US5222220A (en) * 1989-11-16 1993-06-22 Mehta Hemang S Microprocessor stack built-in guards
JPH0484224A (ja) * 1990-07-26 1992-03-17 Nec Corp スタックエリア保護回路
US5154762A (en) * 1991-05-31 1992-10-13 Minnesota Mining And Manufacturing Company Universal water-based medical and dental cement
FR2683357A1 (fr) * 1991-10-30 1993-05-07 Philips Composants Microcircuit pour carte a puce a memoire programmable protegee.
JP2850808B2 (ja) * 1995-10-31 1999-01-27 日本電気株式会社 データ処理装置およびデータ処理方法
US5754762A (en) * 1997-01-13 1998-05-19 Kuo; Chih-Cheng Secure multiple application IC card using interrupt instruction issued by operating system or application program to control operation flag that determines the operational mode of bi-modal CPU

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0022533A1 *

Also Published As

Publication number Publication date
CN1322316A (zh) 2001-11-14
WO2000022533A1 (de) 2000-04-20
DE19846673A1 (de) 2000-04-20
US20020013907A1 (en) 2002-01-31

Similar Documents

Publication Publication Date Title
DE68924720T2 (de) Verfahren und Vorrichtung für Zugriffsrechtensteuerung.
DE3854616T2 (de) Nichthierarchischer Programmberechtigungsmechanismus.
DE2458065C2 (de) Datenverarbeitungsanlage
DE3689961T2 (de) Verfahren zur Verarbeitung von Unterbrechungen in einem digitalen Rechnersystem.
DE4215063C2 (de) Einrichtung und Verfahren zum Seitenwechsel bei einem nicht-flüchtigen Speicher
DE2916658C2 (de)
DE3750249T2 (de) Privilegausführung in Mikroprozessoranordnungen zur Verwendung in der Software-Gütersicherung.
DE2416609C2 (de) Datenverarbeitungsanlage mit einer zentralen Verarbeitungseinheit und Multiprogrammierung mit mehreren Programmunterbrechungs-Prioritätsstufen
DE68923863T2 (de) Ein-/Ausgabecachespeicherung.
EP0813714A1 (de) Mehrbenutzerdatenverarbeitungsanlage mit speicherschutz
DE68916853T2 (de) Unabhängige Programmlader für virtuelle Maschinenarchitektur.
DE3901457A1 (de) Verfahren zur adressbereichsueberwachung bei datenverarbeitungsgeraeten in echtzeit
DE2758152A1 (de) Speicherschutzanordnung
EP1358558B1 (de) Mikroprozessorschaltung für datenträger und verfahren zum organisieren des zugriffs auf in einem speicher abgelegten daten
DE102018132970A1 (de) Verfahren und Vorrichtung zur Isolation von sensiblem nichtvertrauenswürdigem Programmcode auf mobilen Endgeräten
DE2801518A1 (de) Datenverarbeitungssystem mit speicher-schutzeinrichtung
WO2000022533A1 (de) Verfahren zur verbindung von stackmanipulationsangriffen bei funktionsaufrufen
DE3688811T2 (de) Speicherblock für eine Ringschutzarchitektur.
DE102005022893B3 (de) Verfahren zum Zugreifen auf Speicherbereiche einer Speicherkarte durch eine anfordernde Anwendung und Speicherkarte
DE60017438T2 (de) System zur betriebsmittelzugriffsteuerung
EP1407348B1 (de) Verfahren zum ansteuern einer zentralen verarbeitungseinheit für eine adressierung bezüglich eines speichers und controller
DE112016004301T5 (de) Vornehmen einer flüchtigen Fehleratomarität von Isolierungstransaktionen in einem nichtflüchtigen Speicher
DE19954407A1 (de) Verfahren zum direkten Aufrufen einer Funktion mittels eines Softwaremoduls durch einen Prozessor mit einer Memory-Management-Unit (MMU)
DE602004002241T2 (de) Schutz eines auf ausführungwartenden Programms in einem Speicher für einen Mikroprozessor
EP1428105A2 (de) Programmgesteuerte einheit

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20010302

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

17Q First examination report despatched

Effective date: 20010906

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

R18D Application deemed to be withdrawn (corrected)

Effective date: 20020117

RBV Designated contracting states (corrected)

Designated state(s): AT DE FR GB