github.com/gagliardetto/binary

Version	Released
`v0.8.0` minor	Apr 01, 2024
`v0.7.9` patch	Jun 26, 2023
`v0.7.8` patch	Dec 11, 2022
`v0.7.7` patch	Nov 23, 2022
`v0.7.6` patch	Oct 30, 2022
`v0.7.5` patch	Oct 30, 2022
`v0.7.4` patch	Oct 26, 2022
`v0.7.3` patch	Oct 22, 2022
`v0.7.2` patch	Oct 02, 2022
`v0.7.1` patch	Aug 28, 2022
`v0.7.0` minor 1 CVE	Aug 28, 2022
`v0.6.1` patch 1 CVE	Feb 01, 2022
`v0.6.0` minor 1 CVE	Feb 01, 2022
`v0.5.2` patch 1 CVE	Jan 05, 2022
`v0.5.1` patch 1 CVE	Jan 05, 2022
`v0.5.0` minor 1 CVE	Oct 10, 2021
`v0.4.5` patch 1 CVE	Oct 02, 2021
`v0.4.4` patch 1 CVE	Sep 19, 2021
`v0.4.3` patch 1 CVE	Sep 10, 2021
`v0.4.2` initial 1 CVE	Sep 10, 2021

v0.8.0 minor

Apr 01, 2024

v0.7.9 patch

Jun 26, 2023

v0.7.8 patch

Dec 11, 2022

v0.7.7 patch

Nov 23, 2022

v0.7.6 patch

Oct 30, 2022

v0.7.5 patch

Oct 30, 2022

v0.7.4 patch

Oct 26, 2022

v0.7.3 patch

Oct 22, 2022

v0.7.2 patch

Oct 02, 2022

v0.7.1 patch

Aug 28, 2022

v0.7.0 minor

1 CVE

CVE-2022-36078 GHSA-4p6f-m4f9-ch88 GO-2022-0963 Sep 16, 2022

Binary vulnerable to Slice Memory Allocation with Excessive Size Value

8.8 / 10

High

Network Low None Required Unchanged High High High

Impact

What kind of vulnerability is it? Who is impacted?

The vulnerability is a memory allocation vulnerability that can be exploited to allocate slices in memory with (arbitrary) excessive size value, which can either exhaust available memory or crash the whole program.

When using github.com/gagliardetto/binary to parse unchecked (or wrong type of) data from untrusted sources of input (e.g. the blockchain) into slices, it's possible to allocate memory with excessive size.

When dec.Decode(&val) method is used to parse data into a structure that is or contains slices of values, the length of the slice was previously read directly from the data itself without any checks on the size of it, and then a slice was allocated. This could lead to an overflow and an allocation of memory with excessive size value.

Example:

package main

import (
	"github.com/gagliardetto/binary" // any version before v0.7.1 is vulnerable
	"log"
)

type MyStruct struct {
	Field1 []byte // field is a slice (could be a slice of any type)
}

func main() {
	// Let's assume that the data is coming from the blockchain:
	data := []byte{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
	
	var val MyStruct
	// - To determine the size of the val.Field1 slice, the decoder will read the length
	//   of the slice from the data itself without any checks on the size of it.
	//
	// - This could lead to an allocation of memory with excessive size value.
	//   Which means: []byte{0x01, 0x02, 0x03, 0x04} will be read as the length
	//   of the slice (= 67305985) and then an allocation of memory with 67305985 bytes will be made.
	//
	dec := binary.NewBorshDecoder(data)
	err := dec.Decode(&val)  // or binary.UnmarshalBorsh(&val, data) or binary.UnmarshalBin(&val, data) etc.
	if err != nil {
		log.Fatal(err)
	}
}

Patches

Has the problem been patched? What versions should users upgrade to?

The vulnerability has been patched in github.com/gagliardetto/binary v0.7.1

Users should upgrade to v0.7.1 or higher.

To upgrade to v0.7.1 or higher, run:

go get github.com/gagliardetto/binary@v0.7.1

# or

go get github.com/gagliardetto/binary@latest

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

A workaround is not to rely on the dec.Decode(&val) function to parse the data, but to use a custom UnmarshalWithDecoder() method that reads and checks the length of any slice.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in github.com/gagliardetto/binary
DM me on twitter

Fixed in


          0.7.1

References

Updated Nov 08, 2023 · Source: OSV.dev

Aug 28, 2022

v0.6.1 patch

1 CVE

CVE-2022-36078 GHSA-4p6f-m4f9-ch88 GO-2022-0963 Sep 16, 2022

Binary vulnerable to Slice Memory Allocation with Excessive Size Value

8.8 / 10

High

Network Low None Required Unchanged High High High

Impact

What kind of vulnerability is it? Who is impacted?

The vulnerability is a memory allocation vulnerability that can be exploited to allocate slices in memory with (arbitrary) excessive size value, which can either exhaust available memory or crash the whole program.

When using github.com/gagliardetto/binary to parse unchecked (or wrong type of) data from untrusted sources of input (e.g. the blockchain) into slices, it's possible to allocate memory with excessive size.

When dec.Decode(&val) method is used to parse data into a structure that is or contains slices of values, the length of the slice was previously read directly from the data itself without any checks on the size of it, and then a slice was allocated. This could lead to an overflow and an allocation of memory with excessive size value.

Example:

package main

import (
	"github.com/gagliardetto/binary" // any version before v0.7.1 is vulnerable
	"log"
)

type MyStruct struct {
	Field1 []byte // field is a slice (could be a slice of any type)
}

func main() {
	// Let's assume that the data is coming from the blockchain:
	data := []byte{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
	
	var val MyStruct
	// - To determine the size of the val.Field1 slice, the decoder will read the length
	//   of the slice from the data itself without any checks on the size of it.
	//
	// - This could lead to an allocation of memory with excessive size value.
	//   Which means: []byte{0x01, 0x02, 0x03, 0x04} will be read as the length
	//   of the slice (= 67305985) and then an allocation of memory with 67305985 bytes will be made.
	//
	dec := binary.NewBorshDecoder(data)
	err := dec.Decode(&val)  // or binary.UnmarshalBorsh(&val, data) or binary.UnmarshalBin(&val, data) etc.
	if err != nil {
		log.Fatal(err)
	}
}

Patches

Has the problem been patched? What versions should users upgrade to?

The vulnerability has been patched in github.com/gagliardetto/binary v0.7.1

Users should upgrade to v0.7.1 or higher.

To upgrade to v0.7.1 or higher, run:

go get github.com/gagliardetto/binary@v0.7.1

# or

go get github.com/gagliardetto/binary@latest

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

A workaround is not to rely on the dec.Decode(&val) function to parse the data, but to use a custom UnmarshalWithDecoder() method that reads and checks the length of any slice.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in github.com/gagliardetto/binary
DM me on twitter

Fixed in


          0.7.1

References

Updated Nov 08, 2023 · Source: OSV.dev

Feb 01, 2022

v0.6.0 minor

1 CVE

CVE-2022-36078 GHSA-4p6f-m4f9-ch88 GO-2022-0963 Sep 16, 2022

Binary vulnerable to Slice Memory Allocation with Excessive Size Value

8.8 / 10

High

Network Low None Required Unchanged High High High

Impact

What kind of vulnerability is it? Who is impacted?

The vulnerability is a memory allocation vulnerability that can be exploited to allocate slices in memory with (arbitrary) excessive size value, which can either exhaust available memory or crash the whole program.

When using github.com/gagliardetto/binary to parse unchecked (or wrong type of) data from untrusted sources of input (e.g. the blockchain) into slices, it's possible to allocate memory with excessive size.

When dec.Decode(&val) method is used to parse data into a structure that is or contains slices of values, the length of the slice was previously read directly from the data itself without any checks on the size of it, and then a slice was allocated. This could lead to an overflow and an allocation of memory with excessive size value.

Example:

package main

import (
	"github.com/gagliardetto/binary" // any version before v0.7.1 is vulnerable
	"log"
)

type MyStruct struct {
	Field1 []byte // field is a slice (could be a slice of any type)
}

func main() {
	// Let's assume that the data is coming from the blockchain:
	data := []byte{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
	
	var val MyStruct
	// - To determine the size of the val.Field1 slice, the decoder will read the length
	//   of the slice from the data itself without any checks on the size of it.
	//
	// - This could lead to an allocation of memory with excessive size value.
	//   Which means: []byte{0x01, 0x02, 0x03, 0x04} will be read as the length
	//   of the slice (= 67305985) and then an allocation of memory with 67305985 bytes will be made.
	//
	dec := binary.NewBorshDecoder(data)
	err := dec.Decode(&val)  // or binary.UnmarshalBorsh(&val, data) or binary.UnmarshalBin(&val, data) etc.
	if err != nil {
		log.Fatal(err)
	}
}

Patches

Has the problem been patched? What versions should users upgrade to?

The vulnerability has been patched in github.com/gagliardetto/binary v0.7.1

Users should upgrade to v0.7.1 or higher.

To upgrade to v0.7.1 or higher, run:

go get github.com/gagliardetto/binary@v0.7.1

# or

go get github.com/gagliardetto/binary@latest

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

A workaround is not to rely on the dec.Decode(&val) function to parse the data, but to use a custom UnmarshalWithDecoder() method that reads and checks the length of any slice.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in github.com/gagliardetto/binary
DM me on twitter

Fixed in


          0.7.1

References

Updated Nov 08, 2023 · Source: OSV.dev

Feb 01, 2022

v0.5.2 patch

1 CVE

CVE-2022-36078 GHSA-4p6f-m4f9-ch88 GO-2022-0963 Sep 16, 2022

Binary vulnerable to Slice Memory Allocation with Excessive Size Value

8.8 / 10

High

Network Low None Required Unchanged High High High

Impact

What kind of vulnerability is it? Who is impacted?

The vulnerability is a memory allocation vulnerability that can be exploited to allocate slices in memory with (arbitrary) excessive size value, which can either exhaust available memory or crash the whole program.

When using github.com/gagliardetto/binary to parse unchecked (or wrong type of) data from untrusted sources of input (e.g. the blockchain) into slices, it's possible to allocate memory with excessive size.

When dec.Decode(&val) method is used to parse data into a structure that is or contains slices of values, the length of the slice was previously read directly from the data itself without any checks on the size of it, and then a slice was allocated. This could lead to an overflow and an allocation of memory with excessive size value.

Example:

package main

import (
	"github.com/gagliardetto/binary" // any version before v0.7.1 is vulnerable
	"log"
)

type MyStruct struct {
	Field1 []byte // field is a slice (could be a slice of any type)
}

func main() {
	// Let's assume that the data is coming from the blockchain:
	data := []byte{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
	
	var val MyStruct
	// - To determine the size of the val.Field1 slice, the decoder will read the length
	//   of the slice from the data itself without any checks on the size of it.
	//
	// - This could lead to an allocation of memory with excessive size value.
	//   Which means: []byte{0x01, 0x02, 0x03, 0x04} will be read as the length
	//   of the slice (= 67305985) and then an allocation of memory with 67305985 bytes will be made.
	//
	dec := binary.NewBorshDecoder(data)
	err := dec.Decode(&val)  // or binary.UnmarshalBorsh(&val, data) or binary.UnmarshalBin(&val, data) etc.
	if err != nil {
		log.Fatal(err)
	}
}

Patches

Has the problem been patched? What versions should users upgrade to?

The vulnerability has been patched in github.com/gagliardetto/binary v0.7.1

Users should upgrade to v0.7.1 or higher.

To upgrade to v0.7.1 or higher, run:

go get github.com/gagliardetto/binary@v0.7.1

# or

go get github.com/gagliardetto/binary@latest

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

A workaround is not to rely on the dec.Decode(&val) function to parse the data, but to use a custom UnmarshalWithDecoder() method that reads and checks the length of any slice.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in github.com/gagliardetto/binary
DM me on twitter

Fixed in


          0.7.1

References

Updated Nov 08, 2023 · Source: OSV.dev

Jan 05, 2022

v0.5.1 patch

1 CVE

CVE-2022-36078 GHSA-4p6f-m4f9-ch88 GO-2022-0963 Sep 16, 2022

Binary vulnerable to Slice Memory Allocation with Excessive Size Value

8.8 / 10

High

Network Low None Required Unchanged High High High

Impact

What kind of vulnerability is it? Who is impacted?

The vulnerability is a memory allocation vulnerability that can be exploited to allocate slices in memory with (arbitrary) excessive size value, which can either exhaust available memory or crash the whole program.

When using github.com/gagliardetto/binary to parse unchecked (or wrong type of) data from untrusted sources of input (e.g. the blockchain) into slices, it's possible to allocate memory with excessive size.

When dec.Decode(&val) method is used to parse data into a structure that is or contains slices of values, the length of the slice was previously read directly from the data itself without any checks on the size of it, and then a slice was allocated. This could lead to an overflow and an allocation of memory with excessive size value.

Example:

package main

import (
	"github.com/gagliardetto/binary" // any version before v0.7.1 is vulnerable
	"log"
)

type MyStruct struct {
	Field1 []byte // field is a slice (could be a slice of any type)
}

func main() {
	// Let's assume that the data is coming from the blockchain:
	data := []byte{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
	
	var val MyStruct
	// - To determine the size of the val.Field1 slice, the decoder will read the length
	//   of the slice from the data itself without any checks on the size of it.
	//
	// - This could lead to an allocation of memory with excessive size value.
	//   Which means: []byte{0x01, 0x02, 0x03, 0x04} will be read as the length
	//   of the slice (= 67305985) and then an allocation of memory with 67305985 bytes will be made.
	//
	dec := binary.NewBorshDecoder(data)
	err := dec.Decode(&val)  // or binary.UnmarshalBorsh(&val, data) or binary.UnmarshalBin(&val, data) etc.
	if err != nil {
		log.Fatal(err)
	}
}

Patches

Has the problem been patched? What versions should users upgrade to?

The vulnerability has been patched in github.com/gagliardetto/binary v0.7.1

Users should upgrade to v0.7.1 or higher.

To upgrade to v0.7.1 or higher, run:

go get github.com/gagliardetto/binary@v0.7.1

# or

go get github.com/gagliardetto/binary@latest

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

A workaround is not to rely on the dec.Decode(&val) function to parse the data, but to use a custom UnmarshalWithDecoder() method that reads and checks the length of any slice.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in github.com/gagliardetto/binary
DM me on twitter

Fixed in


          0.7.1

References

Updated Nov 08, 2023 · Source: OSV.dev

Jan 05, 2022

v0.5.0 minor

1 CVE

CVE-2022-36078 GHSA-4p6f-m4f9-ch88 GO-2022-0963 Sep 16, 2022

Binary vulnerable to Slice Memory Allocation with Excessive Size Value

8.8 / 10

High

Network Low None Required Unchanged High High High

Impact

What kind of vulnerability is it? Who is impacted?

The vulnerability is a memory allocation vulnerability that can be exploited to allocate slices in memory with (arbitrary) excessive size value, which can either exhaust available memory or crash the whole program.

When using github.com/gagliardetto/binary to parse unchecked (or wrong type of) data from untrusted sources of input (e.g. the blockchain) into slices, it's possible to allocate memory with excessive size.

When dec.Decode(&val) method is used to parse data into a structure that is or contains slices of values, the length of the slice was previously read directly from the data itself without any checks on the size of it, and then a slice was allocated. This could lead to an overflow and an allocation of memory with excessive size value.

Example:

package main

import (
	"github.com/gagliardetto/binary" // any version before v0.7.1 is vulnerable
	"log"
)

type MyStruct struct {
	Field1 []byte // field is a slice (could be a slice of any type)
}

func main() {
	// Let's assume that the data is coming from the blockchain:
	data := []byte{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
	
	var val MyStruct
	// - To determine the size of the val.Field1 slice, the decoder will read the length
	//   of the slice from the data itself without any checks on the size of it.
	//
	// - This could lead to an allocation of memory with excessive size value.
	//   Which means: []byte{0x01, 0x02, 0x03, 0x04} will be read as the length
	//   of the slice (= 67305985) and then an allocation of memory with 67305985 bytes will be made.
	//
	dec := binary.NewBorshDecoder(data)
	err := dec.Decode(&val)  // or binary.UnmarshalBorsh(&val, data) or binary.UnmarshalBin(&val, data) etc.
	if err != nil {
		log.Fatal(err)
	}
}

Patches

Has the problem been patched? What versions should users upgrade to?

The vulnerability has been patched in github.com/gagliardetto/binary v0.7.1

Users should upgrade to v0.7.1 or higher.

To upgrade to v0.7.1 or higher, run:

go get github.com/gagliardetto/binary@v0.7.1

# or

go get github.com/gagliardetto/binary@latest

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

A workaround is not to rely on the dec.Decode(&val) function to parse the data, but to use a custom UnmarshalWithDecoder() method that reads and checks the length of any slice.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in github.com/gagliardetto/binary
DM me on twitter

Fixed in


          0.7.1

References

Updated Nov 08, 2023 · Source: OSV.dev

Oct 10, 2021

v0.4.5 patch

1 CVE

CVE-2022-36078 GHSA-4p6f-m4f9-ch88 GO-2022-0963 Sep 16, 2022

Binary vulnerable to Slice Memory Allocation with Excessive Size Value

8.8 / 10

High

Network Low None Required Unchanged High High High

Impact

What kind of vulnerability is it? Who is impacted?

The vulnerability is a memory allocation vulnerability that can be exploited to allocate slices in memory with (arbitrary) excessive size value, which can either exhaust available memory or crash the whole program.

When using github.com/gagliardetto/binary to parse unchecked (or wrong type of) data from untrusted sources of input (e.g. the blockchain) into slices, it's possible to allocate memory with excessive size.

When dec.Decode(&val) method is used to parse data into a structure that is or contains slices of values, the length of the slice was previously read directly from the data itself without any checks on the size of it, and then a slice was allocated. This could lead to an overflow and an allocation of memory with excessive size value.

Example:

package main

import (
	"github.com/gagliardetto/binary" // any version before v0.7.1 is vulnerable
	"log"
)

type MyStruct struct {
	Field1 []byte // field is a slice (could be a slice of any type)
}

func main() {
	// Let's assume that the data is coming from the blockchain:
	data := []byte{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
	
	var val MyStruct
	// - To determine the size of the val.Field1 slice, the decoder will read the length
	//   of the slice from the data itself without any checks on the size of it.
	//
	// - This could lead to an allocation of memory with excessive size value.
	//   Which means: []byte{0x01, 0x02, 0x03, 0x04} will be read as the length
	//   of the slice (= 67305985) and then an allocation of memory with 67305985 bytes will be made.
	//
	dec := binary.NewBorshDecoder(data)
	err := dec.Decode(&val)  // or binary.UnmarshalBorsh(&val, data) or binary.UnmarshalBin(&val, data) etc.
	if err != nil {
		log.Fatal(err)
	}
}

Patches

Has the problem been patched? What versions should users upgrade to?

The vulnerability has been patched in github.com/gagliardetto/binary v0.7.1

Users should upgrade to v0.7.1 or higher.

To upgrade to v0.7.1 or higher, run:

go get github.com/gagliardetto/binary@v0.7.1

# or

go get github.com/gagliardetto/binary@latest

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

A workaround is not to rely on the dec.Decode(&val) function to parse the data, but to use a custom UnmarshalWithDecoder() method that reads and checks the length of any slice.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in github.com/gagliardetto/binary
DM me on twitter

Fixed in


          0.7.1

References

Updated Nov 08, 2023 · Source: OSV.dev

Oct 02, 2021

v0.4.4 patch

1 CVE

CVE-2022-36078 GHSA-4p6f-m4f9-ch88 GO-2022-0963 Sep 16, 2022

Binary vulnerable to Slice Memory Allocation with Excessive Size Value

8.8 / 10

High

Network Low None Required Unchanged High High High

Impact

What kind of vulnerability is it? Who is impacted?

The vulnerability is a memory allocation vulnerability that can be exploited to allocate slices in memory with (arbitrary) excessive size value, which can either exhaust available memory or crash the whole program.

When using github.com/gagliardetto/binary to parse unchecked (or wrong type of) data from untrusted sources of input (e.g. the blockchain) into slices, it's possible to allocate memory with excessive size.

When dec.Decode(&val) method is used to parse data into a structure that is or contains slices of values, the length of the slice was previously read directly from the data itself without any checks on the size of it, and then a slice was allocated. This could lead to an overflow and an allocation of memory with excessive size value.

Example:

package main

import (
	"github.com/gagliardetto/binary" // any version before v0.7.1 is vulnerable
	"log"
)

type MyStruct struct {
	Field1 []byte // field is a slice (could be a slice of any type)
}

func main() {
	// Let's assume that the data is coming from the blockchain:
	data := []byte{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
	
	var val MyStruct
	// - To determine the size of the val.Field1 slice, the decoder will read the length
	//   of the slice from the data itself without any checks on the size of it.
	//
	// - This could lead to an allocation of memory with excessive size value.
	//   Which means: []byte{0x01, 0x02, 0x03, 0x04} will be read as the length
	//   of the slice (= 67305985) and then an allocation of memory with 67305985 bytes will be made.
	//
	dec := binary.NewBorshDecoder(data)
	err := dec.Decode(&val)  // or binary.UnmarshalBorsh(&val, data) or binary.UnmarshalBin(&val, data) etc.
	if err != nil {
		log.Fatal(err)
	}
}

Patches

Has the problem been patched? What versions should users upgrade to?

The vulnerability has been patched in github.com/gagliardetto/binary v0.7.1

Users should upgrade to v0.7.1 or higher.

To upgrade to v0.7.1 or higher, run:

go get github.com/gagliardetto/binary@v0.7.1

# or

go get github.com/gagliardetto/binary@latest

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

A workaround is not to rely on the dec.Decode(&val) function to parse the data, but to use a custom UnmarshalWithDecoder() method that reads and checks the length of any slice.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in github.com/gagliardetto/binary
DM me on twitter

Fixed in


          0.7.1

References

Updated Nov 08, 2023 · Source: OSV.dev

Sep 19, 2021

v0.4.3 patch

1 CVE

CVE-2022-36078 GHSA-4p6f-m4f9-ch88 GO-2022-0963 Sep 16, 2022

Binary vulnerable to Slice Memory Allocation with Excessive Size Value

8.8 / 10

High

Network Low None Required Unchanged High High High

Impact

What kind of vulnerability is it? Who is impacted?

The vulnerability is a memory allocation vulnerability that can be exploited to allocate slices in memory with (arbitrary) excessive size value, which can either exhaust available memory or crash the whole program.

When using github.com/gagliardetto/binary to parse unchecked (or wrong type of) data from untrusted sources of input (e.g. the blockchain) into slices, it's possible to allocate memory with excessive size.

When dec.Decode(&val) method is used to parse data into a structure that is or contains slices of values, the length of the slice was previously read directly from the data itself without any checks on the size of it, and then a slice was allocated. This could lead to an overflow and an allocation of memory with excessive size value.

Example:

package main

import (
	"github.com/gagliardetto/binary" // any version before v0.7.1 is vulnerable
	"log"
)

type MyStruct struct {
	Field1 []byte // field is a slice (could be a slice of any type)
}

func main() {
	// Let's assume that the data is coming from the blockchain:
	data := []byte{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
	
	var val MyStruct
	// - To determine the size of the val.Field1 slice, the decoder will read the length
	//   of the slice from the data itself without any checks on the size of it.
	//
	// - This could lead to an allocation of memory with excessive size value.
	//   Which means: []byte{0x01, 0x02, 0x03, 0x04} will be read as the length
	//   of the slice (= 67305985) and then an allocation of memory with 67305985 bytes will be made.
	//
	dec := binary.NewBorshDecoder(data)
	err := dec.Decode(&val)  // or binary.UnmarshalBorsh(&val, data) or binary.UnmarshalBin(&val, data) etc.
	if err != nil {
		log.Fatal(err)
	}
}

Patches

Has the problem been patched? What versions should users upgrade to?

The vulnerability has been patched in github.com/gagliardetto/binary v0.7.1

Users should upgrade to v0.7.1 or higher.

To upgrade to v0.7.1 or higher, run:

go get github.com/gagliardetto/binary@v0.7.1

# or

go get github.com/gagliardetto/binary@latest

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

A workaround is not to rely on the dec.Decode(&val) function to parse the data, but to use a custom UnmarshalWithDecoder() method that reads and checks the length of any slice.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in github.com/gagliardetto/binary
DM me on twitter

Fixed in


          0.7.1

References

Updated Nov 08, 2023 · Source: OSV.dev

Sep 10, 2021

v0.4.2 initial

1 CVE

CVE-2022-36078 GHSA-4p6f-m4f9-ch88 GO-2022-0963 Sep 16, 2022

Binary vulnerable to Slice Memory Allocation with Excessive Size Value

8.8 / 10

High

Network Low None Required Unchanged High High High

Impact

What kind of vulnerability is it? Who is impacted?

The vulnerability is a memory allocation vulnerability that can be exploited to allocate slices in memory with (arbitrary) excessive size value, which can either exhaust available memory or crash the whole program.

When using github.com/gagliardetto/binary to parse unchecked (or wrong type of) data from untrusted sources of input (e.g. the blockchain) into slices, it's possible to allocate memory with excessive size.

When dec.Decode(&val) method is used to parse data into a structure that is or contains slices of values, the length of the slice was previously read directly from the data itself without any checks on the size of it, and then a slice was allocated. This could lead to an overflow and an allocation of memory with excessive size value.

Example:

package main

import (
	"github.com/gagliardetto/binary" // any version before v0.7.1 is vulnerable
	"log"
)

type MyStruct struct {
	Field1 []byte // field is a slice (could be a slice of any type)
}

func main() {
	// Let's assume that the data is coming from the blockchain:
	data := []byte{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
	
	var val MyStruct
	// - To determine the size of the val.Field1 slice, the decoder will read the length
	//   of the slice from the data itself without any checks on the size of it.
	//
	// - This could lead to an allocation of memory with excessive size value.
	//   Which means: []byte{0x01, 0x02, 0x03, 0x04} will be read as the length
	//   of the slice (= 67305985) and then an allocation of memory with 67305985 bytes will be made.
	//
	dec := binary.NewBorshDecoder(data)
	err := dec.Decode(&val)  // or binary.UnmarshalBorsh(&val, data) or binary.UnmarshalBin(&val, data) etc.
	if err != nil {
		log.Fatal(err)
	}
}

Patches

Has the problem been patched? What versions should users upgrade to?

The vulnerability has been patched in github.com/gagliardetto/binary v0.7.1

Users should upgrade to v0.7.1 or higher.

To upgrade to v0.7.1 or higher, run:

go get github.com/gagliardetto/binary@v0.7.1

# or

go get github.com/gagliardetto/binary@latest

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

A workaround is not to rely on the dec.Decode(&val) function to parse the data, but to use a custom UnmarshalWithDecoder() method that reads and checks the length of any slice.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Open an issue in github.com/gagliardetto/binary
DM me on twitter

Fixed in


          0.7.1

References

Updated Nov 08, 2023 · Source: OSV.dev

Sep 10, 2021

Activity

Reach

Details