Security
Headlines
HeadlinesLatestCVEs

Headline

GHSA-f2gr-7299-487h: DOS and excessive memory usage when passing untrusted user input to to dag import

Impact

go-ipfs nodes crash when trying to import certain malformed CAR files due to an issue in the go-car dependency. This impacts nodes running ipfs dag import on untrusted user inputs, for example, pinning services with a car ingest endpoint. This include the corresponding HTTP RPC API v0/dag/import endpoint.

An attacker controlling the car file passed in can also make the node allocate arbitrary sized buffers creating memory exhaustion attacks.

Patches

0.13.1, 0.14 and later.

Forks

For those running on forked versions of go-ipfs, simply updating the version of github.com/ipld/go-car/v2 you are using to >= v2.4.0 should resolve the issue.

Libraries consumers

Any users of libraries within the go-ipfs ecosystem, even if not the go-ipfs package or binary itself, may be affected and should upgrade their dependency on go-car.

You can check if your Go module has a dependency on go-car by running a command such as go mod graph | grep go-car in your module root.

Note: if you are using other libraries, some parts of go-car (github.com/ipld/go-car/v2/index/...) have not fully been fixed yet. Please see go-car’s security advisory for more information. go-ipfs do not make use of this code.

Workarounds

The best way to work around this is to control exposure to the HTTP RPC API endpoint for CAR imports to only work with trusted data.

You can also validate that the car will not crash go-ipfs by running car verify on it first (go install github.com/ipld/go-car/cmd/car@latest).

References

See also the go-car security advisory.

For more information

If you have any questions or comments about this advisory:

  1. Ask in the IPFS Discourse
  2. Ask in the IPFS Discord #ipld-chatter
  3. Open an issue in go-ipfs
ghsa
#git

Impact

go-ipfs nodes crash when trying to import certain malformed CAR files due to an issue in the go-car dependency. This impacts nodes running ipfs dag import on untrusted user inputs, for example, pinning services with a car ingest endpoint.
This include the corresponding HTTP RPC API v0/dag/import endpoint.

An attacker controlling the car file passed in can also make the node allocate arbitrary sized buffers creating memory exhaustion attacks.

Patches

0.13.1, 0.14 and later.

Forks

For those running on forked versions of go-ipfs, simply updating the version of github.com/ipld/go-car/v2 you are using to >= v2.4.0 should resolve the issue.

Libraries consumers

Any users of libraries within the go-ipfs ecosystem, even if not the go-ipfs package or binary itself, may be affected and should upgrade their dependency on go-car.

You can check if your Go module has a dependency on go-car by running a command such as go mod graph | grep go-car in your module root.

Note: if you are using other libraries, some parts of go-car (github.com/ipld/go-car/v2/index/…) have not fully been fixed yet. Please see go-car’s security advisory for more information. go-ipfs do not make use of this code.

Workarounds

The best way to work around this is to control exposure to the HTTP RPC API endpoint for CAR imports to only work with trusted data.

You can also validate that the car will not crash go-ipfs by running car verify on it first (go install github.com/ipld/go-car/cmd/car@latest).

References

See also the go-car security advisory.

For more information

If you have any questions or comments about this advisory:

  1. Ask in the IPFS Discourse
  2. Ask in the IPFS Discord #ipld-chatter
  3. Open an issue in go-ipfs

References

  • GHSA-f2gr-7299-487h

ghsa: Latest News

GHSA-27wf-5967-98gx: Kubernetes kubelet arbitrary command execution