Bug#718315: Please reduce severity of bug

[Vincent Lefevre]

Control: severity -1 important

Reducing the severity because XSLT can be regarded as a general
programming language, and not all programming language implementations
are protected against infinite recursion anyway.

On 2014-10-07 08:55:46 -0700, Andrew Ayer wrote:
 Dear Maintainer,
 
 I do not believe that this bug constitutes a security vulnerability or
 that it deserves grave severity.

Well, I agree that this isn't a security vulnerability, but it still
*easily* freezes the whole system for several minutes, and can
possibly make random process crash / be killed by the OOM killer.

 As for exploiting locally, there are already a plethora of ways for a
 local user to DoS the system, such as by running a fork bomb in bash.

Note however that this must be done on purpose (or because of a
specific bug). That's not common.

 In these ways, Xalan is similar to an interpreter like bash or perl.

Yes, that's true at least with perl:

#!/usr/bin/env perl

sub f { f }

f;

(BTW, that might explain why some buggy Perl script was freezing my
system some time ago, though I didn't have the time to find what was
the cause exactly.)

In C, one would be protected because the memory for the recursize
function calls is taken from the stack, which is limited by default.

 The fact that malicious programs can do great harm to a system if
 interpreted by bash or perl does not constitute a security
 vulnerability in bash or perl, and nor should it in Xalan.

The main problem is not malicious programs, but bugs, e.g. in user
code. It's very easy to introduce a bug that yields an infinite
recursion. Users should be protected against system freeze due to
infinite recursion (or with a large number of recursion calls) by
default, just like what can be observed in C.

 I therefore propose that the severity of this bug be reduced to
 important or normal so that Xalan can migrate to Testing.  It would
 be a shame for Xalan to not make it into Jessie because of this.

I've reduced it to important.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718315: Please reduce severity of bug

[Andrew Ayer]

Dear Maintainer,

I do not believe that this bug constitutes a security vulnerability or
that it deserves grave severity.

To be exploited remotely, you have to execute an untrusted XSLT
stylesheet, which is similar to executing untrusted arbitrary code, and
is a bad idea for reasons much more severe than this DoS.  For example,
using external entities and the document() function, an untrusted XSLT
stylesheet can read arbitrary files from the filesystem and upload
their contents to a Web server on the Internet.

So in order to safely execute an untrusted XSLT stylesheet, you really
need to run the XSLT processor in a sandbox with restricted filesystem
and network access.  At that point you might as well use ulimit or
cgroups to prevent resource consumption such as from infinite recursion.

As for exploiting locally, there are already a plethora of ways for a
local user to DoS the system, such as by running a fork bomb in bash.

In these ways, Xalan is similar to an interpreter like bash or perl.
The fact that malicious programs can do great harm to a system if
interpreted by bash or perl does not constitute a security
vulnerability in bash or perl, and nor should it in Xalan.

I therefore propose that the severity of this bug be reduced to
important or normal so that Xalan can migrate to Testing.  It would
be a shame for Xalan to not make it into Jessie because of this.

Regards,

Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org