PFM is the Safest Middleware in Cosmos

An Audit is Born

Folks familiar with the Cosmos ecosystem are likely familiar with Packet Forward Middleware (PFM). Strangelove initially began development of PFM in early September 2021 and later that same month it was approved for deployment via Cosmos Hub governance. Since then, PFM has seen widespread adoption across the Cosmos ecosystem with dozens of chains integrating the middleware and hundreds of dependents on GitHub importing it into their projects. The most recent chain to adopt PFM is Celestia. Thanks to a public goods initiative, funded by the Celestia community, an audit of PFM was recently conducted by Zellic.

Audit Summary

The audit revealed zero critical, high, or medium impact issues. A single low impact issue was discovered and the auditors left two informational remarks. The lack of critical issues discovered in the audit is a testament to the code quality of PFM. That quality is a result of three years of battle testing by the community, and a professional development team launching and maintaining PFM throughout.

The single low impact issue mentioned was that PFM does not enforce an upper limit with regards to IBC timeouts. The timeout uses Go's `time.Duration` type, which is a 64-bit integer, meaning the maximum value for the timeout can be very large. PFM also makes use of retries where the maximum number of retries could be 255. Using the maximum value for the timeout duration and the number of retries could result in an IBC packet getting stuck for an extremely long time. Ultimately Strangelove determined that it is not the responsibility of PFM to enforce an upper limit on the timeout value, but instead should be handled by relayer or chain implementations.

One of the informational related findings in the audit was that the `RefundPacketKey` store path, used for storing information about forwarded packets in the `Keeper`, is missing a prefix. This means that if PFM was storing other data in its store it would be unable to disambiguate it from the other store paths. Since this would require an upgrade with a state migration and we don't plan on storing any additional data in the `Keeper`, we determined that this issue is not worth addressing right now. We are tracking this issue on GitHub in case there is ever a need for PFM to store additional data in its `Keeper`.

The remaining informational finding was that the `processed` flag could potentially lead to bugs in the future if the value was changed from `false` to `true`. This `processed` flag was originally introduced to handle cases where some other middleware higher in the stack has already processed the packet, circumventing multiple calls into the underlying app that could invoke the ICS-20 burn/mint voucher logic more than once. There are currently no known middlewares using this key so we determined that removing the flag altogether was the best course of action since it removes a possible footgun in the code.

There were previously three security related issues discovered in PFM, two of which were reported via the HackerOne program and one that was discovered internally. Strangelove followed security best practices in patching and disclosing these previous issues in a timely manner in collaboration with Amulet and others in the community. We take the software development lifecycle very seriously and continue to work closely with the community and our various partners to deliver safe and mature code to our users.

Zellic has posted the full PFM audit report as a PDF, and you can learn more about PFM by checking out our announcement blog post from early 2024.