3 ms·

There is nothing to do, the incident was not caused by a vulnerability in mediawiki. Basically someone who had permissions to alter site js, accidentally added

by bawolff 8mo ago

There is nothing to do, the incident was not caused by a vulnerability in mediawiki. Basically someone who had permissions to alter site js, accidentally added malicious js. The main solution is to be very careful about giving user accounts permission to edit js. [There are of course other hardening things that maybe should be done based on lessons learned]

streetfighter64 8mo ago
Well, admins (or anybody other than the developers / deployment pipeline) having permissions to alter the JS sounds like a significant vulnerability. Maybe it wasn't in the early 2000s, but unencrypted HTTP was also normal then.
- LaGrange 8mo ago
  > Well, admins (or anybody other than the developers / deployment pipeline) having permissions to alter the JS sounds like a significant vulnerability. It's a common feature of CMS'es and "tag management systems." Its presence is a massive PITA to developers even _besides_ the security, but PMs _love them_, in my experience.
- bawolff 8mo ago
  That's a fair point, but keep in mind normal admin is not sufficient. For local users (the account in question wasn't local) you need to be an "interface admin", of which there are only 15 on english wikipedia. The account in question had "staff" rights which gave him basically all rights on all wikis.
  - cesarb 8mo ago
    > For local users (the account in question wasn't local) you need to be an "interface admin", of which there are only 15 on english wikipedia. It used to be all "admin" accounts, of which there were many more. Restricting it to "interface admin" only is a fairly recent change.
    - bawolff 8mo ago
      > Restricting it to "interface admin" only is a fairly recent change. Its been 8 years!
dboreham 8mo ago
There are already tools and techniques to validate served JS is as-intended, and these techniques could be beefed up by adding browser checks. I've been surprised these haven't been widely adopted given the spate of recent JS-poisoning attacks.
- bawolff 8mo ago
  You mean like SRI? That's not really what happened here, so its not really relavent.

by bawolff 8mo ago

streetfighter64 8mo ago

Well, admins (or anybody other than the developers / deployment pipeline) having permissions to alter the JS sounds like a significant vulnerability. Maybe it wasn't in the early 2000s, but unencrypted HTTP was also normal then.

LaGrange 8mo ago
> Well, admins (or anybody other than the developers / deployment pipeline) having permissions to alter the JS sounds like a significant vulnerability. It's a common feature of CMS'es and "tag management systems." Its presence is a massive PITA to developers even _besides_ the security, but PMs _love them_, in my experience.
bawolff 8mo ago
That's a fair point, but keep in mind normal admin is not sufficient. For local users (the account in question wasn't local) you need to be an "interface admin", of which there are only 15 on english wikipedia. The account in question had "staff" rights which gave him basically all rights on all wikis.
- cesarb 8mo ago
  > For local users (the account in question wasn't local) you need to be an "interface admin", of which there are only 15 on english wikipedia. It used to be all "admin" accounts, of which there were many more. Restricting it to "interface admin" only is a fairly recent change.
  - bawolff 8mo ago
    > Restricting it to "interface admin" only is a fairly recent change. Its been 8 years!

dboreham 8mo ago

There are already tools and techniques to validate served JS is as-intended, and these techniques could be beefed up by adding browser checks. I've been surprised these haven't been widely adopted given the spate of recent JS-poisoning attacks.

bawolff 8mo ago
You mean like SRI? That's not really what happened here, so its not really relavent.