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.

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

Read smaller frames to workaround OpenSSL bug #5115

Merged
merged 1 commit into from
Jul 26, 2021

Conversation

jakirkham
Copy link
Member

@jakirkham jakirkham commented Jul 24, 2021

As older versions of OpenSSL (in particular 1.0.2) have limitations on the size of buffers they can work with, take small views into our larger buffer and read those in instead. This should keep the buffer sizes more manageable for OpenSSL.

Closes #4538

@@ -35,6 +38,7 @@


MAX_BUFFER_SIZE = MEMORY_LIMIT / 2
C_MAX_INT = 256 ** ctypes.sizeof(ctypes.c_int) // 2 - 1
Copy link
Member Author

@jakirkham jakirkham Jul 24, 2021

Choose a reason for hiding this comment

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

AFAICT the limit to what OpenSSL can handle is based on the maximum value of int in C (as used by num bytes in this call). This is implementation specific. So am using ctypes to figure that out.

Copy link
Member Author

@jakirkham jakirkham Jul 24, 2021

Choose a reason for hiding this comment

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

Just to back this up, the following C program (on my machine) gives this result

#include <stdio.h>
#include <limits.h>

int main() {
	printf("%lu\n", INT_MAX);
	return 0;
}
2147483647

Using this Python code (on my machine), I get the same result.

import ctypes

print(256 ** ctypes.sizeof(ctypes.c_int) // 2 - 1)

Copy link
Member Author

Choose a reason for hiding this comment

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

Renamed the variable to C_INT_MAX. Otherwise the code is the same

@jakirkham jakirkham force-pushed the wrk_ssl_bug branch 2 times, most recently from 54a734b to 14247d5 Compare July 24, 2021 02:47
@jakirkham jakirkham force-pushed the wrk_ssl_bug branch 3 times, most recently from 420bf97 to ca30c78 Compare July 24, 2021 06:42
As older versions of OpenSSL (in particular 1.0.2) have limitations on
the size of buffers they can work with, take small views into our larger
buffer and read those in instead. This should keep the buffer sizes more
manageable for OpenSSL.
@jakirkham
Copy link
Member Author

Looks like the one CI test failure is a known flaky test ( #4957 )

@jakirkham jakirkham changed the title [WIP] Read smaller frames to workaround OpenSSL bug Read smaller frames to workaround OpenSSL bug Jul 26, 2021
@jakirkham jakirkham marked this pull request as ready for review July 26, 2021 19:04
@jakirkham
Copy link
Member Author

cc @fjetter

@mrocklin
Copy link
Member

@jakirkham if you're confident that this is a good fix I'm more than happy to trust you on it. Please merge at will if so.

@jakirkham jakirkham merged commit 145e8aa into dask:main Jul 26, 2021
@jakirkham jakirkham deleted the wrk_ssl_bug branch July 26, 2021 20:25
@jakirkham jakirkham mentioned this pull request Jul 28, 2021
3 tasks
@jakirkham
Copy link
Member Author

Doing the same thing for the write code path in PR ( #5134 )

mrocklin added a commit to mrocklin/distributed that referenced this pull request Jul 29, 2021
Supercedes dask#5134

Copying over the summary of that PR

Works around the OpenSSL 1.0.2 bug demonstrated in issue ( dask#4538 ), except unlike PR ( dask#5115 ) which did this for reading, this does the same thing for writing. The error may be less likely to show up in the write path (as frames may simply be smaller than this limit). Still it seems like a good idea to protect against OverflowErrors from OpenSSL
jrbourbeau pushed a commit that referenced this pull request Jul 29, 2021
Supercedes #5134

Copying over the summary of that PR

Works around the OpenSSL 1.0.2 bug demonstrated in issue ( #4538 ), except unlike PR ( #5115 ) which did this for reading, this does the same thing for writing. The error may be less likely to show up in the write path (as frames may simply be smaller than this limit). Still it seems like a good idea to protect against OverflowErrors from OpenSSL
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.

Integer overflow in TCP comm
2 participants