(e pelo que eu me lembre, um especialista, a não muito tempo atrás, varreu o openbsd em algumas horas e encontrou umas duas duzias de vulnerabilidades sérias….Realmente, openbsd é Muito seguro, aliás, como toda obra feita pelos seres humanos..
:)
)

—-

Subject: Postfix local privilege escalation via hardlinked symlinks
To: Postfix announce
Date: Thu, 14 Aug 2008 08:05:28 -0400 (EDT)
CC: Postfix users
X-Time-Zone: USA EST, 6 hours behind central European time
X-Mailer: ELM [version 2.4ME+ PL82 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Message-Id:
From: wietse@porcupine.org (Wietse Venema)
Sender: owner-postfix-announce@postfix.org
Precedence: bulk
List-Post:
List-Help:
List-Unsubscribe:
List-Subscribe:

Summary: Solaris and Linux file system behavior has changed over
time, breaking one of the assumptions in Postfix. See below for a
description of the behavior and how it disagrees with standards.

Postfix is not affected on systems with standard (POSIX, X/Open)
file system behavior, i.e. *BSD, AIX, MacOS, HP-UX, and very old
Sun/Linux systems. The fix and workarounds are simple.

There are efforts to get the non-standard behavior approved by
standards (a function called llink). Today’s fix for Solaris, Linux
etc. also makes Postfix future-proof for such changes.

Wietse

1. Postfix local privilege escalation via hardlinked symlinks
=============================================================
Sebastian Krahmer of SuSE has found a privilege escalation problem.
On some systems an attacker can hardlink a root-owned symlink to
for example /var/mail, and cause Postfix to append mail to existing
files that are owned by root or non-root accounts. This can happen
on operating systems with specific non-standard behavior.

Symlinks (symbolic links) implement aliasing for UNIX pathnames.
They were introduced with 4.2BSD UNIX in 1983, and were adopted by
other UNIX systems in the course of time. Hardlinks are older and
implement the primary mechanism for accessing file system objects.

In some UNIX systems, the link(symlink, newpath) operation has
changed over time: instead of recursively following the symlink and
creating a hardlink to the file thus found, it creates a hardlink
to the symlink itself. This behavior disagrees with, for example,
the POSIX.1-2001 and X/Open XPG4v2 standards, and is the default
on current Solaris, IRIX and Linux systems. On systems with this
non-standard behavior, Postfix may be vulnerable depending on how
it is configured.

Postfix allows a root-owned symlink as a local mail destination,
so that mail can be delivered to e.g. /dev/null which is a symlink
on Solaris.

2. What configurations are (not) affected
=========================================
A configuration is considered affected when an attacker with local
access to a system can make Postfix append mail to an existing file
of a different user. Appendix A gives a procedure to determine if
a system is affected.

The following configurations are NOT affected: Postfix on FreeBSD
7.0, OpenBSD 4.3, NetBSD 4.0, MacOS X 10.5, AIX 5.3, HP-UX 11.11,
Solaris 1.x, Linux kernel 1.2.13, and other systems with standard
hardlink behavior. However, these systems may become affected when
they share file systems with hosts where users can create hardlinks
to symlinks.

Also not affected are the following configurations: a) maildir-style
delivery with the Postfix built-in local or virtual delivery agents;
b) mail delivery with non-Postfix local or virtual delivery agents;
c) mailbox-style delivery with the Postfix built-in virtual delivery
agent when virtual mailbox parent directories have no “group” or
other write permissions.

The following configurations are known to be affected on Linux
kernel >= 2.0, Solaris >= 2.0, OpenSolaris 11-2008.5, IRIX 6.5, and
other systems where users can create hardlinks to symlinks: a)
mailbox-style delivery with the Postfix built-in local delivery
agent; b) mailbox-style delivery with the Postfix built-in virtual
delivery agent when virtual mailbox parent directories have “group”
or other write permissions.

3. Solution
===========
If your system is affected, upgrade Postfix, apply the patch in
Appendix C, or apply one of the countermeasures in section 4.

Updated versions will be made available via http://www.postfix.org/
for Postfix versions 2.3, 2.4, 2.5, and 2.6. Individual vendors
will provide updates depending on their support policy.

4. Countermeasures
==================
Each of the following countermeasures will prevent privilege
escalation through Postfix via hardlinked symlinks:

1) Protect mailbox files (maildir files are not affected). The
script in Appendix B makes sure that the system mail spool directory
is owned by root, that the sticky bit is turned on, and that each
UNIX account has a mailbox file; it also has suggestions for virtual
mailbox file deliveries (again, maildir files are not affected).

2) Don’t allow non-root users to create hardlinks to objects of
other users. This behavior is configurable on some systems.

Appendix A: Procedure to find out if a system is affected
=========================================================
As mentioned in section 2, not affected are maildir-style delivery
with the Postfix built-in local or virtual delivery agents, mail
delivery with non-Postfix local or virtual delivery agents, and
mailbox-style delivery with the built-in Postfix virtual delivery
agent when virtual mailbox parent directories have no “group” or
other write permissions.

To find out if a system may be affected, execute the following
commands as non-root user on a local file system:

$ PATH=/bin:/usr/bin:$PATH
$ mkdir test
$ cd test
$ touch src
$ ln -s src dst1
$ ln dst1 dst2
$ ls -l

For the test to be valid, all commands should complete without error.

The system is NOT affected when “ls -l” output shows one symlink
(dst1 -> src) and two files (dst2, src) as in example A.1.

Example A.1:
lrwxr-xr-x 1 user users 3 Mmm dd hh:mm dst1 -> src
-rw-r–r– 2 user users 0 Mmm dd hh:mm dst2
-rw-r–r– 2 user users 0 Mmm dd hh:mm src

However, the system may become affected when it shares file systems
with hosts where users can create hardlinks to symlinks as described
next.

The system is affected when “ls -l” output shows two symlinks and
one file as in example A.2, with the following Postfix configurations:
a) mailbox-style delivery with the Postfix built-in local delivery
agent; b) mailbox-style delivery with the Postfix built-in virtual
delivery agent when virtual mailbox parent directories have “group”
or other write permission.

Example A.2:
lrwxrwxrwx 2 user users 3 Mmm dd hh:mm dst1 -> src
lrwxrwxrwx 2 user users 3 Mmm dd hh:mm dst2 -> src
-rw-r–r– 1 user users 0 Mmm dd hh:mm src

Appendix B: Procedure to protect mailbox files
==============================================
This section describes one of the countermeasures (see section 4)
that eliminate the problem without updating Postfix.

The Perl script below hardens systems that use mailbox-style
deliveries with the Postfix built-in local delivery agent; it makes
sure that the system mailspool directory is root-owned and sticky,
and that every UNIX account has a mailbox file. The script assumes
that mailbox files are stored under /var/mail.

Similar actions would be needed for systems that use mailbox-style
delivery with the Postfix built-in virtual delivery agent, but this
is needed only when Postfix virtual mailbox parent directories have
“group” or other write permissions. Unfortunately, an automated
script for this cannot be made available due to the large variation
between Postfix configurations.

#!/usr/bin/perl

# fix-mailspool – Make sure the mailspool directory is root-owned
# and sticky, and that every UNIX account has a mailbox file.

use Fcntl;

$debug = 0;

# Follow compatibility symlink.
$mailspool=”/var/mail/”;

chown(0, -1, $mailspool)
|| die(“can’t set root ownership for $mailspool: $!\n”);

chmod((stat($mailspool))[2] | 01000, $mailspool)
|| die(“can’t set sticky bit for $mailspool: $!\n”);

while(($name, $passwd, $uid, $gid, $quota,
$comment, $gcos, $dir, $shell) = getpwent()) {
print “user $name\n” if $debug;
$mailbox = ($mailspool . $name);
if (! -e $mailbox) {
print “create $mailbox\n” if $debug;
if (!sysopen(MAILBOX, $mailbox, (O_CREAT | O_RDWR | O_EXCL), 0600)) {
warn(“can’t create $mailbox: $!\n”);
} else {
# XXX fchown() is not portable.
chown($uid, $gid, $mailbox) || warn(“chown $mailbox: $!\n”);
close(MAILBOX);
}
} elsif (! -f $mailbox) {
warn(“$mailbox is not a regular file\n”);
} elsif ((stat($mailbox))[4] != $uid) {
warn(“$mailbox is not owned by $name\n”);
}
}

Appendix C: Source code patch
=============================
This patch is suitable for Postfix 2.0 and later. It presents the
least invasive change that eliminates the problem. Future Postfix
releases may adopt a different strategy.

The solution introduces the following change: when the target of
mail delivery is a symlink, the parent directory of that symlink
must now be writable by root only (in addition to the already
existing requirement that the symlink itself is owned by root).
This change will break legitimate configurations that deliver mail
to a symbolic link in a directory with less restrictive permissions.

*** src/util/safe_open.c.orig Sun Jun 4 19:04:49 2006
— src/util/safe_open.c Mon Aug 4 16:47:18 2008
***************
*** 83,88 ****
— 83,89 —-
#include
#include
#include
+ #include
#include

/* safe_open_exist – open existing file */
***************
*** 138,150 ****
* for symlinks owned by root. NEVER, NEVER, make exceptions for symlinks
* owned by a non-root user. This would open a security hole when
* delivering mail to a world-writable mailbox directory.
*/
else if (lstat(path, &lstat_st) st_dev != lstat_st.st_dev
— 139,167 —-
* for symlinks owned by root. NEVER, NEVER, make exceptions for symlinks
* owned by a non-root user. This would open a security hole when
* delivering mail to a world-writable mailbox directory.
+ *
+ * Sebastian Krahmer of SuSE brought to my attention that some systems have
+ * changed their semantics of link(symlink, newpath), such that the
+ * result is a hardlink to the symlink. For this reason, we now also
+ * require that the symlink’s parent directory is writable only by root.
*/
else if (lstat(path, &lstat_st) st_dev != lstat_st.st_dev

Alguém tem um link para o anúncio original do Wietse Venema?