Full Disclosure mailing list archives
[Full-Disclosure] Objet :Full-disclosure Digest, Vol 1, Issue 2110 (De retour le mardi 28 décembre.)
From: "Christophe Savin" <christophe.savin () tdf fr>
Date: Wed, 22 Dec 2004 18:53:00 +0100
En mon absence, toute demande concernant les réseaux doit être envoyée au mail : ars_reseaux () tdf 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 () lists 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 () lists netsys com You can reach the person managing the list at full-disclosure-owner () lists 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 () vt 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 () idefense 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 () vt edu Subject: Re: [Full-disclosure] TCP Port 42 port scans? What the heck over... To: Matt Ostiguy <ostiguy () gmail com> Cc: "Full-Disclosure \(E-mail\)" <full-disclosure () lists netsys com>, James Lay <jlay () ameriben com> Message-ID: <200412151458.iBFEwIsB021889 () turing-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 () gmail com> Subject: Re: [Full-disclosure] TCP Port 42 port scans? What the heck over... To: "Valdis.Kletnieks () vt edu" <Valdis.Kletnieks () vt edu> Cc: "Full-Disclosure \(E-mail\)" <full-disclosure () lists netsys com> Message-ID: <3dc922c3041215072757528ef1 () mail gmail com> Content-Type: text/plain; charset=US-ASCII On Wed, 15 Dec 2004 09:58:18 -0500, Valdis.Kletnieks () vt edu <Valdis.Kletnieks () vt 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 isDo 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 () cybergeneration com> Subject: Re: [Full-disclosure] TCP Port 42 port scans? What the heck over... To: "Michael Scheidell" <scheidell () secnap net>, "Full-Disclosure \(E-mail\)" <full-disclosure () lists netsys com> Message-ID: <079501c4e2bb$0c16f790$b000a8c0 () cybergeneration 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 () secnap net> To: "James Lay" <jlay () ameriben com>; "Full-Disclosure (E-mail)" <full-disclosure () lists 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 () gmx at> Subject: [Full-disclosure] Re: Linux kernel scm_send local DoS To: Paul Starzetz <ihaquer () isec pl> Cc: bugtraq () securityfocus com, vulnwatch () vulnwatch org, security () isec pl, full-disclosure () lists netsys com Message-ID: <41C03386.3040401 () gmx 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 () idefense com Subject: [Full-disclosure] iDEFENSE Security Advisory 12.15.04: Computer Associates eTrust EZ Antivirus Insecure File Permission Vulnerability To: <idlabs-advisories () idefense com> Message-ID: <FB24803D1DF2A34FA59FC157B77C970503AD39FD () idserv04 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 () idefense 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 () isec pl> Subject: [Full-disclosure] Re: Linux kernel scm_send local DoS To: even multiplexed <Shadow333 () gmx at> Cc: bugtraq () securityfocus com, vulnwatch () vulnwatch org, security () isec pl, full-disclosure () lists netsys com Message-ID: <Pine.LNX.4.44.0412151328540.1826-100000 () isec 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 () isec pl> Subject: [Full-disclosure] Re: Linux kernel IGMP vulnerabilities To: stephen joseph butler <stephen.butler () gmail com> Cc: bugtraq () securityfocus com, vulnwatch () vulnwatch org, security () isec pl, full-disclosure () lists netsys com Message-ID: <Pine.LNX.4.44.0412151331480.1826-100000 () isec 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 () lists netsys com https://lists.netsys.com/mailman/listinfo/full-disclosure End of Full-Disclosure Digest, Vol 1, Issue 2110 ************************************************ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- [Full-Disclosure] Objet :Full-disclosure Digest, Vol 1, Issue 2110 (De retour le mardi 28 décembre.) Christophe Savin (Dec 22)