https://github.com/miraheze/CreateWiki/security/advisories/GHSA-4rcf-3cj2-46mq

GHSA published, CVE ID CVE-2024-29883 has been assigned to it.

Fixed. GHSA will be published shortly.

https://github.com/miraheze/CreateWiki/security/advisories/GHSA-8wjf-mxjg-j8p9

Please raise back to 'normal' when this is no longer stalled.

I have removed other ldap accounts access.

Yes, in particular we need to investigate if it was disabled for John, Paladox, and Owen's LDAP accounts. So until then this should remain open.

Jank with the LDAP extension? Anyway, the reason this task was opened is solved now ig. However, @Universal_Omega said that other LDAP accounts should be investigated, so I guess this should be kept open or more likely, done in a separate maniphest task, since as a SWE I don't really have a need to know that information.

I also don’t see users listed in my groups in preferences. Anyway, I’ve added you to the member group.

Must be some sort of bug, since you should by default be a “User”.

In T11925#238880, @Universal_Omega wrote:

For the record, since you have an NDA and test151 access, I personally have no issue with you having Graylog/Ldap access, but this is an issue since offboarding seems to have not been done correctly and this is something we should review for other ldap accounts as well.

Hmm according to https://ldapwiki.miraheze.org/wiki/Special:ListGroupRights logged in users have the read permission

Should grant me access to ldapwikiwiki then. It is a private wiki, other than view the main page, I can do literally nothing else (MacFan4000 removed the bureaucrat group from my LDAP account when I resigned iirc).

For the record, since you have an NDA and test151 access, I personally have no issue with you having Graylog/Ldap access, but this is an issue since offboarding seems to have not been done correctly and this is something we should review for other ldap accounts as well.

Security advisory is now published. This task should be good for opening to the public now. For those reading this, we actually found some more XSS vectors when deploying the fixes to prod, so we actually have multiple patches in the GHSA for this one.

I just realized it will be better to just leave deploying the fixes to someone with access to mwtask181. Removing myself as assignee as my part is done, I think.

I've set confidentiality to high, since you could read private ManageWiki settings (for example, the Discord webhook for wikis using that extension) with XSS on those pages.

https://github.com/miraheze/ManageWiki/security/advisories/GHSA-4jr2-jhfm-2r84

I'm going to create a new draft GHSA, GitHub got bugged and thinks there are no changes waiting to be merged from the private fork sigh.

https://github.com/miraheze/WikiDiscover/security/advisories/GHSA-cfcf-94jv-455f is now published and the fix is live on the latest master. I believe this is task is now good for opening to the public

In T11814#236918, @OrangeStar wrote:

Fix for this one is pretty simple. @Universal_Omega I will need you to give me permission to make security advisories on WikiDiscover as well.

Fix for this one is pretty simple. @Universal_Omega I will need you to give me permission to make security advisories on WikiDiscover as well.

security advisory draft (https://github.com/miraheze/ManageWiki/security/advisories/GHSA-42fh-6pcr-3j58) is ready, all the changes have been made to the private fork if I'm not missing anything. Waiting for an SRE to review everything and give me the okay (or merge the changes themselves) so that they can double check my work and we can deploy the fixes to production as soon as possible.

Please do a security merge not a normal PR, should be fairly easy to do security with GitHub

I think I'm good to go to squash all of these and make a PR.

Adding all the messages that has an issue to wgRawHtmlMessages is a mitigation to this but it might be to complex with to many at this time.

@Universal_Omega You mean making the help messages in MWS.php, like https://github.com/miraheze/mw-config/blob/master/ManageWikiSettings.php#L109, interface messages? Because if so that looks like a complex rewrite. Also, all of those messages as well as managewiki-requires, managewiki-conflicts, and all the various right-* messages from core that are also XSS vectors in the permissions subpage must be added to wgRawHtmlMessages. We can do that, if you want, but after this.

I think what we should do is allow raw messages in MWS to be defined in config, and if it is, add them to $wgRawHtmlMessages, which prevents true security vulnerabilities by not only require editinterface, but also the same rights to editsitecss/js which would mean absolutely no difference from Common.js, etc...

Yeah there's no way my last patch is right.

Confirmed in Special:ManageWikiDefaultPermissions also

New patch superseding the other patch. Only thing missing is I think the XSS on the permissions subpage, which seems a bit more complex.

Also, just to clarify my previous message.

I think I know what is causing this, so I'll try to get this fixed tomorrow at the latest.

Assuming that patch fixes that for the extensions subpage, I can more or less make a theory (the form descriptor is passed around through so many functions that it is hard to keep track).

Looking at meta.miraheze.org, that is indeed supposed to be the "label" (it is not actually a label HTML element)

https://github.com/miraheze/ManageWiki/blob/75510297a32ed8881c98212f29001d226f0a833e/includes/FormFactory/ManageWikiFormFactoryBuilder.php#L269 where required and conflicting extensions are added to the form.

/extensions and /settings confirmed busted. /core doesn't give any alerts.

I enabled captcha and changed the title to > 'Contact Form on ' . $wgSitename

Looks like we can take the code between the <graph> tags and paste it into the old editor to generate PNG or SVG: https://vega.github.io/vega-editor/?mode=vega

This also provides a tracking category "Category:Pages with disabled graphs" showing the pages that used to contain graphs. [...]

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_205#Graph_extension_disabled_per_immediate_effect

No, it has significant security issues

Is there at least some wiki where it's enabled so that we can paste the code and take screenshots and replace the broken graphs?

I would also like the note that I'm going off the default description for their XSS template. It could be a different way to deliver arbitrary JS to users instead of writing JavaScript directly in the article

Don't we all love responsible disclosure? We can't even investigate this.

actually I can't, because although I uploaded the files to my wiki a few months ago and didn't delete them afterwards, they seem to have completely disappeared, as if they had been deleted. When I click on the red link of one of them (for example this one: https://pauldebouvier.miraheze.org/wiki/Fichier:Phil_Argyre.png), it redirects me to an empty page (in this case, a page named "Fichier:Phil_Argyre.png", even though again I did upload a file under the title "Phil Argyre").

could you please send us a link to one of the files?

Paladox and I discussed this a bit earlier, but here's the short of it:

@John does this seem fine with you?

To convert I did: