Need help on 2.0.28.31 linux server

[Lange]

Not for me!

I still get the damn segmentation fault and no coredump which would help finding the real problem.

Meanwhile i think that this problem is libc related. Because shortly before these problems came i did update the system.

This time glibs and other libraries were updated so i guess that this seg fault might be an incompatiblity TS2 ./. LibC.

Simon

[nwerensteijn]

Very possible.

Some info would be nice..
Linux distro, kernel version, libc version

[R. Ludwig]

aehm niels..

remember the german post ? german forum ?

:P

[Renegat3]

.31 runs fine on the fli4l-System. Haven't heard of any probs from other fli-Users - yet!
The only prob is still the "Error stating daemon. Aborted"-Message on some Systems.
Seems to depend on the used hardware!
For the "segmentation fault" - I use the files of the glibc-2.2.5 for the fli4l-package, which works great!

Stephan

[Lange]

Originally posted by N. Werensteijn
Very possible.

Some info would be nice..
Linux distro, kernel version, libc version

Detailed information here: http://www.teamspeak.org/forums/show...&threadid=2601

Distribution: RedHat 7.2 EN FULL Most recent updates
Kernel Version 2.4.9-34 Enterprise (34 is the redhat specific subversion)
libc versions (rpm packages):
compat-glibc-6.2-2.1.3.2
glibc-profile-2.2.4-31
glibc-2.2.4-31
glibc-devel-2.2.4-31
glibc-common-2.2.4-31

well as i siad more details in the thread i have linked above.

regards

Simon

[Renegat3]

Well, as I mentioned above - use glibc-2.2.5.
I remember some probs depending on 2.2.4. So give it a try, it might solves!

Good luck...
Stephan

[nwerensteijn]

my working info:
gentoo 1.4
2.4.19 kernel

niels_dev@cc21338-a runtime $ ldd server_linux
libpthread.so.0 => /lib/libpthread.so.0 (0x00139000)
libdl.so.2 => /lib/libdl.so.2 (0x0014f000)
libc.so.6 => /lib/libc.so.6 (0x00153000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00110000)

execve("./server_linux", ["./server_linux"], [/* 34 vars */]) = 0
brk(0) = 0x81c96bc
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x126000
open("/etc/ld.so.preload", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=70072, ...}) = 0
old_mmap(NULL, 70072, PROT_READ, MAP_PRIVATE, 3, 0) = 0x127000
close(3) = 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2 00D\0"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=105551, ...}) = 0
old_mmap(NULL, 86880, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x139000
mprotect(0x147000, 29536, PROT_NONE) = 0
old_mmap(0x147000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xd000) = 0x147000
close(3) = 0
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3 24\34"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=14550, ...}) = 0
old_mmap(NULL, 12456, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x14f000
mprotect(0x151000, 4264, PROT_NONE) = 0
old_mmap(0x151000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x151000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0t\ 227\1"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1402939, ...}) = 0
old_mmap(NULL, 1216544, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x153000
mprotect(0x272000, 40992, PROT_NONE) = 0
old_mmap(0x272000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x11e000) = 0x272000
old_mmap(0x278000, 16416, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x278000
close(3) = 0
munmap(0x127000, 70072) = 0
getrlimit(0x3, 0x7ffff75c) = 0
setrlimit(RLIMIT_STACK, {rlim_cur=2044*1024, rlim_max=RLIM_INFINITY}) = 0
getpid() = 10134
uname({sys="Linux", node="cc21338-axxxxxxx", ...}) = 0
rt_sigaction(SIGRTMIN, {0x141984, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x141a24, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0x141b40, [], 0x4000000}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0x7ffff564, 32, (nil), 0}) = 0
brk(0) = 0x81c96bc
brk(0x81c96ec) = 0x81c96ec
brk(0x81ca000) = 0x81ca000
dup(1) = 3
fcntl64(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat64(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x127000
_llseek(3, 0, 0x7ffff56c, SEEK_CUR) = -1 ESPIPE (Illegal seek)
old_mmap(NULL, 65535, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = 0
readlink("/proc/self/exe", "/home/niels_dev/projects/teamspeak 2/runtime/server_linux", 4096) = 57
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/gconv/gconv-modules", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=43131, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x128000
read(4, "# GNU libc iconv configuration.\n"..., 4096) = 4096
brk(0x81cb000) = 0x81cb000
brk(0x81cc000) = 0x81cc000
read(4, "2\n\nalias\tISO-IR-141//\t\tJUS_I.B1."..., 4096) = 4096
brk(0x81cd000) = 0x81cd000
brk(0x81ce000) = 0x81ce000
read(4, "SF00010003//\t\tISO-8859-3//\nmodul"..., 4096) = 4096
brk(0x81cf000) = 0x81cf000
read(4, "/\nalias\tLATIN8//\t\tISO-8859-14//\n"..., 4096) = 4096
brk(0x81d0000) = 0x81d0000
brk(0x81d1000) = 0x81d1000
<cut>


I am still a linux newbie :P
But what is libsafe ?

from you:
open("/etc/libsafe.exclude", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40020000
read(3, "/etc/tss2/server_linux\n", 4096) = 23
read(3, "", 4096) = 0

I am not sure but i dont think we look in "/etc/tss2/server_linux" (correct me if im wrong ralf)

[Lange]

What libsafe is? Well im sure you know that most attacks on linux services are based on bufferoverruns. Means dangerous code will be send and executed and if the attacker has success he can execute this code on the host.

Libsafe intercepts these attacks as good as it can. a comon admin will update dangerous packages with fixe version (openssl, wuftp, xinetd,...) but there is always a time between detecting the bug and release of updates. this delay is a dangerous time for any administraor. HERE comes libsafe.

libsafe will be used by ANY application,daemon whatsoever. as you could see even TS first jumps to libsafe. libsafe now looks if TS2 is enlisted in the exclude list. if so id just jumps to the libs and nothing happens. if TS2 is not enlisted then it will check in realteime ANY function which uses libc or other libraries for security holes. -> pretty effective.
At a customers server we had such a case: a wannabehacker used a securityhole in wuftp and gained superuserrights. once he tried to open a shell BANG he was out. then he tried it again with sum other tools so he uploaded rootshell and tried to install it. the second he tried to start rootshell - BANG process were killed again and was logged again in /var/log/secure...
if you want more information : http://www.research.avayalabs.com/project/libsafe/

I have tested so far without libsafe at all, libsafe 1.3 and libsafe 2.0.16. the libsafe team themself tested TS2 with 2.1.5 (will be released next time) .

well on my side it was always the same since i have updated my system via up2date --nox -u (which caused also sum important glibc updates beside of xinetd which had a security hole) TSS2 does not work anymore.

on the other hand the libsafe team tested on three different systems TSS2 und had no trouble with libsafe enabled. so i guess meanwhile this is not actually a libsafe related bug but it is in fast sum kind of incompatiblity between tss2 and libc... well as i said before its so sad that there is no coredump otherwise we would know more...

regards

Simon
PS: Hope i helped ya

[Lange]

Originally posted by Renegat3
Well, as I mentioned above - use glibc-2.2.5.
I remember some probs depending on 2.2.4. So give it a try, it might solves!

Good luck...
Stephan

2.2.5 is not released by Redhat for v7.2 so i wont install it. also please notify that version by the GLIB team are not equal to version from redhat. im pretty sure that 2.2.4-31 is at least that stable and "bugfree" as 2.2.5 from the original team. But who knows.. In fact i cannot update to 2.2.5 becuase it does not exist as an official update

regards

Simon

[nwerensteijn]

Thax for the explination.
Ok lets see if 2.2.5 works better for you.

[Lange]

Originally posted by N. Werensteijn
Thax for the explination.
Ok lets see if 2.2.5 works better for you.

there is no 2.2.5 for redhat 7.2 so i wont know