Encrypted file may start with "<?xml ".

[vovcacik]

Environment

• Windows version: Windows 10 Pro
• Processor architecture: x64
• Encfs4win version: encfs version 1.10.1-RC10
• Dokan version (legacy, modern): Dokany 1.0.2

Description

When I use Null filename encryption and I edit a specially crafted txt file starting with <?xml (note the trailing space) through encfs, the underlying encrypted file won't be binary but is mixed - the <?xml is preserved and encrypted binary data follows it. This is the minimal example, but the problem can be made as bad as this.

The file starting with <?xml have to be created in underlying filesystem first and then it can be edited through dokan mount. If the file is created and edited through dokan mount it all works correctly.

Expected behavior vs. actual behavior

When I save file through encfs I expect the underlying encrypted file to contain only cipher binary data.

Steps to reproduce problem

Follow the prompts, it is 100 % reproducible. When you create encfs disk choose Null filename encryption, otherwise default values.

@echo off
mkdir "%temp%\bug"
encfs "%temp%\bug" x:

echo ^<?xml > "%temp%\bug\test.txt"

echo Open the x:\test.txt, input some s3cr3t and save it
pause

echo Now open the underlying "%temp%\bug\test.txt" and see that it starts with "^<?xml" which is strange
pause

pause
dokanctl /u x:
rmdir /S /Q "%temp%\bug"

Relevant logs

None.

[jetwhiz]

Hi @vovcacik, thanks for the bug report!

I will have to look at this more. It is very strange if behavior depends on the contents of the file itself.

Do you know if this issue exists in the upstream encfs project (on Linux), too?

Related: https://github.com/jetwhiz/encfs4win/issues/82, https://github.com/jetwhiz/encfs4win/issues/83

[vovcacik]

I am not sure, but it is possible, since the encfs config file leaks as well according to vgough/encfs#174. So it should be rather easy to reproduce this on linux:

• create new encfs disk with Null filename encryption
• go to your encfs disk, open encfs xml config file and save it (you don't need to do any changes, just make sure your editor won't ignore your save command due to lack of changes)
• go to your root/underlying dir and open encfs xml config - it should be malformed (like this)

[benrubson]

I can't reproduce this with upstream on FreeBSD (no reason to be different on Linux).

In addition, @vovcacik, I think the following from your test case is wrong : echo ^<?xml > "%temp%\bug\test.txt" And should be : echo ^<?xml > "x:\test.txt" Why do you want to directly write to the ciphered version ? You should not...

[vovcacik]

@benrubson I have updated report description to make clear that echo ^<?xml > "%temp%\bug\test.txt" is the secret sauce to trigger the behaviour. Can you test it again while you make sure the test.txt is created in the underlying filesystem and not through the mount point please?

You might be right that I should not mess with the ciphered files/dirs. But my understanding was that the ciphered files can be manipulated just like any other, e.g. you can copy them, move them, rsync them, git them etc. It is not exaggerated to say one of such tool could create local configuration file of some sort in the encrypted dirs that would start with <?xml. Not that I could name one such tool at the moment.

My concern here is that any files starting with <?xml are handled as special by encfs, which seems wrong. Then funny stuff happens 1.

[vovcacik]

Also I was explicit about that the <?xml_ is ending with trailing space, but it is easy to overlook (github trims it after rendering markdown) - just in case you are going to test this again on your system.

[benrubson]

I did my tests with the trailing space :)

But my understanding was that the ciphered files can be manipulated just like any other, e.g. you can copy them, move them, rsync them, git them etc.

You're right, but not modify them as plain file. The plain text you put in a file among the ciphered one will tried to be decrypted, and garbage will then be displayed by EncFS while reading it though the EncFS mount point. I think that if you activate MAC headers, an error will occur reading such a file.

I was going through all encfs-upstream issues to see how I could help, and I think this one is rather an user issue, as EncFS is not intended to be used like this :)

[vovcacik]

There are legitimate use cases. For example you want to cloud sync your directory (think Dropbox, bittorrent sync, syncthing or other) and you decide to use encfs for end-to-end encryption. But the sync solution of your choice is creating xml configuration files inside the synchronized directory.

[benrubson]

Put your encfs directory in a subfolder of the synced directory, so that your sync solution xml file is not inside the encfs dir, but in the top-folder ?