![](http://content.invisioncic.com/u329766/set_resources_34/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
BennTech
Members-
Posts
16 -
Joined
-
Last visited
Converted
-
Gender
Undisclosed
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
BennTech's Achievements
Noob (1/14)
13
Reputation
-
Yeah, you're right. This did get blown out of proportion. This is what LimeTech representatives SHOULD do when an Unraid customer reports a security flaw: Acknowledge the customer's concern. Acknowledge the security flaw. Describe the steps being taken to correct the issue. Thank the customer for reporting the flaw so LimeTech can continue to improve and secure their product. The only part has happened is #3. However, even in their "fix" LimeTech doesn't acknowledge that they are going to stop writing a plaintext password to a file. Quite the opposite--their fix is to shred the keyfile, so apparently they're still dumping the password to a file. I've offered several constructive ideas and solutions. I've thanked multiple people in this thread, including multiple devs. Has anyone thanked me for bringing this security flaw to light? What is it that I said that is so condescending? That it's lazy programming to save a plaintext password to a file? IT IS. Meanwhile, the devs have dismissed my concerns this entire thread. They have refused to acknowledge that saving a plaintext password to a file is insecure and have even denied that there is a security issue at all, with excuses like it's a RAM drive, or that you can delete the keyfile (that users don't even know exists). Is that constructive? How is dismissing a customer's valid security concerns like they don't matter NOT condescending? It is, and devs have done that to me multiple times in thread. So why don't you get onto the devs for being condescending to their customers? 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. 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. 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.
-
Thanks, limetech, for your thorough answer. I have to reiterate that I still don't want my password written in plaintext to disk. This reduces security by unnecessarily introducing an additional attack vector. Now my secret password is not just vulnerable to keyloggers, shoulder surfing, etc., but also to all the vulnerabilities of a keyfile. Yes, the password is also available in memory, network buffers, etc. But to retrieve it from those locations requires precise timing and more skills than most computer-literate users possess. Again, no system is 100% secure, so this is about making it too difficult to be worth the effort, and files are ridiculously easy to obtain, even by my computer-illiterate 75-year-old mother. I'm confident that I could teach her how to get the password from the plaintext keyfile in a few minutes, but I don't think I could ever teach her how to grab the password from a network buffer. As I said and Xaero provided an example, LUKS does not require writing the secret password to a file. To me, this looks like lazy programming so Unraid can use the same unlock method for either a keyfile or a password. And Xaero, I'm still not on board with your idea for different keys per drive. If it's formulaic, like salting with the license key or drive serial, that can be easily replicated. If you're relying on a cipher system, you're adding another attack vector (the cipher system, its recovery mode, its formula, its storage method, etc.), which I should note will be written by the same company that thinks it's OK to write passwords in plaintext to the file system. No thank you. Plus, I would much rather know the exact password(s) to my encrypted drive than to rely on the added complexity and insecurity and incompatibilities of an external program. A potential solution could be that when LimeTech implements multiple keys. Assuming they allow users to assign unique keys per drive (e.g., so you can hand over a single drive to someone), that could be used to optionally leverage multiple passwords to start the array. This is tricky to implement because most people will want the same password for all drives and will not appreciate having to repeatedly type the same password for every drive in their array. They'll want one blank to enter one password. So how do you implement multiple passwords without frustrating the majority of users? Maybe try that one password on each drive, and prompt for an additional password if that one doesn't decrypt all the drives, then repeat until all drives are decrypted. (It would only take a few seconds to check even for a huge array.) Or maybe a multi-line text box to enter a different password on each line, then try each password on each drive until one decrypts it. Also, these techniques allow for one set of drives all containing related information to be keyed with the same password, and another set to be keyed with a different password. All certainly possible, but all depends on how LimeTech implements multiple keys.
-
Thank you, Xaero. Finally someone who gets it. I will say this in defense in LimeTech. LUKS is relatively new for them, and they plan on adding features in future versions, like allowing multiple keys (something that is already built-in to LUKS, but currently has to be done manually with cryptosetup). That said, I think LimeTech should keep a single password for the whole array. I shouldn't need to enter a different password for every drive in my array--that can get unwieldy. And salting the password with the license key or drive serial doesn't add much security since those are available both inside and outside Unraid. Worst of all, that would make my LUKS drives inaccessible in other LUKS-compatible systems because of some Unraid-proprietary manipulation of my password. That's one of the reasons I like both Unraid and LUKS--if my server crashes or I chose to stop using Unraid, I can plug my drives into virtually any other Linux system and access all my files. What SHOULD happen--and I don't know if Unraid is doing this or not--is the AES key should be randomly generated for each drive. With LUKS, the shorter user password unlocks the huge AES key, and it's that AES key that encrypts/decrypts the drives. Each user password has its own copy of that AES key. If you give someone a single drive from your array with their unique password, they now have access to the AES key. So the security hole is that if the Unraid array uses the same AES key for all your drives, they now have the key to all your drives from that single one that you gave them. Again, I don't know whether LimeTech uses different AES keys for every drive or not. I certain hope each drive has its own unique, randomly-generated AES key. That's getting nit picky and a little off-topic, and frankly I don't care too much about all that right now. I'm more concerned about the blatant security flaw of my password being saved in plaintext to a file. You're absolutely right about everything else you said. I am well aware of all the other flaws you mentioned, but I didn't bother going into to those details because I can't even convince these people that saving the array password in plaintext to a file is BAD BAD BAD. Thus, they clearly won't have a clue or even care about Meltdown, Spectre, or Use After Free vulnerabilities. And frankly, none of those are even necessary since the PASSWORD IS MORONICALLY STORED IN PLAINTEXT TO A FILE and left there for all to see. Seriously, people...WTF? "If you can implement mitigation you should." <<< YES! YES! YES!
-
bonienl, you helped me out with jumbo frames affecting Unassigned Devices, and I appreciate that. But you are absolutely wrong here. Storing a secret password in a plaintext file is a HUGE SECURITY FLAW. Not accessible by any regular users? So Unraid and its underlying Slackware OS is 100% free of all exploits and privilege escalation? All Unraid plugins and apps and dockers are likewise 100% free of all exploits and privilege escalation? Let's be clear: NO SYSTEM IS 100% SECURE. Even LUKS can be bruteforced. The point is to make it as difficult and time-consuming as possible, something that is so unreasonable it's not worth the effort, like thousands of years to bruteforce the LUKS AES encryption. Thus, the attack vector is usually the much simpler user password that produces the full AES key. If you don't understand why storing passwords in plaintext is bad, research the RockYou breach. 32 million user passwords dumped because they were stored in plaintext. That password list is so popular that it's included in Kali Linux. To avoid things like that, passwords should be stored as hashes, not plain text. However, there are hash tables that instantly convert hashes to text. Thus, to make cracking more difficult, passwords are usually "salted" before hashing. Thus, an attacker would need to determine the salt, then bruteforce the password. Still crackable, but with long and complex passwords, it could take hundreds of years. Mission accomplished--not worth the effort. I have a ridiculously long and complex password. Again, I am not using a keyfile like a lot of people do to implement the inherently insecure "autostart". Instead, I am using a SECRET password that Unraid then makes available to everyone INSTANTLY. OK, fine, it's available only to root. And also available to every exploit and privilege escalation that can get root access. And let's not forget that the Unraid WebGUI and terminal REQUIRE ROOT. No other account can access those, so anyone who needs to do anything on Unraid, even just to check the status of a parity check, requires the root account. Thus, everyone who needs to administer Unraid has to share the same root account. Let's gloss over that security flaw and focus on the fact that that means everyone--regardless of how trivial their task is--has access to the Unraid LUKS password. And it's not just the Unraid server or root account that can be compromised. After finishing in the WebGUI, did the Unraid admin (i.e., root) click the obscure little "Logout" icon? No? BAM! Access to the plaintext LUKS password. You don't even need to know the root password in this case, but if you want it, check out tools like LaZagne. How about social engineering? BAM! Access to the plaintext LUKS password. Exploits and privilege escalation? BAM! Access to the plaintext LUKS password. And yes, I've seen the option in the WebGUI to delete the encryption keyfile. But since I don't use a keyfile, I shouldn't need to delete a keyfile, right? And that idea is further supported by the fact that the Delete button is disabled. It's only when I click the obscure checkbox in the other column to indicate "Yes I want to do this" that the Delete button is then enabled. So what exactly am I about to do? Like I said, I don't use a keyfile, just a password. So to me it looks is this a way to delete the AES keyfile stored on the drives. And yes, deleting the primary encryption key is an option in many disk encryption software, including LUKS. That's essentially an unrecoverable loss of encrypted drives, and hence the obvious need for the checkbox verification before the Delete button is even enabled, and hopefully a supplementary "Are you sure? Type YES to confirm" dialog. But I wouldn't know because I never got that far because I don't use a keyfile! The WebGUI is unclear what any of this does, and I sure as hell don't want to click a button that possibly makes my encrypted data permanently inaccessible. I infer from your description that that is not the case and that it just deletes the keyfile THAT SHOULDN'T EVEN EXIST, but how are we supposed to know that? Nowhere have I found Unraid mentioning that it stores your secret password in plaintext in the file system. So why would I or anyone else using Unraid LUKS with only a password even know that this keyfile exists and that we need to delete it? And as I said previously, since the password is written in plaintext, it needs to be securely deleted with a tool like "shred" or "wipe". Is that what the WebGUI is doing? I don't know, but I am skeptical based on LimeTech's nonchalant security practices that I've already uncovered here. And frankly, no one should have to worry about any of this because our passwords should NOT be written in plaintext to a file. And I don't care if it only "lives in RAM". It's not like it only exists in the decrypting app's internal memory--hopefully obscured and requiring complex tools and skill to obtain. Instead, that RAM is setup as a file system, and anytime the server is running, the clear text password is accessible with the basic tools built into the operating system. No special skills or tools needed. LUKS does not require its password stored in plaintext in the file system. This is clearly a sloppy LUKS implementation by LimeTech that is compromising the security of their users. Why store the password at all? Apparently it's not needed after boot, so why isn't LimeTech deleting it by default? And if they're going to store it, why store it in plaintext? Whoever implemented this at LimeTech has no understanding of basic security and consequently LimeTech is putting all of their LUKS users' encrypted data at risk. Unacceptable.
-
My question still stands: WHY IS UNRAID STORING MY SECRET PASSWORD IN PLAIN TEXT? If I am not using a keyfile, then why do I have to delete a keyfile every time I start the array? So now I not only have to enter the password, I have to remember to delete the keyfile as well even though I don't use one? And I should add that it needs to be securely deleted by overwriting with random/cryptographic data to prevent data leakage. And how many other Unraid users have their key exposed and don't know about it because they never poked around? LUKS is very secure, but Unraid effectively makes it completely insecure by publishing the password. In fact, I dare to say it's even worse than no security because it gives users a false sense of security, thinking their data is protected and lets them relax on other security measures when in fact their password is actually published in clear text. It's not a hash. It's not salted. It's the password stored in a plain text file with the blatant name "/root/keyfile". It's the equivalent of a password written on a Post-It note and stuck on your monitor. How is this not a big deal to people? This is a HUGE security flaw that basically negates LUKS entirely.
-
That's entirely different. I do NOT "autostart" my array with a keyfile. As I said, I use ONLY A PASSWORD, not a keyfile. I specifically enter my LUKS password after each boot. That password should be secret. Unfortunately, Unraid then stores that secret password in plaintext on the system.
-
I understand /root is in RAM, but it is still setup as a file system and is accessible via simple built-in commands. Even someone who has never used Linux before can obtain the LUKS password in 2 seconds with a simple "cat /root/keyfile" and BAM! LUKS password displayed and entire array encryption compromised.
-
BennTech started following LUKS password stored in plaintext at /root/keyfile
-
I just came across the file /root/keyfile that stores my LUKS drive encryption password in plaintext. Why??!? I am not using a keyfile; I am using a password only. I thought that password was secure only to find it written out in plaintext on my server. This is a huge security hole. I tried deleting the file, but it is recreated on each startup. Why would Unraid store the LUKS password in a plaintext file? Why store it all? Why not just keep it exclusively in memory? Most importantly, HOW DO I PREVENT /root/keyfile FROM BEING CREATED AT EACH STARTUP?
-
Do you have exporting to custom location working? if so, would you post the scripts you made? I can't have filenames exported to the unencrypted USB drive because the actual filenames might include sensitive information.
-
This is getting a bit off-topic for Unassigned Devices, but here's what I've discovered. My motherboard has 2 built-in Realtek 8111C LAN controllers. I have these setup as a bond (802.3ad link aggregate), and I have bridging enabled. I had set my "Desired MTU" in Unraid as 9000. However, the Realteks only support 6128 max (as evidenced by bonienl's find in the logs). In 6.5.3, Unraid drops the invalid 9000 and sets the Realteks, bond, and bridge to the standard 1500. In 6.6.x, Unraid sets the Realteks and bond to 1500, but sets the bridge to 9000. If I set the Desired MTU to 6128, the Realteks, bond, and bridge are all set to 6128 and everything works in both 6.5.3 and 6.6.x. So the problem is that if the Desired MTU is too large for the hardware, 6.6.x sets the bridge to that MTU regardless. Seems a Lime Tech fix for that is needed. Maybe also add a warning if the Desired MTU greater than the known hardware limit.
-
Finally something useful! THANK YOU, boneinl! Disabling jumbo frames and reverting to 1500 MTU fixed it! I might go back and bump up to 6000 (everything else on my network supports at least that). I might even revert back to 6.5.3 to see what the MTU is there. Perhaps an updated driver lowered the max. But for now it works. Thank you! Thank you! Thank you! I didn't know should have been keeping records to prove other people had issues back when I spent days researching this back in October, but a quick search pulls up: "WonkoTheSane" posted in this thread starting on October 1, 2018 with the same NFS timeouts between TWO UNRAID SERVERS. "manofcolumbia" posted in this thread starting on December 13, 2018 with the same SMB and NFS timeout issues. "Oppaunke" posted in the Duplicati thread on October 27, 2018 with the exact same issue I have: Duplicati locks up during backup. "jj_uk" posted in the Duplicati thread shortly thereafter about the same lockups writing to SMB via Unassigned Devices. And there's me. By the way, it's not just SMB, it's NFS as well, as WonkoTheSane, manofcolumbia, and I have all documented. You deleted that part of your post, but I still have a copy. That is a crappy attitude to have toward Unraid customers, particularly a knowledgeable user who is willing to spend his time to help troubleshoot your product. Again, huge thanks to bonienl!!! Reducing network MTU size solved the problem!
-
I should add that I've been a computer programmer since the 1980s. I currently run my own IT company. I haven't done much Linux programming, but I am familiar with the OS. I am well-versed in client/server and networking protocols. My network switch is a smart switch. I can run Wireshark if we need. I'm ready to go. You want to troubleshoot? Limited time offer, though. I can't afford to skip backups forever. (You can message me privately if you want to avoid clogging this thread with troubleshooting this one issue.)
-
My servers are NOT going offline. That is EXACTLY the finger pointing that I described back in December in this thread where you responded saying you haven't seen any finger pointing. Let me make this clear: MY SERVERS ARE NOT OFFLINE. I HAVE NO NETWORK ISSUES. My backups with the Duplicati docker have been rock solid since I started them a year ago. Back in October I upgraded to 6.6.x (tested 6.6.0 through 6.6.3) with no changes to my NAS devices or network. Unraid 6.6.x FAILS EVERY TIME with a timeout. Every backup failed for an entire month while I researched and troubleshot and found numerous people reporting this same issue and no one believing them--i.e., no Unraid or Unassigned Devices fix because "it's a server issue". I revert back to 6.5.3, and everything works again. No changes to NAS or network. Rock solid for the past 6 months on 6.5.3. Yesterday I upgrade to 6.6.7. No changes to NAS or network. Unraid immediately fails again with timeouts. I think I have a solid case for proving it is Unraid 6.6.x and NOT MY SERVERS. I have some time now to help you (and Lime Tech) troubleshoot Unraid 6.6.x. Do you want to troubleshoot or point fingers at my servers exactly like I said you and Lime Tech have been doing? Unfortunately, YOU dlandon are going to have to convince Lime Tech that it's actually Unraid causing the problem because when people like me bring this up, Lime Tech points the finger at your third-party plugin. In reality, Lime Tech has utterly failed by creating a Linux server that cannot access other servers without third-party plugins like yours. So thank you, dlandon, for stepping up and filling in this GLARING DEFICIENCY IN UNRAID. (Are you listening Lime Tech? If dlandon isn't on your payroll, he should be for all the value he has added to Unraid.)
-
I finally have some downtime where I'm not in need of regular backups can work with you to troubleshoot this. Previously, I have been running 6.5.3 using a Duplicati docker to backup my Unraid files to old Netgear ReadyNAS NV and NV+ mounted with Unassigned Devices using SMB. When I upgraded to 6.6.x, my NAS devices would drop from Unassigned Devices when my Duplicati backups ran. Logs show the mounts timed out and Unassigned Devices would show them mounted with a 0/0 byte count. I switched the shares to NFS. Same issue. I tried multiple versions of Unraid (6.6.0, 6.6.1, 6.6.2, 6.6.3, and now 6.6.7), all the same issue. Multiple versions of Unassigned devices. Same issue. Yes, they are mounted as RW/Slave in docker. My Duplicati docker is the only thing on Unraid that accesses these drives, so to troubleshoot further. I did a clean boot, opened a terminal, and copied files directly to/from the NAS using cp. I copied several hundred MB from the NAS to Unraid successfully. However, copying the files back to the NAS, it failed. Out of the dozen files, only one file was created, but it was 0 bytes when it should have been 50 MB. And again, same issue as above: timeouts in diagnostics and Unassigned Devices shows that NAS mounted with 0/0 byte count. Thus, this isn't just isolated to Duplicati or dockers, but also occurs in Unraid itself. Attached are diagnostics. The first three show Unassigned Devices during my Duplicati backups. The last one is using a terminal and cp to copy files directly. moria-diagnostics-20190401-1815.zip moria-diagnostics-20190401-1950.zip moria-diagnostics-20190402-0108.zip moria-diagnostics-20190402-0129.zip
-
This is a problem with Unraid 6.6.x. I spent a lot of time researching this, and Lime Tech tells you it's a third-party plugin and to contact Unassigned Devices. Unassigned Devices tells you that your remote server is offline or you have network issues. That's not the problem. Unfortunately, I don't know what the actual problem because everyone points fingers somewhere else. The fact is that numerous people have issues with drives dropping from Unassigned Devices when using Unraid 6.6.x. Affects both SMB and NFS. Mapped drives suddenly drop during moderate or high usage. The only solution is to revert back to Unraid 6.5.3. Everything works fine until you upgrade to 6.6.x, so clearly it is NOT an offline server or network problem but directly related to 6.6.x. I have researched Slackware and Linux support for similar issues but haven't found a solution. I suspect our problem has something to do with old protocols (my remotes are old ReadyNAS that only support SMB 1.0/2.0...not sure about NFS but likely v3 or possibly 4 or 4.1) and some upgraded component in the base distro of Unraid 6.6.x that Unassigned Devices requires. Before I say this next part, let me first say that I love Unraid. Its capabilities are amazing: unique (not) RAID parity solution, Dockers, virtual machines, LUKS, huge community support. And huge thanks to dlandon for providing and supporting this plugin for free. HOWEVER, I think it is pathetic that Lime Tech has to rely on third parties just to map a remote network drive. This should be built-in (as it has been on a every major operating system since the 1990s, including Linux and Slackware that Unraid is based on), so we can avoid the finger-pointing that we're encountering here and get actual support from Lime Tech to fix this issue. Until then, the only solution is to revert back to Unraid 6.5.3 and be envious of everyone who is able to upgrade, use new features, patch security holes, etc.