WO2013174503A1 - Secure loader - Google Patents

Abstract

A computer implemented architecture to securely execute an untrusted application relying on loader functionalities comprises a secure loader (2) to dynamically load new code from external memory regions not part of the application (AP) during the execution process of the untrusted application (AP), and a separate sandbox (1) with a translation element. (BT) that dynamically translates and analyzes code elements of the untrusted application (AP) before, the code elements are executed. The secure loader (1) and the sandbox (2) reside in a trusted execution domain (TED). The untrusted application (AP) resides in an untrusted execution domain (UED).

Description

SECURE LOADER

'Cross References to Related Applications

This application claims the^' priority of European patent application 12003967.2, filed or. May 21, 2012, the disclosure . of which is incorporated herein by reference in its entirety . ^' - 0

Technical Field

;^■ ,■;^■'■ ^■ The invention relates to a computer implemented architecture to securely execute an untrusted ap-5 plication relying on loader functionalities, and to a

.method to securely execute an untrusted application. ^' .

Background Art ^■'"^■ ■_· ^■ . 0 ' Secure execution, of applications in user- space remains a hard .problem. Software-based fault isola^- t ion (SEI) has been, embraced by many projects r.o address. . this, problem. SFI . aims,, to. provide ,an execution environ- ^■' ment that allows the safe and undisturbed execution of5 applications. An. advantage of ^; SFI is_. that other techniques, to ^'protect ^'the execution of applications (e.g., Address Space Layout Randomization (ASLR) , Data Execution. Prevention (DEP), stack canaries, and policy based system call authorization) are orthogonal to SFI and can be com-0 bined with SFI. The protection techniques can be used to ^{■ '}.^' strengthen the implementation of . the SFI platform that

forms a crucial element of the trusted computing, base, as Well as the application . code . , · ..

A key component of every system is the dynam-5 ic loader . The loader takes control of the application

before the application is everi started. The dynamic load- ; er maps the. application into memory and resolves all. sym- bols that are used from, different shared libraries .^■, These relocations and symbol lookups enable a program to use- libraries and to implement different techniques like position independent code. After the program has been pre.- ^' pared for execution i.e., after the loader has finished the initial relocation and loading, the "initialization code of the application is executed and the application starts . . ·^{■ ■ ■}.

The loader has. access o all symbols and re- located objects at runtime and .shares this information with^' the. executing program. ^'The standard dynamic loader, ; e.g. in Linux, is optimized for . fast relocation and, aims .- to offer a rich functionality_^. The combination of the rich functionality and cpmplexity and the fact.^' that all· applications- e.g., privileged applications, applications reachable ^"over the network, local applications use the same, loader makes it a promising attack ; vector . , ,

. Disclosure of the Invention . ^'"-.^'.

■ .^', . . ^'.·^{·' ■■} ._. ^'■ : ._. . . ^{, ' ■}.^{· '}·^{' : ■■■}

^■.^' Hence, it . is desired, to provide a mechanism that ^"provides an improved security a;; loading of appiica- ' tions . - . ^' . .^" .-. ^· " . ^'.,.^'.^■.

According to^' a first aspect of the present invention, a computer implemented architecture is provided to seeurely execiite. an uritr.usted application relying.- on loader functionalities. ^'The architecture, which may . also be considered as a computing system, comprises. a secure loader^' to dynamically load new. code from external, memory . regions not part; of the application during the execution process of the untrusted application, and a separate sandbox with - a ^' translation .element that dynamically translates .and analyzes code elements of the untrusted application before the code elements are executed. The secure - loader and the sandbox reside-in a trusted execution domain while the .untrusted application resides in an untrusted execution domain, -the trusted execution domain and the untrusted execution domain essentially being owned by the user of, the untrusted application.

^■ _. . . The computer implemented architecture in embodiments may contain one^' or more of the following fea- tures :

- a. control flow analyzer, preferably as part of the secure loader, which can analyze control-flow information, segment information and/or privilege information of the untrusted application on basic-block level and provide this information to the. sandbox, ^{' 1} . . . - the secure loader is adapted to resolve addresses of obj ects ,. symbols and. relocations for the sandbox, ._. :

' . - the sandbox is adapted .to embed the re-. solved addresses in the translated code,

- the objects, symbols and relocations refer to dynamically shared objects called from the untrusted application-,

- the secure loader is adapted to resolve im- ported symbols by checking the . following scopes one after the other: a) A loader scope 'containing symbols that, are exported by the secure loader; b) A local scope of a dy- - hamically shared object containing its own symbols and the symbols of. all libraries that the dynamically shared object depends on; c) A global scope encompassing- .all shared objects that are in an initial set of objects^■ loaded during a start-up of the application or shared ob^¬ jects that are loaded at .runtime with a RTLD_GLOBAL flag,

- the secure loader is accessible for the ap- plication only .through a well-defined application programming interface preventing reading^' and writing -inter-- nal loader data;

- a ¹ functionality related to runtime configu^¬ ration, debugging, backwards, compatibility, access , to loader internal data structures is absent in the secure loader, - a policy enforcement module, preferably as part of the sandbox that can enforce a security policy to the running untrusted application ox code elements thereof, preferably by applying security guards that observe

5 the integrity with the information provided by the control flow analyzer,

- the sandbox is adapted to intercept all call instructions and to check for each instruction if

_{¾ ,} the call is . a PLT call, ■ ·._ ^■-..^'

10 - the secure loader is adapted to resolve a static target address of a target- of the PLT call, and replace the^' original ^"call and indirect jump of the. PLT call by a translated call instruction to the resolved target,

. — the sandbox comprises a protection guard15·- for write-protecting all; data of the trusted execution domain when code from the untrusted execution^' domain is executed, V ^; _. .

- the sandbox comprises a security guard for setting a non-executable _, bit on all memory pages of the ^■20 application, ■ '

- the sandbox is adapted to use address space layout randomization for allocating internal data structures t random addresses,

- the sandbox. comprises a privileged code 25^' stack for executing privileged code,

- a sandbox stack, ^{■'' '} - an .application stack,

- an entry .trampoline for handling a transi-

. - ti n from translated application code to privileged sand- 30 box code adapted to let an application stack remain unchanged, to spill registers to a thread-local storage ar^¬ ea in the trusted execution domain, to swap the stack to . the sandbox stack, arid to run code in the trusted. execution domain by using the sandbox stack to store local in- 35 formation,^" . - . _. ^'..

- an exit trampoline for returning from the . trusted execution domain to the untrusted execution do- main adapted to restore registers, to switches back to , ^' the ; application stack, and to continue the execution of the translated code,

• * ' - a shadow stack for protecting all addresses returned to the application stack and for keeping information about the application stack frames in the _. trusted, execution domain, including a return instruction pointer, a translated return instruction pointer,, and a stored application stack pointer, „ "·

, According to another aspect of the present invention, a method is provided to securely execute an .untrusted application . on a computer using the computer implemented architecture according to any, of the preceding embodiments comprising the steps of running an ini- tialization code . on the secure loader and the sandbox, ^■ the secure . loader . passing a loaded code element of the untrusted application to the sandbox for translation, ensuring that all access to loader functionalities is direcfed to the secure loader, the secure loader giving. control to the translated, code element, the secure loader, controlling the correctness of requests it receives from translated code elements,, whereas the execution of the initialization code is run at first.

According to a . further aspect .of the present- invention, a method is provided to securely execute an untrusted application on a compute , profe rab I y by using the computer implemented architecture according to any of the preceding embodiments, comprising the steps of ini^¬ tializing a secure loader in a trusted execution domain of a user space_/ initializing a sandbox in the trusted: execution domain, the secure loader , resolving, addresses of objects, symbols and/or . relocations called- by the untrusted application, the. secure loader dynamically loading the objects, symbols and/or relocations called by the untrusted application and passing the loaded objects, symbols and/or relocations to the sandbox for transla- tion, the sandbox -embedding the resolved- addresses in the translated code-.

Any of the methods may contain in embodiments one or, more of the following features:

- the secure loader loads the untrusted - application or parts thereof, into the untrusted execution domain and the control-flow, analyzer provides the sandbox

•with basic-block level information about control-flow,

^'segments and/or privileges-,_. ■ ^' ..

- the sandbox controls if the untrusted ap- plication follows the basic-block level information it receives from the control-flow analyzer and stops, or at least modifies the execution of the untrusted application if this is not the case,

. - the secure _.loader removes any references or information about . the trusted execution domain before it passes it . to the untrusted application,

- the execution of the initialization code is run at first, in particular wherein the secure loader is ^" initialized first and initializes the sandbox second.

.According to a further aspect of the present invention, a computer program element is provided for operating a portable electronic device, which computer program, element, which preferably is stored on a computer storage medium, comprises computer program code means for executing a method according to any of the embodiments of the present invention. ,

According to , another aspect , of the present _. invention_/ a .use of a computer implemented architecture according to any one of the preceding embodiments is provided in a computer system, and preferably in an operating system of the. computer system.

. ^: Other advantageous embodiments are listed in. the dependent .claims as well as in_. the description below. The described embodiments similarly pertain to the archi- tecture / system, any of the the methods, and the computer program element, and the use. -Synergetic effects may arise from different combinations of the embodiments although they might hot be described in detail.

, Brief Description of the Drawings ' .

. ^■·^' · ^■'

■ The detailed description refers to embodiments of the present invention. Such description makes reference to the annexed drawings, wherein:/

Fig.^{^}1 illustrates a diagram of a computer implemented architecture to securely execute an .untrusted application according to an embodiment of the present invention,

Fig. 2 and 3 illustrate flowcharts of a method, according to an embodiment of the present invention,

Fig. 4 illustrates an ELF table as used in a computer implemented archit.ecture according to an embodiment of ..the present invention,

Fig. 5 illustrates ^' a block diagram of a computer implemented architecture to securely execute an un- trusted application according to an , embodiment of the present- invention, and_...

Fig . 6 illustrates a conventional process of executing code residing ^"in various dynamically shared ob- - j ects . ^". ^{' ■}

Detailed Description

Prior to describing . embodiments of the invention in more detail, ' it is referred to the dynamic link- ing of libraries or other Dynamically Shared Objects. (DSO) in a conventional approach, e.g. in Linux. This section aims at- the introduction of terms and abbreviations in the context of linking.

Linux uses the. Executable and Linkable Format (ELF) to_. describe the on-disk layout of .Dynamically

Shared Objects (DSO) and executables. The ELF format de- fines two views for. applications and libraries . The first view contains essential information for the loader about . the different segments, i.e.. areas with same page permissions in the object. The second view. contains the- section header table■ with more fine-grained information like symbol tables. Libraries contain one or two symbol tables:'

· . dynsym, a dynamic ^' symbol table that contains information such as size, type, permissions, and others about all exported symbols; and

- · . syrr.Lab, an optional table that contains information about all symbols in the library.. The, optional table, is available by default and removed if the ob^¬ ject is stripped. .

^■ Libraries are, mapped to dynamic, i.e. non- constant addresses in memory., The compiled code- must, therefore be position indopendent. Position independent code relies on the Global Offset Table (GOT) , which con- ^■tains ^' information about imported and exported symbols for each DSO . This information is used to^" access symbols in other DSOs with non-constant addresses. The Procedure Linkage Table (PLT) is used to transfer control to sym- , boIs in other DSOs. Entries. in . the PLT correspond to a indirect, jump . through ^' a GOT . slot .see Figure 6 for an ex- ample. Function references in the GO are initialized .with a pointer to the dynamic -loader. The first execution resolves the actual symbol and stores the. esolved point- er in the GOT slot,. Later calIs to the same 'function re- suit in a direct transfer to the resolved .symbol..

Prior to referring to the.. Figures in the^' corresponding . description, it is pointed at various embodi- . ments. of the present- invention in the following sections.

The computer implemented architecture splits the user-space into two execution domains, the _, privileged sandbox domain that controls an application and the ap- plication domain that executes translated application . code. The sandbox implements an additional protection domain in user-space, splitting the user-space into. an application domain^' and a sandbox, domain . The memory of a computerized system, which shall include the main memory such as a random access memory, is the place where application code is loaded for execution.. Typically, the memory comprises a user space representing a space in the memory reserved for user applications as opposed to a kernel space reserved for running the kernel of the operating system. Typically, the user space cannot be used by applications from other users . At the same time, ^'the user space is reserved for a user and its applications which applications may not access user spaces assigned to. other users.. Access to a reserved space in the memory, such as a user space is subject to the application / process having access rights / privileges that match access_, rights / privileges required by the respective user space. As a result, applications running in a user space are protected. In the following, a user space of the memory _;is^' also referred to as execution domain given where this is the domain of the memory- that- applications under the control of the user can be executed-. Or, in other words, a user space is owned by the user having the corresponding access rights.

A sandbox is understood as a software based tool that ensures that no unchecked code is„executed. The sandbox at the same time aims to provide an execution en- vironment that allows. the safe and undisturbed execution of applications.. For verifying the application code to be executed, the . sand box requires a' dedicated portion of the user space .in which portion the sandbox is executed. Such portion of the user space is referred to in the fol- lowing as . trusted execution domain or sandbox domain or second privileged .domain compared to another domain of_. the user space which is referred to as untrusted execution domain or application domain. Hence,, the sandbox resides in and/or forms the trusted execution domain, given that its operations require an enhanced protection for preventing interference with other processes. Hence, the trusted execution domain can be considered -as a domain in the virtual main memory of the computerized system. in which the execution of code is trusted based on memory access rights and/or execution privileges, considered as trustable. The untrusted execution domain in contrast may be accessed with memory access rights and/or execution - privileges less stringent than for accessing the trusted execution domain.

Hence, the sandbox implements two privilege: ^■■■ domains, in the user space: the sandbox domain as a trust-^' ed execution domain that contains a loader and the sandbox, and the application domain as an untrusted execution domain that contains the application: code and all needed libraries . , ^{■ '}

The sandbox domain ensures that no unchecked .code is executed in the application domain ._. In a preferred embodiment, application code is examined by the sandbox ..before execution^" and additional security guards . are added to ensure that the executed code cannot escape out of the sandbox. Preferably, a binary-only application is executed under the control of the dynamic sandbox.

Preferably, the binary itself is untrusted but not mali^¬ cious, i . e . , the binary can contain implementation bugs but the binary is not controlled by the attacker. Preferably, no static 'modifications or static analysis are needed to execute an application in the sandbox.

It is preferred that the sandbox comprises a translation element,, which is adapted to use binary translation to check the executed code. The sandbox preferably translates and encapsulates all machine code in- structipns of the application. In a preferred approach of a sandbox, a dynamic binary translation is applied, in . which all code is translated on-the-fly and checked be^¬ fore it- is executed. The translated code preferably is placed in a code cache to lower translation costs . The translation element . which in a preferred example is a us- ■er-space dynamic binary translation element also denoted as BT takes control and implements a second privilege do- main, i.e. the trusted execution domain in. the user- space. Translated application code is then executed in the untrusted execution domain with lower privileges than in the trusted execution domain. The translation element preferably ensures that during the translation the translated application code has no access to data ^"structures and to . code of. the translation . element . ^■

.. . Indirect control flow transfers trap into the privileged . sandbox domain and are checked upon every exe- cu ion , ensuring that only translated branch targets are reached . The ; translation .element preferably can change, adapt, or remove any invalid instruction and . preferably is able to intercept system calls before they are -execut- ' ^:- It is preferred that return addresses' of the translated application^' remain unchanged on the stack^'.

Translated return ^'addresses on the ^' application stack .

would,,leak pointers into the code cache. Unchanged return . addresses add additional complexity when handling return Ϋ instructions as they are translated to a lookup in a map-, ping table of the. sandbox which is an internal data .

• , structure that relates, between translated and untranslated code, and an indirect control transfer. Or.. he other ^' hand an unchanged stack may ensure, that the original pro- gram can use the return' instruction- pointer on the stack . for (i) exception management, (ii) debugging, and (iii) return trampolines, for example . Additionally, . the appli^¬ cation .program has no^■ easy way to discover that it runs in a. sandboxed environment, and the address of the code cache is only known by the translation element-.

It is preferred that , the sandbox combines ' software-based fault isolation (SFI) concepts and policy- . based system call authorization to ensure that neither the application nor any exploits can escape the sandbox. SFI is a technique that enforces a security policy on ex- : ecuted code. The_. security policy includes. one or more or all of guards and restrictions. oh memory accesses, re- strictions an control flow transfers,_, arid restrictions on instructions ^' and combinations of instructions^' that can be executed. ^" ' ^{' ■}··^■"·

A -dynamic loader takes control of the appli-

5 ■ cation before the application is. even started. The dynam- • ic loader maps. the application into memory and resolves all symbols that are used from different, shared librar- . . ies. These¹ relocations and symbol lookups ..enable a pro- . gram to use libraries and to implement different cech- 10 niques like position^' independent code. After the. program - has been prepared for execution i.e._/. after the loader ·. has finished the initial relocation and loading_/ the ini- ' ·, tiaiizatioh code of the application is _. executed and the application starts. ^'"^',·'■

15 ' . A standard loader may have several problems if . it Is used in ^' a security-relevant context. Bugs in the ':^■. standard loader lead to direct privilege, escalation. If the application and the sandbox share the same loader ■ then the sandbox can be attacked, through the loader. All^" _. 20 . .dynamically loadable applications rely on features of the loader to dynamically resolve references or to load addi- • ^■ tional modules .. If the loader . is translated alongside the application then the' application must have the privileges ^{■ '} to map code as . executable which again poses a security 5 risk . ^■':^' ; ^■ ■ ·

According to an embodiment of the. present in^¬ vention, the secure. loader resides also in the trusted execution domain. Hence, the sandbox separates user-space ; into two privilege domains, , the privileged sandbox , domain 0 that contains the secure loader and the sandbox, and the application domain that executes application code.

i The secure loader^' runs as part of the privi- . leged - sandbox domain. Preferably,, the secure loader is

the only entity . that is .allowed . to load new code, and

5 preferably, the application is only allowed to access

loader functions through a well defined- API . The sandbox ' ^'and the loader are tightly coupled and share information about the. program. The loader preferably analyzes segment and section information . of the application and all dynamically loaded objects and enables per object privileges. - . The. loader preferably resolves objects, symbols, and rc- 5 , locations for. the sandbox that then embeds resolved addresses in the translated code .. The tight coupling of the loader and the sandbox enables module separation. Control transfers between'^' modules are inlined directly into the translated code. The translated source. object contains a 10 direct reference that is unreadable, from the. application to the target . obj ect and no call through the PLT and GOT is needed. The PLT data structure ^'Is only kept for refer- ence reasons. The secure loader preferably ensures, that the SFI library is initialized first and treated special- 15 ly so that ^' symbols are neither added to. the global scope nor accessible through any APT functions.

Combining a secure loader and a safe sandbox to form a trusted execution environment enhances security. The loader is separated from the application and the 20 application may not access the loader's internal data

structures directly . ,The privileged sandbox domain is a perfect location for the secure, loader. The secure loader , and the sandbox; share information, about all loaded shared ' ' objects and symbols.. The shared information enables the 5 sandbox to restrict control flow transfers in the appli- • cation domain. The loader needs_, privileges to resolve dependencies, and to map executable code, these privileges . are best placed in the sandbox domain.

The secure loader may restrict¹ rivilege es- 0 calatipn attacks: The secure loader preferably implements a subset of the features of a standard loader. The subset preferably is complete enough to run ^'in practice any programs compiled with a recent version of the compiler . toolchain. The supported programs are independent of the 5 source language ( e.g. C, C++, Fortran) . The feature set of the" secure loader preferabl-y . is limited to relocation, types needed on the current platform while a standard loader supports : relocation of other platforms as well.

. .Preferably, no runtime configuration, no debugging features that execute ^'user specified code,, no backwards compatibility to old formats, and no direct access ' to- loader internal . data structures from the application , are availa- ^' ble. :

Programs / applications are targeted running •with a higher, privilege level than the user interacting with the . program / application,. Two examples of such ap- plications are (i) privileged "SUID" applications and ^■ (ii) applications that are connected to the network. A. third possible use-case is the execution of potentially malicious code, in combination with specific system call policies. The interaction between the malicious^' binary e . g¹. , the ,.pro,gram, a library, or a module-,, and the regu- 1ar system libraries is controlled and checked using dynamic security guards. ^{■ '}. ,

The: secure loader preferably does not read any environment variables and has. no configuration files that are parsed at runtime. A user preferably, is not al- . lowed to change settings for privileged programs.

·^' . All settings are preferably hardcoded during the compilation. Library paths, debugging features,' and , loader settings can preferably only be changed .before the compilation of the. secure loader . The secure loader preferably does not allow changes to any settings at runtime. The removal of these user-settable features protects from, attacks. Privileged applications do not need these fea- . tures, therefore removing the■ features, altogether is more secure than executing additional checks before accessing _ the features . .

.· . Λ The secure loader may protect all executed application code: An initialization code of the secure loader is the first' code that runs, when an application is started. This^' initialization code starts and initializes the sandbox as, well. The secure loader can execute all application code under the control of the sandbox because the loader is part of the privileged sandbox domain.

Preferably, the secure loader tells the sandbox to, trans late an. entry point to application code whenever the standard loader would pass control to application code. The application traps into the sandbox domain when it us es any loader functionality e.g., for resolving symbols, loading additional modules, or loading PLT entries. The secure loader preferably verifies the correctness of the request, and returns the result to the application do- ..main. The secure loader preferably cleans all references to internal data from any returned structures as an addi tional level of protection next to setting internal ._.data structures read-only when executing translated application code. The . application may ^" use the loader features through a well-defined API and can ho longer read or 'write internal loader data . Trapping intp the sandbox do main switches the stack of the current thread, stores in formation about the current .state of the application thread i.e., registers and PC, and adds write, permission for the internal data structures of the^' secure loader; these changes are reversed when returning to. translated application code. This procedure ensures the safety of the secure- loader, the sandbox, and the internal data structures at all times.

The sandbox and the loader are in the^' same trust - domain and together provide the base for. trusted execution. Loader and sandbox . can share data structures ' and exchange information about executable code regions, data regions, and symbol . locations^'. The loader is there- ^" fore not translated by the sandbox as a part of the application but is an. integral part of the sandbox. The . application no longer needs, and preferably has no privileges to map executable code into the application memory space but preferably uses the loader API provided by the sandbox. All applications can remain unchanged but calls to the loader are redirected to' the secure loader API in the sandbox domain. . . For mapping libraries to dynamic i.e. -non-^■ constant addresses in memory, . the compiled code . must . therefore be position independent. Conventionally, pdsi- - ' tion independent code relies on . the Global Offset Table , '(GOT) , which contains information about imported and ex^¬ ported symbols for each DSO. This information is used to access symbols in other DSOs with non-constant addresses. The Procedure Linkage .Table (PLT) is used to transfer control to symbols in other DSOs, entries in the PLT cor- respond to an . indirect .jump through a GOT slot.. Hence,

. the PLT is originally. used to enable position independent code. However, in one embodiment of. the invention the bi- .^' _: nary translation element in the sandbox removes the PLT . code and- inlines the resolved target addresses directly into the ^' generated. / translated code. This optimization reduces the amount of_. indirect control' flow transfers which account for the main overhead, in dynamic binary translation, and hides the location of other objects from ^: the application.

As a result, the addresses are ^'encoded di^¬ rectly in the code cache and the application has no ac^¬ cess to the^: instructions in the code cache . Th^'is. feature . enables module separation and raises ^' the bar. for security exploits, because a potential exploit is unable to deter- mine. the locations of specific functions in other ob^¬ jects. The total number of indirect control flow transfers is reduced, limiting j ump-oriented attacks. Format string attacks and other data-oriented attacks can,be used to circumvent guards in the application domain like ASLR, DEP, and stack canaries. These attacks overwrite pointers in_. GOT sections of shared objects and use ^'the .indirect jump instructions in the corresponding PLT regions to set up arbitrary code execution. Each PLT call in the application code can be used as. a gadget for jump- oriented programming._. PLT inlining closes this attack . vector .. ^' , ; If the program. would be able to. locate the internal data^' structures of the binary translation element e.g., the code cache, it could modify the executed code by directly changing instructions in. the code cache ^■ and, break out; of the isolation layer . Therefore any pointers to internal data are preferably only allowed in the sandbox domain, and a protection guard in the sandbox ■ preferably ..ensures that all data of the sandbox domain is write-protectod whenever, application code is executed. The basic binary translation element is preferably ex- tended by one or more of the following security guards that secure the user-space isolation sandbox and t;o en^¬ sure that application code . cannot escape,, the sandbox :

• Non-executable data and' code ensures that neither data nor code of the original application can be executed directly by setting the non-executable bit on all memory pages of the application. This guard prevents . code injection attacks; . . ^' .

- ^".^'· . Only translated code_, in the code cache and code .of the^{' '} sandbox domain are executable. A shadow stack , in the sandbox domain- protects all return addresses on the application stack. This guard prevents return- oriented programming. - ' _. · The -sandbox uses Address Space Layout -Ran- domization ( SLR) to allocate^' internal data; structures at random addresses . ASLR is an additional probabilistic ·. protection against bugs in the implementation of the - sandbox . , _. ¹

• The sandbox uses a dedicated stack for all privileged code to prevent data leaks . to the /unprivileged domain . A trampoline switches the context and stack when^¬ ever privileged code is executed.

^{' ■} · A protection guard ensures _. that no data from the sandbox domain is writable when code from the application domain is executed. The protection guard uses information from the sandbox, internal memory allocator and. mprotect . system calls to write-protect all. sandbox. internal data structures whenever translated application code is executed. . ,

' The sandbox and the secure loader. of the introduced trusted computing base are small and provide a safe - the implementation is reviewed and bug-^free - _;and secure - the design does not provide attack vectors in the offered functionality - environment. This combination enables a safe foundation ,for software-based fault isolation where all application code is executed under the . control of the sandbox.

..^{' '} , ^' The secure loader implements the safe foundation for the SFI framework, provides information for . the sandbox that executes application code,^' and supports basic loader functionality. The secure loader ^' collects information about all symbol locations and relocated pointers. This information is then used in the sandbox- to secure the execution of the untrusted code. This approach to a user-space sandbox implements a holistic view, of ^'the ' program execution. Inter-module control flow .transfers ' are no longer implemented as jump tables but the loader forwards the^' information about the target location into the sandbox .. Preferably,, the sandbox directly encodes the correct target location at. the source control transfer instruction . , This dynamic setup removes the additional indirections eeded¹ to cross module boundaries ._. while still enabling dynamic loading of shared objects.

Concerning the timing in a -method according to an embodiment, of. the invention, it is preferred, that (i) the secure loader and the sandbox are initialized during startup, (ii) the secure loader then loads the ap^¬ plication in the sandbox and resolves all dependencies to external libraries, and (iii) the . sandbox starts the^" main . application thread in the application domain.

In a preferred 'embodiment , the secure loader first initializes the secure sandbox. The secure loader then opens and analyzes the application and all needed libraries. Accesses of the application into the loader are intercepted and redirected to^' the protected _..domain . The sandbox dynamically translates . all. application code before it is executed. Original. code regions in the application preferably are mapped as read-only. The tar- gets of static control flow instructions (di rect jumps, direct calls, and conditional jumps) preferably are verified during the translation. Dynamic control flow instructions preferably incur a .runtime check that verifies for each, execution that, the target is valid.

In a preferred embodiment, the secure loader starts and initializes the .sandbox before the application binary is opened . The loader then loads ^' and _/relocates the application and all .libraries . Any application code is executed under the control of the sandbox. The sandbox ensures that no untranslated code is executed. The memory layout of. the sandbox ensures, that no. code-injection attacks are possible_* Preferably, all. memory regions are either executable or writable, but never executable and writable. The security- guards that are woven into ' the. - ^', translated code preferably^' ensure that any direct or indirect control flow transfers only redirect control flow to already known, and verified targets_^.

The . combination of a secure loader with a ^' sandbox offers several advantages. The secure loader ena- bles a clean foundation to implementing ^' a secure sandbox, ^'■ unmodified binary, applications are safely executed in- the unprivileged application domain. Any requests for system calls, · indirect control flow transfers, or functionalit o^'f the dynamic loader trap into the^' sandbox domain. The application domain preferably, has 'no^' privileges to map executable code. The sandbox"^' ensures that no untrusted application code is executed outside of.^' the sandbox . Any calls into the loader trap into handler functions in the . privileged sandbox domain where the parameters can be checked and verified. . ^

- . . Self-modifying code in the application pref-, ..erably is not supported, i.e., the application is not al- lowed, to generate/new code at runtime. -Preferably, code ^' can only be added to the runtime image of an application through the secure loader API. - Preferably, . calls from the , application to the loader are redirected into the sandbox ^'domain , where the requests are verified- Applications running in the sand-. . box need .fewer privileges, and code-oriented attacks are no longer possible. An additional advantage of the shared information between the loader and the sandbox: is the po- tcn iai to remove many indirect control flow transfers between modules. This optimization reduces the · overhead of the sandbox and limits ump-oriented programming ■at-■ tacks.' This approach .bridges the security context of programming languages and operating . systems by enabling a language-independent secure execution of . applications .

Many of the above arid following embodiments -, focus on a Unix-like context, but may be applied to other contexts as well..

.Figure 1 shows- a diagram illustrating a coiri-. puter implemented architecture to securely execute an un- trusted application, according to an embodiment of the present invention^'. An application program AP in an un- trusted execution domain UED comprises, for example, various basic blocks 0,1,2,3,4 which. are executed in an or- der indicated by edges between the various basic_. blocks. Hence, the. edges indicate a^■ control flow, of the. application program AP when being executed. The flow of execution in^' an application can be seen as a_. graph where con- · trol flow transfers^' are^' the, edges and the nodes are indi- viduai'basic blocks. A. sandbox 1 which is arranged in a trusted execution domain '.TED includes a dynamic binary translation element BT. In the. translation element BT^ each basic block - aiso referred to. as code segment or code element - is translated/before execution and placed in a code cache CC . A mapping table MT maps basic blocks ^■', from .the original prog-ram AP to translated basic blocks 1." , 2 " , 3 " . Outgoing edges in translated basic blocks point ' to other translated basic, blocks or back to the translation element BT if the basic block is not translated. Un- ^^'translated basic blocks are translated on demand. Most instructions are copied verbatim for regular binary translation.^' Preferably, special treatment is applied to all instructions that change control : flow . The- translation element BT emits extra code . that · handles direct con- trol flow transfers such as one or more of e.g., jump in- structions, conditional jump instruction^'s, call ins-truc- tions, interrupts,, and system calls. Jump instructions and conditional jump instructions are- redirected to the translated basic blocks in the code cache, interrupts and system- calls are , replaced with , a code sequence that traps into the privileged domain of the sandbox 1. Indirect control flow transfers e.g.-, indirect jumps, indirect . calls, or function returns .are replaced with cpde sequences that execute ,a lookup in the mapping table. MT ^" and an indirect control, flow transfer to the translated basic block. The special, treatment of indirect control flow, transfers is preferred to keep up the illusion that the application is running in its native environment. No . pointers and return addresses are changed by . the .translation element BT,^' therefore the translation element BT must trap the indirect control flow transfers to. keep control of the program.

As a result, and not limited to the present .example, the loader informs the sandbox about vaLid, code regions of the application. The translation element BT prepares and enables the ^"checking of machine code in- structions of the application program ΆΡ before they are' executed. SFI extends the translation element BT, wherein the. translation process, which often uses a code cache for already translated code, weaves additional guards.-^" e.g.,, unexecutable stack, shadow stack, and write- , protected executable code - into the translated code that ^' ensure that the targets-of control -flow instructions cannot be changed by. code based exploits . The translated ap- plication code can read any readable memory location and can write any writable memory location' without any addi-

. tional penalties. ._. .·

System calls are requested using specific in- structions and the sandbox 1 is in the unique position to replace these instructions with special sandbox code. The sandbox 1. checks individual system calls and verifies

^■ v^■ « .^' ■ ^■■ - .

system call numbers, parameters, and locations according , to a given system call policy. This concept is known as policy-based system call authorization.

, Figure 2 illustrates a flowchart of a method according to an embodiment of the present invention. The secure loader first initializes the sandbox, in step ^'SI before any application or library code is loaded or exe- ^■ cuted. The secure loader then opens and analyzes the application and all needed_. libraries in step S2. All application and library code is then executed under the con^¬ trol of the sandbox in step S3, such that no unchecked code is executed directly.

· The secure loader preferably uses, ELF. information, and symbol table information and implements all needed functionality to load most programs e.g.:, OpenOf- fice, and SPEC CPU benchmarks. The SFP platform is tightly coupled witlr the secure loader. The loader first maps the sandbox into the_. address space and initializes the sandbox / SFI platform i-n step Si . This special treatment ensures that "the SFI platform is initialized and that the

^■ application has no access to or knowledge of the sandbox domain .

· . .The next steps include the relocation of the application and all needed shared objects in step S2. The loader controls all data, that^' is passed to the applica^¬ tion and. runs all user code under the control of the SFI

^■ platform in step S3.

... In one embodiment, the secure loader implements the most common subset of features from the standard loader. Some_. features e . g ., overwriting library search paths, runtime debugging, or debugging features that execute, user-supplied code for . specific events, are removed and not implemented out of security concerns. Un- implemented. features result in an error message and

_,5 graceful termination of the program. For example, in an implementation the .loader covers the core- functionality . . needed to execute in- practice any ELF programs that^' uses shared, libraries . Further options e.g., obscure relocation patterns, additional callbacks from- the application 0 into the loader, and access to internal loader data can ■ be added if needed. The API of the secure . loader that, is accessible from the application - e.g., dlopen, dladdr, . and dlsym - ensures that no protected internal , data is . leaked to the application. The. sandbox write-protect_.s all 5 internal data 'whenever translated application^{* '}code is ex^ ecuted. by using mpro ect on all memory regions of the ^'· sandbox .

The secure loader preferably handles the start-ύρ of new applications as is shown in- the flowchart 0 of FIG... 3. First of all the loader ^'is completely independent from any libraries, even from the standard libc, and is just mapped into memory, . preferably into the trusted execution domain. This loader then examines the ELF headers , of the application and maps the runtime sec- 5 tion≤ of the application to a. fixed address in memory in step S21. Then the list of needed libraries is examined and entries are. added to a "to-process- 1 i stl", see . step S22. The loader dequeues one entry at a time and loads arid initializes this library at random addresses in ste0 S23. If the library depends on other libraries then ..they are added, at the end of the "to-process-list" . This algorithm conforms to a breadth-first traversal of the de- • , pendence graph of the application, starting with the application as the root node. References- to needed librar-5 ies only contain the. name of the library ^' but . not _. the

path. When the loader locates a new library several paths are examined: first a. per-DSO variable that specifies one or more search paths per DSO, then the standard search paths defined in /etc/Id . so . conf. The. standard libc - loader also supports additional Search directories using the LD_LIBRARY_PATH environment variable and the local" cache ^' file /etc/Id . so . cache . , Out of security reasons the secure loader preferably, does not support runtime-configurable paths . ^: . _. . ^■ . > . .

In an embodiment, the loader : resolves symbols -using the symbol tables in the different shared objects.^' Every shared object contains the .dynsym table with all exported Symbols. If the loader needs to resolve an imported symbol then, the loader checks, different lookup' . scopes. The loader defines . three different ..lookup scopes that are checked one after the .'other :.^{' ~} :

1 ) Loader^' scope": this scope contains, -the symbols that are exported by the secure loader . The loader scope is checked first and symbols in this scope cannot be overwritten.

2 ) Local scope: the local scope of a DSO con- tains its own symbols and the symbols of all libraries that- the DSO depends on. This scope is a subset of the global ..scope . . ; ; ^'

> 3) Global scope: shared objects, that are in

/the initial _. set- of objects loaded during the start-up of. the application (e.g., all objects in the dependence

^' graph") , or shared objects that_. are. loaded at runtime with. the RTLD__GLOBAL flag set are in the global scope'.

.. A special feature may be symbol versioning where symbols can be defined multiple times with differ- ent versions .. The correct ^' symbol is then selected based on a matching version. -_:

;. The Secure loader preferably supports the GNU IFUNC relocation format- (STT_GNU_IFUNC) where a piece of code is executed to determine the correct location of the symbol. .This feature is,, e.g., used' in the libc to select between multiple implementations of a function. A test .,^' function checks if a. specific CPU feature is available and returns an optimized version for^' the current environment . The loader then uses this function^■ pointer, and for- . wards it to the requesting DSO where the function pointer can be embedded in the GOT.

One of the advantages of a secure loader is,, and one, preferred embodiment of the invention includes that a^'ll loader . related data structures can be write- protected. The secure loader manages, two kinds of data structures, internal data structures and application data. structures,. Internal data structures, contain information about the, different relations between shared objects, scope information, and other details about the loaded objects. This information is 'updated by the secure loader whenever new shared objects . such as additional shared li- braries are loaded and initialized. The secure loader maps these data structures read-only, whenever application code is executed.

Shared objects contain, data structures that are > only changed by the loader and are. only , read by the . application., If the standard libc 2.13 is taken as an example, see the table in FIG. 4, there. are thirty-four -ELF sections _. that are mapped to memory. Eleven sections are mapped · writable, i.e. .tdata, .tbss, . fini array, .ctors, libc subfreeres, libc atexit, libc thread sub,

.data.rel.ro, .dynamic, .got, .got. pit, .data, . bss , and one section -..dtors - is marked read-only but on the same memory page as . ctors . and is. therefore writable^" as well. Most, of these sections are used only during the in^¬ itialization of. the shared object. The sections

· · . data . rel ._:.fo, .^'dynamic, .got,, .got .pit are critical for, the loade and . can be used in attacks against a classic ' sandbox that does not integrate the loader into the security concept- The standard loader., would map .data.rel.ro as read-only after the initialization but the other sec- . tions remain writable. Out of the writable set of sec-, tions only .data and .bss are used by the libc code. The secure loader instead write-protects all . sections, except^" • .data and . bss dynamically to protect the application . from modification attacks in_. these sections whenever translated application code is executed. If the secure loader, needs to update write-protected structures e.g., a GOT entry, then the write-permission is set temporarily ^'. during ^'the update in the sandbox domain. The write- permission is removed when returning to the. application doma in , .' ,-. ^"

In an embodiment of the invention, the secure loader implements a binding mechanism, also referred to as "lazy binding" which reduces the amount of ^' relocations . that have to be calculated when a library is Loaded. Only symbols in the data .region are relocated in this embodiment, but symbols in the PLT region are only resolved^' and relocated when the function is executed, the first time.

,In an embodiment of the invention, the secure loader- implements an inlining mechanism, also referred to as "PLT in 1 i ning" which uses the close relationship between the secure loader and the sandbox. The sandbox in- tercepts all . call instructions and checks for each instruction if .the call is a PLT call. The secure loader:, .then resolves the static target address of the PLT tar-, get. The original call and indirect jump of the PLT call are then replaced by a translated call instruction to the resolved target. This removes an -indirect jump including^' ._.an indirect 'control flow check for every PLT call: that is executed. , . . ■.

It is preferred, that: during the loading process weak symbols of prior DSOs can be ^' overwritten by symbols in the current DSO. Library loading forces all threads to trap into the sandbox domain and to flush

. their code -caches . If the weak symbol points to a func^¬ tion aid this function was inlined through a PLT slot then the sandbox has an invalid reference ' in the code cache and must therefore flush the code cache to< retranslate the_; given PLT slot. It is preferred that, the secure loader handles the sandbox in a special way: The loader resolves the additional sandbox code before any shared library or application code is loaded and initialized. The' symbols -are also resolved in a protected scope that is only accessible by the secure loader and. the sandbox.. Any application or library code that ^' is then executed during the initialization phase is executed under the control of the sandbox, enabling security .right from the start.

; -Returning to the architecture illustrated in

Figure 3 wherein an API is provided for the secure loader 2, wherein additionally ^' an alternate sandbox stack 3 is provided for functions in the sandbox domain,, and wherein' . additionally a ^' new shadow stack 4 is provided, to store information about the application stack 5 in the sandbox domain . ,

The sandbox 1. uses the secure loader 2. to lookup information on , the different sections. The sandbox 1 uses this information to decide if code is in an . exe- cu able section of a shared- object or in some other region. The. same information may be. used to implement PLT. inlining as described above. The sandbox 1 preferably uses · specific_. entry and exit trampolines. TP to simplify the transition between, the application domain and the sandbox domain. The entry trampoline TP_. handles the transition from translated application code to privileged- sandbox ' code.. The application stack 5^' remains unchanged,, registers are spilled to a thread-local storage area in the , sandbox domain and the ..stack is swapped to a _. sandbox stack 3. Code running in the sandbox domain uses the^', sandbox stack 3 to store local information. The exit trampoline TP returns from the sandbox domain to the ap- plication domain. The trampoline TP restores registers, switches back to the application stack 5,.. and continues the execution of the translated code. Events that trigger a switch from the application domain to the 'sandbox domain may. be one or more of the following: ^{' :}

' ^' · Lookup misses in the mapping table: If an

• 5 indirect, control flow transfer cannot be resolved with . the inlined. assembler code, such as . a quick lookup in the first entry of the mapping hash table, then the control flow transfer code escalates to the sandbox domain and requests a slow-path lookup. · .

10· • Untranslated code:- If the translated ap-

'plication, code branches Lo untranslated code, an exception is triggered and the sandbox either translates the untranslated code and continues execution or faults._. : · Signals and exceptions: The sandbox in-

15 stalls special handlers^■ to catch all signals and excep^¬ tions. These handlers check the signal¹ or exception, resolve the original instruction pointer, check if. the sig- nal or exception is legit, and pass the information to the application..

20 . . , , · System calls: System calls trigger a

switch to the sandbox domain. A handler copies the arguments of the system call into the sandbox domain. If an •argument is a pointer to a data structure then . only the * pointer, is copied. The handler then checks the comb na-

25 tion of system call and parameters using a per- application policy. The system call is evaluated in the sandbox domain to protect from time of chock to time of use attacks by concurrent threads...

The shadow stack protects the application

30 from return-oriented programming attacks. The basic con- ■ cept : of the shadow stack keeps information about the ap^¬ plication stack frames in the sandbox domain . The shadow stack uses triples of pointers of return instruction pointer, translated return instruction pointer,^' and

35 stored application stack pointer. The advantage of. using triples is that the , stack .can be resynchronized if there, is, a mismatch'. If. the last translated function removed 2^'9 multiple, stack frames e.g., through exception handling then the reauthentication method^' can pop stack, frames on the shadow stack until the application stack pointer

'^" matches the stored stack pointer on the shadow stack, re- synchronizing . the shadow stack with: the application stack. Preferably, the different privilege level. of the sandbox domain naturally protects the shadow stack.

Figure 5. shows a diagram of a computer implemented architecture to securely execute an untrusted ap- plication AP according to an embodiment of the present invention. A secure loader 2 and a, sandbox 1 acting on an, application program AP and libraries reside in a trusted execution domain TED, Via a system call .policy 8 , the . "trusted execution domain TED communicates with a^' kernel 9 of the^' .operating system. . ^"

The following sections refer, to ; even further embodiments of the present invention:

Preferably, the sandbox either detects an illegal region that contains code when a "control flow in- struction" attempts to transfer control to a data, region or the kernel generates a protectiqn ·, -fault- if. the app l.i- . cation tries to write a code region. Preferably, the sandbox dynamically removes indirect control flow transfers- whenever possible to reduce the opportunities for jump-oriented programming. Preferably, the sandbox , uses per application system call, policies to protect . from re- maining attack vectors ., Preferably, data-based attacks and jump-oriented programming^' are' stopped whenever an illegal system call is. executed. Preferably, attacks

' against the sandbox are limited by protecting internal data. Preferably, all data structures, of the sandbox do^¬ main, (including the secure loader) . are write-protected during the execution of translated code.

The loader is a crucial., component of. the ap- plication as it can load and map new code into the run^¬ ning process. If the .sandbox provides a transparent and secure loader API then the . privilege to- map executable memory , regions can be abstracted into the trusted sandbox

• domain. The sandbox can control the^■application and limit the loading process to predefined libraries. The secure loader and the sandbox together. cooperate to. allow con-. trolled execution of untrusted programs . A, secure loader makes security a first class, concept: and ensures that the 'SFI system does^■ not allow any unchecked code to be executed. The user-space sandbox builds on the secure loader and subsequently dynamically checks for malicious code . . and ensures, that all control^' flow instructions ,of , the application adhere to an execution model ... The combination of the secure loader, and the: user-space sandbox' enables the safe execution of untrusted code_, in userspaco. --Code . injection attacks are stopped before any unintended code; ^' is executed. Furthermore, additional information provided by the loader can be used to support additional s^'ecurity properties, e.g., inlining of Procedure Linkage Table .^' calls reduces the: number of indirect. control flow trans- ■ fers and therefore limits jump-oriented _. attacks . This ap- proach implements a secure platform, for_: privileged appli-

^• cations and applications reachable over the network that . anticipates and confines security threats: from the beginning ^■'·^' _.'.

An extension of the secure loader can be used to implement a clear separation between the different shared objects. Privileges and permissions (e.g., specific system calls and parameters to the system calls) can be tuned and specified on a per-object bas_;is and are no longer enabled, for all parts of an. application.

Claims

Claims

l.-.A computer, implemented architecture to se^¬ curely execute an untrusted application relying on loader . functionalities comprising ,

• a secure loade (2) to dynamically load new code from external memory regions not part of the ap- plication (AP). during the execution process of the un- .. - trusted , application (AP) , ^'.^' ··^'

. ·- · a separate sandbox (1) with a translation element (BT) that dynamically translates and analyzes, code elements of the ; untrusted application .^' (AP) before the code elements are executed, ¹ .

• a trusted execution domain■ (TED), essentially owned by the user , of the untrusted application

^{' ' (AP )} ' ·,

• . an untrusted execution domain (USD) essen- tially owned by the user of the untrusted application (AP) with. lower memory access. and execution privileges than; the trusted _, execution domain (TED) , . ■ .^'■'·^'

characterized -in that the secure load r (1) ' and the sandbox (2) reside in the trusted execution do- main (TED) while, the untrusted application' (AP) resides in the untrusted execution .^'domain (UED)..

2. The computer implemented architecture, ac- . cording to claim _.1, further comprising a control flow an^¬ alyzer, preferably as part of the secure loader (2), which can analyze^' control-flow information, segment information and/or privilege information of the untrusted application · (AP) on basic-block level and provide this. Information to the sandbox (1)..

3. The computer, implemented architecture ac- cording to claim 1 or claim 2, , - ^{■ '■} - _. ^· 32 . ^■ .^■■ wherein the secure loader (2) is adapted to resolve addresses. of objects,, symbols and relocations for the sandbox ( 1 ) , and _. . . .

wherein the sandbox (1) is adapted to embed 5 the resolved addresses in the translated code.

4. The computer implemented architecture ^' according to claim 3,

wherein the. objects, symbols and relocations refer to dynamically shared objects (DSO) called from the 10. untrusted application (AP ) ..

5. The computer implemented architecture according to claim 3 or claim 4, ,-

^■* wherein the secure loader ( 2 ) is adapted to resolve imported symbols. -by checking the following scopes 15 one after the other: a) A. loader, scope containing . symbols • , that^' are exported by the. secure- loader ( 2 ) ; b) A local scope of a DSO. containing its own symbols and the symbols of all libraries./that the DSO depends on; c) A global scope encompassing all shared objects that are in an^' ini- 20 tial. set of objects loaded during a start-up of the ap- . plication (AP). or shared objects, that are Loaded at

runtime with a RTLD_ GLOBAL flag.

• . - 6. The computer implemented architecture according to any one of the preceding claims, - 25 _^ wherein the secure loader (2) is accessible

·^'' for the_. application (AP) only through a well-defined ap^¬ plication programming interface (API) preventing reading and writing . internal loader data.

, 7. The computer implemented architecture ac- 30 cording to any one' of .the -preceding claims,

wherein a functionality related to runtime configuration, debugging, backwards compatibility,_, access to loader internal data structures is absent in the secure loader ^' (2) . ^■ .₍ . ^{' '} .

35 · 8. The computer implemented architecture ac^¬ cording to■ any . one . of the preceding ·. claims , further com^¬ prising a policy enforcement module, preferably as part 33 ^■ _. . . ^{' '}, . of the sandbox (-1) that can enforce a security policy to the running untrusted application or code elements thereof, preferably by applying security guards that observe the integrity, with the information provided by the cori- trol flow analyzer.

9. The computer implemented architecture according to any .one. of the preceding claims,

wherein the sandbox (_.1) is adapted to intercept .all call instructions and to check for each instruc- tion _. if the call is a PLT call, arid

wherein the secure, loader (2) is adapted to resolve a static target address of a target of the PLT ' call and replace the original call and indirect jump of the PLT call by a translated^ call iristruction to the. re-^' solved target. _. ¹

10. The computer implemented architecture according to any one of the preceding claims, '

wherein the sandbox ( 1 ), comprises a protection guard for write-protecting all data of the trusted execution domain (TED) when code from the untrusted execution domain (UED) is executed.

11. The compute implemented architecture ac- ^". cording to any one of the preceding claims,

wherein:, the sandbox ( 1 )·-comprises a_. security guard for setting. a non-executable bit on all memory pages of the application (AP) .

12. The computer implemented architecture ac^¬ cording to any one of the. preceding claims,

wherein the sandbox (1) is adapted to use ad- dress space layout randomization, for allocating internal data structures at random addresses. - .

13. The computer implemented architecture according to any one of the preceding claims,

wherein the sandbox (1) comprises a privi- leged code stack for executing privileged code.

14. The computer implemented architecture, according_, to any one of the preceding claims, comprising , a sandbox stack (3) ,

an application stack ( 4 ) , . and an entry trampoline (TP) for handling a tran ' sition from translated -application code to. privileged ... 5. sandbox code . adapted to let_, an application stack (5) remain unchanged, to spill registers to a thread-local storage, area in the trusted execution domain (TED), to . swap the stack to. the sandbox stack (3),. and. to run code in the trusted execution domain_., (TED) by using the sand-0 box stack (3) to store. local information,

15. The computer implemented architecture according' to claim 14, comprising. .

an exit trampoline (TP) for returning from • the trusted execution domain. (TED) to the untrusted exe-5 cution domain (UE.D) adapted, to restore registers, to

switches .back to. the application stack (5), and to con- ' inue . he execution of the translated code.

16. The computer implemented architecture ac- cording to any one of the preceding claims, comprising0 a_, shadow stack- for protecting all addresses returned to the application stack (5) and for keeping in formation about :the application stack frames in the trusted execution domain (TED), including a_, return, instruction pointer, a translated return instruction point5 er, and a stored application stack pointer. '

17. A method to securely execute an untrust.ed , application on a; computer using the computer implemented architecture according to any of the claims 1, 2 or 8 comprising the steps of

0 · - running an initialization code on the se^¬ cure loader (2) and the sandbox ( 1 ) ,

.· the secure loader ( 2 ). passing a loaded code element of the untrusted application (AP) to the sandbox. (1) for translation, ensuring that all access to . loader ' functionalities is directed to the secure .loader :^'.(2)^', . ; ^" - ^{' ■'■ ■} _.·^{■■ '} • the secure loader. (2 ) giving control to the translated code element,

• the_. secure loader (2) controlling the correctness_, of requests it _. receives .from translated code el-

5 ements, ^'> - whereas the execution of the initializaion code is run at first. ^' _, ·^{" '} · .^' .

18. The method, of claim 17 using a computer ■ . implemented architecture of claim 2 or 8 further comp is- 0 ing steps where the secure loader (2) loads. the untrusted application (AP) or parts thereof into the untrusted^' execution domain (UED) _.and che control-flow analyzer provides the sandbox (1)_. with basic-block level information , . about control-flow,^■ segments and/or privileges. .

5 19. The method of claim 18. where the sandbox

(_.1) controls if the untrusted application (AP) follows the basic-block level information it receives from the control-flow analyzer and, stops or at least modifies the execution_. of the untrusted application if this is not the 0 case . . _. -

20. The. method according to any of the claims 17 to^' 19, where the secure loader (2) removes any refer^¬ ences or information about the trusted execution domain (TED), before it passes it to the un rusted application 5 . (AP) , .^'■ ; ^: _:

.21. A method to securely execute an untrusted - application on a computer, preferably by using the com-, puter implemented architecture according 'to any of the preceding claims, comprising the. steps of ^■' \ 0 · _. initializing a secure loader: (2) in a

trusted execution domain (TED) of a user^' space, -

• initializing a sandbox (1.)^' in the trusted execution domain (TED^"), . .

• the secure loader (2) resolving addresses 5 of Objects, symbols and/or relocations called by. the untrusted application (AP) , . ^' • the secure, loader (2) dynamically loading the Objects, symbols and/or relocations called by the un- trusted application (AP) and passing the loaded objects, symbols^' and/or relocations to the sandbox (1) for trans- lation, ^■· ' ,

^'· . the sandbox (2) embedding the resolved addresses in the translated code.

.22. The' method of claim 21,

wherein the execution^' of the initialization code is run at first, in particular wherein the secure, loader is initialized first and initializes the , sandbox second . , ^{; '} :

: _.23. Computer . program element comprising computer program code means for executing . a method according to any one of the preceding claims 17 to 22 when run on a processing . unit of a computer system.^" . ,

24.. Computer program medium having stored, the computer program element according to claim 23 on the medium.

- 25. Use of a computer implemented architec- . ture according to any one of the preceding claims 1 to 16 in. a computer system, and preferably in an operating sys- tern, of the^■ computer system.