octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Insecure downloading of octave forge packages


From: Carnë Draug
Subject: Re: Insecure downloading of octave forge packages
Date: Mon, 23 Nov 2015 16:23:01 +0000

On 16 November 2015 at 21:40, Orion Poplawski <address@hidden> wrote:
> This bug just came into Fedora:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1282383
>
>            Summary: octave: insecure downloading of packages
>            Product: Security Response
>          Component: vulnerability
>
> It was reported that Octave's package manager downloads packages over HTTP and
> from an unreliable source. The full report is available at:
>
> https://bugs.gentoo.org/show_bug.cgi?id=565410
>
> Download phase:
>
> Octave's pkg subprogram (scripts/pkg/pkg.m:392) upon being issued
> "pkg install -forge <package_name>" from the interpreter or other
> code calls get_forge_download (scripts/pkg/private/get_forge_download.m)
> which calls get_forge_pkg (scripts/pkg/private/get_forge_pkg.m).
> This function returns an url of the form
> http://packages.octave.org/%s/index.html"; that resolved to
> "http://sourceforge.net/projects/octave/files/";.
> This url is then passed to urlwrite on scripts/pkg/pkg.m:395 that
> does the actual fetching. It does not seem to fetch any cryptographic
> signatures.
>
> This is bad for two reasons:
> 1) Octave fetches packages over an insecure channel
>    (not very bad on its own, read below)
> 2) Octave fetches packages from _sourceforge_, which was found to be packaging
>    adware into GIMP's installer [1].
>
>
> Install phase:
>
> scripts/pkg/private/install.m:109 verify_directory (packdir);
> This function only ensures presence of "COPYING" and "DESCRIPTION" files.
> scripts/pkg/private/install.m:331 load_packages_and_dependencies ...
> This function calls load_package_dirs(...) and adds it to function search
> path.
> scripts/pkg/private/load_package_dirs.m: load_package_dirs(..)
> This function seems to only sort out the order in which the paths must be
> set up.
>
> grepping for 'pgp', 'gpg', 'checksum' and 'sha' comes up with no package
> integrity verification code at all!
>
> 1) The octave interpreter does not seem to restrict the code it interprets
>    in any way.
> 2) A lot of the Octave packages (e.g. image-2.4.1, control-2.8.4, optim-1.3.0)
>    contain source code intended for the package command to build and
>    dynamically load into the interpreter:
>    install.m calls configure_make() that then executes make in shell (line 
> 91).
>
> While the presence of this does not seem to pose a security risk as soon as
> GNU Octave is installed by portage, there is no security warning issued
> to the pkg command user before the above happens or when Octave itself is
> installed.
>
>
> [1]
> http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/
>
> Reproducible: Always
>
>
>
> ----
>
> But I don' know if anything has been reported to the octave folks.
> Any comments?
>

I don't think any bug report about it has actually been reported but I'd
have guessed it to be known.  I have pushed a note to the documentation
of pkg about the security implications of it:

  http://hg.savannah.gnu.org/hgweb/octave/rev/453fca9ae397

Of course the ideal solution would be to have a better pkg, and better
repository for packages with hashes for confirmation, and signed packages.

Carnë



reply via email to

[Prev in Thread] Current Thread [Next in Thread]