RE: New Linux Trojan

["Vidovic,Zvonimir,VEVEY,GL-IS/CIS" <Zvonimir.Vidovic () nestle com>]

to remedy this annoying buffer overflow problem, one can prevent user stack
area from being executable. You stop dead in its tracks most buffer
overflows, even those unknown at the time being.
That's what openwall does in particular.
http://www.openwall.org/linux/README

Here's some other fancy stuff useful to know about it:

Most buffer overflow exploits are based on overwriting a function's return
address on the stack to point to some arbitrary code, which is also put onto
the stack. If the stack area is non-executable, buffer overflow
vulnerabilities become harder to exploit. Another way to exploit a buffer
overflow is to point the return address to a function in libc, usually
system(). This patch also changes the default address that shared libraries
are mmap()'ed at to make it always contain a zero byte. This makes it
impossible to specify any more data (parameters to the function, or more
copies of the return address when filling with a pattern), -- in many
exploits that have to do with ASCIIZ strings. However, note that this patch
is by no means a complete solution, it just adds an extra layer of security.
Many buffer overflow vulnerabilities will remain exploitable a more
complicated way, and some will even remain unaffected by the patch. The
reason for using such a patch is to protect against some of the buffer
overflow vulnerabilities that are yet unknown. Also, note that some buffer
overflows can be used for denial of service attacks (usually in
non-respawning daemons and network clients). A patch like this cannot do
anything against that. It is important that you fix vulnerabilities as soon
as they become known, even if you're using the patch. The same applies to
other features of the patch (discussed below) and their corresponding
vulnerabilities. 



> -----Original Message-----
> From: Jason Robertson [SMTP:jason () ifuture com]
> Sent: Thursday, September 06, 2001 12:15 AM
> To:   incidents () securityfocus com
> Subject:      Re: New Linux Trojan
>
> You guys are forgetting the other problem, Buffer Overflows, in SUID
> executables could in theory 
> cause this to be a source of infection as well, Root or not..
>
> Jason
>
> On 6 Sep 2001 at 9:26, Russell Fulton wrote:
>
> From:                 Russell Fulton <r.fulton () auckland ac nz>
> To:                   incidents () securityfocus com
> Subject:              Re: New Linux Trojan
> Date sent:            Thu, 6 Sep 2001 09:26:01 +1200 (NZST)
> Priority:             NORMAL
> Mailer:               Simeon for Solaris Motif Version 4.1.5 Build (43)
>
> > On Wed, 05 Sep 2001 13:57:12 -0700 Ben Ford 
> > <bford () securityexchange net> wrote:
> >
> > > Qualys Inc wrote:
> > >
> > > > executable programs. On Linux systems, the Remote Shell Trojan 
> > > > typically begins its replication activities in the current working 
> > > > directory and in the /bin directory.
> > > [ . . .]
> > >
> > > > Mitigating Factors:
> > > > -------------------
> > > > The replication process of the Remote Shell Program can only effect 
> > > > binary files within the access privileges of the user who launched 
> > > > the originally infected program.
> > >
> > > I think that this point should be emphasized a bit more, unless you
> are 
> > > simply out for dramatization.  A properly configured machine won't
> have 
> > > the root user running untrusted binaries.
> >
> > True, however a local (non root) user compromise is still a serious 
> > matter.   This is another good reason to write protect *all* 
> > executables, and preferably have them owned by someone other that the 
> > user.
> >
> > Again Unix is protected because users can't write to most executable 
> > files.
> >
> > Russell Fulton, Computer and Network Security Officer
> > The University of Auckland,  New Zealand
> --------------------------------------------------------------------------
> --
> > This list is provided by the SecurityFocus ARIS analyzer service. For
> more
> > information on this free incident handling, management and tracking
> system
> > please see: http://aris.securityfocus.com
>
>
> ---
> Jason Robertson                
> Network Analyst            
> jason () ifutureinc com    
> http://www.astroadvice.com      
>
>
> --------------------------------------------------------------------------
> --
> This list is provided by the SecurityFocus ARIS analyzer service.
> For more information on this free incident handling, management 
> and tracking system please see: http://aris.securityfocus.com

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com