[Bug 459211] Review Request: oolite - A space sim game, inspired by Elite

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=459211





--- Comment #16 from Jens Ayton <redhat-bugzilla.ja at oolite.org>  2009-09-28 17:05:12 EDT ---
Libjs is used to run local user-installed scripts (as parts of expansion packs)
only. There is, by design, no support for loading scripts (or other expansion
pack data) over the network.

In debug and testing builds – that is, ones built without the
OO_EXCLUDE_DEBUG_SUPPORT macro predefined – one designated script is able to
communicate with an external program over the network using a host-defined
protocol. (This is used to implement a debug console facility; it is usually
only used with localhost, but this can be overridden in a configuration file,
which can be part of an expansion pack together with the console script.) In
principle, an expansion pack could be made which masquerades as the debug
facility and uses JavaScript to send information to an arbitrary server
implementing the protocol. Since we only produce “test” versions at the moment,
the standard makefile has no option to define OO_EXCLUDE_DEBUG_SUPPORT.

The use of this debug facility also enables scripts to call a semi-arbitrary
set of Objective-C methods on classes which are bridged to JavaScript.
(Specifically, methods which take zero or one parameter, which must be an
object, and return void or an object.) I am not aware of any way in which this
could be used to do anything more nefarious than cause the game to access
invalid memory and crash, but since it’s an open-ended set of methods I can’t
rule anything out.

It should also be noted that in versions of Oolite prior to test release 1.73,
a similarly open set of methods could be called by the “legacy scripting
system” (which essentially consists of lists of methods to call under various
circumstances). This is true of every version of Oolite prior to 1.73 on all
platforms. Version 1.73 added method whitelists to address this problem. To my
knowledge, nobody has successfully attacked this mechanism, but it was
obviously insecure in principle.

It is quite likely that there are still bugs in Oolite’s use of libjs. In the
past, such bugs have manifested as immediate crashes as a result of heap
corruption or assertion failures. These are broadly the sort of bugs you would
expect in C programs that handle diverse and complex user data - inherently a
risk, unlikely to be an attractive target.

In short, I judge that the risk in building your own copy of the game is small.
However, while this is not what Oolite fans want to hear, it would be a
reasonable precaution to hold on including it in a distribution until we catch
up with the current version of libjs (hopefully this autumn) or wait until the
we’ll-get-there-eventually next “full” release (optimistically, this winter),
and then build with OO_EXCLUDE_DEBUG_SUPPORT defined by default.

Due to the questionable design of the legacy scripting mechanism, I can’t
recommend the previous “stable” version (1.65) either.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.