Re: [Full-disclosure] TippingPoint IPS Signature Evasion

2007-07-12 Thread Paul Craig
This is exploitable (and tested) against IIS 5/5.1 (IIS6/7 are not
vulnerable)
However, potentially other web servers are also vulnerable if they are
capable of decoding alternate unicode characters.

I also agree with you, blaming an IPS for not detecting attack which is
impossible in the wild would be very pointless.
Although IIS 5 is old, it is still relatively common.

Any further questions, feel free to ask.


Cheers,



Paul Craig
Security Consultant
Security-Assessment.com


-Original Message-
From: 3APA3A [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 12 July 2007 2:30 a.m.
To: Paul Craig
Cc: [EMAIL PROTECTED]; full-disclosure@lists.grok.org.uk
Subject: Re: TippingPoint IPS Signature Evasion

Dear Paul Craig,

--Wednesday, July 11, 2007, 1:37:03 AM, you wrote to
[EMAIL PROTECTED]:


PC http://www.test.com/scripts%c0%afcmd.exe
PC http://www.test.com/scripts%e0%80%afcmd.exe
PC http://www.test.com/scripts%c1%9ccmd.exe

PC Web servers located behind a Tippingpoint IPS device which are capable
PC of decoding alternate Unicode characters can be accessed, and exploited
PC without triggering the IPS device.

Can  you,  please, provide example of such server? Fatih Ozavci reported
similar   problem   with  Checkpoint  and  Halfwidth/Fullwidth  Unicode,
potential  attack  vector  was IIS with .Net framework, in this case IIS
seems not to be exploitable.

Blaming IPS it does not detect attack which is impossible in-the-wild is
nonsense. Blaming corporate-level IPS doesn't detect attack against SOHO
web server is acceptable nonsense :)

-- 
~/ZARAZA http://securityvulns.com/



___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


[Full-disclosure] CVE-2007-3693: Cross site scripting and information disclosure in gobi/helma

2007-07-12 Thread Hanno Böck
http://int21.de/cve/CVE-2007-3693-gobi.txt

Cross site scripting and information disclosure in gobi/helma

security advisory

References:
 http://gobi.helma.org/
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3693

Description:
 Cross site scripting describes attacks that allow to insert malicious
 html or javascript code via get or post forms. This can be used to steal
 session cookies.
 helma is a javascript-based application server, gobi is a cms
 based on helma. It's used on some popular pages, e. g. the ORF.
 The search-function can be used to inject javascript code.
 It will cause an information disclosure about the system path of helma
 if filled with invalid chars.

Workaround/Fix:
 There's no vendor fix. All input strings in web applications should be
 escaped properly and error messages containing paths should be suppressed
 on live installations.
 Vendor has been contacted 2007-04-12 and hasn't answered yet.

Sample injection URLs:
 http://gobi.helma.org/search/?q=scriptalert(1)/script
 http://dev.helma.org/search/?q=scriptalert(1)/script
 http://tv.orf.at/search?keyword=;scriptalert(1)/script

Sample information disclosure URLs:
 http://gobi.helma.org/search/?q=;
 http://dev.helma.org/search/?q=;

CVE Information:
 The Common Vulnerabilities and Exposures (CVE) project has assigned the
 name CVE-2007-3693 to this issue. This is a candidate for inclusion in
 the CVE list (http://cve.mitre.org/), which standardizes names for
 security problems.

Credits and copyright:
 This vulnerability was discovered by Hanno Boeck of schokokeks.org
 webhosting, http://www.schokokeks.org
 It's licensed under the creative commons attribution license:
 http://creativecommons.org/licenses/by/3.0/

 Hanno Boeck, 2007-07-12, http://www.hboeck.de


signature.asc
Description: This is a digitally signed message part.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] rPSA-2007-0138-1 gimp

2007-07-12 Thread rPath Update Announcements
rPath Security Advisory: 2007-0138-1
Published: 2007-07-11
Products: rPath Linux 1
Rating: Minor
Exposure Level Classification:
Indirect User Deterministic Unauthorized Access
Updated Versions:
gimp=/[EMAIL PROTECTED]:devel//1/2.2.16-0.1-1

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2949
https://issues.rpath.com/browse/RPL-1487

Description:
Previous versions of the gimp package are vulnerable to multiple
user-assisted buffer-overflow attacks in which gimp may execute
arbitrary code contained in maliciously-crafted image files.

Copyright 2007 rPath, Inc.
This file is distributed under the terms of the MIT License.
A copy is available at http://www.rpath.com/permanent/mit-license.html

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Re: [Full-disclosure] Wachovia Bank website sends confidential information

2007-07-12 Thread Bob Toxen
Wachovia Bank's Web Security people did phone me late yesterday to thank
me for raising the security issue.  They also stated that they were
investigating why my initial contacts with Wachovia did not result in
an appropriate response.

They said that they also were working with their legal people to determine
what notification to consumers, if any, was required due to the California
data breach law and similar laws elsewhere.

It was not made clear whether their phone call (and their correction
of the web page) was directly due to my posting on the Full-disclosure
list or because Steve Ragan saw my posting and contacted Wachovia.


For those who questioned whether I made sufficient attempts to contact
them, please note that I talked by phone both with customer support and
web support people and then FAXed the details to the web support person
who took my call.  Note that I bothered with this at all as a courtesy
to Wachovia.  Nobody paid me for my time.

For those who questioned whether I gave them sufficient time to react,
I stated in my FAX to them, in effect, that all they had to do within
7 days was to respond to the FAX and ask for more time to deal with
the problem.  I then waited 15 days, not 7, before posting on FD after
having received no response and seeing that the problem remained.

For those who questioned my motives and suggested that I deliberately
did not make sufficient effort to contact them, well, I detailed my
3 contacts above and then got no response for 15 days.  For those who
suggested I was motivated by fame, well, I already have that.  I won't
blow my horn here but anyone is welcome to do a Google search on me.

Wachovia has fixed the problem.  They are working to ensure that future
advisories are handled properly.  Thanks to all who responded.  Shall we
put this matter to bed?

Bob Toxen,
Horizon Network Security
http://www.verysecurelinux.com   [Network  Linux/Unix Security Consulting]
http://www.realworldlinuxsecurity.com [Our 5* book: Real World Linux Security]

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Re: [Full-disclosure] Does this exist ?

2007-07-12 Thread Dan Becker
Others have pointed out a database would work for common packets and  
yet others have pointed out much beyond that scope the idea is not  
feasible.

I have another question. Would moving the TCP stack to base 32 double  
traffic ?

We have enough alphanumeric characters to do so. Perhaps a designation  
of 1x000 instead of 0x000 to define the difference in base 32 to base  
16 respectively.

Or am I missing something you uber math types can explain to me.


  All message scanned for viruses with Clam Antivirus.

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Re: [Full-disclosure] Does this exist ?

2007-07-12 Thread Valdis . Kletnieks
On Thu, 12 Jul 2007 07:14:17 CDT, Dan Becker said:

 I have another question. Would moving the TCP stack to base 32 double  
 traffic ?

 We have enough alphanumeric characters to do so. Perhaps a designation  
 of 1x000 instead of 0x000 to define the difference in base 32 to base  
 16 respectively.

Umm.. That doesn't actually work.  For instance - in binary, one of the
addresses of this laptop is 128.173.14.107. First, let's look at it
in binary:

1000  1010 1101  1101 0011 1011

Representing that in base 16, you get 80 AD 0E 6B.  Representing it in
base 32 is still going to get you that same exact sequence of 32 bits on
the wire.

You may wish to read RFC791, especially section 3.1, which goes into great
detail about the on-the-wire format of the bits.

http://www.ietf.org/rfcs/rfc791.txt


pgpOVb6Nt4HVZ.pgp
Description: PGP signature
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Does this exist ?

2007-07-12 Thread Dan Becker
Quoting [EMAIL PROTECTED]:

 On Thu, 12 Jul 2007 07:14:17 CDT, Dan Becker said:

 I have another question. Would moving the TCP stack to base 32 double
 traffic ?

 We have enough alphanumeric characters to do so. Perhaps a designation
 of 1x000 instead of 0x000 to define the difference in base 32 to base
 16 respectively.

 Umm.. That doesn't actually work.  For instance - in binary, one of the
 addresses of this laptop is 128.173.14.107. First, let's look at it
 in binary:

 1000  1010 1101  1101 0011 1011

 Representing that in base 16, you get 80 AD 0E 6B.  Representing it in
 base 32 is still going to get you that same exact sequence of 32 bits on
 the wire.

 You may wish to read RFC791, especially section 3.1, which goes into great
 detail about the on-the-wire format of the bits.

 http://www.ietf.org/rfcs/rfc791.txt

Thank you for the reply. This is not helping my headache.

There simply has to be a way to represent a larger value than you  
transmit when you transmit.





  All message scanned for viruses with Clam Antivirus.

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


[Full-disclosure] iDefense Security Advisory 07.12.07: Red Hat Enterprise Linux init.d XFS Script chown Race Condition Vulnerability

2007-07-12 Thread iDefense Labs
Red Hat Enterprise Linux init.d XFS Script chown Race Condition
Vulnerability

iDefense Security Advisory 07.12.07
http://labs.idefense.com/intelligence/vulnerabilities/
Jul 12, 2007

I. BACKGROUND

XFS is the X Font Server, and is used to render fonts for the X Window
System. init.d refers to the startup and shutdown scripts used by
Linux distributions. These scripts are run by the init process to start
and stop various system services.

II. DESCRIPTION

Local exploitation of a race condition vulnerability in Red Hat Inc.'s
Enterprise Linux init.d XFS script allows an attacker to elevate their
privileges to root.

The XFS script is vulnerable to a race condition when it is started by
init, or by a system administrator. Specifically, it insecurely changes
the file permissions of a temporary file. This allows an attacker to
make any file on the system world writable.

III. ANALYSIS

Exploitation of this vulnerability results in an attacker gaining root
privileges on the affected system.

However, in order to exploit this, it is necessary for either the system
to be rebooted, or for the administrator to manually restart the XFS.

IV. DETECTION

iDefense has confirmed the existence of this vulnerability in Red Hat
Enterprise Linux version 4, and Fedora Core 6. Other versions may also
be affected.

V. WORKAROUND

iDefense is currently unaware of any workarounds for this issue.

VI. VENDOR RESPONSE

Red Hat has released errata updates for versions 4 and 5 of their
Enterprise Linux software. More information is available at the URLs
shown below.

https://rhn.redhat.com/errata/RHSA-2007-0519.html
https://rhn.redhat.com/errata/RHSA-2007-0520.html

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
name CVE-2007-3103 to this issue. This is a candidate for inclusion in
the CVE list (http://cve.mitre.org/), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

06/05/2007  Initial vendor notification
06/06/2007  Initial vendor response
07/12/2007  Coordinated public disclosure

IX. CREDIT

The discoverer of this vulnerability wishes to remain anonymous.

Get paid for vulnerability research
http://labs.idefense.com/methodology/vulnerability/vcp.php

Free tools, research and upcoming events
http://labs.idefense.com/

X. LEGAL NOTICES

Copyright © 2007 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 e-mail [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.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Re: [Full-disclosure] Does this exist ?

2007-07-12 Thread Valdis . Kletnieks
On Thu, 12 Jul 2007 12:10:46 CDT, Dan Becker said:

 There simply has to be a way to represent a larger value than you
 transmit when you transmit.

Why does there *have* to be a way?  There's 32 bits available, that can
represent 2**32 different addresses.  You want to represent more than 2**32
addresses, you'll need more bits (see IPv6).

Note that it's possible to use some trickery to represent a larger *range*.
For example, TCP Window Scaling, where (basically) you send a TCP option that
says Multiply all the windows by 8, or 16 or some other specified power-of-2.
The problem is that the number of different possible values doesn't change.
So for instance, the TCP window field in the header has 16 bits, so you can
represent 65536 different values 0, 1, 2, 3, 4,... 65534, 65535. WIth a window
scale of (say) 64, you can represent 0, 64, 128, 192, 255, ... 4194176,
4194240.  But there's still only 65536 different values - you can no longer
reresent 1-63, 65-127, and so on.



pgp8wAZhLZf7M.pgp
Description: PGP signature
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] FLEA-2007-0031-1: xfs

2007-07-12 Thread Foresight Linux Essential Announcement Service
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Foresight Linux Essential Advisory: 2007-0031-1
Published: 2007-07-12

Rating: Minor

Updated Versions:
xfs=/[EMAIL PROTECTED]:1-devel//1/1.0.4-2
group-dist=/[EMAIL PROTECTED]:1-devel//1/1.3.2-0.4-3

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3103
https://issues.rpath.com/browse/RPL-1485

Description:
Previous versions of the xfs package was vulnerable to a temporary-file
creation race condition which a local user could exploit to gain elevated
permissions.

- ---

Copyright 2007 Foresight Linux Project
This file is distributed under the terms of the MIT License.
A copy is available at http://www.foresightlinux.org/permanent/mit-license.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (GNU/Linux)

iQIVAwUBRpZ8NNfwEn07iAtZAQLMaw//ZLXWosf2WRLH1a3ELsI73XvVgpcSzl5O
2T31EMoTqKX5j9D8uXdhPeAAC2Ipe0GWVMTujwxgiec2ZmZd3P4onaM1iai6trAm
PmtIRuNm7q0l3DdFsp9lo+z5otDcQn/B85BFnJ27bck4kdCTwRrcB9lPtcjVCIqL
No6GYSat+tWtccfgJIKnXRziu83WKhLFurI7xoWV8g9k7CdhFOE1qhvv/ytQnB34
va1EAr1teqOW7WlcbUAGmPMHuggTrKeu/CBD83tGnnbGQKlUq9HKIGMLUWHE44xY
2aeCwPDXSxmTMvdtqlfxQzh0VPWfT+HOl5MaqhDg18tA5WHADME3JIO76Dvb4sHB
iQc4wtEzihP2pnve2pGId9rbC7oRRKTOGZzS790TGch6ElkjVXd9+rtsD34VODJp
NrSUquDnGGGj7hPC/Mp512JcTwwffal6azwaQSgW5MWKvEIhmw9i8xo2m5C05xZA
8LLj9ckwfH7em0w4VJ757SKJ4D1AKmMxvyxiNwEs0ZUBr4zvoKV/tHZUu1rEgow8
+DsEJKdfKb53wERtQA1WpGZe+VcJbM7yq0oy1ZZkYNxoZjZqCyE1PE4kXqtvfzpk
Fk2alSmk7aKeZ5GBz9Fzr54rBeei6rBRHtE5SKCR/lXZU8K3sB9q0byR950/w8JD
hfnXKo3J1eQ=
=Q7Si
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


[Full-disclosure] ZDI-07-039: Symantec AntiVirus Engine RAR File Parsing DoS Vulnerability

2007-07-12 Thread zdi-disclosures
ZDI-07-039: Symantec AntiVirus Engine RAR File Parsing DoS Vulnerability
http://www.zerodayinitiative.com/advisories/ZDI-07-039.html
July 12, 2007

-- CVE ID:
CVE-2007-3699

-- Affected Vendor:
Symantec

-- Affected Products:
Symantec AntiVirus Engine


-- TippingPoint(TM) IPS Customer Protection:
TippingPoint IPS customers have been protected against this
vulnerability since November 20, 2006 by Digital Vaccine protection
filter ID 4695,4824. For further product information on the TippingPoint 
IPS:

http://www.tippingpoint.com 

-- Vulnerability Details:
This vulnerability allows attackers to create a denial of service
condition on software with vulnerable installations of the Symantec's
AntiVirus engine. Authentication is not required to exploit this
vulnerability.

The specific flaw resides in a forged PACK_SIZE field of a RAR file
header. By setting this field to a specific value an infinite loop
denial of service condition will occur when the scanner processes the
file.

-- Vendor Response:
Symantec has issued an update to correct this vulnerability. More
details can be found at:

http://www.symantec.com/avcenter/security/Content/2007.07.11f.html

-- Disclosure Timeline:
2006.11.01 - Vulnerability reported to vendor
2006.11.20 - Digital Vaccine released to TippingPoint customers
2007.07.12 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by an anonymous researcher.

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, a division of 3Com, The Zero Day Initiative
(ZDI) represents a best-of-breed model for rewarding security
researchers for responsibly disclosing discovered vulnerabilities.

Researchers interested in getting paid for their security research
through the ZDI can find more information and sign-up at:

http://www.zerodayinitiative.com

The ZDI is unique in how the acquired vulnerability information is used.
3Com does not re-sell the vulnerability details or any exploit code.
Instead, upon notifying the affected product vendor, 3Com provides its
customers with zero day protection through its intrusion prevention
technology. Explicit details regarding the specifics of the
vulnerability are not exposed to any parties until an official vendor
patch is publicly available. Furthermore, with the altruistic aim of
helping to secure a broader user base, 3Com provides this vulnerability
information confidentially to security vendors (including competitors)
who have a vulnerability protection or mitigation product.

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is being sent by 3Com for the sole use of the intended recipient(s) and
may contain confidential, proprietary and/or privileged information.
Any unauthorized review, use, disclosure and/or distribution by any 
recipient is prohibited.  If you are not the intended recipient, please
delete and/or destroy all copies of this message regardless of form and
any included attachments and notify 3Com immediately by contacting the
sender via reply e-mail or forwarding to 3Com at [EMAIL PROTECTED] 
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


[Full-disclosure] ZDI-07-040: Symantec AntiVirus Engine CAB Parsing Heap Overflow Vulnerability

2007-07-12 Thread TSRT
ZDI-07-040: Symantec AntiVirus Engine CAB Parsing Heap Overflow
Vulnerability
http://www.zerodayinitiative.com/advisories/ZDI-07-040.html
July 12, 2007

-- CVE ID:
CVE-2007-0447

-- Affected Vendor:
Symantec

-- Affected Products:
Symantec AntiVirus Engine

-- TippingPoint(TM) IPS Customer Protection:
TippingPoint IPS customers have been protected against this
vulnerability since November 30, 2006 by Digital Vaccine protection
filter ID 4875. For further product information on the TippingPoint IPS:

http://www.tippingpoint.com 

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
systems with affected installations of Symantec's AntiVirus Engine.
User interaction is not required to exploit this vulnerability.

The specific flaw exists during the process of scanning multiple
maliciously formatted CAB archives. The parsing routine implicitly
trusts certain user-supplied values that can result in an exploitable
heap corruption.

-- Vendor Response:
Symantec has issued an update to correct this vulnerability. More
details can be found at:

http://www.symantec.com/avcenter/security/Content/2007.07.11f.html

-- Disclosure Timeline:
2006.11.09 - Vulnerability reported to vendor
2006.11.30 - Digital Vaccine released to TippingPoint customers
2007.07.12 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by an anonymous researcher.

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, a division of 3Com, The Zero Day Initiative
(ZDI) represents a best-of-breed model for rewarding security
researchers for responsibly disclosing discovered vulnerabilities.

Researchers interested in getting paid for their security research
through the ZDI can find more information and sign-up at:

http://www.zerodayinitiative.com

The ZDI is unique in how the acquired vulnerability information is used.
3Com does not re-sell the vulnerability details or any exploit code.
Instead, upon notifying the affected product vendor, 3Com provides its
customers with zero day protection through its intrusion prevention
technology. Explicit details regarding the specifics of the
vulnerability are not exposed to any parties until an official vendor
patch is publicly available. Furthermore, with the altruistic aim of
helping to secure a broader user base, 3Com provides this vulnerability
information confidentially to security vendors (including competitors)
who have a vulnerability protection or mitigation product.


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is being sent by 3Com for the sole use of the intended recipient(s) and
may contain confidential, proprietary and/or privileged information.
Any unauthorized review, use, disclosure and/or distribution by any 
recipient is prohibited.  If you are not the intended recipient, please
delete and/or destroy all copies of this message regardless of form and
any included attachments and notify 3Com immediately by contacting the
sender via reply e-mail or forwarding to 3Com at [EMAIL PROTECTED] 
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


[Full-disclosure] TPTI-07-12: Multiple Vendor Progress Server Heap Overflow Vulnerability

2007-07-12 Thread TSRT
TPTI-07-12: Multiple Vendor Progress Server Heap Overflow Vulnerability
http://dvlabs.tippingpoint.com/advisory/TPTI-07-12.html
July 12, 2007

-- CVE ID:
CVE-2007-2417

-- Affected Vendor:
Progress Software

-- Affected Products:
RSA Authentication Manager
Progress Database

-- TippingPoint(TM) IPS Customer Protection:
TippingPoint IPS customers have been protected against this
vulnerability since May 22, 2007 by Digital Vaccine protection
filter ID 5326. For further product information on the TippingPoint IPS:

http://www.tippingpoint.com 

-- Vulnerability Details:
This vulnerability allows attackers to execute arbitrary code on
vulnerable installations of RSA Authentication Manager and other
products that include the Progress server. User interaction is not
required to exploit this vulnerability.

The specific flaw exists in the Progress Server listening by default on
TCP ports 5520 and 5530. The _mprosrv.exe process trusts a user-supplied
DWORD size and attempts to receive that amount of data into a statically
allocated heap buffer. 

The user-supplied size parameter is used directly as an argument to
recv() as shown below:

_mprosrv.exe:
0044F24F mov eax, [esp+42Ch+buf] ; 1012 byte heap buffer
0044F253 push0   ; flags
0044F255 pushesi ; attacker-controlled size
0044F256 pusheax ; 1012 byte heap buffer
0044F257 pushedi ; s
0044F258 callrecv

The heap buffer which is received into is 1012 bytes. Sending more than
1012 bytes will overflow into subsequent heap chunks. This heap
corruption can be leveraged by an attacker to execute arbitrary code in
the context of the SYSTEM user.

-- Vendor Response:
RSA has made hot fixes available to registered users through RSA
Customer Support. For more information, please visit the RSA website
for the appropriate product:

For RSA ACE/Server 5.2, apply the following hot fix on top of Patch 1:
 
 
https://knowledge.rsasecurity.com/dlcpages/rsa_securid/securid_dlc_as52p.asp

For RSA Authentication Manager 6.0, apply the following hot fix on top
of the Patch 2 -  (scroll down to the second half of the page)
 
 
https://knowledge.rsasecurity.com/dlcpages/rsa_securid/securid_dlc_am60p2.asp

For RSA SecurID Appliance 2.0, apply the following hot fix on top of
the Upgrade 2.0.1:
 
 
https://knowledge.rsasecurity.com/dlcpages/rsa_securid/securid_dlc_app.asp

For RSA Authentication Manager 6.1, apply the 6.1.2 patch:
 
 
https://knowledge.rsasecurity.com/dlcpages/rsa_securid/securid_dlc_am60p2.asp

RSA recommends that all customers using RSA ACE/Server 5.2, RSA
Authentication Manager 6.0 and 6.1, and RSA SecurID Appliance 2.0
install the hot fixes. RSA states Notification was recently (June 28,
2007) sent to RSA SecurCare customers about the vulnerability and the
correct way to resolve it.

-- Disclosure Timeline:
2007.03.14 - Vulnerability reported to vendor
2007.05.22 - Digital Vaccine released to TippingPoint customers
2007.07.12 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by Aaron Portnoy, TippingPoint DVLabs.

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is being sent by 3Com for the sole use of the intended recipient(s) and
may contain confidential, proprietary and/or privileged information.
Any unauthorized review, use, disclosure and/or distribution by any 
recipient is prohibited.  If you are not the intended recipient, please
delete and/or destroy all copies of this message regardless of form and
any included attachments and notify 3Com immediately by contacting the
sender via reply e-mail or forwarding to 3Com at [EMAIL PROTECTED] 
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


[Full-disclosure] [ MDKSA-2007:146 ] - Updated perl-Net-DNS packages fix multiple vulnerabilities

2007-07-12 Thread security

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___
 
 Mandriva Linux Security Advisory MDKSA-2007:146
 http://www.mandriva.com/security/
 ___
 
 Package : perl-Net-DNS
 Date: July 12, 2007
 Affected: 2007.0, 2007.1, Corporate 3.0, Corporate 4.0
 ___
 
 Problem Description:
 
 A flaw was discovered in the perl Net::DNS module in the way it
 generated the ID field in a DNS query.  Because it is so predictable,
 a remote attacker could exploit this to return invalid DNS data
 (CVE-2007-3377).
 
 A denial of service vulnerability was found in how Net::DNS parsed
 certain DNS requests.  A malformed response to a DNS request could
 cause the application using Net::DNS to crash or stop responding
 (CVE-2007-3409).
 
 The updated packages have been patched to prevent these issues.
 ___

 References:
 
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3377
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3409
 ___
 
 Updated Packages:
 
 Mandriva Linux 2007.0:
 92d215a4965bb8d944c030cf1dd73a11  
2007.0/i586/perl-Net-DNS-0.58-1.1mdv2007.0.i586.rpm 
 06c1dd9d596004e261a9706060a4c167  
2007.0/SRPMS/perl-Net-DNS-0.58-1.1mdv2007.0.src.rpm

 Mandriva Linux 2007.0/X86_64:
 34bc7cfb39bd239dea991559a05f66b7  
2007.0/x86_64/perl-Net-DNS-0.58-1.1mdv2007.0.x86_64.rpm 
 06c1dd9d596004e261a9706060a4c167  
2007.0/SRPMS/perl-Net-DNS-0.58-1.1mdv2007.0.src.rpm

 Mandriva Linux 2007.1:
 cd6db816556ae5f3c172dafb5ee98002  
2007.1/i586/perl-Net-DNS-0.59-1.1mdv2007.1.i586.rpm 
 dc954016fe3924ab2a362285cd780636  
2007.1/SRPMS/perl-Net-DNS-0.59-1.1mdv2007.1.src.rpm

 Mandriva Linux 2007.1/X86_64:
 d9cbd72d34d8eab851473716740290f3  
2007.1/x86_64/perl-Net-DNS-0.59-1.1mdv2007.1.x86_64.rpm 
 dc954016fe3924ab2a362285cd780636  
2007.1/SRPMS/perl-Net-DNS-0.59-1.1mdv2007.1.src.rpm

 Corporate 3.0:
 338edc98b82b661a4245c8dfdea463fa  
corporate/3.0/i586/perl-Net-DNS-0.39-2.1.C30mdk.i586.rpm 
 eeeb5c182365d9726f36326892065015  
corporate/3.0/SRPMS/perl-Net-DNS-0.39-2.1.C30mdk.src.rpm

 Corporate 3.0/X86_64:
 e47654bec20760643ce0e4d7b78ab394  
corporate/3.0/x86_64/perl-Net-DNS-0.39-2.1.C30mdk.x86_64.rpm 
 eeeb5c182365d9726f36326892065015  
corporate/3.0/SRPMS/perl-Net-DNS-0.39-2.1.C30mdk.src.rpm

 Corporate 4.0:
 51e6714b343575136bf296a495c32de3  
corporate/4.0/i586/perl-Net-DNS-0.52-1.1.20060mlcs4.i586.rpm 
 862ceacd8ba656dee551039d5074dd46  
corporate/4.0/SRPMS/perl-Net-DNS-0.52-1.1.20060mlcs4.src.rpm

 Corporate 4.0/X86_64:
 99cb67c8f400c7f826ce63702e863508  
corporate/4.0/x86_64/perl-Net-DNS-0.52-1.1.20060mlcs4.x86_64.rpm 
 862ceacd8ba656dee551039d5074dd46  
corporate/4.0/SRPMS/perl-Net-DNS-0.52-1.1.20060mlcs4.src.rpm
 ___

 To upgrade automatically use MandrivaUpdate or urpmi.  The verification
 of md5 checksums and GPG signatures is performed automatically for you.

 All packages are signed by Mandriva for security.  You can obtain the
 GPG public key of the Mandriva Security Team by executing:

  gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98

 You can view other update advisories for Mandriva Linux at:

  http://www.mandriva.com/security/advisories

 If you want to report vulnerabilities, please contact

  security_(at)_mandriva.com
 ___

 Type Bits/KeyID Date   User ID
 pub  1024D/22458A98 2000-07-10 Mandriva Security Team
  security*mandriva.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGlqB9mqjQ0CJFipgRAtR2AJ9k0gv3DiQhhRnitqXz+ZDG2OimbwCfacXe
aq9g2vyl8V79tBNKBAMG5VY=
=OBVo
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


[Full-disclosure] [Advisory] Phishing Vulnerability in Verisign Network

2007-07-12 Thread Aditya K Sood

Advisory : Phishing Vulnerability in Verisign Network
Dated :  5 July 2007
Severity : Critical

Explanation:

The Verisign Secured Network and Verisign Weblogs network is vulnerable to
phishing . The problem persists in the redirection links present which
allows third party redirection. The cause :

1. Redirection of traffic directly without visiting website.
2. The website wont check the link that is being called by the phisher.
3. Third party linking is possible.
4. Looping attack is also possible.

The vulnerable links are:

1. http://www.verisignsecured.com/Redirect.aspx?[ website name ]
2. http://www.weblogs.com/clickthru?url=[website name]

It is considered as vulnerable because the clickthru parameter can be
initialised
to any website not related to main website links respectively.

Examples:
1]http://www.weblogs.com/clickthru?url=http://www.unep.org/Documents.Multilingual/Default.asp?DocumentID='
 


2]http://www.weblogs.com/clickthru?url=http://www.weblogs.com/clickthru?url=http://www.pewinternet.org/report_display.asp?r=');--
 


3]http://www.verisignsecured.com/Redirect.aspx?http://www.unep.org/Documents.Multilingual/Default.asp?DocumentID='
 


4]http://www.verisignsecured.com/Redirect.aspx?http://www.weblogs.com/clickthru?url=http://www.weblogs.com/clickthru?url=http://www.pewinternet.org/report_display.asp?r=');--
 


5]http://www.verisignsecured.com/Redirect.aspx?http://www.weblogs.com/clickthru?url=http://www.weblogs.com/clickthru?url=http://www.weblogs.com/clickthru?url=http://www.google.com
 



Vendor Status : Reported.


Regards
Aditya K Sood
http://www.secniche.org



___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/