Invalid SCP command leads to null pointer dereference

[Castaglia]

Fabian Vogt reported via email that while debugging an issue with libssh+mod_sftp, he accidentially stumbled upon a
reliable way to crash the proftpd server process (ProFTPD Version 1.3.6d):

ssh user@server scp

This causes sftp_scp_set_params to call getopt() with argc=2 and argv of ["scp", NULL], which leads to a null deref in getopt(). This does not happen with plain scp as client, because it passes the target path as non-option argument and so getopt() does not even reach the invalid last argv pointer.

(gdb) bt       
#0  0x00007ffff7c012a3 in _getopt_internal_r (argc=2, argv=argv@entry=0x5555556e2988, optstring=optstring@entry=0x7ffff77d16d3 "dfprtv", longopts=longopts@entry=0x0, longind=longind@entry=0x0, long_only=long_only@entry=0,
    d=0x7ffff7cdf4a0 <getopt_data>, posixly_correct=0) at getopt.c:527
#1  0x00007ffff7c017d1 in _getopt_internal (argc=<optimized out>, argv=argv@entry=0x5555556e2988, optstring=optstring@entry=0x7ffff77d16d3 "dfprtv", longopts=longopts@entry=0x0, longind=longind@entry=0x0, long_only=long_only@entry=0,
    posixly_correct=0) at getopt.c:711
#2  0x00007ffff7c01813 in getopt (argc=<optimized out>, argv=argv@entry=0x5555556e2988, optstring=optstring@entry=0x7ffff77d16d3 "dfprtv") at getopt.c:735
#3  0x00007ffff77b9fb2 in sftp_scp_set_params (p=0x5555556e2810, channel_id=0, req=0x5555556e2968) at scp.c:2494
#4  0x00007ffff779e5ea in handle_exec_channel (buflen=0x7fffffffdcd8, buf=0x7fffffffdce0, pkt=0x5555556e2858, chan=0x5555556e4268) at channel.c:810
#5  handle_channel_req (pkt=0x5555556e2858) at channel.c:1012
#6  sftp_channel_handle (pkt=0x5555556e2858, mesg_type=<optimized out>) at channel.c:1343
#7  0x00007ffff7782433 in sftp_ssh2_packet_handle () at packet.c:1632
#8  0x00007ffff7782a8a in sftp_cmd_loop (s=<optimized out>, conn=0x5555556e63c8) at mod_sftp.c:302
#9  0x000055555557a7a0 in fork_server (fd=<optimized out>, l=<optimized out>, no_fork=<optimized out>) at main.c:1483
#10 0x000055555557b128 in daemon_loop () at main.c:1720
#11 0x0000555555571959 in standalone_main () at main.c:1905
#12 main (argc=2, argv=<optimized out>, envp=<optimized out>) at main.c:2616
(gdb) p argv[1]
$8 = 0x0

It's after authentication and just a nullptr deref, so not highly critical.

[Castaglia]

Fixed in master, and backported to the 1.3.6 branch.

[Vogtinator]

Thanks! I can confirm that #1043 fixes the crash.