CVE-2017-16560 — SanDisk SecureAccess can leave plain-text temporary files on disk

I recently picked up a SanDisk Ultra USB 3.0 128GB flash drive, it’s a fairly old model so I got it for cheap, but I noticed it came standard with a piece of SanDisk-branded encryption software. SanDisk SecureAccess is developed by a third-party named EncryptStick.

I couldn’t find any real reviews when I looked so I figured I do a bit of digging, and it wasn’t long before it became apparent that there was an issue with how the software handles opening encrypted files.

The software provides two methods for opening files, either you can “copy” them to a new location, whereby the application will load the file into memory, decrypt it, then dump it into the directory of your choice, or you can open the file “in place”. This works as you would expect, you double-click on the file in the file list and it opens in your default application.

The example file in this case is simply named “Document.docx”

Double-clicking the file to open it in Word, and examining procmon, you can see how this mechanism works. First off the program reads some basic information about the file you're opening, then it creates a temporary file in “%TEMP%\Sandisk SecureAccessV3\”. It then reads the encrypted file into memory, decrypts it, then writes it out to the temporary file.

In itself this isn’t great, but the real issues occur when the program needs to manage the file it decrypts. If you open a Word doc, for example, you would expect that SecureAccess would monitor the file and delete it when the file is closed. This is not the case, and the file will remain on disk until the user exits SecureAccess. During the exit routine the program will delete any temporary files created during that session.

This problem is made worse by the fact that, if the user has the file locked when they exit SecureAccess, the Delete command will fail. In this circumstance I expected to receive an error from SecureAccess stating that the file was open and must be closed, but instead the application exits and leaves the plain-text file on disk.

Secure Access tries to delete the file, which promptly fails because the file being locked

Contents of the temp dir after closing the app

A similar issue exists if the application crashes when the user has a file open. As SecureAccess creates a plain-text copy of the encrypted file on disk, if the program exits unexpectedly (program crash, power failure, or the user ends the process) the routine to delete the temporary files does not run, so any files you’ve opened during that session remain on disk in plain-text.

This is exacerbated by the way that Windows handles the “%TEMP%” directory. In standard operation this directory is not emptied unless the user explicitly empties it, either by deleting the content manually or using some other utility. Thus a user who uses SecureAccess fairly regularly is much more likely to end up with some plain-text copies of their files sat on their disk.

Communication with vendor

After discovering this issue I reported it to the vendor, SanDisk , on the 5th of November and waited for a response. I received the initial response from the vendor in just six days which stated the following:

Thank you for contacting SanDisk® Global Customer Care. We sincerely appreciate you sharing your feedback and pointing this out for us to know.

Please be informed the application is ‘as designed’. We need to write a clean copy of the file to some temp space where applications like Word and Excel can access them, and where they can be checked by a virus scanner before they are opened. This implies that they are unencrypted and accessible at that specific moment, otherwise Word and Excel cannot work on then.

When the application closes, the file should be removed. When the file is locked, there is no way we can remove it or shred it. The OS prevents this.
When this happens, the user gets a popup warning telling him that the file could not be deleted.

Please feel free to reply to this email if you have any other concerns.

I wasn’t satisfied with that response, while I understand their stance that they do need to store plain-text copies of files on disk temporarily so that user applications can interact with them, the software should at least warn the user if there is the possibility that these plain text copies might be left on the disk. They also state that the user would receive a pop-up telling them that the file could not be deleted, however this was not the case in any of my testing.

I followed up on their response outlining this, and that the application should at least give a warning or ideally refuse to exit if it is unable to remove any temporary files it creates, but was met with the following response:

Thank you for the continued response. We value your feedback and please allow me to inform you that we have discuss this issue with the engineers and it is not a vulnerability, we have confirmed with the engineers that the software works as programmed. There is nothing we can do change it.

Timeline

05/11/2017 — Initial report to vendor
11/11/2017 — Response from vendor stating that they do not believe this is a security issue, further details sent
15/11/2017 — Confirmation from vendor that they do not believe this is a security issue