[ 
https://issues.apache.org/jira/browse/TINKERPOP-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guian Gumpac updated TINKERPOP-3281:
------------------------------------
    Description: 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.  (was: 
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.)

> 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)

Reply via email to