Reading Secret Files From a Mounted Windows Folder Deletes Contents of Secrets File When Using 'sudo'

[Myvryn-LF]

This is an interesting one.
** WARNING **
Before attempting to reproduce this bug, make sure you are testing on a file that you are willing to lose (copy of an existing file or a file that you've created for the explicit purpose of having nuked).

SETUP:

1. Store your secret files on a Windows based file server.
2. On a linux machine (I was using Ubuntu 22.04.3 LTS), mount the Windows Folder

STEPS

1. Use ssclient to read all/any of the keys in your secrets file
   ssclient get -s temp_store.json myPasswordKey --all
2. Scratch your head wondering why your decrypted password(s) were displayed, but your command prompt has not returned.
3. Hit CTRL+C to cancel the running command
4. ls -l to list the contents of your directory
5. Repeat step 4 a few times until you see that the size of your file is now 0 and all contents have been wiped.

[mqudsi]

Out of curiosity, can you install the rust client and try it? Cargo install ssclient

[Myvryn-LF]

I was trying to read the secrets via the rust client on the Linux box. So, it's already installed. I'll record a video for you tomorrow and post it. Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Mahmoud Al-Qudsi ***@***.***> Sent: Thursday, February 15, 2024 7:50:26 PM To: neosmart/SecureStore ***@***.***> Cc: Eddy Jones ***@***.***>; Author ***@***.***> Subject: Re: [neosmart/SecureStore] Reading Secret Files From a Mounted Windows Folder Deletes Contents of Secrets File When Using 'sudo' (Issue neosmart/securestore-rs#6) [EXTERNAL] Out of curiosity, can you install the rust client and try it? Cargo install ssclient — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.com/v3/__https://github.com/neosmart/securestore-rs/issues/6*issuecomment-1947714719__;Iw!!AD8y5q2f9OQ!tx-C20kDmhKNtc0GogqMkDAukqh9Op3-XKvVuyZiFLL_l6q_2yKx_dOe3Sp0ePigy5Di1dCECSXBm-Xn2nUYjlgNXK9f1Q$>, or unsubscribe [github.com]<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/BBPO25ZEZKFDDEGRKOARVRTYT3JQFAVCNFSM6AAAAABDJMTDKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBXG4YTINZRHE__;!!AD8y5q2f9OQ!tx-C20kDmhKNtc0GogqMkDAukqh9Op3-XKvVuyZiFLL_l6q_2yKx_dOe3Sp0ePigy5Di1dCECSXBm-Xn2nUYjlg0cRHiEg$>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[mqudsi]

Oh, ok. What about trying the .NET client on Linux?

dotnet tool install --global SecureStore.Client

[Myvryn-LF]

Now that I haven't tried. I'll let you know tomorrow Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Mahmoud Al-Qudsi ***@***.***> Sent: Thursday, February 15, 2024 8:14:43 PM To: neosmart/SecureStore ***@***.***> Cc: Eddy Jones ***@***.***>; Author ***@***.***> Subject: Re: [neosmart/SecureStore] Reading Secret Files From a Mounted Windows Folder Deletes Contents of Secrets File When Using 'sudo' (Issue neosmart/securestore-rs#6) [EXTERNAL] Oh, ok. What about trying the .NET client on Linux? dotnet tool install --global SecureStore.Client — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.com/v3/__https://github.com/neosmart/securestore-rs/issues/6*issuecomment-1947730050__;Iw!!AD8y5q2f9OQ!s6U8G3yP5YSZPH2lsW1Y88iEoIJSccAEJovkdxywEm7d2YcWPM76Y_lIxznPgt5z1CZY1St9Rfp5jhvf8N6Wa-pw6b6Cxw$>, or unsubscribe [github.com]<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/BBPO2566EOUEYQKGR5L4QRTYT3MLHAVCNFSM6AAAAABDJMTDKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBXG4ZTAMBVGA__;!!AD8y5q2f9OQ!s6U8G3yP5YSZPH2lsW1Y88iEoIJSccAEJovkdxywEm7d2YcWPM76Y_lIxznPgt5z1CZY1St9Rfp5jhvf8N6Wa-qmAC-FcA$>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[mqudsi]

I've moved this to the securestore-rs repo, as it seems the bug is in the rust version of the client (unless @Myvryn-LF reproduces it with the dotnet one, too).

[Myvryn-LF]

Well, it looks like the process hanging and the "wiping out of the secrets file" part of this is no longer happening. There may be something specific about the file that I was using in my earlier trials, I will continue to investigate that to see if I can't find the circumstances. However, I am still seeing the "IO Error / Permission denied" that shows up AFTER ssclient shows me the password requested.

This is repeatable with both the RUST and .NET clients.

If this was a network permissions issue, I would understand, but I would also expect to not actually be able to read the secrets in the file. As you can see, though, I'm able to query the secrets file and get an appropriate response.

[mqudsi]

If you have a legacy version of the store and are using a modern version of ssclient or securestore.client, the client will attempt to upgrade the store before exit.

I'm guessing the store is read-only to the active user (+r, -w) so the read and decrypt succeeds but the write fails. This may — possibly — be why you are not running into the "wipe the store" issue as well, if your user doesn't have permission to do that.

[Myvryn-LF]

Thanks,

I'm assuming that because I created the store files with the current version of SecureStore they are not legacy stores and, therefore, shouldn't require a file write to upgrade. However, the error that I'm seeing definitely looks like it's occurring because it's trying to write to the mounted (windows) folder; just as you described.

Reasoning:

• I can create/get/set with no problem from a PowerShell terminal.
• I cannot create/set from a Linux terminal (haven't tried a WSL terminal yet)
• Looking at permissions in Linux: -rwxr-xr-x and no amount of chmod will change that
• Looking at permissions in Windows: there appear to be special settings for the "read only" checkbox, and attempting to change those permissions only reverts back to the original state immediately.
• And this is not to mention that I get a permission denied error trying to "touch" a file in that mounted folder as well.. (probably should have checked this first :P)

I will work with my IT dept. to get them to allow writing to this folder from a linux vm.

This is great stuff, and very useful. Thanks for working on it and putting it out there for everyone's use.

Myvryn

[mqudsi]

I created the store files with the current version of SecureStore they are not legacy stores and, therefore, shouldn't require a file write to upgrade

I'm sorry, I completely forgot about the usual case! ssclient writes the store on exit to serialize any changes to the store (e.g. to persist the result of an ssclient set ... command). I can't remember off the top of my head if this is unconditional (i.e. even in the case of a read-only operation) but there's a real chance it's done in all cases.

[Myvryn-LF]

And I just figured out how to repro the "wipe out the store" problem.

The mounted folder is owned by root, so I have to use sudo to write to it.
Executing a get or set as sudo with ssclient will actually wipe out your secrets file.

EDIT:
This does NOT happen with the .NET client.

I did notice one thing odd. When I ran a get on the store file, the file size changed from 914 bytes to 884 bytes. There was no text difference, the line endings appeared to be the same, CRLF. A hex compare with BeyondCompare also says that the files are identical. I have no idea where those 30 bytes went. Other than file size differences there, the file was completely useable and didn't appear to be altered by the get command.