dxbjavid opened a new pull request, #3609:
URL: https://github.com/apache/thrift/pull/3609

   the rust binary protocol reader enforces the configured max_string_size 
everywhere it reads a length-prefixed value, except one. when 
read_message_begin handles a non-strict message (the legacy mode kept for 
senders that don't write the protocol-version header) it takes the leading four 
bytes as the name length and allocates the name buffer straight from that wire 
value, skipping the check that read_bytes and read_string both apply. the value 
is attacker-controlled, so a peer talking to a server in non-strict mode can 
make a four-byte length drive an allocation of up to about two gigabytes, which 
quietly defeats the default 100 MiB string limit for that field. i noticed it 
while comparing the non-strict path with read_bytes and with the compact 
reader, which routes its message name through read_string and so stays bounded. 
the fix runs the name length through the same max_string_size check before 
allocating and returns a SizeLimit error otherwise. i kept it inside 
read_message_beg
 in so the rest of the path is unchanged, and added a regression test beside 
the existing string-limit ones.
   
   - [ ] Did you create an [Apache 
Jira](https://issues.apache.org/jira/projects/THRIFT/issues/) ticket?  
([Request account here](https://selfserve.apache.org/jira-account.html), not 
required for trivial changes)
   - [ ] If a ticket exists: Does your pull request title follow the pattern 
"THRIFT-NNNN: describe my issue"?
   - [x] Did you squash your changes to a single commit?  (not required, but 
preferred)
   - [x] Did you do your best to avoid breaking changes?  If one was needed, 
did you label the Jira ticket with "Breaking-Change"?
   - [ ] If your change does not involve any code, include `[skip ci]` anywhere 
in the commit message to free up build resources.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to