What's the data security guarantee of Anytype's client?

[SilverBut]

I'm reading code of anytype-heart and noticed Middleware struct contains some quite sensitive info like mnemonic which can be derived to sessionKey, and the pin for protecting(?) mnemonics.
Due to Golang's memory model, in current form of storage (raw string and []byte), they can be found in memory, and maybe will duplicated later after a few copies. Even though keys are safely rested on the disk using OS's keychains, they are not very safe while Anytype is running.

But, while it sounds horrifying, this might not be a vulnerability. Attackers need to access the memory. For macOS, I think you need to bypass SIP before accessing a signed application's memory. Windows have some similar features, but for Linux, maybe a application running as current user is enough. Coredump is also a possible way to extract memory content. Besides, physical attack (such as abusing IOMMU with a malicious device) is also a way to read memory. And if not using on-site methods, attacker must have the ability to run code remotely on victim's device. This is a relatively high bar.

So the question is: What's the security guarantee to the keys (and maybe clear text content of blocks)? Some possible answers:

• Data at rest security. This ensures nothing goes wrong if Anytype is not running, and not having any security promise if Anytype is already running. That's a reasonable choice if we think user should keep their own client security.
• Prevent normal remote attackers. This ensures unless system is modified or have vulnerability (for example, disable macOS SIP manually), reading memory remotely is not allowed. KeepassXC implemented this. As for physical attacks, there is very little a program can do.
• Future more, have some design to minimize the risk of sensitive variables being copied everywhere. For example, if a copy is used, always overwrite the content of that memory region. The implementation would be difficult.
• Or, for crazy people, maybe put the sensitive memory into some enclaves like SGX?

[ahmedwael216]

Vulnerabilities shouldn't be posted it here in the public.
it's mentioned in the security section in the contribution guide.

[ahmedwael216]

I know, but if it is then you are writing a PoC for attackers to build on.

I think you should discuss this in private with the security team.

And if it's not a vulnerability than write about it as you like.

[SilverBut]

Whether this is a vulnerability depends on Anytype's expected security guarantee. And, even if this is finally considered as a vuln, a PoC is not necessary for this specific case, cause searching strings in memory using gdb, lldb or Windbg is considered as a basic skill.

[clems4ever]

I think it would have been better to privately report and ask the team if it's ok to publish beforehand indeed. Now that it's there, I would also not be too alarming by emphasizing what @SilverBut has said , reading memory is probably a high bar kind of pre-requisite in most cases.

Anyway, I have not reviewed the code yet but from a very high level point of view, many apps don't use memory enclaves for handling sensitive data and it's fine, not to say this is always ok but rather that if it's considered a vuln in anytype it should be considered as such in many of those other apps. However the sensitive code you came across must be carefully written/reviewed to make sure the data is not maintained in memory more than it should. Indeed it could end up on disk in the swap for instance and that could be a bigger problem than memory for those not using an encrypted swap. Also there might be kernel primitives that can help protect sensitive data, like the kernel keyring, maybe some might be used to improve this specific situation you have found.

Regarding dumping the memory on linux, as far as I know one must be root to do so unless there is an actual vuln in AnyType that would allow the attacker to read memory from a buffer overflow for instance, which is really hard on linux nowadays. Indeed, normally with default kernel settings and properly compiled software there are chances that the attacker would face issues with canaries, the ASLR and memory pages permissions.

However, there are solutions for those out there who are paranoid like myself (and @SilverBut potentially :) ). I came across this one https://github.com/awnumar/memguard that I have not thoroughly reviewed nor tested yet but the promises seem good. Might be worth getting feedback about it and see if it is worth introducing. I tend to think it is over engineering though. It's purely subjective and maybe I'm wrong, I leave that to the team to decide.
As far as physical attacks, I think it is definitely a good thing to keep them in sight and avoid those issues as much as possible but AnyType is not meant to be a military grade kind of software I think, if that was the case, one would likely need to rely on FIPS compatible hardware to protect the keys for instance.

Also fyi @SilverBut , SGX enclaves have been deprecated in recent processors because of the number of vulns they had... So, this is not a potential solution anymore. https://www.bleepingcomputer.com/news/security/new-intel-chips-wont-play-blu-ray-disks-due-to-sgx-deprecation/

[SilverBut]

Indeed. I have not seen much enclaves. Some applications like KeepassXC can keep credential related memory relatively safe because the programming language allowed managing memory manually, but this seems hard for Golang. But I don't rememver if KeepassXC have made any guarantee about data security if the device is promised...

I'm also not worrying about traditional memory flaws like heap/stack overflow. Infra of anytype have erased most causes of those type of flaws, and even if they exists, writing exploit on modern platform would be hard.

Considering Anytype is using some Web3 technologies like IPFS...is hardware wallet helpful? Not sure about that.

[clems4ever]

From what I understand, anytype uses only a tiny part of ipfs and I don't know the full details yet but it would not surprise me if it would only be a data layer, not really the security layer making web3 "safe". Also, it's only a subset of the anytype solution which is only related to file storage. But there is also the space storage which is another part totally unrelated to ipfs.

Knowing that I think it would be more general to consider your question with regards to hardware tokens instead of only web3 hardware wallets, i.e., basically anyway to offload the sensitive operations to a dedicated hardware like a yubikey or the like. I think this could be an idea but it has some limitations, the main one being that you would need to have the token plugged in during the entire session, which means all day long for certain people... So we'd rather use the TPM if we really want to do anything about the problem you mention but again I think it's over engineering at this stage.

If it's only for unlocking the space though, a yubikey is definitely better than the pin and I might introduce it at some point to be able to unlock my space with my keys or fingerprint. However it does not solve the problem of keeping the encryption keys safe, it would just be a fancy (potentially 2FA) unlocker like KeepassXC uses HOTP.

[requilence]

Hello @SilverBut!

Appreciate your deep dive into Anytype's security. Let's get right into your queries.

First, our security model assumes a non-compromised device. If the device is compromised, there would be innumerable ways for an attacker to gain access to data including key loggers and secure enclave phishing.

On 'Data at Rest' security: The mnemonic (recovery phrase) is stored securely in the system's secure enclave. All files and objects' changes are encrypted in rest. As for search indexes (such as fts and localstore folders), these are non-encrypted for performance reasons. However, they can be safely deleted, though re-indexing will be required upon app start. We are currently researching the feasibility of providing optional encryption for indexes, but we don't have any estimates.

At the same time, it makes sense to mitigate the risks associated with the most critical information, like the mnemonic variable you mentioned. It should be possible to avoid storing it in memory and instead, use it only at the time of logging in.

Also, since we use BIP39, it should theoretically be possible to use hardware wallets to sign into the Anytype account and derive the encryption keys. However, this is currently not on our roadmap.