On Thu, Jun 27, 2002 at 05:40:24PM +0100, Sam Vilain wrote:
> Ben Collins <email@example.com> wrote:
> > > You mean `mount --bind'? No, definitely not. `root' still needs to
> > > be able to replace the files, and it is not acceptable for one vserver
> > > to be able to alter another vserver's files in any way.
> > Then you are asking for special casing for an off-the-wall situation.
> > Removing that part of the dpkg code opens up all sorts of security
> > issues, so it cannot be bypassed.
> I'm just having a hard time seeing why you even care whether or not the
> chmod() fails or not - you're about to unlink the file!
Take this scenario:
/usr/bin/sudo is suid root. It is version 1.2. Sometime later, it is
found that version 1.2 has a locally exploitable root producing bug. The
admin needs to upgrade to 1.2.1.
Unbeknownst to the admin, user "billybob" has created a hard link to the
exploitable sudo binary in his home directory. Because of the way hard
links work, it is the exact same mode (including being suid root) as the
original file. The admin upgrades the sudo package. During the upgrade,
dpkg finds the /usr/bin/sudo is suid root, so it attempts to chmod it to
600. This in effect chmods the hardlink the user has made to the binary
in their home directory. The original is unlinked, and the attempted
copy in the users home directory is rendered useless.
If the chmod failed, and dpkg didn't fail, that exploitable copy in the
users homedirectory would be left, and continue to be exploitable.
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com