Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial draft of the Session ID security proposal #8

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

Initial draft of the Session ID security proposal #8

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
5cfc738
Initial draft of the proposal
pandaninjas Jun 17, 2023
b496676
More implementation details
pandaninjas Jun 17, 2023
48b39ea
Remove opinionated DRM section
pandaninjas Jun 19, 2023
541f209
Add potential solution for DRM issue
pandaninjas Jun 24, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions docs/sandboxing/session-id/proposal.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
# Session ID Security Proposal

This proposal seeks to sandbox tokens used to log in to Minecraft servers, which are called session IDs.

## Background

Currently, session IDs are stored on the Minecraft client. The client presents the session IDs to Mojang's session server when logging into a server. This configuration presents several issues when it comes to security. A malicious Minecraft mod could potentially read the session IDs from the process, and send it to its owner. This would allow the malware spreader to use the victim's session IDs to log in to Minecraft servers for 24 hours. There is no way to invalidate the session ID, and the only recourse the victim has is to disable multiplayer in their Xbox settings.

## Proposed solution

For clarity, we will refer to Java process that runs Minecraft as the Minecraft process, and the other process as the session ID process.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "the other process" refer to? I don't think this is explicit enough to clarify.


At some point during or before the launch, the session ID is given to the session ID process. The session ID is them removed from the Minecraft process. The Minecraft process then has `com.mojang.authlib.yggdrasil.YggdrasilMinecraftSessionService#joinServer` rerouted to ask the session ID process to join servers instead. The session ID process then uses the session ID to contact the Mojang session servers.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would prevent a malicious mod from talking to the session ID process itself? Obviously, the solution presented here would secure the token from being exfiltrated. But if all an attacker needs is brief access to the account (which is likely the case if they are targeting a session token) all a malicious mod would need to do is "join" a server directly in the local client and do some malicious actions.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a concern with the current implementation, however it is rather difficult to secure it against this case. A solution to this problem would be to have the session ID process handle the entire process of logging into Minecraft servers, with the process asking the user if they want to join the server. However this solution is more difficult to implement, and I believe that the current solution is a large improvement over the current situation

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This proposal would only limit the scope of the token to the runtime of the client. That is a net gain. However it could be much simpler if launchers could revoke session tokens after the game was closed. We would achieve almost the same effect that way


If sandboxing is being used, the session ID process ideally should be separated by from the Minecraft process while still being able to communicate with it.

## Reasons for this solution

This solution stays secure even if the Minecraft process is fully under the control of an attacker.

## Pros

This solution is relatively simple to implement and can work well within the current modding framework. It is not invasive and keeps multiplayer/multiplayer verification working while being totally invisible to the client.

## Cons

This solution requires modifying Authlib, which is not released under an open source licence. This would present copyright issues, which would make implementation more difficult. In addition, Authlib is liable to change because Mojang has made no guarantees about its stability

## Implementation details

The Minecraft and the session ID process should be separated by a sandbox, but that is beyond the scope of this proposal. If the session ID process is written in Java, care must be taken in order to ensure that it cannot be attached to. This can be done with the JVM flag `+XX:DisableAttachMechanism`.

Implementations of this system must not use the arguments to a process to pass the session ID, as it may expose the Session ID through OS mechanisms such as the procfs or Windows' process API

## Alternatives

Using a `URLStreamHandler` was considered instead, but this presents a few issues.
- Mods may set their own URLStreamHandler, which would then cause logging into online mode servers to mysteriously fail
- URLStreamHandlers may slow down networking

## Concerns

### DRM
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire section is problematic, as it wasn't reviewed by someone with the required legal skills to decide whether it is a DRM circumvention or not. In general, modifying DRMs, no matter what the modification is, will be considered as unlawful. In the absence of such reviewing, we should stay caution and not arbitrarily decide something is within the law without careful reviewing.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could not present this to Mojang in good faith with these assertions - it's not up to us to decide and "the authors believe" is not an OK thing to say when the MMPA itself does not believe.


Because this modifies Authlib, it could be seen as modifying DRM by potentially allowing you to choose a different session server and bypass certain protections.

#### Solution

A solution to this issue is to have the client independently verify that the server has a session ID valid for Minecraft. This can be achieved with a system when on connection the Minecraft process asks the session ID process to join a 'server', and speicifying a random UUID (without dashes) as the server name. Then the client can independently verify that the server actually controls a valid Minecraft session ID by calling Mojang's API or by using `com.mojang.authlib.minecraft.MinecraftSessionService#hasJoinedServer` to verify that the server truly holds a valid session ID

## Implementations

[NoSession](https://github.com/thefightagainstmalware/NoSession) is an implementation of a similar system. Full disclosure: One of the authors of this proposal the maintainer of this implementation.