/
Bugzilla – Bug 2658
Segfault in mod_radius when using long password
Last modified: 2005-10-31 17:13:49 UTC
From a proftp-user post: Date: Mon, 18 Jul 2005 17:27:12 +0200 From: Martin Loewer <mloewer@web.de> Reply-To: proftp-user@lists.sourceforge.net To: proftp-user@lists.sourceforge.net Subject: [Proftpd-user] proftpd segmentation fault using mod_radius Hi, during some security testing it appears that proftpd with mod_radius enabled got a segmentation fault when the "pass" statement has a long string (e.g. 1000 x a ). When I disable the mod_radius, the proftpd gives me a messeage "530 Login incorrect". So I think there may be a problem in the mod_radius module. I am using an AIX machine with proftpd 1.3.0rc1, but I have recreated the problem on debian sarge with proftpd 1.2.10. harry (10.155.11.121[10.155.11.121]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_tls harry (10.155.11.121[10.155.11.121]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_core harry (10.155.11.121[10.155.11.121]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_core harry (10.155.11.121[10.155.11.121]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_radius harry (10.155.11.121[10.155.11.121]) - ProFTPD terminating (signal 11) harry (10.155.11.121[10.155.11.121]) - FTP session closed.
Created attachment 2358 [details] Fixes bug (hopefully)
Patch committed to CVS.
HI TJ, good news is that the patch has resolved the problem in mod_radius. But now the proftpd crashes at the mod_auth module. Should I open a new bug report on this or will you track it here ? New backtrace : harry (127.0.0.1[127.0.0.1]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_core harry (127.0.0.1[127.0.0.1]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_radius harry (127.0.0.1[127.0.0.1]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_delay harry (127.0.0.1[127.0.0.1]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_auth Program received signal SIGSEGV, Segmentation fault. 0x401f7965 in mallopt () from /lib/tls/libc.so.6 (gdb) bt #0 0x401f7965 in mallopt () from /lib/tls/libc.so.6 #1 0x401f6c43 in malloc () from /lib/tls/libc.so.6 #2 0x08052c09 in smalloc (size=524) at pool.c:87 #3 0x08052c39 in malloc_block (size=512) at pool.c:119 #4 0x08052dc9 in new_block (minsz=512, exact=0) at pool.c:206 #5 0x080530c2 in make_sub_pool (p=0x0) at pool.c:336 #6 0x0806cad1 in call_module (m=0x80d7e20, func=0x80b86cb <radius_endpwent>, cmd=0x8111c44) at modules.c:430 #7 0x0806e382 in dispatch_auth (cmd=0x8111c44, match=0x80c2e18 "endpwent") at auth.c:77 #8 0x0806e484 in pr_auth_endpwent (p=0x8111c04) at auth.c:113 #9 0x0809838b in auth_pre_pass (cmd=0x80e64cc) at mod_auth.c:1841 #10 0x0806cafd in call_module (m=0x80d5ca0, func=0x8098377 <auth_pre_pass>, cmd=0x80e64cc) at modules.c:435 #11 0x0804dd02 in _dispatch (cmd=0x80e64cc, cmd_type=1, validate=0, match=0x80e651c "PASS") at main.c:570 #12 0x0804dfdb in pr_cmd_dispatch (cmd=0x80e64cc) at main.c:632 #13 0x0804e987 in cmd_loop (server=0x80e6d0c, c=0x8123c34) at main.c:864 #14 0x0804f513 in fork_server (fd=1, l=0x8123814, nofork=0 '\0') at main.c:1362 #15 0x0804fb9c in daemon_loop () at main.c:1569 #16 0x08050fe5 in standalone_main () at main.c:2373 #17 0x08051b01 in main (argc=2, argv=0xbffffd04, envp=0xbffffd10) at main.c:2912 (gdb) Regard, Martin
What length of password did you use to trigger this?
I don't know exactly how much it was. I made a new backtrace with 500 "a". See below. I switched to Version 1.3.0.rc2 ( as I recognized that it has already the Patch for mod_radius. My configure options are : --enable-devel=coredump:nodaemon:nofork --with-modules=mod_radius:mod_tls Also I recognized some strange behaviers: 1. The problem disappeared when I don't use mod_radius. 2. The problem disappeared also when I use mod_radius and mod_tls. Program received signal SIGSEGV, Segmentation fault. 0x401f7965 in mallopt () from /lib/tls/libc.so.6 (gdb) bt #0 0x401f7965 in mallopt () from /lib/tls/libc.so.6 #1 0x401f6c43 in malloc () from /lib/tls/libc.so.6 #2 0x08052c09 in smalloc (size=524) at pool.c:87 #3 0x08052c39 in malloc_block (size=512) at pool.c:119 #4 0x08052dc9 in new_block (minsz=512, exact=0) at pool.c:206 #5 0x080530c2 in make_sub_pool (p=0x0) at pool.c:336 #6 0x0806cad1 in call_module (m=0x80d7e20, func=0x80b86cb <radius_endpwent>, cmd=0x8111c44) at modules.c:430 #7 0x0806e382 in dispatch_auth (cmd=0x8111c44, match=0x80c2e18 "endpwent") at auth.c:77 #8 0x0806e484 in pr_auth_endpwent (p=0x8111c04) at auth.c:113 #9 0x0809838b in auth_pre_pass (cmd=0x80e64cc) at mod_auth.c:1841 #10 0x0806cafd in call_module (m=0x80d5ca0, func=0x8098377 <auth_pre_pass>, cmd=0x80e64cc) at modules.c:435 #11 0x0804dd02 in _dispatch (cmd=0x80e64cc, cmd_type=1, validate=0, match=0x80e651c "PASS") at main.c:570 #12 0x0804dfdb in pr_cmd_dispatch (cmd=0x80e64cc) at main.c:632 #13 0x0804e987 in cmd_loop (server=0x80e6d0c, c=0x8123c34) at main.c:864 #14 0x0804f513 in fork_server (fd=1, l=0x8123814, nofork=0 '\0') at main.c:1362 #15 0x0804fb9c in daemon_loop () at main.c:1569 #16 0x08050fe5 in standalone_main () at main.c:2373 #17 0x08051b01 in main (argc=2, argv=0xbffffd04, envp=0xbffffd10) at main.c:2912
Created attachment 2360 [details] Fixes bug (hopefully) This patch will also be necessary. Much of the code in mod_radius was influenced by freeradius code. Unfortunately, that the time mod_radius was developed, freeradius created RADIUS packets using stack memory, writing attribute information into portions of the stack which were _assumed_ to be unused. That assumption broke, in this particular case. A quick fix is to pad the size of the radius_packet_t structure to be greater than the longest password supported, so that the stack writing tricks employed in mod_radius don't corrupt other pointers (as the segfault was showing). This padding should address the issue. A more proper solution would involve a rewrite of how mod_radius constructs and operates on packet objects.
Sorry, I meant "heap" in my previous comment, instead of "stack"; mod_radius was writing into portions of the heap that ideally it should not have been.
Hi TJ, I started testing the patch and it seems to work. But during the tests I missed typing the user statement before the pass statement and the deamon crashed again. I tried with a short password and it gives me a segfault again. Here are some Details: telnet localhost 21 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. 220 ProFTPD 1.3.0rc2 Server (ruby FTP Server virtual) [127.0.0.1] pass mloewer harry (127.0.0.1[127.0.0.1]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_tls harry (127.0.0.1[127.0.0.1]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_core harry (127.0.0.1[127.0.0.1]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_core harry (127.0.0.1[127.0.0.1]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_radius Program received signal SIGSEGV, Segmentation fault. 0x401fd363 in strlen () from /lib/tls/libc.so.6 (gdb) bt #0 0x401fd363 in strlen () from /lib/tls/libc.so.6 #1 0x080b74d9 in radius_build_packet (packet=0x812bf44, user=0x0, passwd=0x812b994 "mloewer", secret=0x8121a74 "testing123") at mod_radius.c:1563 #2 0x080b8951 in radius_pre_pass (cmd=0x812b93c) at mod_radius.c:2253 #3 0x0806cafd in call_module (m=0x80d7e20, func=0x80b87ce <radius_pre_pass>, cmd=0x812b93c) at modules.c:435 #4 0x0804dd02 in _dispatch (cmd=0x812b93c, cmd_type=1, validate=0, match=0x812b98c "PASS") at main.c:570 #5 0x0804dfdb in pr_cmd_dispatch (cmd=0x812b93c) at main.c:632 #6 0x0804e987 in cmd_loop (server=0x80e6d0c, c=0x81265cc) at main.c:864 #7 0x0804f513 in fork_server (fd=1, l=0x812609c, nofork=0 '\0') at main.c:1362 #8 0x0804fb9c in daemon_loop () at main.c:1569 #9 0x08050fe5 in standalone_main () at main.c:2373 #10 0x08051b01 in main (argc=2, argv=0xbffffd04, envp=0xbffffd10) at main.c:2912 (gdb)
Please be very specific. How short of a password did you use? Did you see the segfault after not sending USER, sending PASS, then trying USER/PASS again? Or was it a different sequence?
I did the following: telnet to port 21 of localhost, then typing "pass mloewer" return and the proftpd crashed imediatly. Nothing else. Then generate the backtrace which is in the comment above. script output: telnet localhost 21 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. 220 ProFTPD 1.3.0rc2 Server (ruby FTP Server virtual) [127.0.0.1] pass mloewer
See Bug #2669.
Committed second patch to CVS.
Hi TJ, I tested the patches and it worked. I will apply it to my prod system . Thanks.
Resolved in 1.3.0rc3.