Thus said Richard Hipp on Fri, 11 Aug 2017 11:41:09 -0400:

> I don't  feel a particular need  to rush out a  new release containing
> this fix.  But I  am open to  arguments to the  contrary, if  you feel
> differently.

I think  at a certain  point, users of any  software have to  take their
own  measures to  work  securely.  A malicious  user  could give  Fossil
instructions similar to:

fossil sync --ssh-command "ssh -malicious -options" ssh://my.malicious.host/repo

And if  an unsuspecting  user just blindly  acceepts that  command, what
should Fossil  do about  it? But  Fossil shouldn't make  it easy  by any
means.

I think a bigger problem that Fossil has is partially addressed here:

http://www.fossil-scm.org/index.html/info/ce7baa9798de21aa

which  is similar  to  the attack  vector that  you  just fixed,  though
perhaps worse because it allows remote execution of commands:

fossil clone "ssh://somehost//some/path;rm -rf /" clone.fossil

Again, the  attack surface  of this  is limited to  the access  that the
remote user has, but it's still pretty bad in my opinion.

I  don't have  a Windows  environment available,  so I  cannot test  the
changes I've made for Windows so I committed the code to a branch.

The safest way to use SSH is with ForceCommand.

Thanks,

Andy
-- 
TAI64 timestamp: 40000000598f2d17


_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Reply via email to