Jump to content
BennTech

LUKS password stored in plaintext at /root/keyfile

38 posts in this topic Last Reply

Recommended Posts

To put things into a more realistic perspective ... If people have physical access to my server, I'm more concerned about being kidnapped, shot, or killed than my data drives being taken.

Share this post


Link to post
47 minutes ago, BennTech said:

This is what LimeTech representatives SHOULD do when an Unraid customer reports a security flaw:

  1. Acknowledge the customer's concern.
  2. Acknowledge the security flaw.
  3. Describe the steps being taken to correct the issue.
  4. Thank the customer for reporting the flaw so LimeTech can continue to improve and secure their product.

 

Alright, you get the point. You found something that was raised before in the encryption discussions, but you raised it loud. However, I do say 'thank you' for reporting this. 

 

47 minutes ago, BennTech said:

I am offended by the way LimeTech and everyone else in this thread other than Xaero has repeatedly dismissed all my concerns, and I feel I'm owed an apology in addition to a thank you for pointing out this security flaw. I'm not so naive as to think that anyone, especially from LimeTech, is going that. Instead, I'll just have to settle for them fixing the issue (sort of), which is at least an acknowledgement that saving a plaintext password to a file is insecure even though they never actually admit it.

 

I agree, you both provided decent solutions, but do note that even salted password hashes have to be securely computed using proper sources of random data and the salt cannot be user-controlled input, something that cannot be easily guessed and derived. We all know about rainbow tables and how to generate them based on common and re-used usernames.

 

47 minutes ago, BennTech said:

BTW, yes, I actually do run pfSense with Snort--I've been using it for 14 years since v0.9.8 when it forked off m0n0wall. No, I don't run Qubes--my work/clients require Windows, but I do run a Kali VM to perform basic PenTesting at my clients. Yes, I do know about LiME to grab passwords from memory and had started to include it in a previous response but removed it because what's the point in all that if I can't even convince any of the devs that saving a plaintext password to a file is bad.

 

That's great! Check out opnsense and suricata ;) 

 

Also for Qubes, you can run Windows VM and AppVM  (Seamless Apps). Check it out, if Snowden uses it, so can you - I've been running it for awhile as well! Tinfoil hats! 

 

47 minutes ago, BennTech said:

And to all the LimeTech devs, even though you never said thank you, you're welcome. Assuming you implement the changes described by limetech above, you and all your users will soon enjoy a better and more secure Unraid thanks to me bringing this security flaw to your attention.

Now this part man, why so arrogant, you are better than this - you are a professional. Ping them directly and workout a fix, you can be part of the solution. You can even test it first!

 

 

Edited by ezhik

Share this post


Link to post
18 minutes ago, BRiT said:

To put things into a more realistic perspective ... If people have physical access to my server, I'm more concerned about being kidnapped, shot, or killed than my data drives being taken.

 

I guess the concern here is in case of a really targeted attack where somebody exploits for example an externally accessible web-based docker and gets a reverse shell on a server as root and then gets access to the passphrase to decrypt master keys for disks. But even then in order to actually use it - they would need to either have physical access or leverage IPMI or iLo to actually reboot the system and boot to an ISO and access the drives for data exfiltration. We are talking about some next-level espionage right here.

 

So this type of scenario would be really targeted.

 

Personally, if somebody steals my drive and manages to decrypt it - they would definitely return it back to me with an apology note after seeing my nudes.

 

It all depends on what you are protecting. There is always the right tool for the job. In this case, for somebody who is security paranoid, this may not be it. 

 

May be a standard linux raid6 (mdadm) with encrypted lvm would be a better fit then. All comes down to security vs convenience. The more  functionality you add, the more security you trade.

Edited by ezhik
  • Like 1
  • Haha 1

Share this post


Link to post
On 9/1/2019 at 2:19 PM, limetech said:

It's not written to any permanent storage, it's written to a file in the root file system which is in RAM.

 

Your "secret password" is only to decrypt the drives - even if the password were leaked somehow they still need the physical drives to make use of it.

 

You'll first have to teach her to hack your root login password in order to get into your server.

 

As @bonienl mentioned in above post we have made some changes so that casual user doesn't accidentally leave a keyfile laying around.  These will appear in Unraid OS 6.8 release.  In meantime, click that 'Delete' button after Starting array

 

and, I'm done talking with you.

I find it disappointing that a developer like yourself would take these comments so personally. I imagine you have a lot invested into Unraid, but as a business you should be responding to your customers with respect and courtesy no matter how they are acting. Rather then responding in frustration, just refrain from responding. I really appreciated how ezhik responded to BennTech.

Share this post


Link to post
2 hours ago, justvano said:

I find it disappointing that a developer like yourself would take these comments so personally. I imagine you have a lot invested into Unraid, but as a business you should be responding to your customers with respect and courtesy no matter how they are acting. Rather then responding in frustration, just refrain from responding. I really appreciated how ezhik responded to BennTech.

Sorry but I disagree.

 

LT has always been so often too nice and bowed down to pressure from the minority that happens to scream really loudly about niche issues.

e.g. new GUI too big / small and certain people refused to use their browsers' native zoom functionality and demanded very loudly that LT changed everything back to the way they were familiar with - and guess what, LT spent time and resource responding to these GUI supremacists while ignoring the fact that Gigabyte X399 users (e.g. me) have severe lags that to-date still have not been resolved.

 

So it's rather refreshing to hear LT dev(s) get the balls to respond to loudmouth screamers in a different way. Donald Trump and Boris Johnson come to power because people are too nice to scream back at them.

Share this post


Link to post
On 8/31/2019 at 2:59 AM, limetech said:

Having read through the topic, we will make these changes:

  • Change the default action of array Start to shred /root/keyfile after opening all the encrypted volumes.
  • Add an additional configuration variable, probably under Settings/Disk Settings to change this default action if someone wants to, with clearer help text that explains what's happening (though the current Help text does explain it).
  • Add the ability to change the passphrase.

 

I hope the 6.8 changes won't break the ability to GUI mount an encrypted drive (with or without retyping pass) using Unassigned Devices after array start

Share this post


Link to post
On 9/6/2019 at 9:06 PM, golli53 said:

I hope the 6.8 changes won't break the ability to GUI mount an encrypted drive (with or without retyping pass) using Unassigned Devices after array start

Well funny you should say that...

 

Apologies for bumping an older thread, but I've spent the last hour or so confused as to why I haven't been able to perform one of my regular backups to an encrypted external USB HDD using Unassigned Devices, like I've been doing without hiccups for months. Was confused as to why the log kept spitting out "luksOpen: key file not found" every time I tried to mount the HDD when I knew that Unraid generated a temp keyfile upon array start, but after a little googling and finding this thread I realized what's happening - this is the first time I've tried backup up to this disk since switching to the RC branch a couple of weeks ago.

 

I presume that the solution is that I should manually generate a keyfile containing my array passphrase and place it in /root every time I want to backup for the foreseeable, and then also manually delete that file once the backup is finished? Guess this is one of those bugs (or perhaps better to call it an unintended side effect?) that can come from going with RC...

Share this post


Link to post

Aha, thanks for the clarification!

 

(And nice one tracking down that SQL corruption bug btw.)

Share this post


Link to post

I’m fairly sure that storing the key isn’t the issue it’s that it’s plain text. I’m also fairly sure that other apps can successfully utilise stored keys that include some kind of encryption / salt, so they’re not plain text - not that I’m an expert.

I’m just saying it seems like the issue is that it’s plain text not that it’s stored and I think that should be resolvable.

Sorry if someone already suggested this, the thread is long on my tiny phone.


Sent from my iPhone using Tapatalk

Share this post


Link to post
22 hours ago, Marshalleq said:

I’m fairly sure that storing the key isn’t the issue it’s that it’s plain text. I’m also fairly sure that other apps can successfully utilise stored keys that include some kind of encryption / salt, so they’re not plain text - not that I’m an expert.

I’m just saying it seems like the issue is that it’s plain text not that it’s stored and I think that should be resolvable.

Sorry if someone already suggested this, the thread is long on my tiny phone.


Sent from my iPhone using Tapatalk

This is exactly the point.

Share this post


Link to post
On 11/5/2019 at 8:41 AM, justvano said:

This is exactly the point.

Yeah so someone just needs to encrypt / salt the file, which leaves it readable to the OS and not readable to the casual file system browser and we're done.  No more complaints.  Sounds reasonable!  Hopefully limetech will agree.

Share this post


Link to post

This is addressed in version 6.8. Passphrases are no longer stored in a keyfile.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.