See the public phab ticket: https://phabricator.wikimedia.org/T419143
In short, a Wikimedia Foundation account was doing some sort of test which involved loading a large number of user scripts. They decided to just start loading random user scripts, instead of creating some just for this test.
The user who ran this test is a Staff Security Engineer at WMF, and naturally they decided to do this test under their highly-privileged Wikimedia Foundation staff account, which has permissions to edit the global CSS and JS that runs on every page.
One of those random scripts was a 2 year old malicious script from ruwiki. This script injects itself in the global Javascript on every page, and then in the userscripts of any user that runs into it, so it started spreading and doing damage really fast. This triggered tons of alerts, until the decision was made to turn the Wiki read-only.
This is a pretty egregious failure for a staff security engineer
Pretty much the definition of a “career limiting event”
It's either a a Career Limiting Event, or a Career Learning event.
In the case of a Learning event, you keep your job, and take the time to make the environment more resilient to this kind of issue.
In the case of a Limiting event, you lose your job, and get hired somewhere else for significantly better pay, and make the new environment more resilient to this kind of issue.
Hopefully the Wikimedia foundation is the former.
Nobody is going to know who did this, so probably not career limiting in any major way.
They named him in the support ticket linked here somewhere.
> sbassett
They'll be fine, recruiters don't look this stuff up and generally background checks only care about illegal shit.
[flagged]
Is ok, the AI was going to replace them in a few weeks anyway.
Didn't realise this was some historic evil script and not some active attacker who could change tack at any moment.
That makes the fix pretty easy. Write a regex to detect the evil script, and revert every page to a historic version without the script.
Letting ancient evil code run? Have we learned nothing from A Fire Upon the Deep?!
"It was really just humans playing with an old library. It should be safe, using their own automation, clean and benign.
This library wasn't a living creature, or even possessed of automation (which here might mean something more, far more, than human)."
Link to the Prologue of Fire Upon the Deep: https://www.baen.com/Chapters/-0812515285/A_Fire_Upon_the_De...
It's very short and from one of my favorite books. Increasingly relevant.
I've only just heard of it. But, I already knew to not run random scripts under a privileged account. And thank you for the book suggestion - I'm into those kinds of tales.
I love that book
Or just restore from backup across the board. Assuming they do their backups well this shouldn't be too hard (especially since its currently in Read Only mode which means no new updates)
Are you sure? Are you $150 million ARR sure? Are you $150 million ARR, you'd really like to keep your job, you're not going to accidentally leave a hole or blow up something else, sure?
I agree, mostly, but I'm also really glad I don't have to put out this fire. Cheering them on from the sidelines, though!
True but it does say something that such a script was able to lie dormant for so long.
Why would anyone test in production???!!!
There are plenty of ways to safely test in production. For one thing you need to limit the scope of your changes.
I have never heard of this kind of insane behaviour before.
Selecting the wrong environment in your test setup by mistake?
I refuse to believe that someone on the security team intentionally tested random user scripts in production on purpose.
> I refuse to believe that someone on the security team intentionally tested random user scripts in production on purpose.
Do I have a bridge to sell you, oh boy
300 million dollar organization btw
I'm guessing, "1> Hey Claude, your script ran this malicious script!"
"Claude> Yes, you're absolutely right! I'm sorry!"
On one hand, I was about to get irrationally angry someone was attacking Wikipedia, so I'm a bit relieved
On the other hand,
>a Staff Security Engineer at WMF, and naturally they decided to do this test under their highly-privileged Wikimedia Foundation staff account
seriously?
wait as a wikipedia user you can just put random JS to some settings and it will just... run? privileged?
this is both really cool and really really insane
It's a mediawiki feature: there's a set of pages that get treated as JS/CSS and shown for either all users or specifically you. You do need to be an admin to edit the ones that get shown to all users.
Yes, you can have your own JS/CSS that’s injected in every page. This is pretty useful for widgets, editing tools, or to customize the website’s apparence.
It sounds very dangerous to me but who am I to judge.
It's nothing.
For the global ones that need admin permissions to edit, it's no different from all the other code of mediawiki itself like the php.
For the user scripts, it's no worse than the fact that you can run tampermonkey in your browser and have it modify every page from evry site in whatever way your want.
It is kind of risky - you now have an entire, mostly unreviewed, ecosystem of javascript code, that users can experiment with.
However its been really useful to allow power users to customize the interface to their needs. It also is sort of a pressure release for when official devs are too slow for meeting needs. At this point wikipedia has become very dependent on it.
That is how Mediawiki works. Everything is a page, including CSS and JS. It is not really different than including JS in a webpage anywhere else.