On Apr 2, 2017, at 9:28 PM, Eduard <eduard.c.dumitre...@gmail.com> wrote:
> 
> An attacker can place malicious javascript at the top of every page

Certainly.

> they could, for example, change the victim's password

Doesn’t the login cookie prevent the hosted user from doing that to any but 
their own repository, at least through normal HTTP URLs?  (As you say, TH1 and 
SQL may well be a different matter.)

Setup privilege isn’t given to all users of a repository, only to the most 
trusted administrator(s) of that repository.

Unless Fossil erroneously lets you log into repo A and then have the same 
privileges on repo B hosted by the same Fossil server, I don’t see the problem. 
 Any wounds would be self-inflicted.

> In particular, the ability to run arbitrary TH1 and SQL may also need to be 
> restricted/disallowed (because a user could just modify the config table 
> using SQL, for example).

I can only see that being possible if embedded SQL is allowed to attach to 
arbitrary other SQLite DB files.  Without that ability, all SQL executes within 
the same repo that had the JS code added to it, which isn’t a problem per se, 
because you’ve given the user who added the JS code Setup privilege.

As for TH1, I’ve not looked into it, and so don’t know how close it is to Tcl 
in terms of capability.  It may be sufficiently restricted that it can’t do 
anything evil outside of the particular repo it runs atop.

> (Another way to fix it is by giving each repository a separate subdomain

Since ChiselApp is using HTTPS, they must be using some kind of front-end 
proxy, which could redirect each repo URL to a different Fossil instance.  That 
in turn could be run as a chroot or jail, which would mitigate most of the 
problems you bring up, if not all.

It’s not hard.  I do this on for my own public repositories.

It does mean you’re limited in the number of Fossil instances you can run on a 
single server by RAM and private TCP port numbers, but I shouldn’t think you’d 
want more than a few tens of thousands of Fossil instances on a single machine 
anyway.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to