This post to bugtraq raises an interesting point. If we have a suid
executable (not suid root), it is really silly to let the user it is
suid to write to it, since this gives an attacker a guarenteed way to
get a trojan onto the system if they manage to exploit a hole in the
program. Instead of mode 4755, it should be mode 4555. Then if an
attacker cracks the program, they cannot overwrite it with a trojan.
Although there will still be other avenues of attack on the system,
we might as well close one of them.
A patch for policy:
--- /tmp/debian-policy-3.5.0.0/policy.sgml Sun Jan 28 20:04:59 2001
+++ /home/joey/policy.sgml Mon Feb 5 19:20:24 2001
@@ -5550,9 +5550,10 @@
it.</p>
<p>
- Setuid and setgid executables should be mode 4755 or 2755
+ Setuid and setgid executables should be mode 4555 or 2755
respectively, and owned by the appropriate user or group.
- They should not be made unreadable (modes like 4711 or
+ While the user they are setuid or setgid to should not be able
+ to write to the executable, they should not be made unreadable (modes
like 4711 or
2711 or even 4111); doing so achieves no extra security,
because anyone can find the binary in the freely available
Debian package--it is merely inconvenient. For the same
Of course, there's little point in making a suid root binary mode 4555
as opposed to 4755, since root will be able to write to it anyway. I
don't feel that is worth mentioning in policy though.
----- Forwarded message from Megyer Ur <[EMAIL PROTECTED]> -----
From: Megyer Ur <[EMAIL PROTECTED]>
Date: Mon, 5 Feb 2001 23:18:58 +0100
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: Re: SuSe / Debian man package format string vulnerability
Reply-To: Megyer Ur <[EMAIL PROTECTED]>
On Mon, Feb 05, 2001 at 06:34:47AM -0500, John wrote:
> On my Debian 2.2 system 'man' was installed
> suid root. I don't know about Debian 2.3 but,
> Debian 2.2 does install 'man' suid root.
Debian systems:
---------------
-rwsr-xr-x 1 man root 84524 Oct 24 08:11 /usr/lib/man-db/man
-rwxr-xr-x 3 root root 5060 Oct 24 08:11 /usr/bin/man
there are two man binaries.
/usr/bin/man is a simple binary, without any suid bit, BUT
/usr/lib/man-db/man is suid man, and it's vulnerable to man -l <formatstr>
attack. So anyone can get man uid by exploiting it.
So we can overwrite the /usr/lib/man-db/man binary with any stuff we
want, and when some user launches man, our code will be run instead of
the original /usr/lib/man-db/man binary. This is the real security
problem.
If root runs /usr/bin/man, it drops root priviledges, and it setuids to
man(6) as you can see:
lez:~# strace man asdf 2>&1 |grep setuid
setuid(6) = 0
Redhat systems:
---------------
-rwxr-sr-x 1 root man 35260 Aug 23 17:56 /usr/bin/man
We can get man gid with man on Redhat. Then we may be able to
overwrite some stuff in /var/man/cache, what is still unsecure because
troff may have some security flaws...
Conclusion:
-----------
In debian systems, we can own the user who runs man (but not root!).
In redhat systems, we get only man gid, but one may be able to get more
(not checked).
--
Lez (Megyer Laszlo)
[EMAIL PROTECTED]
----- End forwarded message -----
--
see shy jo
