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] [thread-next>] [day] [month] [year] [list]

Date: Fri, 24 Mar 2006 10:39:30 -0700
From: Theo de Raadt <deraadt@....openbsd.org>
To: Claus Assmann <ca+bugtraq@...doc.endmail.org>
Cc: bugtraq@...urityfocus.com
Subject: Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)

> Ask ISS about the exploit. It definitely is a programming bug,
> just read the man page for setjmp() on an OpenBSD system.

Claus is talking about this particular piece of text which we added to
our setjmp(3) manual page in late 2001:

CAVEATS
     [...]

     Use of longjmp() or siglongjmp() from inside a signal handler is not as
     easy as it might seem.  Generally speaking, all possible code paths be-
     tween the setjmp() and longjmp() must be signal race safe, as discussed
     in signal(3).  Furthermore, the code paths must not do resource manage-
     ment (such as open(2) or close(2)) without blocking the signal in ques-
     tion, or resources might be mismanaged.  Obviously this makes longjmp()
     much less useful than previously thought.

We came to a generic realization of the above concern as we were
auditing our source tree for signal handler issues, and thus we
documented it in the manual page so that all could see.

We were in the process of trying to clean up all of the signal
handlers in our entire source tree.  A few still remain, as they were
just too bizzare or difficult to change without potentially breaking
something.  This was one of them.  We knew the risk was there, but
what could we do...

This keeps happening, and I suppose, will keep happening.  People used
to think that just blindly replacing strcpy() with strncpy() was safe.
That number * sizeof(item) was a safe idiom in all cases.  These
things add up, and we learn more.  64 bit long's are making our life
harder, too.  The C standard has not helped us because it is broken
with regards to type casting.  We attempt to document some of these
issues in our manual pages.  Like the way people continually misuse
realloc()...

I specifically urge people to go read the OpenBSD signal(3) manual
page for more issues to worry about:

	http://www.openbsd.org/cgi-bin/man.cgi?query=signal