[SNMP4J] Potential Bug / Fix with authentication and encryption passwords (empty passwords)

[David Catapano]

Hello,

I never saw a reply to this question, and looking through archives for
March looks like it never got posted so trying again.

Thanks,
Dave


On Wed, Mar 13, 2013 at 8:55 PM, David Catapano <dcatapano5825 at gmail.com>wrote:

> Hello,
>
> I'm new to this DL so hopefully I'm submitting this observation correctly.
>
> Been using SNMP4J for a while, and so far has work great.  Good stuff and
> thanks!
>
> Recently noticed a bug scenario which since this is an open source
> project, I think I have have been able to chase down and resolve but of
> course wanted to review with experts to make sure is correct.
>
> The scenario is a user is setup with agent as V3 with authentication and /
> or encryption.  Certainly if incorrect passwords are supplied by client
> during a GET operation, failure happens as expected.
>
> However, if empty passwords as supplied by client, the GET succeeds
> whereas it should fail.  True for authentication or encryption passwords.
>
> By making the following change in latest source code in *
> org.snmp4j.security.USM.processIncomingMsg(...)*, it seems to resolve
> issue (from roughly line 600 on down):
>
>
> usmSecurityStateReference.setUserName(user.getUserName().getValue());
>
>             final AuthenticationProtocol auth =
> securityProtocols.getAuthenticationProtocol(user.getUsmUser().getAuthenticationProtocol());
>             final PrivacyProtocol priv =
> securityProtocols.getPrivacyProtocol(user.getUsmUser().getPrivacyProtocol());
>
> // Added from here
> *            if (auth != null && securityLevel <
> SecurityLevel.AUTH_NOPRIV)
>             {
>                 final CounterEvent event = new CounterEvent(this,
> SnmpConstants.usmStatsWrongDigests);
>                 fireIncrementCounter(event);
>                 statusInfo.setSecurityLevel(new Integer32(securityLevel));
>                 statusInfo.setErrorIndication(new
> VariableBinding(event.getOid(), event.getCurrentValue()));
>                 return SnmpConstants.SNMPv3_USM_AUTHENTICATION_FAILURE;
>             }
>
>             if (priv != null && securityLevel < SecurityLevel.AUTH_PRIV)
>             {
>                 final CounterEvent event = new CounterEvent(this,
> SnmpConstants.usmStatsWrongDigests);
>                 fireIncrementCounter(event);
>                 statusInfo.setSecurityLevel(new Integer32(securityLevel));
>                 statusInfo.setErrorIndication(new
> VariableBinding(event.getOid(), event.getCurrentValue()));
>                 return SnmpConstants.SNMPv3_USM_DECRYPTION_ERROR;
>             }*
> // To here
>
>             if (((securityLevel >= SecurityLevel.AUTH_NOPRIV) && (auth ==
> null))
>                     || (((securityLevel >= SecurityLevel.AUTH_PRIV) &&
> (priv == null))))
>             {
>
> What seems to be happening, is the *securityLevel *passed into
> "processIncomingMsg" is flagged as "noAuthNoPriv" if no passwords are
> supplied, but if user name matches then additional check to see if needed
> passwords are present is missing (local *auth *and *priv *variables being
> non-null thus expecting *securityLevel *to be higher ).  Above seems to
> resolve this case but perhaps there's better method of catching this case.
>
> Thanks much.
>
> Hope this is helpful.
>
> Dave
>
>
>