Forum:Responsible vulnerability disclosure

I have drafted a responsible disclosure policy regarding vulnerability fixes on wiki. We have previously received informal requests from Mojang asking to remove such information before they are patched. I think that the wiki should be responsible to

• Minimize the risk of spreading information on how to trigger the exploit before it is fixed
• Warn and allow users to upgrade to a secure version ASAP

From the draft:

This addresses several of the points raised in the board meeting:

• wait with disclosure until at least a full release, optimally with a grace period.
• only describe such exploits in general terms, without describing how to trigger the bug
• if it becomes public knowledge, deal with such issues on a case-by-case basis

I agree that this might be considered self-censoring. However, I believe it's done for a good cause. --GIM Dianliang233 T C 01:58, 17 October 2024 (UTC)

👁 Image
 Support Exploits and vulnerabilities are different from the usual information we document on the wiki. They are unintended behavior that can be used maliciously. Some people will use them maliciously, and we probably shouldn't make it easier for bad actors to do bad things. The proposal doesn't ban mentioning that vulnerabilities exist, it just prohibits the details from being disclosed until after a fix is implemented. The information will be added to the wiki eventually. It could also be argued that we would be doing our part to help uphold the Community Standards for Minecraft in the Minecraft EULA, which prohibit the use of exploits. Rampage455 (talk) 02:57, 17 October 2024 (UTC)

👁 Image
 Support per Rampage455. -BrianGLHF (talk) 07:03, 17 October 2024 (UTC)

What is the definition of "exploits and vulnerability" here? That should be included in any policy of this nature. I also oppose having a policy like this in general since it feels very much like putting the cart before the horse. The vast majority of multiplayer servers are not using vanilla, but instead using a modded server jar to allow greater performance and plugins. The extent to which any exploits are applicable in multiplayer will vary depending on the specific exploit. And exploits in single player are completely moot unless pasting a command or opening someone else's save file. The reality is that any exploit that could exfiltrate data or permanently harm a users system will be immediately addressed by Mojang with a new full release without going through the preview system. I see no reason to create a policy on this when we have not to my knowledge actually had any issues with this in the past. We already have {{dangerous release}}, just put that on top of any release that is known (outside of NDA) to have something dangerous in it. Mudscape 👁 Image
talk 09:42, 17 October 2024 (UTC)

There's a separate section that defines vulnerability with the CIA triad, which I didn't include in the forum post.

We have had a problem with handling exploits, and it was discussed in the board meeting that I quoted above. A policy like this ensures that we have a response ready in case a serious issue arises, rather than putting together some reactive measure.

Although most multiplayer servers do run modded software, whether an issue is reproducible or not with modded really depends. Vanilla still represents a foundation upon which most modded environments are built, and it can't be said that such information would be useless. Singleplayer issue might be low impact, but I think that's an overgeneralization.

The dangerous release template is usually used to mark versions that leave world files corrupted, and this approach of "just throw a tag on it" just leaves too much room for ambiguity and future debate. GIM Dianliang233 T C 10:27, 17 October 2024 (UTC)

I think the drafted policy is mostly fine and acceptable. When I spoke with the board about this issue I spoke with need of balance the public mission of the wiki as well as security of users. What's important to me is that the drafted policy allows for description of ”vulnerability” after some time it has been actively exploited. While it might sound counterintuitive, I don't take for granted that Mojang will always fix security issues in timely manner, either because they might classify the issue as low priority and insignificant in their eyes or because they might consider some behavior not a security issue at all, in that case wiki shouldn't stay in deadlock and it is my belief it's in public interest to cover those mechanics if they have enough of value to the players as thay are part of the game.

The only thing I'm personally still a bit iffy about with the policy is what is defined as vulnerability. For me vulnerability is some exploit allowing for denial of service (taking down entire servers), causing significant performance issues (for multiplayer sessions), causing corruption of data or using the game to gain access of the system either of players or server hoster - basically anything that affects provided service on functional level or allows someone to break system security. Things such as item duplication glitches or other things giving advantage in-game never struck me as something that's worth covering under this label. I personally don't view those issues as ”critical”, they might break server's economy in some way, but it's still a video game so I don't really see the significance of this kind of action. For me breakage of integrity in mentioned CIA triad would be corrupting world map or other game files. Frisk (talk) 10:55, 17 October 2024 (UTC)

Item dupe definitely impacts integrity, albeit it's a rather low impact. CVE-2024-41565 shows that NVD considers it to be I:L. GIM Dianliang233 T C 11:37, 17 October 2024 (UTC)

NVD does not assess vulnerabilities, they are just an aggregator of reported vulnerabilities. The person who reported it (in the linked gist) is the one who declared I:L Mudscape 👁 Image
talk 12:42, 17 October 2024 (UTC)

NVD assesses vulnerabilities. GIM Dianliang233 T C 14:33, 17 October 2024 (UTC)

The enrichment process described is to correlate reports/patches/etc and does nothing to evaluate their legitimacy. See https://nvd.nist.gov/general/FAQ-Sections/General-FAQs#faqLink4 Mudscape 👁 Image
talk 14:51, 17 October 2024 (UTC)

"NVD enrichment efforts use the reference information provided with the CVE and any publicly available information at the time of enrichment to associate Reference Tags, Common Vulnerability Scoring System (CVSS) v4.0, CVSS v3.1, CWE, and CPE applicability statements." – [1]

The FAQ entry you mentioned is there to state that the NVD is completely synced with the upstream MITRE database and problems with CVE records should be directed to them instead of NVD. GIM Dianliang233 T C 15:02, 17 October 2024 (UTC)

It seems I am incorrect then. Although I find it hard to believe that anyone at NVD took a close enough look at the disclosure to determine it's validity. See https://lwn.net/Articles/944209/ Mudscape 👁 Image
talk 15:17, 17 October 2024 (UTC)

Thanks for creating this topic. I want to clarify that my brief discussion with Mojang was not a direct request by them of any kind and we shouldn't treat it as such. In the specific case we discussed, all information about the exploits was already public, but since the wiki has a fairly wide reach, it made the exploits more well-known, leading to some disappointment. Due to my conflict of interest (as both wiki editor/admin and Mojang bug tracker moderator) and the sensitive nature of this topic, I wanted to gather input from fellow board members on whether any action from the board specifically was necessary, which we determined not to be the case. I will refrain from giving any opinion on this topic myself. However, if it is desired for Mojang devs to give any input or feedback on this policy though, I can gather and relay that, as long as the community wishes for me to do so. | violine1101 ^(talk) 15:39, 17 October 2024 (UTC)

I think if you have any opinion on this you can feel free to add it. IMO feedback from Mojang is also welcome. GIM Dianliang233 T C 01:49, 18 October 2024 (UTC)

@violine1101: seeing this discussion has been dead for a while, could you ask Mojang about what they think? Also I don't think that there is really a conflict of interest of any sort (you won't gain/lose anything by commenting here) and I'd like to hear your take as well if possible. GIM Dianliang233 (talk) 04:24, 9 December 2024 (UTC)

In my opinion I have a conflict of interest because as a bug tracker moderator, I want to avoid exploits to become public knowledge, whereas as a wiki editor I don't want to censor information based on Mojang's decisions. The wiki is independent and should remain as such; my somewhat privileged position as bug tracker moderator does put me in a bit of an awkward situation here regarding exploits.

My personal opinion on the matter is that exploits shouldn't be documented on the wiki until a certain time (e.g. two weeks; 7 days seems a little short IMO) after they've been fixed to prevent damage to servers and such, but also that the wiki shouldn't restrict itself to only document information from the changelog. There's also some discussion on how to define exploit; on the bug tracker, any crash that can be intentionally caused by others and item duplication issues are considered as exploits, among others (like RCE exploits that'd also be considered exploits outside of Minecraft).

Fortunately, these situations where exploits are publicized happen rarely enough but in the cases where they do happen the wiki shouldn't contribute to any potential harm they might cause, so it's good to prepared, although ultimately it can be difficult to decide what actually is an exploit or not. Your draft seems like a well-thought-out proposal that does just that while keeping the wiki independent from Mojang. | violine1101 ^(talk) 18:47, 10 December 2024 (UTC)

I get why this policy is being proposed, and I agree with keeping certain critical vulnerabilities under wraps until they're fixed, but I'm not really in favor of censoring all information, especially for things like gameplay exploits. As Mudscape pointed out, most multiplayer servers run modded software, so these issues often won't even apply. Plus, like Frisk mentioned, there's a big difference between serious vulnerabilities that could affect security and stuff like item duplication, which doesn’t really cause harm outside of gameplay. I think we should be careful with how we handle actual security threats, but I don't see why we need to restrict info on every little bug or exploit, especially if it’s something that doesn’t pose any real danger. - 👁 Image
StizzurpXDD^(talk) 10:20, 9 December 2024 (UTC)

Thanks everyone for your input. I've updated the draft to address the concern regarding item duplication by exempting item dupes. GIM Dianliang233 (talk) 12:59, 14 December 2024 (UTC)

Strong oppose. I think that the wiki should be responsible to - this wiki shouldn't be responsible for anything. That's why Minecraft Wiki:General disclaimer exists.--Arina (she/her) 15:08, 28 January 2025 (UTC)

The general disclaimer is a legal disclaimer, but it doesn't absolve us of the ethical responsibility to consider how the information we publish could be used. I believe it's in the best interest of the community to have a consistent and proactive policy. GIM Dianliang233 (talk) 16:59, 28 January 2025 (UTC)

it doesn't absolve us of the ethical responsibility to consider how the information we publish could be used - why shouldn't it? Wikipedia has suicide methods category, for example.--Arina (she/her) 19:35, 28 January 2025 (UTC)

The comparison to Wikipedia's suicide methods isn't a fitting analogy. Suicide-related information is already widely known and accessible through many sources. Minecraft vulnerabilities often involve newly discovered exploits that aren't public knowledge. The proposed policy isn't about permanent censorship - it's about giving the community reasonable time to update before detailed information becomes public. GIM Dianliang233 (talk) 03:49, 30 January 2025 (UTC)

Support Why was this abandoned? 2401:4900:A501:E303:0:0:25A8:63D 10:08, 7 March 2025 (UTC)