Re: Re: CVE request for wget

[Austin English <austinenglish () gmail com>]

And 1.7 is now out as well:
https://tails.boum.org/news/version_1.7/index.en.html

With the fix included and documented

On Mon, Nov 2, 2015 at 2:37 AM, Austin English <austinenglish () gmail com>
wrote:

> The fix has been released in 1.7-rc1,
> https://tails.boum.org/news/test_1.7-rc1/index.en.html
>
> On Mon, Oct 26, 2015 at 3:21 PM, Austin English <austinenglish () gmail com>
> wrote:
>
> > On Thu, Oct 1, 2015 at 6:10 PM, Seth Arnold <seth.arnold () canonical com>
> > wrote:
> > > On Thu, Oct 01, 2015 at 06:57:26PM -0400, cve-assign () mitre org wrote:
> > > > If there is any additional Tails vulnerability related to this,
> > > > another CVE ID may be needed. For example,
> > > >
> > > >   https://lists.gnu.org/archive/html/bug-wget/2015-08/msg00050.html
> > > >
> > > > says
> > > >
> > > >   to be 100% sure, you should add --passive-ftp to your command line.
> > > >   If you don't do that, your /etc/wgetrc or ~/.wgetrc could include
> > > >   --no-passive-ftp (or passiveftp = off).
> > > >
> > > > If Tails is supposed to try to ensure that, perhaps there's a
> > > > requirement to have something like:
> > > >
> > > >   alias wget="wget --passive-ftp"
> > > >
> > > > in a system-wide location (possibly /etc/bash.bashrc). The concept of
> > > > CVE IDs for "failure of a torify step" issues is new, and we aren't
> > > > sure of the best approach.
> > >
> > > I suspect using a bash alias in a site-wide config might then qualify
> > for
> > > another CVE in the future, along the lines of "programs that spawn wget
> > > via system(3), popen(3), or exec family of functions can use unsafe
> > active
> > > mode by accident". If Tails is in the business of fixing these things
> > > for safety, removing active ftp support from tools seems like better
> > fix.
> > > Thanks
> >
> > A fix has been applied to Tails git:
> >
> > https://labs.riseup.net/code/projects/tails/repository/revisions/b9fd6312435d55dd0bc0b6abdb7994da4d66e2b2
> >
> > In short, the wget binary is moved to /usr/lib/wget/wget, and a
> > wrapper script is put in place in /usr/bin/wget. The wrapper ensures
> > that wget is called via torsocks, and additionally, also forces
> > --passive-ftp.
> >
> > Moving wget to /usr/lib/wget/wget gets the potentially dangerous wget
> > binary out of $PATH. A dedicated attacker could check if /usr/bin/wget
> > is a script and then parse it to find the actual binary, but that
> > would need to be a very dedicated attacker and at that point, there
> > are more feasible attacks available.
> >
> > --
> > -Austin
>
>
>
> --
> -Austin



-- 
-Austin