You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Performing calculations involving the size of potentially large strings or slices can result in an overflow (for signed integer types) or a wraparound (for unsigned types). An overflow causes the result of the calculation to become negative, while a wraparound results in a small (positive) number. This can cause further issues. If, for the result is then used in an allocation, it will cause a runtime panic if it is negative, and allocate an unexpectedly small buffer otherwise.
POC
In the following vulnerable, assume that there is a function encryptBuffer that encrypts byte slices whose length must be padded to be a multiple of 16. The function encryptValue provides a convenience wrapper around this function: when passed an arbitrary value, it first encodes that value as JSON, pads the resulting byte slice, and then passes it to encryptBuffer.
When passed a value whose JSON encoding is close to the maximum value of type int in length, the computation of size will overflow, producing a negative value. When that negative value is passed to make, a runtime panic will occur.
To guard against this, the function should be improved to check the length of the JSON-encoded value. here is a version of encryptValue that ensures the value is no larger than 64 MB, which fits comfortably within an int and avoids the overflow:
Always guard against overflow in arithmetic operations involving potentially large numbers by doing one of the following:
Validate the size of the data from which the numbers are computed.
Define a guard on the arithmetic expression, so that the operation is performed only if the result can be known to be less than, or equal to, the maximum value for the type.
Use a wider type (such as uint64 instead of int), so that larger input values do not cause overflow.
fleet-server/internal/pkg/danger/buf.go
Line 36 in ba68a24
Performing calculations involving the size of potentially large strings or slices can result in an overflow (for signed integer types) or a wraparound (for unsigned types). An overflow causes the result of the calculation to become negative, while a wraparound results in a small (positive) number. This can cause further issues. If, for the result is then used in an allocation, it will cause a runtime panic if it is negative, and allocate an unexpectedly small buffer otherwise.
POC
In the following vulnerable, assume that there is a function
encryptBuffer
that encrypts byte slices whose length must be padded to be a multiple of 16. The functionencryptValue
provides a convenience wrapper around this function: when passed an arbitrary value, it first encodes that value as JSON, pads the resulting byte slice, and then passes it toencryptBuffer
.When passed a value whose JSON encoding is close to the maximum value of type
int
in length, the computation ofsize
will overflow, producing a negative value. When that negative value is passed tomake
, a runtime panic will occur.To guard against this, the function should be improved to check the length of the JSON-encoded value. here is a version of
encryptValue
that ensures the value is no larger than 64 MB, which fits comfortably within anint
and avoids the overflow:Recommendation
Always guard against overflow in arithmetic operations involving potentially large numbers by doing one of the following:
uint64
instead ofint
), so that larger input values do not cause overflow.References
Integer overflow.
Making slices, maps and channels.
CWE-190.
For confirmed bugs, please report:
The text was updated successfully, but these errors were encountered: