> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: dinsdag 17 juli 2012 16:07
> To: Ivan Zhakov
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1362434 - in /subversion/trunk: configure.ac
> subversion/include/svn_fs.h subversion/libsvn_fs/fs-loader.c
>
> Ivan Zhakov <ivan_at_visualsvn.com> writes:
>
> >> If the victim has a world writeable location in the search path the
attacker
> >> could replace any DSO.
> >
> > The attacker cannot replace any DSO, because current directory has
> > lower priority than other locations. So in typical scenarios user is
> > not vulnerable, because DSO is found in other location.
> >
> > So for security reason we should load DSO using absolute path at least
> > on Windows.
>
> I'm not sure how to get the absolute path.
>
> Does anyone build on Windows with SVN_USE_DSO set?
I don't think so, as we don't provide a way to enable this via gen-make.py.
We use apr to load libraries and APR loads libraries with the
LOAD_WITH_ALTERED_SEARCH_PATH flag, so Windows starts by checking the
directory in which the current executable is located. So for our own
executables this should be a safe default.
If some other application is using our libraries they should set a good
default policy via SetDllDirectory.
(We could call SetDllDirectory from our own executables, but we should make
sure we don't do it by default for our api users as this might break their
current security model)
For some specific case such as JavaHL (which would run in the java runtime,
where the application dir is something out of our control) we may improve
the situation a bit by providing a full path instead of just a dll name.
But then: Java has already loaded our javahl dll via an unsecure route, so
the front door is already open. No need to lock down the windows :)
(Note: The police recommends to lock the Windows anyway, to make sure
burglars don't feel they have a safe way out. But I don't think this part
applies to software security)
Bert
Received on 2012-07-17 17:15:30 CEST