Iroh-Blobs Security Fix

We just released iroh-blobs 0.103.1, together with patch releases for older versions. It fixes a bug that allowed any peer that can connect to a blobs provider to write data into the provider's store. If you run an iroh-blobs provider or use sendme, please update.

The iroh-blobs protocol has four request types: get, get many, observe and push. The first three only read from the store. Push is different: it allows a remote peer to send you data, which then gets written to your local store.

Since push requests write to the store, they are supposed to be disabled unless you explicitly enable them. The EventMask has a separate mode for each request type, and both EventMask::DEFAULT and EventMask::ALL_READONLY have push: RequestMode::Disabled. The docs say so too.

Unfortunately the code did not do what the docs said. The function that handles incoming requests is shared by all request types, and it always looked at mask.get, never at mask.push, mask.get_many or mask.observe. So:

In other words, a provider with the default configuration would accept arbitrary blobs from any peer that can connect to it. The data is content-addressed and verified, so a peer can not modify existing blobs. But it can fill up your disk.

Whether you are at risk depends on who can connect to your provider. A push request needs your endpoint id, so a long-running provider with a published endpoint id is the most exposed. If you only share the endpoint id or tickets with trusted parties, the risk is much lower.

Each request type now uses its own mode from the event mask (#270). Thanks to @Frando, who wrote the original fix.

There is no API change, but the behaviour now matches the documentation, so you might notice two things:

The bug has been there since the provider events refactor in 0.94, so all versions from 0.94.0 up to and including 0.103.0 are affected. We published fixed releases for the most popular versions on crates.io and yanked the corresponding broken versions:

If you are on an older version, please update to one of the fixed versions.

sendme was affected as well: while sendme send was running, anyone with the ticket could push data into the sender's temporary store. The store gets deleted when sendme exits. Please update to sendme 0.36.1.