issue-c3eee5436097c69985bd795524a5c0e092ebc25d.yaml

--- !ditz.rubyforge.org,2008-03-06/issue 
title: prevent access to internal properties even with buffer access
desc: |-
  (GH-44)
  
  The current internal property approach is not ideal for sandboxing untrusted
  code.  The sandbox must prevent user code from creating or using buffer
  values, because a buffer value can be used to construct a non-UTF-8 string
  which can then be used to access internal properties of objects.  Depending
  on the writability of the internal properties, this may or may not be a
  sandboxing security issue.
  
  This limitation is OK for sandboxing standard Ecmascript code which needs no
  access to buffer values at all.  But there are also sandboxed environments
  where buffer values need to be available.
  
  Not sure what's the best fix for this.  A few possibilities:
  
  - Deny access to internal properties from Ecmascript code even if the
    calling code uses an internal property name.  Internal properties would be
    non-readable and non-writable (e.g. attempt to read would return undefined
    and attempt to write would throw an error).
  
  - Deny access to internal properties from both C and Ecmascript code, unless
    accessed with an API call intended specifically for internal properties
    (equivalently, use a flag for this purpose).  This would prevent intentional
    or accidental access to internal properties both from C and Ecmascript code.
  
  - Deny buffer-to-string coercion which would result in a non-extended-UTF-8
    string.  This would prevent Ecmascript code from constructing internal
    property names (strings), but wouldn't prevent access if an internal
    property name was constructed by C code and leaked to Ecmascript code.
  
  Somewhat unrelated, an alternative to using a \xFF prefix would be to add a
  new non-standard "hidden" attribute to object properties.  A hidden property
  would behave like an internal property does now, but would not need to have
  a special form.  This cannot be implemented as a duk_hstring flag because a
  certain property name may be a hidden property in one object but not in
  another.
type: :task
component: duk
release: 
reporter: Sami Vaarala <sami.vaarala@iki.fi>
status: :unstarted
disposition: 
creation_time: 2014-09-12 08:50:09.871394 Z
references: []

id: c3eee5436097c69985bd795524a5c0e092ebc25d
log_events: 
- - 2014-09-12 08:50:10.207175 Z
  - Sami Vaarala <sami.vaarala@iki.fi>
  - created
  - ""