[ntcore] Clarification and Safeguards for pub/subuid Constraints in NetworkTables
#7679
Comments
cjlawson02
changed the title
pub/subuid Constraints in NetworkTables
cjlawson02
changed the title
pub/subuid Constraints in NetworkTablespub/subuid Constraints in NetworkTables
|
I will document and add implementation validation of the current signed 32-bit values (at a minimum, fix the crash). At some point (e.g. for 2027, when the platform goes to 64-bit), I may add support for signed 64-bit values. I do not plan on changing the value type to strings or unsigned integers. Security is not a concern in our environment, but we do like to avoid crashes. |
|
Investigating further, the 32-bit range won't support the full 32-bit range, because (as you discovered) some of these values are used for sentinel values in the internal implementation. So the spec will likely say something like the server "should" support signed 32-bit values, but may be constrained to smaller ranges based on implementation. It will also recommend that clients use as small of values as possible for pubuid's, because those IDs are used in the MessagePack messages from the client to server (so larger values mean they take more space and time to encode/decode for every message). |
|
Does the client need to worry about a collision with another pubuid, or could it just increment from 0? |
|
pubuid's are client-unique; there is no possibility of colliding with another client's pubuids. So it's perfectly fine to just increment from 0. |
Describe the bug
Hi team, the
pubuidandsubuidfor NetworkTables publishers are constrained to fit within a signed 32-bit integer space (source). However, this constraint is not explicitly documented in the relevant sections of the networktables4.adoc. Exceeding this range can cause unexpected behavior, including crashes.To Reproduce
Steps to reproduce the behavior:
pubuidexceeding the signed 32-bit positive integer range.[{"method":"publish","params":{"type":"string","name":"/MyTable/myvalue","pubuid":2147483647,"properties":{}}}]Expected behavior
The
pubuidshould be validated and rejected if it exceeds the supported range.Desktop (please complete the following information):
Additional context
This issue became evident when testing with values near and beyond the signed 32-bit limit:
A
pubuidof2147483646worked as expected.A
pubuidof2147483647caused a crash, however not all integers above the max cause the code to crash.the UID's are defined as
inthere: Message.hPotential Security Concern
A malicious actor with websocket access could exploit this limitation to trigger denial-of-service scenarios by sending invalid publish requests, such as:
[{"method":"publish","params":{"type":"string","name":"/MyTable/myvalue","pubuid":2147483647,"properties":{}}}]Suggested Solutions
pubuidandsubuidto unsigned integers with server-side validation.pubuidandsubuidto support strings for greater flexibility.Additionally, the documentation should be updated to clearly specify the current constraint, preventing similar issues for developers and mitigating security risks.
The text was updated successfully, but these errors were encountered: