Re: pkg/49860: DoS against snmpd on netbsd routers

[christos%zoulas.com@localhost (Christos Zoulas)]

The following reply was made to PR pkg/49860; it has been noted by GNATS.

From: christos%zoulas.com@localhost (Christos Zoulas)
To: 6bone%6bone.informatik.uni-leipzig.de@localhost, gnats-bugs%NetBSD.org@localhost
Cc: pkg-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, pkgsrc-bugs%netbsd.org@localhost
Subject: Re: pkg/49860: DoS against snmpd on netbsd routers
Date: Mon, 27 Apr 2015 10:45:59 -0400

 On Apr 27,  3:16pm, 6bone%6bone.informatik.uni-leipzig.de@localhost (6bone%6bone.informatik.uni-leipzig.de@localhost) wrote:
 -- Subject: Re: pkg/49860: DoS against snmpd on netbsd routers
 
 | On Sun, 26 Apr 2015, Joerg Sonnenberger wrote:
 | 
 | > Can you ktrace it to see what it is doing? Does sockstat work fine? The
 | > problem with net-snmp is that it is extremely messy code and quite a few
 | > things are using kmem when they don't have to, so it is easy to hit race
 | > conditions and the like.
 | 
 | I've never worked with ktrace. I have tested ktruss -p <pid snmpd>
 | 
 | The output at 100% CPU was as follows:
 | 
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | ....
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    mmap(0, 0x100000, 0x3, 0x14001002, 0xffffffff, 0, 0) 
 | = 0x7f7feeb00000
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | ...
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    mmap(0, 0x100000, 0x3, 0x14001002, 0xffffffff, 0, 0) 
 | = 0x7f7fee300000
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | ...
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    mmap(0, 0x100000, 0x3, 0x14001002, 0xffffffff, 0, 0) 
 | = 0x7f7fee200000
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | ...
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    mmap(0, 0x100000, 0x3, 0x14001002, 0xffffffff, 0, 0) 
 | = 0x7f7fedf00000
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | 10754      1 snmpd    __clock_gettime50(0x3, 0x7f7fffffd930) = 0
 | ...
 | 
 | Does that help?
 
 Not very much, it seems to keep allocating memory... So perhaps gdb the
 process, break in malloc, and print a backtrace?
 
 $ gdb /path/to/snmpd pid-of-snmp-d
 (gdb) break malloc
 (gdb) continue
 (gdb) where
 (gdb) quit
 [hopefully it [snmpd] did not die, but it could...]
 
 christos