Wed Feb 13 17:44:13 CET 2002
Well, I'm not sure about the "did not waste resources" part. ;)
It seems as if the snmp agent pretty prints an error message
upon a decoding error. For some of the PDUs, this message can
become quite sizeable, e.g. after a badarg on
I think the appropriate thing to do for a protocol handler is to
_optionally_ log invalid messages in the cheapest way possible
(using e.g. disk_log). This is simple enough to fix.
Try the following for grins (not entirely accurate, but close
1> L = lists:seq(1,256).
2> Reason = (catch list_to_binary(L)).
5> snmp_error:user_err("failed encoding message only(pdu: ~p,
community: ~p): ~p~n", [L,"public",]).
=ERROR REPORT==== 13-Feb-2002::17:15:32 ===
** User error: failed encoding message only(pdu: [1,
<lots and lots of output snipped>
(In general, someone should come up with a nice way to protect
against io:format()s or crash reports with huge information
Running this on an embedded system with start_erl and to_erl (and
to_erl activated which means I/O gets directed to both screen and
disk) on a Solaris system (seemingly slower I/O system than
Linux, and no graphics accelerators), might cause some
On Wed, 13 Feb 2002, Martin Bjorklund wrote:
>You might have seen that CERT has found vulnerabilities in many
>implementations of SNMP
>I've had an oppurtunity to run the tool they're using to find
>these falws towards OTP's SNMP agent (some 30.000 cases with
>mostly malformed ASN.1 PDUs). No security issues were found,
>and the agent did not waste resources during the test.
>However, I did found a couple of bugs; in some of the corner
>cases the packets were silently dropped but the
>snmpInASNParseErrs counter was not incremented. A patch for
>this bug is attached. (Also, looking at the code in
>snmp_pdus.erl, I realize that there is lots of room for
More information about the erlang-questions