From: Theo Buehler Subject: Re: snmpd(8): Be stricter with varbind value ranges/encodings To: Martijn van Duren Cc: tech@openbsd.org Date: Tue, 6 Feb 2024 23:02:39 +0100 On Tue, Feb 06, 2024 at 10:04:17PM +0100, Martijn van Duren wrote: > While reading RFC2578 I noticed some restrictions that are placed on > returned values that are currently not checked for. I don't think we > should blindly rely on all clients doing the right thing outside the > standardised ranges. Interesting that SNMP had the sense of imposing some restrictions here. Just a year ago there was CVE-2023-2650 because OIDs in the ASN.1 spec don't have a length restriction on their arcs. The diff is ok > --- snmp.h > +++ snmp.h > @@ -157,4 +157,17 @@ enum snmp_security_model { > > #define SNMP_MAX_TIMEWINDOW 150 /* RFC3414 */ > > +/* RFC2578 */ > +#define SMI_INTEGER_MIN -2147483648 > +#define SMI_INTEGER_MAX 2147483647 > +#define SMI_OCTETSTRING_MAX 65535 > +#define SMI_IPADDRESS_MAX 4 > +#define SMI_COUNTER32_MIN 0 > +#define SMI_COUNTER32_MAX 4294967295 > +#define SMI_GAUGE32_MIN 0 > +#define SMI_GAUGE32_MAX 4294967295 > +#define SMI_TIMETICKS_MIN 0 > +#define SMI_TIMETICKS_MAX 4294967295 I'd be inclined to use the INT32_MIN, INT32_MAX etc constants from stdint.h. I find them more readable than either their decimal or hexadecimal expansions and in addition I don't have to think about whether I need stupid LL suffixes or not.