Linda Walsh <law@sgi.com> writes:
> yoann@mandrakesoft.com wrote:
> >
> > 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.
> ---
> That's better if it works -- restrict it to the user that runs it,
> but, excuse my ignorance, would that affect binding to ports below 1024?
yop
>
> >
> > > >
> > > > 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. :)
> ---
> Open another one? I don't understand. How does having a non-exec.
> open other exploits that were not there before?
Sorry, misunderstanding :
As Michael explained, Hackers not bother anymore doing assembler junk,
they just have to know where the data is, and know the system() call entry.
So what you can see here is that exec and n-e stack are always vulnerable.
> > > 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.
>
> Add that as well.
Not as well, it is sufficient, ( for stack overflow only, not heap one ).
>
> > > > 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.
> ---
> Then how does adding non-executable stack disable those tools?
never said that... or i misunderstand / misunderstood you...
> Please educate me. How does having the stack be non-executable
> open a hole that wasn't already there?
That's not that was said,
it open a hole that wasn't already there by the fact it give false sence
of security.
-- -- 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