TiddlySpace, Security and Computer Macro Parameters
Jeremy Ruston
TiddlySpace core that will soon filter out to tiddlyspace.com:
http://github.com/TiddlySpace/tiddlyspace/commit/90730c3fbc23fc597836dabb336ceb32ce6c895a
The change disables the use of TiddlyWiki's computer macro parameters
within TiddlySpace. This means that macros that use computed
JavaScript parameters like this will no longer work:
<<tiddler {{tiddler.title + "_notes"}}>>
The change is part of a range of measures that we need to take to make
TiddlySpace more secure.
The fundamental issue is that TiddlySpace is an environment for
sharing both code and content. The ability for users to share code is
powerful, and one of the things that I think has led to TiddlyWiki's
success. But it can also present dangers, particularly in the hands of
the malicious or the inexperienced.
For example, a malicious user could entice users to include a space
that includes code that "steals" the users private data and sends it
back to the attacker.
In a system that is designed for sharing code we don't believe that
this problem can be solved entirely within the technical domain. The
intention instead is to also address it in the social domain, such
that users will be able to use the social features of TiddlySpace to
discover spaces and plugins that are safe to use.
However, there are still technical steps that need to be taken in
order for that to work. In particular, the system needs to be able to
identify all the vectors through which a malicious attacker could
inject malicious code into a space.
It's straightforward to detect plugins by looking for the systemConfig
tag. Accordingly, future versions of TiddlySpace will enable users to
optionally filter out plugins when they include a space. Less obvious
vectors include:
- Computed macro parameters
- <script> tags and event handlers within <HTML> blocks
We'll address the latter problem soon, but we felt that it was worth
drawing this change to everyone's attention now, and encourage people
to prepare for TiddlySpace by exploring alternative approaches.
Cheers
Jeremy
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
PMario
I understand the issue, and totally agree, that it is/will be needed.
But a little bit more time to fix/adjust existing spaces, would have
been nice.
-m
PS: The following page template definition still seems to work.
<div macro='hideWhen {{
var tid=store.getTiddler("CSidebarTools");
tid.tags.contains("hide");}}'>
<div id='sidebarTools' class='box' refresh='content' force='true'
tiddler='CSidebarTools'></div>
</div>
On Sep 21, 6:01 pm, Jeremy Ruston <jeremy.rus...@gmail.com> wrote:
> It's worth drawing attention to a recent change we've made to the
> TiddlySpace core that will soon filter out to tiddlyspace.com:
>
Tobias Beer
This seems a major cutback.and as such is really bad news.
Does that mean that none of what we call transclusions these days will
work in TiddlySpace?!?
Would it be reasonalbe to ask for an ability to allow users to turn on
"insecure mode"?
Why not simply handle transclusions like plugins instead... security-
wise? Meaning: to require a standard tag indicating that something is
a transclusion which only then allows for parameter
evaluation ...otherwise not. There really should be no diffference in
managing transclusions or plugins as both contain executable code.
I understand the concerns, but I think it were better to advise users
on their responsibility as to "know" what they include and to improve
a user's ability to evaluate the reliability or stability of such
content by seeing user votes on these things or knowing trustworthy
authors, etc.
I also understand that anything {{eval}} presents possible security
issues. But, would you mind explaining precisely how malicious users
can hijack another users space?
How is disallowing parameter evaluation not just but one of a of a
myriad of (potential) security problems and therefore maybe not worthy
restricting as there is plenty more, equally exploitable room for
manipulation?
Of course, no client-side manipulation should be able to compromise
the server, but (potentially) only a user's data instead.
This issue feels to me like - yet again - (maybe just a false sense
of) security comes at the cost of utterly restricting degrees of
freedom... which I most always tend to find rather unfortunate.
So here is my vote for a policy that reads like this: "Put plugins and
transclusions on an equal standing while letting users decide on how
secure they need their spaces and contents to be (or user managers on
the security level of members in the user group they are to
manage ...if something like that should ever be developped.)"
Kind regards, Tobias.
Jeremy Ruston
change being pushed too quickly.
We'll create a plugin that people can use to re-enable computed macro
parameters within a particular space. This will only be a temporary
workaround, because the plugin will not be included into other spaces
when "safe inclusion" is used to filter out systemConfig plugins.
Thus, any content published from the space that relies on computed
macro parameters will not be processed correctly.
I'll respond shortly to Tobias' message with more background to the change.
Best wishes
Jeremy
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To post to this group, send email to tiddl...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywiki+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
Jeremy Ruston
It's definitely a nuisance, and part of a complex and deep discussion
about security topics that is pretty confusing. But there are lots of
mitigations, and I don't think the situation is as bad as you think.
> Does that mean that none of what we call transclusions these days will
> work in TiddlySpace?!?
The <<tiddler>> macro transclusion would continue to work. Do you mean
the way that a tiddler that is intended for transclusion can use
computed parameters to adapt itself to the tiddler in which it is
transcluded?
> Would it be reasonalbe to ask for an ability to allow users to turn on
> "insecure mode"?
Yes, perfectly reasonable, as long as them turning on insecure mode
doesn't also force any other spaces that include that space to also
switch to insecure mode. The plugin that I mentioned in my previous
post would work like more or less like that: install the plugin and
computed macro macro plugins will work for you when you visit the
space as a logged in user, and for guests who are not logged in.
> Why not simply handle transclusions like plugins instead... security-
> wise? Meaning: to require a standard tag indicating that something is
> a transclusion which only then allows for parameter
> evaluation ...otherwise not. There really should be no diffference in
> managing transclusions or plugins as both contain executable code.
Are you suggesting that computed macro parameters could be enabled on
a per-tiddler basis with a systemSomething tag? That's a reasonable
approach - we could then filter out that tag for safe transclusions.
> I understand the concerns, but I think it were better to advise users
> on their responsibility as to "know" what they include and to improve
> a user's ability to evaluate the reliability or stability of such
> content by seeing user votes on these things or knowing trustworthy
> authors, etc.
I think you're supporting the earlier point about social solutions
being more effective than technical solutions.
However, this business with the computed macro parameters is more
basic than that: it's tightening things up to gain us the ability to
reliably filter dangerous content. If we build the system such that
all wikicontent can potentially contain executable javascript we would
be inviting fun and games like today's twitter worm:
> I also understand that anything {{eval}} presents possible security
> issues. But, would you mind explaining precisely how malicious users
> can hijack another users space?
Alice constructs a space to store her study notes, and share them with
the rest of her class
Malevolent Bob constructs a space that claims and appears to be a
funky new theme with animated kittens
Alice includes the kittentheme space
Bob has secretly included code in the kittentheme space that
vandalises all the private and public tiddlers of the host space,
replacing every fifth word with "miaow"
Because Bob's code is running with the same authority as Alice's user
account, it can do anything it likes - including deleting content by
removing all revisions
There are endless examples of malicious payload that Bob might try
including shutting other uses out of a space or sending spam.
Social measures aren't always going to be enough: Bob might actually
not be malicious at all, but just have chosen a poor password so some
joker could steal his account.
> How is disallowing parameter evaluation not just but one of a of a
> myriad of (potential) security problems and therefore maybe not worthy
> restricting as there is plenty more, equally exploitable room for
> manipulation?
The vectors through with executable code can hide in wikitext are
actually pretty much limited to computed macro parameters and <script>
blocks. Of course, plugins can introduce new macros that do execute
code derived from wikitext, but at least those plugins themselves can
be filtered.
> Of course, no client-side manipulation should be able to compromise
> the server, but (potentially) only a user's data instead.
That's correct.
> This issue feels to me like - yet again - (maybe just a false sense
> of) security comes at the cost of utterly restricting degrees of
> freedom... which I most always tend to find rather unfortunate.
There is a solution which I haven't mentioned because I don't think we
currently have the resources to implement it. The idea would be to
manually parse and execute the computed parameter expressions in
JavaScript, and thus to restrict them to safe operations. There's a
project called Caja that does something similar on the server.
> So here is my vote for a policy that reads like this: "Put plugins and
> transclusions on an equal standing while letting users decide on how
> secure they need their spaces and contents to be (or user managers on
> the security level of members in the user group they are to
> manage ...if something like that should ever be developped.)"
Letting users decide is exactly what we're trying to do: but that
means letting users who include a space decide whether or not they
want to include executable code when they include a space. It can't be
decided by the users that are publishing spaces.
My apologies again about the timing and miscommunication of the change.
Best wishes
Jeremy
> Kind regards, Tobias.
>
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To post to this group, send email to tiddl...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywiki+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
>
>
--
Tobias Beer
Thanks for the detailed answers! ...will be back with more comments,
tomorrow.
As for now, gd' knight ;o)
Tobias.
PMario
There has been a thread at TiddlyWeb group some time ago. Also talking
about security issues with binary / svg uploads. I think you should
also read that one. Even if it is really looong.
http://groups.google.com/group/tiddlyweb/browse_thread/thread/d42af0cfcb5cc4e1/f667ff648b3a6fb1
And there is a tiddlyspace talking about security.
Especially:
http://security.tiddlyspace.com/#[[Summary%20of%20TiddlySpace%20security%20discussion%20on%20Wednesday%2015th%20July%202010]]
-mario
Tobias Beer
As a quick workaround, to get back that much desired functionaility
(and fix my spaces), I created a most simple macro called "Evalify"
and put it into a dedicated plugin-space [1] from which to included
it. It evals a statement and wikifies the returned string into either
place or any element with an ID specified as the second parameter.
Thus...
<<evalify [[readOnly?'':'<<tiddler ConditionalContent>\>']]>>
...wikifies ConditionalContent into place.
<<evalify [[readOnly?'':'<<tiddler ConditionalContent>\>']]
MySpecialSidebarContainer>>
...wikifies ConditionalContent into MySpecialSidebarContainer.
Please note that it exposes the same security risks as presumably
exposed by the standard parameter evaluation in the tiddler macro or
the eval statement in HideWehenPlugin or the eval staements in other
plugins that I wouldn't know of (yet).
Cheers, Tobias.
[1] http://evalify.tiddlyspace.com
Tobias Beer
Thanks for those interesting links. However, neither seems to give
information as to the reasoning behind the "evaled parameters security
risk"... maybe I am just missing the obvious,
Cheers, Tobias.
Jeremy Ruston
> information as to the reasoning behind the "evaled parameters security
> risk"... maybe I am just missing the obvious,
I'll try to restate the risk as best I can.
If a space A includes content from another space B, then when I visit
space A,that content from B will act as if it were part of space A.
If space B publishes executable content, then that content will be
executed in the context of space A.
Executable content includes:
- systemConfig tiddlers
- computed macro parameters
- <HTML> blocks containing JavaScript code
- MarkupPreHead and it's siblings
If I am a member of space A then the JavaScript within that space
(including that which came from space B) has the same access as me -
it can read and write to both the private and public bags.
If the executable content in space B is mischevious, therefore, it can
steal or modify my private content.
An example of mischievous content within a tiddler from space B:
<<tiddler {{window.store.deleteAllTiddlers();"HelloThere";}}>>
The effect of that example would be to invoke a (hypothetical) core
function to delete all tiddlers.
So, the issue is that as things currently stand including a space can
be dangerous from an information security viewpoint.
We're not trying to make it impossible to do dangerous things, we
think they are often rather useful. We're trying to avoid people
inadvertantly doing dangerous things.
To make space inclusion safe we need to be able to filter out
executable content.
In order to do that we need to be able to distinguish executable
content from ordinary, safe wikitext content.
With the computed macro parameters as currently implemented, it isn't
possible to make that distinction.
Hence the change.
Best wishes
Jeremy
--
Tobias Beer
How difficult would you think it were to implement a sandbox-mode
after including another space... then for a while one could work with
the sandboxed-inclusion and once you're comfortable that things work
as expected, you hit the button to either permanently accept or
otherwise undo the inclusion.
Cheers, Tobias.
Martin Budden
just have evaluated macro parameters switched on or off, we could have
a restricted evaluation: the code would be parsed and only executed if
it was 'safe'. The user would then have the choice of setting macro
parameter evaluation to on, off, or restricted. I'm looking at
implementing this at the moment.
What would be useful is people could give some examples of some of the
simpler evaluated macro parameters (transclusions) that they used.
I've looked at quite a few of Eric's transclusions from TiddlyTools
and think that most of these would require unrestricted evaluation,
since they access the story or the store.
TIA, Martin
Jeremy Ruston
That could be done by including the space in safe mode and then later
relaxing the safe mode restriction.
However, including a space in safe mode wouldn't really give any
useful information about how the space would behave if it were
included in unsafe mode.
Best wishes
Jeremy
>
> Cheers, Tobias.
>
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To post to this group, send email to tiddl...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywiki+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
>
>
--
Tobias Beer
I think Eric's transclusions provide awill fairly good benchmark as to
what others might as well (want to) accomplish and thus require
parameter evaluation.
As I said, these transclusions essentially are like plugins and from
my point of view should be treated in the context of security measures
on TiddlySpace just like anything tagged systemConfig ...in the case
that parameter evaluation is being used in a transclusion.
Cheers, Tobias.
Tobias Beer
I believe with said "sandbox-mode" I had something quite different in
mind. Something along the lines of putting all change requests at the
server into some temporary store and to somewhat disconnect the wiki
from the server ...while allowing any changes to the local wiki in an
unrestricted manner... and only when finally approving of the included
space to actually perform the changes at the server, otherwise discard
them.
Or even to always discard those temporary changes and notify the user
that for the moment he is in sandbox-mode... thus, no changes will be
saved at the server.
Most importantly, in this kind of sandbox, any included content or
code would run unrestricted ...against the local wiki, behaving much
like a standard TiddlyWiki.
However it would be necessary for any code to be unaware of the fact
that the server is not saving changes... otherwise it would be all too
easy to simply have different (malicious) code running once the server
is reconnected.
Cheers, Tobias.
PMario
And I also think, this can be achieved.
1) But "server side".
2) As you can see that "not executing" evaluated parameters
clientside doesn't add any security to tiddlyspace. As Tobias has
shown with his quick eval hack.
====
Some thoughts about 1)
Hash the content, and compare against a "plugin whitelist", when the
tiddler is saved.
If it doesn't pass the test, it can be _private_ only.
So I can use and test it until it passes the test.
A private malicious tiddler can only effect space members. But as a
owner of a space I'd only make someone a member, if I trust her or
him. The server could tag a private tiddler "test not passed". So
members can easily find them and togehter make them pass the "approved
for public use" tests.
There is the question. How to get a "plugin white listed"
I think this should be discussed at TiddlyWeb or Dev group.
====
There has been some dicussion about the target group, that uses/should
use TiddlySpace.
a) As a default user (80%) I'd want to write text.
Make it public.
Done.
b) As an advanced user (15%) I'd want to write something like:
<<tiddler {{tiddler.title + "_notes"}}>> or
<<tiddler {{"[["+tiddler.title+"_notes]]"}}>>
I think some server side white list filter can see that this should be
allowed.
Done.
c) As a programmer (5%) I should be able to write code, that can be
"approved for public use".
And how to get "white listed" should imho be discussed at TiddlyWeb or
TiddlyWikiDev group
d) may be there is a better solution for b) so it can be added to a)
-mario
Jeremy Ruston
> And I also think, this can be achieved.
That's a good insight: what we're dealing with here is best treated as
a new kind of plugin, one that is evaluated at the point of reference,
rather than at startup. I really like that idea.
I'd think of it as a tiddler tagged "systemScript" that contains
javascript that is executed when the tiddler is referenced through
<<tiddler title>> (or perhaps some new syntax like [[[tiddler
title]]]). The JavaScript code would be invoked with the roughly same
context as macro handlers, plus the with: parameters on the
<<tiddler>> macro.
> 1) But "server side".
You're meaning that the verification for safety of systemScript
tiddlers would happen on the server? If so, I would agree.
> 2) As you can see that "not executing" evaluated parameters
> clientside doesn't add any security to tiddlyspace. As Tobias has
> shown with his quick eval hack.
Changing the implementation of evaluated parameters doesn't add
security on it's own, but it is one of the necessary components for us
to implement safe filtering on space inclusions in the future. Tobias'
quick eval hack is a systemConfig tiddler and so would be filtered out
of a safe inclusion. That's the whole point: forcing javascript code
up out of invisible {{blocks}} and into manageable plugins.
The motivation for bringing up the change early is to minimise
disruption; as the service grows, more spaces would be affected by any
change we make in the future.
> Some thoughts about 1)
> Hash the content, and compare against a "plugin whitelist", when the
> tiddler is saved.
> If it doesn't pass the test, it can be _private_ only.
> So I can use and test it until it passes the test.
That is also one of my motivations in being interested in the hashing
mechanism being added to the server.
> A private malicious tiddler can only effect space members. But as a
> owner of a space I'd only make someone a member, if I trust her or
> him. The server could tag a private tiddler "test not passed". So
> members can easily find them and togehter make them pass the "approved
> for public use" tests.
>
> There is the question. How to get a "plugin white listed"
> I think this should be discussed at TiddlyWeb or Dev group.
I was thinking of the hashing more for blacklisting plugins that have
known vulnerabilities. For example, a trusted member of the community
may write a plugin that unwittingly parses and processes some piece of
user input as HTML. Then, a mischievous person discovers that
vulnerability, and publishes a specially crafted tiddler that if
included in spaces that include the original plugin would cause data
loss. Note that the mischievous person there is only publishing "safe"
content, but is exploiting a flaw in trusted code. In that situation a
blacklist would be a good way to pick up people who have copied and
pasted the plugin into their spaces. I'm sure there are other measures
that need looking at too, but this fingerprinting seems pretty
fundamental.
In terms of whitelisting, I was thinking of letting users have a list
of spaces they trust, and optionally to also trust the spaces that
those spaces trust. Everyone would start by trusting tiddlyspace,
which would trust the established developers. As a user I would want
to know how many other people trust or actively mistrust a space.
As you say, the way that we establish all this deserves deep
discusion. It's possible that UnaMesa might have a role in this,
maintaining the register of the highest grade of trust for people who
have, say, been through a legal notarisation process so that the
community can have some confidence in who they are.
> ====
> There has been some dicussion about the target group, that uses/should
> use TiddlySpace.
>
> a) As a default user (80%) I'd want to write text.
> Make it public.
> Done.
>
> b) As an advanced user (15%) I'd want to write something like:
> <<tiddler {{tiddler.title + "_notes"}}>> or
> <<tiddler {{"[["+tiddler.title+"_notes]]"}}>>
> I think some server side white list filter can see that this should be
> allowed.
> Done.
You mean the whitelist filter combined with having the tiddler tagged
systemScript because it contains JavaScript?
> c) As a programmer (5%) I should be able to write code, that can be
> "approved for public use".
> And how to get "white listed" should imho be discussed at TiddlyWeb or
> TiddlyWikiDev group
Agreed, as above.
Cheers
Jeremy
> d) may be there is a better solution for b) so it can be added to a)
>
> -mario
>
> On Sep 22, 6:08 pm, Tobias Beer <beertob...@googlemail.com> wrote:
>> Hi Martin,
>>
>> I think Eric's transclusions provide awill fairly good benchmark as to
>> what others might as well (want to) accomplish and thus require
>> parameter evaluation.
>>
>> As I said, these transclusions essentially are like plugins and from
>> my point of view should be treated in the context of security measures
>> on TiddlySpace just like anything tagged systemConfig ...in the case
>> that parameter evaluation is being used in a transclusion.
>>
>> Cheers, Tobias.
>
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To post to this group, send email to tiddl...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywiki+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
>
>
--
Tobias Beer
Since parameter evaluation seems a client-side issue, here's what I
suggest (the official TiddlySpace crew to provide) for now...
Create a space called EvaluatedParameters which one can include to
ones own space, which reactivates parameter evaluation and thus the
use of (mostly Eric's) transclusions.
I think this should be somewhat easy to implement and allows users to
get back this much desired functionality (at their own risk). Before
that, however, you might want to make sure that including another
space will not auto-include this or any other subspaces.
Cheers, Tobias.
FND
> ones own space, which reactivates parameter evaluation
Here's all that's necessary for that:
http://sandbox.tiddlyspace.com/#EvaluatedMacroParameters
(Note the Requires slice and systemConfigDisable tag.)
I'm uncomfortable maintaining such a space myself though, as I don't
want to encourage the use of evaluated parameters.
> you might want to make sure that including another space will not
> auto-include this or any other subspaces
That's currently not possible.
-- F.
Tobias Beer
config.evaluateMacroParameters = "full";
...in a zzConfig tiddler is all that is needed (for now).
Thanks for the info, Tobias.