Major Vulnerability in Minecraft versions 1.7 - 1.12
Sa1ZeR opened this issue · 31 comments
hello, can you fix this vulnerability for minecraft 1.7.10? (4472105)
Sorry but no, that version came out over 5 years ago, i don't have the time or the energy to support it.
A version for 1.12.2 is available now too, you can get it on curseforge (once approved) or here
I think this should cover all the popular historic versions, let me know if you have a big modpack for some other version that is still actively played.
Sorry to necro this, but there are now reports of this vulnerability getting used out in the wild!
This is a VERY SERIOUS problem, as this vulnerability allows for REMOTE CODE EXECUTION!!!
I've sent bdew a message on Reddit informing him of the situation
EDIT: Full message I've sent to bdew on Reddit:
Sorry for contacting you out of the blue, but a situation regarding bdlib for 1.7.10 and possibly 1.12.2 has come up that demands your attention!
A MAJOR vulnerability that you previously dismissed on Github has potentially been confirmed to be actively used by malicious actors! This vulnerability enables them to perform RCE (Remote Code Execution) attacks on Minecraft servers using bdlib for 1.7.10 and possibly 1.12.2!
Do NOT underestimate the severity of this issue! Malicious actors can use it to take over a victim's computer and steal personal information! There's already at least 1 video of the vulnerability in action. The video shows the hacker giving themself items, giving themself OP, and stealing/leaking Discord credentials of people connected to the server!
That version is long past it's support date, I won't be surprised if the answer's still gonna be no.
- there is a sizable number who still play on 1.12, for multiple reasons
- This is a serious vulnerability and a concern in regards to data integrity for players
Oops, missed that. The blog mentions an alternative mitigation though (edited into my previous comment).
I don't have the feeling this discussion can go into a positive/productive direction.
Considering that there exists a valid, easy to use and directly applicable strategy to mitigate this problem, namely "[...] migrate to the GT New Horizons forks of [BDLib] [...]" (1.7.10) or "[T]o mitigate all mods generally, you can install our mod PipeBlocker on both forge servers and clients" (1.12) (quotes from the blog entry about the vulnerability, I propose two things:
- document the vulnerability and its mitigation for all versions it exists in (which hopefully is doable for bdew, time and energy wise)
- we do not add further comments to this issue; all that can be said has been already said:
- this is a serious vulnerability
- in an ideal world (i.e. a world with infinite time and energy for all our projects), it would long be fixed
- there exists a valid mitigation strategy
- there would be a considerable amount of time and energy required to properly fix this for the affected versions
EDIT: mitigation strategy for 1.12
EDIT2: insert post to blog, which was removed from parent comment
GTNH is only for 1.7 IIRC, and the more pressing issue is that this exploit is prevalent in 1.12 as well
yeah by adding a mod, but go and convince every pack dev to add a fucking mod to their pack
I don't see the difference between adding a mod (i.e. PipeBlocker) or updating a different mod (i.e fixed BDLib), tbh. (although I do have to admit, that I don't have any experience maintaining mod packs)
I do agree that it is a mitigation strategy that is limited in scope versus the number of modpacks available, and the amount of modpack authors that are available AND willing to add in the mod to address the issue.
And either way, this is at best a shield for the mod devs to casually ignore the issue.
honestly curseforge should make every 1.12.2 instance download that mod by default
If you're here from that damn blog post, consider not sending that hatemail you were thinking of to the developer of a 5 year old abandoned piece of software (it was incredibly irresponsible of them to include a link here), and instead directing your attention to a more complete research project about this issue, which also includes a more complete list of affected mods
And either way, this is at best a shield for the mod devs to casually ignore the issue.
There's no deception going on, it is thoroughly expected that no software gets to be supported forever. All open source projects have a right to have a beginning, middle, and end, and developers shouldn't be harassed on Reddit for not editing 5 year old code. You're asking for a task that often involves reinstalling gigabytes of development tooling (which may have broken or deprecated features over the years), getting acquainted with code you haven't looked at in almost a decade, and testing that the change actually fixes the problem. This wouldn't be so bad, if you didn't also persist after the answer is obviously "No"
The level of selfish entitlement in this thread is awful. Completely inappropriate behavior.
"selfish entitlement" to have a mod for a still-played version to be patched in regards to a RCE... I don't think you have a particularly good-faith understanding of what is going on here.
The kind of exploit is one that any bad actor can hop in to do anything they wish on your computer. And it is a relatively old exploit that managed to fly past Minecraft until recently. And the code responsible for the exploit has been marked as unreliable.
So I am selfish for wanting an active and potentially dangerous exploit to be fixed on the mod itself. Go pound on some sand if you truly think that this is magically "unreasonable".
Even some of the largest enterprise software companies, ones that have a shockingly high number of legacy users, will not ship a patch on an unsupported version just because the vulnerability is severe. Spreading awareness of mod forks that do intend to further support is a much more fruitful effort than complaining in this bug tracker.
Edit: Not going to comment much further, but to respond to the claim that enterprise software companies often support ancient versions — these versions are usually still within the pre-defined support period, or in very rare cases, the support period is announced, before the EOL date, to be extended after the EOL date. It is extremely rare for software to still get patched after a pre-defined support period, WannaCry was a rare exception where a vulnerability was actually getting people killed (hospital equipment)
Now, a lot of open source software doesn't even announce support periods, so there is no expectation of this. These software licenses all have an all-caps section explaining that there is no warranty whatsoever unless otherwise stated.
Still a bad-faith understanding at best.
"large enterprise software" not getting updates more so boils down to corporate laziness than anything meaningful in relation to this discussion. They "can't" because they do not want to, and some of them have paid the price for their apathy to "old issues affecting old versions".
Have you wondered why enterprise software is still getting updates on ancient versions? Because the software have very big userbases, and cannot afford the blowback from stalled support, not even in the exploit protections, but also mitigations for the software to "support" newer systems and protocols.
And whining about posts in the bug tracker is even less productive than what you are claiming about this "complaining". I really could not care less about your pointed language and blatant hand-waving, especially when you keep dodging the point of the issue at hand.
So I am selfish for wanting an active and potentially dangerous exploit to be fixed on the mod itself
No. You are selfish for wanting others to fix a problem for you for free.
Why "for you": Well, you don't add any kind of productive to this problem. Neither do you provide mitigation strategies for the vulnerability, nor do you work on or present any ideas on how to apply these strategies to the minecraft moding eco system (i.e. modpacks).
The problem at this point, is not that the vulnerability exists. Yes that is unfortunate, but that's how it sometimes is in software development. The problem is how to distribute the fix(es) as fast as possible to as many parties as possible.
Possible solutions include adding the mod/update to any modpack automatically by the modpack hosting platforms (curseforge, modrinth et al) or pushing the mitigation into the modding platforms (forge, fabric, quilt, etc) (but that still has the problems, that modpacks need to be updated to versions that include the mitigation).
(Oh and note, that both those solutions do not mitigate the vulnerability for private modpacks)
But for that, this issue tracker is the wrong place (it's only about a single mod, and there's a whole list of affected mods + an unknown number of additionally, not yet known, affected mods).
This is about the same thing as "go build a solution yourself". The most anti-productive argument that one can ever present in a situation like this. Nothing more than deflection, which is sadly a rampant problem in FOSS software development.
The absurd lack of self-awareness is comical.
Pushing this problem to the loader platforms, in this case Forge, is not going to lead anywhere at all. Even with the new management in NeoForged, there is a stubborn reluctance to do anything in versions older than 1.19. A big problem of Forge management, that sadly has no meaningful resolution. The practical problems with forcing this on to the modpacks have already been explained; scope is bit of a clustertruck when it comes to 1.12. Curseforge and Modrinth cannot do a whole lot on their own; that kind of task is best left to the launcher devs, and I do not need to explain the logistical problems with that.
If you're here from that damn blog post, consider not sending that hatemail you were thinking of to the developer of a 5 year old abandoned piece of software (it was incredibly irresponsible of them to include a link here), and instead directing your attention to the original security research project that MMPI is seemingly taking credit for, which also includes a more complete list of affected mods (because it was assembled by people actually at the root of this investigation) and a more accurate list of credits!
Hi, I've updated the post to say to not post here, however it's important to keep this link for archival reasons. Understanding that a fix is not coming is important.
directing your attention to [the original security research project that MMPI is seemingly taking credit
This was posted after our blogpost, and we had no knowledge of the investigation they were doing. We attempted to contact the people working on this the day prior, and were ghosted.
closing an issue as completed without indicating that the issue continues to be present
I believe the reason it was closed as completed is that it was technically already fixed in 1.16. But yes, it probably should have been made clear that no backport has been done, since that was what was originally requested.
ColonelGerdauf
Even with the new management in NeoForged, there is a stubborn reluctance to do anything in versions older than 1.19. A big problem of Forge management, that sadly has no meaningful resolution.
Okay, this is getting really stupid. Yes, things before 1.19 are not supported. But Forge actually does have predictable support periods. They give you every chance to prepare by always supporting the last two versions. If you don't think this GENEROUS support schedule is enough, then be your own support vendor. I am happy to repeat the mantra of "go do it yourself" when the circumstances are as silly and unreasonable as this.
IMS212
Hi, I've updated the post to say to not post here, however it's important to keep this link for archival reasons. Understanding that a fix is not coming is important.
Thank you for fixing the issues with the blog post!
Before y'all start hassling a modder.
First of all, the MMPA blog post is incorrect; this is hardly the first mod to have had this issue. This type of bug was reported, publicly disclosed and fixed in RebornCore in 2021; private discussions about the safety of ObjectInputStream from my archives date back to as far as 2017, when its use in the mod RedLogic (although not exploitable by itself without a separate gadget) was discussed.
Second, read the 1.12 version's license again:
This mod is provided 'as is' with no warranties, implied or otherwise. The owner
of this mod takes no responsibility for any damages incurred from the use of
this mod.
Even though I do believe ignoring a major security vulnerability on old versions is irresponsible at best, and closing an issue as completed without indicating that the issue continues to be present even moreso, none of us are, in fact, entitled to security updates - or any updates.
Now shoo. This issue is closed, and if you do want to discuss - it's about nothing bar BDLib itself. It's not about Forge, it's not about the MMPA, it's not about CurseForge.
This was posted after our blogpost, and we had no knowledge of the investigation they were doing. We attempted to contact the people working on this the day prior, and were ghosted.
I'm editing my posts to remove the shit about you guys "taking credit", it's looking more like simultaneous discovery or some telephone-game happened and the version of events I first heard wasn't entirely true ! Auugh, this is such a mess, I'm sorry
Just so this thread has some actionable advice
Preventative:
- Forge 1.7 to 1.19 - On both server and client, add this mod https://github.com/dogboy21/serializationisbad/releases to your modpack instance. It will auto patch the affected mods. This file has proof that it contains support specifically for bdlib.
- Forge 1.6 or below - Use the Java Agent described in this README - https://github.com/dogboy21/serializationisbad#any-other-instances
- PipeBlocker may also be able to mitigate some of the problems, but I haven't checked it.
Cleanup:
It is currently unknown which anti-malware vendors target some of the malware that has spread through this route. Right now, exercise caution, enable 2fa on your accounts, practice good security, and don't fall for alarmism.
I've added a note about the vulnerability on curseforge.
When i have some free time i'll investigate if it's viable to use the same method used in GTNH fork to release updates to other popular historic versions. It seems to be easier than completely getting rid of java serialization like i did in newer versions (which would require some major rewrites and rebuilding of all the other mods that use bdlib)
In general I do not recommend playing those old versions on public servers, there are many mods out there with similar vulnerabilities and no one can guarantee the mitigation mods catch all of them.
I'm reopening this issue for now for better visibility and to track progress.
I released versions for 1.7.10 and 1.10.2, they will soon be available on curseforge.
You can also download them here
- https://bdew.net/download/bdlib-1.12.5.1-mc1.10.2.jar
- https://bdew.net/download/bdlib-1.9.5.1-mc1.7.10.jar
I also want to do a version for 1.12.2 - hopefully it will be out later today.