[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Proposal: new fsfs.conf properties

From: Markus Schaber <m.schaber_at_codesys.com>
Date: Wed, 12 Jul 2017 11:43:10 +0000


From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> > That's such an easy way to make a malicious client explode the
> > repository size. And ... there's realy no reason to complicate. The
> > server's storage layer can cheaply do all the necessary checks without
> > having to believe the client, and without adding yet another
> > (dangerous!) config knob.
> Yes, well in any case allowing this by server-side inspection will also open
> up possibilities for blowing up the repository by a malicious client.

A malicious user can always "explode" the server by just uploading/overwriting huge random files. Using svnmucc and a unix pipe, he doesn't even need a local file or working copy for that.

Thus, I think listening to a client hint in general will not open a completely new security hole. SVN repositories are a kind of data storage, and we cannot prevent users from abusing it by storing data...

> In fact, making it coupled with "client also non-deltifies" forces the client
> to also send those huge files over the wire, making it a little bit more
> difficult to DoS the server by blowing it up. If the client can still deltify
> (only sending a few bytes), but trick the server into storing those as full-
> texts, the attack can be more powerful I guess.

Yes, I think allowing deltification for the client while storing non-deltified on the server amplifies the possible attack, so we should be careful.

Could the server use the already pre-deltified and -compressed representation coming from the client, without compressing and re-deltifying itself (but still verifying it, of course).

On the other hand, I'd also hesitate to automatically skip deltification and compression just because the client delivers uncompressed or non-deltified content. This will effectively disable deltification and compression for svnmucc, DAV-autoversioning and maybe some other use cases.

Best regards

Markus Schaber

CODESYS® a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.
Received on 2017-07-12 13:54:05 CEST

This is an archived mail posted to the Subversion Dev mailing list.