bitcore

Nice work @sticklyman! Thanks for the help @itimpi ! Glad to hear that it seems to stop the exploit POC! @sticklyman, Would a community applications plugin be easy to build/deploy with your binaries to make this as easy as a few clicks for the entire unraid userbase? I've not made one of these before so I'm unsure if it's even possible to distribute binaries as part of a plugin...

Apparently you can set the following at boot and it disables the chicken bit (edit) without microcode update: wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9))) Reference: https://news.ycombinator.com/item?id=36852699 Reference that it works better than a microcode update for one person's hardware combo: https://news.ycombinator.com/item?id=36854488 I've not tested it myself yet but apparently it's rather well supported across the linux ecosystem. I'm not sure of the best way to implement this automatically at boot in Unraid... perhaps someone else can chime in and add a recommended method? I'm running threadripper and a lot of VMs, so this is a particularly desirable fix that I want to be reliable.

I agree, a link to the discussion forum in the little release notes provided in the webGUI (the "i" button) would be very helpful and courteous to users. Additionally, I'd love to have more than just the changelog in there. The same text blurbs that are posted in the forum post for the release notes would also be helpful. I'm personally pretty diligent about reading the upgrade threads from top to bottom, and I'll admit that though it's great we have organized release threads, it's a little annoying to have to search for the thread to be sure I don't run into any show-stoppers. A link would really be lovely. Anyway, thanks for the release! Edit: Also, my upgrade from 6.10.1 to 6.10.2 went just fine.

Just an FYI, the 8 character password limitation in VNC is actually a protocol limitation with VNC. Most implementations of VNC are inherently insecure. You'll find that your VNC password is also effectively transmitted in clear text. It's more common to encapsulate (tunnel) VNC through SSH, but in this application it's not practical. KVM/QEMU/LibVirt is actually the VNC host. Other "more secure" VNC applications (such as RealVNC) break protocol spec to implement their security and additional features. Most other common flavors of VNC (Tiger, Tight, NoVNC, Turbo,Ultra) all pretty much adhere to spec, and thusly are also insecure (outside of encryption plugins). We must rely upon what KVM/QEMU/LibVirt support. If security is a concern, I recommend disabling the VNC VM console across your VMs altogether until UNRAID makes it easy to operate with x.590/TLS that libvirt also supports. See: https://wiki.libvirt.org/page/VNCTLSSetup A step in the right direction, but cumbersome to use.

I have similar issues with SHFS CPU utilization very high. Have you found any solutions?

Great. How do I manually reset the counter via SSH. How do I increase the failed attempt count to something reasonable like 10 attempts within 15 minutes? IMO, a limit of 3 is asinine.

I confirm that this also works on my system. 6.9.2 Thank you booman! This effectively downgraded my ncurses package from 6.2 to 5.9. +============================================================================== | Upgrading ncurses-6.2_20201024-x86_64-1 package using ./ncurses-5.9-x86_64-4.txz +============================================================================== Hopefully nothing else breaks...

Same issue here. Also tried uninstalling and reinstalling - no difference. I also uninstalled python 2.7.11 and then reinstalling iotop. Same errors. Edit: I ran across this thread: https://github.com/dmacias72/unRAID-NerdPack/issues/59 which seems to indicate both an ncurses incompatibility, and that the iotop app is massively out of date anyway.

+1. Virtualizing a firewall makes using unraid as the bare metal OS for an all-in-one server a problem. Consider: I have an encrypted array. If I have an extended power failure and UPS goes flat, I can't get back into the array without physically being present to enter the key and start it up again. I don't want to have to virtualize unraid itself to achieve this.

I'm very excited to see a larger push for security. Thank you. Security is very important to me, and I applaud the efforts! I'm very pleased to see this! However, is there a way to adjust the GUI's failed login lock threshold, or cool-down timer? I personally believe that a max of 3 attempts is... extremely aggressive, such that it's counter-productive. This leaves very little room to allow humans to be humans; fallible, and prone to mistakes. These values are simply a punishment and unfriendly to those cursed with fat fingers, rather the serving as an effective protection measure. This is especially true with long and complex passwords. It would be brilliant to provide us a drop-down to let us adjust these values ourselves, or at least share the config value names in the config files, if they exist. Please allow me to articulate an argument to change these default values away from 3 and 15 minutes. Yes, a tight value like this is technically more secure, but doing so renders the extra layer of protection impractical. It's not sensible or realistic. I would suggest a default value of at least 5 attempts, better 10. Actually, you could flip these values: 15 attempts, 3 minute cool-down, and this would still be incredibly effective at protecting a moderately complex password, yet still minimizing the friction of getting an authorized user logged in. That would result in only 300 password attempts per hour. You are not cracking an 8 character password at that rate within a single year. An attacker would be better served profiling and exploiting a vulnerability. Honestly, a 15 minute cooldown after 3 type-os is a "go sit in the corner time-out, and wear this dunce cap" punishment. These are not sensible values for a home NAS. I suggest taking the minimum password length allowed, calculating the worst case keyspace (user chooses a dumb password with minimal complexity), and work from there to establish an acceptable "attempts per minute" to prevent brute forcing.

This issue appeared again today. I have a PFSense VM handling internet+NAT+etc with a quad port nic passed through to the VM. This does not go down and internet stays stable. However, the NIC that all other unraid services operate on (webGUI, shares, other VMs, etc), seemed to suddenly stop working with no other entries in dmesg that I can see. This time, bouncing the physical port (disconnect, reconnect) did not help. Neither did rebooting my Netgear switch (it's firmware is also fully up to date). This is the 10Gig Aquantia AQC107 NIC. I hope I can get to the bottom of this so I don't have to waste a PCI-E slot on another NIC. Hopefully the upcoming 6.9 release will include better driver support and resolve this - this is a fairly new platform.

I have the same symptoms. Asrock TRX40 Creator, AMD Threadripper 3960X, 128GB of unbuffered ECC Samsung M391A4G43MB1-CTD. All network accessibility on the server seems to suddenly severely degrade and/or eventually fail completely: No SSH, no SMB, and no ping responses. Console seems responsive, but last time this occurred it became non-responsive and I had to hard-power down. Link stays up at 1Gbit to my existing switch. I have the same/similar log entries with the interfaces - which seem to correlate when VMs are powered on/off (and it's the bond0 interface, so likely unrelated, just like @JorgeB said) Jan 1 16:51:28 server kernel: br0: port 1(bond0) entered blocking state Jan 1 16:51:28 server kernel: br0: port 1(bond0) entered forwarding state However: Physically bouncing the NIC by unplugging and re-plugging the ethernet cable into my switch seemed to immediately resolve the issue. Either the NIC driver is faulty (it's a 10GBE PHY from Aquantia), or the Netgear managed switch I have is faulty and causing me grief. I suspect it's my existing network switch, which is also not suitable for my application. I may be chasing two issues here, but I believe the previous issue was due to overclocking that RAM to 3200 (as many have been known to do successfully, and I've burned in for about 2 weeks of heavy memory load during initial build testing) I backed that off and I haven't had a hard-lock since.

This got me. Thanks!!!!

Update: I resolve this issue for me. Rebuilding the VM from scratch and switching to the Q45 chipset seemed to resolve my issue. I'm also now able to use the same VM as a base image to clone multiple other VM's from. (I have to make a new vm give it a name, save it, copy the XML from my template VM, paste it into the XML for my new VM, correc the <name></name> tag to MATCH the new VM's name and not the template! Remove the contents of <uuid></uuid> to generate a new VM in libvirt, edit the disk location in <devices><disk><source file="">, and of course change the mac address. Apparently Q45 chipset is PCI-E native, whereas the i440fx is a much older generation that is PCI-first. So for new OS's: use Q45, for old OS's: use i440fx. I do wish that the GUI Help/Tips context menu didn't direct users to try and get a VM working on i440 first, since it's so old and likely not very true these days.

Hi Majorpaynedof, did you find a solution to this question? I'm interested in this as well.

I'm seeing this same Phenomenon. Unraid 6.8.3. Threadripper 3960x on an ASRock TRX40 Creator. Fresh W10 20H2 install, fully updated. No PCI-E pass through, no extra shares added to the guest. VirtIO ISO version 1.185 i440fx-4.2, OVMF, Hyper-V: Yes (What does that ACTUALLY do, extend hyper-V functions to the guest?), USB 2.0 EHCI, VirtIO disk. It's effectively a default configuration as far as I'm aware. It seems to randomly freeze it's GUI after being idle. Same symptoms as OP, noVNC locks up and remote desktop fails, but some OS network-based functions remain available (EG, it responds to Ping). Win 10 Guest stuff: Turn off display after: never Advanced power settings: Turn off hard disk: 0 minutes No options for sleep, but allow wake timers is set to: enable USB Settings: USB Selective Suspend Setting: Enabled. I'm trying this set to disabled now, if this resolves it I'll try to remember to post back (if I forget, please remind me and I'll do so.)

Upgraded from 6.6.6. It took me a while to want to move away from the number of the beast.... Alas, security et. al. Seems to be OK. VM boots fine. webgui feels faster/snappier. Running on very old hardware (circa 2008): Gigabyte EP45-UD3P, core 2 quad Q9550, 8GB, Arecca ARC-1880IX-12

Since 6.8.1, the linux kernel included supposedly included the fix for threadripper 3 where the MCE=off boot option was no longer required. Can anyone confirm that this is indeed the case? Also, are you able to actually read the ECC log if you have ECC memory? https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.4-4.19-4.14-MCE-Fix-TR Thanks!

Hi dlandon, Thanks again for your reply. Yes, I tend to be more paranoid than most, still, I prefer to run minimal configurations where possible. I appreciate your responses, and the time and energy you have put forth into maintaining the plugin. Genuinely: Thank you.

Hello dlandon, I understand, thanks for your reply and comments. Is it possible to "echo" a comment during the install of the plugin, so that users who see the nmap and are alarmed, as I was, are presented with a way to remove without having to search? Cheers.

Hello, Thank you for maintaining this plugin - it's very useful and seems to work rather well. Very much appreciated. I understand Nmap was added as a requirement so that a "scan for NFS shares" button would be available. When I saw nmap show up during an upgrade - fears of compromise IMMEDIATELY set in. I believed that this plugin's repository was compromised and nefarious actors wished to scan users' networks swiftly and with ease - perhaps to install a RAT or compromise other devices within personal networks behind firewalls. This was extremely disconcerting to see! From what I understand, this is a drive mapping/mounting utility - not a network scanning and discovery tool. I personally disagree with the choice of installing a hand-picked nmap version by default. It's understandable to want to provide the convenience to 'scan' for NFS shares, however by nature of the way NFS access is granted by IP restrictions (exclusive of more elaborate systems such as kerberos), it would follow that users must know the IP addresses, or at least hostnames, of both the server and the clients anyway, and won't need this feature to begin with. Installing a network mapping binary by default for a drive mapping utility seems very excessive to me. May I suggest removing this, making it an optional extra (the button shows up if nmap was discovered), or foregoing any network scanning feature altogether? For those of you that wish to continue to use this plugin, but would rather not have nmap installed - you can run the following to uninstall the package. The plugin appears to function just fine without nmap. (Again, thank you dlandon for providing this procedure in 2016) cd /var/log/packages removepkg nmap-* Unfortunately, until the current maintainer of the project also agrees to remove the package requirement, it appears you must manually perform this step every time you update the plugin. Cheers

Hello, I had this same issue with an ARC-1880. I just flashed the latest firmware to it, seems to have fixed it. It was exhibiting the same behavior described above, for me with some WDC drives that are same make/model. When the card is in RAID mode and you are presenting some passhrough disks for UNRAID to manage, by default they will be assigned different SCSI LUNs by on the same SCSI_ID. The trick appeared to be to assign separate SCSI_ID's. Unfortunately on this card, you are limited to a certain number of passthrough disks in RAID mode. I was also encountering this problem in JBOD mode but there's no way to assign SCSI ID's in this mode. I've put my card back into JBOD mode after the firmware update, and everything seems to be behaving itself now. UNRAID now sees the disk serial number postfixed to the drive ID. I updated to 1.55. I believe I was at 1.47 Hopefully this helps someone.

Thanks for the plugin, very useful and convenient! The atop package seems to be filling up my /var/log partition in the atop directory with compressed binary data. Anyway to configure this differently to not fill it up?

Upgrade went smoothly for me from 6.6.5 on 10 year old hardware. (Q9450 + EP45-UD3P)

Hi Johnnie.Black, Thanks for your reassurance. That GUI behavior/language is a little strange to me, "Enter new key" can easily be interpreted to mean "Your un-decrypted array is about to be encrypted with a new key and your data will then be garbage because I think this is a new array that is at the initial encryption stage"