LUKS password stored in plaintext at /root/keyfile


BennTech

Recommended Posts

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
  • Like 1
Link to comment
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
  • Upvote 1
Link to comment
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.

  • Like 1
Link to comment
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.

  • Like 1
  • Upvote 1
Link to comment
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

  • Like 1
Link to comment
  • 1 month later...
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...

Link to comment

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

Link to comment
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.

Link to comment
  • 2 weeks later...
  • 5 months later...
On 11/4/2019 at 5:09 AM, limetech said:

This is a question, not a statement so please don't hurt me :) I feel like i'm going to get punched for re-opening this old wound, but i saw this comment which actually had me a bit worried. Should i be? I'm not sure if that is even valid anymore with bonienl's most recent comment but the dates are oh so close to each other. The quote is from the above URL.

Quote

Here's what I think we can do.  I'll create a new config setting, call it "BLKMGK mode", when set to Yes then when emhttpd initiates the mount sequence it will write the plaintext passphrase to /root/keyfile and then at end of mount sequence it will delete the file.  That way UD can pick up the passphrase - but bear in mind, any other plugin could possibly pick it up too.

I'm here because i was wondering if could grab my LUKS password to pass to a script without me having to store the password somewhere or manually type it in. But thinking about it, it's actually a bit worrying that anyone could write a plugin that could scape that.

Link to comment

The way it is implemented in 6.8 and later, is that the passphrase is no longer stored in a file, but internally cached by the emhttpd process.

 

This makes the passphrase invisible/non-retrievable once entered at startup of the array.

 

When using a keyfile, this file is copied to /root prior to starting the array. The option exists to delete the file from /root after the array is started/

 

  • Thanks 1
Link to comment
  • 1 month later...
On 4/15/2020 at 6:00 AM, bonienl said:

The way it is implemented in 6.8 and later, is that the passphrase is no longer stored in a file, but internally cached by the emhttpd process.

 

This makes the passphrase invisible/non-retrievable once entered at startup of the array.

 

When using a keyfile, this file is copied to /root prior to starting the array. The option exists to delete the file from /root after the array is started/

 

My standard disclaimer: I only know enough to break things that I don't know how to fix...

 

I've written my go file such that at boot, I get my array passphrase via AWS Secrets Manager and write it to /root/keyfile. unRAID then uses /root/keyfile to unlock/startup my array. I've been manually deleting my keyfile after startup.

 

The aws-cli command I use for the procedure above retrieves a string, not a file. So, is it possible to use the output of this command as the passphrase rather than writing it to a keyfile first?

 

Thanks!

Link to comment
  • 3 years later...
On 9/5/2019 at 7:02 AM, 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.

 

I agree. It's unfortunate that as projects grow larger and attract followers, people's natural disposition is to reflexively "defend" (not really, but that's what they think they're doing, it's more like enabling) whenever someone points out a flaw, especially when they don't understand the severity of it. If you don't understand why this was (is?) such a big issue, and why BennTech was justified in addressing it the way he did, it might be best to refrain from commenting altogether. You're not "defending" anyone because there was no attack to begin with; he rightfully brought attention to a BIG ISSUE. He did so respectfully, yet he encountered not only a dismissive attitude but one that betrayed a lack of understanding of BASIC cybersecurity hygiene (which was both informative and unfortunate). I'm glad that in the end it looks like the project lead's better angels emerged victorious in this situation. I'm not thrilled that this is my first post here but I wanted to add my 0.2 cents so, hopefully, when another cybersecurity issue is brought up again in the future it won't be met with the same dismissive treatment from prominent members of this community. This wasn't a niche issue; it should never have occurred in the first place so I empathize with BennTech's frustration when all he got was dismissal when he brought it up. Thank you @BennTech for bringing it up when you did and the way you did it, clearly delineating why it was a big issue. And thank you devs for addressing the issue despite it seeming like you disagreed lol.

Link to comment

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.