[
https://issues.apache.org/jira/browse/TINKERPOP-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18102509#comment-18102509
]
ASF GitHub Bot commented on TINKERPOP-3281:
-------------------------------------------
kenhuuu commented on code in PR #3610:
URL: https://github.com/apache/tinkerpop/pull/3610#discussion_r3730688568
##########
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/binary/types/SimpleTypeSerializer.java:
##########
@@ -68,6 +68,39 @@ public T readValue(final Buffer buffer, final
GraphBinaryReader context, final b
*/
protected abstract T readValue(final Buffer buffer, final
GraphBinaryReader context) throws IOException;
+ /**
+ * Reads a length or element-count prefix and validates it before it is
used to size an allocation. A negative
+ * value, or one larger than the number of bytes actually remaining in the
buffer, cannot be legitimate since
+ * every counted element or byte needs at least one byte on the wire, so
it is rejected rather than allowed to
+ * drive a large allocation from a small message.
+ */
+ protected static int readSizePrefix(final Buffer buffer) throws
IOException {
+ if (buffer.readableBytes() < Integer.BYTES)
+ throw new IOException(String.format(
Review Comment:
We should probably throw SerializationException from serializers as that is
already a type of IOException
> GraphBinary deserializer unbounded pre-allocation from length prefixes
> ----------------------------------------------------------------------
>
> Key: TINKERPOP-3281
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3281
> Project: TinkerPop
> Issue Type: Bug
> Components: io
> Affects Versions: 4.0.0, 3.7.7, 3.8.2
> Reporter: Guian Gumpac
> Priority: Major
>
> GraphBinary value types size a heap allocation (or bound a read loop) from a
> 4-byte length/count prefix before the payload is read or checked against the
> bytes actually remaining. Because GraphBinary is deserialized
> pre-authentication on the default wire path, a tiny malformed frame (~6-21
> bytes) can declare a multi-hundred-megabyte to multi-gigabyte allocation and
> drive Gremlin Server to OutOfMemoryError. maxContentLength bounds the frame,
> not a single declared length, and the binary decoder catches only
> SerializationException, so the OOM escapes. The surface is symmetric: a
> malicious or on-path server can OOM a connecting driver the same way. The
> same shape recurs across String, Collection (list/set), Map, BigInteger,
> InetAddress, ByteBuffer, Bytecode, P, Tree, graph and BulkSet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
