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?> > > > > > > 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?
> > > > > > > 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... --- Not suggesting that -- it's just that 'root' usually owns /etc/shadow, so reading it would require root access so an exploit through a user account wouldn't automatically get you /etc/shadow. There would have to be other steps.
> > 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.
> > > 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?
Please educate me. How does having the stack be non-executable open a hole that wasn't already there?
*confused* -linda
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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