Re: [fossil-users] XSS attack and fossil hosting services

[Warren Young]

On Apr 3, 2017, at 11:15 AM, Eduard  wrote:
> 
> Evil-user then convinces
> good-user to visit evilproject while logged into goodproject

Ah, I see.  Yes, I agree now.

>>> (Another way to fix it is by giving each repository a separate subdomain
>> 
>> ...run as a chroot or jail, which would mitigate most of the problems you 
>> bring up, if not all.
> 
> Sorry, by "it" in "Another way to fix it" I meant the XSS vulnerability.

Yes, I’m just giving another way to solve the problem, until the ones you want 
solved get some developer attention.

Running these repos in individual jails or chroots is a good idea anyway.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] XSS attack and fossil hosting services

[Eduard]

On 04/03/2017 02:16 AM, Warren Young wrote:
> On Apr 2, 2017, at 9:28 PM, Eduard  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.

Not true. Suppose that good-user registers
"https://example.com/f/goodproject; and evil-user registers
"https://example.com/f/evilproject; (both have setup privileges on their
respective repositories but don't trust each other). Good-user spends
most of their time logged into goodproject. Evil-user then convinces
good-user to visit evilproject while logged into goodproject; javascript
on evilproject (running on good-user's browser instance) can make
queries to and receive results for all pages on https://example.com/
(according to same-origin policy), including goodproject; it of course
also has access to all of the good-user's cookies. That JS code can do
anything that good-user can do on https://example.com/.

The usage scenario to consider here is that of a large repository host
(like github/sourceforge) which doesn't trust its users (since anyone
with an email address can register an account).

>> (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.

Sorry, by "it" in "Another way to fix it" I meant the XSS vulnerability.

Best,
Eduard
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] XSS attack and fossil hosting services

[Stephan Beal]

On Mon, Apr 3, 2017 at 5:28 AM, Eduard 
wrote:

> Hi,
>
> I recently realized that fossil repository hosting websites (such as
> chiselapp  and hydra
> ) are vulnerable to arbitrary HTML
> injection (XSS) as soon as they give (untrusted) users the 'setup'
> capability to the repositories they create.
>
Giving an untrusted user setup rights is kind of like giving them your bank
card and its PIN. Setup rights are only intended for the person (or people)
who physically maintain a repository, not untrusted users.


> As a related and more general question, what damage can a "fossil http -R
> $repo" command do to surrounding files/other repositories? In particular,
> using TH1/SQL or using the JSON interface?
>
-R $repo limits that server process's access to that one repo. There are no
services (other than "login groups") which span repos. TH1, if you add TCL
support to it, can run any arbitrary commands which TCL allows, so all bets
are off in that case ("rm -fr /etc"). Only setup user(s) should be able to
add TH1/TCL code to a repo, though, and if you have "untrusted" setup users
then (again) all bets are off. That's not a technical/fossil problem, but
an organizational one.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] XSS attack and fossil hosting services

[Warren Young]

On Apr 2, 2017, at 9:28 PM, Eduard  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