Page 1 of 1

vsftpd (pax)

PostPosted: Wed Sep 03, 2003 2:33 am
by devastor
Hi,

I've have some problems with vsftpd 1.2.0 and maybe somebody here can
figure out from the logs what's going on:

PAX: From 81.49.59.38: terminating task: /usr/sbin/vsftpd(vsftpd):10123, uid/euid: 1063/1063, EIP: 08052D60, ESP: 5F168BD8
PAX: bytes at EIP: 55 89 e5 83 ec 14 53 8b 5d 08 83 fb 3f 76 0d 83 c4 f4 68 c0
PAX: From 81.49.59.38: terminating task: /usr/sbin/vsftpd(vsftpd):7021, uid/euid: 1063/1063, EIP: 08052D60, ESP: 5F9BFCD8
PAX: bytes at EIP: 55 89 e5 83 ec 14 53 8b 5d 08 83 fb 3f 76 0d 83 c4 f4 68 c0
PAX: From 212.11.17.145: terminating task: /usr/sbin/vsftpd(vsftpd):23104, uid/euid: 1063/1063, EIP: 08052D60, ESP: 59888CE8
PAX: bytes at EIP: 55 89 e5 83 ec 14 53 8b 5d 08 83 fb 3f 76 0d 83 c4 f4 68 c0
PAX: From 81.49.59.38: terminating task: /usr/sbin/vsftpd(vsftpd):22608, uid/euid: 1063/1063, EIP: 08052D60, ESP: 5BD85288
PAX: bytes at EIP: 55 89 e5 83 ec 14 53 8b 5d 08 83 fb 3f 76 0d 83 c4 f4 68 c0
PAX: From 81.49.59.38: terminating task: /usr/sbin/vsftpd(vsftpd):24179, uid/euid: 1063/1063, EIP: 08052D60, ESP: 5BF3EF18
PAX: bytes at EIP: 55 89 e5 83 ec 14 53 8b 5d 08 83 fb 3f 76 0d 83 c4 f4 68 c0
PAX: From 81.49.59.38: terminating task: /usr/sbin/vsftpd(vsftpd):905, uid/euid: 1063/1063, EIP: 08052D60, ESP: 5FE78A68
PAX: bytes at EIP: 55 89 e5 83 ec 14 53 8b 5d 08 83 fb 3f 76 0d 83 c4 f4 68 c0
PAX: From 81.53.64.71: terminating task: /usr/sbin/vsftpd(vsftpd):10896, uid/euid: 1063/1063, EIP: 08052D60, ESP: 5A183E98
PAX: bytes at EIP: 55 89 e5 83 ec 14 53 8b 5d 08 83 fb 3f 76 0d 83 c4 f4 68 c0
PAX: From 81.49.59.38: terminating task: /usr/sbin/vsftpd(vsftpd):22616, uid/euid: 1063/1063, EIP: 08052D60, ESP: 58A93478
PAX: bytes at EIP: 55 89 e5 83 ec 14 53 8b 5d 08 83 fb 3f 76 0d 83 c4 f4 68 c0
PAX: From 81.49.59.38: terminating task: /usr/sbin/vsftpd(vsftpd):14890, uid/euid: 1063/1063, EIP: 08052D60, ESP: 5C0E2408
PAX: bytes at EIP: 55 89 e5 83 ec 14 53 8b 5d 08 83 fb 3f 76 0d 83 c4 f4 68 c0
PAX: From 82.64.180.129: terminating task: /usr/sbin/vsftpd(vsftpd):18845, uid/euid: 1063/1063, EIP: 08052D60, ESP: 58426BA8
PAX: bytes at EIP: 55 89 e5 83 ec 14 53 8b 5d 08 83 fb 3f 76 0d 83 c4 f4 68 c0

Does those bytes at EIP tell something to someone?:)
would be nice to find out when and where in the code that happens..
running it through gdb would probably tell that.. Need to check that out..
Oh and Pax doesn't kill it everytime somebody connects to it and uploads/downloads something..

-devastor

Re: vsftpd (pax)

PostPosted: Wed Sep 03, 2003 5:46 am
by PaX Team
devastor wrote:PAX: From 81.49.59.38: terminating task: /usr/sbin/vsftpd(vsftpd):10123, uid/euid: 1063/1063, EIP: 08052D60, ESP: 5F168BD8
PAX: bytes at EIP: 55 89 e5 83 ec 14 53 8b 5d 08 83 fb 3f 76 0d 83 c4 f4 68 c0

Does those bytes at EIP tell something to someone?:)
It is the vsf_sysutil_common_sighandler() function in sysutil.c and as far as i see, it ends up in a valid executable segment so the above is a bit of a mystery. Can you tell me your kernel/glibc/gcc/binutils/grsec version and make your .config and vsftpd binary available? I think this function is normally called on timeouts, maybe that explains why you don't see it on every connection.

PostPosted: Wed Sep 03, 2003 3:08 pm
by devastor
kernel: 2.4.20 + all the security patches
glibc: 2.2.5
gcc: 2.95.4
binutils: 2.12.90.0.1
grsec: 1.9.9h

.config and vsftpd binary are available at
http://www.silen.eu.org/vsftpd/

PostPosted: Thu Sep 04, 2003 4:12 pm
by PaX Team
devastor wrote:.config and vsftpd binary are available at
http://www.silen.eu.org/vsftpd/
just a quick note, i'm on vacation right now (you just missed it by a few hours ;-), so can't take a look at it until the end of next week.

PostPosted: Sat Sep 13, 2003 10:20 am
by PaX Team
devastor wrote:kernel: 2.4.20 + all the security patches
grsec: 1.9.9h
could you do two tests please:

1. the above kernel but with KERNEXEC/EMUSIGRT disabled
2. kernel 2.4.22 + latest PaX, with your .config

PostPosted: Sat Sep 13, 2003 2:49 pm
by devastor
I am going to boot to kernel 2.4.22 and grsec 1.9.12 probably next week.
I guess 1.9.12 has latest PaX too, so then we will see.

I guess I can compile a kernel with KERNEXEC/EMUSIGRT disabled on a test-server,
but It's quite difficult to test that because i still haven't figured out when exactly that
error occurs.. I've let the connection timeout at different stages, but no luck yet.
need to look at the source code of vsftpd when i have time.

PostPosted: Sat Sep 13, 2003 6:33 pm
by PaX Team
devastor wrote:I guess 1.9.12 has latest PaX too, so then we will see.
there is a reason i asked for testing with PaX and not grsec: i'd like to determine whether the problem is in PaX itself or grsec before i spend too much time reading the code ;-). for now i could not reproduce the error under PaX, nor do i see how the circumstances can occur that lead to this error, so i must be missing some important piece of info.

PostPosted: Sun Sep 14, 2003 6:34 am
by devastor
Ah, well that need to be tested on the test-server then, too..
I'll see what I can do :)

PostPosted: Wed Sep 17, 2003 4:36 pm
by devastor
Ok i was now able to reproduce the problem with
2.4.22 + grsec 1.9.12.
That happens if the remote end stops responding while transfering files
(Like when I send a SIG_STOP to the ftp client) and then let the connection time out.

i'll now do those two tests you asked for..

PostPosted: Wed Sep 17, 2003 5:12 pm
by devastor
seems to happen also with the above kernel KERNEXEC/EMUSIGRT disabled.
Will try 2.4.22 + newest Pax tomorrow.

PostPosted: Sat Sep 20, 2003 11:24 am
by devastor
OK it happens with 2.4.22 + newest_pax, too.

I tested it with different options and came to the conclusion that It happens
when Paging or Segmentation based PAGE_EXEC AND randomized ET_EXEC
base are enabled for vsftpd-binary.

So maybe it's a false attack detection caused by randomized ET_EXEC base..

PostPosted: Sat Sep 20, 2003 3:48 pm
by PaX Team
devastor wrote:So maybe it's a false attack detection caused by randomized ET_EXEC base..
aha, you didn't tell me before that RANDEXEC was enabled on vsftpd as well ;-), so i didn't even think of it. one thing i don't understand is why i could not reproduce it here (i did try RANDEXEC as well), probably the stack layout produced by your gcc is slightly different from mine (i have 2.95.3).