Re: CVE-2017-8805: Unsafe symlinks not filtered in Debian mirror script ftpsync

[Robert Watson <robertcwatson1 () gmail com>]

Thank You for taking the time to explain the scripting issue.

Okay, so a script adds a symlink to /etc/shadow or something else
confidential. Unless they're root, what good does it do them? They can't
read it.

On Fri, Oct 20, 2017, 14:35 Ben Tasker <ben () bentasker co uk> wrote:

> On Thu, Oct 19, 2017 at 9:32 PM, Robert Watson <robertcwatson1 () gmail com>
> wrote:
>
> > Scripts depend on the underlying functionality of the various utilities
> > like rsync that they call. I'm having trouble understanding how a script
> > could ever be deserving of a CVE. Maybe I'm wrong. I wish to be educated.
>
> Whether you think it applies to the current example is obviously a
> different debate, but the simple principle is that the script is (arguably)
> using the underlying tool unsafely. The tool (rsync in this case) provides
> an argument to prevent the "risky" behaviour, but the calling script isn't
> using it, potentially opening a vector for misuse.
>
> So if there should be a CVE, it shouldn't be against rsync (as it provides
> the means to avoid, and in other cases you may even find the calling script
> is overriding the "safe" behaviour) but against the calling script.
>
> To give a fairly limited example, both of these scripts rely on the same
> functionality, but one is riskier (albeit not from a security perspective)
> - in neither case is the tool at risk
>
> fname=$1
> rm -rf "/$1"
>
> ...
>
> fname=$1
> rm -rf --no-preserve-root "/$1"
>
>
> Obviously it's quite easy for there to be more severe connotations to other
> scripts (for example, think about some of the things you might pass
> adduser) which may well be worthy of a CVE by nature of them effectively
> misusing a tool.
>
> Back on topic, I can see potential for abuse, though I'm also not convinced
> whether it's CVE worthy.
>
>
>
> > We are overwhelmed with more vulnerabilities than can be fixed quickly
> > already.
> >
> > Are "just to be safer" type things really a wise use of our resources?
> The problem there is setting the threshold. It's not unheard of for a "just
> in case" fix to later have proved to have mitigated a more severe (and at
> the time, unknown) issue. But gain, whether it needs a CVE is something
> else.
>
>
>
>
> > Does a proliferation of a large number of low-caliber problems make
> > monitoring these lists more trouble than it's worth? Does it cause
> > high-impact problems to be lost amongst low-impact ones?
>
>
> > On Thu, Oct 19, 2017, 15:46 Seth Arnold <seth.arnold () canonical com>
> wrote:
> > > On Wed, Oct 18, 2017 at 04:55:07PM -0400, Robert Watson wrote:
> > > > Removing the ability for rsync to copy symlinks pointing to targets
> > > outside
> > > > the mirror tree would greatly cripple it. I need to understand how
> the
> > > > danger is worth the loss of this functionality.
> > >
> > > Note that the fix isn't modifying rsync, the fix is modifying the
> ftpsync
> > > script that calls rsync:
> > >
> > > +    RSYNC_OPTIONS=${RSYNC_OPTIONS:-"-prltvHSB8192 --safe-links
> > --timeout
> > > 3600 --stats --no-human-readable"}
> > >
> > >
> > > https://anonscm.debian.org/cgit/mirror/archvsync.git/commit/?id=
> > d1ca2ab2210990b6dfb664cd6776a41b71c48016
> > > Of course for people who run this mirroring tool as a specific user
> > > account and set file permissions appropriately this is more or less a
> > > no-op. But this is a useful hardening for people who run the ftpsync
> > > command as a user with too many privileges. (I wouldn't have bothered
> > > filing for a CVE for this change; I see it as a simple hardening
> change.)
> > > This option shouldn't cripple ftpsync as a well-run repository is
> highly
> > > unlikely to have symlinks pointing out of the tree. A repository with
> > > symlinks pointing out of the tree is already not a suitable rsync
> source.
> > > Thanks
> > --
> >
> > Robert "DocSalvager" Watson
> > ... trust in truth keeps hope alive
> > www.DocSalvage.info
>
>
>
> --
> Ben Tasker
> https://www.bentasker.co.uk
-- 

Robert "DocSalvager" Watson
... trust in truth keeps hope alive
www.DocSalvage.info