Luring Attack

External pointers to “Luring attack”: SetScopePermission; What is a luring attack?
External pointers to “Stack introspection”: Extensible Security Architectures for Java, The Evolution of Java Security

Quoting Jim Roskind

We define a “luring attack” as an attack where trusted code (with power or information) is unwittingly directed (due to deception or confusion induced by the attacker) to make a call into an attacker’s code fragment.

The danger with this scenario seems to stem from the implicit assumption that the called routine acquires the authority of its caller. The authority stemming from values of variables and parameters does not flow to the subroutine. However the ambient authority controlled by the stack introspection described in Extensible Security Architectures for Java indeed defaults to just such acquisition.

When authority instead follows Algol60’s scoping rules there is no Luring attack. The subroutine does not have access to the local variables of its caller. The authority is just the collection of values (object references) that may be named in the code and this does not generally include that of the caller. These local variables can hold procedure values that are inaccessible to the subroutine.

These properties of Algol 60 hold for most block structured languages that use lexical scoping. They hold for Java as well. While it may feel unconventional for authority for “system things” to be accessible via language scope rules, these rules are themselves familiar to anyone who has written substantial code in block structured languages. It is not an alien paradigm! More parameters are passed but fewer calls are made to routines such as enablePrivilege, disablePrivilege, checkPrivilege. Only experience can convince that authority passed this way can be used to build efficient systems. Keykos is such a system.

Some have noted overriding of Java’s System.out in Luring attacks. Code in a class with non final methods is at risk of having those methods redefined and thus changing the meaning of call sites to that method. This is not a necessarily fatal language feature but is surely error prone. The default, not final, is the dangerous case. Even here if there were no ambient authority the only mischief would be to steal the argument, or throw a confusing exception.

I take stack introspection to be as described in Extensible Security Architectures for Java which describes both MSIE & Netscape approaches. They refer to an unspecified “policy engine” which knows some space of potential targets for which two predicates are defined: enable and forbid. Already the idea that there is a single engine that must be configured raises the issue of “Who configures it?”, there being more than one stake holder within the machine. Perhaps such an engine can arrange for negotiated and mutually agreeable policy.