No abstract

It is well recognized that JavaScript can be exploited to launch browser-based security attacks. We propose to battle such attacks using program instrumentation. Untrusted JavaScript code goes through a rewriting process which identifies relevant operations, modifies questionable behaviors, and prompts the user (a web page viewer) for decisions on how to proceed when appropriate. Our solution is parametric with respect to the security policy-the policy is implemented separately from the rewriting, and the same rewriting process is carried out regardless of which policy is in use. Be-sides providing a rigorous account of the correctness of our solution, we also discuss practical issues including policy management and prototype experiments. A useful by-product of our work is an operational semantics of a core subset of JavaScript, where code embedded in (HTML) documents may generate further document pieces (with new code embedded) at runtime, yielding a form of self-modifying code.

No abstract

No abstract

No abstract

Extenszbzlzty can be based on cross-address-space communacatzon or on graflang applzcation-specafic modules znto the operatzng system For comparang both approaches, we need to explore the best achzeuable performance for both models Thzs paper reports the achzeved performance of cross-address-space communzcataon for the L4 p-kernel on Intel Pentium, Maps R4600 and DEC Alpha. The direct costs range from 45 cycles (Alpha) to 121 cycles (Pentaum). Since only 2.3% of the L I cache are requzred (Pentaum), the average zndzrect costs are not to be expected much higher 1 Motivation: extensibility "Extensibility" is a relatively new buzzword in OS research. Nevertheless, the requirement for extensibility i s neither specific tmo operating systems nor new. Editors are extended by macros associating new functions to keys, programming languages are extended by libraries, database systems are extended by applicationspecific functions, word processing systems are extended by customized texts, et cetera, et cetera.What makes extensibility an OS-specific topic? Security and safety! When extending an operating system by a new or modified service, we require that (a) the service can be introduced only for selected clients and that (b) a potential malfunction of the new service affects only those clients that use it. In accordance to (a), diffferent clients can, of course, use different services for the same event. (a) is difficult because the operating system controls central resources; (b) is difficult because (i) these resources are critical with respect to the correct functioning of the ent,ire system and (ii) services need to be protect,ed from each ot,her making uncont,rolled interference impossible.The multiple-server approach An obvious (and well-known) solut,ion: use mult>iple servers, protect them by classical operating syst,ern mechanisms, i.e. address spa.ces, and make t,hern freely att,achable t.0 applications. Basically, that is t,he pkernel approach, pioneered by Amoeba, Mach and Chorus. further developed by L4 [Liedtke 19951, Fluke [Ford et al. 19961 and others. This method i s best-suited to incorporat,e general. well-known software techniques for extensibility. Functionally, it, i s most flexible and most, genera.].However, good performance of the multiple-server technique requires that the direct and indirect cost,s of cross-address-space communication (including addressspace switching) are sufficiently low. Unfort,unately. years ago, IPC was considered to be expensive. The grafting approachA further solution i s to graft additional modules into the monolithic server (the operating system). Early applications of this technique are widely used but insecure and/or of limited flexibility: mounting new file systems, adding new device drivers et cetera.New research projects, in particular Spin [Bershad et al. 19951 and Vino [Seltzer et al. 19961 experiment with compile-time and run-time (compiler-supported) security for "grafted" kernel components. Spin [Bershad et al. 19951 inserts type-checked modules into the ...

No abstract

Abstract. The increasing software complexity and proliferation of distributed applications for cell phones demand the introduction of middleware services to assist in the development of advanced applications. However, from the user perspective, it is essential that these new phones provide a smooth error-free experience. Despite of the complexity underlying a cell phone, placing a phone call remains a simple task that can be performed by most users regardless of their technical background. Furthermore, cell phones rarely crash (especially compared to PCs) and carriers are able to correct certain problems remotely without user intervention. We advocate for a middleware infrastructure that allows carriers and developers to correct middleware behavior, configure it, and upgrade it, without requiring user intervention and without stopping the execution of applications. We introduce a new technique we refer to as externalization. This technique explicitly externalizes the state, the logic, and the internal component structure of middleware services. As a result, carriers and developers have full control over these middleware services. They can access, inspect, and modify the state, logic, and structure of middleware services at runtime while preserving the execution of existing applications and providing an error-free experience to users. We claim that externalization is the key for the future evolution of cell phones' middleware infrastructure.