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
This is a followup to #130. with my apologies for ignoring this for so long.
A very recent simple-binary-encoding build from the CME templates generated MDIncrementalRefreshBook46.h, which does indeed contain some bounds checking, but I think it's incomplete. In the generated file, there's a class MDIncrementalRefreshBook46::NoOrderIDEntries, and that contains:
inline NoOrderIDEntries &next()
{
if (m_index >= m_count)
{
throwstd::runtime_error("index >= count [E108]");
}
m_offset = *m_positionPtr;
if (SBE_BOUNDS_CHECK_EXPECT(((m_offset + m_blockLength) > m_bufferLength), false))
{
throwstd::runtime_error("buffer too short for next group index [E108]");
}
*m_positionPtr = m_offset + m_blockLength;
++m_index;
return *this;
}
dimensions.blockLength() is an untrusted value, although it happens to be an sbe_uint16_t despite being stored in an sbe_uint64_t field, so it's constrained. This dodges a bullet: otherwise m_offset + m_blockLength could overflow. I didn't check whether other classes might not be so lucky, though.
But there's a more fundamental issue: nothing seems to check that m_blockLength is appropriate. For example:
If there are fewer than 8 bytes in the buffer, this will overflow. But m_blockLength could easily be 0 or 1 or 7, and the bounds check in next() would pass with fewer than 8 bytes in the buffer.
This is extra complicated because of the actingVersion mechanism:
blockLength == 8 is valid for NoOrderIDEntries if actingVersion < 7, but if actingVersion >= 7, then this requires a blockLength of at least 16! And checking that from user code (as opposed to the generated headers) would get very awkward very quickly.
The text was updated successfully, but these errors were encountered:
This is a followup to #130. with my apologies for ignoring this for so long.
A very recent simple-binary-encoding build from the CME templates generated
MDIncrementalRefreshBook46.h
, which does indeed contain some bounds checking, but I think it's incomplete. In the generated file, there's a classMDIncrementalRefreshBook46::NoOrderIDEntries
, and that contains:And next() looks like this:
dimensions.blockLength()
is an untrusted value, although it happens to be an sbe_uint16_t despite being stored in an sbe_uint64_t field, so it's constrained. This dodges a bullet: otherwisem_offset + m_blockLength
could overflow. I didn't check whether other classes might not be so lucky, though.But there's a more fundamental issue: nothing seems to check that m_blockLength is appropriate. For example:
If there are fewer than 8 bytes in the buffer, this will overflow. But m_blockLength could easily be 0 or 1 or 7, and the bounds check in
next()
would pass with fewer than 8 bytes in the buffer.This is extra complicated because of the actingVersion mechanism:
blockLength == 8
is valid forNoOrderIDEntries
if actingVersion < 7, but if actingVersion >= 7, then this requires ablockLength
of at least 16! And checking that from user code (as opposed to the generated headers) would get very awkward very quickly.The text was updated successfully, but these errors were encountered: