Sendmail -- aktualni verze [Re: SPAM (podpora do sendmailu)]

[Hynek Med]

On 12 Nov 1997, Vladimír Solnický {Vladimir Solnicky} wrote:

> Jen bych doplnil, ze v rijnu byl dan do obehu 8.8.8, ale posledni znama
> bezpecnostni dira byla v 8.8.4 a byla opravena v 8.8.5, pozdejsi verze
> obsahuji jen ,,minor bux fixes`` ne bezpecnostniho charakteru.

No ani bych nerekl.

8.8.6/8.8.6     97/06/14
[..]
        SECURITY: A few systems allow an open with the O_EXCL|O_CREAT open
                mode bits set to create a file that is a symbolic link that
                points nowhere.  This makes it possible to create a root
                owned file in an arbitrary directory by inserting the symlink
                into a writable directory after the initial lstat(2) check
                determined that the file did not exist.  The only verified
                example of a system having these odd semantics for O_EXCL
                and symbolic links was HP-UX prior to version 9.07.  Most
                systems do not have the problem, since a exclusive create
                of a file disallows symbolic links.  Systems that have been
                verified to NOT have the problem include AIX 3.x, *BSD,
                DEC OSF/1, HP-UX 9.07 and higher, Linux, SunOS, Solaris,
                and Ultrix.  This is a potential exposure on systems that
                have this bug and which do not have a MAILER-DAEMON alias
                pointing at a legitimate account, since this will cause old
                mail to be dropped in /var/tmp/dead.letter.
        SECURITY: Problems can occur on poorly managed systems, specifically,
                if maps or alias files are in world writable directories.
                If your system has alias maps in writable directories, it
                is potentially possible for an attacker to replace the .db
                (or .dir and .pag) files by symbolic links pointing at
                another database; this can be used either to expose
                information (e.g., by pointing an alias file at
/etc/spwd.db
                and probing for accounts), or as a denial-of-service attack
                (by trashing the password database).  The fix disallows
                symbolic links entirely when rebuilding alias files or on
                maps that are in writable directories, and always warns on
                writable directories; 8.9 will probably consider writable
                directories to be fatal errors.  This does not represent an
                exposure on systems that have alias files in unwritable
                system directories.
        SECURITY: disallow .forward or :include: files that are links (hard
                or soft) if the parent directory (or any directory in the
                path) is writable by anyone other than the owner.  This is
                similar to the previous case for user files.  This change
                should not affect most systems, but is necessary to prevent
                an attacker who can write the directory from pointing such
                files at other files that are readable only by the owner.
        SECURITY: Tighten safechown rules: many systems will say that they
                have a safe (restricted to root) chown even on files that
                are mounted from another system that allows owners to give
                away files.  The new rules are very strict, trusting file
                ownership only in those few cases where the system has
                been verified to be at least as paranoid as necessary.
                However, it is possible to relax the rules to partially
                trust the ownership if the directory path is not world or
                group writable.  This might allow someone who has a legitimate
                :include: file (referenced directly from /etc/aliases) to
                become another non-root user if the :include: file is in a
                non-writable directory on an NFS-mounted filesystem where
                the local system says that giveaway is denied but it is
                actually permitted.  I believe this to be a very small set
                of cases.  If in doubt, do not point :include: aliases at
                NFS-mounted filesystems.
        SECURITY: When setting a numeric group id using the RunAsUser option
                (e.g., "O RunAsUser=10:20", the group id would not be set.
                Implicit group ids (e.g., "O RunAsUser=mailnull") or alpha
                group ids (e.g., "O RunAsUser=mailuser:mailgrp") worked fine.
                The user id was still set properly.  Problem noted by Uli
                Pralle of the Technical University of Berlin.
[..]
        MAIL.LOCAL: SECURITY: check to make sure that an attacker doesn't
                "slip in" a symbolic link between the lstat(2) call and the
                exclusive open.  This is only a problem on System V derived
                systems that allow an exclusive create on files that are
                symbolic links pointing nowhere.

Hynek

--
Hynek Med, xmedh02 at manes.vse.cz