Hi,
When using fetchmail+SSL (openssl 0.9.5a) over stunnel on a Linux 2.2.17
box (glibc 2.1.3, egcs 2.91.66) with libsafe 1.3, more often than not
libsafe detects a memcpy() overflow by fetchmail. It seems to only happen
when there are messages to be downloaded, and then perhaps 8 out of 10
times. Originally I thought it was a fetchmail problem, but ESR seems to
think it's a bug in my SSL implementation.
Here's the relevant output from `ltrace fetchmail`:
memchr("+OK Mailbox scan listing follows"..., '\n', 129) = 0xbfff9371
__errno_location() = 0x401cdd60
memcpy(0xbfff9350, "+OK Mailbox scan listing follows"..., 34) = 0xbfff9350
setitimer(0, 0xbfff931c, 0, 0xbfff9588, 3) = 0
strcpy(0xbfff9588, "Mailbox scan listing follows") = 0xbfff9588
setitimer(0, 0xbfffb578, 0, 0xbfffb5b0, 3) = 0
memcpy(0xbfffb5b0, "1 4417\r\n2 4236\r\n3 1230\r\n4 3668\r\n"...,
95Detected an attempt to write across stack boundary.
Terminating /usr/local/bin/fetchmail.
Null message body; hope that's ok
<unfinished ...>
--- SIGCHLD (Child exited) ---
+++ exited (status 1) +++
And here's what ESR has to say about it:
> OK, it's pretty clear what's going on here. The clue is the setitimer()
> call just before the overflow. That means that the bad memcpy() is happening
> inside SockRead() -- relevant code is near driver.c:447 right at the beginning
> of the do loop. The SockRead code itself doesn't contain a memcpy() call..
> but when SSL support is configured it calls SSL_* functions which doubtless
> do some buffer shuffling.
>
> Looks to me like you've found a buffer-overrun bug in your SSL library.
The only SSL_* functions I find in fetchmail's SockRead() are SSL_peek and
SSL_read. Have these been audited for buffer overruns in the memcpy
calls?
Thanks,
Javier
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
