mirror of https://github.com/svaarala/duktape.git
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
54 lines
2.4 KiB
54 lines
2.4 KiB
--- !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
|
|
- ""
|
|
|