Re: why so many "potential buffer overflow" alerts?

From: citizen (no-spam@sonic.net)
Date: 03/20/02 

From: citizen <no-spam@sonic.net>
Date: Wed, 20 Mar 2002 07:11:22 GMT

 Thank you, Luke, and thank you to the other people who replied.

 Your comments about kernel modules reminded me of something I read in the
old vger kernel mailing list, back in the days when the idea of Linux kernel
modules was first being debated.

  I recall one person in particular -- I think she was the only woman taking
part in the discussion at the time -- who voiced very strong misgivings
about the whole idea of kernel modules, words to the effect that they would
be opening the door to the very kind of confusion they should be trying to
get away from.

   Thanks again.
     BillHogan

Luke Vogel wrote:

> "(name goes here)" wrote:
>
> > And I just now searched Google Groups for "buffer overflow"
> > group:*security*
> > and got 4,350 hits ["Search took 0.68 seconds."]
>
> Is that all ... I thought there would be more, but I suppose you've
> missed the discussions on the MS groups (I don't think they have one
> with "security" in it)
>
> > How is buffer overflow a security threat?
>
> search google for "Smashing the stack for fun and profit" by Aleph One.
> It is the definitive guide for buffer overflows.
>
> > Why is buffer overflow such a common problem?
>
> It appears so because it is relatively easy to search for buffer
> overflows in source code, and as we know, source code for many front
> facing daemons is easily available.
>
> I believe that it is losing its appeal as more and more holes are
> plugged up. Format string overflows are another one to look out for ...
> have a look at the document on the team-teso site for more info on that
> one.
>
> What worries the *** out of me is the runtime (on the fly) kernel
> patching on a running system under Linux using direct access to kernel
> memory ... think about it people ... there aren't too many ways that
> this sort of tampering could be detected. Linux Kernel Modules are easy
> enough to code and consequently hide, but are still largely detectable
> because of the changes to the syscall tables, but, on the fly patching
> is a totally different kettle of fish!
>
> If I recall correctly, only recently we have had a report of a hack with
> the SucKIT: root kit ... well guess what, that source was released on
> Phrack just recently and uses the new techniques.
>
> I haven't had time to analyse the source properly, but it has the
> potential to make the adore lkm look a little tame. (I wonder if the
> guys at team-teso are doing follow-up research on the new techniques)
>
> --
> Regards
> Luke
> ------
> Q: What does FAQ stand for?
> A: We are Frequently Asked this Question, and we have no idea.
> ------
> C.O.L.S FAQ - http://www.linuxsecurity.com/docs/colsfaq.html
> Note: Remove NOSPAM from my return address if necessary
> ------

Quantcast