[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Oct 2017 23:08:14 +0000
From: Robert Watson <robertcwatson1@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2017-8805: Unsafe symlinks not filtered in
Debian mirror script ftpsync
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@...tasker.co.uk> wrote:
> On Thu, Oct 19, 2017 at 9:32 PM, Robert Watson <robertcwatson1@...il.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@...onical.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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
