Bug#1003719: stund: killed with assertion failed message
Package: stun-server Version: 0.97~dfsg-2.1+b1 Severity: normal Tags: upstream Dear Maintainer, Through fuzzing with AFL++, a STUN request raising the following assertion in stund was found: stund: stun.cxx:791: void stunCreateUserName(const StunAddress4&, StunAtrString*): Assertion `l%4 == 0' failed. One UDP datagram that triggers the assertion is: $ echo AAIAAGS0zoCspgAAAGS0tM6ArPc= | base64 -d | hexdump -C 00 02 00 00 64 b4 ce 80 ac a6 00 00 00 64 b4 b4 |dd..| 0010 ce 80 ac f7 || 0014 This packet can be sent with: $ echo AAIAAGS0zoCspgAAAGS0tM6ArPc= | base64 -d | socat - UDP-DATAGRAM:10.0.2.15:3478 Stacktrace: $ gdb /usr/sbin/stund (gdb) run -v -h 10.0.2.15 Starting program: /usr/sbin/stund -v -h 10.0.2.15 STUN server version 0.97 If your machine does not have exactly two ethernet interfaces, you must specify the server and alt server Running with on interface 10.0.2.15:3478 with alternate 0.0.0.0:3479 Warning - no alternate ip address STUN will not work Binding to interface 0xf02000a Opened port 3478 with fd 3 Binding to interface 0xf02000a Opened port 3479 with fd 4 received on A1:P1 Got a request (len=20) from 10.0.2.15:47005 Received stun message: 20 bytes Request parsed ok Received SharedSecretRequestMsg on udp. send error 433. stund: stun.cxx:791: void stunCreateUserName(const StunAddress4&, StunAtrString*): Assertion `l%4 == 0' failed. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x77af7535 in __GI_abort () at abort.c:79 #2 0x77af740f in __assert_fail_base (fmt=0x77c59ee0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0xe76d "l%4 == 0", file=0xe705 "stun.cxx", line=791, function=) at assert.c:92 #3 0x77b05102 in __GI___assert_fail (assertion=assertion@entry=0xe76d "l%4 == 0", file=file@entry=0xe705 "stun.cxx", line=line@entry=791, function=function@entry=0xf5c0 "void stunCreateUserName(const StunAddress4&, StunAtrString*)") at assert.c:101 #4 0x6a30 in stunCreateUserName (source=..., username=username@entry=0x7fff9dbe) at stun.cxx:791 #5 0x97bd in stunCreateSharedSecretResponse (response=..., source=..., request=...) at stun.cxx:1007 #6 stunServerProcessMsg (buf=buf@entry=0x7fffa230 "", bufLen=, from=..., secondary=..., myAddr=..., altAddr=..., resp=, destination=, hmacPassword=, changePort=, changeIp=, verbose=) at stun.cxx:1058 #7 0xb532 in stunServerProcess (info=..., verbose=) at stun.cxx:1566 #8 0x622c in main (argc=, argv=) at server.cxx:222 The problem is found in stunCreateUserName() in stun.cxx: 762 void 763 stunCreateUserName(const StunAddress4& source, StunAtrString* username) [...] 770char buffer[1024]; 771sprintf(buffer, 772"%08x:%08x:%08x:", 773UInt32(source.addr), 774UInt32(stunRand()), 775UInt32(lotime)); [...] 783char hmacHex[41]; 784toHex(hmac, 20, hmacHex ); 785hmacHex[40] =0; 786 787strcat(buffer,hmacHex); 788 789int l = strlen(buffer); 790assert( l+1 < STUN_MAX_STRING ); 791assert( l%4 == 0 ); buffer's length is always a multiple of 3, not 4, due to the number of colons specified in sprintf()'s format string. Remark: buffer's length must be a multiple of 4, as STUN message attributes must be aligned on 4 byte boundary. -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages stun-server depends on: ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libstdc++6 8.3.0-6 Versions of packages stun-server recommends: ii stun-client 0.97~dfsg-2.1+b1 stun-server suggests no packages. -- no debconf information
Bug#1003720: stund: buffer overflow parsing error attribute
Package: stun-server
Version: 0.97~dfsg-2.1+b1
Severity: normal
Tags: upstream
Dear Maintainer,
Through fuzzing with AFL++, a STUN request triggering a buffer overflow
was found.
One UDP datagram that triggers the buffer overflow is:
$ echo EAAAEAEAAAEAAImJiYmJiYmJiQAACQEA | base64 -d |
hexdump -C
10 00 00 10 01 00 00 01 00 00 89 89 89 89 89 89
||
0010 89 89 89 00 00 09 00 00 00 00 00 00 00 00 00 00
||
0020 00 00 01 00 ||
0024
The packet can be sent with:
$ echo EAAAEAEAAAEAAImJiYmJiYmJiQAACQEA | base64 -d | socat
- UDP-DATAGRAM:10.0.2.15:3478
On x86_64, stund crashes, not due to the buffer overflow itself, but
because memcpy() is trying to read after the stack:
$ gdb /usr/sbin/stund
(gdb) run -v -h 10.0.2.15
Starting program: /usr/sbin/stund -v -h 10.0.2.15
STUN server version 0.97
If your machine does not have exactly two ethernet interfaces, you must
specify the server and alt server
Running with on interface 10.0.2.15:3478 with alternate 0.0.0.0:3479
Warning - no alternate ip address STUN will not work
Binding to interface 0xf02000a
Opened port 3478 with fd 3
Binding to interface 0xf02000a
Opened port 3479 with fd 4
received on A1:P1
Got a request (len=36) from 10.0.2.15:47185
Received stun message: 36 bytes
Program received signal SIGSEGV, Segmentation fault.
__memmove_avx_unaligned_erms () at
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:262
262 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file
or directory.
(gdb) bt
#0 __memmove_avx_unaligned_erms () at
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:262
#1 0x7bab in memcpy (__len=65532, __src=0x7fffa24c,
__dest=0x7fff986e) at /usr/include/x86_64-linux-gnu/bits/string3.h:53
#2 stunParseAtrError (result=..., hdrLen=0, body=0x7fffa24c
"\375\367\377\177") at stun.cxx:114
#3 stunParseMessage (buf=buf@entry=0x7fffa230 "", bufLen=, msg=..., verbose=verbose@entry=true) at stun.cxx:344
#4 0x958f in stunServerProcessMsg (buf=0x7fffa230 "",
bufLen=, from=..., secondary=..., myAddr=..., altAddr=...,
resp=, destination=,
hmacPassword=, changePort=, changeIp=,
verbose=) at stun.cxx:1040
#5 0x in ?? ()
(gdb) disassemble
Dump of assembler code for function __memmove_avx_unaligned_erms:
[...]
0x77c316fc <+76>:mov%rdx,%rcx
=> 0x77c316ff <+79>:rep movsb %ds:(%rsi),%es:(%rdi)
(gdb) info registers
[...]
rcx0xb248 45640
rdx0xfffc 65532
rsi0x7000 140737488351232
rdi0x7fffe622 140737488348706
rbp0x7fff95f0 0x7fff95f0
rsp0x7fff94e8 0x7fff94e8
(gdb) p $_siginfo._sifields._sigfault.si_addr
$5 = (void *) 0x7000
(gdb) info proc mappings
process 25711
Mapped address spaces:
Start Addr End Addr Size Offset objfile
[...]
0x7ffde000 0x70000x210000x0 [stack]
The problem is found in stunParseAtrError() in stun.cxx:
98 static bool
99 stunParseAtrError( char* body, unsigned int hdrLen, StunAtrError&
result )
100 {
101if ( hdrLen >= sizeof(result) )
102{
103 clog << "head on Error too large" << endl;
104 return false;
105}
106else
107{
108 memcpy(, body, 2); body+=2;
109 result.pad = ntohs(result.pad);
110 result.errorClass = *body++;
111 result.number = *body++;
112
113 result.sizeReason = hdrLen - 4;
114 memcpy(, body, result.sizeReason);
115 result.reason[result.sizeReason] = 0;
116 return true;
117}
118 }
hdrLen is not checked for being at least 4, thus resulting in
result.sizeReason being greater than the result.reason size
for any hdrLen < 0.
Remark:
There doesn't seems to be any remote code execution possible
as stun-server is compiled with -fstack-protector-strong, thus,
even if stack depth was greater, allowing memcpy() to complete
the buffer overflow, it would still trigger stack protector in
stunServerProcessMsg().
-- System Information:
Debian Release: 10.9
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Bug#739273: dibbler-client: segfaults in TAddrAddr::getValid
Package: dibbler-client Version: 0.8.2-1 Severity: normal Dear Maintainer, I'm no more able to restart dibbler-client, as soon as it start configuring the interface it segfault: dibbler-client[47071]: segfault at 10 ip 0045ac00 sp 7fff78ba4348 error 4 in dibbler-client[40+d8000] When ran under valgrind, here's the report: # valgrind --log-file=dibbler.valgrind.log --track-origins=yes /usr/sbin/dibbler-client run | Dibbler - a portable DHCPv6, version 0.8.2 (CLIENT, Linux port) | Authors : Tomasz Mrugalskithomson(at)klub.com.pl,Marek Senderskimsend(at)o2.pl | Licence : GNU GPL v2 only. Developed at Gdansk University of Technology. | Homepage: http://klub.com.pl/dhcpv6/ 2014.02.17 12:07:24 Client Warning Pid file found (pid=48245, file /var/lib/dibbler/client.pid), but process 48245 does not exist. 2014.02.17 12:07:24 Client NoticeMy pid (48295) is stored in /var/lib/dibbler/client.pid 2014.02.17 12:07:24 Client NoticeDetected iface dummy0/4, MAC=xx:xx:xx:xx:xx:xx. 2014.02.17 12:07:24 Client NoticeDetected iface eth1/3, MAC=yy:yy:yy:yy:yy:yy. 2014.02.17 12:07:24 Client NoticeDetected iface eth0/2, MAC=zz:zz:zz:zz:zz:zz. 2014.02.17 12:07:24 Client NoticeDetected iface lo/1, MAC=00:00:00:00:00:00. 2014.02.17 12:07:24 Client NoticeParsing /etc/dibbler/client.conf config file... 2014.02.17 12:07:25 Client Debug Prefix delegation option found. 2014.02.17 12:07:25 Client Debug Parsing /etc/dibbler/client.conf done, result=0 2014.02.17 12:07:25 Client Debug 1 interface(s) specified in /etc/dibbler/client.conf 2014.02.17 12:07:25 Client Info Interface eth0/2 configuation has been loaded. 2014.02.17 12:07:25 Client Debug DUID's value = aa:bb:cc:dd:ee:ff:gg:hh:ii:jj was loaded from client-duid file. 2014.02.17 12:07:25 Client Info My DUID is aa:bb:cc:dd:ee:ff:gg:hh:ii:jj. 2014.02.17 12:07:25 Client Info Loading old address database (client-AddrMgr.xml), using built-in routines. 2014.02.17 12:07:25 Client Info DB timestamp:1392635071, now()=1392635245, db is 174 second(s) old. 2014.02.17 12:07:25 Client Debug Loaded IA from a file: t1=3600, t2=7200,iaid=1, iface=2 2014.02.17 12:07:25 Client Debug Parsed IA, iaid=1, unicast=b80e:3ed1:f27f:0:b80e:3ed1:f27f:0 2014.02.17 12:07:25 Client Debug Loaded PD from a file: t1=3600, t2=7200, iaid=1, iface=2 2014.02.17 12:07:25 Client Debug Parsed prefix 2001:dead:beef:cafe::/56, pref=3800, valid=3800,ts=1392480252 2014.02.17 12:07:25 Client Debug Parsed PD, pdid=1, t1=3600, t2=7200 2014.02.17 12:07:25 Client Debug Client aa:aa:aa:aa:aa:aa:aa:aa:zz:zz:zz:zz:zz:zz loaded from disk successfuly (1/1/0 ia/pd/ta). 2014.02.17 12:07:25 Client Debug Bind reuse enabled (multiple instances allowed). 2014.02.17 12:07:25 Client NoticeCreating control (::) socket on the lo/1 interface. 2014.02.17 12:07:25 Client NoticeCreating socket (addr=fe80:::::) on eth0/2 interface. 2014.02.17 12:07:25 Client Debug Initialising link-state detection for interfaces: eth0/2 2014.02.17 12:07:25 Client NoticeCONFIRM support compiled in. 2014.02.17 12:07:25 Client Info Creating CONFIRM: 1 IA(s) on eth0/2 2014.02.17 12:07:25 Client Debug Authentication is disabled, not including auth options in message. 2014.02.17 12:07:25 Client Debug Sending CONFIRM(opts:1 3 8 6 ) on eth0/2 to multicast. 2014.02.17 12:07:25 Client Debug Sending CONFIRM(opts:1 3 8 6 ) on eth0/2 to multicast. 2014.02.17 12:07:25 Client Info Creating SOLICIT message with 0 IA(s), no TA and 1 PD(s) on eth0/2 interface. 2014.02.17 12:07:25 Client Debug Sending SOLICIT(opts:1 25 8 6 ) on eth0/2 to multicast. 2014.02.17 12:07:25 Client Debug Sleeping for 1 second(s). 2014.02.17 12:07:26 Client Info Processing msg (CONFIRM,transID=0xd58839,opts: 1 3 8 6) 2014.02.17 12:07:26 Client Debug Sending CONFIRM(opts:1 3 8 6 ) on eth0/2 to multicast. 2014.02.17 12:07:26 Client Info Processing msg (SOLICIT,transID=0x234345,opts: 1 25 8 6) 2014.02.17 12:07:26 Client Debug Sending SOLICIT(opts:1 25 8 6 ) on eth0/2 to multicast. 2014.02.17 12:07:26 Client Debug Sleeping for 1 second(s). 2014.02.17 12:07:27 Client Info Processing msg (CONFIRM,transID=0xd58839,opts: 1 3 8 6) 2014.02.17 12:07:27 Client Debug Sending CONFIRM(opts:1 3 8 6 ) on eth0/2 to multicast. 2014.02.17 12:07:27 Client Debug Sleeping for 1 second(s). 2014.02.17 12:07:28 Client Info Processing msg (CONFIRM,transID=0xd58839,opts: 1 3 8 6) 2014.02.17 12:07:28 Client Debug Sending CONFIRM(opts:1 3 8 6 ) on eth0/2 to multicast. 2014.02.17 12:07:28 Client Info Processing msg (SOLICIT,transID=0x234345,opts: 1 25 8 6) 2014.02.17 12:07:28 Client Debug Sending SOLICIT(opts:1 25 8 6 ) on eth0/2 to multicast. 2014.02.17 12:07:28 Client Debug Sleeping for 1 second(s). 2014.02.17 12:07:29 Client Info Processing msg
