In August, Mastodon 2.4.4 was released which contains two fixes for security vulnerabilities.
Today, 39.5% of all Mastodon instances which show their version number are still running vulnerable Mastodon < 2.4.4.
We already checked this twice:
– 10/1/18: 42% vulnerable
– 8/23/18: 38.6% vulnerable
Either the remaining instances are all unmaintained or admins refuse to update.
Mastodon 2.5.2 fixes even more vulnerabilities found in many Mastodon versions:
@Sir_Boops oh ok nice just worried for a sec there
@ale The exact code running is -> https://git.sergal.org/Sir-Boops/docker-mastodon/src/branch/master/Dockerfile
I'm not sure but I think m.io still uses my docker image too?
@Sir_Boops most likely they do, i doubt stan would make his own docker image if there already is a good one out there
@infosechandbook May be also because Mastodon don't do "security fix only" releases so you are forced to get all the new stuff, even if not interested in it.
@bortzmeyer @infosechandbook How far back is it supposed to go though? You essentially have to maintain a lot of separate versions especially when code changes between releases so the same fix can't be applied cleanly. I saw some places running 1.3, that's over a year old now. And upgrading isn't actually that difficult whether it's a patch or a major release
@infosechandbook I know any of them on FreeBSD and installed from ports/pkg are stuck on 2.3.3 because of the maintainer declaring bankruptcy on the port, because they couldn't keep it in sync with moving dependencies
@infosechandbook it says the version at the bottom of the "getting started page".. At least for this instance; v2.5.2
@infosechandbook This is incorrect -- not every version < 2.4.4 is vulnerable. You have to look at when the vulnerabilities were introduced!
This may be right, however, there are nearly 5,900 servers on instances.social and most of them don't disclose their version number. Furthermore, instances.social doesn't list every Mastodon instance on the internet.
So, it is hard to identify the actual percentage of vulnerable servers (there may be even more), however, there are many servers which are definitely affected and don't get updates.
@infosechandbook Not the point I was trying to make. I meant that you should have looked at the GitHub commit history and changelog, identified which commits were included in the "security fix" update, and then look at what they were changing and when that logic was introduced.
@infosechandbook For example: servers < 2.0.0 may not be vulnerable to the bugs fixed in 2.4.4, because there were major changes since 2.0.0 (including an entire protocol switch from OStatus to ActivityPub). It's possible that the vulns were introduced in e.g. 2.4.0, so only 2.4.0 - 2.4.4 would be vulnerable.
There were two vulnerabilities.
One vulnerability (CVE-2018-1000211) affects all Doorkeeper versions from 4.2.0 to 4.4.0.
The first stable version of Mastodon released in February 2017 uses vulnerable Doorkeeper 4.2.0. So, basically all Mastodon releases are affected by this.
Fixed by PR #8197.
Affected code of the second vulnerability is already present in Mastodon 1.5.0rc1 released in July 2017. I didn't check all files, though. So there may be affected code in versions before 1.5.0rc1.
Fixed by PR #8372.
I perfectly understood your comment the first time.
However, it is not our job to identify security vulnerabilities and tell people when they should update. Server admins are responsible for keeping their server software up-to-date and regularly check for security-related fixes.
It doesn't matter whether 10, 20, 30 or 40% of Mastodon instances are vulnerable. Every vulnerable server is bad. Unmaintained instances put personal data of their users at risk.
Here we have to be honest with ourselves, this is one of the disadvantages of federated systems.
@infosechandbook My plan of forking and closely following master pays off again. Also my version numbers are sometimes complete lies.
mastodon.at is a microblogging site that federates with most instances on the Fediverse.