Skip to content

Safer ExternalPermutationWorkerFactory connections#10257

Open
niloc132 wants to merge 2 commits intogwtproject:mainfrom
niloc132:10256-safer-epwf-test
Open

Safer ExternalPermutationWorkerFactory connections#10257
niloc132 wants to merge 2 commits intogwtproject:mainfrom
niloc132:10256-safer-epwf-test

Conversation

@niloc132
Copy link
Copy Markdown
Member

Cookies are now sent/received as 32 ascii chars before any ObjectOutputStream data is sent, and the server validates before returning the socket. An invalid socket is closed and ignored, and the next valid socket will be used instead.

Also improved cookie randomness source.

Fixes #10256

Cookies are now sent/received as 32 ascii chars before any
ObjectOutputStream data is sent, and the server validates before
returning the socket. An invalid socket is closed and ignored, and the
next valid socket will be used instead.

Also improved cookie randomness source.

Fixes gwtproject#10256
@niloc132 niloc132 marked this pull request as ready for review February 12, 2026 19:21
Copy link
Copy Markdown
Member

@vegegoku vegegoku left a comment

Choose a reason for hiding this comment

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

LGTM, might need to fix the checkstyle warnings.

if (--accepts == 0) {
sock.close();
sock = null;
while (!validCookies.isEmpty()) {
Copy link
Copy Markdown
Collaborator

@zbynek zbynek Mar 11, 2026

Choose a reason for hiding this comment

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

The old code did throw an error on invalid "cookie", this seems to retry until a valid "cookie" is sent, is that an intentional change?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yes - rather than permit a "denial of service" where an attacking client can guess the port but get the cookie wrong and thus kill the compile job, this implementation just ignores the client since they aren't connecting correctly anyway.

If I've done this right, we still warn about the bad connection, but we don't let it kill the compiler. The only way kill the job is if it was the right client, but somehow had the wrong cookie, which would have failed in the old code too.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Restating this slightly:

  • "good" clients will effectively never have this issue, but if they do, we will get a warning, and the client itself will crash out.
  • "bad" clients will no longer be able to just guess one of the outstanding cookies and take down the server. Technically a malicious client could guess and guess and never be rate limited... but they have 128 bits of search space to work through, which is infeasible.

zbynek
zbynek previously approved these changes Mar 11, 2026
@niloc132 niloc132 added this to the 2.14 milestone Mar 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Investigate options to make ExternalPermutationWorkerFactory more safe

3 participants