/ Bug 2658 – Segfault in mod_radius when using long password
Bug 2658 - Segfault in mod_radius when using long password
: Segfault in mod_radius when using long password
Status: CLOSED FIXED
Product: ProFTPD
mod_radius
: 1.3.0rc1
: All All
: P2 normal
Assigned To: TJ Saunders
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-07-21 13:15 UTC by TJ Saunders
Modified: 2005-10-31 17:13 UTC (History)
1 user (show)

See Also:


Attachments
Fixes bug (hopefully) (822 bytes, patch)
2005-07-21 13:16 UTC, TJ Saunders
Details
Fixes bug (hopefully) (521 bytes, patch)
2005-07-26 21:12 UTC, TJ Saunders
Details

Note You need to log in before you can comment on or make changes to this bug.
Description TJ Saunders 2005-07-21 13:15:09 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.
Comment 1 TJ Saunders 2005-07-21 13:16:38 UTC
Created attachment 2358 [details]
Fixes bug (hopefully)
Comment 2 TJ Saunders 2005-07-24 14:08:36 UTC
Patch committed to CVS.
Comment 3 Martin L 2005-07-25 09:20:23 UTC
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
Comment 4 TJ Saunders 2005-07-25 11:09:13 UTC
What length of password did you use to trigger this?
Comment 5 Martin L 2005-07-26 04:51:24 UTC
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
Comment 6 TJ Saunders 2005-07-26 21:12:02 UTC
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.
Comment 7 TJ Saunders 2005-07-26 22:01:44 UTC
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.
Comment 8 Martin L 2005-07-29 11:03:59 UTC
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)
Comment 9 TJ Saunders 2005-07-29 11:24:31 UTC
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?
Comment 10 Martin L 2005-08-01 09:00:35 UTC
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
Comment 11 TJ Saunders 2005-08-01 12:29:05 UTC
See Bug #2669.
Comment 12 TJ Saunders 2005-08-03 13:09:23 UTC
Committed second patch to CVS.
Comment 13 Martin L 2005-08-05 02:19:10 UTC
Hi TJ, 

I tested the patches and it worked. 
I will apply it to my prod system .
Thanks. 
Comment 14 TJ Saunders 2005-10-31 17:13:49 UTC
Resolved in 1.3.0rc3.