Table Of Content(cid:0)
Language Issues in Mobile Program Security
(cid:0) (cid:1)
Dennis Volpano and Geo(cid:0)rey Smith
(cid:0)
Departmentof ComputerScience(cid:0) Naval Postgraduate School(cid:0) Monterey(cid:0) CA
(cid:1)(cid:2)(cid:1)(cid:3)(cid:2)(cid:0) USA(cid:0) email(cid:4) volpano(cid:5)cs(cid:6)nps(cid:6)navy(cid:6)mil
(cid:1)
School of ComputerScience(cid:0) Florida International University(cid:0)Miami(cid:0) FL (cid:2)(cid:2)(cid:7)(cid:1)(cid:1)(cid:0)
USA(cid:0) email(cid:4) smithg(cid:5)cs(cid:6)(cid:8)u(cid:6)edu
Abstract(cid:0) Manyprogramminglanguages havebeendevelopedandim(cid:9)
plemented for mobile code environments(cid:6) They are typically quite ex(cid:9)
pressive(cid:6) But while security is an important aspect of any mobile code
technology(cid:0) it is often treated after the fundamental design is complete(cid:0)
in ad hoc ways(cid:6) In the end(cid:0) it is unclear what security guarantees can
be made for the system(cid:6) We argue that mobile programming languages
should be designed around certain security properties that hold for all
well(cid:9)formed programs(cid:6) This requires a better understanding of the rela(cid:9)
tionship between programming language design and security(cid:6) Appropri(cid:9)
ate security properties mustbe identi(cid:8)ed(cid:6) Some of these properties and
related issues are explored(cid:6)
Anassortmentoflanguagesandenvironmentshavebeenproposedformobile
code(cid:1) Some have been designed for use in executable content and others for use
in agents (cid:2)(cid:3)(cid:4)(cid:5)(cid:6)(cid:7)(cid:8)(cid:1) Parallel e(cid:0)orts in extensible networks and operating systems
havealsofocusedattentiononlanguagedesignformobility(cid:1)Thesee(cid:0)ortsinclude
workonactivenetworks(cid:2)(cid:6)(cid:6)(cid:5)(cid:6)(cid:9)(cid:8)(cid:5)theSPINkernel(cid:2)(cid:10)(cid:5)(cid:3)(cid:11)(cid:8)andExokernel(cid:2)(cid:9)(cid:8)(cid:1)What
these e(cid:0)orts have in common is a need for security(cid:1)
We can roughly separate security concerns in this setting into code security
andhost security(cid:1)Theformerisconcernedwithprotectingmobilecodefromun(cid:12)
trusted hostswhile the latter is concernedwith protectinghosts fromuntrusted
mobilecode(cid:1)Thismayseemabitarti(cid:13)cialsinceonemightliketomodelsecurity
(cid:0)
more symmetrically(cid:1) Nonetheless(cid:5) it is a useful distinction for now(cid:1) The code
security problem seems quite intractable(cid:5) given that mobile code is under the
control of a host(cid:1) For some proposals and a discussion(cid:5) see (cid:2)(cid:10)(cid:4)(cid:5)(cid:10)(cid:14)(cid:5)(cid:7)(cid:15)(cid:8)(cid:1) In the
remainder of this paper(cid:5) we treat only the host security problem(cid:1)
(cid:0) Host Security
Our view of the problem is that mobile code is executed on a host which must
be protected from privacy and integrity violations(cid:1) As far as privacy goes(cid:5) the
(cid:0)
ThismaterialisbaseduponactivitiessupportedbyDARPAandtheNationalScience
FoundationunderAgreementNos(cid:6)CCR(cid:9)(cid:1)(cid:10)(cid:7)(cid:11)(cid:7)(cid:12)(cid:10) andCCR(cid:9)(cid:1)(cid:10)(cid:7)(cid:11)(cid:2)(cid:3)(cid:13)(cid:6) Toappearina
special issue of LNCSon Mobile Agents andSecurity(cid:6)
(cid:0)
Onecanimagineamodelthatdoesnotdistinguishmobilecodefromahost(cid:0)treating
both as mutuallysuspicious parties(cid:6)
Report Documentation Page Form Approved
OMB No. 0704-0188
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it
does not display a currently valid OMB control number.
1. REPORT DATE 3. DATES COVERED
1998 2. REPORT TYPE 00-00-1998 to 00-00-1998
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
Language Issues in Mobile Program Security
5b. GRANT NUMBER
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION
Naval Postgraduate School ,Center for Information Systems Security REPORT NUMBER
Studies and Research (NPS CISR),Department of Computer
Science,Monterey,CA,93943
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT
NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT
Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
Mobile Agents and Security, G. Vigna (Ed.), volume 1419 of Lecture Notes in Computer Science, pp. 25-43.
Springer Verag, 199
14. ABSTRACT
see report
15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF
ABSTRACT OF PAGES RESPONSIBLE PERSON
a. REPORT b. ABSTRACT c. THIS PAGE Same as 19
unclassified unclassified unclassified Report (SAR)
Standard Form 298 (Rev. 8-98)
Prescribed by ANSI Std Z39-18
host has private data that the code may need to perform some expected task(cid:1)
The host wants assurance that it can trust the code not to leak the private
data(cid:1) This is the classical view of privacy (cid:2)(cid:10)(cid:3)(cid:16)(cid:10)(cid:6)(cid:8)(cid:1) As for integrity(cid:5) the host has
information that should not be corrupted(cid:1) Integrity(cid:5) in general(cid:5) demands total
code correctness(cid:1) After all(cid:5) corrupt data can simply be the result of incorrect
code(cid:1) There are(cid:5) however(cid:5) weakerforms of integrity (cid:2)(cid:6)(cid:8)(cid:1)
We believe that an important characteristic of the mobile code setting is
that the only observable events are those that can be observed from within a
mobile program using language primitives and any host utilities(cid:1) There are no
meta(cid:12)level observers of a mobile program(cid:17)sbehavior such as a person observing
its execution behavior online(cid:1) Still(cid:5) depending on the language(cid:5) leaks can occur
in many di(cid:0)erent ways(cid:5) some being much more di(cid:18)cult to detect than others(cid:1)
(cid:0)(cid:1)(cid:0) Security Architectures
A common approach to host security is to monitor the execution of mobile
code(cid:1) You build an interpreter (cid:19)or virtual machine(cid:20) and slap the hands of any
code that tries to touch something sensitive(cid:1) The interpreter obviously needs
to know whether hand slapping is in order so it might appeal to some sort of
trust framework to decide(cid:1) This arrangement is often called a (cid:21)security archi(cid:12)
tecture(cid:22)(cid:1) Architecturesaregrowingquite elaborateasthe demand for lesshand
slapping rises(cid:1) An example is the security architecture of the Java Developer(cid:17)s
Kit JDK(cid:3)(cid:1)(cid:10) (cid:2)(cid:3)(cid:3)(cid:8)(cid:1) It blends some proven concepts(cid:5) such as protection domains(cid:5)
access control(cid:5) permissions(cid:5) and code signing(cid:5) to allow applets more room to
maneuver(cid:1) Netscape(cid:17)s (cid:21)Object Signing Architecture(cid:22) takes a similar approach(cid:1)
One begins to wonder how much of these security architectures is really
necessary(cid:1)Aretheyaresponsetoaneedforhostsecuritygivenmobileprograms
written in a poorly(cid:12)designed mobile programming language(cid:23) Perhaps they can
be simpli(cid:13)ed(cid:1) It would seem that this is possible if mobile code is written in a
language that ensures certain security properties statically(cid:1)
For example(cid:5) suppose that all well(cid:12)typed programs have a secure (cid:24)ow prop(cid:12)
erty and that you know a certain program(cid:5) needing your personal identi(cid:13)cation
number (cid:19)PIN(cid:20)(cid:5) is indeed well typed(cid:1) Then that program respects the privacy of
your PIN and there is no need to check at runtime whether the program has
permission to read it(cid:1)
Our claim is not that security architectures will no longer have a role in
the future(cid:1) We feel their role will simply change and be more formally justi(cid:13)ed(cid:1)
For example(cid:5) they might carry out certain static analyses or proof checking(cid:5)
perhaps along the lines of proof(cid:12)carrying code (cid:2)(cid:10)(cid:11)(cid:8)(cid:1) It should be possible(cid:5) for
a given language(cid:5) to more clearly identify the role of the security architecture(cid:1)
Certain desirable properties might be provable for all well(cid:12)formed programs in
the language(cid:5) in which case some security checks can go away(cid:1)
There are many di(cid:0)erent facets of mobile language design that in(cid:24)uence
security in some way(cid:1) For example(cid:5) access control mechanisms (cid:19)encapsulation(cid:5)
visibility rules(cid:5) etc(cid:1)(cid:20) are important(cid:1) We will limit our attention to some of the
issues that impact host privacy and integrity(cid:1) On the integrity side(cid:5) we look at
(cid:10)
type safety(cid:1) Type safety is often said to be a key ingredient for security in Java
andforsafekernelextensionswritteninModula(cid:12)(cid:6)(cid:2)(cid:10)(cid:8)(cid:1)Today(cid:5)somelanguageslike
Standard ML evolve with formal treatments of the type system and semantics
developed along the way(cid:1) This allows one to give formal accounts of type safety
thatevolveaswell(cid:1)Otherlanguages(cid:5)likeJava(cid:5)lackthissortofformaltreatment(cid:1)
Java has grown so rapidly that one quickly loses grasp of the impact of certain
features on key properties like type safety(cid:1)
Thenweexploretherelationshipbetweenprivacyandlanguagedesign(cid:1)There
aremanywaysmobilecodecanleaksecrets(cid:1)Westartbyexamininginformation
channels in a deterministic language(cid:1) We look at how they are in(cid:24)uenced by
timing(cid:5) synchrony(cid:5) and nontermination(cid:1) Then we consider channels in a simple
concurrent languagewith shared variables(cid:1) Some of these channels arise in very
subtle ways(cid:1) For example(cid:5) they can arise from contention among processes for
shared resources(cid:5)like CPU cycles(cid:1)
(cid:1) Type Safety
Whatistypesafety(cid:23)ConsiderthefollowingdescriptionfromaJavaperspective(cid:25)
The Java language itself is designed to enforce security in the form of
typesafety(cid:1)Thismeansthecompilerensuresthatmethodsandprograms
donotaccessmemoryinwaysthatareinappropriate(cid:19)i(cid:1)e(cid:1)dangerous(cid:20)(cid:1)In
e(cid:0)ect(cid:5) this is the most essential part of the Java security model in that
it fundamentally protects the integrity of the memory map(cid:1)
Secure Computing with Java(cid:0) Now and the Future(cid:1)
(cid:2)(cid:3)(cid:3)(cid:4) JavaOne Conference(cid:5)
InJava(cid:5)forexample(cid:5)codeshouldnotsomehowbeabletocoerceareferenceofa
user(cid:12)de(cid:13)nedclassto one ofasystem classlikeSecurityManagerwhich therun(cid:12)
time system (cid:19)Java Virtual Machine(cid:20) consults for access permissions(cid:1) Obviously(cid:5)
this leads to trouble(cid:1)
So at the heart of type safety is a guarantee against misinterpretation of
data(cid:26)some sequence of bits being misinterpreted by an operation(cid:1) This has
long been recognized as a serious computer security problem(cid:1) In a well(cid:12)known
reportpublished twenty(cid:12)(cid:13)veyearsago(cid:5)Andersondescribesawaytopenetratea
time(cid:12)sharingsystem(cid:19)HIS(cid:14)(cid:6)(cid:4)(cid:27)GCOSIII(cid:20)basedontheabilitytoexecuteauser(cid:17)s
arraycontentswith an assignedGOTOstatementinFortran(cid:2)(cid:3)(cid:8)(cid:1)The statement
can misinterpret its target(cid:5) the contents of an arbitrary integer variable(cid:5) as an
instruction(cid:1) Today we see the same sort of problem in a di(cid:0)erent context (cid:2)(cid:10)(cid:28)(cid:8)(cid:1)
(cid:2)(cid:1)(cid:0) Type Preservation
An important property related to type safety is the idea of type preservation(cid:1)
Type preservation is frequently confused with type soundness in the literature(cid:1)
Soundness is a statement about the progressa program(cid:17)sexecution can makeif
(cid:6)
the programis well typed(cid:1) Typepreservation(cid:5)on the otherhand(cid:5) merelyasserts
that if a well(cid:12)typed program evaluates successfully(cid:5) then it produces a value of
the correcttype(cid:1) It isusually needed to provesoundness(cid:1)Forinstance(cid:5) youmay
know that an expression(cid:5) with some type(cid:5) evaluates to a value(cid:5) but the value
must have a speci(cid:13)c form in order for evaluation to proceed(cid:1) Type preservation
gives you that the value has the same type as the expression(cid:5) and with some
correctformstyping lemma(cid:5) youknow thatonly values ofthe formneededhave
that type(cid:1)
Thefollowing isa typicaltype preservationtheorem(cid:1) If (cid:0) isamemory(cid:5)map(cid:12)
ping locations to values(cid:5) and (cid:1) is a location typing(cid:5) mapping locations to types(cid:5)
then type preservation is stated as follows (cid:2)(cid:3)(cid:14)(cid:8)(cid:25)
(cid:0)
Theorem(cid:1) (cid:19)Type Preservation(cid:20)(cid:1) If (cid:0) (cid:0) e (cid:1) v(cid:2)(cid:0)(cid:5) (cid:1) (cid:0) e (cid:25) (cid:3)(cid:5) and (cid:0) (cid:25) (cid:1)(cid:5) then
(cid:0) (cid:0) (cid:0) (cid:0) (cid:0)
there exists (cid:1) such that (cid:1)(cid:2)(cid:1)(cid:5) (cid:0) (cid:25)(cid:1)(cid:5) and (cid:1) (cid:0)v (cid:25)(cid:3)(cid:1)
The(cid:13)rsthypothesisofthetheoremstatesthatundermemory(cid:0)(cid:5)aclosedexpres(cid:12)
(cid:0)
sioneevaluatestoavaluev andamemory(cid:0)(cid:1)Nowemaycontainfreelocations(cid:5)
hence e is typed with respect to a location typing (cid:1) which must be consistent
with (cid:0)(cid:5) that is(cid:5) (cid:0) (cid:25) (cid:1)(cid:1) Evaluation of e can produce new locations that wind up
(cid:0)
in v(cid:5) so v is typed with respect to an extension (cid:1) of (cid:1)(cid:1)
As one can clearly see from the theorem(cid:5) whether a language exhibits this
propertydependsonthetypesystemandthesemantics(cid:1)Insomecases(cid:5)wemight
expect that the type system needs to change if the property does not hold(cid:1) But
the semantics itself may be to blame(cid:1) For instance(cid:5) consider the C program in
Figure(cid:3)(cid:1)Whencompiledandexecuted(cid:5)(cid:0)cevaluatestoasignedintegerquantity(cid:5)
char (cid:0)c(cid:1)
f(cid:2)(cid:3) (cid:4)char cc (cid:5) (cid:6)a(cid:6)(cid:1) c (cid:5) (cid:7)cc(cid:1)(cid:8)
g(cid:2)(cid:3) (cid:4)int i (cid:5) (cid:9)(cid:10)(cid:10)(cid:1)(cid:8)
main(cid:2)(cid:3) (cid:4)f(cid:2)(cid:3)(cid:1) g(cid:2)(cid:3)(cid:1) printf(cid:2)(cid:11)(cid:12)c(cid:11)(cid:13)(cid:0)c(cid:3)(cid:1)(cid:8)
Fig(cid:0)(cid:1)(cid:0)Dereferencing a dangling pointer
yet it has type char(cid:1) If a C semantics prescribes this behavior(cid:5) then we cannot
provetypepreservationwith respecttothat semantics(cid:29)theClanguagesaysthis
program is unpredictable(cid:1) This is one place where type preservation and C col(cid:12)
(cid:1)
lide(cid:1) A formal C semantics should be clear about the outcome of dereferencing
adanglingpointer(cid:5) if this isconsidered(cid:21)normal(cid:22)execution(cid:5) sothat typepreser(cid:12)
vation can be proved(cid:1) Otherwise(cid:5) it should specify that execution gets stuck in
thissituation(cid:5)againsothattypepreservationholds(cid:1)Inthelattercase(cid:5)animple(cid:12)
mentationofCwould be requiredtodetectsuchanerroneousexecutionpointif
thatimplementationweresafe(cid:1)Asafe(cid:19)faithful(cid:20)implementationguaranteesthat
every execution is prescribed by the semantics(cid:5) so that programs cannot run in
(cid:1)
Thus(cid:0) perhaps(cid:0) it is not surprising that the SPIN group abandoned its attempts to
de(cid:8)ne a (cid:14)safe subset of C(cid:15)(cid:0) adopting Modula(cid:9)(cid:2) instead (cid:16)(cid:11)(cid:17)(cid:6)
(cid:7)
ways not accounted for by the semantics(cid:1) This usually requires that an imple(cid:12)
mentation do some runtime type checking unless it can be proved unnecessary
by a type soundness result(cid:1)
Remark(cid:1) Although a lack of pointer expressiveness is in general a good thing
from a safety viewpoint(cid:5) manifest pointers (cid:19)references(cid:20) are still a substantial
security risk(cid:1)A runtime system might accidentallyprovide an applicationa ref(cid:12)
erencetoasystem securityobjectthat mustremaininvariant(cid:1)This wasdemon(cid:12)
stratedinJavaforJDK(cid:3)(cid:1)(cid:3)(cid:1)Its entiretrust framework(cid:5)basedondigitally(cid:12)signed
code(cid:5) was undermined when it was discovered that applications could obtain a
(cid:2)
reference to a code signers array(cid:1)
(cid:2)(cid:1)(cid:2) Type Soundness
Typepreservationtheoremsusuallytalkaboutsuccessfulevaluations(cid:1)Theirhy(cid:12)
pothesesinvolveanassumptionaboutanevaluationproceedinginsomenumber
of steps to a canonical form(cid:1) But this may not adequately address a type sys(cid:12)
tem(cid:17)sintentions(cid:1)Anobjectiveofasystem mightbetoguaranteeterminationor
to ensure that programs terminate only in speci(cid:13)ed ways (cid:19)e(cid:1)g(cid:1) no segmentation
(cid:3)
violations(cid:20)(cid:1) What is needed is a precise account of how a well(cid:12)typed program
can behave when executed(cid:1) In other words(cid:5) we want a type soundness theorem
that speci(cid:13)es all the possible behaviors that a well(cid:12)typed program can exhibit(cid:1)
Traditional type soundness arguments based on showing that a well(cid:12)typed
program does not evaluate to some special untypable value are inadequate for
languages like C and Java(cid:1) There are many reasons why programs written in
languages like Java and C may produce runtime errors(cid:1) Invalid class formats
in Java and invalid pointer arithmetic in C are examples(cid:1) A type soundness
theorem should enumerate all the errors that cause a well(cid:12)typed program to
get stuck (cid:19)abort(cid:20) according to the semantics(cid:1) These are the errors that every
safe implementation must detect(cid:5) One regards the type system as sound if none
of these errors is an error that we expect the type system to detect(cid:1) This is
essentially the traditional view of type soundness as a binary property(cid:1) But a
key point to keep in mind is that whether a given type system is sound really
dependsonourexpectationsofthetypesystem(cid:1)Thoughitmaybeclearwhatwe
expect for languages like Standard ML(cid:5) it is less clear for lower(cid:12)level languages
like C and assembler(cid:1)
Forexample(cid:5)wegiveatypesystemforapolymorphicdialectofCin(cid:2)(cid:6)(cid:15)(cid:5)(cid:6)(cid:10)(cid:8)(cid:1)
Thetype soundnesstheorem basicallysaysthat executing awell(cid:12)typedprogram
either succeeds(cid:5)producingavalueofthe appropriatetype(cid:5) fails toterminate(cid:5)or
gets stuck because of an attempt to
(cid:2)
Itisinterestingtoconsiderwhatsortofproofwouldhaverevealedtheproblem(cid:6)One
strategy would be to try (cid:8)ndinga P(cid:9)time reduction from compromising the private
key used in a digital signature to executing untrusted code(cid:6) It would also establish
a computational lower boundon executinguntrustedcode using JDK(cid:7)(cid:6)(cid:7)(cid:6)
(cid:3)
Suchproperties are important in situations where you need guarantees against cer(cid:9)
tain faults(cid:6) Anexampleis isolating execution behindtrust boundaries (cid:16)(cid:7)(cid:12)(cid:17)(cid:6)
(cid:4)
(cid:3) access a dead address(cid:5)
(cid:3) access an address with an invalid o(cid:0)set(cid:5)
(cid:3) read an uninitialized address(cid:5) or
(cid:3) declare an empty or negative(cid:12)sized array(cid:1)
The(cid:13)rsttwoerrorsareduetopointersinthelanguage(cid:1)Nowonemayexpectthe
type system to detect the (cid:13)rst error in which case our type system is unsound(cid:1)
However(cid:5)if one believes it is beyond the scope of a type system for C(cid:5) then our
type system is sound(cid:1) Clearly if the list included an errorsuch asan attempt to
applyanintegertoaninteger(cid:5)thenthetypesystemwouldgenerallyberegarded
as unsound(cid:1)
A better way to look at type soundness is merely as a property about the
executions ofprogramsthat the typesystem saysareacceptable(cid:1)Thisallowsus
tocomparetypesystemsforalanguagebycomparingtheirsoundnessproperties(cid:1)
Some may be weakerthan others in that they requireimplementations to check
typesatruntimeinordertoremainsafe(cid:1)Itisalsousefulfordeterminingwhether
a particular language is suitable for some application(cid:1) Some of the errors listed
in a formulation of soundness may be among those that an application cannot
tolerate(cid:1) Further(cid:5) and perhaps most importantly(cid:5) it identi(cid:13)es those errors that
an implementation must detect in order to safely implement the semantics(cid:1) For
instance(cid:5) a safe implementation of C should trap any attempt to dereference a
danglingpointer(cid:1)MostCimplementationsareunsafeinthisregard(cid:1)Oneexpects
Java implementations to be safer(cid:5) but despite all the attention to typing and
bytecode veri(cid:13)cation(cid:5) the current situation is unfortunately not as good as one
might imagine(cid:1)
(cid:4)
Consider the Java class in Figure (cid:10)(cid:1) The class modi(cid:13)es itself by putting
a CONSTANT Utf(cid:1) type tag for x in that part of the constant pool where a
CONSTANT String type tag for x is expected by the ldc (cid:19)load from constant
pool(cid:20) instruction(cid:1) Method exec gets a copy of itself in the form of a bytecode
array(cid:1)Theclassiswelltyped(cid:5)yetitabortswitha(cid:21)segmentationviolation(cid:22)(cid:19)core
dump(cid:20) in JDK(cid:3)(cid:1)(cid:3)(cid:1)(cid:3)(cid:5) evenwhen Java is run in (cid:21)verify(cid:22)mode(cid:1) Veri(cid:13)cation of the
modi(cid:13)edbytecodesdoesfailusingtheverifyoptionoftheJavaclassdisassembler
javap(cid:1)Onewouldexpectittoalsofailforthebytecodesdynamicallyconstructed
in exec(cid:5) leading to a VerifyErrorwhen class SelfRefis run(cid:1) Instead we get a
core dump(cid:1) So the JDK(cid:3)(cid:1)(cid:3)(cid:1)(cid:3) implementation of Java is unsafe(cid:1)
Perhaps making class representations available in bytecode form needs to
be reconsidered(cid:1) It becomes quite easy to dynamically construct classes that
aredi(cid:18)cult toanalyzestaticallyfor securityguarantees(cid:1)Self(cid:12)modifying code(cid:5) in
general(cid:5) makes enforcement of protection constraintsdi(cid:18)cult(cid:5) if not impossible(cid:1)
Channel command programs in the M(cid:1)I(cid:1)T(cid:1) Compatible Time(cid:12)Sharing System
(cid:19)CTSS(cid:20)(cid:5) for instance(cid:5) were years ago prohibited from being self(cid:12)modifying for
this reason (cid:2)(cid:10)(cid:9)(cid:8)(cid:1)
(cid:4)
Abitofhistory(cid:6)Theclassstemsfromanattempttoimplementanactivenetworkin
Java(cid:6) Active programs migrate among servers that invoke their exec methods(cid:6) An
active program maintains state by modifying its own bytecode representation prior
to being forwarded(cid:6) Yes(cid:0) it(cid:18)s a hack(cid:6)
(cid:14)
public class SelfRef implements ActiveProgram (cid:4)
final String x (cid:5) (cid:11)aaba(cid:11)(cid:1)
public void exec(cid:2)byte(cid:14)(cid:15) b(cid:13) MyLoader loader(cid:3) throws Exception (cid:4)
if (cid:2)b(cid:14)(cid:16)(cid:17)(cid:15) (cid:5)(cid:5) (cid:18)x(cid:18)(cid:19)(cid:3) (cid:4) (cid:20)(cid:20) CONSTANT(cid:21)String
b(cid:14)(cid:16)(cid:17)(cid:15) (cid:5) (cid:18)x(cid:18)(cid:16)(cid:1) (cid:20)(cid:20) set CONSTANT(cid:21)Utf(cid:19)
b(cid:14)(cid:16)(cid:22)(cid:15) (cid:5) (cid:18)x(cid:18)(cid:18)(cid:1)
b(cid:14)(cid:16)(cid:23)(cid:15) (cid:5) (cid:18)x(cid:18)(cid:18)(cid:1)
Class classOf (cid:5) loader(cid:24)defineClass(cid:2)b(cid:13) (cid:18)(cid:13) b(cid:24)length(cid:3)(cid:1)
ActiveProgram p (cid:5) (cid:2)ActiveProgram(cid:3) classOf(cid:24)newInstance(cid:2)(cid:3)(cid:1)
p(cid:24)exec(cid:2)b(cid:13) loader(cid:3)(cid:1)
(cid:8)
else System(cid:24)out(cid:24)println(cid:2)x(cid:3)(cid:1)
(cid:8)
public static void main(cid:2)String(cid:14)(cid:15) argv(cid:3) throws Exception (cid:4)
FileInputStream f (cid:5) new FileInputStream(cid:2)(cid:11)SelfRef(cid:24)class(cid:11)(cid:3)(cid:1)
byte(cid:14)(cid:15) data (cid:5) new byte(cid:14)f(cid:24)available(cid:2)(cid:3)(cid:15)(cid:1)
int c (cid:5) f(cid:24)read(cid:2)data(cid:3)(cid:1)
MyLoader loader (cid:5) new MyLoader(cid:2)(cid:3)(cid:1)
new SelfRef(cid:2)(cid:3)(cid:24)exec(cid:2)data(cid:13) loader(cid:3)(cid:1)
(cid:8)
(cid:8)
Fig(cid:0)(cid:2)(cid:0) Typemismatchleading to segmentation violation in Java
(cid:2) Privacy in a Deterministic Language
Suppose we begin by considering a very simple deterministic programming lan(cid:12)
guage with just variables(cid:5) integer(cid:12)valued expressions(cid:5) assignment(cid:5) conditionals(cid:5)
while loops(cid:5) and sequential composition(cid:1) Programs are executed relative to a
memorythat maps variables to integers(cid:1)If a programneeds I(cid:27)O(cid:5) then it simply
reads from or writes to some speci(cid:13)c variables of the memory(cid:1) Further(cid:5) suppose
thatsomevariablesofthememoryareconsideredprivatewhileothersarepublic(cid:1)
Every program is free to use all variables of the memory and also knows which
variables are public and which are private(cid:1)
What concernsus is whether some program(cid:5)in this rather anemic language(cid:5)
canalways produce(cid:5)inapublicvariable(cid:5)thecontentsofaprivatevariable(cid:1)There
are many such programs(cid:5) some more complicated than others(cid:1)
For instance(cid:5) one can simply assign a private variable to a public one(cid:5) not a
terribly clever strategy for a hacker(cid:1) This is an example of an explicit channel(cid:1)
Oronemighttrytodoitmoreindirectly(cid:5)onebitatatime(cid:5)asinFigure(cid:6)where
PIN is private(cid:5) y is public(cid:5) and the value of mask is a power of two(cid:1) This is an
example of an implicit channel(cid:1) It illustrates the kind of program we wish to
reject because it does not respect the privacy of PIN(cid:1) We need to formalize the
security property it violates(cid:1)
(cid:11)
while (cid:2)mask (cid:25)(cid:5) (cid:18)(cid:3) (cid:4)
if (cid:2)PIN (cid:7) mask (cid:25)(cid:5) (cid:18)(cid:3) (cid:4) (cid:26)(cid:26) bitwise (cid:6)and(cid:6)
y (cid:27)(cid:5) y (cid:28) mask (cid:26)(cid:26) bitwise (cid:6)or(cid:6)
(cid:8)
mask (cid:27)(cid:5) mask (cid:20) (cid:29)
(cid:8)
Fig(cid:0)(cid:3)(cid:0)Implicitchannel
(cid:4)(cid:1)(cid:0) Privacy Properties
We give a more formal statement of the privacy property we want programs to
have in this simple deterministic language(cid:25)
De(cid:5)nition(cid:1) (cid:19)Termination Security(cid:20)(cid:1) Suppose that c is a command and (cid:0) and
(cid:0) (cid:0)
(cid:4) are memories that agree on all public variables(cid:1) If (cid:0)(cid:0)c(cid:1)(cid:0) and (cid:4) (cid:0)c(cid:1)(cid:4) (cid:5)
(cid:0) (cid:0)
then (cid:0) and (cid:4) agree on all public variables(cid:1)
(cid:0)
(cid:19)The judgment (cid:0) (cid:0) c (cid:1) (cid:0) asserts that executing command c in initial mem(cid:12)
(cid:0)
ory(cid:0)terminatessuccessfully(cid:5)yielding(cid:13)nalmemory(cid:0)(cid:1)(cid:20)Intuitively(cid:5)Termination
Security says that we can change the contents of private variables without in(cid:12)
(cid:24)uencing the outcome of public variables(cid:1) In other words(cid:5) these changes cannot
interferewiththe(cid:13)nalcontentsofpublicvariables(cid:1)Theaboveprogramdoesnot
have this property(cid:1) Any change in the private PIN will result in a di(cid:0)erent (cid:13)nal
value for the public variable y(cid:1)
IstheTerminationSecuritypropertyanacceptableprivacypropertyforpro(cid:12)
gramsinoursimpledeterministiclanguage(cid:23)Thatdependsonwhatisobservable(cid:1)
ConsiderthesimilarprograminFigure(cid:7)(cid:1)Ifonecanrepeatedlyrunthisprogram
while (cid:2)PIN (cid:7) mask (cid:5)(cid:5) (cid:18)(cid:3) (cid:4) (cid:8)
y (cid:27)(cid:5) y (cid:28) mask
Fig(cid:0)(cid:4)(cid:0) Channel fromnontermination
with a di(cid:0)erent mask(cid:5) one for each bit of PIN(cid:5) then assuming y is initially zero(cid:5)
therunswillcopyPINtoy(cid:1)OnePINbitisleakedtoyinasinglerun(cid:1)Weassume
that(cid:5) after a speci(cid:13)c period of time(cid:5) if a run has not terminated then it never
(cid:5)
will(cid:5) and we move on to the next bit(cid:1)
But although the program seems insecure(cid:5) it satis(cid:13)es Termination Security(cid:1)
ChangestoPINcannotin(cid:24)uencetheoutcomeofyinasinglerunoftheprogram(cid:1)
AfterchangingthePIN(cid:5)theprogrammaynolongerterminate(cid:5)butthisdoesnot
violate Termination Security since it only applies to successful termination(cid:1)
Consider another property(cid:25)
(cid:5)
The task obviously becomes mucheasier when we enrichthe language with threads
and a clock(cid:6) Now each bit can be examined by an asynchronously(cid:9)running thread(cid:0)
and after some timeout we can be fairly con(cid:8)dent that all nonzero bits have been
properly set in y(cid:6)
(cid:9)
De(cid:5)nition(cid:1) (cid:19)O(cid:30)ine Security(cid:20)(cid:1) Suppose that c is a command and (cid:0) and (cid:4) are
(cid:0) (cid:0)
memories that agree on all public variables(cid:1) If (cid:0) (cid:0) c (cid:1) (cid:0)(cid:5) then there is a (cid:4)
(cid:0) (cid:0) (cid:0)
such that (cid:4) (cid:0)c(cid:1)(cid:4) (cid:5) and (cid:4) and (cid:0) agree on all public variables(cid:1)
Notice that we have removed one of the two successful evaluation hypotheses
from Termination Security(cid:1) The property basically says that changing private
variables cannot interfere with the (cid:13)nal contents of public variables(cid:5) nor can
it interfere with whether a program terminates(cid:1) We call the property O(cid:30)ine
Security because it addresses only what one can observe about a program(cid:17)s
behaviorif it is executed o(cid:30)ine(cid:5) orin batch mode (cid:19)one either sees the results of
asuccessfulexecutionorisnoti(cid:13)edofsometimeoutthatwasreached(cid:20)(cid:1)Thetime
it takesfora programtoterminateis not observed(cid:1)In adeterministic language(cid:5)
O(cid:30)ineSecurityimpliesTerminationSecurity(cid:1)Actually(cid:5)theformulationofO(cid:30)ine
Securityis suitablefortreatingnondeterminism asweshallsee(cid:1)Theprogramin
Figure (cid:7) does not satisfy O(cid:30)ine Security(cid:1)
Unfortunately(cid:5) there are other sources of channels(cid:1) Consider the program
in Figure (cid:4)(cid:1) Again suppose we can repeatedly execute it with di(cid:0)erent masks(cid:1)
if (cid:2)(cid:16) (cid:20) (cid:2)PIN (cid:7) mask(cid:3)(cid:3) (cid:4) (cid:8)
y (cid:27)(cid:5) y (cid:28) mask
Fig(cid:0)(cid:5)(cid:0) Channel frompartial operation
It always terminates(cid:5) sometimes abnormally from division by zero(cid:1) The e(cid:0)ect(cid:5)
however(cid:5) will be the same(cid:5) to copy PIN to y one bit at a time(cid:1)
Henceifweincludepartialoperationslikedivision(cid:5)wehaveasituationwhere
aprogrammighteithergetstuck(cid:19)terminateabnormally(cid:20)orrunforever(cid:5)depend(cid:12)
ingonaprivatevariable(cid:1)Soweneedyetastrongero(cid:30)inesecurityproperty(cid:1)Ba(cid:12)
sicallyitneedstoextendO(cid:30)ineSecuritywith thecondition thatifcterminates
abnormally under (cid:0)(cid:5) then it does so under (cid:4) as well (cid:2)(cid:6)(cid:4)(cid:8)(cid:1)
Noneoftheprecedingpropertiesaddressesanydi(cid:0)erenceinthetime required
to run a program under two memories that can disagree on private variables(cid:1)
These di(cid:0)erences can be used to deduce values of private variables in timing
attacks on cryptographic algorithms(cid:1) For example(cid:5) a private key used in RSA
modularexponentiationhasbeendeducedinthisfashion(cid:2)(cid:10)(cid:15)(cid:8)(cid:1)Di(cid:0)erencesintim(cid:12)
ingundertwomemoriescanberuledoutbyrequiringthatexecutionsunderthe
two memories proceed in lock step(cid:5) a form of strong bisimilarity(cid:1) This property(cid:5)
which might be called Online Security(cid:5) is the most restrictive thus far(cid:1) But is it
really necessaryfor mobile programs(cid:23) That depends on what is observable(cid:1)
(cid:4)(cid:1)(cid:2) What is Observable(cid:6)
Key to judging whether any of the preceding properties is necessary is deter(cid:12)
mining what is observablein the model(cid:1) Whether a privacy propertyis suitable
depends on how it treats observable events(cid:1) Notice that there is an observation
(cid:28)
