#2412 4 octets out of 16 of a localized key seem to be ignored

open
nobody
None
5
2012-11-08
2012-09-11
Serge B
No

I have to open a new bug, since my original one 3559938 was promptly closed as invalid, which I believe is wrong, and there was no way for me to reopen it or even post a comment, whereas my e-mail with additional explanations went unanswered.
So, the gist of the problem is that out of the 16 octets of a privacy localized key for an snmpv3 user having SHA authentication and DES privacy, up to 4 octets seem to not matter. I'm running net-snmp 5.4.2.1 on Ubuntu 10.04.4 LTS (Linux version 2.6.32-41-generic), but I have reasons to believe the issue exists also in 5.7.1, and probably other versions. Here are the steps I used when the problem manifested itself:
1. Create an snmpv3 user with read-write access (probably, can be any access), SHA authentication and DES privacy.
2. Generate localized keys for a given EngineID, SHA authentication and DES privacy (I used the snmpkey utility).
Note that the auth key generated is exactly 40 hex-digits (20 bytes), and the privacy key generated is exactly 32 hex-digits (16 bytes) - as they should be, not more and not less.
3. Issue commands for this user to use localized keys instead of the passphrases:
3a. snmpusm -v3 -u "user_name" -n "" -l authPriv -a SHA -A "auth_setup_passphrase" -x DES -X "priv_setup_passphrase" localhost passwd -Ca -Ck "auth_setup_passphrase" "auth_hex_localized_key"
3b. snmpusm -v3 -u "user_name" -n "" -l authPriv -a SHA -3k "auth_hex_localized_key" -x DES -X "priv_setup_passphrase" localhost passwd -Cx -Ck "priv_setup_passphrase" "priv_hex_localized_key"
4. Run an snmp command (I used snmpget) using the original - correct - privacy key:
snmpget -v 3 -u "user_name" -n "" -l authPriv -a SHA -3k "auth_hex_localized_key" -x DES -3K "priv_hex_localized_key" localhost sysUpTime.0
You get a correct response - something like:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (211115) 0:35:11.15
5. Run the same command using a tampered version of the privacy key, where any number of the last 4 octets are changed, e.g., if the original key is 0xc5665184fe8fc2202291b5c67df77c68, try using something like 0xc5665184fe8fc2202291b5c67df77c00, or 0xc5665184fe8fc2202291b5c67d123456. You get the same correct response:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (219104) 0:36:31.04
6. Run the same command using a tampered version of the privacy key, where the last 5 octets are changed, e.g., 0xc5665184fe8fc2202291b50000000000 - the command fails:
Timeout: No Response from localhost

Discussion


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks