Last modified: 2011-12-16 13:53:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T31630, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 29630 - Make [[mw:Extension:LilyPond]] safe against DoS attacks
Make [[mw:Extension:LilyPond]] safe against DoS attacks
Status: RESOLVED INVALID
Product: MediaWiki extensions
Classification: Unclassified
LilyPond (Other open bugs)
unspecified
All All
: Low major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 7355
  Show dependency treegraph
 
Reported: 2011-06-28 17:56 UTC by Helder
Modified: 2011-12-16 13:53 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Helder 2011-06-28 17:56:58 UTC
Per bug 189 comment 37[1] and bug 189 comment 105 [2], the current implementation of the LilyPond extension is not safe. It needs to be improved in order to not allow [[denial-of-service attacks]] on wikis where it is used.

So, I'm opening this bug to track this specific issue of the extension.

The following pages on MediaWiki.org may be useful:
* [[mw:Security for developers]]
* [[mw:Manual:Security]]
* [[mw:Security for developers]]

Besides, per bug 189 comment 42[3] TeX has similar issues and it was possible to make it reasonably safe (indeed the <math> tags, added by [[mw:Extension:Math]], are in use on Wikimedia projects). So, maybe the solution which was applied there could be adapted to this extension too.

On bug 189 comment 82[4], Aryeh Gregor also indicated some ways in which this could be fixed:

----
> > But in the same message Graham Percival said that "trying to keep lilypond
> > within certain CPU-time limits is going to be hard". Would this be solved by
> > doing what Dscho said at
> > http://lists.gnu.org/archive/html/lilypond-devel/2009-02/msg00023.html
> > ?
> 
> You mean:
> 
> > But we could add a simple timeout that says "if this fails to 
> > terminate in 20 seconds, it errors _out_".
> 
> I assume that would address all DoS concerns, if memory and disk use are also
> limited (either explicitly, or as a practical matter).  I'd assume that any
> reasonable score could be created in well under 20 seconds.  It wouldn't be
> ideal, though.  It would lead to intermittent failure for input that's close to
> the limit, and it might cause occasional failures if the server is under high
> load briefly for some reason.
> 
> For wikitext, which can also be very slow, we have limits like "no more than X
> of this instruction" instead, calibrated so as to make DoS unlikely.  Likewise,
> for ImageMagick I believe we have pixel limits on what images it will try to
> resize.  This way the software behaves consistently regardless of server load
> or other hard-to-control factors, but it's harder to do, of course.
> 
> > After this, was said that "Scheme just should be disabled for the purpose of
> > the MediaWiki extension."
> > (http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00265.html). How
> > much of the issues would be solved with this?
> 
> I'd assume that disabling Scheme would be necessary, but not sufficient.

After that, on bug 189 comment 87[5], Tim said that this approach "sounds like an overkill".


[1]https://bugzilla.wikimedia.org/show_bug.cgi?id=189#c37
[2]https://bugzilla.wikimedia.org/show_bug.cgi?id=189#c105
[3]https://bugzilla.wikimedia.org/show_bug.cgi?id=189#c42
[4]https://bugzilla.wikimedia.org/show_bug.cgi?id=189#c82
[5]https://bugzilla.wikimedia.org/show_bug.cgi?id=189#c87
Comment 1 Helder 2011-06-28 18:04:59 UTC
Marking this as "major", per [[mw:Bugmeister/Bugzilla]], since this bug "affects an area of MediaWiki that is important on WMF sites".
Comment 2 Sam Reed (reedy) 2011-06-28 22:31:36 UTC
That extension isn't enabled on the WMF cluster, so I'm not sure how this affects WMF sites
Comment 3 Helder 2011-06-28 22:44:19 UTC
What I mean is that all the requests[1] to enable it on WMF wikis have being refused because, among other things, currently the extension is not safe.

[1]E.g.: for Wikipedia (Bug 935), Wikisource (bug 189 comment 15), Wikibooks (bug 189 comment 18), and so on (not to mention the requests on MetaWiki and the local wikis...). Since the feature is being requested on many WMF sites, I believe it should be considered important (although as the age of bug 189 confirms, it may not be considered a priority at the moment).
Comment 4 Helder 2011-06-29 21:28:05 UTC
(In reply to comment #3)
> [1]E.g.: for Wikipedia (Bug 935), Wikisource (bug 189 comment 15),
Actually, there is a specific request for Wikisources on Bug 7355.
Comment 5 Mark A. Hershberger 2011-06-30 16:11:26 UTC
(In reply to comment #3)
> Since the feature is being requested on many WMF sites, I
> believe it should be considered important (although as the age of bug 189
> confirms, it may not be considered a priority at the moment).

I think until now this hasn't really been seen (among the many things the
Foundation could be concerned about) as a high priority.  Adding the ability to
do music in the WikiSource sites would be great, but the work we're already
doing has consumed all our resources.

I suspect that if the community really wants this, it is going to have to
bootstrap it into existence.  See [[mw:Writing an extension for deployment]]
for exactly what is needed to get this on WMF sites.  It has already been
reviewed (to an extent) and those criticisms need to be addressed.

Until this module has a champion in the (developer) community, I don't think it
can really be above "low" priority.
Comment 6 Sumana Harihareswara 2011-12-16 13:53:01 UTC
Instead of fixing Extension:LilyPond, the new direction will be to review & deploy Extension:Score per bug 33193 .

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links