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.