Re: sendmail wizard thing...

[smb () research att com (smb () research att com)]

         > years ago, hence my assumption.  then again, i recently spotted an o
        ld
         > sendmail hole ("wizard") at a site, so one can never really assume a
        nything,

         That reminds me... browing the results of running the uksm
         config stuff (2.1) I noticed the Wizards password entry in
         sendmail.cf. I've scaned all the docs I've got and I'm still
         ignorant - so what is it for? Can I simply remove it?

Yes, you can remove it.

The story of the ``wizard'' hole is quite interesting; it's a good
lesson in how the interaction of features can cause truly horrendous
results.

Sendmail uses large and truly horrendous configuration files.  Everything,
it seems, can be tweaked that way.  In older versions, to avoid the
overhead of reading and parsing that mess each time, there was something
known as a ``frozen'' configuration file.  (Some vendors still support
it, btw; Eric Allman has quite rightly removed that feature from recent
releases.)  The frozen configuration file was intended as just a compiled
version; as such, there's nothing wrong with the concept.  But it was
implemented in a very unclean fashion.  And to understand it, it's
necessary for me to digress and review the structure of a executable
program in UNIX.

Executable files are composed of three sections:  text, data, and bss.
Text is the actual machine code, initialized variables are in the data
section, while bss is used for variables which are not explicitly
initialized by the (C language) programmer; by definition of the language,
these must be set to zero, so UNIX clears the bss area before transferring
control to the program.  Note that the bss area does not take up any
space in the file.

Finally, when executing, programs can allocate memory dynamically using
the sbrk() system call (to which malloc() is the usual interfac).  This
area resides immediately above the bss area in memory, at least in classic
versions of UNIX.

When sendmail read in its configuration file, dynamic storage was used
to hold all of the necessary data structures.  The configuration file was
frozen by writing out the bss area and the currently-allocated dynamic
memory area.  (Yes, this is horribly compiler- and system-dependent.
And yes, other things, such as stdio's data structures and buffers were
written out as well.  See my editorial comments above.)

As I recall -- and it's been a fair number of years -- the wizard mode
feature was implemented by two variables, a flag saying that there was
a password (and hence that the feature was to be enabled), and a pointer
to the hashed password that was read from the configuration file.
The crucial bug was in the declaration of the pointer to the hashed
password:

        char *wizpw = NULL;

It was explicitly initialized, albeit to 0 -- and as such, it resided in
the data area, not the bss area.  It was thus not written out to the
frozen configuration file.  When sendmail was running in its normal
production state, it appeared that wizard mode was enabled -- the flag
was in the frozen section -- but that there was no password.  Anyone
who connected to the mailer port could type ``wiz'' and get all sorts
of privileges, notably an interactive shell.

But when the code was being developed, the password was tested -- and
it worked.  After all, you test code when you add it, and you can't use
an old frozen config file when you've just recompiled; the bss area layout
is different.  So the wizard mode password always worked in testing, but
never in production.