calc.c, from jwa's sendmail exploit script

[mouse () collatz mcrcim mcgill edu (der Mouse)]

> This program uses "calc.c," the program mentioned by Timothy Newsham
> in an earlier message.  The program has been modified slightly so
> that it gives better results (it would occasionally fail to locate
> the offset of a config given a buggy sendmail.  The fix is to force a
> sync() after it generates a coredump.)

Actually, that's not the right fix.  The problem is that...

> gencore()
> {
[...fork, exec sendmail, send it signal 11...]
> }

> main(argc,argv)
> char **argv;
> int argc;
> {
>   unsigned int ConfFile,tTdvect,off;
>   
>   gencore();
>   sync();   /* grr. */
>   tTdvect = find("ZZZZZZZZ", "core");
>   ConfFile = find(argv[1], "core");

...that nothing is done to ensure that the coredump is finished by the
time find() opens it to look for the magic pattern.  gencore() returns
only moments after sending the signal.  You're just lucky that on the
systems you tried, the sync() either blocks waiting for the coredump to
complete or takes long enough for it to complete.  The right fix is for
gencore() to do a wait() on the child process, to wait for it to go
away after completing the coredump.

ObBugQ: Anyone know just what the SPARC integer divide bug is?  I've
got copies of the relevant kernel .o files both before and after the
patch, but haven't gotten around to disassembling and uncompiling
enough to figure out what's wrong yet.

                                        der Mouse

                            mouse () collatz mcrcim mcgill edu