There appears to be an error in the 5.4.1.1 tarball distribution that causes problems for me when I attempt to build the perl module: snmplib/snmp_version.c still contains a version string of "5.4.1" and that's where the configure script extracts VERSION from. So net-snmp-config --version reports 5.4.1, and the perl code that builds the perl Makefile contains version checking code that notices that 5.4.1 doesn't match 5.4.1.1 and so it bombs out.
Modifying snmplib/snmp_version.c to contain "5.4.1.1" fixes the problem for me. Nathan On Mon, Jun 9, 2008 at 12:13 PM, Wes Hardaker <[EMAIL PROTECTED]> wrote: > > I regret to inform you about multiple new releases of the Net-SNMP > suite. There is a ***CRITICAL SECURITY ISSUE*** that appears in the > SNMPv3 implementation that exists in every release made since the > SNMPv3 code was written (which includes all versions of UCD-SNMP and > Net-SNMP beyond version 4.0). Please read the following summary that > explains how this might impact you and what mitigation you can take: > > > > Let me upgrade NOW! Where's the code? > ---------------------------------------- > Grab one of the new releases from our sourceforge download sites: > > http://www.net-snmp.org/download.html > > > > Are there vulnerability tracking numbers? > ---------------------------------------- > Yes: > > CERT: VU#878044 > CVE: CVE-2008-0960 > > > > What does it affect? > ---------------------------------------- > The issue is part of the code that checks the authentication field of > the SNMPv3 packet. A carefully crafted SNMPv3 packet may succeed in > getting passed the authentication check when it should not. It does > not affect authorization checks (which is done by the VACM system) so > even if the falsified authentication succeeds, an attacker would only be > granted access to the portions of the SNMP MIB space that the account > would have been normally granted access to. > > > > What about SNMPv1 and SNMPv2c? > ---------------------------------------- > This does not affect SNMPv1 nor SNMPv2c. SNMPv1 and SNMPv2c are less > secure than SNMPv3 even when considering this problem. > > > > What should I do? > ---------------------------------------- > 1) Install one of the updated packages immediately which will fix the > problems. If you do that, you need not take any of the other steps > below. > > If you are using Net-SNMP through a third party distribution such > as your operating system vendor they should be release updates for > their systems ASAP as well (likely today for most of them). > > > > 2) If this is impossible to do quickly and immediately you can do any > of the following to help: > > a) Put firewalls in front of your SNMP ports. This is generally > recommended anyway, since allowing external access to any server > that doesn't need to be accessible across the entire Internet > is always good practice. > > b) Utilize encryption in addition to authentication. Turning on > *and requiring* DES or AES support for your SNMPv3 users will at > least make attacking a system more difficult. Cryptographically > speaking, encryption is not a good form of authentication but in > this case it will be better than not using it even if you don't > need to protect your SNMPv3 packets from disclosure. Make sure > you change your VACM authorization settings to require that > encryption be used. For example, in the rwuser or rouser config > tokens add "priv" to the end. For example: > > Change from: > rwuser wes > rouser joe > > Change to: > rwuser wes priv > rouser joe priv > > c) Decrease what an authenticated packet can do. If you do not > need SNMP SETs to be supported on your network, you con turn > them off by disallowing them. For example: > > Change from: > rwuser wes priv > > Change to: > rouser wes priv > ^ > > d) Detect illegal authentication attempts by turn on authentication > notifications. If you are using SNMP notifications (traps and > informs) in your network of SNMP agents, adding the following > line to your snmpd.conf file will make the agent send a trap or > inform when someone fails to authenticate properly to the > agent. Because an attacker trying to exploit this issue will > not succeed every time you should get notifications that devices > are being targeted: > > authtrapenable 1 > > (You will also need to define trap destinations if you have not already) > > > > Is there a patch instead? > ---------------------------------------- > > Yes, a direct small patch is available from: > > > https://sourceforge.net/tracker/index.php?func=detail&aid=1989089&group_id=12694&atid=456380 > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Net-snmp-coders mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
