[21006] in bugtraq
Re: lil' exim format bug
daemon@ATHENA.MIT.EDU (Tabor J. Wells)
Wed Jun 13 18:48:41 2001
Date: Tue, 12 Jun 2001 22:45:57 -0400
From: "Tabor J. Wells" <twells@fsckit.net>
To: Foldi Tamas <crow@kapu.hu>
Cc: bugtraq@securityfocus.com, lez@sch.bme.hu, exim-users@exim.org
Message-ID: <20010612224557.A9499@fsckit.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <992339134.21746.2.camel@DarkSun>
On Tue, Jun 12, 2001 at 11:45:34AM +0200,
Foldi Tamas <crow@kapu.hu> is thought to have said:
> Hi Bugtraqers,
>
> All of the downloadable versions are still buggy, and I can't understand
> why does it recommend the main-main-developer to paste '%s' into the
> source code.
>
> The following patch should work against this ugly format bug:
>
> --- accept.c.orig Tue Jun 12 11:33:01 2001
> +++ accept.c Tue Jun 12 11:33:38 2001
> @@ -2503,7 +2503,7 @@
> nothing on success. The function moan_smtp_batch() does not return -
> it exits from the program with a non-zero return code. */
>
> - else if (smtp_reply != NULL) moan_smtp_batch(NULL, smtp_reply);
> + else if (smtp_reply != NULL) moan_smtp_batch(NULL, "%s", smtp_reply);
> }
>
> /* Reset headers so that logging of rejects for a subsequent message
> doesn't
The author has stated on the exim-users mailing list that this is the
correct patch to resolve this problem. It'll be rolled into the next
release, 3.30, which is expected out shortly.
> ><sarcasm>
> >Why, thank you for letting Philip Hazel (who is on holiday right now)
> >get a patched version out before announcing this to bugtraq.
> ></sarcasm>
>
> At the moment, we know another 'ugly' bug in the exim main code, but
> because of your tone it's not published. I can't understand, why do you
> use this tone against people, who audits your shity code, which has some
> errors in it.
Gee. The original poster did not contact the author or the mailing list
about the problem but instead went straight to bugtraq and security-l
which runs counter to the widely used standards for vendor notification
like RFPolicy. This, justifiably, upsets some of the users of Exim. Now
you state you are aware of another problem in the Exim source but have
not, and apparantly will not, tell anyone about it. I'm not sure what your
agenda is but it's clear that it is not about helping to fix security
bugs.
If the code is so "shity", then I'd think you'd want to point out
all of the ways in which it is lacking and submit patches to address those
deficiencies.
Tabor
--
--------------------------------------------------------------------
Tabor J. Wells twells@fsckit.net
Fsck It! Just another victim of the ambient morality
