Re: Microsoft SQL Server 2000,7 OpenRowSet Buffer Overflowvulnerability (#NISR02072002)

[Dave Aitel]

So, unless I'm mistaken, there's no way to patch MS Desktop Engine for
this bug. Unless someone can point out a way to get it to SP2, since the
SQL Server SP2 installer won't work for it.

Also, does anyone find it odd that you have to literally copy a dll over
another dll to apply the hotfix? Not even Linux makes you do that.

-dave


On Fri, 2002-08-02 at 20:55, NGSSoftware Insight Security Research
wrote:
> NGSSoftware Insight Security Research Advisory
> 
> Name: OpenRowSet Buffer Overflows
> Systems: Microsoft SQL Server 2000 and 7, all Service Packs
> Severity: High Risk
> Category: Remote Buffer Overrun Vulnerability
> Vendor URL: http://www.microsoft.com/
> Author: David Litchfield ([EMAIL PROTECTED])
> Advisory URL: http://www.ngssoftware.com/advisories/mssql-ors.txt
> Date: 2nd July 2002
> Advisory number: #NISR02072002
> VNA reference : http://www.ngssoftware.com/vna/ms-sql.txt
> 
> This advisory covers the solution to one of the problems mentioned in the
> above VNA URL.
> 
> Description
> ***
> Microsoft's database servers SQL Server 2000 and 7 have a remotely
> exploitable buffer overrun vulnerability in the OpenRowSet function.
> OpenRowSet allows users to run ad hoc queries on the server.
> 
> Details
> ***
> By passing overly parameters to certain Providers using the OpenRowSet
> functions an attacker can overwrite program control data, such as saved
> return addresses on the stack. This allows an attacker to gain control over
> the SQL Server process and run arbitrary code. Any code provided by an
> attacker will execute in the secuirty context of the account used to run SQL
> Server. Often this is the powerful local SYSTEM account and in this case an
> attacker can not only compromise all SQL Server data but completely control
> the operating system too. Where SQL Server is running in the context of a
> domain user they will only gain access to the server's data. Neither of
> these two situations are desirable and as such SQL Server administrators
> should patch this as soon as they can.
> 
> 
> Fix Information
> ***
> NGSSoftware alerted Microsoft to this problem on the 15th of May 2002 and
> they have since released a patch to resolve this problem. Please see
> 
> http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/
> bulletin/MS02-040.asp
> 
> for more details. Further one can prevent users from running adhoc queries
> by setting DisallowAdhocAccess to 1 for each provider under the following
> registry key HKLM\Software\Microsoft\MSSQLServer\Providers\. If the value
> does not exist already then it can be created as a new DWORD value.
> 
> 
> A check for this vulnerability has been added to Typhon II, NGSSoftware's
> vulnerability assessment scanner, of which, more information is available
> from the NGSSite, http://www.ngssoftware.com/
> 
> Further Information
> 
> For more information regarding SQL Injection please read
> 
> http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf
> http://www.ngssoftware.com/papers/advanced_sql_injection.pdf
> 
> and for more information about buffer overflows please read
> 
> http://www.ngssoftware.com/papers/ntbufferoverflow.html
> http://www.ngssoftware.com/papers/bufferoverflowpaper.rtf
> http://www.ngssoftware.com/papers/unicodebo.pdf
> http://www.ngssoftware.com/papers/non-stack-bo-windows.pdf
> 
> 
> 
> 
> 
> 
> 
> 
> 




signature.asc
Description: This is a digitally signed message part

Re: EEYE: Macromedia Shockwave Flash Malformed Header Overflow

[Tim Jackson]

On Fri, 9 Aug 2002 12:44:38 -0700 Scott Lampert wrote:

> As far as I can see there is no update to the UNIX versions.  The files
> are all dated March 25.  The bulletin describes version 6 of the Flash
> player as the fix, however that doesn't seem to be available for
> anything other than Windows and Mac.  Am I missing something?

I asked Macromedia the same thing, and Troy Evans (Flash Player Product
Manager) replied:

TE> Flash Player for Linux and Solaris will be updated this afternoon (by
TE> the end of the day), the new player will be available at
TE> www.macromedia.com/go/getflashplayer/ 

It seems they kept to this, as Flash Player 5.0r50 (at least for Linux;
other OS's not checked) is now available from that URL.

Tim

RE: EEYE: Macromedia Shockwave Flash Malformed Header Overflow

[Mike Chambers]

The linux and solaris updates will be avaliable later today.

You will be able to download it at:
www.macromedia.com/go/getflashplayer/ 

mike chambers

[EMAIL PROTECTED]

> -Original Message-
> From: Scott Lampert [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, August 09, 2002 3:45 PM
> To: BUGTRAQ
> Subject: Re: EEYE: Macromedia Shockwave Flash Malformed 
> Header Overflow
> 
> 
> On Thu, Aug 08, 2002 at 05:26:20PM -0700, Marc Maiffret wrote:
> > Vendor Status:
> > Macromedia has released a patch for this vulnerability, 
> available at:
> > 
> http://www.macromedia.com/v1/handlers/index.cfm?ID=23293&Metho
d=Full&Title=M
>
PSB02%2D09%20%2D%20Macromedia%20Flash%20Malformed%20Header%20Vulnerabili
ty%2
> 0Issue&Cache=False
> 
> Discovery: Drew Copley
> Exploitation: Riley Hassell
> 

As far as I can see there is no update to the UNIX versions.  The files
are all dated March 25.  The bulletin describes version 6 of the Flash
player as the fix, however that doesn't seem to be available for
anything other than Windows and Mac.  Am I missing something?
-Scott

-- 
Scott Lampert
<[EMAIL PROTECTED]>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

Public Key: http://www.lampert.org/public_key.asc

Re: IE SSL Vulnerability

[Mike Benham]

On Wed, 7 Aug 2002, Alex Loots wrote:
> Hi Mike,
> I visited your demo at https://www.thoughtcrime.org. It appears that Thawte is
> the TTP instead of Verisign. Does this make any difference for example the
> certificate extensions?

First of all, https://www.thoughtcrime.org is NOT the demo site.  Several
people were confused by this email, and subsequently concluded that their
browser isn't vulnerable because they got an alert that the "name on the
certificate is invalid."  If you would like to see a demo of this
vulnerability, please email me offline.

> Is that what you are saying here that you got a subordinate CA signing
> certificate from Thawte (or Verisign according to your posting) for
> thoughtcrime.org and used this to generate a end entity server certificate for
> any domain you like? Or did you got an end entity server certificate from
> Thawte for www.thoughtcrime.org and used this certificate to sign end entity
> certificates?
>
> I ask this because in the basic constraints of  www.thoughtcrime.org in your
> example the "subject type" is "end entity" instead of "CA" which should be the
> case for an intermediate CA according to RFC 2459.  I think that you used a
> end entity certificate as intermediate CA, but I am not sure.

Thawte and Verisign aren't doing anything wrong.  I received an end-entity
certificate with the CA basic constraint set to FALSE from Thawte.
According to RFC 2459, intermediate CAs in a certificate chain SHOULD have
a CA basic constraint set to TRUE.  According to that document, steps "h"
through "m" should be applied to all certificates but the leaf certificate
when verifying a certificate path.  Step "i" is:

  (i) Verify that the certificate is a CA certificate (as specified
  in a basicConstraints extension or as verified out-of-band).

...so this is the point.  I'm using my joe-schmoe end-entity certificate
as an intermediate certificate, and IE is not doing step i.  The
vulnerability lies with IE.

> > As the unscrupulous administrator of www.thoughtcrime.org, I can generate
> > a valid certificate and request a signature from VeriSign:
>
> Is this a CA-signature or a end entity signature?

It's a signature from an end-entity certificate, but IE treats it as a CA
signature.

> > [CERT - Issuer: VeriSign / Subject: VeriSign]
> > -> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]
> >
> > Then I generate a certificate for any domain I want, and sign it using my
> > run-of-the-mill joe-blow CA-signed certificate:
>
> The "name constraints extension" in the CA certificate should not allow this.
> However in the case of a end entity certificate the name constraints extension
> is not present so you used a end entity certificate for your  run-of-the-mill
> joe-blow CA-signed certificate?
>
> > [CERT - Issuer: VeriSign / Subject: VeriSign]
> > -> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]
> >-> [CERT - Issuer: www.thoughtcrime.org / Subject: www.amazon.com]
>
> > Since IE doesn't check the Basic Constraints on the
> > www.thoughtcrime.org
> > certificate, it accepts this certificate chain as valid for
> > www.amazon.com.
> >
> > Anyone with any CA-signed certificate (and the corresponding private
> > key) can spoof anyone else.
>
> Not if the "name constraints extension" is properly defined by the TTP. See
> section "4.2.1.11  Name Constraints" of RFC 2459. And the "pathLenConstraint
> field" in the basic constraints is set to zero.
>
> So is IE really vulnerable or is it the TTP that messed up by not defining a
> "name constraints extension"?

IE is vulnerable.  There's no reason to have a name constraints extension
on an end-entity certificate at all.  Anyone verifying the certificate
path would trip over the absense of a CA basic constraint before even
getting to name constraints.

- Mike

--
http://www.thoughtcrime.org

Cross-Site Scripting Issues in Falcon Web Server

[Matthew Murphy]

>From Developer:

"Falcon Web Server is running under Windows NT/2000/XP as well as Windows
95/98. It supports ISAPI and WinCGI, and it is a fully  functional web
server which is capable of running a small / medium scale website of about
50-80 hits per minute.  The real advantage of Falcon Web Server is the
ability to run on a desktop computer with almost the same functionality as
large-scale web servers like MS IIS and Apache."

A lack of input sanitation in the error message output of this server makes
it susceptible to two cross-site scripting vulnerabilities:

* An issue in the way the server handles 301 messages when a file is not
found, and the request is not terminated by a slash.  Falcon simply adds a
slash to the request URI, and sends back a 301 with the following entity:

/alert("xss")/Redir
ecting browser to /">/alert("xss")/If nothing happens click the link above.

* An issue in the way the server handles 404 messages when a file/folder is
not found, and the necessary slash has been added (entity below):

HTTP/1.0 404 Not
Found/alert("xss")/index.html Not
FoundCannot locate the requested file.

Examples:

* 301 Message XSS

Closing TITLE tag:
http://localhost/%3c/title%3e%3cscript%3ealert(%22xss%22)%3c/script%3e
Closing A HREF:
http://localhost/%22%3cscript%3ealert(%22xss%22)%3c/script%3e
Closing A tag:
http://localhost/%3c/a%3e%3cscript%3ealert(%22xss%22)%3c/script%3e

* 404 Message XSS

http://localhost/%3cscript%3ealert(%22xss%22)%3c/script%3e/

The 301 examples will simply add a slash and pass it on to the browser,
which then raises a 404, exploiting that vulnerability as well (although the
301 exploits will cause some useless HTML to be added on)

"The reason the mainstream is thought
of as a stream is because it is
so shallow."
 - Author Unknown

Apache 2.0 vulnerability affects non-Unix platforms

[Mark J Cox]

-BEGIN PGP SIGNED MESSAGE-

For Immediate Disclosure

=== SUMMARY 

Title: Apache 2.0 vulnerability affects non-Unix platforms
 Date: 9th August 2002
 Revision: 2
 Product Name: Apache HTTP server 2.0
  OS/Platform: Windows, OS2, Netware
Permanent URL: http://httpd.apache.org/info/security_bulletin_20020809a.txt
  Vendor Name: Apache Software Foundation
   Vendor URL: http://httpd.apache.org/
  Affects: All Released versions of 2.0 through 2.0.39
 Fixed in: 2.0.40
  Identifiers: CAN-2002-0661

=== DESCRIPTION 

Apache is a powerful, full-featured, efficient, and freely-available Web
server.  On the 7th August 2002, The Apache Software Foundation was
notified of the discovery of a significant vulnerability, identified by
Auriemma Luigi <[EMAIL PROTECTED]>.

This vulnerability has the potential to allow an attacker to inflict
serious damage to a server, and reveal sensitive data.  This vulnerability
affects default installations of the Apache web server.

Unix and other variant platforms appear unaffected.  Cygwin users are
likely to be affected.

=== SOLUTION 

A simple one line workaround in the httpd.conf file will close the
vulnerability.  Prior to the first 'Alias' or 'Redirect' directive, add
the following directive to the global server configuration:

   RedirectMatch 400 "\\\.\."

Fixes for this vulnerability are also included in Apache HTTP server
version 2.0.40.  The 2.0.40 release also contains fixes for two minor
path-revealing exposures.  This release of Apache is available at
http://www.apache.org/dist/httpd/

More information will be made available by the Apache Software
Foundation and Auriemma Luigi <[EMAIL PROTECTED]> in the
coming weeks.

=== REFERENCES 

The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2002-0661 to this issue.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0661

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iQCVAwUBPVQvLO6tTP1JpWPZAQEYwgQAqdRDauIcFcBpjwWqLuqPhyHthtOk8Vms
WSKd5Q4wS8tCX4c1wUskKVyGGVEqACkzqd0Gm3W1I34Q7iJlwBYosVl/00d0IlGY
tNj+XFB2R2ORT35H0oVjf+La99V1KPmed0+2HzxM6KbSeLWh/H1tRpMHtC0Q9EBK
GAs3seQmHRI=
=MfPR
-END PGP SIGNATURE-

Re: EEYE: Macromedia Shockwave Flash Malformed Header Overflow

[Scott Lampert]

On Thu, Aug 08, 2002 at 05:26:20PM -0700, Marc Maiffret wrote:
> Vendor Status:
> Macromedia has released a patch for this vulnerability, available at:
> http://www.macromedia.com/v1/handlers/index.cfm?ID=23293&Method=Full&Title=M
> PSB02%2D09%20%2D%20Macromedia%20Flash%20Malformed%20Header%20Vulnerability%2
> 0Issue&Cache=False
> 
> Discovery: Drew Copley
> Exploitation: Riley Hassell
> 

As far as I can see there is no update to the UNIX versions.  The files
are all dated March 25.  The bulletin describes version 6 of the Flash
player as the fix, however that doesn't seem to be available for
anything other than Windows and Mac.  Am I missing something?
-Scott

-- 
Scott Lampert
<[EMAIL PROTECTED]>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

Public Key: http://www.lampert.org/public_key.asc



msg08785/pgp0.pgp
Description: PGP signature

Re: EEYE: Macromedia Shockwave Flash Malformed Header Overflow

[ismail donmez]

Unix version is still vulnerable as Macromedia didnt
updated its Flash plugin for Unix systems.

__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

[RHSA-2002:133-13] Updated bind packages fix buffer overflow in resolver library

[bugzilla]

-
   Red Hat, Inc. Red Hat Security Advisory

Synopsis:  Updated bind packages fix buffer overflow in resolver library
Advisory ID:   RHSA-2002:133-13
Issue date:2002-07-01
Updated on:2002-08-08
Product:   Red Hat Linux
Keywords:  bind libbind buffer overflow resolver library
Cross references:  
Obsoletes: RHSA-2002:105
CVE Names: CAN-2002-0651
-

1. Topic:

Various versions of the ISC BIND resolver libraries are vulnerable to a
buffer overflow attack.  Updated BIND packages are now available to fix
this issue.

2. Relevant releases/architectures:

Red Hat Linux 6.2 - alpha, i386, sparc

Red Hat Linux 7.0 - alpha, i386

Red Hat Linux 7.1 - alpha, i386, ia64

Red Hat Linux 7.2 - i386, ia64

Red Hat Linux 7.3 - i386

3. Problem description:

ISC BIND (Berkeley Internet Name Domain) is an implementation of the DNS
(Domain Name System) protocols. BIND includes a DNS server (named),
which resolves host names to IP addresses; a resolver library
(routines for applications to use when interfacing with DNS); and
various tools.
 
A buffer overflow vulnerability exists in multiple implementations of DNS
resolver libraries.  Applications that utilize vulnerable DNS resolver
libraries may be affected.  A remote attacker who is able to send malicious
DNS responses could potentially exploit this vulnerability to execute
arbitrary code or cause a denial of service on a vulnerable system. 

Red Hat Linux does not ship with any applications or libraries that link 
against the BIND resolver libraries; however, third party code may be affected.

The updated bind packages included in this errata contain the patches from
8.3.3 which fix the buffer overflow applied (backported) to the 9.2.1 sources.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which are
not installed but included in the list will not be updated.  Note that you
can also use wildcards (*.rpm) if your current directory *only* contains the
desired RPMs.

Please note that this update is also available via Red Hat Network.  Many
people find this an easier way to apply updates.  To use Red Hat Network,
launch the Red Hat Update Agent with the following command:

up2date

This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system.0

5. RPMs required:

Red Hat Linux 6.2:

SRPMS:
ftp://updates.redhat.com/6.2/en/os/SRPMS/bind-9.2.1-0.6x.3.src.rpm

alpha:
ftp://updates.redhat.com/6.2/en/os/alpha/bind-9.2.1-0.6x.3.alpha.rpm
ftp://updates.redhat.com/6.2/en/os/alpha/bind-devel-9.2.1-0.6x.3.alpha.rpm
ftp://updates.redhat.com/6.2/en/os/alpha/bind-utils-9.2.1-0.6x.3.alpha.rpm

i386:
ftp://updates.redhat.com/6.2/en/os/i386/bind-9.2.1-0.6x.3.i386.rpm
ftp://updates.redhat.com/6.2/en/os/i386/bind-devel-9.2.1-0.6x.3.i386.rpm
ftp://updates.redhat.com/6.2/en/os/i386/bind-utils-9.2.1-0.6x.3.i386.rpm

sparc:
ftp://updates.redhat.com/6.2/en/os/sparc/bind-9.2.1-0.6x.3.sparc.rpm
ftp://updates.redhat.com/6.2/en/os/sparc/bind-devel-9.2.1-0.6x.3.sparc.rpm
ftp://updates.redhat.com/6.2/en/os/sparc/bind-utils-9.2.1-0.6x.3.sparc.rpm

Red Hat Linux 7.0:

SRPMS:
ftp://updates.redhat.com/7.0/en/os/SRPMS/bind-9.2.1-0.70.2.src.rpm

alpha:
ftp://updates.redhat.com/7.0/en/os/alpha/bind-9.2.1-0.70.2.alpha.rpm
ftp://updates.redhat.com/7.0/en/os/alpha/bind-devel-9.2.1-0.70.2.alpha.rpm
ftp://updates.redhat.com/7.0/en/os/alpha/bind-utils-9.2.1-0.70.2.alpha.rpm

i386:
ftp://updates.redhat.com/7.0/en/os/i386/bind-9.2.1-0.70.2.i386.rpm
ftp://updates.redhat.com/7.0/en/os/i386/bind-devel-9.2.1-0.70.2.i386.rpm
ftp://updates.redhat.com/7.0/en/os/i386/bind-utils-9.2.1-0.70.2.i386.rpm

Red Hat Linux 7.1:

SRPMS:
ftp://updates.redhat.com/7.1/en/os/SRPMS/bind-9.2.1-0.71.1.src.rpm

alpha:
ftp://updates.redhat.com/7.1/en/os/alpha/bind-9.2.1-0.71.1.alpha.rpm
ftp://updates.redhat.com/7.1/en/os/alpha/bind-devel-9.2.1-0.71.1.alpha.rpm
ftp://updates.redhat.com/7.1/en/os/alpha/bind-utils-9.2.1-0.71.1.alpha.rpm

i386:
ftp://updates.redhat.com/7.1/en/os/i386/bind-9.2.1-0.71.1.i386.rpm
ftp://updates.redhat.com/7.1/en/os/i386/bind-devel-9.2.1-0.71.1.i386.rpm
ftp://updates.redhat.com/7.1/en/os/i386/bind-utils-9.2.1-0.71.1.i386.rpm

ia64:
ftp://updates.redhat.com/7.1/en/os/ia64/bind-9.2.1-0.71.1.ia64.rpm
ftp://updates.redhat.com/7.1/en/os/ia64/bind-devel-9.2.1-0.71.1.ia64.rpm
ftp://updates.redhat.com/7.1/en/os/ia64/bind-utils-9.2.1-0.71.1.ia64.rpm

Red Hat Linux 7.2:

SRPMS:
ftp://updates.redhat.com/7.2/en/os/SRPMS/bind-9.2.1-1.7x.2.src.rpm

i386:
ftp://updates.redhat.com/7.2/en/

Re: [SNS Advisory No.55 rev.2] Eudora 5.x for Windows Buffer Overflow Vulnerability

[John Pettitt]

At 06:15 PM 8/7/2002, Atsushi Nishimura wrote:
>--
>SNS Advisory No.55
>Eudora 5.x for Windows Buffer Overflow Vulnerability rev.2
>
>Problem first discovered: 6 Jun 2002
>Published: 5 Aug 2002
>Last revised: 8 Aug 2002
>--
>
>Overview:
>-
>   Eudora 5.x for Windows contains a buffer overflow vulnerability,
>   which could allow a remote attacker to execute arbitrary code.
>
>Problem Description:
>
>   Eudora developed and distributed by QUALCOMM Inc.
>   (http://www.qualcomm.com/), is a Mail User Agent running on Windows
>   95/98/2000/ME/NT 4.0 and MacOS 8.1 or later.
>
>   The buffer overflow occurs when Eudora receives a message using 139 bytes
>   or more of string as a boundary, which is used to divide a multi-part
>   message into separate parts. In our verification environment, we have
>   found that this could allow arbitrary commands to be executed.
>

For postfix users adding the following to header_checks should guard 
against this problem

/boundary=.{138,}$/REJECT MIME boundary too long

Not that only the most recent version of postfix understand mime so in 
older versions (pre 20020525) nested mime won't be blocked by this.

John



John Pettitt Email: [EMAIL PROTECTED]

"Do what you feel in your heart to be right for you'll be criticized anyway."
   
- 
Eleanor Roosevelt

Re: [VulnWatch] iDEFENSE Security Advisory: iSCSI Default Configuration File Settings

[Mike Caudill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


The Cisco PSIRT would like clarify the issue raised in the following 
iDEFENSE Security Advisory.

The installation script for the linux-iscsi drivers on Cisco's worldwide
web site (http://www.cisco.com/) and the corresponding mirrored distributions
on SourceForge (http://sourceforge.net/) installs the /etc/iscsi.conf file 
with mode 0600 (read/write only by the file owner which is set to the root 
user).  Therefore, installations of linux-iscsi installed from a distribution
downloaded from Cisco or SourceForge are not vulnerable.  Other Linux 
distributors may repackage the iSCSI drivers setting the file permissions 
appropriately for their own distribution.   

Since the /etc/iscsi.conf file contains CHAP passwords, this file should 
not be readable or writable by anyone other than the root user.   If you 
are running a version of the linux-iscsi drivers from another vendor, you
should both inspect the permissions on the /etc/iscsi.conf file and patch
your systems when those vendors issue their respective patches for the issue.

Also, let me take this opportunity to remind folks that vulnerabilities 
within any Cisco product should be reported directly to "[EMAIL PROTECTED]"
or "[EMAIL PROTECTED]".  At the very least we can assist with the
verification of the vulnerability.
 
- -Mike-


-BEGIN PGP SIGNATURE-
Version: PGP 6.5.2

iQA/AwUBPVLsHZPS/wbyNnWcEQJ53gCfY9MIBnFXDk6yVbpMVMSv3oVr6FIAn0Dc
y3DuunME0m7s2pChKiTDvJzW
=7o1f
-END PGP SIGNATURE-



> David Endler <[EMAIL PROTECTED]> [2002-08-08 10:30] wrote:
> iDEFENSE Security Advisory 08.08.2002 
> iSCSI Default Configuration File Settings
> 
> 
> DESCRIPTION 
> 
> iSCSI is a popular new protocol that allows the SCSI protocol 
> to be used over traditional IP networks. This allows for SAN 
> like storage arrays without requiring new network 
> infrastructure. iSCSI’s primary authentication mechanism for 
> users is the CHAP protocol (Challenge Handshake Authentication 
> Protocol), which is very resilient against replay attacks and 
> provides strong protection for the user’s password. The CHAP 
> protocol requires the user’s password to connect, and in order 
> to automate this process the user must provide the cleartext 
> password to the system that is then stored, typically in 
> cleartext, so that it will be accessible when needed. Care 
> must be taken to ensure configuration files containing the 
> cleartext password are properly protected.  For more 
> information on the CHAP protocol please see RFC 1994. 
> 
> The primary iSCSI implementation for Linux, “Linux-iSCSI” is a 
> freely available software package primarily maintained by 
> Cisco Systems. This package stores it primary configuration 
> directives in the file:
> 
> /etc/iscsi.conf
> 
> This file is created world writeable by default and no mention 
> is made in the file of the importance of protecting it from 
> being read by attackers. At least one vendor has shipped this 
> file world readable in the default configuration of a beta 
> release of an operating system, when notified they stated it 
> would be fixed in the release version of the operating system.
> 
> ANALYSIS
> 
> Any authentication systems that require cleartext passwords to 
> be stored should be carefully audited to ensure that passwords 
> are properly protected. This problem can also potentially 
> affect numerous packages, ranging from NTP and BIND to iSCSI 
> all of which require stored passwords or secrets. 
> 
> DETECTION
> 
> Check the permissions on the file:
> 
> /etc/iscsi.conf
> 
> The file should be owned by the user and group root, and only 
> the root user should be granted read and write access to the 
> file, all other permissions should be removed (i.e. file 
> permissions should be 0400) 
> 
> VENDOR RESPONSE
> 
> Red Hat has confirmed that the file /etc/iscsi.conf was set 
> world readable in the Limbo Beta, and that it will be fixed in 
> the next release version of Red Hat Linux. SuSE has confirmed 
> that the file permissions are set correctly on 
> /etc/iscsi.conf. No other major Linux vendors appear to be 
> shipping the iSCSI package yet. 
> 
> DISCOVERY CREDIT
> 
> Kurt Seifried ([EMAIL PROTECTED])
> 
> DISCLOSURE TIMELINE
> 
> July 11, 2002:Problem found on Red Hat Linux Limbo Beta #1
> Initial contacts sent to Red Hat, SuSE and Cisco
> 
> July 12, 2002:SuSE confirms file mode 600 by default, not 
> vulnerable
> Email sent to Matthew Franz at Cisco, additional Cisco 
> employees also contacted, iSCSI for Linux is an external 
> project at Cisco, PSIRT was not used, no response ever 
> received. 
> 
> July 17, 2002:   iDEFENSE client disclosure
> 
> July 29, 20022:  Problem confirmed in Red Hat Limbo Beta #2, 
> Red Hat contacted again, no response received. 
> 
> August 6, 2002:  No update of Linux iSCSI, nor mention of 
> problem on website. 
> 
> August 8, 2002:  Public Advisory
> 
> 
>

MDKSA-2002:048 - mod_ssl update

[Mandrake Linux Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Mandrake Linux Security Update Advisory


Package name:   mod_ssl
Advisory ID:MDKSA-2002:048
Date:   August 8th, 2002
Affected versions:  7.1, 7.2, 8.0, 8.1, 8.2, Corporate Server 1.0.1,
Single Network Firewall 7.2


Problem Description:

 Frank Denis discovered an off-by-one error in mod_ssl dealing with the
 handling of older configuration directorives (the rewrite_command
 hook).  A malicious user could use a specially-crafted .htaccess file
 to execute arbitrary commands as the apache user or execute a DoS
 against the apache child processes.

 This vulnerability is fixed in mod_ssl 2.8.10; patches have been
 applied to correct this problem in these packages.


References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0653
  http://marc.theaimsgroup.com/?l=apache-modssl&m=102491918531562


Updated Packages:

 Linux-Mandrake 7.1:
 8f336f83c0ad7ba0f21da3f805839b77  7.1/RPMS/mod_ssl-2.8.5-3.1mdk.i586.rpm
 9f28eb3330d357a7bb7e27fb16da757b  7.1/SRPMS/mod_ssl-2.8.5-3.1mdk.src.rpm

 Linux-Mandrake 7.2:
 39ce2c8b476fd8069c8f0fe7aedbef21  7.2/RPMS/mod_ssl-2.8.5-3.1mdk.i586.rpm
 9f28eb3330d357a7bb7e27fb16da757b  7.2/SRPMS/mod_ssl-2.8.5-3.1mdk.src.rpm

 Mandrake Linux 8.0:
 3f8e7d148ea509d27d0e59587ac86602  8.0/RPMS/mod_ssl-2.8.5-3.1mdk.i586.rpm
 9f28eb3330d357a7bb7e27fb16da757b  8.0/SRPMS/mod_ssl-2.8.5-3.1mdk.src.rpm

 Mandrake Linux 8.0/ppc:
 d9e727172d7147dc3ec9140c24fcacff  ppc/8.0/RPMS/mod_ssl-2.8.5-3.1mdk.ppc.rpm
 9f28eb3330d357a7bb7e27fb16da757b  ppc/8.0/SRPMS/mod_ssl-2.8.5-3.1mdk.src.rpm

 Mandrake Linux 8.1:
 7817c09901d4be439fd00bfd4cf9cc1b  8.1/RPMS/mod_ssl-2.8.5-3.1mdk.i586.rpm
 9f28eb3330d357a7bb7e27fb16da757b  8.1/SRPMS/mod_ssl-2.8.5-3.1mdk.src.rpm

 Mandrake Linux 8.1/ia64:
 f55a946cac1b64bf4c9b1952aa9b779a  ia64/8.1/RPMS/mod_ssl-2.8.5-3.1mdk.ia64.rpm
 9f28eb3330d357a7bb7e27fb16da757b  ia64/8.1/SRPMS/mod_ssl-2.8.5-3.1mdk.src.rpm

 Mandrake Linux 8.2:
 406eee7d9607cf40f5cea3376fe38697  8.2/RPMS/mod_ssl-2.8.7-3.1mdk.i586.rpm
 9e421423dc9cef30f0a1b04a49ab87da  8.2/SRPMS/mod_ssl-2.8.7-3.1mdk.src.rpm

 Mandrake Linux 8.2/ppc:
 01fc7c44707f19136d6f31b75ad754e1  ppc/8.2/RPMS/mod_ssl-2.8.7-3.1mdk.ppc.rpm
 9e421423dc9cef30f0a1b04a49ab87da  ppc/8.2/SRPMS/mod_ssl-2.8.7-3.1mdk.src.rpm

 Corporate Server 1.0.1:
 8f336f83c0ad7ba0f21da3f805839b77  1.0.1/RPMS/mod_ssl-2.8.5-3.1mdk.i586.rpm
 9f28eb3330d357a7bb7e27fb16da757b  1.0.1/SRPMS/mod_ssl-2.8.5-3.1mdk.src.rpm

 Single Network Firewall 7.2:
 b22c66c49703a46c10507da989e72948  snf7.2/RPMS/mod_ssl-2.8.4-5.1mdk.i586.rpm
 6bf148ae0fe73cd6874d6c08b711ae10  snf7.2/SRPMS/mod_ssl-2.8.4-5.1mdk.src.rpm


Bug IDs fixed (see https://qa.mandrakesoft.com for more information):



To upgrade automatically, use MandrakeUpdate.  The verification of md5
checksums and GPG signatures is performed automatically for you.

If you want to upgrade manually, download the updated package from one 
of our FTP server mirrors and upgrade with "rpm -Fvh *.rpm".  A list of
FTP mirrors can be obtained from:

  http://www.mandrakesecure.net/en/ftp.php

Please verify the update prior to upgrading to ensure the integrity of
the downloaded package.  You can do this with the command:

  rpm --checksig 

All packages are signed by MandrakeSoft for security.  You can obtain
the GPG public key of the Mandrake Linux Security Team from:

  https://www.mandrakesecure.net/RPM-GPG-KEYS

Please be aware that sometimes it takes the mirrors a few hours to 
update.

You can view other update advisories for Mandrake Linux at:

  http://www.mandrakesecure.net/en/advisories/

MandrakeSoft has several security-related mailing list services that
anyone can subscribe to.  Information on these lists can be obtained by
visiting:

  http://www.mandrakesecure.net/en/mlist.php

If you want to report vulnerabilities, please contact

  [EMAIL PROTECTED]


Type Bits/KeyID Date   User ID
pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <[EMAIL PROTECTED]>


- -BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.0.7 (GNU/Linux)

mQGiBDlp594RBAC2tDozI3ZgQsE7XwxurJCJrX0L5vx7SDByR5GHDdWekGhdiday
L4nfUax+SeR9SCoCgTgPW1xB8vtQc8/sinJlMjp9197a2iKM0FOcPlkpa3HcOdt7
WKJqQhlMrHvRcsivzcgqjH44GBBJIT6sygUF8k0lU6YnMHj5MPc/NGWt8wCg9vKo
P0l5QVAFSsHtqcU9W8cc7wMEAJzQsAlnvPXDBfBLEH6u7ptWFdp0GvbSuG2wRaPl
hynHvRiE01ZvwbJZ

EEYE: Sun(TM) ONE / iPlanet Web Server 4.1 and 6.0 Remote Buffer Overflow

[Marc Maiffret]

Sun(TM) ONE / iPlanet Web Server 4.1 and 6.0 Remote Buffer Overflow

Release Date: August 8, 2002

Severity:
High (Remote SYSTEM/ROOT)

Systems Affected:
iPlanet 6.0 and prior

Description:
A vulnerability in transfer chunking can be exploited to remotely execute
code of an attacker's choice on a vulnerable machine. By sending a carefully
crafted session, an attacker can overwrite a section of the heap. Various
data structures in the overwritten heap can be manipulated to move attacker
supplied data to attacker supplied memory addresses, thereby altering the
flow of execution into an attacker supplied payload.

Note this variant is not the integer overflow affecting IIS and Apache that
was discovered during regression testing with Microsoft. This is another
variant relating to incorrect size calculation.

The following example will show the vulnerable condition:

**Begin Session
POST /EEYE.html HTTP/1.1
Host: www.EEYE2002.com
Transfer-Encoding: chunked
Content-Length: 22

4
EEYE
7FFF
[DATA]
**End Session**

[DATA] will overwrite heap memory. Increase or decrease depending on
implementation.

Technical Description:
The example session above overwrites a section of the heap that contains
data structures related to the Memory management system. By manipulating the
content of these structures, we can overwrite an arbitrary 4 bytes of memory
with an attacker supplied address.

It is widely assumed that the risk for these type of vulnerabilities is
fairly low due to the fact that addressing is dynamic and that you must use
brute force in your attack; however, this is false assumption and
exploitation can be successful with one attempt, across dll versions. An
attacker can overwrite static global variables, stored function pointers,
process management structures, memory management structures, or any number
of data types that will allow him to gain control of the target application
in one session.

Vendor Status:
Sun has released a security bulletin and patch:
http://www.sun.com/service/support/software/iplanet/alerts/transferencodinga
lert-23july2002.html

Credit: Riley Hassell

Greetings:
Eli, Kasia, Halvar, FX, and the three amigos K2, Dark Spyrit, and Joey.

Copyright (c) 1998-2002 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express consent of
eEye. If you wish to reprint the whole or any part of this alert in any
other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for
permission.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There are
NO warranties with regard to this information. In no event shall the author
be liable for any damages whatsoever arising out of or in connection with
the use or spread of this information. Any use of this information is at the
user's own risk.

Feedback
Please send suggestions, updates, and comments to:

eEye Digital Security
http://www.eEye.com
[EMAIL PROTECTED]

EEYE: Macromedia Shockwave Flash Malformed Header Overflow

[Marc Maiffret]

Macromedia Shockwave Flash Malformed Header Overflow

Release Date: August 8, 2002

Severity:
High (Remote Code Execution)

Systems Affected:
Macromedia Shockwave Flash - All Versions;
Unix and Windows; Netscape and Internet Explorer

Description:
While working on some pre-release eEye Retina CHAM tools, an exploitable
condition was discovered within the Shockwave Flash file format called SWF
(pronounced "SWIF").

Since this is a browser based bug, it makes it trivial to bypass firewalls
and attack the user at his desktop. Also, application browser bugs allow you
to target users based on the websites they visit, the newsgroups they read,
or the mailing lists they frequent. It is a "one button" push attack, and
using anonymous remailers or proxies for these attacks is possible.

This vulnerability has been proven to work with all versions of Macromedia
Flash on Windows and Unix, through IE and Netscape. It may be run wherever
Shockwave files may be displayed or attached, including: websites, email,
news postings, forums, Instant Messengers, and within applications utilizing
web-browsing functionality.

Technical Description:
The data header is roughly made out to:

[Flash signature][version (1)][File Length(A number of bytes too
short)][frame size (malformed)][Frame Rate (malformed)][Frame Count
(malformed)][Data]

By creating a malformed header we can supply more frame data than the
decoder is expecting. By supplying enough data we can overwrite a function
pointer address and redirect the flow of control to a specified location as
soon as this address is used. At the moment the overwritten address takes
control flow, an address pointing to a portion of our data is 8 bytes back
from the stack pointer. By using a relative jump we redirect flow into a
"call dword ptr [esp+N]", where N is the number of bytes from the stack
pointer. These "jump points" can be located in multiple loaded dll's. By
creating a simple tool using the debugging API and ReadMemory, you can
examine a process's virtual address space for useful data to help you with
your exploitation.

This is not to say other potentially vulnerable situations have not been
found in Macromedia's Flash. We discovered about seventeen others before we
ended our testing. We are working with Macromedia on these issues.

Protection:
Retina(R) Network Security Scanner already scans for this latest version of
Flash on users' systems. Ensure all users within your control upgrade their
systems.

Vendor Status:
Macromedia has released a patch for this vulnerability, available at:
http://www.macromedia.com/v1/handlers/index.cfm?ID=23293&Method=Full&Title=M
PSB02%2D09%20%2D%20Macromedia%20Flash%20Malformed%20Header%20Vulnerability%2
0Issue&Cache=False

Discovery: Drew Copley
Exploitation: Riley Hassell

Greetings: Hacktivismo!, Centra Spike

Copyright (c) 1998-2002 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express consent of
eEye. If you wish to reprint the whole or any part of this alert in any
other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for
permission.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There are
NO warranties with regard to this information. In no event shall the author
be liable for any damages whatsoever arising out of or in connection with
the use or spread of this information. Any use of this information is at the
user's own risk.

Feedback
Please send suggestions, updates, and comments to:

eEye Digital Security
http://www.eEye.com
[EMAIL PROTECTED]

MDKSA-2002:047 - util-linux update

[Mandrake Linux Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Mandrake Linux Security Update Advisory


Package name:   util-linux
Advisory ID:MDKSA-2002:047
Date:   August 8th, 2002
Affected versions:  7.1, 7.2, 8.0, 8.1, 8.2, Corporate Server 1.0.1,
Single Network Firewall 7.2


Problem Description:

 Michal Zalewski found a vulnerability in the util-linux package with
 the chfn utility.  This utility allows users to modify some information
 in the /etc/passwd file, and is installed setuid root.  Using a
 carefully crafted attack sequence, an attacker can exploit a complex
 file locking and modification race that would allow them to make
 changes to the /etc/passwd file.  To successfully exploit this
 vulnerability and obtain privilege escalation, there is a need for some
 administrator interaction, and the password file must over over 4kb in
 size; the attacker's entry cannot be in the last 4kb of the file.


References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0638
  http://www.kb.cert.org/vuls/id/405955


Updated Packages:

 Linux-Mandrake 7.1:
 4c5df1947b62460beb8df7592ef35c6e  7.1/RPMS/util-linux-2.10o-6.1mdk.i586.rpm
 fa4fd5a20bc4cbca324294e3ed712eb1  7.1/SRPMS/util-linux-2.10o-6.1mdk.src.rpm

 Linux-Mandrake 7.2:
 69f07cace4649f3d8326ea8866d95e4f  7.2/RPMS/util-linux-2.10o-6.1mdk.i586.rpm
 fa4fd5a20bc4cbca324294e3ed712eb1  7.2/SRPMS/util-linux-2.10o-6.1mdk.src.rpm

 Mandrake Linux 8.0:
 18a2dc6e74636bdf6b7be146dfa3d6cf  8.0/RPMS/util-linux-2.10s-3.2mdk.i586.rpm
 dd4a423ddc444a202176b09e5251f6fd  8.0/SRPMS/util-linux-2.10s-3.2mdk.src.rpm

 Mandrake Linux 8.0/ppc:
 55e49d1ad321c229a8468f11a43b2fb7  ppc/8.0/RPMS/util-linux-2.11h-3.5mdk.ppc.rpm
 25c5b47d39f8b1c0147930218ddaecd5  ppc/8.0/SRPMS/util-linux-2.11h-3.5mdk.src.rpm

 Mandrake Linux 8.1:
 889ba34fcb46d9c2c2f11cf4fa81dd23  8.1/RPMS/util-linux-2.11h-3.5mdk.i586.rpm
 25c5b47d39f8b1c0147930218ddaecd5  8.1/SRPMS/util-linux-2.11h-3.5mdk.src.rpm

 Mandrake Linux 8.1/ia64:
 2405d127006eef10e1d58e23866f0044  ia64/8.1/RPMS/util-linux-2.11h-3.5mdk.ia64.rpm
 25c5b47d39f8b1c0147930218ddaecd5  ia64/8.1/SRPMS/util-linux-2.11h-3.5mdk.src.rpm

 Mandrake Linux 8.2:
 f137a274c2969ca3b893e96902dee893  8.2/RPMS/losetup-2.11n-4.3mdk.i586.rpm
 c074a07a7f3c3fd92b0be2ebd02dff93  8.2/RPMS/mount-2.11n-4.3mdk.i586.rpm
 420c1537cb8260f984125fd6311dc3d1  8.2/RPMS/util-linux-2.11n-4.3mdk.i586.rpm
 240139061f653327735eb46c3009d245  8.2/SRPMS/util-linux-2.11n-4.3mdk.src.rpm

 Mandrake Linux 8.2/ppc:
 9260b9deba8a1e025e028217f99df3ed  ppc/8.2/RPMS/losetup-2.11n-4.3mdk.ppc.rpm
 abdbafa149f499409c31969ff081e818  ppc/8.2/RPMS/mount-2.11n-4.3mdk.ppc.rpm
 3adff58b4e961fa17c8be1d1224072a2  ppc/8.2/RPMS/util-linux-2.11n-4.3mdk.ppc.rpm
 240139061f653327735eb46c3009d245  ppc/8.2/SRPMS/util-linux-2.11n-4.3mdk.src.rpm

 Corporate Server 1.0.1:
 4c5df1947b62460beb8df7592ef35c6e  1.0.1/RPMS/util-linux-2.10o-6.1mdk.i586.rpm
 fa4fd5a20bc4cbca324294e3ed712eb1  1.0.1/SRPMS/util-linux-2.10o-6.1mdk.src.rpm

 Single Network Firewall 7.2:
 69f07cace4649f3d8326ea8866d95e4f  snf7.2/RPMS/util-linux-2.10o-6.1mdk.i586.rpm
 fa4fd5a20bc4cbca324294e3ed712eb1  snf7.2/SRPMS/util-linux-2.10o-6.1mdk.src.rpm


Bug IDs fixed (see https://qa.mandrakesoft.com for more information):



To upgrade automatically, use MandrakeUpdate.  The verification of md5
checksums and GPG signatures is performed automatically for you.

If you want to upgrade manually, download the updated package from one 
of our FTP server mirrors and upgrade with "rpm -Fvh *.rpm".  A list of
FTP mirrors can be obtained from:

  http://www.mandrakesecure.net/en/ftp.php

Please verify the update prior to upgrading to ensure the integrity of
the downloaded package.  You can do this with the command:

  rpm --checksig 

All packages are signed by MandrakeSoft for security.  You can obtain
the GPG public key of the Mandrake Linux Security Team from:

  https://www.mandrakesecure.net/RPM-GPG-KEYS

Please be aware that sometimes it takes the mirrors a few hours to 
update.

You can view other update advisories for Mandrake Linux at:

  http://www.mandrakesecure.net/en/advisories/

MandrakeSoft has several security-related mailing list services that
anyone can subscribe to.  Information on these lists can be obtained by
visiting:

  http://www.mandrakesecure.net/en/mlist.php

If you want to report vulnerabilities, please contact

  [EMAIL PROTECTED]
_

[SECURITY] [DSA 147-1] New mailman packages fix cross-site scripting problem

[Martin Schulze]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 147-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
August 8th, 2002   
- --

Package: mailman
Vulnerability  : cross-site scripting
Problem-Type   : remote
Debian-specific: no
CVE Id : CAN-2002-0388

A cross-site scripting vulnerability was discovered in mailman, a
software to manage electronic mailing lists.  When a properly crafted
URL is accessed with Internet Explorer (other browsers don't seem to
be affected), the resulting webpage is rendered similar to the real
one, but the javascript component is executed as well, which could be
used by an attacker to get access to sensitive information.  The new
version for Debian 2.2 also includes backports of security related
patches from mailman 2.0.11.

This problem has been fixed in version 2.0.11-1woody2 for the current
stable distribution (woody), in version 1.1-10.1 for the old stable
distribution (woody) and in version 2.0.12-1 for the unstable
distribution (sid).

We recommend that you upgrade your mailman package.

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 2.2 alias potato
- -

  Source archives:

http://security.debian.org/pool/updates/main/m/mailman/mailman_1.1-10.1.dsc
  Size/MD5 checksum:  528 91d75b840f97ab2dcd700678e5c03d4a
http://security.debian.org/pool/updates/main/m/mailman/mailman_1.1-10.1.diff.gz
  Size/MD5 checksum:22053 adb539c2a3709490a58416ea69ec92cd
http://security.debian.org/pool/updates/main/m/mailman/mailman_1.1.orig.tar.gz
  Size/MD5 checksum:   322247 42d499f4e1de6959c50b20a4eb0f432a

  Alpha architecture:

http://security.debian.org/pool/updates/main/m/mailman/mailman_1.1-10.1_alpha.deb
  Size/MD5 checksum:   329118 0b9ba1dc599532594dd9c30787e1fed3

  ARM architecture:

http://security.debian.org/pool/updates/main/m/mailman/mailman_1.1-10.1_arm.deb
  Size/MD5 checksum:   327118 0ab80d4de1d9c674d7971e3cb91dca2c

  Intel IA-32 architecture:

http://security.debian.org/pool/updates/main/m/mailman/mailman_1.1-10.1_i386.deb
  Size/MD5 checksum:   328680 58aab5cf2c13a03952f22097c7224e01

  Motorola 680x0 architecture:

http://security.debian.org/pool/updates/main/m/mailman/mailman_1.1-10.1_m68k.deb
  Size/MD5 checksum:   328190 84b30c21c3e0bce5b1f6f5778d4b34e7

  PowerPC architecture:

http://security.debian.org/pool/updates/main/m/mailman/mailman_1.1-10.1_powerpc.deb
  Size/MD5 checksum:   328926 527f56d4dbe531d3889a8aaf61d73729

  Sun Sparc architecture:

http://security.debian.org/pool/updates/main/m/mailman/mailman_1.1-10.1_sparc.deb
  Size/MD5 checksum:   334170 bcec29e94554042ba97f8330aeac04fe


Debian GNU/Linux 3.0 alias woody
- 

  Source archives:

http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody2.dsc
  Size/MD5 checksum:  595 5cceabc484906689b7408f71869dfb59

http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody2.diff.gz
  Size/MD5 checksum:30899 dd977c232b4deab55ab45a39e306fa10
http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11.orig.tar.gz
  Size/MD5 checksum:   415129 915264cb1ac8d7b78ea9eff3ba38ee04

  Alpha architecture:


http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody2_alpha.deb
  Size/MD5 checksum:   460872 5434c7767498b7966072d5c4f77ff22b

  ARM architecture:


http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody2_arm.deb
  Size/MD5 checksum:   458520 759b2a9aa822ec6ce37087e98dcd9546

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody2_i386.deb
  Size/MD5 checksum:   474860 ed7707ac59ea0901db6a7d4519193bdb

  Intel IA-64 architecture:


http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody2_ia64.deb
  Size/MD5 checksum:   461646 cb36836e6f69fc3c788f4c3c2127

  HP Precision architecture:


http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody2_hppa.deb
  Size/MD5 checksum:   459152 e9db053ea86b48f66e28ab0ca96bae15

  Motorola 680x0 architecture:


http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody2_m68k.deb
  Size/MD5 checksum:   458594 db02b66740d0a14cdeda930e36c

Security Update: [CSSA-2002-035.0] Linux: local off by one in cvsd

[security]

To: [EMAIL PROTECTED] [EMAIL PROTECTED] 
[EMAIL PROTECTED] [EMAIL PROTECTED]

__

Caldera International, Inc.  Security Advisory

Subject:Linux: local off by one in cvsd 
Advisory number:CSSA-2002-035.0
Issue date: 2002 August 08
Cross reference:
__


1. Problem Description

There is a locally exploitable vulnerability in the cvsd program.


2. Vulnerable Supported Versions

System  Package
--

OpenLinux 3.1.1 Server  prior to cvs-1.11-8.i386.rpm
prior to cvs-doc-ps-1.11-8.i386.rpm

OpenLinux 3.1.1 Workstation prior to cvs-1.11-8.i386.rpm
prior to cvs-doc-ps-1.11-8.i386.rpm

OpenLinux 3.1 Serverprior to cvs-1.11-8.i386.rpm
prior to cvs-doc-ps-1.11-8.i386.rpm

OpenLinux 3.1 Workstation   prior to cvs-1.11-8.i386.rpm
prior to cvs-doc-ps-1.11-8.i386.rpm


3. Solution

The proper solution is to install the latest packages. Many
customers find it easier to use the Caldera System Updater, called
cupdate (or kcupdate under the KDE environment), to update these
packages rather than downloading and installing them by hand.


4. OpenLinux 3.1.1 Server

4.1 Package Location

ftp://ftp.caldera.com/pub/updates/OpenLinux/3.1.1/Server/CSSA-2002-035.0/RPMS

4.2 Packages

446921ba85f2f865d698060ab344d189cvs-1.11-8.i386.rpm
11ddbffdbf9310b24364b2b91d851acccvs-doc-ps-1.11-8.i386.rpm

4.3 Installation

rpm -Fvh cvs-1.11-8.i386.rpm
rpm -Fvh cvs-doc-ps-1.11-8.i386.rpm

4.4 Source Package Location

ftp://ftp.caldera.com/pub/updates/OpenLinux/3.1.1/Server/CSSA-2002-035.0/SRPMS

4.5 Source Packages

0e5b474050456ed691d77fc8ce5825becvs-1.11-8.src.rpm


5. OpenLinux 3.1.1 Workstation

5.1 Package Location


ftp://ftp.caldera.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2002-035.0/RPMS

5.2 Packages

d24451d87b1c7424f12bb41d4873c3dfcvs-1.11-8.i386.rpm
035d93df5ab69f025f7d08a583977658cvs-doc-ps-1.11-8.i386.rpm

5.3 Installation

rpm -Fvh cvs-1.11-8.i386.rpm
rpm -Fvh cvs-doc-ps-1.11-8.i386.rpm

5.4 Source Package Location


ftp://ftp.caldera.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2002-035.0/SRPMS

5.5 Source Packages

ba797e325ccc15beff8506f27ee4436ecvs-1.11-8.src.rpm


6. OpenLinux 3.1 Server

6.1 Package Location

ftp://ftp.caldera.com/pub/updates/OpenLinux/3.1/Server/CSSA-2002-035.0/RPMS

6.2 Packages

1f3a09e4fcc1a8a0d011a6e7fcd0d810cvs-1.11-8.i386.rpm
ff3e5b2acdd60e4b0492b212603a0d23cvs-doc-ps-1.11-8.i386.rpm

6.3 Installation

rpm -Fvh cvs-1.11-8.i386.rpm
rpm -Fvh cvs-doc-ps-1.11-8.i386.rpm

6.4 Source Package Location

ftp://ftp.caldera.com/pub/updates/OpenLinux/3.1/Server/CSSA-2002-035.0/SRPMS

6.5 Source Packages

c54cf8725ca2d24535e3abe86524fcb8cvs-1.11-8.src.rpm


7. OpenLinux 3.1 Workstation

7.1 Package Location


ftp://ftp.caldera.com/pub/updates/OpenLinux/3.1/Workstation/CSSA-2002-035.0/RPMS

7.2 Packages

cf5125e9586da6217df51051f66eb8d6cvs-1.11-8.i386.rpm
4bce0b96a28195c75878515b6a3dcvs-doc-ps-1.11-8.i386.rpm

7.3 Installation

rpm -Fvh cvs-1.11-8.i386.rpm
rpm -Fvh cvs-doc-ps-1.11-8.i386.rpm

7.4 Source Package Location


ftp://ftp.caldera.com/pub/updates/OpenLinux/3.1/Workstation/CSSA-2002-035.0/SRPMS

7.5 Source Packages

05f22c4bfcb98b826fcbb85e1d81f637cvs-1.11-8.src.rpm


8. References

Specific references for this advisory:
http://archives.neohapsis.com/archives/vulnwatch/2002-q2/0081.html

Caldera security resources:
http://www.caldera.com/support/security/index.html

This security fix closes Caldera incidents sr865452, fz521139,
erg712068.


9. Disclaimer

Caldera International, Inc. is not responsible for the misuse
of any of the information we provide on this website and/or
through our security advisories. Our advisories are a service
to our customers intended to promote secure installation and
use of Caldera products.


10. Acknowledgements

David Reign ([EMAIL PROTECTED]) discovered and reported
this vulnerability. Larry Jones (the maintain

Re: White paper: Exploiting the Win32 API.

[Simos Xenitellis]

Dear All,
The issue of vulnerabilities in event-driven systems has been mentioned
last month (7th July 2002) in the vuln-dev mailling list at
http://online.securityfocus.com/archive/82/280912/2002-07-04/2002-07-10/0
Perhaps vuln-dev is not that popular as bugtraq :'(. Time to switch
mailling lists.

As part of my studies (http://www.isg.rhul.ac.uk/~simos/) I examined
security issues in event-driven systems and the results have been
published in two (academic) papers, found at
http://www.isg.rhul.ac.uk/~simos/pub/

For the demonstration of these issues, there is a page available at
http://www.isg.rhul.ac.uk/~simos/event_demo/. There are also a
demonstration application and some exploitation ideas.

Regarding the issue whether event-driven system vulnerabilities are a
new type of attack or not, depends on how you classify a new attack. One
way to classify it is to regard an application as an independent entity
that can be attacked from specific types of "dangerous inputs" like
command line parameters, reading data from a file (like "gets()" reading
from STDIN) or reading data from the network. We describe an input as
dangerous if an attacker can manipulate it somehow. The command line
parameters of a SUID application is dangerous input, the cookies that a
WWW server is receiving from a WWW browser is dangerous FOR the WWW
server, the cookies that a WWW browser receives from a WWW server is
dangerous FOR the WWW browser and so on. In [Wheeler, 2002]** there is
such a list of dangerous inputs. 

Thus, one way to classify classes of vulnerabilities is to arrange by
inputs that a potential attacker can manipulate. In our case, events
form such an input that an attacker can manipulate. Thus they can be
technically a new class of attacks. 

These vulnerabilities exist in Windows because an attacker can
enumerate other people's windows and find the window handles. Then, the
attacker can send crafted events to those windows. The problem arises
from the fact that a "normal" user can send events to an
"administrative" account. The reason I see this happening is that of
usability. You can copy and paste between Windows from different users
and it's flexible to do so.

Furthermore, it is common in event-driven systems like Windows to have
"interface-based" security, that is, an application using the "window
controls" like text boxes to enforce security. An attacker can bypass
these security measures. It is similar to the JavaScript filtering in
specific WWW pages for information sent to CGI scripts. You can bypass
JavaScript and sent directly to the CGI script.

In addition, as [Forrester et al., 2000]* have shown, you have the
added issue of an application malfunctioning if it receives a sequence
of events that it was not designed to receive. The internal state of the
running application gets messed up and you can possible make it do
things that it should not do. This is due to the complicated
interactions of the different events that an application can receive and
can have consequences with other event-driven systems employed in
hardware devices, ATMs and so on.

Finally, an additional issue is the richness of the parameters of the
event types in Windows. You can put pointers to data structures (also
noted by [Forrester et al., 2000]*) or even addresses to subroutines as
it happens with the WM_TIMER event type [Xenitellis, 2002a]***,
[Xenitellis, 2002a] and more recently by Chris Paget at 
http://security.tombom.co.uk/shatter.html

By using the functionality of window stations you can fix the issue.
However, as long as the attacker and victim windows run in the same
window station, I cannot see currently a way to filter events. There
could be filtering if the receiver of events could know what is the
origin of the event and cut off those that it does not feel comfortable
with. This is putting access controls to the fuctionality of sending
events. However, it will make things more complicated for application
writers.

The way I see all these being handled by the software companies is
through the "risk management" cycle. If there is a high profile
incident, then something may happen. Otherwise things will stay the
same. It happens all the time. It's a rule of nature.

Thanks for your time,
Simos Xenitellis


* Forrester, J.E. and Miller, B.P. (2000) An empirical study of the
robustness of Windows NT applications using random testing, In
Proceedings of 4th USENIX Windows System Symposium, USENIX.

** Wheeler, David (2002), Secure Programming for Linux and Unix HOWTO.
http://www.dwheeler.com/secure-programs/, 2002.

*** Simeon Xenitellis (2002a), "Security vulnerabilities in Event-Driven
Systems ", IFIP / SEC2002 Security in the Information Society : Visions
and Perspectives, May 7-9, 2002, Cairo, Egypt, In Security in the
Information Society: Visions and Perspectives, Kluwer Academic Press,
pages 147-160.

 S

RE: IE SSL Vulnerability

[Pidgorny, Slav]

Hi Mike and the list,
 
That is one side of an issue I have described in 
 
http://online.securityfocus.com/archive/1/273101
 
 
I have to admit, your message captures attention much better than mine. All
for good, if that will be fixed.
 
The issue is known to both Microsoft and Verisign: the fix isn't on the todo
list for Microsoft, according to the feedback I have, and Verisign consider
that as a managed/manageable risk (it's more dangerous to their business,
really).
 
One quick note is that there's no basic constraints field in Verisign V1
certificates that are still available (their test CA used to issue V1).
 
I do agree: that's a problem to PKI implementations.
 
Regards
 
S. Pidgorny
 

-Original Message- 
From: Mike Benham [mailto:[EMAIL PROTECTED]] 
Sent: Tue 6/08/2002 9:03 AM 
To: [EMAIL PROTECTED] 
Cc: 
Subject: IE SSL Vulnerability




 
Internet Explorer SSL Vulnerability 08/05/02 
Mike Benham <[EMAIL PROTECTED]> 
http://www.thoughtcrime.org   

 
Abstract 

Internet Explorer's implementation of SSL contains a vulnerability that 
allows for an active, undetected, man in the middle attack.  No dialogs 
are shown, no warnings are given. 

 
Description 

In the normal case, the administrator of a web site might wish to provide 
secure communication via SSL.  To do so, the administrator generates a 
certificate and has it signed by a Certificate Authority.  The generated 
certificate should list the URL of the secure web site in the Common Name 
field of the Distinguished Name section. 

The CA verifies that the administrator legitimately owns the URL in the CN 
field, signs the certificate, and gives it back.  Assuming the 
administrator is trying to secure www.thoughtcrime.org, we now have the 
following certificate structure: 

[CERT - Issuer: VeriSign / Subject: VeriSign] 
-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] 

When a web browser receives this, it should verify that the CN field 
matches the domain it just connected to, and that it's signed using a 
known CA certificate.  No man in the middle attack is possible because it 
should not be possible to substitute a certificate with a valid CN and a 
valid signature. 

However, there is a slightly more complicated scenario.  Sometimes it is 
convenient to delegate signing authority to more localized authorities. 
In this case, the administrator of www.thoughtcrime.org would get a chain 
of certificates from the localized authority: 

[Issuer: VeriSign / Subject: VeriSign] 
-> [Issuer: VeriSign / Subject: Intermediate CA] 
   -> [Issuer: Intermediate CA / Subject: www.thoughtcrime.org] 

When a web browser receives this, it should verify that the CN field of 
the leaf certificate matches the domain it just connected to, that it's 
signed by the intermediate CA, and that the intermediate CA is signed by a 
known CA certificate.  Finally, the web browser should also check that all 
intermediate certificates have valid CA Basic Constraints. 

You guessed it, Internet Explorer does not check the Basic Constraints. 

== 
Exploit 

So what does this mean?  This means that as far as IE is concerned, anyone 
with a valid CA-signed certificate for ANY domain can generate a valid 
CA-signed certificate for ANY OTHER domain. 

As the unscrupulous administrator of www.thoughtcrime.org, I can generate 
a valid certificate and request a signature from VeriSign: 

[CERT - Issuer: VeriSign / Subject: VeriSign] 
-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] 

Then I generate a certificate for any domain I want, and sign it using my 
run-of-the-mill joe-blow CA-signed certificate: 

[CERT - Issuer: VeriSign / Subject: VeriSign] 
-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] 
   -> [CERT - Issuer: www.thoughtcrime.org / Subject: www.amazon.com] 

Since IE doesn't check the Basic Constraints on the www.thoughtcrime.org 
certificate, it accepts this certificate chain as valid for 
www.amazon.com. 

Anyone with any CA-signed certificate (and the corresponding private 
key) can spoof anyone else. 

 
Severity 

I would consider this to be incredibly severe.  Any of the standard 
connection hijacking techniques can be combined with this vulnerability 
to produce a successful man in the middle attack.  Since all you need is 
one constant CA-signed certificate (and the corresponding private key), an 
attacker can use that to generate spoofed certificates for other domains 
as connections are intercepted (on the fly).  Since no warnings are given 
and no dialogs are shown, the att