Hi all, I'd like to set up an encrypted access to imap using ssl. I installed the sslwrap package of suse 7.0, and installed it according to the instructions in /usr/share/doc/packages/sslwrap/README.SuSE. However, if somebody tries to connect, I get an error message in the syslog: Dec 10 16:21:39 mango sslwarp[16004]: error: cannot execute /usr/sbin/sslwarp: I tried to start the program by hand (/usr/sbin/sslwarp -cert /usr/ssl/certs/raspberry_internal.pem -port 143 -accept 993), this time I get a similar error:
bash: /usr/sbin/sslwarp: No such file or directory However, if I start the program from within gdb, everything works fine. (It is an unstripped ELF executable, BTW).
What is wrong with it? Is it my fault? Or is there some memory uninitialized in this program? Thanks for your help in advance. :-) Gordon.
On Mon, 11 Dec 2000, someone (possibly Gordon F. Cichon) said: //snip
I installed the sslwrap package of suse 7.0, and installed it according to the instructions in /usr/share/doc/packages/sslwrap/README.SuSE. //snip
which probably did not include this minor detail:
/usr/sbin/sslwarp ^^^^ warp != wrap ... by now you have fixed this, haven't you ...?
&:-)
Sorry, that was a typo. Sure, I said sslwrap. As I said, the program runs fine when started from within the debugger. But I can't run sslwrap/gdb from within inetd. Also, sslwrap is intended to make the thing secure, and this behaviour isn't very promising, is it? Gordon. Andrew McGill wrote:
On Mon, 11 Dec 2000, someone (possibly Gordon F. Cichon) said:
//snip
I installed the sslwrap package of suse 7.0, and installed it according to the instructions in /usr/share/doc/packages/sslwrap/README.SuSE. //snip
which probably did not include this minor detail:
/usr/sbin/sslwarp ^^^^ warp != wrap ... by now you have fixed this, haven't you ...?
Sorry, that was a typo. Sure, I said sslwrap. As I said, the program runs fine when started from within the debugger. But I can't run sslwrap/gdb from within inetd. Also, sslwrap is intended to make the thing secure, and this behaviour isn't very promising, is it?
Gordon.
It smells like a shared library is missing. Cryptic, I know, it could at least say so. Strange, though, since it isn't linked against something special. This is what it looks like on my SuSE-7.0 system: for i in ldd file "ls -la"; do $i /usr/sbin/sslwrap;done libc.so.6 => /lib/libc.so.6 (0x40023000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/sbin/sslwrap: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped -rwxr-xr-x 1 root root 760575 Jul 12 04:10 /usr/sbin/sslwrap The ldd command most likely fails. If so, use strace to see what happens. Repeat it after running `ldconfig´ as root. Try `rpm -V sslwrap´. Output means removal and reinstallation of the package. Thanks, Roman. -- - - | Roman Drahtmüller <draht@suse.de> // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -
Roman Drahtmueller wrote:
Sorry, that was a typo. Sure, I said sslwrap. As I said, the program runs fine when started from within the debugger. But I can't run sslwrap/gdb from within inetd. Also, sslwrap is intended to make the thing secure, and this behaviour isn't very promising, is it?
It smells like a shared library is missing. Cryptic, I know, it could at least say so. Strange, though, since it isn't linked against something special.
This is what it looks like on my SuSE-7.0 system:
for i in ldd file "ls -la"; do $i /usr/sbin/sslwrap;done libc.so.6 => /lib/libc.so.6 (0x40023000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/sbin/sslwrap: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped -rwxr-xr-x 1 root root 760575 Jul 12 04:10 /usr/sbin/sslwrap
The ldd command most likely fails. If so, use strace to see what happens. Repeat it after running `ldconfig´ as root.
Try `rpm -V sslwrap´. Output means removal and reinstallation of the package.
Hi Roman, yes, a missing library was also the first thing I thought. However, (1.) the ldd command you mentioned works.
ldd /usr/sbin/sslwrap libc.so.6 => /lib/libc.so.6 (0x40026000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) (2.) the program works perfectly fine when started from the debugger. I did : echo set args -cert /usr/ssl/certs/cert.pem -port 143 -accept 993 \
.gbdinit gdb /usr/sbin/sslwrap (gdb) run This works!
So, I assume that there is some unitialized memory in this program. Gdb clears all allocated memory before use which in the runtime does not happen. This is a common cause if program fail only without debugger. Gordon.
participants (3)
-
Andrew McGill -
Gordon F. Cichon -
Roman Drahtmueller