"Michael H. Warfield" wrote:
>
> On Tue, Apr 18, 2000 at 08:15:17AM -0700, Linda Walsh wrote:
> > "Michael H. Warfield" wrote:
> > > I use to think that making the stack non-executable would at
> > > least make it tougher. The existance of such a simple payload requiring
> > > no assembly language work at all, points out just what a lie that idea is.
> > > Sad to say but non-executable stacks are no help at all.
> > ---
> > That's where real-time audit monitoring and response come in.
> > The log monitor sees UID=root, LUID=daemon, 'exec'ing any programs not
> > on an 'allowed' list and it can shut down the port/process immediately --
> > The list of programs spawned by a system daemon and UID=root is or can be a
> > fairly small list. Programs like inetd shouldn't be writing to any file
> > directly AFAIK. Suppose you hack in through sendmail (assuming you still
> > run it as root) -- you can be alarmed about any files written outside
> > of /var/mail or a user's directory. I still think all of these things
> > provide increasing layers of difficulty.
>
> 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.> > Two, this doesn't have to be run as root. Run it as a plain user > (or even a user without a shell) and you can get in as that user. From > there you can worry about elevation of priviledge attacks. This just > establishes a backdoor from which the real dirty work can proceed. --- True, but in the example, configuring system level commands to be root-only seems prudent.
> > 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. > > 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.
> 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.
> 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. If we don't have exec stack, then they'll stop wasting time there and look for a different exploit. As long as the stack exploit is there, though, you've left 1 window open.
> > 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.
-- 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:13 EST