[e-lang] Bug: Non-composability of __getPropertySlot

[Karp, Alan H]

MarkM wrote:
> 
> The key to reducing cases is to have the result of
> expansion/translation, no matter what the declared version, be fed
> into the Kernel-E AST evaluator, and to have that evaluator itself be
> openly available. The declared version of source would only affect how
> it expands to Kernel-E ASTs on a given version of E. Once expanded,
> none of the further processing would be version dependent. By making
> the evaluator itself openly accessible, if there's an security
> vulnerability in the evaluator, it can be exploited anyway. Therefore,
> there's no loss of security by putting these translating front-ends in
> front of the evaluator.
> 
I agree with this solution to the problem.  I'd just like to explain a
bit about the vulnerability I was worried about.  My knowledge of E
comes from the discussion with MarkM, so misundertandings are likely.

There are two steps involved in handling an imported object that concern
me.  There is a version dependent expansion to Kernel-E and a version
independent Kernel-E AST evaluator.  The expander is supposed to reject
illegal E code.  However, due to a flaw, it might pass such a program.
That program might be able to exploit a flaw in the Kernel-E AST
evaluator.  This threat is always present, but there are more
opportunities if the expander relies on the version reported by the
programmer of the object been expanded.  If the Kernel-E AST evaluator
is directly accessible, a malicious programmer could produce the
Kernel-E that the faulty expander would have created.  Hence, there is
no added vulnerability from relying on the version number when
expanding.  

_________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories 
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 423 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/e-lang/attachments/20060725/be683b1c/attachment.vcf