High performance text component

[Gaja Sutra]

>> [1]: In sample 4, you load a Button. I am not currently in security 
>> business, then my example is not as good and realistic as possible 
>> (and use no bugs, only features).
>> I will suppose an application using a PasswordField in rich text and 
>> allowing plugins for some specific features (country-specific web 
>> services) but restricting sensible access from plugins to application 
>> with Java policies (not using multiple ClassLoader to avoid bugs due 
>> to visibility problems or only by simplicity).
>>
>>   * A custom localization contain a replacement of the standard
>>     <PasswordField .../> by fully-named
>>     <external.package.LoggingPasswordField .../>.
>>   * The class "external.package.LoggingPasswordField" is provided by
>>     a plugin to the application for adding country-specific features
>>     (like web services).
>>
>> Given the FXML is loaded by application, it will be in a domain 
>> non-restricted by policies and FXML will load without problem a class 
>> from plugin. The pseudo-password field in scenegraph can send 
>> password to the web.
>
> For your application, this is not a concern. A localizer cannot 
> reference some class that hasn't been loaded into the system, so it is 
> not possible to present a malicious password field, unless your 
> application has such a malicious password field. Further, unless you 
> are dynamically downloading localization files over the web (from 
> either an untrusted source or man-in-the-middle attack), there is no 
> vector for malicious FXML injection via localization. Only if you 
> actually shipped it in your app.
Excepted if the malicious password field is provided by external code 
like a plugin for country-specific web services. With standard Java 
security, the plugin would be in restricted zone by policy, not by 
class-loading (except OSGi-like application), then will be visible from 
standard class loader.

By example, currently Jigsaw use the same classloader for all its 
modules. A good security policy will usually intercept insecure calls 
from plugin to core application but not from core application to plugins 
(like a FXMLLoader in core application loading a class from a plugin).

For me, a usual final user would probably have two potentially insecure 
practices but clearly unavoidable: adding untrusted plugin and adding 
untrusted localization. My problem is only to put boundaries explicitly 
where expected by user.

  * All displays coming from plugin need to be explicitly viewed as
    coming from plugin, not from core application (by example with a
    message like "Plugin x.y.z tell you ..." followed by UI of plugin.
  * All data of user, accessed by plugin, need to be in a category
    allowed by user for this plugin.
  * An unofficial localization can display any stupid messages, images
    but can not compromise security of core application.


When I see a localization will be allowed to resolve part of general 
scenegraph in global namespace of classes, I see this as something 
dangerous, because a bad localization associated with a bad plugin can 
bypass my boundaries.

But this is clearly not unmanageable, only something to be cautious 
(like concatenating strings for creating SQL queries is not inherently 
bad, only something to not use with untrusted strings).

I will only put in my memory to avoid loading FXML from localizations 
even if technically possible. I will load some decorated strings from 
localization and transform these strings in RichText nodes in my code 
(without allowing resolution of absolute names like fully qualified 
class names). Most of my rich text usecases are coming from content and 
not from localization, then it will not be an important problem.


> We could (and have discussed some day doing it) support RTF / HTML 
> importers. So that you could supply the text in any of those forms, 
> and we'd convert FXML to a fragment of rich text nodes, or HTML (some 
> subset thereof), or RTF. But the root case, that this would be a 
> security hole, may be possible but I don't see how it could be a 
> reasonable attack vector since we'd turn off all scripting support for 
> these FXML fragments.
Adding an importer from RTF / HTML to current API will clearly solve my 
concern because you will have an official way (for documentation, 
teaching, etc.) to allow localizable rich texts, without resolving 
identifiers used in rich text in the global namespace of a classloader 
but in a local namespace of RTF / HTML commands.

Thanks,
Gaja.