Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encrypted libraries leak lots of information #350

Open
ef4 opened this issue Sep 3, 2013 · 65 comments

Comments

@ef4
Copy link
Contributor

commented Sep 3, 2013

I spent some time auditing the crypto constructs for Seafile's encrypted repos, because I'd like to help make Seafile more secure and trustworthy. I found some significant problems.

An attacker who obtains a copy of the encrypted library without the key can:

  • read the complete list of directory and file names.
  • know the size of every file
  • know which files share some of the same information
  • see the history of who changed each file, when, and what byte ranges were altered

Furthermore, since the same initialization vector is reused for all chunks, the library is vulnerable to watermarking and known-plaintext attacks.

The first problem is straightforward to solve: encrypt all file and directory entries, not just the content chunks.

The second problem (predictable IVs) is not as easy to fix. To maintain seafile's existing deduplication and synchronization capabilities, you want deterministic encryption. But maintaining semantic secrecy with deterministic encryption is probably not possible.

As a practical improvement, you could use an HMAC of each chunk as its IV. This is still deterministic, but it would at least prevent chunks with the same prefix from sharing the same ciphertext prefix.

To achieve strong secrecy, Seafile would need to give up deterministic encryption. This can still provide reasonable reduplication and efficient sync, but it would require clients to maintain their own cached mapping from chunk sha1 sums to their encrypted identities. You may want to look at how the Tarsnap client does something similar.

@killing

This comment has been minimized.

Copy link
Member

commented Sep 4, 2013

Thanks for your suggestions.

Encrypting file and directory entries has been discussed for some time. It'll be added in the future. But it takes a lot of effort so we don't have time to work on it currently. If file and directory entries are encrypted, we have to decrypt them when browsing the files from the web. That requires a lot of changes.

I don't quite understand why using a single IV for the whole library is vulnerable to known-plaintext attacks. The IV is derived from the password with salt. It's deterministic, but not so predictable. If it's so bad to use this method to produce an IV, it's bad to derive the key from password too. I know it's better to use different IV and key for each file/block. But that would greatly increase complexity.

@ef4

This comment has been minimized.

Copy link
Contributor Author

commented Sep 4, 2013

It's bad for the same reason that ECB mode is bad: patterns in the data remain visible as patterns in the ciphertext. The only difference is that in this case we're talking about patterns of chunks instead of patterns of cipher blocks. I think it's possible to guess with good probability whether a repo contains certain files, just based on the statistical patterns of blocks with shared common prefixes.

An attacker can often guess that a repo might contain some well-known file. But combined with the plaintext file & directory metadata, I don't even need to guess. For example, if I see a file containing 35684 bytes named "seafile/common/processors/blocktx-common-impl-v2.h" in your encrypted repo, it wouldn't take much guessing for me to know exactly what the plaintext of that file must be. Then I can run the chunking algorithm over it, and I learn what the first 16 bytes of each block always encrypts to (because the IV never changes). I can then search for other blocks that start with those same patterns, and now I know some of the plaintext of your other files, too.

Repeat over and over for every known or guessable plaintext, and an accurate statistical picture of some of your private data can emerge. Or even worse, maybe I can send you some chosen plaintext (like a specially crafted PDF) and get you to stick it in your repo. That opens up even better attacks, because I can choose the chunking, tag my chunks with common shared prefixes of various lengths, and then accurately sample how the rest of each chunk encrypts.

Anyway, I'm just an amateur interested in improving open source security. Maybe try to engage some dedicated crypto discussion groups -- I bet you'll get an earful about potential risks. Then you can decide if those risks matter to your threat model.

Thanks for Seafile, if I didn't think it was useful I wouldn't spend time looking for security bugs. :-)

@q000te

This comment has been minimized.

Copy link

commented Jan 15, 2014

I second the need to encrypt all file and directory entries within encrypted libraries.
Furthermore the use of an HMAC of each chunk as its IV seems like an useful enhancement.

@tinco

This comment has been minimized.

Copy link

commented May 13, 2014

Having the same IV every chunk is the same as having no IV. You are not using the protocol in the way it was designed, so you are vulnerable to the attacks the protocol was designed to defend against. Using the HMAC of each chunk as an IV is better, but it introduces a relation between the IV and the data that was not researched by the designers of the protocol so it might introduce a weakness too. Intuitively the relation is faint and deliberately obfuscated, but a true cryptographer must judge whether that is good enough, and then other cryptographer should critique that judgement.

@3onyc

This comment has been minimized.

Copy link

commented May 14, 2014

Any news on this? Filenames (and the other mentioned issues) leaking information is a major problem. And unless it's clearly mentioned when creating an encrypted library may give people a false sense of security.

@patrickwolf

This comment has been minimized.

Copy link

commented Jun 8, 2014

Your page states:

Privacy Protection

  • Deploy on your own machine
  • Encrypt files with your own password
  • Keep password only on clients

Seafile provides an advanced feature called encrypted library to protect your privacy. The file encryption/decryption is performed in the client-side. The password of an encrypted library is not stored in the server. Even the system admin of the server can't view the file contents.
https://seacloud.cc/group/3/wiki/faq-for-security-features/

But as @ef4 points out above SeaFile really isn't ready to be used with sensitive material yet.

Your response is totally understandable:

Killing: But it takes a lot of effort so we don't have time to work on it currently.

BUT you need to need to state on your site that SeaFile is beta software and only rudimentary secure right now instead of making it look like it is fully secure.

Thanks!

@Finkregh

This comment has been minimized.

Copy link

commented Jun 8, 2014

kudos! @patrickwolf

@fstoerkle

This comment has been minimized.

Copy link

commented Oct 15, 2014

Is there any update on this topic?
Are the issues raised by @ef4 still valid in the latest release?

Would be glad to have your insight on this.

@kunnix

This comment has been minimized.

Copy link

commented Jan 21, 2015

Agreed with @patrickwolf, the documentation is currently misleading regarding what to expect from Seafile on the security/privacy side.

A fair move would be to add a "Limitations" notice to the documentation.

@killing: Any update on this?

@midi

This comment has been minimized.

Copy link

commented Jan 21, 2015

Another albeit not security limitation, auto upload of photos/videos on Android is not supported for encrypted libraries haiwen/seadroid#201

To my knowledge Seafile is still the best Open Source file syncing solution that has integrated encryption and thus no need to fiddle around with third party encryption tools, which is especially annoying on mobile.

@killing

This comment has been minimized.

Copy link
Member

commented Feb 1, 2015

For the time being, the only thing we plan to improve is use a different salt for each encrypted library. The current version still use a static salt for all encrypted libraries.
The other proposed security enhancements to encrypted libraries are not on schedule. Those includes:

  • Full encryption of file metadata, history etc. Only file content is encrypted.
  • Use separate IV for each file.

We'll make these limitations clear in our documentation. The users can make their own choice.

@CoolkcaH

This comment has been minimized.

Copy link

commented Feb 18, 2015

It's much worse to have bad encryption than no encryption...and don't even try to implement security or distributed code if you are not an expert in the field.
Use proven libs the recommended way only, and get the code audited.
Otherwise it's worse than useless, and the users cannot make their own choice because users know nothing about security.

@shuhaowu

This comment has been minimized.

Copy link

commented Feb 23, 2015

Full encryption of file metadata, history etc. Only file content is encrypted.

Wait, are histories decrypted and stored or something? The content in the history should be encrypted as well, right?

@shoeper

This comment has been minimized.

Copy link
Collaborator

commented Feb 25, 2015

look at the first post. Don't think anything changed so far.
And dev already commented on this 24 days ago - don't think it's that hard to read.

If you think your data is so important/confidential that it is not enough to keep it on your own hardware, don't think anyone will stop you from implementing this or hirering one to do so.

@killing

This comment has been minimized.

Copy link
Member

commented Feb 26, 2015

Yes, file contents in the history are encrypted.

2015-02-25 4:52 GMT+08:00 Aaron Hastings notifications@github.com:

Wait, are histories decrypted and stored or something? The content in the
history should be encrypted as well, right?

I certainly hope so. Can a dev comment on this?


Reply to this email directly or view it on GitHub
#350 (comment).

@akaho

This comment has been minimized.

Copy link

commented May 27, 2015

@patrickwolf I agree.

@curtiszimmerman

This comment has been minimized.

Copy link

commented Nov 28, 2015

Holy shit. This needs to be advertised loudly in the manual and the UI. I was about to send data to S3 and decided to look into how exactly Seafile is encrypting my library contents. This is security theater. I love Seafile, but people need to know to not use this functionality if they want something secure.

@kantorkel

This comment has been minimized.

Copy link

commented Feb 7, 2016

Any news on this topic?

@stevesbrain

This comment has been minimized.

Copy link

commented Feb 7, 2016

@ef4 - Just wanted to say I appreciate the in-depth explanation you have given; very insightful to read!

@killing

This comment has been minimized.

Copy link
Member

commented Feb 15, 2016

@kantorkel We'll update the encryption algorithm to use separate salt for each library in version 5.1 or 5.2. Other improvements proposed in this thread are not planned, as I said before. We'll make the limitation clear in our documentation.

@shuhaowu

This comment has been minimized.

Copy link

commented Apr 11, 2016

Where is the limitation section in the documentation? I cannot find it here: http://manual.seafile.com/security/security_features.html

@shoeper

This comment has been minimized.

Copy link
Collaborator

commented Apr 11, 2016

Which limitation? Are you talking about the metadata?

In the manual it says the following in bold characters.

Even the system admin of the server can't view the file contents.

kunnix added a commit to kunnix/seafile-docs that referenced this issue Apr 11, 2016

Update security_features.md
Documented how the metadata is stored server-side.

haiwen/seafile#350
@kelson42

This comment has been minimized.

Copy link

commented Feb 23, 2017

This ticket seems to be a blocker for Seafile adoption in Freedombox https://wiki.debian.org/FreedomBox/LeavingTheCloud

@k-ninja

This comment has been minimized.

Copy link

commented Jun 28, 2017

So what is the status on this? The issue remains Open, but @killing has stated that there are no plans for other improvements...

I sincerely hope that the issue related to the re-use of IVs is not going to stay unfixed forever, in fact IMO moving to at least using unique IV per file/block should be one of your highest priorities, if you are serious about Seafile being used for anything other than hobby file servers.

If there's not going to be any further improvements, then this issue should be closed, so that those of us who are hoping for an improvement can look for a product which better meets our needs. If there is any intention to improve the current implementation of encrypted libraries, then it would be good to get some kind of definitive time line on when we can expect it.

@instantname

This comment has been minimized.

Copy link

commented Mar 15, 2018

Shall this ticket not be split into two (or more) separate issues: the single IV vulnerability and the unencrypted metadata/history? The first one really is a bug that should be fixed, while the second one is more of a design choice.

On the long term, I agree with other comments that even the metadata of the "filesystem" should be encrypted. If you want to claim without small prints that "Seafile uses encryption", I think some effort should be put into having full encryption of the libraries.

@Chouchen

This comment has been minimized.

Copy link

commented Apr 23, 2018

More than 4 years? Any news @killing ? Wasn't aware of this and, as much as I like Seafile, that makes me want to stop using it…

@aadrian

This comment has been minimized.

Copy link

commented May 24, 2018

But they're happy for users to store their sensitive, private data with them, aren't they? Gee, I wonder why...

@alphapapa they're among the very few that allow you to install the server on your own hardware where you have the full control (and this can be even your home computer behind a NAT with DynDNS), so encryption is pretty much a non-issue there.

@alphapapa

This comment has been minimized.

Copy link

commented May 24, 2018

@aadrian That depends on your threat model.

@aadrian

This comment has been minimized.

Copy link

commented May 24, 2018

That depends on your threat model.

@alphapapa seriously? :)

Most Seafile users are just happy and grateful that they have an alternative to Dropbox et co that works on many device types too, is fast and they can own the server and data (as opposed to the many "alternatives"): this is the main use case of this application.

Being open source however, allows the many security experts around to contribute PRs for the use cases where they want to host Seafile like a service, for others: where encryption would be of course a requirement :) .

@alphapapa

This comment has been minimized.

Copy link

commented May 24, 2018

@aadrian I don't understand what you're getting at.

an alternative to Dropbox et co

There are open-source alternatives to Seafile.

Most Seafile users are just happy and grateful

Why did you emphasize the word "grateful"? Are you implying that we should not be complaining about security vulnerabilities? If so, that is a peculiar and dangerous attitude.

Being open source however, allows the many security experts around to contribute PRs

What? As this bug report demonstrates, Seafile's developers are not taking security seriously. Do you honestly think that the server is devoid of security flaws? Don't you think that the client having serious issues like this means that the server certainly does as well? In which case...

for the use cases where they want to host Seafile like a service

Seafile is certainly an unwise solution for those use cases.

where encryption would be of course a requirement :)

You seem to be missing a point: encryption is not the only issue. Security vulnerabilities are the issue. And the fact that the developers are not taking security seriously raises serious questions about the project as a whole. Who knows what other vulnerabilities the project might have, now or in the future. As I said, it should be carefully considered whether the project could be coerced into acting as honeypot.

If you don't care about security, fine, it's your data. Don't pooh-pooh the serious concerns others have about this project; doing so raises questions about your motivation.

@shoeper

This comment has been minimized.

Copy link
Collaborator

commented May 24, 2018

Security vulnerabilities are the issue. And the fact that the developers are not taking security seriously raises serious questions about the project as a whole.

From where do you know / infer that developers do not care about all security issues? This one is a very specific one. It does not affect the security for all users. For what I know other known security issues have been fixed within less than a week in the past.

And the reason it isn't getting fixed is quite obvious from my point of view. The professional edition customers don't use the feature. Most of them even don't want to have it, but ask for features allowing the administrator to have full control over everything. Since 5.0.1 there is even an option for the admin to fully disable encrypted libraries.

@aadrian

This comment has been minimized.

Copy link

commented May 24, 2018

@alphapapa

I don't understand what you're getting at.

There are several use cases for Seafile, with the main one being users that own a few devices (different types) and a personal server (or the desktop behind a NAT) and what to keep the data on them in sync (and private).

Encryption of that kind of server is not relevant in this case: what this ticket is about - so most users do not seem to be affected buy the actual poor encryption feature implementation of the server.

There are open-source alternatives to Seafile.

There are, but name only one that supports as many different clients, as easy to use, is as fast as Seafile, is still maintained and can be installed behind NAT, requires only port 443 ( -> SyncThing does not fulfill these common criteria :( ).

Why did you emphasize the word "grateful"? Are you implying that we should not be complaining about security vulnerabilities?

I'm implying that since the main use case of this application does not require Encryption, and since this ticket is about server encryption, the "outrage" does not seem to constructive here.

Do you honestly think that the server is devoid of security flaws?

Of course not, but it would be really helpful for all of us if those issues would be addressed separately (each one), since they should be fixed even if the users don't activate the encryption on their servers.

You seem to be missing a point: encryption is not the only issue.

This very ticket is however about encryption.

Security vulnerabilities are the issue.

Which ones? Please open a ticket if you are aware of them. Do you also have some sort of tests to reproduce them for the main use case this project has (since that's what most users care about)?

@shoeper

This comment has been minimized.

Copy link
Collaborator

commented May 24, 2018

@alphapapa you gave thumbs down. Could you please also tell which other security issues where not resolved and why you think security is not being taken seriously at all.

@christmart

This comment has been minimized.

Copy link

commented Mar 5, 2019

@killing We'll update the encryption algorithm to use separate salt for each library in version 5.1 or 5.2. Other improvements proposed in this thread are not planned, as I said before. We'll make the limitation clear in our documentation.

Did you ever update the encryption algorithm like you intended?
There is now a CVE https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7469 for this problem and the analysis seams to show that it is still not changed.

@moschlar

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

If we do not address this situation, the Seafile client will never be officially packaged for Debian (and thus, Ubuntu), Gentoo and probably all other distributions that care about CVEs.

@killing

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

We'll fix the salt issue recently and include it in 7.0 version of Seafile server. Also a new version of client is needed to work with the new encrypted libraries.

@killing

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

IMO, there is some misunderstanding in the CVE. Seafile doesn't use the same IV for every library. The IV is calculated from the library password and the salt. Even though the salt is reused in all libraries, the passwords are usually different.

What @ef4 originally stated is that the IV is reused for all the files in the same library.

@moschlar

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2019

@killing

What @ef4 originally stated is that the IV is reused for all the files in the same library.

Isn't it for every chunk, actually?

@killing

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

@moschlar Yes chunk is more accurate description for that.

@marcusmysc

This comment has been minimized.

Copy link

commented Mar 8, 2019

Glad to hear!

@Redsandro

This comment has been minimized.

Copy link

commented May 5, 2019

@killing said:

We'll fix the salt issue recently and include it in 7.0 version of Seafile server. Also a new version of client is needed to work with the new encrypted libraries.

This might be only semi-relevant: The Ubuntu 18.04 LTS version of the Seafile client is frozen, not updated for a while when updates to the client are available for Windows and OSX. I'm not sure what the (technical) reason is behind this, but if a client update is mandatory to support the server, will this mean that it is best not to update the server while some clients are still on Ubuntu 18.04?

This might annoy to some degree, because 18.04 LTS has 10 years of support and some LTS folks are perpetually reluctant to update their system.

@shoeper

This comment has been minimized.

Copy link
Collaborator

commented May 5, 2019

The official PPA linked at https://help.seafile.com/en/syncing_client/install_linux_client.html should deliver the most recent version of the client.

@Redsandro

This comment has been minimized.

Copy link

commented May 5, 2019

@shoeper I just double-checked, and indeed the version from the PPA was updated last year, it is not actually the most recent version. So it does get updated sometimes. Do the Linux- and Windows binary have alternating versions?

deb http://ppa.launchpad.net/seafile/seafile-client/ubuntu bionic main is at 6.2.9, while win and max are at 6.2.11.

@shoeper

This comment has been minimized.

Copy link
Collaborator

commented May 5, 2019

Normally not, but I don't know. Looking at the changelog (https://manual.seafile.com/changelog/client-changelog.html) it looks like the most recent changes were not worth an update for linux.

@killing

This comment has been minimized.

Copy link
Member

commented May 9, 2019

We've been working on to use different salt for each library. Currently there is a PR available: haiwen/seafile-server#221

@freeplant

This comment has been minimized.

Copy link
Member

commented May 18, 2019

This feature is included in version 7.0. To enable using new encrypted libraries with different salt for different libraries, you need to add the following configuration to seahub_setting.py

ENCRYPTED_LIBRARY_VERSION = 3

Currently the mobile clients and desktop clients does not supported new version of encrypted library yet. After we upgrade the clients, we will make the setting as default.

@Redsandro

This comment has been minimized.

Copy link

commented May 18, 2019

Thank you for the update @freeplant 👍

@Raph33

This comment has been minimized.

Copy link

commented Jun 21, 2019

Hello,
I'm only semi-technical so I didn't fully understand the entire thread above. Can someone help me understand: does the fact that SeaFile now uses "different salt for each library" mean that the amount of data leaked by encrypted libraries is reduced? Or that they don't link any information?
Thanks

@shoeper

This comment has been minimized.

Copy link
Collaborator

commented Jun 24, 2019

No

@killing

This comment has been minimized.

Copy link
Member

commented Jun 25, 2019

@Raph33 Use different salt for each library makes it harder for an attacker to crack the password or contents of the files in the encrypted libraries. But the metadata (e.g. file names, folder names, file sizes) are still stored unencrypted.

@killing

This comment has been minimized.

Copy link
Member

commented Jun 25, 2019

Update: desktop clients 7.0 already support the new encrypted library format.

@x11x

This comment has been minimized.

Copy link

commented Aug 1, 2019

Seafile doesn't use the same IV for every library. The IV is calculated from the library password and the salt. Even though the salt is reused in all libraries, the passwords are usually different.

Now with the new encrypted library format, salt is different for each file. This mitigates problems with the password possibly being the same for different libraries.

But the IV is still calculated from the library password and the salt. So the IV will be the same for all files/chunks in each the library? My understanding of AES CBC is that the IV should never be reused - there should be a unique IV for each file.

I may be misunderstanding the challenges but it seems like the IV should just be a random string stored in plain text in some kind of mapping from chunk to IV. The IV itself does not need to be kept secret if I understand correctly. It does not (should not?) need to be generated from the password/salt.

I wonder if the authors have considered libsodium / NACL - which takes away the need to worry about IVs and salts and whether you're doing it properly. There are a range of browser libraries available too.

@Raph33 the way I see it, this doesn't change much, the attacks described above still apply, but just for files within the same library.

Edit: I've reread the original issue and understand that random IVs might not be possible with the current sync/dedup algorithm and that using a HMAC was recommended. And I get that this would mean changes in the frontend like the inclusion of a crypto library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.