Re: LilyPond disabled on Wikimedia

[Han-Wen Nienhuys]

On Fri, Oct 16, 2020 at 3:32 AM Carl Sorensen <c_sorensen@byu.edu> wrote:

> Unfortunately, I’m not capable of handling this problem right now.
>
>
>
> But it’s hard for me to imagine that something that would require a major
> version bump is only a week’s worth of work.  I’ve copied Han-Wen to try to
> understand more about why the change would require a major version bump.
>
>
The one week estimate is not from me, or I am starting to forget things.

To make a program secure, you have to introduce a security boundary, from
where you control what the program can do. If you look in the archives, you
can find https://gitlab.com/lilypond/lilypond/-/merge_requests/310  and its
discussion. This tried to introduce a security boundary at the system call
level, but this is impractical for various reasons outlined in the MR.

The other obvious boundary is at the Scheme interpretation: if we can
control what Scheme code does, the threat surface is reduced to C++ errors
(eg. use-after-free, buffer overflow), which is a drastic reduction
relative to escaping to the system through

  #(system "naughty-command")

The mechanism to do this is through GUILE modules: a GUILE module
introduces a namespace, and a GUILE module can only see symbols explicitly
imported with (use-modules). So if we do evalation within an empty or safe
module, we prevent unsafe code from executing. Or differently expressed: we
prevent people from running the 'system function by declining to make the
function value available to untrusted Scheme code.

So far so good. Unfortunately, LilyPond parser scopes (eg \header, \paper)
etc are implemented
as modules as well, so the following works

   sym  = 2    % toplevel scope
   #(set! sym (1+ sym))

In order to get access to interesting functions, all scopes import GUILE
and lilypond bindings, see

https://github.com/lilypond/lilypond/blob/d99780e93bfeafbcafce1c2653eac8e294057e84/lily/ly-module.cc#L53

These bindings bring in a number of unsafe functions. In particular,  you
can do

  myvar  = \system

to store the unsafe 'system function into myvar in any given scope. Then,
you can use one of the many callback mechanisms to invoke the 'system
function to do mischief.

The solution would be to ly_make_module always create a "safe" module (the
code is just below), but I couldn't get this to work easily: the obvious
solution triggers obscure errors in the GUILE module system.

I do not know if fixing is possible and if this might take 2 hours or 2
weeks. When the GUILE problem is fixed, the system interface will have to
be revisited too: the PS -> PDF/PNG conversions are partially driven from
LilyPond parser scopes (have a look at init.ly), so they will need
significant rearrangement.

Finally, such a change will invalidate any .ly file that does anything
remotely interesting (such as interact with the file system directly). I
don't know how serious the impact to complicated extensions is (orchestral
lily, XML/SVG/speech synth output etc.), hence the reason that this will
require a 3.0 version bump.

WMF could actually run LilyPond in a seccomp-style sandbox to secure it for
Wikimedia itself, but IIUC, they decided LilyPond files pose an
unacceptable risk to their users, hence their insistence on a better
containment story for .ly files.

Thanks,
>
>
> Carl
>
>
>
>
>
> *From: *Tim Starling <tstarling@wikimedia.org>
> *Date: *Thursday, October 15, 2020 at 6:17 PM
> *To: *Étienne Beaulé <beauleetienne0@gmail.com>, Carl Sorensen <
> c_sorensen@byu.edu>
> *Cc: *Daniel Benjamin Miller <dbmiller@dbmiller.org>, "
> lilypond-devel@gnu.org" <lilypond-devel@gnu.org>
> *Subject: *Re: LilyPond disabled on Wikimedia
>
>
>
> A number of safe mode escape vulnerabilities were discovered. One of them,
> tracked internally as T260225, was discovered by Han-Wen and has not been
> rectified after two months.
>
>
>
> I discussed a plan for rectifying it with Han-Wen, and suggested that we
> could contribute funding towards fixing it. However, I was not able to get
> approval for funding it. So the task remains open for volunteers to
> address. Of course, it is difficult to recruit volunteers when it is a
> private security issue.
>
>
>
> Han-Wen commented that the rectification we discussed would require a
> major version bump to 3.0. I don't consider that to be a blocker. I think
> security hardening would make a good headline improvement for a 3.0 release.
>
>
>
> I would estimate it as approximately one week of work. If you're willing
> to put that kind of time in, I can forward you the previous communications
> on this issue.
>
>
>
> -- Tim Starling
>
>
>
> On 16/10/20 10:46 am, Étienne Beaulé wrote:
>
> Hello, I’m the maintainer of the Score extension.
>
>
>
> There is also https://nvd.nist.gov/vuln/detail/CVE-2020-17353 which
> affects LilyPond through PostScript code injection. We’ve also done a
> security audit. I’ve CC’d Tim Starling who performed the audit to this
> thread, and he’s be in a better position to responsibly disclose problems.
>
>
>
> We hope to get LilyPond back on the Wikis, and that vulnerabilities get
> fixed well for a safer LilyPond!
>
>
>
> Étienne
>
>
>
> Le 15 oct. 2020 à 19:05, Carl Sorensen <c_sorensen@byu.edu> a écrit :
>
>
>
> Unfortunately, there's not enough information on that thread to understand
> what the issues are.
>
> I know that in the past there have been significant security concerns
> which had a core concern related to Guile programming, since Guile is a
> turing-complete language.
>
> I don't know how we can contribute until we are made aware of the
> challenges here.
>
> Carl
>
>
> On 10/15/20, 4:14 PM, "lilypond-devel on behalf of Daniel Benjamin Miller"
> <lilypond-devel-bounces+carl.d.sorensen+digest=gmail.com@gnu.org on
> behalf of dbmiller@dbmiller.org> wrote:
>
> Not of direct relevance to us as end users, but can someone shed light
> on this and/or resolve the concern of the Wikimedia people? In the
> meantime Lilypond support has been disabled on Wikipedia.
> https://phabricator.wikimedia.org/T257066
>
>
>
>
>
>


-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen