Re: Secure 2.4.x kernel
Hi
I haven't read all the messages in this thread yet, but from
your first question about whether or not the kernel can detect
SIGSEGVs it seems you think that when a buffer is overrun, a
SIGSEGV is generated. This is not always the case.
i.e. If a buffer is overrun in a process, and there is garbage
on the stack, the chances are the process will get a SIGSEGV and
it will crash.
If there is exploit code on the stack instead of garbage, there
will be no SIGSEGV. The process will carry on running just fine
and the kernel will not know the buffer has been overrun (unless
you're using the non-executable stack patch or something.)
If you're using the non-exec stack patch, it is still possible
to exlpoit buffer overruns. It's just a little more work.
i.e. it's not possible for the kernel to stop buffer overruns
by monitoring SIGSEGVs, because when there's a successful
exploit, there is no SIGSEGV.
I hope that helps :)
On Tue, Dec 25, 2001 at 08:57:25AM -0500, Gary MacDougall wrote:
> > On Monday, December 24, 2001, at 10:52 , Gary MacDougall wrote:
> >
> > > Someone said that St. Jude was what I was looking for, and I think
> > > its pretty much *exactly* what I was pointing out.
> >
> > Can't, in general, stop an attack. All the attacker has to do is
> > not do unusual calls which jude monitors, which would appear
> > from the docs to be execve.
> >
> > You don't need to call execve to have all sorts of evil fun.
> > open and write (something most processes do quite legitimately)
> > will suffice. So will open and read.
>
> certainly, I agree to that.
>
> > >> The problem you're trying to solve is to get the kernel to
> > >> refuse to execute exploit code. Exploit code looks just like any
> > >> other code to CPU. Good luck trying to get the kernel to tell
> > >> the difference.
> > >
> > > The problem really isn't the code that an exploit executes, the problem
> > > is that the exploit can allow for "root" access by allowing the
> > > malicious
> > > code to spawn a new shell.
> >
> > It doesn't need to spawn a new shell to allow root access. It
> > can just load the a properly-linked shell into memory (not
> > calling execve), then jump to main.
> >
> > Or it can not use a shell at all. Shells aren't special in any way.
>
> True, shells aren't special. But if someone tries to smash the stack,
> and the kernel protects against this (hypothetically), I think that its
> just another level of protection. The goal, in my mind, is to take the
> "buffer overrun" out of the hands of 99.9% of the attackers/script kiddies
> out there. I think it sort of analogous to a firewall where as your not
> going to be 100% effective, but you'll atleast ward off most of the
> offensive attackers.
>
>
> > >
> > >
> > >> In short: Would EPERM from exec stop a script kiddie? Probably.
> > >> Would it stop a dedicated attacker? No.
> > >
> > > Ok, maybe i'm missing something, but a "script kiddie" basically needs
> > > access to your box to trojan it right? An attacker, needs
> > > access to the
> > > box to attack it, right? Whats the difference?
> >
> > A script kiddie is someone who downloaded some exploit code off
> > the 'net, and goes and tries it against random boxes. Or against
> > popular boxes. If his downloaded code does not work, he's stuck.
> > Might not even know C. Probably doesn't understand how the
> > exploit works. He'll give up or try another box.
> >
> > A dedicated attacker, to me, is a person with a lot more
> > experience, a lot more time to use to attack you, and a reason
> > to attack that box specifically. He does read the source of
> > programs, looking for holes. He will manage to find the tricks
> > you've put into place, and, given enough time, get around them.
> >
> > I confess that the danger to most people is the former. You have
> > to be protecting fairly important information to get the latter.
> > Or be otherwise important.
> >
>
> <onsoapbox>
>
> The descriptions of who and what a attacker are to me besides
> the point. I'll never understand why people want to put labels on
> someone trying to do something *bad* things to your box, I don't
> care what kind of intelligence or expertise these jerks have -- to me,
> they're equally appaulling.
>
> I remember once my mother asked me (she barely knows anything
> about computers) what a computer "break in" was. The only way I
> could explain it, in laymens terms, was to describe someone walking
> up to her house and jiggling the locks and trying all the windows to
> find a weakness or a kink in the armour so that they could get
> inside to either do "bad things" like use the house or allow others to
> come by and party... Her response: "Thats illegal, how come if
> someone try's to get into your computer, they aren't arrested.".
> Hmmm... Mom has a good point.
>
> I think the bottom line is that we'll never have 100% security until
> there are laws that protect the break-in's and hacking that occurs.
> Still laws... not crappy little wrist slapping type laws.
>
> </offsoapbox>
>
> > --
> > To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> >
> >
>
>
> --
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
Michael Wood <mwood@its.uct.ac.za>
Reply to: