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:jasonat_private] > Sent: Thursday, September 06, 2001 12:15 AM > To: incidentsat_private > 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.fultonat_private> > To: incidentsat_private > 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 > > <bfordat_private> 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 > jasonat_private > 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
This archive was generated by hypermail 2b30 : Thu Sep 06 2001 - 08:15:04 PDT