Summary

The specification and tests are missing a specific prohibition for extraneous characters before and after the allowed portion of a "$numberDouble" value. As a result, drivers do not have uniform parsing behavior.

For example, the Python driver allows an extra "+" before "Infinity", and it allows whitespace before and after the value:

>>> loads('{"$numberDouble": "+Infinity"}')
inf
>>> loads('{"$numberDouble": "    3.14159     "}')
3.14159
>>> 

The C driver allows leading space, "+Infinity", abbreviations of +/- "inf", and it currently allows arbitrary characters to appear after any valid sequence. For example, this is currently valid extjson in Libbson:

{"$numberDouble": "  3.14159 and so on"}, 0.0, {"$numberDouble": "+Informational"} 

Parses as: (3.141590118408203, 0.0, inf).

This is arguably just a bug in _bson_json_parse_double()'s use of strtod(), but the spec doesn't specifically disallow it and there are no unified tests which cover these cases.

Motivation

Who is the affected end user?

Application developers may be affected by ambiguous requirements. This likely has no security impact on its own, but in combination with more serious flaws this may be used as part of a system to target exploits for specific client libraries.

How does this affect the end user?

Behavior will be inconsistent between client libraries, causing security or reliability problems when multiple client library types are in use on the same data.

How likely is it that this problem or use case will occur?

Untested edge case.

If the problem does occur, what are the consequences and how severe are they?

Errors or behavior divergence in data parsing.

Is this issue urgent?

Not urgent.

Is this ticket required by a downstream team?

Unknown.

Is this ticket only for tests?

The requested tests would immediately show driver bugs.

Acceptance Criteria

New bson_corpus tests should include cases for invalid $numberDouble strings, and these tests should pass on all drivers that handle extended JSON.