RE: COPS vs. SNMP

["Hahn, Scott" <scott.hahn@intel.com>]

While I find this discussion interesting, I think a discussion about
potentially security problems in SNMP should be moved to one or all of the
SNMP mailing lists.

	-Scott Hahn
	RAP WG co-chair

-----Original Message-----
From: Glenn Waters [mailto:gww@nortelnetworks.com]
Sent: Wednesday, February 27, 2002 7:05 AM
To: rap@ops.ietf.org
Cc: Durham, David
Subject: RE: COPS vs. SNMP


Dave, the CERT advisory is purely about SNMP implementations and it not in
any way about the design of the SNMP protocol.
The types of implementation problems that have been identified are pretty
much all buffer overflow problems. When a buffer overflow occurs the box
will typically exhibit some bad behavior -- like crash. This is known as a
denial of service attack. Some smart hackers have even put assembled byte
code in the overflowed buffer in an attempt to get that code to execute. In
this case, the hacker could possibly take control of the box.
If you remember your Internet history, many years ago the SMTP protocol was
used to compromise a system. This also made the news big time. I would
characterize the SMTP protocol encoding to be even simpler than COPS-PR; to
which I conclude that COPS-PR is just as vulnerable as ANY other protocol.
Try the following goggle search and you see what I mean by the word ANY in
the previous sentence:
        http://www.google.com/search?hl=en&q=buffer+overflow 
/gww 
-----Original Message----- 
From: Durham, David [mailto:david.durham@intel.com] 
Sent: Tuesday, February 26, 2002 21:13 
To: 'David.Partain@ericsson.com'; rap@ops.ietf.org 
Subject: RE: COPS vs. SNMP 
Comments inline... 
> -----Original Message----- 
> From: David Partain [mailto:David.Partain@ericsson.com] 
> Sent: Tuesday, February 26, 2002 4:03 AM 
> To: Durham, David; 'Wijnen, Bert (Bert)'; rap@ops.ietf.org 
> Subject: Re: COPS vs. SNMP 
> 
[DaveD] ... 
> I don't see that that has _anything_ whatsoever to do with SNMP 
> (which was the focus of your mail about the CERT advisory), 
> but it certainly is related to SNMPCONF (of course).  Of course, 
> this model has existed in DISMAN for a number of years, as well 
> as in various other areas of technology. 
> 
[DaveD] The issue is two fold, 1. if the installed base of 
protocol/implementations for whatever reason are being shut-off, then who 
can do configuration management with SNMP? 2. Somebody should take a close 
look at running local scripts to do policy control, specifically in the 
context of SNMPConf... I've brought this up before, the CERT advisory is a 
nice reminder to make sure some up-front attack prevention is done or at 
least considered. Clearly defining the division of responsibility between PM

policy and SNMPv3 access-control would be a nice place to start. 
> bw> The SNMP CERT advisories have NOT talked about a flaw 
> bw> in the SNMP Protocol at all. They have talked about implementation 
> dd> Perhaps, 
> 
> It's not a question of "perhaps".  It's absolutely certain. 
> Please read the advisory. 
[DaveD] The advisory is not clear in this regard, I read it. Also, the press

reports clearly specify  that there are Vulnerabilities in the SNMP 
Protocol. It was not clear if this was based ONLY on the cited CERT 
advisory. 
> 
> dd> There are a lot of SHOULDs and MAYs in the specs that 
> help contribute to 
> dd> implementations going awry. 
> 
> In this case, it's classic programming errors in handling 
> buffers.  It's exactly the same kind of programming errors that 
> have affected a very wide range of available software from 
> OS kernels to web servers to printing systems, to.... 
> 
> Don't try to blame this on the protocol.  It won't fly. 
[DaveD] Ummm, the protocol can make it more difficult for implementations to

get it right. Eg. XML provides nice begin tags and end tags. Or better yet, 
fixed size fields are easier to implement than allowing everything to vary. 
Allowing fields to vary (via the spec) within bounds specified with a lower 
bound of MUST and an upper bound of SHOULD also adds to the complexity for 
implementers. 
> 
> dd> COPS and COPS-PR security mechanisms are NOT BER-based. 
> 
> It has absolutely nothing to do with security mechanisms. 
> It's buffer overflows. 
[DaveD] If the protocol uses the BER encoded security mechanisms, and the 
BER encodings are susceptible to buffer overflows,  then you can obviously 
directly attack a machine through the BER encoded security mechanism itself!

> 
> dd> The security 
> dd> mechanisms use fixed size COPS objects and tried & true 
> TCP security 
> dd> mechanisms. Once the persistent & secure client/server 
> communication is 
> dd> established, only then does BER come into play. Even 
> then, the BER objects 
> dd> are still wrapped in COPS objects, providing an extra 
> level of validation 
> dd> to avoid buffer overruns and the like. 
> 
> If the folks writing COPS/COPS-PR code write perfect code, 
> I'm sure there'll never be any COPS-related problems with any 
> kind of denial of service or buffer overflow attack. 
[DaveD] ... And I forgot to point out that the SPPI promotes better type 
checking as well, and removes the need for those long, composit-INDEX OIDs 
altogether. Keeping things easy for implementers is a good thing here!