[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Oct 2017 14:40:50 +0100
From: Ben Tasker <ben@...tasker.co.uk>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2017-8805: Unsafe symlinks not filtered in
Debian mirror script ftpsync
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
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.
