Questions over the exploit and ramifications

[slowthgt]

I've been reading through the README and issues with the question label, and while it solved some loose ends, I do have some questions regarding some cases and details:

• In case someone is just running a server locally and just connecting it through multiplayer, as long as the server is not exposed to the internet (the case for most people, even more so if server-ip=127.0.0.1), it mostly works the same as the singleplayer case, correct?
• When it comes to protecting a server, does a client have to successfully connect to the server in order to exploit the vulnerability or could it be also done through querying or just without connecting to the server at all? In other words, would something like a whitelist effectively protect a public facing server?
• Related to feat(scanallclasses): create a scan all classes boolean #15 and What about potentially vulnerable classes that *aren't* in the config? #18 , is there still plans to implement a generic fix as to not rely on knowledge of which mods are affected? I'm aware that you mentioned that some launchers are still shipping absolutely abhorrently old versions of Java 8, but, if it means that it can kill all birds with one stone, it would be worth having at least an alternate version that implements such thing? And, would such fix actually patch the large, if not the entirety of the entry points?
• Did CurseForge/Modrinth ever get back to you over possibly scanning for mods which suffer from the same issues?

Regardless, I thank you for your work on bringing this to everyone's attention and providing a fix for it!

[dogboy21]

Hi!

In case someone is just running a server locally and just connecting it through multiplayer, as long as the server is not exposed to the internet (the case for most people, even more so if server-ip=127.0.0.1), it mostly works the same as the singleplayer case, correct?

I think it can be generalized as "As long as you can trust anyone that would be able to join your server, you should be fine".
Unless you have bad actors in your local network (in which case you probably have bigger problems) you should be fine!

When it comes to protecting a server, does a client have to successfully connect to the server in order to exploit the vulnerability or could it be also done through querying or just without connecting to the server at all? In other words, would something like a whitelist effectively protect a public facing server?

I currently only know of exploits that can be executed after a successful connection, so a whitelist should be sufficient. But please keep in mind that that's only my current knowledge after researching the known exploits.

Related to #15 and #18 , is there still plans to implement a generic fix as to not rely on knowledge of which mods are affected? I'm aware that you mentioned that some launchers are still shipping absolutely abhorrently old versions of Java 8, but, if it means that it can kill all birds with one stone, it would be worth having at least an alternate version that implements such thing? And, would such fix actually patch the large, if not the entirety of the entry points?

As you already mentioned, I also think it is worth having an alternate version (something like #15 but with some more failsafes). If implemented correctly, it would also protect against 99.9% of entry points.
Unfortunately, my time is very limited currently due to some personal stuff going on, so I'm unable to work on that and also test it thoroughly so it doesn't cause any issues.
(If anyone wants to work on that, I would be more than grateful! Feel free to message me if you need further details.)

Did CurseForge/Modrinth ever get back to you over possibly scanning for mods which suffer from the same issues?

Modrinth didn't get back to me after offering them our internal scan tool to scan their whole database.

CurseForge did get back to me. While they were unable to scan their whole database, they added a scan for this vulnerability to their upload checking process so newly uploaded files with this issue should be prevented.

Regardless, I thank you for your work on bringing this to everyone's attention and providing a fix for it!

Thank you, I really appreciate that!
I hope that I will be able to put some more work into this project in the near future once I have some more spare time.

[slowthgt]

Hi!
I think it can be generalized as "As long as you can trust anyone that would be able to join your server, you should be fine". Unless you have bad actors in your local network (in which case you probably have bigger problems) you should be fine!

Feels about what I was expecting, but good to always double check.

I currently only know of exploits that can be executed after a successful connection, so a whitelist should be sufficient. But please keep in mind that that's only my current knowledge after researching the known exploits.

Figured as much, and honestly, it's hard to fathom an exploit without a connection, would need to be something bizarre like modifying a ping packet format or something. Not even sure if that's possible on Forge/Fabric tbh.

As you already mentioned, I also think it is worth having an alternate version (something like #15 but with some more failsafes). If implemented correctly, it would also protect against 99.9% of entry points. Unfortunately, my time is very limited currently due to some personal stuff going on, so I'm unable to work on that and also test it thoroughly so it doesn't cause any issues. (If anyone wants to work on that, I would be more than grateful! Feel free to message me if you need further details.)

Take your time. I assume you guys already swept the most popular modpacks on CurseForge (I'd hazard a guess that you just went to the most popular packs in Curseforge and just sweep them, along with the established names like FTB, Skyfactory, ATM and Enigmatica, right?), so now it must really be down to just very niche mods.

Modrinth didn't get back to me after offering them our internal scan tool to scan their whole database.

CurseForge did get back to me. While they were unable to scan their whole database, they added a scan for this vulnerability to their upload checking process so newly uploaded files with this issue should be prevented.

Well, that's better than nothing. I do sort of understand their position, with having such a large mod database, it'd probably prove... resource intensive. But hey, at least (providing they implemented the scan properly) it will avoid future mods suffering from this.

Thank you, I really appreciate that! I hope that I will be able to put some more work into this project in the near future once I have some more spare time.

As I said above, take your time. Unfortunately, I cant provide any help as I am completely unfamiliar with the Forge/Fabric APIs :(