> 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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
