Bug#841294: Overrule maitainer of "global" to package a new upstream version
[copyoing to the bug, which I failed to do originally]
On 2016-12-08 23:32 +1030, Ron wrote:
> On Mon, Dec 05, 2016 at 10:13:05PM +0100, Philip Hands wrote:
> > Ron <ron@debian.org> writes:
> >
Thanks for comprehensive reply, Ron.
I wonder if it would make more sense to have this discussion in
#816924 which is the actual bug for 'should we upgrade global to v6,
and if not, why not?' You have to be in the know to find this on the
ctte mailing list.
> > Version 6 includes a CGI script that one is expected to install in a
> > manner so hopelessly insecure that we'd not accept it in Debian.
> That one had removed the ability to run it from a secure system CGI
> location at all, and changed the way that it's generated yet again.
> It also made changes that guarantee everyone will need to fork it
> for distro use, because it now hardcodes a fun mix of paths, like
> /opt/local/bin for perl and /usr/local for global et al.
The .cgi scripts are generated from .in files which are correctly
parameterised with @PERLPATH@ and @GLOBALPATH@ etc. Upstream
unhelpfully ships pre-generated versions with the above arbitrary
local paths, but we kicked the build to force regeneration of these so
that all the scripts come out with correct debian paths. That was in
6.5.5-0.1 and is in 6.5.5-0.2 (with ctags path set correctly
too). Please file a bug if we missed any.
So this is not an outstanding issue, and no fork needed,but it would
be nice to improve upstrema's build and reduce debian patching here.
> It does comment out that line from above with a note:
> "To use this code, please uncomment in your own responsibility."
OK, so as shipped, that's not actually an active problem.
> But it also outputs a .htaccess enabling execution in the directory
> where the output is generated, whether you want to use it from there
> or not (and adds a second CGI, and a bunch of jquery doing AJAX too).
The world is absolutely full of jquery doing AJAX. That's not bad in
itself (much as some of us prefered the 'old web'. We should make it
use system jquery.
> It has a bunch of immediately obvious problems:
>
> - it still passes the unsanitised $pattern to global, which then
> passes it to popen (which again lets it be interpreted by the
> shell).
So $pattern used to be sanitised, because that's what CVE-2000-0952 is
about. Ah and in fact it still is on line 148. Hmm, but that's after
using it in a pipe, which probably isn't much use... That is pretty
shoddy.
> - it won't run with perl's taint mode enabled, because that
> simply kills it warning of unsafe operations on untrusted data.
>
> - perl's warnings aren't enabled, and it complains of other
> rookie code problems if you do.
>
> - Enabling 'use strict' makes it scream with pain and completely
> fail to compile and run.
>
>
> It would need more thorough auditing to confirm that there is(n't) an
> exploitable path through that, but given that it ignores even the most
> basic advice which perl has strongly recommended since perl4 was new
> and shiny, then if there isn't, it would be because of luck more than
> obvious care.
I don't claim any web security expertise, so will ask a
potentially-dumb question. How much of a real world problem is the
shoddiness of this script if it is only used locally, using
htags-server (which is the only functionality now provided by the
package)? It exploses the script only to localhost unless you
explicitly configure it to do more, but not 'the net'. Nothing is done
as root, but it is run as 'you' so potentially gives access to 'you's
data, rather than all of www-data's data.
The only report of an actual vulnerability I can find online ('global'
is a very unhelpful name to search for vulnerbilities!) is:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0952 (from
2000 for global prior to v4.0.1
Which claimed to be fixing this very issue, but apparently it didn't stay fixed?
And this same code exists in global v5.7.1 (indeed both usages are
there, including the now-commented-out one), so how exactly was that
safer?
> It might not be utterly unfixable, but you'd have to convince upstream
> that security is important, or completely fork it for debian, which
> brings us back to exactly where we are - unless we just remove it all.
> But that would need Time, whoever does it.
I have not grokked why the shoddy code in 5.7.1 is safe but the same
shoddy code in v6 cannot be let out. Did htmake+htconfig stop people
entering $pattern in the form?
> It is what we now have enabled in the package that Wookey uploaded to
> experimental.
Indeed. Bugs (and even better patches) are welcome.
> > Also, for people that want personal access to htags there is a
> > htags-server command that brings up a dedicated server to run the CGI
> > as the invoking user, by default bound to a localhost port.
>
> htags-server is a shell script that generates python or ruby code
> to use the HTTP server functionality they can provide.
I'd describe it as a script that runs the ruby or python2/3
HTTP-servers, as covered in the NEWS file, but I think we mean the
same thing.
> I have no idea offhand what the security properties of either of
> those is is really like, but AIUI the python version at least
> claims to run the CGIs as 'nobody' - but I'm not sure how that
> works when run as a user unless something is SUID somewhere ...
> or if that's patched to work differently in Debian to what the
> python docs say it does. If that's true it would mean you need
> everything to be at least world readable to use this.
All the files under the generated 'HTML' directory (using --suggest2)
are 644 (except rebuild.sh which is 640). That seems reasonable to me,
and it works as expected (with 6.5.5-0.2) The python process is run as
'wookey', and if I chmod everything o-r it still seems to work OK, so
not convinced that it is really runnning the cgi as 'nobody'.
> It still unconditionally drops a .htaccess file into the output
> though, so if you're running a real web server, that may or may
> not grant CGI execute access to that directory, depending on
> how it's otherwise configured - whether you use htags-server for
> this or not.
Is this an unreasonable default? Anyone who has set up their webserver
to give .cgi execute permissions because there is a .htaccess file
saying so either knows what they are doing, or gets what they deserve.
If you want to use htags locally then this is a sensible way to make
it work.
> That script doesn't really change any of the things that we'd be
> concerned about in practice. It just means people who don't have
> apache (or another web server) installed can install python or
> ruby instead. Either can limit it to localhost or allow access
> on a public IP.
And it's more convenient to use (and safer) than configuring apache to
allow .htacces enabling of CGI execution.
> In terms of the package currently in experimental, there's a bunch
> of issues with it that would need to be fixed if we were going to
> want it in Stretch. Wookey already identified some. And in the
> quick look that I've already had at it so far, there's others
> which were immediately obvious. There's a bunch of upstream stuff
> that is simply missing from it, the man page for htags-server,
fixed in 6.5.5-0.2
> the icons and javascript and css for htags (which it actually complains
> loudly about when you try to use it, and makes me wonder how much
> they did actually test that or pay attention to what it reported)
Good point. I looked at the web-page, not the output from the server
end. I run requestpolicy, so am used to bare-looking web pages :-)
That's an easy fix.
> There's little things like it still having .la files in it, and
> static libs for things that are supposedly 'plugins'. Which aren't
> a big deal on their own to fix, but again suggests that if 'obvious'
> things like that were missed, there's a good chance there will be
> more issues than what I've already seen in a cursory review.
This is probably a result of letting libtool have its way. It loves
that ancient cruft. There is certainly quite a lot of tidying that
could be done with this, although I don't think it is in bad shape in
comparison to a great many debian packages. It would be good to talk
with upstream about whether there is any concrete benefit in using
libtool here anymore.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Reply to: