On Fri, Oct 16, 2020 at 3:32 AM Carl Sorensen <c_soren...@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 <tstarl...@wikimedia.org> > *Date: *Thursday, October 15, 2020 at 6:17 PM > *To: *Étienne Beaulé <beauleetien...@gmail.com>, Carl Sorensen < > c_soren...@byu.edu> > *Cc: *Daniel Benjamin Miller <dbmil...@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_soren...@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....@gnu.org on > behalf of dbmil...@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 - hanw...@gmail.com - http://www.xs4all.nl/~hanwen