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
punycode: use WPACKET for building the result #19591
Conversation
aa0328a
to
6006e28
Compare
dee6213
to
3a6b349
Compare
We might want to cherry pick the x509 commit to 3.0. |
3a6b349
to
482cf71
Compare
Approved assuming CI passes. |
Would it be asked too much to add a simple fuzzing test, as suggested by @hannob on Twitter? |
In a separate PR ? |
I'd go for a separate PR as some tinkering might be needed to make CI happy and it's not related to the substance of this change, even though it's related to the CVE. |
A separate PR is ok, as long as it happens. We should not make the same mistake twice. |
30334a4
to
a2a3070
Compare
I've changed my mind since that time - it is a little bit heavy - could we make it leaner? |
I'd need to write an overflow safe buffer library that doesn't do any memory allocation (i.e. it isn't WPACKET but something new). I'd leave out the sub packet processing etc. Essentially it would be append only with memcpy, strcpy, put byte, get length & probably a few others. The punycode decoder requires an insert operations and I'm not currently doing this with WPACKET because it's not supported. Bad range checking in this code was one of the CVEs 😞 |
You did not explain before why it was heavy.. |
Can you do a quick test of this against the old dodgy code as well? |
The fuzzing does crash the old code. See the two corpora I already included. |
I rather suspect this is getting the onus backwards. |
This has one zalloc overhead. Making it leaner is going to require quite a bit of effort. I'm not convinced it worthwhile especially given the heaviness of certificate processing where it occurs. |
If it was added I would expect that WPACKET might use the lightweight layer. (Having any type of error in the new code would not be a good thing though :)) |
Is it worth trying to do some benchmarks and see if there's an actual problem? Some of the previous problems have been because of determination to increase performance but that's not always the right tradeoff (see e.g. the AVX512 discussion we're having). Sometimes safety costs a bit more and there's already been a problem in the area this PR is designed to solve, i.e. this is obviously going to be a bit slower, but is it problematically slower? Could also maybe let it sit in master and see how things go, but not backport it. |
There is currently no intention to backport it to 3.0 as this is a refactoring not a bug fix. |
This surely can be merged without changing WPACKET. This is not performance critical peace of code anyway. It's just that if we want to use WPACKET truly everywhere we should first consider to make it leaner for the cases where the output buffer is static and there is no need for subpacket support. |
It needs approvals before it can merge... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just doc nits
Ping for second review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Add test for `.' overflows, remove the output size argument from ossl_a2ulabel() since it was never used and greatly complicated the code. Convert ossl_a2ulabel() to use WPACKET for building the output string. Update the documentation to match the new definition of ossl_a2ulabel(). x509: let punycode handle the '\0' string termination. Saves a memset(3) and some size fiddling. Also update to deal with the modified parameters. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from #19591)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from #19591)
merged. |
Add test for `.' overflows, remove the output size argument from ossl_a2ulabel() since it was never used and greatly complicated the code. Convert ossl_a2ulabel() to use WPACKET for building the output string. Update the documentation to match the new definition of ossl_a2ulabel(). x509: let punycode handle the '\0' string termination. Saves a memset(3) and some size fiddling. Also update to deal with the modified parameters. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from #19591) (cherry picked from commit 905ba92)
Add test for `.' overflows, remove the output size argument from ossl_a2ulabel() since it was never used and greatly complicated the code. Convert ossl_a2ulabel() to use WPACKET for building the output string. Update the documentation to match the new definition of ossl_a2ulabel(). x509: let punycode handle the '\0' string termination. Saves a memset(3) and some size fiddling. Also update to deal with the modified parameters. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from openssl#19591)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from openssl#19591)
Removing the recently added bounds checking code in favour of our WPACKET code.
Added a unit test that fails before the recent CVE fix & passes with it. This PR isn't changing the behaviour per say.
Added a notional number of bytes that were attempted to be written to WPACKET, so the required space return is possible.
Converted the punycode code to use WPACKET.
Added a fuzzer
documentation is added or updated
tests are added or updated