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) [] (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


-------------- 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