Re: Secure 2.4.x kernel
> 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
>
>
Reply to: