[Full-disclosure] [SECURITY] [DSA 1680-1] New clamav packages fix potential code execution

2008-12-04 Thread Florian Weimer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- 
Debian Security Advisory DSA-1680-1  [EMAIL PROTECTED]
http://www.debian.org/security/   Florian Weimer
December 04, 2008 http://www.debian.org/security/faq
- 

Package: clamav
Vulnerability  : buffer overflow, stack consumption
Problem type   : local (remote)
Debian-specific: no
CVE Id(s)  : CVE-2008-5050 CVE-2008-5314
Debian Bug : 505134 507624

Moritz Jodeit discovered that ClamAV, an anti-virus solution, suffers
from an off-by-one-error in its VBA project file processing, leading to
a heap-based buffer overflow and potentially arbitrary code execution
(CVE-2008-5050).

Ilja van Sprundel discovered that ClamAV contains a denial of service
condition in its JPEG file processing because it does not limit the
recursion depth when processing JPEG thumbnails (CVE-2008-5314).

For the stable distribution (etch), these problems have been fixed in
version 0.90.1dfsg-4etch16.

For the unstable distribution (sid), these problems have been fixed in
version 0.94.dfsg.2-1.

The testing distribution (lenny) will be fixed soon.

We recommend that you upgrade your clamav 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 4.0 alias etch
- ---

Source archives:

  
http://security.debian.org/pool/updates/main/c/clamav/clamav_0.90.1dfsg.orig.tar.gz
Size/MD5 checksum: 11610428 6dc18602b0aa653924d47316f9411e49
  
http://security.debian.org/pool/updates/main/c/clamav/clamav_0.90.1dfsg-4etch16.dsc
Size/MD5 checksum:  908 ebc60299a69aab41dfdb77e667e2857c
  
http://security.debian.org/pool/updates/main/c/clamav/clamav_0.90.1dfsg-4etch16.diff.gz
Size/MD5 checksum:   216130 5ae1da1b6351a13b5c385919960ca9b7

Architecture independent packages:

  
http://security.debian.org/pool/updates/main/c/clamav/clamav-base_0.90.1dfsg-4etch16_all.deb
Size/MD5 checksum:   201408 63e3898029276baf914fafa347747996
  
http://security.debian.org/pool/updates/main/c/clamav/clamav-docs_0.90.1dfsg-4etch16_all.deb
Size/MD5 checksum:  1003722 5d316f2ea821b441971b0e05e58e481d
  
http://security.debian.org/pool/updates/main/c/clamav/clamav-testfiles_0.90.1dfsg-4etch16_all.deb
Size/MD5 checksum:   158564 189a55ca25bdf9e03a0ae3b9f4a565e9

alpha architecture (DEC Alpha)

  
http://security.debian.org/pool/updates/main/c/clamav/libclamav2_0.90.1dfsg-4etch16_alpha.deb
Size/MD5 checksum:   373052 b59a6787be52e776d3b6238bac4e7fff
  
http://security.debian.org/pool/updates/main/c/clamav/clamav-daemon_0.90.1dfsg-4etch16_alpha.deb
Size/MD5 checksum:   182812 289769066d1883af6c455255725c1c81
  
http://security.debian.org/pool/updates/main/c/clamav/clamav-freshclam_0.90.1dfsg-4etch16_alpha.deb
Size/MD5 checksum:  9305338 e2d5290afa1484ffc3ee6abfc99a7e5f
  
http://security.debian.org/pool/updates/main/c/clamav/libclamav-dev_0.90.1dfsg-4etch16_alpha.deb
Size/MD5 checksum:   465410 ad42ee7f6355353575f05de54d67fa2b
  
http://security.debian.org/pool/updates/main/c/clamav/clamav-dbg_0.90.1dfsg-4etch16_alpha.deb
Size/MD5 checksum:   598714 6f862583fe87d09e3c3a3c288c75a787
  
http://security.debian.org/pool/updates/main/c/clamav/clamav-milter_0.90.1dfsg-4etch16_alpha.deb
Size/MD5 checksum:   180954 7122cfc98ec69b5b012d9794dc3f44cd
  
http://security.debian.org/pool/updates/main/c/clamav/clamav_0.90.1dfsg-4etch16_alpha.deb
Size/MD5 checksum:   862390 df3cb4e88d62cbc641d1c48c14d5c551

amd64 architecture (AMD x86_64 (AMD64))

  
http://security.debian.org/pool/updates/main/c/clamav/clamav_0.90.1dfsg-4etch16_amd64.deb
Size/MD5 checksum:   856672 bc8b467814eb5b76b6a165ee7a7d
  
http://security.debian.org/pool/updates/main/c/clamav/clamav-milter_0.90.1dfsg-4etch16_amd64.deb
Size/MD5 checksum:   177968 c2aa51b550584931f3f1b7b1f6df6508
  
http://security.debian.org/pool/updates/main/c/clamav/clamav-freshclam_0.90.1dfsg-4etch16_amd64.deb
Size/MD5 checksum:  9302094 cd9f623cfb4f23d1777cf21e830d74b2
  
http://security.debian.org/pool/updates/main/c/clamav/libclamav-dev_0.90.1dfsg-4etch16_amd64.deb
Size/MD5 checksum:   355706 e0db968192096ac9215ab676b5750c7d
  
http://security.debian.org/pool/updates/main/c/clamav/clamav-daemon_0.90.1dfsg-4etch16_amd64.deb
Size/MD5 checksum:   179200 99ba1e041488e76a7d6e457ed51536f0
  

[Full-disclosure] Advisory 06/2008: PHP ZipArchive::extractTo() Directory Traversal Vulnerability

2008-12-04 Thread Stefan Esser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


 SektionEins GmbH
www.sektioneins.de

 -= Security  Advisory =-


 Advisory: PHP ZipArchive::extractTo() Directory Traversal Vulnerability
 Release Date: 2008/12/04
Last Modified: 2008/12/04
   Author: Stefan Esser [stefan.esser[at]sektioneins.de]

  Application: PHP 5 = 5.2.6
 Severity: PHP applications using ZipArchive::extractTo() to unpack zip
   archive files can be tricked to overwrite arbitrary files
   writable by the webserver which might result in PHP remote
   code execution
 Risk: Medium
Vendor Status: Vendor has released PHP 5.2.7 which contains an updated
   ZipArchive::extractTo() method that flattens the filename
   stored inside zip archives before unpacking
Reference: http://www.sektioneins.de/advisories/SE-2008-06.txt


Overview:

  Quote from http://www.php.net
  PHP is a widely-used general-purpose scripting language that
   is especially suited for Web development and can be embedded
   into HTML.

  PHP comes with the zip extension that provides the ZipArchive
  class for zip archive manipulation. During an audit of a large
  scale PHP applications that uses ZipArchive::extractTo() to
  unpack user uploaded zip archives to temporary directories it
  was discovered that ZipArchive::extractTo() does not flatten
  the filenames stored inside the zip archives.

  Therefore it is possible to create zip archives containing
  relative filenames that when unpacked will create or overwrite
  files outside of the temporary directory.

  In the applications like the one in question this results in
  a remote PHP code execution vulnerability, because we are
  able to drop new PHP files in writable directories within
  the webserver's document root directory.


Details:

  No details required. To exploit this an attacker just needs to
  create a zip archive containing filenames like

 ../../../../../../../../../../../var/www/wr_dir/evil.php

  An easy way to achieve that is to just store a file with a long
  name inside the zip archive and then change it with a hex editor


Proof of Concept:

  SektionEins GmbH is not going to release a proof of concept
  exploit for this vulnerability.


Disclosure Timeline:

  23. June 2008 - Notified [EMAIL PROTECTED]
  04. December 2008 - PHP developers released PHP 5.2.7
  04. December 2008 - Public Disclosure


Recommendation:

  It is recommended to upgrade to the latest version of PHP
  which also fixes additional vulnerabilities reported by
  third parties.

  Grab your copy at:
  http://www.php.net/get/php-5.2.7.tar.bz2/from/a/mirror


CVE Information:

  The Common Vulnerabilities and Exposures project (cve.mitre.org) has
  not assigned a name to this vulnerability yet.


GPG-Key:

  pub  1024D/15ABDA78 2004-10-17 Stefan Esser [EMAIL PROTECTED]
  Key fingerprint = 7806 58C8 CFA8 CE4A 1C2C  57DD 4AE1 795E 15AB DA78


Copyright 2008 SektionEins GmbH. All rights reserved.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkk3qT4ACgkQSuF5XhWr2nho0QCgi6JABGlJUbf7Z3eR61J7KQMH
JhoAnRBzGsfci/OsDBEVtv+UBE2UZ+I1
=X9Yi
-END PGP SIGNATURE-

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


Re: [Full-disclosure] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread Chris Jeane
The Project Chroma Project website reads(I have highlighted the colors in
black so that they are readable):

*Green level: There is negligible threat to online security.
*Ok this one is pretty simple.*

Yellow level : There is a minimal level of threat, and this must be
monitored and contained.
*The SAN ISC says : We are currently *tracking* a significant new threat.
The impact is either unknown or expected to be minor to the infrastructure.
However, local impact could be significant. Users are advised to take
immediate specific *action to contain* the impact.
You are giving an abbreviation version of something that already exists and
is excepted.

*Orange level: This level of threat indicates there are parties who are
actively engaging in cyber-warfare. Caution is required when online.
*Caution is *always* required when online. If you are in an area
(country/province/region) that is affected by cyber attacks you will have
limited/no access the internet. If only your company/person is being
assaulted from cyberspace the attack would probably go unnoticed by this
monitoring system. If the attackers were commiting a DDOS attack on several
specific non-infastructure targets, you internet access my slow/go dark, but
is that really a threat to you? or one you can protect agianst?

*Red level: This level indicates a full blown cyber-war. It indicates
very high probability of all communications being intercepted.
*The use of the term 'full blown cyber-war' seems like a overarching scare
tactic. We have yet to see what cyber-warfare looks like. Estonia was a one
sided cyber ambush, not two entites engaging in war. The alerts should be
more generic and accompanied by an acessment of the actual *current *situation.
If something like 'Code Red' where to infect the internet agian this alert
calling it cyber-war would be a misnomer.*

While homeland security's implementation does not seem to have a real
world merit, such a threat level would certainly be very useful in the
online security realm.
*Who is this useful to: Security processionals, end users, governmental
agencies? How and why as similar systems already exist?*

Please disseminate this announcement of the
project Chroma levels for online security. The immediate mission of
the project is to be picked up by the antivirus and security tools
vendors, so as to add the color codes to their products and provide
users with a tangible measure of their online security.
*Yellow is not a tangible measure of their online security. If perhaps an
Online Security/IPS package knew that a DDoS attack was coming for an
address segment of the internet and it requested that I block traffic from
those attackers until an all clear or *Green *
status was given.* *That is tangible and actionable.*

Current status: Threat level Yellow.*
Your current is higher than SANS ISC. Do you know something they don't?

On Wed, Dec 3, 2008 at 9:57 PM, Luke Scharf [EMAIL PROTECTED]wrote:

 Mike C wrote:
  If you really want to change state of security for the n00bs,
  spread the knowledge, not the colors.
 
 
  Thats what project Chroma is all about.. Are you on board?!
 

 This already exists, backed up by some hard-core security competence:
http://isc.sans.org/infocon.html
http://isc.sans.org/

 Has it changed the world?

 -Luke

 ___
 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] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread James Rankin
full-blown cyber war

This indicates that Mike C is N3tN00b, and is also about to join him on the
spam filter. Flame away, cos I won't hear you Mike/N3tty

2008/12/4 Chris Jeane [EMAIL PROTECTED]

 The Project Chroma Project website reads(I have highlighted the colors in
 black so that they are readable):

 *Green level: There is negligible threat to online security.
 *
 Ok this one is pretty simple.*

 Yellow level : There is a minimal level of threat, and this must be
 monitored and contained.
 *
 The SAN ISC says : We are currently *tracking* a significant new threat.
 The impact is either unknown or expected to be minor to the infrastructure.
 However, local impact could be significant. Users are advised to take
 immediate specific *action to contain* the impact.
 You are giving an abbreviation version of something that already exists and
 is excepted.

 *Orange level: This level of threat indicates there are parties who are
 actively engaging in cyber-warfare. Caution is required when online.
 *
 Caution is *always* required when online. If you are in an area
 (country/province/region) that is affected by cyber attacks you will have
 limited/no access the internet. If only your company/person is being
 assaulted from cyberspace the attack would probably go unnoticed by this
 monitoring system. If the attackers were commiting a DDOS attack on several
 specific non-infastructure targets, you internet access my slow/go dark, but
 is that really a threat to you? or one you can protect agianst?

 *Red level: This level indicates a full blown cyber-war. It indicates
 very high probability of all communications being intercepted.
 *
 The use of the term 'full blown cyber-war' seems like a overarching scare
 tactic. We have yet to see what cyber-warfare looks like. Estonia was a one
 sided cyber ambush, not two entites engaging in war. The alerts should be
 more generic and accompanied by an acessment of the actual *current 
 *situation.
 If something like 'Code Red' where to infect the internet agian this alert
 calling it cyber-war would be a misnomer.*

 While homeland security's implementation does not seem to have a real
 world merit, such a threat level would certainly be very useful in the
 online security realm.
 *
 Who is this useful to: Security processionals, end users, governmental
 agencies? How and why as similar systems already exist?*

 Please disseminate this announcement of the
 project Chroma levels for online security. The immediate mission of
 the project is to be picked up by the antivirus and security tools
 vendors, so as to add the color codes to their products and provide
 users with a tangible measure of their online security.
 *
 Yellow is not a tangible measure of their online security. If perhaps an
 Online Security/IPS package knew that a DDoS attack was coming for an
 address segment of the internet and it requested that I block traffic from
 those attackers until an all clear or *Green *
 status was given.* *That is tangible and actionable.*

 Current status: Threat level Yellow.*
 Your current is higher than SANS ISC. Do you know something they don't?

 On Wed, Dec 3, 2008 at 9:57 PM, Luke Scharf [EMAIL PROTECTED]wrote:

 Mike C wrote:
  If you really want to change state of security for the n00bs,
  spread the knowledge, not the colors.
 
 
  Thats what project Chroma is all about.. Are you on board?!
 

 This already exists, backed up by some hard-core security competence:
http://isc.sans.org/infocon.html
http://isc.sans.org/

 Has it changed the world?

 -Luke

 ___
 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/

___
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] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread Valdis . Kletnieks
On Wed, 03 Dec 2008 21:57:27 CST, Luke Scharf said:

 This already exists, backed up by some hard-core security competence:
 http://isc.sans.org/infocon.html
 http://isc.sans.org/
 
 Has it changed the world?

The most useful aspect of the SANS color meter is the fact that when it
changes, they *also* publish an in-depth article about the threat that made
them change the level.  So you as a security professional can say Wow, the
meter just flickered, I better go read the latest and act on it...

Note the last 4 words there. That's the distinction between a useful service
and a color-du-jour marker - actionable information.

Or you can just point your favorite RSS reader at the article feed:

http://isc.sans.org/diary.html?rss

and have *it* chirp at you when there's a new article.


pgpmzZtofCBd4.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] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread Razi Shaban
On Thu, Dec 4, 2008 at 5:03 PM, Chris Jeane [EMAIL PROTECTED] wrote:
 The Project Chroma Project website reads(I have highlighted the colors in
 black so that they are readable):

 Levels crap


On Thu, Dec 4, 2008 at 6:28 PM, Razi Shaban [EMAIL PROTECTED] wrote:
 On Thu, Dec 4, 2008 at 6:02 PM, Chris Jeane [EMAIL PROTECTED] wrote:
 Exactly. Which is why there is a need of a system that contains more
 information and less cookie cutter levels. We still don't know what a
 cyber-war looks like. One country could attack the transport/power systems
 of a third party that supplies/supports their target. This is all
 hypothetical, but there is a high probability of collateral damage.


 You misunderstood me. What I was getting at is that your ideas,
 including a cyber-war and all this leveling, show that you are about
 as uninformed as n3td3v. Please take your nub spam somewhere else.

 --
 Razi Shaban


To explain the idea of leveling: The internet is a gigantic place. No
matter when and from where you connect, it is out to get you, you
individually. Also, large-scale cyber wars are a constant thing. I am
aware of three very large-scale wars taking place at the moment, does
that increase or decrease the risk any user would be taking by
accessing the internet? Of course not. The concept of basing a
levelling system on a few organized national or private attempts to do
something or another is ridiculous; the Estonian attack compromised
less than 0.0001% of all cyber attacks during that time period.

The matter of the fact is, attempting to take the hugely complex and
intricate dark side of the internet and summarize it in a color level
is absurd. In fact, attempting to summarize it at all is ridiculous.
Summarizing implies that you know everything about the topic. Anyone
trying to summarize this knows nothing when he/she realizes the
vastness of the internet.

tl;dr : attempting to summarize the internet is less fruitful than
throwing ice cubes at the sun, but it requires much lesser
intelligence to do the first.

--
Razi Shaban

___
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 1681-1] New Linux 2.6.24 packages fix several vulnerabilities

2008-12-04 Thread dann frazier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA-1681-1[EMAIL PROTECTED]
http://www.debian.org/security/   Dann Frazier, Alexander Prinsier
December 04, 2008   http://www.debian.org/security/faq
- --

Package: linux-2.6.24
Vulnerability  : denial of service/privilege escalation
Problem type   : local/remote
Debian-specific: no
CVE Id(s)  : CVE-2008-3528 CVE-2008-4554 CVE-2008-4576 CVE-2008-4618
 CVE-2008-4933 CVE-2008-4934 CVE-2008-5025 CVE-2008-5029
 CVE-2008-5134 CVE-2008-5182 CVE-2008-5300

Several vulnerabilities have been discovered in the Linux kernel that
may lead to a denial of service or privilege escalation. The Common
Vulnerabilities and Exposures project identifies the following
problems:

CVE-2008-3528

Eugene Teo reported a local DoS issue in the ext2 and ext3
filesystems.  Local users who have been granted the privileges
necessary to mount a filesystem would be able to craft a corrupted
filesystem that causes the kernel to output error messages in an
infinite loop.

CVE-2008-4554

Milos Szeredi reported that the usage of splice() on files opened
with O_APPEND allows users to write to the file at arbitrary
offsets, enabling a bypass of possible assumed semantics of the
O_APPEND flag.

CVE-2008-4576

Vlad Yasevich reported an issue in the SCTP subsystem that may
allow remote users to cause a local DoS by triggering a kernel
oops.

CVE-2008-4618

Wei Yongjun reported an issue in the SCTP subsystem that may allow
remote users to cause a local DoS by triggering a kernel panic.

CVE-2008-4933

Eric Sesterhenn reported a local DoS issue in the hfsplus
filesystem.  Local users who have been granted the privileges
necessary to mount a filesystem would be able to craft a corrupted
filesystem that causes the kernel to overrun a buffer, resulting
in a system oops or memory corruption.

CVE-2008-4934

Eric Sesterhenn reported a local DoS issue in the hfsplus
filesystem.  Local users who have been granted the privileges
necessary to mount a filesystem would be able to craft a corrupted
filesystem that results in a kernel oops due to an unchecked
return value.

CVE-2008-5025

Eric Sesterhenn reported a local DoS issue in the hfs filesystem.
Local users who have been granted the privileges necessary to
mount a filesystem would be able to craft a filesystem with a
corrupted catalog name length, resulting in a system oops or
memory corruption.

CVE-2008-5029

Andrea Bittau reported a DoS issue in the unix socket subsystem
that allows a local user to cause memory corruption, resulting in
a kernel panic.

CVE-2008-5134

Johannes Berg reported a remote DoS issue in the libertas wireless
driver, which can be triggered by a specially crafted beacon/probe
response.

CVE-2008-5182

Al Viro reported race conditions in the inotify subsystem that may
allow local users to acquire elevated privileges.

CVE-2008-5300

Dann Frazier reported a DoS condition that allows local users to
cause the out of memory handler to kill off privileged processes
or trigger soft lockups due to a starvation issue in the unix
socket subsystem.

For the stable distribution (etch), these problems have been fixed in
version 2.6.24-6~etchnhalf.7.

We recommend that you upgrade your linux-2.6.24 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 4.0 alias etch
- ---

Stable updates are available for alpha, amd64, arm, hppa, i386, ia64, mips, 
mipsel, powerpc, s390 and sparc.

Source archives:

  
http://security.debian.org/pool/updates/main/l/linux-2.6.24/linux-2.6.24_2.6.24-6~etchnhalf.7.diff.gz
Size/MD5 checksum:  3951605 2c2f19150d409bc91052c159bfc2618a
  
http://security.debian.org/pool/updates/main/l/linux-2.6.24/linux-2.6.24_2.6.24.orig.tar.gz
Size/MD5 checksum: 59630522 6b8751d1eb8e71498ba74bbd346343af
  
http://security.debian.org/pool/updates/main/l/linux-2.6.24/linux-2.6.24_2.6.24-6~etchnhalf.7.dsc
Size/MD5 checksum: 5107 5491cd0340d5f730a95e70844e786646

Architecture independent packages:

  
http://security.debian.org/pool/updates/main/l/linux-2.6.24/linux-doc-2.6.24_2.6.24-6~etchnhalf.7_all.deb
Size/MD5 checksum:  4259978 f92e913356662607598cb222d5dff90b

[Full-disclosure] DDIVRT-2008-18 Orb Denial of Service

2008-12-04 Thread DDI_Vulnerability_Alert
Title

-

DDIVRT-2008-18 Orb Denial of Service

 

Severity



Medium

 

Date Discovered

---

October 21st 2008

 

Discovered By

-

Digital Defense, Inc. Vulnerability Research Team

Credit: Steven James and [EMAIL PROTECTED]

 

Vulnerability Description

-

Orb Networks' Orb media server is vulnerable to a denial of service
condition. Sending malformed http requests may crash the service denying
service to legitimate users.

 

Solution Description



Use firewall rules to restrict access to authorized users of the Orb
server.

This issue has been fixed in version 2.01.0025, which is available on
Orb's website.

 

Tested Systems / Software (with versions)

--

Orb version 2.01.0017 on Windows XP Pro SP2

Nullsoft Winamp Remote Server Beta (featuring Orb version 2.01.0013) on
Windows XP Pro SP2

Orb version 2.01.0020 on Windows XP Pro SP2

 

Vendor Contact

--

Orb Networks

http://www.orb.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] News for Ureleet

2008-12-04 Thread James Matthews
A nice compromise i wonder if it will work..

On Thu, Dec 4, 2008 at 5:23 AM, ghost [EMAIL PROTECTED] wrote:

 Hey mike, how about you stop playing moderator you fucking douche bag.
 I for one believe netdev brings alot to this list and encourage him
 and ureleet to continue posting.

 On Wed, Dec 3, 2008 at 9:47 PM, Mike C [EMAIL PROTECTED] wrote:
  Hye Guys,
 
  I though we had settled the issues offline. Lets restart our
  discussions.. this bickering is highly unnecessary on the list.
 
  --
  MC
  Security Researcher
  Lead, Project Chroma
  http://sites.google.com/site/projectchromaproject/
 
  ___
  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/




-- 
http://www.astorandblack.com/

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

[Full-disclosure] iDefense Security Advisory 12.04.08: Sun Java JRE TrueType Font Parsing Heap Overflow Vulnerability

2008-12-04 Thread iDefense Labs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

iDefense Security Advisory 12.02.08
http://labs.idefense.com/intelligence/vulnerabilities/
Dec 02, 2008

I. BACKGROUND

The Sun Java JRE is Sun's implementation of the Java runtime. For more
information, see the vendor's site found at the following link.

http://www.java.com

II. DESCRIPTION

Remote exploitation of a heap overflow vulnerability in Sun Microsystems
Inc.'s Java JRE could allow an attacker to execute arbitrary code with
the privileges of the current user.

The vulnerability exists within the font parsing code in the JRE.
Various types of fonts are supported, one of which is the TrueType
format font. The vulnerability occurs when processing TrueType font
files. During parsing, improper bounds checking is performed, which can
lead to a heap based buffer overflow.

III. ANALYSIS

Exploitation allows attackers to execute arbitrary code in the context
of the currently logged-on user. To exploit this vulnerability, a
targeted user must load a malicious Web page created by an attacker. An
attacker typically accomplishes this via social engineering or injecting
content into compromised, trusted sites.

The content of the overflow buffer undergoes a series of transformations
during the font decoding process. The data is not entirely controlled by
the attacker, but there is likely enough control to allow for the
overwriting of critical data structures in a manner that makes
exploitation possible.

IV. DETECTION

iDefense has confirmed the existence of this vulnerability in Sun
Microsystem Inc.'s Java JRE version 1.6.0_07 for Windows. Previous
versions and versions for other platforms may also be affected.

V. WORKAROUND

iDefense is currently unaware of any workarounds for this vulnerability.

VI. VENDOR RESPONSE

Sun Microsystem Inc. has released a patch which addresses this issue.
For more information, consult their advisories at the following URL.

http://onesearch.sun.com/onesearch/index.jsp?qt=Bug%206751322charset=UTF-8

VII. CVE INFORMATION

A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.

VIII. DISCLOSURE TIMELINE

09/10/2008  Initial Vendor Notification
10/28/2008  Initial Vendor Reply
11/25/2008  Additional Vendor Feedback
12/02/2008  Coordinated Public Disclosure

IX. CREDIT

This vulnerability was discovered by Sean Larsson, iDefense Labs.

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

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

X. LEGAL NOTICES

Copyright © 2008 iDefense, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDefense. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please e-mail [EMAIL PROTECTED] for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
~ There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJODJZbjs6HoxIfBkRAk1nAKDt6PFkGPu1QmIuloDG9N9V4yc3FQCglUAH
P+jmeMp9co0KtkQe1M57hwk=
=1EjC
-END PGP SIGNATURE-

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


[Full-disclosure] iDefense Security Advisory 12.04.08: Sun Java JRE Pack200 Decompression Integer Overflow Vulnerability

2008-12-04 Thread iDefense Labs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

iDefense Security Advisory 12.02.08
http://labs.idefense.com/intelligence/vulnerabilities/
Dec 02, 2008

I. BACKGROUND

Pack200 is a compression method introduced by Sun in the 1.5 release of
the JRE. It is used to compress Jar files, and is optimized for the
compression of Java class files. A Java applet can be compressed using
the pack200 tool, and if the browser plugin supports the pack200-gzip
encoding it will pass the compressed Jar file to the JRE for unpacking.
For more information, see the vendor's site at the following links.

http://www.sun.com/java/
http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html

II. DESCRIPTION

Remote exploitation of an integer overflow vulnerability in Sun
Microsystems Inc.'s Java JRE could allow an attacker to execute
arbitrary code with the privileges of the current user.

The vulnerability occurs when reading the Pack200 compressed Jar file
during decompression. In order to calculate the size of a heap buffer,
the code multiplies and adds several integers. The bounds of these
values are not checked, and the arithmetic operations can overflow.
This results in an undersized buffer being allocated, which leads to a
heap based buffer overflow.

III. ANALYSIS

Exploitation allows attackers to execute arbitrary code in the context
of the currently logged-on user. To exploit this vulnerability, a
targeted user must load a malicious Web page created by an attacker. An
attacker typically accomplishes this via social engineering or injecting
content into compromised, trusted sites.

Exploitation of heap overflow vulnerabilities on modern operating
systems can at times be difficult due to various heap integrity
protections. However, the Pack200 code uses a custom allocator that
does not contain such integrity checks. Labs testing has demonstrated
that code execution is possible on the Linux platform. A similar
methodology is likely to be successful on the Windows platform.

IV. DETECTION

iDefense has confirmed the existence of this vulnerability in Sun
Microsystem Inc.'s Java JRE version 1.6.0_07 for Windows and Linux.
According to Sun, Pack200 was first introduced in JRE 1.5.0. The latest
version of JRE 1.5, 1.5.0_15, does contain the vulnerable code, but the
browser plugin does not handle Pack200 encoding. As such, exploitation
through the browser does not appear to be possible with JRE 1.5.

V. WORKAROUND

The library containing the vulnerability can be renamed, which will
prevent it from being loaded. This workaround will prevent users from
loading Pack200 format Jar files, and from using the pack/unpack tools
that come with the JRE. However, normal applets and Java applications
will continue to function correctly. The vulnerable library is called
'unpack', and can be found in:

%SYSTEMDRIVE%\Program Files\Java\JAVA VERSION\bin\unpack.dll

on Windows, and in differing locations dependent upon the
distribution/platform on Unix systems.

VI. VENDOR RESPONSE

Sun Microsystem Inc.'s has released a patch which addresses this issue.
For more information, consult their advisory at the following URL.

http://sunsolve.sun.com/search/document.do?assetkey=1-66-244992-1

VII. CVE INFORMATION

A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.

VIII. DISCLOSURE TIMELINE

10/02/2008  Initial Vendor Notification
11/25/2008  Initial Vendor Reply
12/02/2008  Coordinated Public Disclosure

IX. CREDIT

This vulnerability was reported to iDefense by regenrecht.

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

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

X. LEGAL NOTICES

Copyright © 2008 iDefense, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDefense. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please e-mail [EMAIL PROTECTED] for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
~ There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJOFMPbjs6HoxIfBkRAt4LAKDhmj/ozNKfY4ivEyfBzlaEWUIWMwCfWhzp
QSiD+sqZ2PGexeNSYO3XVrI=
=oup8
-END PGP SIGNATURE-

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


[Full-disclosure] iDefense Security Advisory 12.04.08: Sun Java Web Start GIF Decoding Memory Corruption Vulnerability

2008-12-04 Thread iDefense Labs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

iDefense Security Advisory 12.02.08
http://labs.idefense.com/intelligence/vulnerabilities/
Dec 02, 2008

I. BACKGROUND

Java Web Start (JWS) is a framework built by Sun that is used to run
Java applications outside of the browser. It is distributed with the
Java Runtime Environment (JRE) installation. JWS is typically launched
by clicking on a link in the browser, and results in a separate process
being started that is not tied to the JVM inside of the browser. A file
contains various parameters that describe the Java application to be
run. For more information, see the vendor's site found at the following
link.

http://java.sun.com/javase/technologies/desktop/javawebstart/index.jsp

II. DESCRIPTION

Remote exploitation of a memory corruption vulnerability in Sun
Microsystems Inc.'s Java Web Start could allow an attacker to execute
arbitrary code with the privileges of the current user.

When JWS starts up, it displays a splash screen. By default, the image
displayed on this splash screen is a GIF file provided by Sun, but it
is possible for an attacker to pass an arbitrary GIF file to the splash
logo parsing code.

The vulnerability occurs when parsing this GIF file. The parsing code
does not correctly validate several values in the GIF header. This lets
an attacker write data outside of the bounds of an allocated heap
buffer, which can lead to the execution of arbitrary code.

III. ANALYSIS

Exploitation of this vulnerability results in the execution of arbitrary
code with the privileges of the user. There are several ways to exploit
this vulnerability. In Internet Explorer 6, after the user visits the
malicious web page, no further user interaction is needed. However, in
FireFox and Internet Explorer 7, the user will be presented with the
'File Open' confirmation dialog, and will have to accept opening the
file. It would also be possible for an attacker to e-mail an infected
file to a user, or place it on a shared network drive. In this
situation, a targeted user would need to manually open the file.

Even though the vulnerability is likely to be triggered through the
browser, the actual vulnerability occurs in the Web Start binary. Since
this vulnerability allows for relatively precise control of the area and
content of memory corrupted, reliable exploitation is possible.

IV. DETECTION

iDefense has confirmed the existence of this vulnerability in Java Web
Start version 1.6_10 and 1.6_07 on Windows and Linux. Previous versions
may also be affected.

V. WORKAROUND

On Windows, it is possible to prevent automatic exploitation by double
clicking such a file, or opening it through the browser by removing the
file associations for JNLP files. However, if a user specifically
selects the Java Web Start application to open the JNLP file,
exploitation is still possible. This can be done by removing the
registry key for .jnlp in the 'HKEY_CLASSES_ROOT' registry hive.

An additional workaround which will prevent all exploitation attempts is
to rename the splashscreen library so that Java Web Start will not be
able to load it. This file is found in different locations depending on
the platform and installation choices, but one such location is:

C:\Program Files\Java\jre6\bin\splashscreen.dll

Renaming this file to splashscreen.dll.bak will prevent it from being
loaded.

VI. VENDOR RESPONSE

Sun Microsystems Inc. has released a patch which addresses this issue.
For more information, consult their advisory at the following URL.

http://sunsolve.sun.com/search/document.do?assetkey=1-66-244987-1

VII. CVE INFORMATION

A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.

VIII. DISCLOSURE TIMELINE

10/01/2008  Initial Vendor Notification
11/05/2008  Initial Vendor Reply
11/25/2008  Additional Vendor Feedback
12/02/2008  Coordinated Public Disclosure

IX. CREDIT

This vulnerability was reported to iDefense by regenrecht.

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

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

X. LEGAL NOTICES

Copyright © 2008 iDefense, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDefense. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please e-mail [EMAIL PROTECTED] for permission.

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

[Full-disclosure] [ MDVSA-2008:237 ] apache2

2008-12-04 Thread security

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

 Mandriva Linux Security Advisory MDVSA-2008:237
 http://www.mandriva.com/security/
 ___

 Package : apache2
 Date: December 4, 2008
 Affected: Corporate 3.0, Multi Network Firewall 2.0
 ___

 Problem Description:

 A vulnerability was discovered in the mod_proxy module in Apache where
 it did not limit the number of forwarded interim responses, allowing
 remote HTTP servers to cause a denial of service (memory consumption)
 via a large number of interim responses (CVE-2008-2364).
 
 This update also provides HTTP/1.1 compliance fixes.
 
 The updated packages have been patched to prevent this issue.
 ___

 References:

 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2364
 ___

 Updated Packages:

 Corporate 3.0:
 532973a116bcdf63ed72042b819b59cc  
corporate/3.0/i586/apache2-2.0.48-6.19.C30mdk.i586.rpm
 e2913623f1876d02e426bbca997f3435  
corporate/3.0/i586/apache2-common-2.0.48-6.19.C30mdk.i586.rpm
 2e583f46edd8e83d8071e1912fbcced6  
corporate/3.0/i586/apache2-devel-2.0.48-6.19.C30mdk.i586.rpm
 83b6d9adea62a2c186f2acfb7372a8f0  
corporate/3.0/i586/apache2-manual-2.0.48-6.19.C30mdk.i586.rpm
 f797d9dd78f6a75328f3156f4d97de54  
corporate/3.0/i586/apache2-mod_cache-2.0.48-6.19.C30mdk.i586.rpm
 1e13b9cf9ed69f69f1700d89e7b0a625  
corporate/3.0/i586/apache2-mod_dav-2.0.48-6.19.C30mdk.i586.rpm
 eeacd8fa60a510fe23a949303aefa934  
corporate/3.0/i586/apache2-mod_deflate-2.0.48-6.19.C30mdk.i586.rpm
 12978be0a831fb2164e8663e0aa96c16  
corporate/3.0/i586/apache2-mod_disk_cache-2.0.48-6.19.C30mdk.i586.rpm
 ff7133c4d2f3a18d5ca86398b6a3b482  
corporate/3.0/i586/apache2-mod_file_cache-2.0.48-6.19.C30mdk.i586.rpm
 de43091c378ef1b0a465f409d4198c7d  
corporate/3.0/i586/apache2-mod_ldap-2.0.48-6.19.C30mdk.i586.rpm
 2a884bf3c648fe6e45bd1858e7ac8fca  
corporate/3.0/i586/apache2-mod_mem_cache-2.0.48-6.19.C30mdk.i586.rpm
 435c1058b34b3e5603e8502315d3f1be  
corporate/3.0/i586/apache2-mod_proxy-2.0.48-6.19.C30mdk.i586.rpm
 5a54d1929057b311ab83863fcfc6785b  
corporate/3.0/i586/apache2-mod_ssl-2.0.48-6.19.C30mdk.i586.rpm
 37bb90e385c1571579d604120cd1c1d4  
corporate/3.0/i586/apache2-modules-2.0.48-6.19.C30mdk.i586.rpm
 377a8d1250fb1276e0c52fe89b63775a  
corporate/3.0/i586/apache2-source-2.0.48-6.19.C30mdk.i586.rpm
 2c6db35de4997018b043181957072182  
corporate/3.0/i586/libapr0-2.0.48-6.19.C30mdk.i586.rpm 
 30da5c4069b7b8ea5b3bb13734ca0058  
corporate/3.0/SRPMS/apache2-2.0.48-6.19.C30mdk.src.rpm

 Corporate 3.0/X86_64:
 43cb9996c4ad55ead2a2bba2a618b939  
corporate/3.0/x86_64/apache2-2.0.48-6.19.C30mdk.x86_64.rpm
 898f1420c5fe218c748281c238da9d00  
corporate/3.0/x86_64/apache2-common-2.0.48-6.19.C30mdk.x86_64.rpm
 b7ca472734ea5776cfecf1dd2315f71d  
corporate/3.0/x86_64/apache2-devel-2.0.48-6.19.C30mdk.x86_64.rpm
 8ebd24059163cd8f8e22eb0203682e41  
corporate/3.0/x86_64/apache2-manual-2.0.48-6.19.C30mdk.x86_64.rpm
 ac6f64c5aabbf463be38023dfb2e30e0  
corporate/3.0/x86_64/apache2-mod_cache-2.0.48-6.19.C30mdk.x86_64.rpm
 2e66000edd688d563645ecf526724899  
corporate/3.0/x86_64/apache2-mod_dav-2.0.48-6.19.C30mdk.x86_64.rpm
 d82ba16ad19ebfbb412f033537fe7dfb  
corporate/3.0/x86_64/apache2-mod_deflate-2.0.48-6.19.C30mdk.x86_64.rpm
 e83174382435df2220f7563545543342  
corporate/3.0/x86_64/apache2-mod_disk_cache-2.0.48-6.19.C30mdk.x86_64.rpm
 af5d024a4cff0c216d0c02dcbe08ab83  
corporate/3.0/x86_64/apache2-mod_file_cache-2.0.48-6.19.C30mdk.x86_64.rpm
 b6a74826d456381f9c3807d7cdaef8ff  
corporate/3.0/x86_64/apache2-mod_ldap-2.0.48-6.19.C30mdk.x86_64.rpm
 3e0c99c91a186db1650ab277fb266ddf  
corporate/3.0/x86_64/apache2-mod_mem_cache-2.0.48-6.19.C30mdk.x86_64.rpm
 5bcf1224653b851df20d07d6fbb248b6  
corporate/3.0/x86_64/apache2-mod_proxy-2.0.48-6.19.C30mdk.x86_64.rpm
 c07af351ea84b7d8a0b0de879c9aad2e  
corporate/3.0/x86_64/apache2-mod_ssl-2.0.48-6.19.C30mdk.x86_64.rpm
 fa40774c92468aa0080979674ff473c5  
corporate/3.0/x86_64/apache2-modules-2.0.48-6.19.C30mdk.x86_64.rpm
 a387e498b01b876ee31066aa3a73970a  
corporate/3.0/x86_64/apache2-source-2.0.48-6.19.C30mdk.x86_64.rpm
 659d44dc9615de5b556d35425d628bf7  
corporate/3.0/x86_64/lib64apr0-2.0.48-6.19.C30mdk.x86_64.rpm 
 30da5c4069b7b8ea5b3bb13734ca0058  
corporate/3.0/SRPMS/apache2-2.0.48-6.19.C30mdk.src.rpm

 Multi Network Firewall 2.0:
 93eef0301be074129e8c8f67381c09ad  
mnf/2.0/i586/apache2-2.0.48-6.19.C30mdk.i586.rpm
 0dd927e4efb8dc43f2168227d22c1407  
mnf/2.0/i586/apache2-common-2.0.48-6.19.C30mdk.i586.rpm
 366c8a236e33babca8447b3c3f926c83  
mnf/2.0/i586/apache2-devel-2.0.48-6.19.C30mdk.i586.rpm
 73490cae06d07885512ff28fb24c1d6c  

Re: [Full-disclosure] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread n3td3v
On Thu, Dec 4, 2008 at 4:36 PM, Razi Shaban [EMAIL PROTECTED] wrote:
 On Thu, Dec 4, 2008 at 5:03 PM, Chris Jeane [EMAIL PROTECTED] wrote:
 The Project Chroma Project website reads(I have highlighted the colors in
 black so that they are readable):

 Levels crap


 On Thu, Dec 4, 2008 at 6:28 PM, Razi Shaban [EMAIL PROTECTED] wrote:
 On Thu, Dec 4, 2008 at 6:02 PM, Chris Jeane [EMAIL PROTECTED] wrote:
 Exactly. Which is why there is a need of a system that contains more
 information and less cookie cutter levels. We still don't know what a
 cyber-war looks like. One country could attack the transport/power systems
 of a third party that supplies/supports their target. This is all
 hypothetical, but there is a high probability of collateral damage.


 You misunderstood me. What I was getting at is that your ideas,
 including a cyber-war and all this leveling, show that you are about
 as uninformed as n3td3v. Please take your nub spam somewhere else.

 --
 Razi Shaban


 To explain the idea of leveling: The internet is a gigantic place. No
 matter when and from where you connect, it is out to get you, you
 individually. Also, large-scale cyber wars are a constant thing. I am
 aware of three very large-scale wars taking place at the moment, does
 that increase or decrease the risk any user would be taking by
 accessing the internet? Of course not. The concept of basing a
 levelling system on a few organized national or private attempts to do
 something or another is ridiculous; the Estonian attack compromised
 less than 0.0001% of all cyber attacks during that time period.

 The matter of the fact is, attempting to take the hugely complex and
 intricate dark side of the internet and summarize it in a color level
 is absurd. In fact, attempting to summarize it at all is ridiculous.
 Summarizing implies that you know everything about the topic. Anyone
 trying to summarize this knows nothing when he/she realizes the
 vastness of the internet.

 tl;dr : attempting to summarize the internet is less fruitful than
 throwing ice cubes at the sun, but it requires much lesser
 intelligence to do the first.


I can't believe people are still using Estonia as an example of a
cyber attack, it was a false flag on an epic scale and so obvious to
I.T security experts. The government have got to try harder if they
want to convince the industry that cyber terrorism is a real threat.
But the fact is Estonia and Georgia just weren't convincing enough at
least for me, I don't know what others think.

And the shutting down of a turbine and posting the video to CNN was
just a joke, there was no actual evidence of how the turbine shut
down, it could just be a man in the corner flicking a switch, there
was no evidence of someone using a computer to shut it down, we were
told it was a cyber attack doing it, but no proof or evidence was
given to prove it. They didn't even have a guy with a laptop standing
beside it or anything like that, really the government are clueless
with it comes to cyber security and creating a convincing false flag.

When it comes to power stations being shut down through computerised
attack, I don't see the threat coming from cyber terrorism, what I see
the threat is more is accidental infection, like the three hospitals
in London that got shut down last month because of the MyTob worm/
virus, the industry sit up and listen to that kind of thing and take
it seriously (or at least I did), but they shouldn't take seriously
Estonia, Georgia, DHS turbine videos.

Cyber terrorism isn't a real threat in the climate we're in right now,
what we should fear is accidental infection like the three hospitals
in London. That got my attention more than Estonia, Georgia, DHS
turbine video put together, because it was so obvious that the three
hospitals in London was a genuine incident and not set up by the
powers of be.

We should worry more about staff competence being the main threat, not
cyber terrorism, but mistakes made by I.T departments and accidental
infection onto networks that are sensitive like the three hospitals in
London.

Please it just makes me cringe when I see people using Estonia as a
way to pave political policy and setting up things. There is no cyber
terrorism guys, there is staff incompetence and accidental infection
that is the biggest worry for me right now, than some people in a cave
wanting to carry out an electronic jihad.

Money is wasted setting up cyber commands and other stuff, the money
should really be spent on making sure the private and public sector
and academia is trained to a specific standard so that the three
hospitals incident can't happen again.

As for the color code thing, thats just a load of wash and bollocks
thats not needed, its good for businesses like Symantec and SANS to
have alert levels, because fear is part of what they play on to make
the money that they do.

All the best,

n3td3v

___
Full-Disclosure - We believe in it.

[Full-disclosure] iDefense Security Advisory 12.04.08: Sun Java JRE TrueType Font Parsing Integer Overflow Vulnerability

2008-12-04 Thread iDefense Labs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

iDefense Security Advisory 12.02.08
http://labs.idefense.com/intelligence/vulnerabilities/
Dec 02, 2008

I. BACKGROUND

The Sun Java JRE is Sun's implementation of the Java runtime. For more
information, see the vendor's site found at the following link.

II. DESCRIPTION

Remote exploitation of an integer overflow vulnerability in Sun
Microsystems Inc.'s Java JRE could allow an attacker to execute
arbitrary code with the privileges of the current user.

The vulnerability exists within the font parsing code in the JRE. As
part of its font API, the JRE provides the ability to load a font from
a remote URL. Various types of fonts are supported, one of which is the
TrueType format font. The vulnerability occurs when parsing various
structures in TrueType font files. During parsing, values are taken
from the file, and without being properly validated, used in operations
that calculate the number of bytes to allocate for heap buffers. The
calculations can overflow, resulting in a potentially exploitable heap
overflow.

III. ANALYSIS

Exploitation allows attackers to execute arbitrary code in the context
of the currently logged on user. To exploit this vulnerability, a
targeted user must load a malicious web page created by an attacker. An
attacker typically accomplishes this via social engineering or injecting
content into compromised, trusted sites.

IV. DETECTION

iDefense has confirmed the existence of this vulnerability in Sun
Microsystem Inc.'s Java JRE version 1.6.0_05 for Windows. Previous
versions may also be affected.

V. WORKAROUND

There is a potential workaround for the vulnerability, but it renders
the JRE unusable. It is possible to use the cacls program to change the
file permissions on fontmanager.dll. This will prevent the vulnerable
library from loading. However, this workaround has a serious impact on
the functionality of the JRE. When a webpage attempts to load an
applet, the JRE will abort with a runtime error, and the browser will
close.

VI. VENDOR RESPONSE

Sun Microsystem Inc. has released a patch which addresses this issue.
For more information, consult their advisory at the following URL.

http://sunsolve.sun.com/search/document.do?assetkey=1-66-244987-1

VII. CVE INFORMATION

A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.

VIII. DISCLOSURE TIMELINE

07/31/2008  Initial Vendor Notification
08/01/2008  Initial Vendor Reply
10/21/2008  Additional Vendor Feedback
11/26/2008  Additional Vendor Feedback
12/02/2008  Coordinated Public Disclosure

IX. CREDIT

This vulnerability was reported to iDefense by Sebastian Apelt
([EMAIL PROTECTED]).

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

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

X. LEGAL NOTICES

Copyright © 2008 iDefense, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDefense. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please e-mail [EMAIL PROTECTED] for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
~ There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJOFsZbjs6HoxIfBkRAkAXAKCustwzLXcOKMcDJ1sZ0GonmW4F8ACg6Dva
mqtkKX2/C9fA7aiyNDRtgbA=
=Oo+F
-END PGP SIGNATURE-

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


Re: [Full-disclosure] News for Ureleet

2008-12-04 Thread Noel Butler
really, interesting.. how can they contribute to anyone else's benefit,
since they are both fucking cockheads and are in almost everyones
shitlist filters, infact how do we not know ghost, you are not another
one of this delusional fuckheads aliases, you'd have to be, to be even
making out like you even read anything those wankas post.



On Thu, 2008-12-04 at 13:23, ghost wrote:

 Hey mike, how about you stop playing moderator you fucking douche bag.
 I for one believe netdev brings alot to this list and encourage him
 and ureleet to continue posting.
 
 On Wed, Dec 3, 2008 at 9:47 PM, Mike C [EMAIL PROTECTED] wrote:
  Hye Guys,
 
  I though we had settled the issues offline. Lets restart our
  discussions.. this bickering is highly unnecessary on the list.
 
  --
  MC
  Security Researcher
  Lead, Project Chroma
  http://sites.google.com/site/projectchromaproject/
 
  ___
  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/
___
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-687-1] nfs-utils vulnerability

2008-12-04 Thread Marc Deslauriers
===
Ubuntu Security Notice USN-687-1  December 04, 2008
nfs-utils vulnerability
CVE-2008-4552
===

A security issue affects the following Ubuntu releases:

Ubuntu 6.06 LTS
Ubuntu 7.10
Ubuntu 8.04 LTS
Ubuntu 8.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:
  nfs-kernel-server   1:1.0.7-3ubuntu2.1

Ubuntu 7.10:
  nfs-kernel-server   1:1.1.1~git-20070709-3ubuntu1.1

Ubuntu 8.04 LTS:
  nfs-kernel-server   1:1.1.2-2ubuntu2.2

Ubuntu 8.10:
  nfs-kernel-server   1:1.1.2-4ubuntu1.1

After a standard system upgrade you need to restart nfs services to effect
the necessary changes.

Details follow:

It was discovered that nfs-utils did not properly enforce netgroup
restrictions when using TCP Wrappers. Remote attackers could bypass the
netgroup restrictions enabled by the administrator and possibly gain
access to sensitive information.


Updated packages for Ubuntu 6.06 LTS:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-utils_1.0.7-3ubuntu2.1.diff.gz
  Size/MD5:26729 5926412b5a7d5318b1b90747cade6294

http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-utils_1.0.7-3ubuntu2.1.dsc
  Size/MD5:  698 28b88a044214b04388c55c9e206b48c5

http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-utils_1.0.7.orig.tar.gz
  Size/MD5:   401155 73d8af4367c79f31f68a4ca45422fd17

  amd64 architecture (Athlon64, Opteron, EM64T Xeon):


http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-common_1.0.7-3ubuntu2.1_amd64.deb
  Size/MD5:   105890 d8e004d18150e3d6e91575e91b9f3c0c

http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-kernel-server_1.0.7-3ubuntu2.1_amd64.deb
  Size/MD5:   125960 7ddc8bb36714d4ee3db12ce91adbda22

http://security.ubuntu.com/ubuntu/pool/universe/n/nfs-utils/nhfsstone_1.0.7-3ubuntu2.1_amd64.deb
  Size/MD5:45058 d7f5a96c16456e520a28e0c0cb31cb0c

  i386 architecture (x86 compatible Intel/AMD):


http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-common_1.0.7-3ubuntu2.1_i386.deb
  Size/MD5:94970 37cc41d6a9ad5505cb32528f14ec647f

http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-kernel-server_1.0.7-3ubuntu2.1_i386.deb
  Size/MD5:   112816 e47956631dcb0c8980cd0f72a4e8428e

http://security.ubuntu.com/ubuntu/pool/universe/n/nfs-utils/nhfsstone_1.0.7-3ubuntu2.1_i386.deb
  Size/MD5:43208 c0a0ff484719033e7be7ef166d54602f

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


http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-common_1.0.7-3ubuntu2.1_powerpc.deb
  Size/MD5:   107416 aac5f08b6f0f1fb5dea98a574d129225

http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-kernel-server_1.0.7-3ubuntu2.1_powerpc.deb
  Size/MD5:   123988 dac1ae13e726e5e8bdca56aae8ab2a23

http://security.ubuntu.com/ubuntu/pool/universe/n/nfs-utils/nhfsstone_1.0.7-3ubuntu2.1_powerpc.deb
  Size/MD5:44786 b65159109f7d2f0678350194be9b25c8

  sparc architecture (Sun SPARC/UltraSPARC):


http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-common_1.0.7-3ubuntu2.1_sparc.deb
  Size/MD5:96252 8628208ebf8634aeb657c1f99c34ec83

http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-kernel-server_1.0.7-3ubuntu2.1_sparc.deb
  Size/MD5:   114508 a96b1eab0b5a39e0062ad2c1592c2bd6

http://security.ubuntu.com/ubuntu/pool/universe/n/nfs-utils/nhfsstone_1.0.7-3ubuntu2.1_sparc.deb
  Size/MD5:44092 fffba1487c5b3660c592bfe6e5bdc935

Updated packages for Ubuntu 7.10:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-utils_1.1.1~git-20070709-3ubuntu1.1.diff.gz
  Size/MD5:30941 387a16c1bfc126fe5228b7cd7f895b47

http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-utils_1.1.1~git-20070709-3ubuntu1.1.dsc
  Size/MD5: 1041 ee2f5835d47387259a1ffc509a1c800e

http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-utils_1.1.1~git-20070709.orig.tar.gz
  Size/MD5:  1207377 0c1a357290f5f233543bc942c0a006ad

  amd64 architecture (Athlon64, Opteron, EM64T Xeon):


http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-common_1.1.1~git-20070709-3ubuntu1.1_amd64.deb
  Size/MD5:   187718 a21ea0964e11dc7437b31c8a24136a4e

http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-kernel-server_1.1.1~git-20070709-3ubuntu1.1_amd64.deb
  Size/MD5:   158258 5245d20a87b1f265d699082fd3465cf0

  i386 architecture (x86 compatible Intel/AMD):


http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-common_1.1.1~git-20070709-3ubuntu1.1_i386.deb
  Size/MD5:   176422 90dcb97b35a35e59de12e1432c1ab276


[Full-disclosure] ZDI-08-081: Sun Java Web Start and Applet Multiple Sandbox Bypass Vulnerabilities

2008-12-04 Thread zdi-disclosures
ZDI-08-081: Sun Java Web Start and Applet Multiple Sandbox Bypass 
Vulnerabilities
http://www.zerodayinitiative.com/advisories/ZDI-08-081
December 4, 2008

-- Affected Vendors:
Sun Microsystems

-- Affected Products:
Sun Microsystems Java Runtime

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

http://www.tippingpoint.com

-- Vulnerability Details:
These vulnerabilities allow remote attackers to bypass sandbox
restrictions on vulnerable installations of Sun Java Web Start. User
interaction is required to exploit this vulnerability in that the target
must visit a malicious page.

The first vulnerability results in a cache location and a user name
information disclosure. By accessing the SI_FILEDIR property of a
SingleInstanceImpl class, the location of the temporary single instance
files can be parsed to discover the user name and cache location.

The second vulnerability allows applets to read any file on a victim's
filesystem, outside of the restricted path of the applet. The specific
flaw exists in the handling of the file: protocol assigned to an applet
codebase. If the codebase points to the local filesystem, any file is
then readable by the malicious applet.

The third vulnerability allows JNLP files to bypass socket restrictions.
By loading a secondary JNLP with an href attribute containing a
wildcard. When this object is instantiated, all hosts are eligible for
socket connect and accept.

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

http://sunsolve.sun.com/search/document.do?assetkey=1-66-244988-1

-- Disclosure Timeline:
2008-07-14 - Vulnerability reported to vendor
2008-12-04 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Peter Csepely

-- 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/

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


[Full-disclosure] ZDI-08-077: Trillian AIM IMG Tag Parsing Stack Overflow Vulnerability

2008-12-04 Thread zdi-disclosures
ZDI-08-077: Trillian AIM IMG Tag Parsing Stack Overflow Vulnerability
http://www.zerodayinitiative.com/advisories/ZDI-08-077
December 4, 2008

-- Affected Vendors:
Cerulean Studios

-- Affected Products:
Cerulean Studios Trillian

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

The specific flaw exists within the tooltip processing code for
Trillian. When creating a tooltip for an image, the application
generates an XML tag including a property containing the filename. This
data is then copied directly into a stack-based buffer without any
length verifications which can eventually lead to code execution with
the privileges of the client.

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

http://blog.ceruleanstudios.com/?p=404

-- Disclosure Timeline:
2008-11-10 - Vulnerability reported to vendor
2008-12-04 - 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/

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


[Full-disclosure] ZDI-08-078: Trillian IMG SRC ID Memory Corruption Vulnerability

2008-12-04 Thread zdi-disclosures
ZDI-08-078: Trillian IMG SRC ID Memory Corruption Vulnerability
http://www.zerodayinitiative.com/advisories/ZDI-08-078
December 4, 2008

-- Affected Vendors:
Cerulean Studios

-- Affected Products:
Cerulean Studios Trillian

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

The specific flaw exists within the XML processing code for Trillian.
When parsing specially formulated xml, the application will corrupt an
internal data structure. Whilst deallocating this data structure, the
application can be tricked into freeing a single allocated chunk
multiple times, which can potentially lead to code execution.

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

http://blog.ceruleanstudios.com/?p=404

-- Disclosure Timeline:
2008-11-10 - Vulnerability reported to vendor
2008-12-04 - 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/

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


[Full-disclosure] ZDI-08-079: Trillian AIM Plugin Malformed XML Tag Heap Overflow Vulnerability

2008-12-04 Thread zdi-disclosures
ZDI-08-079: Trillian AIM Plugin Malformed XML Tag Heap Overflow 
Vulnerability
http://www.zerodayinitiative.com/advisories/ZDI-08-079
December 4, 2008

-- Affected Vendors:
Cerulean Studios

-- Affected Products:
Cerulean Studios Trillian

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

The specific flaw exists within the XML processing code for Trillian.
When parsing a malformed XML tag, the application does not allocate
enough space for it's contents. During copying of this to the newly
allocated buffer, the application will overwrite heap structures with
attacker-supplied data that can then be leveraged to achieve code
execution with the privileges of the application.

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

http://blog.ceruleanstudios.com/?p=404

-- Disclosure Timeline:
2008-11-24 - Vulnerability reported to vendor
2008-12-04 - 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/

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


[Full-disclosure] ZDI-08-080: Sun Java AWT Library Sandbox Violation Vulnerability

2008-12-04 Thread zdi-disclosures
ZDI-08-080: Sun Java AWT Library Sandbox Violation Vulnerability
http://www.zerodayinitiative.com/advisories/ZDI-08-080
December 4, 2008

-- Affected Vendors:
Sun Microsystems

-- Affected Products:
Sun Microsystems Java Runtime

-- TippingPoint(TM) IPS Customer Protection:
TippingPoint IPS customers have been protected against this
vulnerability by Digital Vaccine protection filter ID 6249. 
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 Sun Microsystems Java. User interaction is
required in that a user must open a malicious file or visit a malicious
web page.

The specific flaw occurs within the Java AWT library. If a custom image
model is used for the source 'Raster' during a conversion through a
'ConvolveOp' operation, the imaging library will calculate the size of
the destination raster for the conversion incorrectly leading to a
heap-based overflow. This can result in arbitrary code execution under
the context of the current user.

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

http://sunsolve.sun.com/search/document.do?assetkey=1-66-244987-1

-- Disclosure Timeline:
2008-04-16 - Vulnerability reported to vendor
2008-12-04 - 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/

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


Re: [Full-disclosure] News for Ureleet

2008-12-04 Thread ghost
a wanka mate? well i be a fag from down unda, cheers  jolly ho ol
chap. This is the only contribution youve made to full-disclosure. So
whos the useless wanka then? go on back to your bread pudding before i
take a piss on ya and give you a good rodging.

On Thu, Dec 4, 2008 at 5:59 PM, Noel Butler [EMAIL PROTECTED] wrote:
 really, interesting.. how can they contribute to anyone else's benefit,
 since they are both fucking cockheads and are in almost everyones shitlist
 filters, infact how do we not know ghost, you are not another one of this
 delusional fuckheads aliases, you'd have to be, to be even making out like
 you even read anything those wankas post.



 On Thu, 2008-12-04 at 13:23, ghost wrote:

 Hey mike, how about you stop playing moderator you fucking douche bag.
 I for one believe netdev brings alot to this list and encourage him
 and ureleet to continue posting.

 On Wed, Dec 3, 2008 at 9:47 PM, Mike C [EMAIL PROTECTED] wrote:
 Hye Guys,

 I though we had settled the issues offline. Lets restart our
 discussions.. this bickering is highly unnecessary on the list.

 --
 MC
 Security Researcher
 Lead, Project Chroma
 http://sites.google.com/site/projectchromaproject/

 ___
 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/

___
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] [ MDVSA-2008:238 ] libsamplerate

2008-12-04 Thread security

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

 Mandriva Linux Security Advisory MDVSA-2008:238
 http://www.mandriva.com/security/
 ___

 Package : libsamplerate
 Date: December 4, 2008
 Affected: 2008.0, 2008.1, Corporate 3.0, Corporate 4.0
 ___

 Problem Description:

 A buffer overflow was found by Russell O'Conner in the libsamplerate
 library versions prior to 0.1.4 that could possibly lead to the
 execution of arbitrary code via a specially crafted audio file
 (CVE-2008-5008).
 
 The updated packages have been patched to prevent this issue.
 ___

 References:

 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5008
 ___

 Updated Packages:

 Mandriva Linux 2008.0:
 9a9cc1fbac25741ad38e914c98d90826  
2008.0/i586/libsamplerate0-0.1.3-0.pre6.3.1mdv2008.0.i586.rpm
 294117b4e81f6d38553faf47b0d0b561  
2008.0/i586/libsamplerate-devel-0.1.3-0.pre6.3.1mdv2008.0.i586.rpm
 695ab47e44749f3f0a6df321992f6064  
2008.0/i586/libsamplerate-progs-0.1.3-0.pre6.3.1mdv2008.0.i586.rpm 
 4068b67bd67786501ddc388824763a19  
2008.0/SRPMS/libsamplerate-0.1.3-0.pre6.3.1mdv2008.0.src.rpm

 Mandriva Linux 2008.0/X86_64:
 24a792941fa5fbff89764b724923a616  
2008.0/x86_64/lib64samplerate0-0.1.3-0.pre6.3.1mdv2008.0.x86_64.rpm
 c1ac9d056ca38c36658158fec3ee3f31  
2008.0/x86_64/lib64samplerate-devel-0.1.3-0.pre6.3.1mdv2008.0.x86_64.rpm
 dcdffc679e6af71864d8cdb78e335df8  
2008.0/x86_64/libsamplerate-progs-0.1.3-0.pre6.3.1mdv2008.0.x86_64.rpm 
 4068b67bd67786501ddc388824763a19  
2008.0/SRPMS/libsamplerate-0.1.3-0.pre6.3.1mdv2008.0.src.rpm

 Mandriva Linux 2008.1:
 f44c5b4f55bbe4ad946f46456dce4745  
2008.1/i586/libsamplerate0-0.1.3-0.pre6.3.1mdv2008.1.i586.rpm
 18a7016e5da1f0f37c3cde4222703f87  
2008.1/i586/libsamplerate-devel-0.1.3-0.pre6.3.1mdv2008.1.i586.rpm
 6064159a6a594c006d16c42d29cfd240  
2008.1/i586/libsamplerate-progs-0.1.3-0.pre6.3.1mdv2008.1.i586.rpm 
 32697b41d7fd390e91b4d4dbeacc0db2  
2008.1/SRPMS/libsamplerate-0.1.3-0.pre6.3.1mdv2008.1.src.rpm

 Mandriva Linux 2008.1/X86_64:
 6497eadf29decebda33422f431a83d45  
2008.1/x86_64/lib64samplerate0-0.1.3-0.pre6.3.1mdv2008.1.x86_64.rpm
 2df7b9d3f1656f728667e68569cfc8af  
2008.1/x86_64/lib64samplerate-devel-0.1.3-0.pre6.3.1mdv2008.1.x86_64.rpm
 b9c0276018ac620bbcd68f998b4daeac  
2008.1/x86_64/libsamplerate-progs-0.1.3-0.pre6.3.1mdv2008.1.x86_64.rpm 
 32697b41d7fd390e91b4d4dbeacc0db2  
2008.1/SRPMS/libsamplerate-0.1.3-0.pre6.3.1mdv2008.1.src.rpm

 Corporate 3.0:
 91ef6d6952ac4d845f4ed16b74117d8d  
corporate/3.0/i586/libsamplerate0-0.0.15-2.1.C30mdk.i586.rpm
 7d1aef25a43863e4a7d89fd559312b29  
corporate/3.0/i586/libsamplerate0-devel-0.0.15-2.1.C30mdk.i586.rpm
 e3d9b6a0c2d32d36bd55b3d2b9ff8fa7  
corporate/3.0/i586/libsamplerate-progs-0.0.15-2.1.C30mdk.i586.rpm 
 67cdb6d349097d08925e2c4cb86d1fe6  
corporate/3.0/SRPMS/libsamplerate-0.0.15-2.1.C30mdk.src.rpm

 Corporate 3.0/X86_64:
 3efec8fbd1ea1fd00f9eea336afd5798  
corporate/3.0/x86_64/lib64samplerate0-0.0.15-2.1.C30mdk.x86_64.rpm
 5783d23a1019bed054e713b94c5ad989  
corporate/3.0/x86_64/lib64samplerate0-devel-0.0.15-2.1.C30mdk.x86_64.rpm
 f970ddd128def98252bc4090f576f4ec  
corporate/3.0/x86_64/libsamplerate-progs-0.0.15-2.1.C30mdk.x86_64.rpm 
 67cdb6d349097d08925e2c4cb86d1fe6  
corporate/3.0/SRPMS/libsamplerate-0.0.15-2.1.C30mdk.src.rpm

 Corporate 4.0:
 0a2d27263f81d8304028bccadb5142af  
corporate/4.0/i586/libsamplerate0-0.1.2-1.1.20060mlcs4.i586.rpm
 7d3dbad29db356b97dc77f720c0a  
corporate/4.0/i586/libsamplerate0-devel-0.1.2-1.1.20060mlcs4.i586.rpm
 9b2bc33430ac70a2c24eab9f2afee0c2  
corporate/4.0/i586/libsamplerate-progs-0.1.2-1.1.20060mlcs4.i586.rpm 
 83cdd1d3349f1017c4c92cb6ee0fb636  
corporate/4.0/SRPMS/libsamplerate-0.1.2-1.1.20060mlcs4.src.rpm

 Corporate 4.0/X86_64:
 ffbc6a9d6d3403a52ca5cbe3c4a3495d  
corporate/4.0/x86_64/lib64samplerate0-0.1.2-1.1.20060mlcs4.x86_64.rpm
 991dd38ed664577613f6a55da77eaa29  
corporate/4.0/x86_64/lib64samplerate0-devel-0.1.2-1.1.20060mlcs4.x86_64.rpm
 92d88adbf9d580a772b702f33cf8d027  
corporate/4.0/x86_64/libsamplerate-progs-0.1.2-1.1.20060mlcs4.x86_64.rpm 
 83cdd1d3349f1017c4c92cb6ee0fb636  
corporate/4.0/SRPMS/libsamplerate-0.1.2-1.1.20060mlcs4.src.rpm
 ___

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

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

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

 You can view other update advisories for Mandriva Linux at:

  

Re: [Full-disclosure] News for Ureleet

2008-12-04 Thread Ureleet
true.

On Wed, Dec 3, 2008 at 10:23 PM, ghost [EMAIL PROTECTED] wrote:
 Hey mike, how about you stop playing moderator you fucking douche bag.
 I for one believe netdev brings alot to this list and encourage him
 and ureleet to continue posting.

 On Wed, Dec 3, 2008 at 9:47 PM, Mike C [EMAIL PROTECTED] wrote:
 Hye Guys,

 I though we had settled the issues offline. Lets restart our
 discussions.. this bickering is highly unnecessary on the list.

 --
 MC
 Security Researcher
 Lead, Project Chroma
 http://sites.google.com/site/projectchromaproject/

 ___
 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/


___
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] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread Ureleet
u mean, again?  dude, its already been done.  and by ppl alot smarter
than u.  stfu.  try sumthing knew.  u obviously fucked this 1 up.

On Wed, Dec 3, 2008 at 9:45 PM, Mike C [EMAIL PROTECTED] wrote:
 On Tue, Dec 2, 2008 at 11:29 AM, Elazar Broad [EMAIL PROTECTED] wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On Tue, 02 Dec 2008 11:50:46 -0500 rholgstad [EMAIL PROTECTED]
 wrote:
Mike C wrote:
 On Mon, Dec 1, 2008 at 5:27 PM, rholgstad [EMAIL PROTECTED]
wrote:

 and how does making a color based on these inputs protect
people?



 Once all desktops have an icon or widget (say at the right hand
 corner) with the color, and this is consistently seen
everywhere, the
 users will start associating with their online security. they
will be
 reminded that they have to be careful with the data they share.

 This, if implemented correctly will be a boon to security
industry,
 where the weakest kinks currently are 'n00b'  users.


you are joking right?

So some widget is going to stop the next SMB remote or IE client
side
and protect the 'n00b' users? Please explain how this works. Also
please
explain how they will be reminded that they have to be careful
with the
data they share.  has anything to do with protecting a users
machine
from being compromised.

 Thats the whole point. There is a fine line between using visual
 alerts to put people(Joe six pack) into a state of awareness(more
 like mild hysteria) of a threat versus knowing how to protect
 oneself against that threat and using that awareness indicator as
 the kick in the ass to get moving and shore up the defenses(hell,
 how many security folk do this too, then again, every time
 something goes bump we see red). Visual alerts are great at
 persuasion tools, especially when the goal is to get Joe to buy
 your latest all-in-one-will-make-your-coffee-and-buy-you-beer
 AV/Malware/Spyware/Foo(whats this doing here?)/evil monkey in the
 closet package. So of course, Joe will never learn how to properly
 defend his computer/data, and the industry will prosper.


 I dont think it is a lost battle. This method could prove an excellent
 way to solve this age old problem.

 Now, thanks to our good friends over at the DHS, the color system
 has turned into a complete and utter joke(for the most part), so my
 friend, you see, this a complete exercise in futility(besides the
 fact that every friggin AV/IDS/Security/SIM company out there has
 red, yellow and green as their corporate flag, if you are just
 joining the party, then you can completely ignore this)

 DHS implementation leaves a lot to be desired. Please do not compare
 this to DHS's implementation.

 If you really want to change state of security for the n00bs,
 spread the knowledge, not the colors.

 Thats what project Chroma is all about.. Are you on board?!

 --
 MC
 Security Researcher
 Lead, Project Chroma
 http://sites.google.com/site/projectchromaproject/

 ___
 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] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread Ureleet
you know andrew, i couldnt have said it better.

even tho i disagree and _do_ say that estonia and georgia _were_ cyber
attacks, u make an excellent discussion.

On Thu, Dec 4, 2008 at 5:29 PM, n3td3v [EMAIL PROTECTED] wrote:
 On Thu, Dec 4, 2008 at 4:36 PM, Razi Shaban [EMAIL PROTECTED] wrote:
 On Thu, Dec 4, 2008 at 5:03 PM, Chris Jeane [EMAIL PROTECTED] wrote:
 The Project Chroma Project website reads(I have highlighted the colors in
 black so that they are readable):

 Levels crap


 On Thu, Dec 4, 2008 at 6:28 PM, Razi Shaban [EMAIL PROTECTED] wrote:
 On Thu, Dec 4, 2008 at 6:02 PM, Chris Jeane [EMAIL PROTECTED] wrote:
 Exactly. Which is why there is a need of a system that contains more
 information and less cookie cutter levels. We still don't know what a
 cyber-war looks like. One country could attack the transport/power systems
 of a third party that supplies/supports their target. This is all
 hypothetical, but there is a high probability of collateral damage.


 You misunderstood me. What I was getting at is that your ideas,
 including a cyber-war and all this leveling, show that you are about
 as uninformed as n3td3v. Please take your nub spam somewhere else.

 --
 Razi Shaban


 To explain the idea of leveling: The internet is a gigantic place. No
 matter when and from where you connect, it is out to get you, you
 individually. Also, large-scale cyber wars are a constant thing. I am
 aware of three very large-scale wars taking place at the moment, does
 that increase or decrease the risk any user would be taking by
 accessing the internet? Of course not. The concept of basing a
 levelling system on a few organized national or private attempts to do
 something or another is ridiculous; the Estonian attack compromised
 less than 0.0001% of all cyber attacks during that time period.

 The matter of the fact is, attempting to take the hugely complex and
 intricate dark side of the internet and summarize it in a color level
 is absurd. In fact, attempting to summarize it at all is ridiculous.
 Summarizing implies that you know everything about the topic. Anyone
 trying to summarize this knows nothing when he/she realizes the
 vastness of the internet.

 tl;dr : attempting to summarize the internet is less fruitful than
 throwing ice cubes at the sun, but it requires much lesser
 intelligence to do the first.


 I can't believe people are still using Estonia as an example of a
 cyber attack, it was a false flag on an epic scale and so obvious to
 I.T security experts. The government have got to try harder if they
 want to convince the industry that cyber terrorism is a real threat.
 But the fact is Estonia and Georgia just weren't convincing enough at
 least for me, I don't know what others think.

 And the shutting down of a turbine and posting the video to CNN was
 just a joke, there was no actual evidence of how the turbine shut
 down, it could just be a man in the corner flicking a switch, there
 was no evidence of someone using a computer to shut it down, we were
 told it was a cyber attack doing it, but no proof or evidence was
 given to prove it. They didn't even have a guy with a laptop standing
 beside it or anything like that, really the government are clueless
 with it comes to cyber security and creating a convincing false flag.

 When it comes to power stations being shut down through computerised
 attack, I don't see the threat coming from cyber terrorism, what I see
 the threat is more is accidental infection, like the three hospitals
 in London that got shut down last month because of the MyTob worm/
 virus, the industry sit up and listen to that kind of thing and take
 it seriously (or at least I did), but they shouldn't take seriously
 Estonia, Georgia, DHS turbine videos.

 Cyber terrorism isn't a real threat in the climate we're in right now,
 what we should fear is accidental infection like the three hospitals
 in London. That got my attention more than Estonia, Georgia, DHS
 turbine video put together, because it was so obvious that the three
 hospitals in London was a genuine incident and not set up by the
 powers of be.

 We should worry more about staff competence being the main threat, not
 cyber terrorism, but mistakes made by I.T departments and accidental
 infection onto networks that are sensitive like the three hospitals in
 London.

 Please it just makes me cringe when I see people using Estonia as a
 way to pave political policy and setting up things. There is no cyber
 terrorism guys, there is staff incompetence and accidental infection
 that is the biggest worry for me right now, than some people in a cave
 wanting to carry out an electronic jihad.

 Money is wasted setting up cyber commands and other stuff, the money
 should really be spent on making sure the private and public sector
 and academia is trained to a specific standard so that the three
 hospitals incident can't happen again.

 As for the color code thing, thats just a load of wash and bollocks
 

Re: [Full-disclosure] Iran executes IT expert who spied for Israel

2008-12-04 Thread Ureleet
oh mike c, now i shall turn my wrath towards u for being a cock.

On Wed, Dec 3, 2008 at 9:49 PM, Mike C [EMAIL PROTECTED] wrote:
 On Wed, Dec 3, 2008 at 6:55 AM, Ureleet [EMAIL PROTECTED] wrote:
 hes not a troll andrew.  he brings up good points.  u nd i are the
 only trolls here.  i only troll u.  you troll every1.


 Yes, acceptance is he first stage of recovery for the both of you. Let
 us continue with the offline discussions.


 --
 MC
 Security Researcher
 Lead, Project Chroma
 http://sites.google.com/site/projectchromaproject/


___
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] Fwd: Solving of problems

2008-12-04 Thread Ureleet
-- Forwarded message --
From: Ureleet [EMAIL PROTECTED]
Date: Thu, Dec 4, 2008 at 8:34 PM
Subject: Re: Solving of problems
To: Mike C [EMAIL PROTECTED]
Cc: n3td3v [EMAIL PROTECTED]


who says we have it in for each other at all?  what makes u the
official 'problem' solver.  i am the Yin to n3td3v's yang, u r just
fucking up the rotation.

On Wed, Dec 3, 2008 at 9:48 PM, Mike C [EMAIL PROTECTED] wrote:
 Ok. Lets restart. Why has the bickering restarted?

 Why do you have it in for each other?

 --
 MC
 Security Researcher
 Lead, Project Chroma
 http://sites.google.com/site/projectchromaproject/


___
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] News for Ureleet

2008-12-04 Thread Ureleet
we implying, u, me, and n3td3v.  1st of all, u didnt do shit but
send 2 emails.  the talks between me n n3td3v have always been an open
line of communication, ur just some douche who is obvouisly trying
to take credit 4 stuff.

moderate the n3td3v/ureleet discussion?  yes, that was mike c, the
cockswallower.

o, and hes the lead of project chroma.  even n3td3v said ur project is
fucking pointless.  go rot u cocksucker.  u obviously have no
contribution 2 life other than breathing my air.  choke on a cock.

On Wed, Dec 3, 2008 at 9:47 PM, Mike C [EMAIL PROTECTED] wrote:
 Hye Guys,

 I though we had settled the issues offline. Lets restart our
 discussions.. this bickering is highly unnecessary on the list.

 --
 MC
 Security Researcher
 Lead, Project Chroma
 http://sites.google.com/site/projectchromaproject/


___
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] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread ghost
A colour scheme will save the world huh? So theyll be more dangerous
when its red? Wont it always be red? why not just cut out the color
scheme and emboss THE INTERNET IS DANGEROUS, SERIOUS BUSINESS! on
every monitor. It will do the exact same thing your suggesting.
without taking up my screen space.

 On Wed, Dec 3, 2008 at 9:45 PM, Mike C [EMAIL PROTECTED] wrote:
 On Tue, Dec 2, 2008 at 11:29 AM, Elazar Broad [EMAIL PROTECTED] wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On Tue, 02 Dec 2008 11:50:46 -0500 rholgstad [EMAIL PROTECTED]
 wrote:
Mike C wrote:
 On Mon, Dec 1, 2008 at 5:27 PM, rholgstad [EMAIL PROTECTED]
wrote:

 and how does making a color based on these inputs protect
people?



 Once all desktops have an icon or widget (say at the right hand
 corner) with the color, and this is consistently seen
everywhere, the
 users will start associating with their online security. they
will be
 reminded that they have to be careful with the data they share.

 This, if implemented correctly will be a boon to security
industry,
 where the weakest kinks currently are 'n00b'  users.


you are joking right?

So some widget is going to stop the next SMB remote or IE client
side
and protect the 'n00b' users? Please explain how this works. Also
please
explain how they will be reminded that they have to be careful
with the
data they share.  has anything to do with protecting a users
machine
from being compromised.

 Thats the whole point. There is a fine line between using visual
 alerts to put people(Joe six pack) into a state of awareness(more
 like mild hysteria) of a threat versus knowing how to protect
 oneself against that threat and using that awareness indicator as
 the kick in the ass to get moving and shore up the defenses(hell,
 how many security folk do this too, then again, every time
 something goes bump we see red). Visual alerts are great at
 persuasion tools, especially when the goal is to get Joe to buy
 your latest all-in-one-will-make-your-coffee-and-buy-you-beer
 AV/Malware/Spyware/Foo(whats this doing here?)/evil monkey in the
 closet package. So of course, Joe will never learn how to properly
 defend his computer/data, and the industry will prosper.


 I dont think it is a lost battle. This method could prove an excellent
 way to solve this age old problem.

 Now, thanks to our good friends over at the DHS, the color system
 has turned into a complete and utter joke(for the most part), so my
 friend, you see, this a complete exercise in futility(besides the
 fact that every friggin AV/IDS/Security/SIM company out there has
 red, yellow and green as their corporate flag, if you are just
 joining the party, then you can completely ignore this)

 DHS implementation leaves a lot to be desired. Please do not compare
 this to DHS's implementation.

 If you really want to change state of security for the n00bs,
 spread the knowledge, not the colors.

 Thats what project Chroma is all about.. Are you on board?!

 --
 MC
 Security Researcher
 Lead, Project Chroma
 http://sites.google.com/site/projectchromaproject/

 ___
 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/


___
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] Fwd: Solving of problems

2008-12-04 Thread ghost
FWD FUD FTW

On Thu, Dec 4, 2008 at 8:34 PM, Ureleet [EMAIL PROTECTED] wrote:
 -- Forwarded message --
 From: Ureleet [EMAIL PROTECTED]
 Date: Thu, Dec 4, 2008 at 8:34 PM
 Subject: Re: Solving of problems
 To: Mike C [EMAIL PROTECTED]
 Cc: n3td3v [EMAIL PROTECTED]


 who says we have it in for each other at all?  what makes u the
 official 'problem' solver.  i am the Yin to n3td3v's yang, u r just
 fucking up the rotation.

 On Wed, Dec 3, 2008 at 9:48 PM, Mike C [EMAIL PROTECTED] wrote:
 Ok. Lets restart. Why has the bickering restarted?

 Why do you have it in for each other?

 --
 MC
 Security Researcher
 Lead, Project Chroma
 http://sites.google.com/site/projectchromaproject/


 ___
 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] Fwd: Solving of problems

2008-12-04 Thread vulcanius
Yin is the dark and yang is the light. Are you saying that you're the evil
one Ureleet and... *gulp* ...n3td3v is the good?

On Thu, Dec 4, 2008 at 8:34 PM, Ureleet [EMAIL PROTECTED] wrote:

 -- Forwarded message --
 From: Ureleet [EMAIL PROTECTED]
 Date: Thu, Dec 4, 2008 at 8:34 PM
 Subject: Re: Solving of problems
 To: Mike C [EMAIL PROTECTED]
 Cc: n3td3v [EMAIL PROTECTED]


 who says we have it in for each other at all?  what makes u the
 official 'problem' solver.  i am the Yin to n3td3v's yang, u r just
 fucking up the rotation.

 On Wed, Dec 3, 2008 at 9:48 PM, Mike C [EMAIL PROTECTED] wrote:
  Ok. Lets restart. Why has the bickering restarted?
 
  Why do you have it in for each other?
 
  --
  MC
  Security Researcher
  Lead, Project Chroma
  http://sites.google.com/site/projectchromaproject/
 

 ___
 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] Fwd: Solving of problems

2008-12-04 Thread j w

I'm an official problem solver, what the problem is?Date: Thu, 4 Dec 2008 
21:14:48 -0500From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Re: [Full-disclosure] 
Fwd: Solving of problemsYin is the dark and yang is the light. Are you saying 
that you're the evil one Ureleet and... *gulp* ...n3td3v is the good?On Thu, 
Dec 4, 2008 at 8:34 PM, Ureleet [EMAIL PROTECTED] wrote:
-- Forwarded message --
From: Ureleet [EMAIL PROTECTED]
Date: Thu, Dec 4, 2008 at 8:34 PM
Subject: Re: Solving of problems
To: Mike C [EMAIL PROTECTED]
Cc: n3td3v [EMAIL PROTECTED]


who says we have it in for each other at all?  what makes u the
official 'problem' solver.  i am the Yin to n3td3v's yang, u r just
fucking up the rotation.

On Wed, Dec 3, 2008 at 9:48 PM, Mike C [EMAIL PROTECTED] wrote:
 Ok. Lets restart. Why has the bickering restarted?

 Why do you have it in for each other?

 --
 MC
 Security Researcher
 Lead, Project Chroma
 http://sites.google.com/site/projectchromaproject/


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

_
You live life online. So we put Windows on the web. 
http://clk.atdmt.com/MRT/go/127032869/direct/01/___
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] News for Ureleet

2008-12-04 Thread Jubei Trippataka
On Fri, Dec 5, 2008 at 11:49 AM, ghost [EMAIL PROTECTED] wrote:

 a wanka mate? well i be a fag from down unda, cheers  jolly ho ol
 chap. This is the only contribution youve made to full-disclosure. So
 whos the useless wanka then? go on back to your bread pudding before i
 take a piss on ya and give you a good rodging.



Wrong country, that's all British slang you extra chromosomal piss-freak.

-- 
ciao

JT
___
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] News for Ureleet

2008-12-04 Thread Noel Butler
On Fri, 2008-12-05 at 10:49, ghost wrote:

 a wanka mate? well i be a fag from down unda, cheers  jolly ho ol
 chap. This is the only contribution youve made to full-disclosure. So
 whos the useless wanka then? go on back to your bread pudding before i
 take a piss on ya and give you a good rodging.
 


no one takes this list seriously anymore thanks to the noisy deadbeats,
there is .001% signal,
with the remaining pure noise, and whos got the bigger  cock, or who can
piss further, no one actually gives a rats ass.




 On Thu, Dec 4, 2008 at 5:59 PM, Noel Butler [EMAIL PROTECTED] wrote:
  really, interesting.. how can they contribute to anyone else's benefit,
  since they are both fucking cockheads and are in almost everyones shitlist
  filters, infact how do we not know ghost, you are not another one of this
  delusional fuckheads aliases, you'd have to be, to be even making out like
  you even read anything those wankas post.
 
 
 
  On Thu, 2008-12-04 at 13:23, ghost wrote:
 
  Hey mike, how about you stop playing moderator you fucking douche bag.
  I for one believe netdev brings alot to this list and encourage him
  and ureleet to continue posting.
 
  On Wed, Dec 3, 2008 at 9:47 PM, Mike C [EMAIL PROTECTED] wrote:
  Hye Guys,
 
  I though we had settled the issues offline. Lets restart our
  discussions.. this bickering is highly unnecessary on the list.
 
  --
  MC
  Security Researcher
  Lead, Project Chroma
  http://sites.google.com/site/projectchromaproject/
 
  ___
  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/
___
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] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread n3td3v
On Thu, Dec 4, 2008 at 3:03 PM, Chris Jeane [EMAIL PROTECTED] wrote:
 The Project Chroma Project website reads(I have highlighted the colors in
 black so that they are readable):

 Green level: There is negligible threat to online security.
 Ok this one is pretty simple.

 Yellow level : There is a minimal level of threat, and this must be
 monitored and contained.
 The SAN ISC says : We are currently tracking a significant new threat. The
 impact is either unknown or expected to be minor to the infrastructure.
 However, local impact could be significant. Users are advised to take
 immediate specific action to contain the impact.
 You are giving an abbreviation version of something that already exists and
 is excepted.

 Orange level: This level of threat indicates there are parties who are
 actively engaging in cyber-warfare. Caution is required when online.
 Caution is always required when online. If you are in an area
 (country/province/region) that is affected by cyber attacks you will have
 limited/no access the internet. If only your company/person is being
 assaulted from cyberspace the attack would probably go unnoticed by this
 monitoring system. If the attackers were commiting a DDOS attack on several
 specific non-infastructure targets, you internet access my slow/go dark, but
 is that really a threat to you? or one you can protect agianst?

 Red level: This level indicates a full blown cyber-war. It indicates
 very high probability of all communications being intercepted.
 The use of the term 'full blown cyber-war' seems like a overarching scare
 tactic. We have yet to see what cyber-warfare looks like. Estonia was a one
 sided cyber ambush, not two entites engaging in war. The alerts should be
 more generic and accompanied by an acessment of the actual current
 situation. If something like 'Code Red' where to infect the internet agian
 this alert calling it cyber-war would be a misnomer.

 While homeland security's implementation does not seem to have a real
 world merit, such a threat level would certainly be very useful in the
 online security realm.
 Who is this useful to: Security processionals, end users, governmental
 agencies? How and why as similar systems already exist?

 Please disseminate this announcement of the
 project Chroma levels for online security. The immediate mission of
 the project is to be picked up by the antivirus and security tools
 vendors, so as to add the color codes to their products and provide
 users with a tangible measure of their online security.
 Yellow is not a tangible measure of their online security. If perhaps an
 Online Security/IPS package knew that a DDoS attack was coming for an
 address segment of the internet and it requested that I block traffic from
 those attackers until an all clear or Green
 status was given. That is tangible and actionable.

 Current status: Threat level Yellow.
 Your current is higher than SANS ISC. Do you know something they don't?


Symantec / Securityfocus is currently Yellow as well.

Maybe its SANS that are out of the loop afterall.

___
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] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread Valdis . Kletnieks
On Fri, 05 Dec 2008 03:36:04 GMT, n3td3v said:

 Symantec / Securityfocus is currently Yellow as well.
 
 Maybe its SANS that are out of the loop afterall.

What color has the most beneficial effect on the stock prices of each of the 3
companies?





pgpih0GcnsGBT.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] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread n3td3v
On Fri, Dec 5, 2008 at 3:39 AM,  [EMAIL PROTECTED] wrote:
 On Fri, 05 Dec 2008 03:36:04 GMT, n3td3v said:

 Symantec / Securityfocus is currently Yellow as well.

 Maybe its SANS that are out of the loop afterall.

 What color has the most beneficial effect on the stock prices of each of the 3
 companies?


This is a cyber security list not Yahoo Finance, how im I supposed to
answer that question? And why would you expect anyone to be able to
answer that on this list? A sweeping guess would be red for danger,
meaning everyone should buy Symantec products and that people should
sign up for doofus SANS courses? Enlighten me Valdis, because i've got
a sneaky suspicion you've already got the answer lined up.

___
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] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread Valdis . Kletnieks
On Fri, 05 Dec 2008 03:48:49 GMT, you said:

 answer that on this list? A sweeping guess would be red for danger,

No, if you sell security products, you *dont* want it to be red, because
that gives the impression that your already-deployed sales aren't doing
a good enough job of stopping the badness.

It's RED, buy our product.
Why? If your product actually *worked*, why should it be RED?


pgpUrhDvr2qa6.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] Project Chroma: A color code for the state ofcyber security

2008-12-04 Thread n3td3v
On Fri, Dec 5, 2008 at 3:59 AM,  [EMAIL PROTECTED] wrote:
 On Fri, 05 Dec 2008 03:48:49 GMT, you said:

 answer that on this list? A sweeping guess would be red for danger,

 No, if you sell security products, you *dont* want it to be red, because
 that gives the impression that your already-deployed sales aren't doing
 a good enough job of stopping the badness.

 It's RED, buy our product.
 Why? If your product actually *worked*, why should it be RED?


I'm coming to the conclusion that most folks benefit from it being at
a moderate level, between green and amber. They can flick it between
the two and not get into too much trouble, while keeping observers
stimulated with interest?

___
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] News for Ureleet

2008-12-04 Thread Valdis . Kletnieks
On Fri, 05 Dec 2008 13:03:45 +1000, Noel Butler said:
 with the remaining pure noise, and whos got the bigger  cock, or who can
 piss further, no one actually gives a rats ass.

Never get into either a pissing or wang-size contest with an elephant. ;)



pgpXCSj8bv057.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/