On the following file, "xalan -xsl rec.xsl -in rec.xsl" makes the
whole system freeze with a lot of disk activity (swap?). Here I
could eventually interrupt it after several minutes, but this was
not easy as the mouse pointer was no longer moving. This is an
obvious DoS.

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/" name="add">
  <xsl:call-template name="add"/>
</xsl:template>

</xsl:stylesheet>

Note that xsltproc doesn't have this problem, as libxslt has infinite
template recursion detection (thanks to xsltMaxDepth).

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

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.

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.

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

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 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've reduced it to important.