There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

Why is OpenSSL able to use a key file my user shouldn't have access to?

The following command works even though I really don’t think I should have permission to the key file:
$ openssl aes-256-cbc -d -pbkdf2 -in etc_backup.tar.xz.enc -out etc_backup.tar.xz -k /etc/ssl/private/etcBackup.key

I’m unable to even ascertain the existence of the key file under my normal user. I’m a member of only two groups, my own group and vboxusers.

The permissions leading up to that file:


<span style="color:#323232;">drwxr-xr-x   1 root root 4010 Jul 31 08:01 etc
</span><span style="color:#323232;">...
</span><span style="color:#323232;">drwxr-xr-x 1 root root      206 Jul 14 23:52 ssl
</span><span style="color:#323232;">...
</span><span style="color:#323232;">drwx------ 1 root root    26 Jul 31 14:07 private
</span><span style="color:#323232;">...
</span><span style="color:#323232;">-rw------- 1 root root 256 Jul 31 14:07 etcBackup.key
</span>

OpenSSL isn’t setuid:


<span style="color:#323232;">> ls -la $(which openssl)
</span><span style="color:#323232;">-rwxr-xr-x 1 root root 1004768 Jul 14 23:52 /usr/bin/openssl
</span>

There don’t appear to be any ACLs related to that key file:


<span style="color:#323232;">> sudo getfacl /etc/ssl/private/etcBackup.key
</span><span style="color:#323232;">[sudo] password for root: 
</span><span style="color:#323232;">getfacl: Removing leading '/' from absolute path names
</span><span style="color:#323232;"># file: etc/ssl/private/etcBackup.key
</span><span style="color:#323232;"># owner: root
</span><span style="color:#323232;"># group: root
</span><span style="color:#323232;">user::rw-
</span><span style="color:#323232;">group::---
</span><span style="color:#323232;">other::---
</span><span style="color:#323232;">
</span><span style="color:#323232;">> sudo lsattr  /etc/ssl/private/etcBackup.key
</span><span style="color:#323232;">---------------------- /etc/ssl/private/etcBackup.key
</span>

Finally, it’s not just the case that the original file was encrypted with an empty file:


<span style="color:#323232;">> openssl aes-256-cbc -d -pbkdf2 -in etc_backup.tar.xz.enc -out etc_backup.tar.xz -k /etc/ssl/private/abc.key
</span><span style="color:#323232;">bad decrypt
</span><span style="color:#323232;">4047F634B67F0000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:providers/implementations/ciphers/ciphercommon_block.c:124
</span>

Does anyone know what I’ve missed here?

ghjones ,

Just to verify all permission-related things in one go, see if you can open the key as your user with an editor like vi or nano. This will let you separate out some behavior specific to OpenSSL vs some behavior purely permissions-based.

I’m not sure what’s happening here, but the above test can at least narrow the focus.

theit8514 ,

The -k argument on my openssl accepts a passphrase, not a file. You likely encrypted with the filename as the secret, not it’s contents. Perhaps you should use -kfile instead.


<span style="color:#323232;">$ openssl aes-256-cbc -help
</span><span style="color:#323232;">Usage: aes-256-cbc [options]
</span><span style="color:#323232;">
</span><span style="color:#323232;">General options:
</span><span style="color:#323232;"> -help               Display this summary
</span><span style="color:#323232;"> -list               List ciphers
</span><span style="color:#323232;"> -ciphers            Alias for -list
</span><span style="color:#323232;"> -e                  Encrypt
</span><span style="color:#323232;"> -d                  Decrypt
</span><span style="color:#323232;"> -p                  Print the iv/key
</span><span style="color:#323232;"> -P                  Print the iv/key and exit
</span><span style="color:#323232;"> -engine val         Use engine, possibly a hardware device
</span><span style="color:#323232;">
</span><span style="color:#323232;">Input options:
</span><span style="color:#323232;"> -in infile          Input file
</span><span style="color:#323232;">** -k val              Passphrase**
</span><span style="color:#323232;"> -kfile infile       Read passphrase from file
</span>
418teapot ,

On my machine at least man openssl shows that -k is for specifying the password you want to derive the key from, so in that case I think you are literally using the string /etc/ssl/private/etcBackup.key as the password. I think the flag you want is -kfile.

You can verify this by running the command in strace and seeing that there is no openat call for the file passed to -k.

Edit: [email protected] beat me to it while I was writing out my answer :)

Maxy ,

I have about 0 experience with openssl, I just looked at the man page (openssl-enc). It looks like this command doesn’t take a positional argument. I believe the etcBackup.key file isn’t being read, as that command simply doesn’t attempt to read any files without a flag like -in or -out. I could be wrong though, see previously stated inexperience.

metiulekm ,

It seems OP wanted to pass the file name to -k, but this parameter takes the password itself and not a filename:


<span style="color:#323232;">       -k password
</span><span style="color:#323232;">           The password to derive the key from. This is for compatibility with previous versions of OpenSSL. Superseded by the -pass argument.
</span>

So, as I understand, the password would be not the first line of /etc/ssl/private/etcBackup.key, but the string /etc/ssl/private/etcBackup.key itself. It seems that -kfile /etc/ssl/private/etcBackup.key or -pass file:/etc/ssl/private/etcBackup.key is what OP wanted to use.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines
    •