Re: [fossil-dev] The "ssh://" vulnerability
On 8/12/17, Richard Hipp wrote: > > I went a slightly different route... Having thought about this more, I'm thinking now that I might go back to Andy's approach -- D. Richard Hipp d...@sqlite.org ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] The "ssh://" vulnerability
On 8/12/17, Andy Bradford wrote: > 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 > I went a slightly different route and simply added additional error checking on the code that constructs the "ssh" command. -- D. Richard Hipp d...@sqlite.org ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] The "ssh://" vulnerability
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: 4000598f2d17 ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] The "ssh://" vulnerability
On Aug 11, 2017, at 9:41 AM, Richard Hipp wrote: > > I am open to arguments to the contrary, if you feel > differently. It would be an excuse to push out the final SQLite 3.20 version... ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
