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@xxxxxxxxxx> 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review