[<prev] [next>] [day] [month] [year] [list]
Message-Id: <20130520174343.6489CE673F@smtp.hushmail.com>
Date: Mon, 20 May 2013 17:43:40 +0000
From: "mancha" <mancha1@...h.com>
To: oss-security@...ts.openwall.com
Subject: tty-hijacking & CVE-2005-4890 - redux
Hello.
A recent use-case on Slackware made me re-visit CVE-2005-4890
in the context of "su -c". Particularly, shadow's implementation
as of shadow 4.1.5.
During the discussions of this CVE (see footer links), it was
pointed out shadow's fix is partial given interactive su remains
vulnerable to tty-hijacking. It was also mentioned this vector
is less worrisome given use cases for interactive su are primarily
privilege escalation.
The CVE was always a bit controversial with many believing
using su and sudo to drop privileges is unsafe and more an
administration issue than a design flaw.
All that said, at the very least would it be reasonable to
apply the same threat-assessment criterion to the crippling
of "su -c" and not drop the controlling tty for the case when
the callee is root?
Slackware doesn't use PAM so the fix in shadow relies on a
TIOCNOTTY ioctl() request and not a setsid() call. One result
of this change is summarized in the table below:
shadow
4.1.4.3 4.1.5.1 4.1.5.1+patch*
1. As unpriv user user1:
xterm -e su -c $COMM SUCCESS FAIL SUCCESS
xterm -e su user2 -c $COMM SUCCESS FAIL FAIL
2. As root:
xterm -e su user1 -c $COMM SUCCESS FAIL FAIL
-----
* See attached
Cheers.
--mancha
===
[1] http://thread.gmane.org/gmane.comp.security.oss.general/5172
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628843
Download attachment "shadow-4.1.5.1-tty.diff" of type "application/octet-stream" (321 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
