From: christophe.savin at tdf.fr (Christophe Savin)
Subject: Objet :Full-Disclosure Digest, Vol 1, Issue 2110 (De retour le mardi 28 décembre.)

 En mon absence,  toute demande concernant les r?seaux doit ?tre envoy?e au mail : ars_reseaux@....fr ou (ars_transpac pour tout incident li? ? ce r?seau)

En cas d'urgence, Vous pouvez contacter :
  La Hot-line R?seaux : 01 49 15 32 53  
  Fran?ois LEVEQUE au 01 49 15 30 56
  Pascal PAINPARAY au 01 49 15 31 36.
 
  Bonnes f?tes de fin d'ann?e.
  Christophe SAVIN


>>> full-disclosure 12/17/04 13:10 >>>

Send Full-Disclosure mailing list submissions to
	full-disclosure@...ts.netsys.com

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.netsys.com/mailman/listinfo/full-disclosure
or, via email, send a message with subject or body 'help' to
	full-disclosure-request@...ts.netsys.com

You can reach the person managing the list at
	full-disclosure-owner@...ts.netsys.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Full-Disclosure digest..."


Today's Topics:

   1. Re: TCP Port 42 port scans? What the heck over... 
      (Valdis.Kletnieks@...edu)
   2. Re: TCP Port 42 port scans? What the heck over... (Matt Ostiguy)
   3. Re: TCP Port 42 port scans?  What the heck over...
      (Maxime Ducharme)
   4. Re: Linux kernel scm_send local DoS (even multiplexed)
   5. iDEFENSE Security Advisory 12.15.04: Computer	Associates
      eTrust EZ	Antivirus Insecure File Permission Vulnerability
      (idlabs-advisories@...fense.com)
   6. Re: Linux kernel scm_send local DoS (Paul Starzetz)
   7. Re: Linux kernel IGMP vulnerabilities (Paul Starzetz)


----------------------------------------------------------------------

Message: 1
Date: Wed, 15 Dec 2004 09:58:18 -0500
From: Valdis.Kletnieks@...edu
Subject: Re: [Full-Disclosure] TCP Port 42 port scans? What the heck
	over... 
To: Matt Ostiguy <ostiguy@...il.com>
Cc: "Full-Disclosure \(E-mail\)" <full-disclosure@...ts.netsys.com>,
	James Lay <jlay@...riben.com>
Message-ID: <200412151458.iBFEwIsB021889@...ing-police.cc.vt.edu>
Content-Type: text/plain; charset="us-ascii"

On Mon, 13 Dec 2004 14:33:42 EST, Matt Ostiguy said:

> found an exploitable bug in the WINS service. Still, given how few
> people one would expect to have that port accessible through a
> firewall, or just how low the percentage of windows servers running
> WINS is

Do you have any actual data showing that either of those two numbers is low,
or are you relying on "if people have clue, these will be low"?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.netsys.com/pipermail/full-disclosure/attachments/20041215/e7e686df/attachment-0001.bin

------------------------------

Message: 2
Date: Wed, 15 Dec 2004 10:27:31 -0500
From: Matt Ostiguy <ostiguy@...il.com>
Subject: Re: [Full-Disclosure] TCP Port 42 port scans? What the heck
	over...
To: "Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>
Cc: "Full-Disclosure \(E-mail\)" <full-disclosure@...ts.netsys.com>
Message-ID: <3dc922c3041215072757528ef1@...l.gmail.com>
Content-Type: text/plain; charset=US-ASCII

On Wed, 15 Dec 2004 09:58:18 -0500, Valdis.Kletnieks@...edu
<Valdis.Kletnieks@...edu> wrote:
> On Mon, 13 Dec 2004 14:33:42 EST, Matt Ostiguy said:
> 
> > found an exploitable bug in the WINS service. Still, given how few
> > people one would expect to have that port accessible through a
> > firewall, or just how low the percentage of windows servers running
> > WINS is
> 
> Do you have any actual data showing that either of those two numbers is low,
> or are you relying on "if people have clue, these will be low"?
> 

Educated guess. Some reasons:

1. A single site /single subnet Windows shop can generally survive
without WINS - systems will battle to act as ad hoc browse master,
which will maintain the browse list of resources for network
neighborhood which it compiles from local subnet broadcasts. This
allows tons of places to run without WINS. If you have ever heard
people talk about Windows boxes being chatty from a network
perspective - this broadcast stuff is why.

2. WINS isn't installed by default on Win2k or 2k3, and I am fairly
certain it wasn't a default install on NT 4 either. DNS is required
for Active Directory on win2k and win2k3.

3. I can't think of a good reason to open WINS through a firewall.
Generally one would expect places with multiple sites to use site to
site connections, IPSec tunnels, and end user VPN tunnels, all of
which would negate the need to open it through the firewall.

4. Most places likely have 1 or 2 WINS servers per site. Any more, and
you are likely increasing pain and complexity (with push-pull
replication issues, etc) versus minimal redundancy gain.

So, DNS is about a universal requirement as there is these days, and a
fair of people are probably exposing their MS DNS service through the
firewall. A fair number are probably running MS DNS internally, and
doing something different externally, for security and/or  usage of
NAT reasons (their DNS server would resolve www.smallbizdomain.com to
192.168.1.2 if exposed to the net). I really cannot think of any
reason why anyone would expose WINS through a firewall, so it probably
leaves the few, the hardy, the stupid who have no firewall whatsoever.

Matt


------------------------------

Message: 3
Date: Wed, 15 Dec 2004 10:30:45 -0500
From: "Maxime Ducharme" <mducharme@...ergeneration.com>
Subject: Re: [Full-Disclosure] TCP Port 42 port scans?  What the heck
	over...
To: "Michael Scheidell" <scheidell@...nap.net>,	"Full-Disclosure
	\(E-mail\)" <full-disclosure@...ts.netsys.com>
Message-ID: <079501c4e2bb$0c16f790$b000a8c0@...ergeneration.com>
Content-Type: text/plain;	charset="iso-8859-1"


Hi

pdx.edu abuse team answered my notice rapidly and
they have taken the host offline for investigation.

Have a nice day

Maxime Ducharme
Programmeur / Sp?cialiste en s?curit? r?seau

----- Original Message ----- 
From: "Michael Scheidell" <scheidell@...nap.net>
To: "James Lay" <jlay@...riben.com>; "Full-Disclosure (E-mail)"
<full-disclosure@...ts.netsys.com>
Sent: Monday, December 13, 2004 8:34 PM
Subject: RE: [Full-Disclosure] TCP Port 42 port scans? What the heck over...


> hmm well, pdx.edu has a computer scanning the world, hit hundreds of other
hosts
>
> http://www.mynetwatchman.com/LID.asp?ip=131.252.116.141
>
>
> http://www.dshield.org/ipinfo.php?ip=131.252.116.141
>
>
> maybe you call them and ask?
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>



------------------------------

Message: 4
Date: Wed, 15 Dec 2004 13:52:22 +0100
From: even multiplexed <Shadow333@....at>
Subject: [Full-Disclosure] Re: Linux kernel scm_send local DoS
To: Paul Starzetz <ihaquer@...c.pl>
Cc: bugtraq@...urityfocus.com, vulnwatch@...nwatch.org,
	security@...c.pl,	full-disclosure@...ts.netsys.com
Message-ID: <41C03386.3040401@....at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Paul Starzetz wrote:

>On Wed, 15 Dec 2004, even multiplexed wrote:
>
>  
>
>>attention.i just wanted to ask if anyone has a tip for me how to 
>>quickfix this bug, without actually rebuilding a patched version of the 
>>kernel.
>>    
>>
>
>I don't think this is practicable, since the bugs reside in deep kernel 
>functions. You can not fix it just by disabling a particular syscall. You 
>have patch a running kernel binary, maybe someone comes up with this kind 
>of utlility.
>
>  
>
well, i was also examining the igmp exploit you posted earlier, that one 
was relatively easy to disable, by setting the following sysctl vars:

net.ipv4.igmp_max_msf = 0
net.ipv4.igmp_max_memberships = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1

since i dont really need igmp support on that server=)

its just that scm_send thing, that i didnt find any config option for...
so i guess that means either waiting till someone of the kernel 
maintainers release a patch, or get one of my friends, that is better on 
programming tasks, to fix that one...
all at all makes for quite a risky day for a shell provider...


------------------------------

Message: 5
Date: Wed, 15 Dec 2004 10:59:44 -0500
From: idlabs-advisories@...fense.com
Subject: [Full-Disclosure] iDEFENSE Security Advisory 12.15.04:
	Computer	Associates eTrust EZ	Antivirus Insecure File Permission
	Vulnerability
To: <idlabs-advisories@...fense.com>
Message-ID:
	<FB24803D1DF2A34FA59FC157B77C970503AD39FD@...erv04.idef.com>
Content-Type: text/plain;	charset="iso-8859-1"

Computer Associates eTrust EZ Antivirus Insecure File Permission
Vulnerability

iDEFENSE Security Advisory 12.15.04
http://www.idefense.com/application/poi/display?id=164
December 15, 2004

I. BACKGROUND

Computer Associates eTrust EZ Antivirus is antivirus protection software 
for home and business use. It provides complete protection, detection 
and elimination of thousands of computer viruses, worms, and Trojan 
Horse programs.

II. DESCRIPTION

Local exploitation of an insecure permission vulnerability in Computer
Associates eTrust EZ Antivirus allows attackers to escalate privileges
or disable protection.

Computer Associates eTrust EZ Antivirus is a product used to protect a
personal computer from virus infections. The vulnerability specifically 
exists in the default file Access Control List (ACL) settings that are 
applied during installation. When an administrator installs eTrust EZ 
Antivirus, the default ACL allows any user to modify the installed 
files. Because of the fact that some of the programs run as system 
services, a user can simply replace an installed eTrust EZ Antivirus 
file with their own malicious code that will later be executed with 
system privileges. One such file that would be a target for this is 
VetMsg.exe.

III. ANALYSIS

Successful exploitation allows local attackers to escalate privileges to 
the system level. It is also possible to use this vulnerability to 
simply disable protection by moving all of the executable files so that 
they cannot start upon a reboot.

IV. DETECTION

iDEFENSE has confirmed the existence of this vulnerability in eTrust EZ 
Antivirus version 7.0.1.4. According to Computer Associates, eTrust EZ
Antivirus r7.0.0 - r7.0.4 installed on PC's running Windows NT, 2000 or
XP and with NTFS formatted drives are also affected.

V. WORKAROUND

Apply proper Access Control List settings to the directory that eTrust 
EZ Antivirus is installed in. The ACL rules should make sure that no 
regular users can modify files in the directory.

VI. VENDOR RESPONSE

"With the assistance of iDEFENSE, Computer Associates has identified a
medium-risk vulnerability in the installation and updating components of
eTrustTM EZ Antivirus which may allow a local user to escalate their
user privileges on a PC and disable protection.

Effected generally available releases of eTrust EZ Antivirus include:
eTrust EZ Antivirus r7.0.0 - r7.0.4 installed on PC's
*- running Windows NT, 2000 or XP
*- with NTFS formatted drives

Computer Associates has actively addressed this issue in eTrust EZ
Antivirus r7.0.5 and above.

More information about this vulnerability and instructions on how to
upgrade to the latest version of eTrust EZ Antivirus can be found at:

http://crm.my-etrust.com/login.asp?username=guest&target=DOCUMENT&openparameter=2222

At Computer Associates, we take every report of exposure with the utmost
urgency, to ensure that no customer is left in a vulnerable situation. 
We have assigned this vulnerability the ID number 32054."

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2004-1149 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

10/26/2004  Initial vendor notification
10/29/2004  Initial vendor response
12/15/2004  Coordinated public disclosure

IX. CREDIT

The discoverer of this vulnerability wishes to remain anonymous.

Get paid for vulnerability research
http://www.idefense.com/poi/teams/vcp.jsp

X. LEGAL NOTICES

Copyright ? 2004 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice@...fense.com for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.




------------------------------

Message: 6
Date: Wed, 15 Dec 2004 13:31:30 +0100 (CET)
From: Paul Starzetz <ihaquer@...c.pl>
Subject: [Full-Disclosure] Re: Linux kernel scm_send local DoS
To: even multiplexed <Shadow333@....at>
Cc: bugtraq@...urityfocus.com, vulnwatch@...nwatch.org,
	security@...c.pl,	full-disclosure@...ts.netsys.com
Message-ID: <Pine.LNX.4.44.0412151328540.1826-100000@...c.pl>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 15 Dec 2004, even multiplexed wrote:

> attention.i just wanted to ask if anyone has a tip for me how to 
> quickfix this bug, without actually rebuilding a patched version of the 
> kernel.

I don't think this is practicable, since the bugs reside in deep kernel 
functions. You can not fix it just by disabling a particular syscall. You 
have patch a running kernel binary, maybe someone comes up with this kind 
of utlility.

-- 
Paul Starzetz
iSEC Security Research
http://isec.pl/




------------------------------

Message: 7
Date: Wed, 15 Dec 2004 13:34:33 +0100 (CET)
From: Paul Starzetz <ihaquer@...c.pl>
Subject: [Full-Disclosure] Re: Linux kernel IGMP vulnerabilities
To: stephen joseph butler <stephen.butler@...il.com>
Cc: bugtraq@...urityfocus.com, vulnwatch@...nwatch.org,
	security@...c.pl,	full-disclosure@...ts.netsys.com
Message-ID: <Pine.LNX.4.44.0412151331480.1826-100000@...c.pl>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 14 Dec 2004, stephen joseph butler wrote:

> > /proc/net/igmp
> > /proc/net/mcfilter
> > 
> > if both exist and are non-empty you are vulnerable!
> 
> Just to be clear: if "mcfilter" is empty, then you aren't vulnerable?
> I have both files, and "igmp" contains data, but "mcfilter" is empty.

You are not vulnerable to the remote attack described under (3), however 
your kernel may be still buggy. Note that you need a running process that 
has manipulated its multicast socket filters. If your kernel is buggy and 
you have local users such an application can always appear, at a time you 
don't expect it.

-- 
Paul Starzetz
iSEC Security Research
http://isec.pl/




------------------------------

_______________________________________________
Full-Disclosure mailing list
Full-Disclosure@...ts.netsys.com
https://lists.netsys.com/mailman/listinfo/full-disclosure


End of Full-Disclosure Digest, Vol 1, Issue 2110
************************************************

Powered by blists - more mailing lists