SOLVED NAME:WRECK - are we at risk?

[nickt]

I haven't been able to find any posts on this, so I'll ask the question - is TrueNAS vulnerable to the so called NAME:WRECK vulnerabilities impacting the TCP/IP stack in FreeBSD? This article suggests that FreeBSD has patched the vulnerabilities upstream, but I can't see anything to say that these have made it into a current release of TrueNAS. Have the patches been applied or are we at risk?

 

[Patrick M. Hausen]

No, we are not.

The bug was fixed in FreeBSD 12.1 in September 2020. TrueNAS CORE is FreeBSD 12.2.

 

[ornias]

The bug was fixed in FreeBSD 12.1 in September 2020. TrueNAS CORE is FreeBSD 12.2.

Though we should imho send out a clear message that users should stop using 11.3.

 

[nickt]

Awesome. Thanks. Good idea about 11.3.

 

[jgreco]

I haven't been able to find any posts on this, so I'll ask the question - is TrueNAS vulnerable to the so called NAME:WRECK vulnerabilities impacting the TCP/IP stack in FreeBSD? This article suggests that FreeBSD has patched the vulnerabilities upstream, but I can't see anything to say that these have made it into a current release of TrueNAS. Have the patches been applied or are we at risk?

As far as I can tell, these people cannot tell the difference between a TCP/IP stack (which would be the protocol stuff in the kernel, from the syscalls to the physical ethernet port) and stuff that runs on top of it, such as DNS and DHCP. It feels very much like opportunistic fearmongering. Plus it is teaching bad terminology to people. TCP/IP stacks are difficult to fix because they reside in the kernel, and a kernel update and reboot is needed to fix them. Things like DHCP or DNS services live in userspace and can potentially be hotpatched without a reboot. This can be a great thing to be confused about for a company trying to make a name for itself in the security world. "I am not impressed."

The problem appears to be that the DHCP client on FreeBSD is susceptible to a malformed response attack involving option 119 data.

Turn off the DHCP client on your FreeNAS/TrueNAS box and you're fine. You shouldn't be running DHCP to get addresses infrastructure devices. You are 100% unaffected by this unless you are using DHCP to configure your FreeNAS. Additionally, it appears that an attacker would need to already have penetrated your network, taking over some other host on the network at a privileged level, in order to be able to intercept a DHCP request and formulate an attack response, so you already have much more significant issues by the time this attack can be exploited in practice.

 

[ornias]

Turn off the DHCP client on your FreeNAS/TrueNAS box and you're fine. You shouldn't be running DHCP to get addresses infrastructure devices. You are 100% unaffected by this unless you are using DHCP to configure your FreeNAS.

Which is the default, so I still expect a formal security advisory.

 

[jgreco]

Which is the default, so I still expect a formal security advisory.

Posting that here is meaningless and doesn't contribute value to the thread.

 

[ornias]

Posting that here is meaningless and doesn't contribute value to the thread.

In my opinion it does (well not of the advisory is posted here ofcoarse):

The questions was "are we at risk".
With such a high publicity CVE, it shouldn't be needed to ask this on the forum at all.
Primarily considering some versions with stock settings are, in fact, at risk.

While I consider most enterprise users also have additional IT partners that are already aware and mittigating the issue, there are still a lot of users for which a clear security advisory is relevant.

And yes: saying my opinion on a forum doesn't change shit and is thus meaningless. However: that goes for about 99% of threads on 99% of forums.

 

[jgreco]

In my opinion it does

Your opinion is silly. Anyone who has access to the network a FreeNAS system is on already has many other more plausible attack routes into the system; we've always counseled that FreeNAS is only to be used on secure networks because the attack surface for a NAS is *massive*.

 

[ornias]

Anyone who has access to the network a FreeNAS system is on already has many other more plausible attack routes into the system;

Yes and that does not make it irrelevant for manufacturers to give out security advisories for this grade of CVE.

we've always counseled that

So manufacturers are excused from duedilligence when it comes to security advisories because some consultants are duedilligent?! Sorry, but if you want to talk about silly opinions, thats one right there.

 

[ornias]

But I don't think we're ever going to agree on this @jgreco, so lets agree to disagree on this one shall we ;-)

 

[jgreco]

It appears that you're trolling, and not contributing anything meaningful to the conversation. At the point where this would be a problem, an attacker would already have gained layer 2 access to your network, so you're screwed regardless. The attacker could simply sit there and ARPocalypse the device into any one of various modes.

 

[nickt]

I really appreciate your input @jgreco.

I consider myself reasonably competent at administering my FreeNAS / TrueNAS box, complete with VMs hosting docker containers with various services I like to use. I'm careful to choose containers from reputable sources and carefully follow security guidelines that I can find to minimise attack surface area. I do the odd bit of python scripting for various hobby projects.

But translating high profile security disclosures into "what does it mean to me" is a whole other level of technical that I am well aware is beyond my capability. I'm also aware that small companies like to make a name for themselves, which makes it all the harder to sift the truly relevant disclosures from the attention grabbing.

So your translation of this situation is enormously helpful. As you say, my setup uses a static IP address, no DHCP client running, so I'm good. But there's no way I could have figured that out for myself from the disclosure. So thanks.

 

[Seren]

Since it seems that this thread is as close to a security advisory as we’re going to get, I’ll add that the CVE in question is CVE-2020-7461. Hopefully that helps anyone searching the forums for information about it.

 

[gary_1]

Really it shouldn't matter what other modes of attack exist against a device, if there's a valid _new_ way to attack a FreeNAS box on a network without physical access that can possibly lead to code execution, people should be made aware of it, especially if there's a mitigation such as disabling dhcp.

It would have been useful for an announcement to clarify that FreeNAS 12 is not vulnerable, that FreeNAS 11 (and earlier I presume?) is but that the vector can be mitigated by not using DHCP (or upgrading).

For comparison, with Debian there's a security mailing list. Notifications are released for any CVE that impacts any of their releases (including packages they distribute) with information for example https://lists.debian.org/debian-security-announce/2021/msg00005.html which is useful to determine whether any given vulnerability is relevant to your specific setup.

 

[gary_1]

It appears that you're trolling, and not contributing anything meaningful to the conversation. At the point where this would be a problem, an attacker would already have gained layer 2 access to your network, so you're screwed regardless. The attacker could simply sit there and ARPocalypse the device into any one of various modes.

Can you elaborate on this? Are you suggesting a fully patched FreeNAS machine for example running only SSH (serving files over SFTP) is already vulnerable to remote code execution from the LAN? If so, can you point me to information on this? I'm assuming that's what you're meaning by any "mode", given, code execution is the possible threat from the above CVE. If that is not what you meant, can you clarify?

Edit: Reworded for clarity.

 

[jgreco]

Can you elaborate on this? Are you saying a fully patched FreeNAS machine with only SSH running (serving files over SFTP) has unfixed remote code vulnerabilities that can be exploited from the same LAN?

Sure, if you want to put words I didn't actually say into my mouth.

If you want to listen to what I actually said, though, anyone with layer 2 access to an Ethernet is able to screw up a network pretty badly, including confusing other hosts who are trying to communicate with the NAS into sending to an alternative MAC address, an attack which has significant potential to gain access to data that one shouldn't have the ability to access, or tricking the NAS in a similar manner. This has the potential for all sorts of issues, and is basically a design flaw in IPv4.

https://en.wikipedia.org/wiki/ARP_spoofing

This turns out to be a real problem in environments where multiple tenants have shared access to an L2 broadcast domain, so devices such as cable modems, hypervisors, etc., typically have the ability to selectively disable "forged transmits" and "promiscuous mode", which are two elements involved in the security considerations of IPv4 networking.

Relatively speaking, this allows for an immense amount of inadvertent data exposure, especially since NAS protocols are typically unencrypted, your weird example of SFTP notwithstanding.

If so, can you point me to information on this? I'm assuming that's what you're meaning by any "mode", given, code execution is a possible threat from the above CVE. If that is not what you meant, can you clarify?

As a security person, the question you have to ask yourself is "what is the attack surface like"?

You mentioned SFTP running over SSH because SSH is generally not terrible from a security perspective. It hasn't had a lot of remote code exploits over the years, but that number isn't zero. One of the big things for experienced security people is not to put all your eggs in one basket; being overly concerned about "code execution" without also designing a system that is designed to minimize the danger of code execution is stupid. Our Internet-facing SSH gateways here run in a /bin/sh-less jailed read-only environment, and are firewalled so that the bastion hosts they run on can only reach inward to specific hosts. I do not live in terror of a code execution exploit for our SSH gateways, because at most you'd only get in to the bastion host, which isn't a big deal. The attack footprint is minimal, specific, and carefully monitored.

By way of comparison, FreeNAS is listening on a crapton of ports, running a huge amount of diverse software, has no onboard firewall, and has middleware written by developers who have explicitly stated in the past that they do not expect FreeNAS to be exposed directly to the Internet, and have cautioned against it. Try it, "netstat -an" is your friend.

From this, the smart advice is not to place a FreeNAS host on a shared tenancy network segment, whether just "raw Internet" or a cloud host or whatever. You don't know if the platform itself is truly secure, you know for sure that the network itself isn't secure, so the smart move is to make sure that only systems you control can access the NAS directly.

Additionally, given the role that a NAS plays in many organizations, reboots for random security patches may not be practical. A classic example is use of a NAS for iSCSI or NFS VM datastores, where an outage is unacceptable, and any planned update may require a days-long evacuation of the datastore to a standby unit. This is hardly unique to FreeNAS.

Anyways, considering what you should be using as a security model, the DHCP thing is really a minor issue in the larger picture, because FreeNAS shouldn't be deployed in a manner that would make this exploitable.

Having said that, let's circle around to those words you were trying to shove in my mouth. Here they are, in stronger form.

I damn well guarantee you that there are multiple unfixed remote code execution vulnerabilities in FreeNAS/TrueNAS. If you're wondering what they are, by all means, go look for them. Nobody's found them yet, but just like every other large scale modern software package, THEY EXIST.

You either plan for that eventuality, or you don't. Don't put all your eggs in the "fully patched" basket. Being fully patched is good. Planning for what happens when that isn't enough is better.

 

[gary_1]

It wasn't putting words into your mouth, it was a genuine question because I'm aware of ARP spoofing, however, my point was, the dhcp vulnerability potentially allows remote code execution from the LAN. I'm not aware of ARP spoofing being able to do that, though it can lead to other nasty scenarios, it is however not a given that you can use it to gain code execution alone. I assumed by the way you brought up ARP spoofing and "mode" that you had knowledge of an exploit specific to FreeNAS that allows code execution in some way via spoofing, hence my question.

Thus deciding that an announcement isn't required because ARP spoofing exists isn't imo a sound strategy. There may be people using freenas in LAN situations where protecting their data is important, but where the risks from ARP spoofing are manageable. People however need to be aware of vulnerabilities, especially unfixed ones, in order to determine what risk it may or may not pose to their particular circumstances.

Take my setup for example. I use FreeNAS as a SFTP server. My LAN sits behind a firewall as I expect most do that does not allow incoming connections. In addition FreeNAS sits behind a firewall that limits SFTP access to certain machines on the LAN and blocks all other incoming ports. As it happens I don't use DHCP for infrastructure, however, if I did, I would have appreciated a heads up on this issue so I could mitigate it. Other than DHCP, what known (potential) remote code execution vulnerabilities exist? I'm not aware of any issues with SSH at this time.

I'm not sure why my example is weird either. I take a defense in depth approach and ensure all network traffic is encrypted. SFTP is a simple way to achieve file sharing, integrates seamlessly with our Linux desktops whether it's via FUSE or a client. We assume that whilst the LAN is meant to be secure, at some stage someone's machine will at one time or another be compromised, and try to limit the chaining impact that could follow.

Is my setup normal? I don't know, I'd assume not. However, that's kinda my point, we don't know what myriad of network configurations might exist out there. What vulnerabilities might be serious to one setup and not apply to another. The best thing to do is to communicate to end users any vulnerability that could lead to remote code execution.

 

[jgreco]

Thus deciding that an announcement isn't required because ARP spoofing exists isn't imo a sound strategy.

I hope you're not laboring under some misconception that I'm an iXsystems staffer. I don't get to decide what announcements get made. I woke up one morning to find myself having been conscripted into moderatorship.

Other than DHCP, what known (potential) remote code execution vulnerabilities exist? I'm not aware of any issues with SSH at this time.

I don't know. Ask the Russians, the Iranians, the Chinese, or basically any state large enough to sponsor an organization of professionals who are actively looking to do these things. That list, I'm fairly confident, also includes the United States and allies as well, all of whom are either known or suspected of analyzing and stockpiling exploits.

The point is, design your stuff with the assumption that it will happen at some point.

I'm on the other side of this, needing to defend resources against attacks. I've been doing this a very long time, by the way.

 

[gary_1]

I hope you're not laboring under some misconception that I'm an iXsystems staffer. I don't get to decide what announcements get made. I woke up one morning to find myself having been conscripted into moderatorship.

I'm not no. I just find it strange you don't think they should make such an announcement?

This is not like a vulnerability that requires physical access to the machine, where you can generally take the "all bets are already off" approach. It's also perhaps not as serious as a true remote based vulnerability given it needs LAN access. However, I don't see that as enough of a reason to not want some announcement to customers to either upgrade to version 12 or ensure they're not using DHCP.