IMAPD Bufferoverflow bug

[Ashley Thomas <athomas unity ncsu edu>]

hi ,

does anybody remember the exact version of imapd had the bufferoverflow bug
in it.
I am using for some research here.
the version i am using is IMAP4rev1 Service 9.0(157)

thanks
ashley


Hal Burgiss wrote:

> On Fri, Aug 31, 2001 at 02:20:02PM -0400, Ashley Thomas wrote:
>
> > How do we detect it ? or make sure it is hacked infact .
> > I guess : ps , top, tcpdump etc can be helpful ..
> >
> > any pointers ?
>
> Quoting from unreleased HOWTO:
>
>    A  well designed rootkit can be quite effective. Nothing on the system
>    can  really  be  trusted  to  provide  accurate feedback. Nothing! But
>    sometimes  the  modifications  are  not as smooth as intended and give
>    hints  that  something is not right. Some things that might be warning
>    signs:
>
>      * Login  acts wierd. Maybe no one can login. Or only root can login.
>        Any  login  wierdness  at all should be suspicious. Similarly, any
>        wierdness with adding or changing passwords.
>      * System  utilities  are  slower,  or  awkward,  or show strange and
>        unexpected results. Common utilities to be modified are: ls, find,
>        who, w, last, netstat, login, ps, top.
>      * Files  or  directories  named  "..."  or ".. ". A sure bet in this
>        case.
>      * Unexplained bandwidth usage.
>      * Logs  that are missing completely, or missing large sections. Or a
>        sudden change in syslog behavior.
>      * Mysterious open ports, or processes.
>      * Indications  of  a "sniffer", such as log messages of an interface
>        entering "promiscuous" mode.
>      * Modifications  to /etc/inetd.conf, or /etc/passwd. Especially, any
>        additions.
>      * Sniffers like tcpdump might be helpful in finding uninvited
>        traffic. Interpreting tcpdump output requires a skill level
>        beyond the average new user.
>
>    Sometimes  the  intruder  is  not  so  smart  and forgets about root's
>    .bash_history,  or  cleaning  up  log entries, or even leaves strange,
>    leftover  files in /tmp. So these should always be checked. Just don't
>    necessarily expect them to be accurate.
>
>    As  mentioned,  a  compromised  system  will  undoubtedly have altered
>    system  binaries,  and  the  output  of  system utilities is not to be
>    trusted.  Nothing  on  the system can be relied upon to be telling you
>    the truth. Re-installing individual packages may or may not help since
>    it  could  be  system  libraries  or kernel modules that are doing the
>    dirty work.
>
>    RPM users can use rpm -Va |less to attempt to verify the integrity all
>    packages. But again there is no assurance that rpm itself has not been
>    tampered with, or the system components that rpm relies on.
>
>    If  you  have  pstree on your system, try this instead of the standard
>    ps.  Sometimes the script kiddies forget about this one. No gaurantees
>    though that this is accurate either.
>
>    Another  approach  is to visit [78]http://www.chkrootkit.org, download
>    thier rootkit checker, and see what it says.
>
> --
> Hal B
>  hal foobox net
>  hal burgiss net
>  hburgiss bellsouth net
>  Spamtrap: uce ftc gov and report fraud org
> --
>
> _______________________________________________
> Redhat-list mailing list
> Redhat-list redhat com
> https://listman.redhat.com/mailman/listinfo/redhat-list