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

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.

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

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/

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.

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

@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

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.

@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.

In T257062#6278732, @faidon wrote:

• 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.

@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

@Krinkle as I understand it, safe mode greatly limits what is exposed in the embedded Guile Scheme runtime, both when it comes to Lilypond features and when it comes to Guile's standard library. I guess that LilyPond features which are disabled somehow rely on those unsafe Scheme interfaces. But yes, I think enabling LilyPond safe mode would get rid of those issues, as the safe mode uses a limited subset of R5RS, and IIRC even full standard of R5RS does not expose underlying operating system functionality like shell commands or filesystem access.

I think I found another issue: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Score/+/refs/heads/master/includes/Score.php#673