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
