Date: Mon, 15 Jun 1998 00:04:58 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 12 Jun 1998 to 14 Jun 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980615040657Z96156-1081+21@brimstone.netspace.org>
There are 11 messages totalling 584 lines in this issue.
Topics of the day:
1. Full Armor.... Fool Proof etc... bugs (3)
2. Vulnerability in 4.4BSD Secure Levels Implementation (4)
3. Solaris 2.6 non-executable stacks (2)
4. SECURITY: new mailx packages now available
5. more named warez
----------------------------------------------------------------------
Date: Fri, 12 Jun 1998 20:14:06 +0100
From: Alan Ramsbottom
Subject: Re: Full Armor.... Fool Proof etc... bugs
On 11 Jun 98, at 19:15, chameleon wrote:
>
> Below is basically how to bypass most "secure" desktop programs:
> --------------------------------------------------------------------------
> Turn on your computer. (Tuff one there) There will be
> a two or so second gap between seeing your windows desktop and seeing the
> explorer bar across the bottom. During that two second gap, hit control +
> alt + delete... this will load task manager.
And the solution to that trick is to simply remove taskman.exe from the
machine ..something folk used to do when attempting(!) to secure 95
desktops before there were any third-party solutions. Another trick was
to use the keyboard remapper from the MS KernelToys to remap one of
those pesky CTRL, ALT or DEL keys.
-Alan-
acr@als.co.uk
------------------------------
Date: Sun, 14 Jun 1998 01:43:36 +1000
From: Darren Reed
Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
I'm not sure I see the value in that particular patch for this problem.
Rather than block out all ptrace access to processes, maybe it is more
appropriate to protect all processes on a system where securelevel > 0
- irrespective of whether or not it's init or immutable - from operations
which could `change' it if it is an immutable executeable.
Anyway, below I've attached what I hope is a "better" patch - allows
ptrace to be used in read-only mode on immutable processes (or init)
where the system is running where securelevel > 0.
Darren
*** sys_process.c.orig Sun Jun 14 01:17:14 1998
--- sys_process.c Sun Jun 14 01:39:15 1998
***************
*** 37,42 ****
--- 37,43 ----
#include
#include
#include
+ #include
#include
#include
***************
*** 243,248 ****
--- 244,253 ----
if (p->p_flag & P_TRACED)
return EBUSY;
+ /* Tracing a system process doesn't work anyway */
+ if (p->p_flag & P_SYSTEM)
+ return EINVAL;
+
/* not owned by you, has done setuid (unless you're root) */
if ((p->p_cred->p_ruid != curp->p_cred->p_ruid) ||
(p->p_flag & P_SUGID)) {
***************
*** 250,268 ****
return error;
}
- /* can't trace init when securelevel > 0 */
- if (securelevel > 0 && p->p_pid == 1)
- return EPERM;
-
/* OK */
break;
- case PT_READ_I:
- case PT_READ_D:
- case PT_READ_U:
case PT_WRITE_I:
case PT_WRITE_D:
case PT_WRITE_U:
case PT_CONTINUE:
case PT_KILL:
case PT_STEP:
--- 255,284 ----
return error;
}
/* OK */
break;
case PT_WRITE_I:
case PT_WRITE_D:
case PT_WRITE_U:
+ #ifdef PT_SETREGS
+ case PT_SETREGS:
+ #endif
+ #ifdef PT_SETFPREGS
+ case PT_SETFPREGS:
+ #endif
+ if ((error = VOP_GETATTR(p->p_textvp, &va, p->p_ucred, p)) != 0)
+ return error;
+ /*
+ * disallow changes to immutable executeables running in a
+ * `secure' kernel environment.
+ */
+ if ((securelevel > 0) &&
+ ((va.va_flags & (IMMUTABLE|NOUNLINK)) || (p->p_pid == 1)))
+ return EPERM;
+ case PT_READ_I:
+ case PT_READ_D:
+ case PT_READ_U:
case PT_CONTINUE:
case PT_KILL:
case PT_STEP:
***************
*** 270,283 ****
#ifdef PT_GETREGS
case PT_GETREGS:
#endif
- #ifdef PT_SETREGS
- case PT_SETREGS:
- #endif
#ifdef PT_GETFPREGS
case PT_GETFPREGS:
- #endif
- #ifdef PT_SETFPREGS
- case PT_SETFPREGS:
#endif
/* not being traced... */
if ((p->p_flag & P_TRACED) == 0)
--- 286,293 ----
*** procfs_vnops.c.orig Sun Jun 14 01:25:29 1998
--- procfs_vnops.c Sun Jun 14 01:27:54 1998
***************
*** 121,126 ****
--- 121,128 ----
{
struct pfsnode *pfs = VTOPFS(ap->a_vp);
struct proc *p1 = ap->a_p, *p2 = PFIND(pfs->pfs_pid);
+ int error;
+ struct vattr va;
if (p2 == NULL)
return ENOENT;
***************
*** 135,144 ****
(p1->p_cred->pc_ucred->cr_gid != KMEM_GROUP))
return EPERM;
!
! if (ap->a_mode & FWRITE)
pfs->pfs_flags = ap->a_mode & (FWRITE|O_EXCL);
!
return (0);
default:
--- 137,150 ----
(p1->p_cred->pc_ucred->cr_gid != KMEM_GROUP))
return EPERM;
! error = VOP_GETATTR(p2->p_textvp, &va, p1->p_ucred, p1);
! if (error)
! return error;
! if (ap->a_mode & FWRITE) {
! if (va.va_flags & IMMUTABLE)
! return EPERM;
pfs->pfs_flags = ap->a_mode & (FWRITE|O_EXCL);
! }
return (0);
default:
------------------------------
Date: Fri, 12 Jun 1998 14:57:23 -0600
From: Dax Kelson
Subject: Solaris 2.6 non-executable stacks
A new feature in Solaris 2.6 is the ability to turn off executable stacks.
Just add these lines to /etc/system and reboot
* Turn off executable stacks
set noexec_user_stack = 1
Does anyone know how secure this implementation is?
Dax Kelson
Internet Connect, Inc.
------------------------------
Date: Fri, 12 Jun 1998 19:20:14 -0400
From: "Alex K."
Subject: SECURITY: new mailx packages now available
/tmp races have been found in the mailx package. All users of Red
Hat Linux 4.2 and 5.x should upgrade to the new versions of mailx,
which are now available on ftp.redhat.com.
Red Hat 5.0 and 5.1
-------------------
i386:
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/mailx-8.1.1-1.i386.rpm
alpha:
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/alpha/mailx-8.1.1-1.alpha.rpm
Red Hat 4.2
-------------
i386:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/mailx-8.1.1-0.i386.rpm
alpha:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/mailx-8.1.1-0.alpha.rpm
SPARC:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/mailx-8.1.1-0.sparc.rpm
------------------------------
Date: Fri, 12 Jun 1998 22:35:18 +0200
From: Florian Weimer
Subject: Re: Full Armor.... Fool Proof etc... bugs
chameleon writes:
> ----------------------------------------------------------------------------
> -----------------
> Turn on your computer. (Tuff one there)
> There will be a two or so second gap between seeing your windows desktop and
> seeing the explorer bar across the bottom.
> During that two second gap, hit control + alt + delete... this will load
> task manager.
> You now have taskmanager which will enable you to run whatever you like. You
> also are able to do this without any restrictions because you froze windows
> from loading explorer and Full Armor... Fool Proof etc...
> ----------------------------------------------------------------------------
> -----------------
If you hit Ctrl-Esc at the Windows 95 login prompt, you'll launch the
task manager as well. From there, you can start the Explorer, and
you'll have full access to the computer. Windows 95 is inherently
insecure.
------------------------------
Date: Sat, 13 Jun 1998 20:53:23 +0100
From: Niall Smart
Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
On Jun 11, 10:33pm, tqbf@POBOX.COM wrote:
} Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
> > We have discovered a vulnerability in all current implementations of
> > secure levels which allow an intruder to modify the memory image of
> > running processes, thereby bypassing the protection applied to system
> > binaries and their configuration files. The vulnerability cannot be
> > exploited to modify the init process, kernel memory or the protected
> > files themselves.
[snip]
> To start with, the fact that processes can be "hijacked" when the system
> is in secure mode is well known. Please consult the June, 1997 OpenBSD
> security advisory regarding procfs vulnerabilities for prior art in
> published advisories; this document acknowledges that processes other than
> init can be taken over by root.
That advisory concerns a vulnerability then present in procfs which
allowed the root user to circumvent the supposed immutability of the
init process' address space in secure mode. The advisory we issued
concerns the semantics of the immutable filesystem flag, the OpenBSD
advisory you refer to does not mention these semantics either explicitly
or implicitly and so I fail to see how it can be claimed as prior art,
nor can I find any mention in it of the fact that processes other than
init can be taken over by root. Of course anyone capable of reading the
source code can determine this, but documentation of a security bug in
the form of the buggy source code hardly qualifies as "prior art".
> I realize that you are referring specifically to the fact that a process
> which was loaded into memory from an immutable file does not have an
> "immutable" text segment. I don't see where it is documented that these
> semantics hold. McKusick et al do not mention anything about the text
> segment of "login" being immutable, and the "man" page documentation for
> the immutable flag doesn't mention it either.
>
> I do not understand how the attack you describe poses a major threat to
> the current securelevels semantics. There remains no published method for
> altering or truncating the contents of an immutable or append-only file on
> OpenBSD 2.2, and there remains no published method for accessing kernel
> memory in securelevel 1 on OpenBSD.
Not propagating the immutable filesystem flag on an executable to its
address space, as you suggest is the correct and documented behaviour,
implies the following:
- The only use of the immutable flag is to protect the disk images
of the kernel, init, the LKMs and the directories in which they reside.
Assuming your semantics are correct, I can see no use in using it
to protect any others. Do you think that protection of these 5-6
files, which could just as easily have been achieved using the
append-only flag, was the sole purpose of the introduction of the
immutable flag?
- The syslogd daemon can be covertly compromised, so no useful
information ever gets logged to the protected system logs. But at
least no-one can modify the useless information.
- Any conventional binary or library used to view the log files can
be compromised, although compromising these would be a waste of time
since that the logs don't have any useful information anyway.
- Performing a syscall requires you to attempt to defeat any backdoors
inserted at runtime in the executable.
McKusick et al have this to say:
Files marked immutable include those that are frequently the subject
of attack by intruders (e.g., login and su). The append-only flag
is typically used for critical system logs. If an intruder breaks
in, he will be unable to cover his tracks. Although simple in
concept, these two features improve the security of a system
dramatically.
Why do they advocate protecting login and su if such protection can
be trivially defeated using the same techniques we demonstrated in
the attack on inetd? And why do they claim these features improve the
security of a system "dramatically" if they can be bypassed so easily?
Either they didn't read the chflags man page (hmm, I think they wrote it),
they advocate partial security (hmm, don't think so), or there is a bug.
I believe the latter is the case.
Propogation of the immutable flag is the logical and correct thing to do.
I agree that this behaviour is not explicitly documented, however it
is a reasonable expectation that people hold. Secure levels become a
farce without it.
> The access you talk about obtaining by patching "inetd" can just as easily
> be obtained by replacing it with another process entirely; even on secure
> systems, unless the inetd process is watched very carefully, it is
> possible to transparently replace inetd with another program, while
> maintaining the process ID.
A system which does not watch inetd very carefully is, by definition,
not a secure system. If an administrator judges the level of risk to
the machine to warrant the use of secure levels but doesn't then watch
inetd and the other daemons then he deserves whatever he gets.
> The fact that inetd is running from a
> different binary is not much more noticeable than the fact that, for
> instance, telnetd is running from a new binary.
It is not necessary to involve any new binaries whatsoever to exploit
the vulnerability, for example you can simply load /usr/libexec/telnetd
and then hose it in situ using ptrace. How are you going to detect that?
Its easier to prevent it happening in the first place.
> Meanwhile, patching this "problem" means that I cannot debug programs that
> run from immutable files. More importantly, I can't take over and perform
> forensics on a live attacking process; an attacker merely flags her
> sniffer "immutable", and I suddenly have no way of backdooring it. From my
> perspective, "fixing" this problem loses more for me much more than it
> wins.
I think you're overplaying the importance of the problem. Firstly,
understanding the sniffer is only practical with access to its source
code because the attacker can easily obfuscate the machine code to such
an extent that deciphering it would be impossible. Presumably someone
who has broken root on your system knows better than to leave the source
code lying around. Secondly, with regard to maintaining the ability to
backdoor a sniffer without killing it, you could allow write access to an
immutable process from the console. Another possibility is to prevent the
setting of the immutable flag on a file when the system is in secure mode.
> Of course, the core issue here is that securelevels are silly. The 4.4BSD
> kernel is not secure against "root". It wasn't designed to be. Adding a
> global flag to the kernel and periodically checking it doesn't alter this
> fact; root is too powerful, and "securelevels" are a hack that attempts
> (and fails, IMO) to perform damage control. Don't defend it; replace it
> with something that works (like compartmentalization/domain-type
> enforcement).
Well, if you can find someone with sufficient time to attempt this and
sufficient skill to implement it without introducing new security problems
then that would be great. However I'm trying to fix the current model,
not introduce a new one.
Niall
------------------------------
Date: Fri, 12 Jun 1998 13:21:18 -0600
From: abc@RALPH.ML.ORG
Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
> The key word is "should" draw attention. Unless there is an
> application (or the system itself) that periodically checks for any
> change in status of a system daemon (like the change of a PID), I
> suspect that most sysadmins will not even notice that a system daemon
> has died and restarted. To help plug this vulnerability one of the
> following options might be desirable,
Many sysadmins in control of operating systems which have the
immutable/no-unlink flags don't use those flags at all.
> following options might be desirable,
>
> 1. Disallow sending signals to processes started from immutable
> binaries,
> except from init, e.g. during shutdown.
> Advantage: Improved security.
> Disadvantages: Administration may be virtually impossible and may
> break
> existing applicaitons.
While I agree that the signal issue is very messy, I don't think this
is a good idea. The obvious reasons include being able to keep a handle
on an out-of-control process. This would also be a great help to an
intruder who doesn't like his/her processes being killed.
> 1a. A variation of #1 except using a new "unkillable" flag which denotes
> immutable binaries that cannot be sent signals.
Same problems.
[...]
> 3. Replicate the immutable flag when a file is copied.
> Advantage: Some improved security.
> Disadvantage: Intruder can FTP a rogue daemon and run it instead.
Reliably implementing this would be impossible. The system has no
real way of knowing whether or not a file is being opened for the purpose
of its duplication, and making guesses at that could just lead to
big problems.
--
cstone
------------------------------
Date: Sun, 14 Jun 1998 03:43:02 -0500
From: tqbf@POBOX.COM
Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
> Unless there is an
> application (or the system itself) that periodically checks for any
> change in status of a system daemon (like the change of a PID),
Watch out. You can't assume that a change of processes is detectable by a
change in the PID --- if I kill off the original holder of a PID, I can
claim that PID by forking until the OS re-uses it for my own process. Even
if the system uses randomized PIDs (a cool idea), I will still eventually
receive the one I want, and until I do (we're probably talking seconds),
I can keep the service I'm backdooring running on a different PID.
-----------------------------------------------------------------------------
Thomas H. Ptacek The Company Formerly Known As Secure Networks, Inc.
-----------------------------------------------------------------------------
http://www.pobox.com/~tqbf "If you're so special, why aren't you dead?"
------------------------------
Date: Sat, 13 Jun 1998 23:24:09 -0400
From: Joseph Gooch
Subject: Re: Full Armor.... Fool Proof etc... bugs
On Thu, 11 Jun 1998, chameleon wrote:
> I have seen a few post about the "Full Armor hacks" and thought I would drop
> some info.
>
> There are various programs that make a desktop "secure". Full Armor and
> Fool Proof are two of them. They both suffer from the same problems.
>
> Below is basically how to bypass most "secure" desktop programs:
< Insert rant about task manager>
We use Fortres 101, not the best solution by far ;) This problem is very
easily remedied by renaming or deleting taskman.exe. We decided on
taskmen.exe, you may make your choice, it doesn't really matter.
------------------------------
Date: Sun, 14 Jun 1998 23:53:41 +0100
From: Gus
Subject: Re: more named warez
This was mostly for my own amusement, since I am always interested in
/who/ is trying to 0wn my boxen, as well as preventing it.
When an exploit attempt is recieved, you get:
Jun 14 23:45:47 victim named[2670]: IQUERY recieved from [192.168.0.20].27447
The patch is for 4.9.6-REL, but it should work accross the board, you get
the idea, anyways.
named may be (is?) the new imapd, with all the bulk scanning that that
implies. You all know the score.
*** ns_req.c Tue Apr 7 05:59:46 1998
--- ns_req.c.new Thu Jun 4 13:54:07 1998
***************
*** 193,199 ****
break;
case IQUERY:
! action = req_iquery(hp, &cp, eom, &buflen, msg, from);
break;
#ifdef BIND_NOTIFY
--- 193,201 ----
break;
case IQUERY:
! hp->rcode = REFUSED;
! action = Finish;
! syslog(LOG_ALERT,"IQUERY recieved from %s",sin_ntoa(from));
break;
#ifdef BIND_NOTIFY
--
angus@intasys.com
------------------------------
Date: Sun, 14 Jun 1998 21:03:28 -0500
From: "Edward S. Marshall"
Subject: Re: Solaris 2.6 non-executable stacks
On Fri, 12 Jun 1998, Dax Kelson wrote:
> A new feature in Solaris 2.6 is the ability to turn off executable stacks.
[...]
> Does anyone know how secure this implementation is?
More importantly, does anyone know whether this breaks anything, like
early versions of Solar Designer's Linux patch did?
--
-------------------. emarshal at logic.net .---------------------------------
Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/
Linux labyrinth 2.1.106 #9 SMP Sun Jun 14 14:50:43 CDT 1998 i586 unknown
9:00pm up 4:56, 3 users, load average: 0.19, 0.18, 0.18
------------------------------
End of BUGTRAQ Digest - 12 Jun 1998 to 14 Jun 1998
**************************************************