smb signing vulnerability TrueNAS SCALE 22.12.2

[paulpop]

Currently, we have the version TrueNAS SCALE 22.12.2, we have tested each of the directives "server signing = required, server smb encrypt = required, smb encrypt = required, client ipc max protocol = SMB2," individually and in combination, but the "SMB Signing" vulnerability is not being fixed.

In the previous two versions, this directive "server signing = required" at the SMB service level does resolve the issue, but in this version, that directive and others do not generate any changes. When running "nmap --script smb2-security-mode.nse -p445 ip," the result is "Message signing enabled but not required."

 

[danb35]

Sounds like this would warrant a bug report--the link is at the top of the page.

 

[ProbablyGetRoasted]

Did you get anywhere with this @paulpop? I am having the same issue. We use TrueNas Scale-22.12.3.3 and still no luck.

 

[anodos]

That was a bug in Samba that was fixed in Samba 4.17.10. We're bringing in Samba 4.17.11 in 22.12.4. It was not brought in via out-of-band release because the feature impacted is only available via auxiliary parameters.

NOTE: Auxiliary parameters are a free-form text field where users can more or less paste anything, and so we make no guarantees regarding stability / behavior of any configuration using them and will typically not go out of our way to make special releases to fix bugs that can only occur while using them.

 

[ProbablyGetRoasted]

@anodos thank you, we will await the release

 

[ProbablyGetRoasted]

@anodos is there any word on when 22.12.4 will be released? or even a month ETA?

Thank you

 

[UnexpectedDevelopment]

@anodos is there any word on when 22.12.4 will be released? or even a month ETA?

Thank you

Just wait until you find out that auxiliary parameters were removed in SCALE 23! And so far, I can't see how to turn on encrypted SMB.

 

[roose101]

Hi, as i see there is no solution yet. The "Auxiliary parameters" are still missing in TrueNAS-SCALE-23.10.1.3. I tried editing /etc/smb4.conf. That works but isn't persistent - configuration gets lost after next reboot. Any idea how to get it persistent? I tried editing /usr/local/etc/smb4.conf, but that didn't work - middleware didn't start anymore.

 

[roose101]

Hi, as i see there is no solution yet. The "Auxiliary parameters" are still missing in TrueNAS-SCALE-23.10.1.3. I tried editing /etc/smb4.conf. That works but isn't persistent - configuration gets lost after next reboot. Any idea how to get it persistent? I tried editing /usr/local/etc/smb4.conf, but that didn't work - middleware didn't start anymore.

Found a solution for enabling smb transfer encryption in SCALE myself. For me it worked via command line interface within the shell:

Code:

cli
service smb update smb_options="server signing = required\nserver smb encrypt = required\ninherit owner=yes\ninherit permissions=yes"

ATTENTION: I'm no samba-expert! This may remove / override previous settings. This may not solve the vulnerability. I have no idea where these settings are stored - the smb4.conf seems unchanged.

 

[anodos]

Found a solution for enabling smb transfer encryption in SCALE myself. For me it worked via command line interface within the shell:

Code:

cli
service smb update smb_options="server signing = required\nserver smb encrypt = required\ninherit owner=yes\ninherit permissions=yes"

ATTENTION: I'm no samba-expert! This may remove / override previous settings. This may not solve the vulnerability. I have no idea where these settings are stored - the smb4.conf seems unchanged.

There's a difference between enabling encryption and forcing encryption. Encryption is by default negotiated by the SMB client. These parameter basically force encryption always. There is actually no way to disable encryption. The SMB vulnerability mentioned in the CVE was specifically about the parameter to force encryption not working. We were never really impacted by it because we don't expose that knob to end-users.

As an aside, allowing auto-negotiation for some reason started to be flagged by some vulnerability scanning tools last year, and so this configuration option may make an appearance in our UI with the caveat that it carries potential to break some SMB clients. If you're a home user, there's basically zero reason to change the defaults. If you're using in a business environment you'll need to carefully weigh pros and cons.

Inherit owner ad inherit permissions are completely unrelated to encryption and shouldn't be set without understanding the implications for the underlying SMB server.