Bug#285554: [Pkg-nagios-devel] Bug#285554: acknowledged by developer
(check_smtp update)
sean finney
seanius at debian.org
Mon Oct 10 07:13:18 UTC 2005
On Mon, Oct 10, 2005 at 02:13:27AM +0200, Jeroen van Wolffelaar wrote:
> > i'm still not quite happy with that last one, as gethostbyname isn't
> > defined by posix/sus/iso, but it's being used elsewhere in the
> > code base already, so oh well.
>
> As long as Debian supporst it across all architectures... But yeah, something
> for upstream to generalize if possible.
yeah. i guess i tend to keep that in mind, as i'm also on the
upstream development team :) but since they were using gethostname
already in the code... whatever.
> Anyway, it doesn't work yet over here completely. I get a segmentation fault
> in the call to SSL_CTX_free(ctx).
sounds like some error checking isn't catching the ssl connection not
being properly established.
> Feel free to use mail.wolffelaar.nl as test SMTP server as much as you like,
> by the way. It's default sarge exim4 with TLS enabled, otherwise nothing
> really special that should be relevant for this check.
cool, thanks. i suspect that it actually is relevant though, as i see
something later on about gnutls, and istr reading another bug report
about openssl extensions causing problems in non-openssl environments.
don't know it well enough to know whether or not that could be the
case here though, i'll look into it.
> #0 0x40072f77 in SSL_SESSION_hash () from /usr/lib/i686/cmov/libssl.so.0.9.8
> #1 0x401272c7 in lh_delete () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
> #2 0x400773d8 in SSL_CTX_get_timeout () from /usr/lib/i686/cmov/libssl.so.0.9.8
> #3 0x40126f34 in lh_doall_arg () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
> #4 0x4007750e in SSL_CTX_flush_sessions () from /usr/lib/i686/cmov/libssl.so.0.9.8
> #5 0x400730cc in SSL_CTX_free () from /usr/lib/i686/cmov/libssl.so.0.9.8
> #6 0x08049777 in my_close () at check_smtp.c:759
> #7 0x08049813 in connect_STARTTLS () at check_smtp.c:655
> #8 0x0804a7ae in main (argc=3, argv=0xbffffaf4) at check_smtp.c:236
probably freeing something that was never successfully allocated.
> I also see no code doing a QUIT over the TLS'd connection, or for that matter,
> anything. I don't think that'd really be needed though, it's definitely not in
> the scope of the original check_smtp... Though I guess it's actually going to
> cause a log entry (exim tends to log "connection closed unexpectedly" if there
> is no QUIT). Currently my logs for the SEGV'ing check_smtp say:
it will send a QUIT if told to do starttls and the server doesn't
support it, or at the end of the SMTP conversation (independant of
whether the connection is SSL-enabled). iirc SMTP requires the
client send a quit before closing the connection. the one place it
doesn't do a QUIT is if there's an error with connect_STARTTLS,
but that's because there's been some application error and
the connection/encryption is in a rather undefined state.
> 2005-10-10 02:11:13 TLS error on connection from 22pc220.sshunet.nl
> (bla.wolffelaar.nl) [145.97.220.22] (gnutls_handshake): Could not negotiate a
> supported cipher suite.
probably an openssl/gnutls thing. i don't know a lot about openssl,
but i'm guessing some SSL_get/set_cipher_list might resolve that.
> > + localhostname = malloc (HOST_MAX_BYTES);
> > + gethostname(localhostname, HOST_MAX_BYTES);
>
> Hm, if gethostname fails, you end up with a bogus localhostname, but you don't
> detect that and continue anyway. Fwiw, this was already present in the old
> code too. Now fortunately nobody but root can set the hostname... Or it'd be a
> security hole.
i'll put some more error checking in there. out of curiosity though,
how can calling gethostname set the hostname?
> check_smtp.c:134: warning: unused variable 'ehlo_resp'
> check_smtp.c:131: warning: unused variable 'amt_read'
my bad, was from earlier hacking attempts
sean
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-nagios-devel/attachments/20051010/3f3d7186/attachment.pgp
More information about the Pkg-nagios-devel
mailing list