bugtraq - Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Tue, 28 Mar 2006 09:36:32 +0200
From: Casper.Dik@....COM
To: Florian Weimer <fw@...eb.enyo.de>
Cc: Theo de Raadt <deraadt@....openbsd.org>,
	Martin Schulze <joey@...odrom.org>, bugtraq@...urityfocus.com
Subject: Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)

>* Theo de Raadt:
>
>> What if we ignore your procedures?  What if we say no?
>
>You won't be told about bugs in the code you write.  It's as simple as
>that.
>
>But I don't quite understand why Gadi is so thoroughly offended by the
>way how this vulnerability has been handled so far.  The patches might
>be obscure, but at least there are official patches for older
>versions, too.  And there is an official advisory.  It could be far
>worse.  The programmers of a rather popular kernel do not publish
>advisories at all, for instance.

I don't quite understand the complaints about "obscure" patches;
intricate bugs require elaborate patches; it's not a one line
sprintf->snprintf change that is easy to understand.

Because of the way the bug was addressed, ripping out setjmp/longjmp,
a lot of change is needed which is not immediately obvious.

But such is the nature of complicated bug fixes; sometimes one also needs
to rewrite parts in a more natural way or code will become increasingly
"patchy" and less maintainable.

Casper