SNMP address values are reversed on little-endian

Description

SNMP PDU bindings generally consist of an object identifier (OID) and a value. In some cases, the value can be an IPv4 address. On a little-endian machine, this address is incorrectly parsed in reverse because the 4 bytes are loaded in network order and not host order. The network_address_to_val() function in src/analyzer/protocol/snmp/snmp-analyzer.pac returns the following.
{{
new AddrVal(network_order);}}

Instead, it should probably return the following to convert the network order to host order, particularly for little-endian machines.
{{
new AddrVal(ntohl(network_order));}}

The network_address_to_val() function is called in two places, by asn1_obj_to_val() when the object tag is APP_IPADDRESS_TAG, and also by build_trap_pdu(). The above change was tested to correct the problem in the first, but the latter case was not tested.

These values are not logged anywhere by default, but can be accessed by utilizing event snmp_response() and using the value$address within a single pdu$bindings object. Here is some sample code to inspect the problem.
{{
@load base/protocols/snmp/main
module SNMP;
event snmp_response(c: connection, is_orig: bool, header: SNMP::Header, pdu: SNMP:DU) {
for (i in pdu$bindings) {
local binding = bindings[i];
if (binding$value?$address) {
print binding$value$address;
}
}
}}}

Sample traffic can be generated by executing the following command against an SNMP supported system. Some OIDs returned from most systems should contain IP addresses, assuming the version and community are correct.
{{
snmpwalk -v 2c -c public 192.168.0.1}}

After re-compiling with the ntohl() call included, the problem is resolved correctly, for at least the asn1_obj_to_val() case described above.

Environment

Linux 3.2.0-4-amd64 Intel x86_64

Assignee

Robin Sommer

Reporter

Anony Mous

Labels

External issue ID

None

Components

Fix versions

Affects versions

Priority

Normal
Configure