SNMP fails to resolve domains when DNS record is longer than 64 characters

[Tanguy Pelado]

[Impact]

Currently, users who would like to query domains with a name length of 63 characters or more are unable to, and instead receive an Unknown Host error.

This fix should be backported to stable releases as net-snmp should be capable of querying all relevant domains, and this includes very long ones.

The bug is fixed by making the limited-size static string into a dynamic one.

[Test Plan]

The fix can be tested with the following:

# lxc launch images:ubuntu/jammy test-net-snmp
# lxc exec test-net-snmp bash

# apt update && apt dist-upgrade -y
# apt install snmp -y

- Attempt to connect to an existing domain containing over 63 characters:
# snmpstatus -v2c -c public aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games

- Before the fix, it will show the following
Created directory: /var/lib/snmp/cert_indexes
snmpstatus: Unknown host (aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games) (Resource temporarily unavailable)

- After the fix, it succeeds or correctly shows that snmpd is not running on the domain
Timeout: No Response from aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games

[Where problems could occur]

Since this change swaps from static allocation to dynamic to handle larger addresses, regressions would most likely be related to memory leaks. If this change fails to account for all situations, the address variable may not be freed, leading to greater memory usage. Also, without the size limit, overwhelmingly large address inputs may also cause issues.

[Original Description]

Hello all,

We recently encountered a bug in net-snmp V5.9.1 related to DNS name length (https://github.com/net-snmp/net-snmp/issues/476)

Here's a summary :

What I did :

snmpstatus -v2c -c public aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games

What I expected to happen :

Get a timeout from this domain because there's no snmpd running, and I wouldn't use public as a community anyway.

What I got :

snmpstatus: Unknown host (aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games) (No such file or directory)

This domain does exist, and does ping properly (also has V4, this is not the problem here):

PING aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games(2001:41d0:801:2000::539f) 56 data bytes
64 bytes from 2001:41d0:801:2000::539f: icmp_seq=1 ttl=46 time=26.0 ms
64 bytes from 2001:41d0:801:2000::539f: icmp_seq=2 ttl=46 time=27.2 ms

Upon discussing with a net-snmp github dev, they found out that a change to a feature introduced a char addr[64] to store the host address. They changed it to char addr* to work with >64 characters domains, and its working properly now.

This bug breaks some of our monitoring when updating our librenms ubuntu host to 22.04, which is an issue.

I am of course available if any additional information is needed.

Cheers,

Tanguy

[Lena Voytek (lvoytek)]

Hello,

Thank you for submitting this bug report. I created a PPA (https://launchpad.net/~lvoytek/+archive/ubuntu/net-snmp-fix-long-domain-names) for 22.04 with the fix provided by upstream, and it seems to work for me. If you would like to test it yourself you can run the following commands:

$ sudo add-apt-repository ppa:lvoytek/net-snmp-fix-long-domain-names
$ sudo apt update
$ sudo apt upgrade

If this works for you then I can get started adding it to Ubuntu 22.04 and other affected versions

Thanks!

[Tanguy Pelado (tanguypelado)]

Hello Lena,

We've successfully tested the new version of the package on a live Ubuntu 22.04, and so far, everything seems to work as expected.

We've tried testing it on 22.10, but it seems your PPA hasn't got the kinetic release.

Cheers

[Lena Voytek (lvoytek)]

Hi Tanguy,

Thanks for verifying with 22.04, I'll work on adding the fix in now. I've also updated the PPA with the fix for 22.10 if you need it/ would like to test it

[Tanguy Pelado (tanguypelado)]

Hello Lena,

We've tested the PPA on Kinetic (22.10) , it's working correctly as well.

Cheers

[Launchpad Janitor (janitor)]

This bug was fixed in the package net-snmp - 5.9.3+dfsg-1ubuntu3

---------------
net-snmp (5.9.3+dfsg-1ubuntu3) lunar; urgency=medium

  * d/p/restore-support-for-long-dns-names.patch: Fix snmp requests for domains
    longer than 63 characters (LP: #1998461)

 -- Lena Voytek <email address hidden> Mon, 05 Dec 2022 07:47:24 -0700

[Timo Aaltonen (tjaalton)]

Hello Tanguy, or anyone else affected,

Accepted net-snmp into kinetic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/net-snmp/5.9.3+dfsg-1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-kinetic to verification-done-kinetic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-kinetic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Timo Aaltonen (tjaalton)]

Hello Tanguy, or anyone else affected,

Accepted net-snmp into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/net-snmp/5.9.1+dfsg-1ubuntu2.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Tanguy Pelado (tanguypelado)]

Hello Timo,

I can confirm this works on Jammy :

root@ueransim:~# snmpstatus -v2c -c public aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games
Timeout: No Response from aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games
root@ueransim:~# snmpstatus -V
NET-SNMP version: 5.9.1
root@ueransim:~# apt search snmp | grep installed

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libsnmp-base/jammy-updates,jammy-security,now 5.9.1+dfsg-1ubuntu2.2 all [installed,automatic]
libsnmp40/jammy-proposed,now 5.9.1+dfsg-1ubuntu2.3 amd64 [installed,automatic]
python3-pyasn1/jammy,now 0.4.8-1 all [installed,automatic]
snmp/jammy-proposed,now 5.9.1+dfsg-1ubuntu2.3 amd64 [installed]
tcpdump/jammy,now 4.99.1-3build2 amd64 [installed,automatic]
root@ueransim:~#

I've updated the tags accordingly.

[Lena Voytek (lvoytek)]

Verified for Kinetic:

# lxc launch images:ubuntu/kinetic test-net-snmp
# lxc exec test-net-snmp bash

# cat <<EOF >/etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list
# Enable Ubuntu proposed archive
deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed restricted main multiverse universe
EOF

# apt update && apt dist-upgrade -y
# apt install snmp -y

# snmpstatus -v2c -c public aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games

Created directory: /var/lib/snmp/cert_indexes
Timeout: No Response from aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games

[Robie Basak (racb)]

Thank you for your help with this!

This looked like it was ready to release in Jammy, but I noticed a couple of things that should probably be addressed first.

1) Kinetic isn't verified yet, and so if we release this in Jammy, users might experience a regression on upgrade to Kinetic. Ideally we'd release the fix to Kinetic before or at the same time.

2) I looked at the patch itself, and found it concerning:

netsnmp_parse_ep_str() is called multiple times in succession, for example from snmpIPv4BaseDomain.c once for "default_target" and again against "inpeername" in the "Invalid default target" failure case. However:

a) While the patch adds various guards in the case that ep_str.addr is NULL, the error exit path in netsnmp_parse_ep_str() frees the pointer but does not reset ep_str.addr back to NULL. So what will happen later?

b) Given that netsnmp_parse_ep_str() can be called multiple times, what happens when it allocates new memory to ep_str.addr again? Is this a memory leak?

It's not clear to me if either of the paths above are actually possible to trigger from outside the program. That would require further analysis to find how these functions are called. But it seems to be that, at a minimum, the guards aren't complete unless all free() calls on the pointer reset the field to NULL, and that nothing new should be assigned to ep_str.addr before first freeing it if it was formerly not NULL.

I think this code needs to be more mature upstream before we can accept it as a patch in an SRU in Ubuntu.

On the other hand if you think my analysis is flawed, I would be happy to be corrected.

[Robie Basak (racb)]

Let's mark this blocked pending further discussion.

[Sergio Durigan Junior (sergiodj)]

I was interested in the conversation a look at bit more into this.

I noticed that upstream actually has implemented the necessary safeguard here:

https://github.com/net-snmp/net-snmp/commit/d420ff6cd3a3bd8ae469fc2d6a0bafd523280794

This is the upstream commit that is part of the master branch, and the commit that should have actually been backported. Instead, we're carrying the following commit:

https://github.com/net-snmp/net-snmp/commit/49a0bca5a138a975ba503e6e8e0c7f1b72fe74be

which is actually part of the initial PR, and doesn't belong to any upstream branch. Interestingly, I did catch this problem during the review (see the inline comments for diff 1bde929 at the MP), but I only asked Lena to update the "Origin" header, and failed to actually compare the patches line-by-line.

We are going to have to amend Jammy's SRU (Lena will probably need to refresh the patch), and will likely need to do another SRU to Kinetic.

[Sergio Durigan Junior (sergiodj)]

(In all fairness, I agree that the code could do a better job at handling variable ownership, but the code shipped by upstream is not technically wrong, so there's that...)

[Lena Voytek (lvoytek)]

I'm sorry for missing this. I've added a work in progress merge request for lunar that matches the upstream version of the commit here:

https://code.launchpad.net/~lvoytek/ubuntu/+source/net-snmp/+git/net-snmp/+merge/435225

This changes one line, setting the value to NULL after jumping to the err label. From what I can tell, though, I don't think this goes far enough to fix it as this is not matched when the address variable is freed in snmpIPv4BaseDomain.c, snmpIPv6BaseDomain.c, and T022netsnmp_parse_ep_str_clib.c. So having some additional cleanup from upstream would be good.

[Marc Deslauriers (mdeslaur)]

Unfortunately, the packages in the -proposed pocket have now been superseded by a security update.

[Lena Voytek (lvoytek)]

Uploaded version matching lunar to kinetic and jammy since this was superseded.

[Andreas Hasenack (ahasenack)]

Hello Tanguy, or anyone else affected,

Accepted net-snmp into kinetic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/net-snmp/5.9.3+dfsg-1ubuntu1.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-kinetic to verification-done-kinetic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-kinetic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Andreas Hasenack (ahasenack)]

Hello Tanguy, or anyone else affected,

Accepted net-snmp into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/net-snmp/5.9.1+dfsg-1ubuntu2.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Lena Voytek (lvoytek)]

Verified for Jammy
# lxc launch images:ubuntu/jammy test-net-snmp
# lxc exec test-net-snmp bash

# apt update && apt dist-upgrade -y
# apt install snmp -y

# snmpstatus -v2c -c public aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games

snmpstatus: Unknown host (aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games) (Resource temporarily unavailable)

# cat <<EOF >/etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list
# Enable Ubuntu proposed archive
deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed restricted main multiverse universe
EOF

# apt update && apt upgrade -y

# snmpstatus -v2c -c public aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games

Timeout: No Response from aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games

[Lena Voytek (lvoytek)]

Verified for Kinetic
# lxc launch images:ubuntu/kinetic test-net-snmp
# lxc exec test-net-snmp bash

# apt update && apt dist-upgrade -y
# apt install snmp -y

# snmpstatus -v2c -c public aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games

snmpstatus: Unknown host (aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games) (Resource temporarily unavailable)

# cat <<EOF >/etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list
# Enable Ubuntu proposed archive
deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed restricted main multiverse universe
EOF

# apt update && apt upgrade -y

# snmpstatus -v2c -c public aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games

Timeout: No Response from aaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaa.taledo.games

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted net-snmp (5.9.1+dfsg-1ubuntu2.5) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

cluster-glue/1.0.12-20ubuntu3 (amd64, ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#net-snmp

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Chris Halse Rogers (raof)]

The verification of the Stable Release Update for net-snmp has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package net-snmp - 5.9.3+dfsg-1ubuntu1.3

---------------
net-snmp (5.9.3+dfsg-1ubuntu1.3) kinetic; urgency=medium

  * d/p/restore-support-for-long-dns-names.patch: Fix snmp requests for domains
    longer than 63 characters (LP: #1998461)

 -- Lena Voytek <email address hidden> Mon, 23 Jan 2023 11:24:02 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package net-snmp - 5.9.1+dfsg-1ubuntu2.5

---------------
net-snmp (5.9.1+dfsg-1ubuntu2.5) jammy; urgency=medium

  * d/p/restore-support-for-long-dns-names.patch: Fix snmp requests for domains
    longer than 63 characters (LP: #1998461)

 -- Lena Voytek <email address hidden> Mon, 23 Jan 2023 11:33:32 -0700