Samourai Wallet Address Reuse Bug

On the 12th of June this year, I was approached by a Samourai Wallet user who had noticed multiple instances of address reuse in his wallet. According to this user, the behavior occurred automatically multiple times without any manual intervention on their part. These instances displayed a pattern of the same address being reused every time reuse occurred. Upon asking the user a few more questions, it was confirmed that the address in his wallet being reused was specifically the 0 index derivation path for that address type. This was peculiar, and I suspected that the core issue related to how the client handled indexing of most recently used addresses.

After my investigation I contacted a Samourai developer about the issue, and we agreed to a disclosure date of July 15th — exactly one month later. While they disclosed some aspects of the issue themselves yesterday, I still want to provide my side of the picture. Here is word-for-word excerpts of the disclosure I made to the Samourai developer, with additional explanation.

At a high level, every HD wallet requires an index to keep track of “where the wallet is” in the derivation path for that address type, i.e. which address was used last, and which address to use next. In the instance of Samourai wallet, this is provided in a JSON object fed by the back end. However, I discovered a lack of error handling, where the JSON object can be nulled (leading to no index being set, causing the wallet to reuse addresses starting from index 0) in any situation where the client receives malformed data or any network connection disruption occurs. This could be solved with local safety checks and proper error handling, but none were in place.

Within the last one-month period, I have made three requests for updates on whether the Samourai team had been able to replicate the issue. Their replies were short, and did not give me any clarity regarding the progress of their investigation.​​​​​​​

This problem can be caused by connectivity issues or invalid responses due to an error in the back end, which leaves the client vulnerable not just to a malicious back end but also a network intermediary. (To be clear, I am not alleging that the Samourai developers would engage in such an attack. I am just pointing out that it is possible to intentionally trigger this behavior in such a manner. This is equally true of someone else’s Dojo instance.)

Instead of addressing the issue directly, their patch is to perform better filtering of transactions on the back end.​​​​​​​ Thankfully, this time, it was not something sensitive enough to put funds at risk. But given the nature of Samourai Wallet as a privacy tool, this is still disconcerting. Ultimately, every time the wallet is started, it starts with the default index of 0. Unless the client manages to successfully query the index from the back end, this default value will be used for constructing new transactions (this value is not persisted on the device). No errors are displayed to the user in case of query failure. The client will also blindly accept whatever it is fed by the back end without question.​​​​​ Instances of this address reuse are observable on the blockchain beyond what the user who reported this to me experienced.

From what I see, Samourai has decided to patch the back end with new filtering criteria that checks transactions for address reuse on Dojo or Samourai’s servers before broadcasting. This could potentially leave out fringe cases, such as users who create transactions and broadcast through other means. (It’s also important to mention that the Whirlpool Client does not suffer from this issue, as it persists the relevant index values locally.)

The last thing I want to say is a general point on how people engage with each other in this space. Over the past year or two, the Samourai team has devoted large amounts of time and resources towards analyzing flows of coins through their competitor, Wasabi. They blame them for post-mix behavior that is consciously taken by end users (which is impossible to prevent in a non-custodial wallet). Meanwhile, their own tools were exhibiting instances of address reuse due to poor architecting and error handling mechanisms. To say “throwing stones from a glass house” is, in my opinion, an understatement.

Due to the way they combatively engage with many other projects in the space, I suspect that there are fewer eyes checking their code base for issues than there otherwise would be. Ultimately it’s the users and not the competitor that suffers most because of the dynamics this environment creates.

I will be investigating the differences between the number of reused addresses in my and Samourai’s analysis and looking for potential false positives, and follow up when finished.

This however does not change the nature of the bug in the client, or the severity of it for individual affected users. I still strongly believe an appropriate patch would be to persist the relevant wallet indexes locally in the same manner the Whirlpool desktop client does. I have put all of this out into the public transparently, with all the necessary data to verify both the reuse on chain and the code relating to the bug, and have described above the cause of the ascertained error in my numbers. I have no intent of engaging in slap fights or arguments on social media, everything necessary to verify this issue is right here, and what any individual chooses to do with that is their decision to make.

Related posts:

Addicts in Ludhiana can get all the support and tools they need at the Nasha Mukti Kendra in Ludhiana to beat their addiction and live better, drug-free lives. The facility treats addiction’s…

To implement a drip campaign, a series of automated emails must be sent out over time. Drip campaigns can be used to nurture leads, strengthen client connections, advertise new goods or services, or…

La carrera contra la vida en estos tiempos extraños no nos ha dado ni el chance de sentarnos a pensar en lo que está pasando. Desde que empezó el año, el covid-19 se ha comportado como una pandemia…