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
It's a pretty egregious failure for the org because it controlled the conditions for it to happen.
The security guy is just the patsy because he actioned it.
They have obviously done this a million times before and now they got burned.
Yes, this. That same engineer shouldn’t have a pocket nuclear trigger shaped just like their key fob, either. Humans are predictable.
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.
In the average real world, the staff engineer learns nothing, regardless of whether they get to lose or keep their job. Some time down the line, they make other careless mistakes. Eventually they retire, having learned nothing.
This is more common than you'd think.
They'll be fine, recruiters don't look this stuff up and generally background checks only care about illegal shit.
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
[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)."
Legitimately listening to this book for the first time after a coworker recommended it. It's rapidly becoming one of my favorite books that balances the truly alien with the familiar just right.
Not so ironically, it came up when we were discussing "software archeology".
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.
＼(＾O＾)／ zones of thought mentioned ＼(＾O＾)／
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
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!
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)
True but it does say something that such a script was able to lie dormant for so long.
Why would anyone test in production???!!!
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.
Once you get big enough… there comes a point where you need to run some code and learn what happens when 100 million people hitting it at once looks like. At that scale, “1 in a million class bugs/race conditions” literally happen every day. You can’t do that on every PR, so you ship it and prepare to roll back if anything even starts to look fishy. Maybe even just roll it out gradually.
At least, that’s how it worked at literally every big company I worked at so far. The only reason to hold it back is during testing/review. Once enough humans look at it, you release and watch metrics like a hawk.
And yeah, many features were released this way, often gated behind feature flags to control roll out. When I refactored our email system that sent over a billion notifications a month, it was nerve wracking. You can’t unsend an email and it would likely be hundreds of millions sent before we noticed a problem at scale.
I would say you can get to this point far below 100 million people, especially on web. Some people are truly special and have some kind of setup you just can't easily reproduce. But I agree, you do really have to be confident in your ability to control rollout / blast radius, monitor and revert if needed.
> 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
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.
"Everyone has a test environment. Some are lucky enough to have a separate production environment."
> 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.
So, like the Samy worm? (https://en.wikipedia.org/wiki/Samy_%28computer_worm%29)
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!"
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.
https://www.mediawiki.org/wiki/Manual:Interface/JavaScript
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.
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?
To paraphrase Bush,
> our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our site and our users, and neither do we.