Invalid forward pointer in DHCP Domain Search option compression.

[Russell Haley]

Hello TrueNas community and ixSystems! I'm a long time PC-BSD/TrueOS/FreeBSD user. I'm happy to be back on an ixSystems message board!

I literally found an old supermicro server sitting in a closet and I am trying to get it up and running with TrueNAS.

Code:

sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
hw.machine: amd64
hw.model: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz
hw.ncpu: 24
hw.machine_arch: amd64
#(2 x 6 core, hyper threaded)

sysctl hw.physmem
hw.phymem: 137355259904
#(128GB)

uname -a
FreeBSD truenas.local 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 df578562304(HEAD)
TRUENAS amd64

For the most part, I have TrueNAS running and connected to the network at my employer (Windows boxes, Cisco switches). However, I am seeing errors in the root console.

Code:

Jun 8 11:15:48 truenas 1 2021-06-08T11:15:48.028520-07:00 trunas.local dhclient 2213 - - Invalid forward pointer in DHCP Domain Search option compression

This message repeats ad-nasium.

I've found some threads that point to the WRECK vulnerability in CVE 2020-7461:

https://www.freebsd.org/security/advisories/FreeBSD-SA-20:26.dhclient.asc

Which seems to point to something "bad" causing these errors? Or perhaps it's misconfiguration? Not sure. What I was hoping is that someone could comment on what is causing these messages OR if someone could point me to a tool that would allow me to capture the messages? Do I just use tcpdump (any clues would be helpful)?

Thanks!
Russ

 

[jgreco]

It's more likely that there's some garbagey response coming from the network's DHCP server.

A NAS generally shouldn't be assigned an address via DHCP anyways, since loss of a lease or reassignment causes network mayhem, so the easiest fix might be to assign it a static IP address.

 

[Russell Haley]

Thanks for answering @jgreco. The DHCP is just a temporary situation while the IT department sets up a subnet for my development environment. It would be nice to discern the cause of the issue though? I was/am mostly worried that something nasty might be on our network.

 

[jgreco]

Well, what you can do is find out what sort of DHCP server is being used.

There's basically two things that could be wrong here.

One is the server.

The other is the client.

Both clients and servers have ben trending towards better input and data validation as time goes on, so my guess is that there's an older DHCP server on the network that is putting out something that isn't quite standards compliant. But it could also be that the client is being excessively picky.

You can breathe easy, it is highly unlikely that something nasty is on your network. There are far, far easier ways to subvert a network, much more quickly and efficiently, than throwing garbage DHCP responses and trying to do ....????something????.... because by the point where you can inject such responses, you already have very deep access to the network.

 

[Russell Haley]

Well, what you can do is find out what sort of DHCP server is being used.

There's basically two things that could be wrong here.

One is the server.

The other is the client.

Both clients and servers have ben trending towards better input and data validation as time goes on, so my guess is that there's an older DHCP server on the network that is putting out something that isn't quite standards compliant. But it could also be that the client is being excessively picky.

You can breathe easy, it is highly unlikely that something nasty is on your network. There are far, far easier ways to subvert a network, much more quickly and efficiently, than throwing garbage DHCP responses and trying to do ....????something????.... because by the point where you can inject such responses, you already have very deep access to the network.

lolz. Good point. I'll go grab a paper bag and stop hyperventilating.

Thanks!