Security Hero Rotating Header Image

ASCII

utils

rPSA-2009-0092-1 ntp ntp-utils

<!– Envelope-to: email@address Delivery-date: Thu, 28 May 2009 16:14:57 +0100 Received: from outgoing.securityfocus.com ([205.206.231.26] helo=outgoing2.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M9hJp-0006Wx-Lx for email@address; Thu, 28 May 2009 16:14:57 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing2.securityfocus.com (Postfix) with QMQP id 065D81439E1; Thu, 28 May 2009 09:05:18 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 25867 invoked from network); 27 May 2009 22:03:58 -0000 X-Authentication-Warning: logo.rdu.rpath.com: johnsonm set sender to rPath Update Announcements <announce-noreply@rpath.com> using -r security-announce@lists.rpath.com, update-announce@lists.rpath.com, product-announce@lists.rpath.com, security-announce@lists.rpath.com, update-announce@lists.rpath.com Cc: full-disclosure@lists.grok.org.uk, vulnwatch@vulnwatch.org, bugtraq@securityfocus.com, lwn@lwn.net, full-disclosure@lists.grok.org.uk, vulnwatch@vulnwatch.org, bugtraq@securityfocus.com, lwn@lwn.net Message-ID: <4a1db8c9.47zXLoDa67xXF+g3%announce-noreply@rpath.com> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IMAPbase: 1176125385 9214 Status: O X-UID: 9214 Content-Length: 1111 X-Keywords:

Understanding Microsoft’s KB971492 IIS WebDAV Vuln

New paper: Understanding Microsoft’s KB971492 IIS WebDAV Vuln

<!– Envelope-to: email@address Delivery-date: Wed, 27 May 2009 22:28:52 +0100 Received: from outgoing.securityfocus.com ([205.206.231.27] helo=outgoing3.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M9Qg8-0000My-E2 for email@address; Wed, 27 May 2009 22:28:52 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing3.securityfocus.com (Postfix) with QMQP id E968C236F94; Wed, 27 May 2009 15:25:07 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 6030 invoked from network); 27 May 2009 19:51:57 -0000 Message-ID: <20090527195150.GA15167@dcent.unixwiz.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-IMAPbase: 1176125385 9212 Status: O X-UID: 9212 Content-Length: 871 X-Keywords:

Host file black lists , (Wed, May 27th)

Host file black lists , (Wed, May 27th)

Henry Hertz Hobbit who maintains a black list of bad hosts wrote in today with some host file links

and comments on them. I have included most of his comments with very little editing

(I removed a few names and comments about other list maintainers and corrected a bit of the grammer).

I have NOT verified all of the lists than Henry discusses below. Our users should be warned that

I have seen poorly maintained lists block legitimate sites in the past.

We have had some less attentive or overly aggressive list maintainers use our hosts

list as a block list even though it clearly states DO NOT USE AS A BLOCK LIST

and then blame isc.sans.org for the listing, http://isc.sans.org/ipsascii.html.

Other handlers have written some excellent diaries about blacklists addressing issues

such as Spam blocking by RBLs, Blacklists and politics,

and making the right choice in black list selection:

http://isc.sans.org/diary.html?storyid=3194

http://isc.sans.org/diary.html?storyid=3042

http://isc.sans.org/diary.html?storyid=1309

For more information on host based blocking this site has a good descriptions,

some lists that are on Henrys lists and some additional lists didnt include in his set.

http://www.malwarehelp.org/how-to-effectively-prevent-malware-hosts-file.html

>From Henry Hertz Hobbit:

Two old venerable lists are MVPHosts and hpHosts.

http://www.mvps.org/winhelp2002/hosts.htm

http://hosts-file.net/

MalwareDomainList is here with their lists and they block ONLY sites with malicious

content (no ads or trackers / spies):

http://www.malwaredomainlist.com/hostslist/hosts.txt

http://www.malwaredomainlist.com/

http://www.malwaredomainlist.com/mdl.php

The French connection consists of what I would call the MVPHosts file with a Franais twist

(there are some trackers that are quite prevalent if France that don’t exist any place else):

http://sysctl.org/cameleon/hosts

http://sysctl.org/cameleon/

Another list that has the most comprehensive lists that may need some pruning:

http://rlwpx.free.fr/WPFF/hosts.htm

This list primarily don’t belong on the desktop but into something like this:

http://www.peereboom.us/adsuck/

And then there is my list which includes many of the hosts that MalwareDomainList lists.

http://www.SecureMecca.com/hosts.html

http://www.HostsFile.org/hosts.html

But I provide something far more powerful called a PAC (Proxy Auto Configuration) filter

that blocks unknown threats:

http://www.SecureMecca.com/pac.html

http://www.HostsFile.org/pac.html

http://www.SecureMecca.com/Downloads/

Now I have heard you need an IQ of 130 plus or higher to use the PAC filter.

If that is a problem so be it. But consider the following points.

1. hpHosts (hosts-file.net) blocks approximately 3700 typo hosts.

I block them with just two hosts in the hosts file (ownbox.com and www.ownbox.com)

and these two rules in the PAC filter:

// OWNBOX FE TYPO

BadNetworks[i++] = 216.65.41.185, 255.255.255.255

BadNetworks[i++] = 216.65.41.188, 255.255.255.255

Now that cuts it down to size, doesn’t it? There is a lot of other power reducers and

falling through the cracks rules in there! Otherwise my file would be almost as large

as the list at rlwpx.free.fr/WPFF/hosts.htm.

2. If you enable the PAC filter on Windows in IE you will have your eyes opened.

I had full debug on that way once and found the PAC filter was even working at the level

of tellimg me I sent a print-out to the network printer! But debug really should only

be used in Firefox with debug mode set to debugNormal. Do not turn debug on in Opera or

Safari (they kill it), or IE (you will have pop-up nightmares).

3. The REGEXPs are precompiled for speed. It is faster in debug mode than John LoVerso’s

original was without any debug. But then I noticed some of his ad patterns are pretty convoluted.

But if you have to interpret them every time …

4. I notice patterns that occur frequently enough that I block yet to be discovered

hosts with patterns like these:

BadHostParts[i++] = antispy // VOTRE CHOIX

BadHostParts[i++] = antivir // VOTRE CHOIX

There are of course some white-list rules to counteract the bad rules

(and now you are back to blocking in the hosts file):

GoodDomains[i++] = antispamfilterblocker.com

GoodDomains[i++] = antivirusyellowpages.com

GoodDomains[i++] = pcantivirusreviews.com

5. Even if hosts make it past the rules for the hosts and there is no host block,

for some of the malware there are patterns and I block them as I discover and

mentally count them and consider the count high enough to go into panic mode

(and I think a lot of people are already there now):

BadURL_Parts[i++] = av2008

BadURL_Parts[i++] = av2009

BadURL_Parts[i++] = sms.exe

BadURL_Parts[i++] = smsreader

Oh yes, HostsMan is available here:

http://www.abelhadigital.com/

URL: http://isc.sans.org/diary.php?storyid=6469&rss

3rd Call – Deadline Extended

[IMF 2009] 3rd Call – Deadline Extended

<!– Envelope-to: email@address Delivery-date: Wed, 27 May 2009 16:47:57 +0100 Received: from outgoing.securityfocus.com ([205.206.231.27] helo=outgoing3.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M9LMD-0001y2-Mw for email@address; Wed, 27 May 2009 16:47:57 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing3.securityfocus.com (Postfix) with QMQP id 0470A2370CE; Wed, 27 May 2009 09:37:49 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 7111 invoked from network); 26 May 2009 19:03:31 -0000 Message-ID: <20090526190320.GB23806@cert.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: RUS-CERT, Universitaet Stuttgart User-Agent: Mutt/1.5.18 (2008-05-17) X-IMAPbase: 1176125385 9198 Status: O X-UID: 9198 Content-Length: 8364 X-Keywords:

Backdoor in com_rsgallery2 gallery extension for joomla

Backdoor in com_rsgallery2 gallery extension for joomla

<!– Envelope-to: email@address Delivery-date: Tue, 26 May 2009 16:58:59 +0100 Received: from outgoing.securityfocus.com ([205.206.231.26] helo=outgoing2.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M8z3L-0002Ld-Ef for email@address; Tue, 26 May 2009 16:58:59 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing2.securityfocus.com (Postfix) with QMQP id 0676F143742; Tue, 26 May 2009 09:55:15 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 20495 invoked from network); 26 May 2009 06:03:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; bh=MB1mx9CQQuOY66iO10m6OSm8RpcN7hzm4chypF1iqaQ=; b=szq0ATS2nMDoJRaMY3wCQJSl/85ukP7SrMSEEA39v17z6ZIKfaVFhn/Vovsh0xPgVg CLrHyhdG+8/vwSrtV4PDNWX9L/3YmMR9PdRBcGFQGaeFarknizRbwnfodiEZYfU6pHJv jlrh7wSu7WVLsjh2iCD8olkaEMRhImp81uCZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=n438N3ZnZLskV3v0hK0T6jzyRgpqntHuwd8WfOvx/huQqW6xwcPlAhHI5e7WSt/sfJ TpS+dy8IFUgBRxhgMqKtYpjGSkf8myOHcUKgyWzCW06453ZYgciKc4lXc58hINUn45dl poe0LZrOxKaz7JRP9KaqlmoI3cxGgUrhbq9Fw= User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905260803.32323.jvnkrk@gmail.com> X-IMAPbase: 1176125385 9186 Status: O X-UID: 9186 Content-Length: 2498 X-Keywords:

New cscope packages fix arbitrary code execution

[SECURITY] [DSA 1806-1] New cscope packages fix arbitrary code execution

<!– Envelope-to: email@address Delivery-date: Mon, 25 May 2009 17:47:31 +0100 Received: from outgoing.securityfocus.com ([205.206.231.26] helo=outgoing2.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M8dKl-0000wJ-NC for email@address; Mon, 25 May 2009 17:47:31 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing2.securityfocus.com (Postfix) with QMQP id C8835144259; Mon, 25 May 2009 08:14:14 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 14511 invoked from network); 24 May 2009 08:28:08 -0000 Resent-Cc: recipient list not shown: ; Old-Return-Path: <jmm@inutil.org> X-Original-To: lists-debian-security-announce@liszt.debian.org Delivered-To: lists-debian-security-announce@liszt.debian.org X-Virus-Scanned: at lists.debian.org with policy bank moderated X-Spam-Flag: NO X-Spam-Score: -9.08 X-Spam-Level: X-Spam-Status: No, score=-9.08 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FOURLA=0.1, FVGT_m_MULTI_ODD=0.02, IMPRONONCABLE_2=1, LDO_WHITELIST=-5, MURPHY_WRONG_WORD1=0.1, MURPHY_WRONG_WORD2=0.2, PGPSIGNATURE=-5, PHONENUMBER=1.5] autolearn=ham X-policyd-weight: using cached result; rate: -6.1 Message-ID: <20090524082751.GA24821@galadriel.inutil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-SA-Exim-Connect-IP: 82.83.229.75 X-SA-Exim-Mail-From: jmm@inutil.org X-SA-Exim-Scanned: No (on inutil.org); SAEximRunCond expanded to false X-Debian: PGP check passed for security officers Priority: urgent Resent-Message-ID: <h-kgsMJsh7H.A.NWB.VUQGKB@liszt> Reply-To: listadmin@securityfocus.com Mail-Followup-To: bugtraq@securityfocus.com Resent-Date: Sun, 24 May 2009 08:28:05 +0000 (UTC) Resent-From: list@liszt.debian.org (Mailing List Manager) X-IMAPbase: 1176125385 9179 Status: O X-UID: 9179 Content-Length: 5245 X-Keywords:

New pidgin packages fix several vulnerabilities

[SECURITY] [DSA 1805-1] New pidgin packages fix several vulnerabilities

<!– Envelope-to: email@address Delivery-date: Fri, 22 May 2009 21:32:55 +0100 Received: from outgoing.securityfocus.com ([205.206.231.27] helo=outgoing3.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M7bQF-0006gJ-A0 for email@address; Fri, 22 May 2009 21:32:55 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing3.securityfocus.com (Postfix) with QMQP id 99FB6237222; Fri, 22 May 2009 14:26:26 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 29893 invoked from network); 22 May 2009 20:04:27 -0000 Resent-Cc: recipient list not shown: ; Old-Return-Path: <jmm@inutil.org> X-Original-To: lists-debian-security-announce@liszt.debian.org Delivered-To: lists-debian-security-announce@liszt.debian.org X-Virus-Scanned: at lists.debian.org with policy bank moderated X-Spam-Flag: NO X-Spam-Score: -9.06 X-Spam-Level: X-Spam-Status: No, score=-9.06 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FOURLA=0.1, FVGT_m_MULTI_ODD=0.02, IMPRONONCABLE_2=1, LDO_WHITELIST=-5, MURPHY_DRUGS_REL8=0.02, MURPHY_WRONG_WORD1=0.1, MURPHY_WRONG_WORD2=0.2, PGPSIGNATURE=-5, PHONENUMBER=1.5] autolearn=ham X-policyd-weight: using cached result; rate: -6.1 Message-ID: <20090522200408.GA6386@galadriel.inutil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-SA-Exim-Connect-IP: 82.83.229.75 X-SA-Exim-Mail-From: jmm@inutil.org X-SA-Exim-Scanned: No (on inutil.org); SAEximRunCond expanded to false X-Debian: PGP check passed for security officers Priority: urgent Resent-Message-ID: <PdP5w1tVwDM.A.YQC.GVwFKB@liszt> Reply-To: listadmin@securityfocus.com Mail-Followup-To: bugtraq@securityfocus.com Resent-Date: Fri, 22 May 2009 20:04:22 +0000 (UTC) Resent-From: list@liszt.debian.org (Mailing List Manager) X-IMAPbase: 1176125385 9167 Status: O X-UID: 9167 Content-Length: 12013 X-Keywords:

New ipsec-tools packages fix denial of service

[SECURITY] [DSA 1804-1] New ipsec-tools packages fix denial of service

<!– Envelope-to: email@address Delivery-date: Wed, 20 May 2009 16:44:13 +0100 Received: from outgoing.securityfocus.com ([205.206.231.26] helo=outgoing2.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M6nxl-0003Rd-1C for email@address; Wed, 20 May 2009 16:44:13 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing2.securityfocus.com (Postfix) with QMQP id AD9C0143B50; Wed, 20 May 2009 09:20:49 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 16939 invoked from network); 20 May 2009 14:08:33 -0000 Resent-Cc: recipient list not shown: ; Old-Return-Path: <nion@debian.org> X-Original-To: lists-debian-security-announce@liszt.debian.org Delivered-To: lists-debian-security-announce@liszt.debian.org X-Virus-Scanned: at lists.debian.org with policy bank moderated X-Spam-Flag: NO X-Spam-Score: -9.08 X-Spam-Level: X-Spam-Status: No, score=-9.08 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FOURLA=0.1, FVGT_m_MULTI_ODD=0.02, IMPRONONCABLE_2=1, LDO_WHITELIST=-5, MURPHY_WRONG_WORD1=0.1, MURPHY_WRONG_WORD2=0.2, PGPSIGNATURE=-5, PHONENUMBER=1.5] autolearn=ham X-policyd-weight: using cached result; rate: -5 X-RZG-AUTH: :KHkJeFmIefYsEPPKCBl/ZNLv/wXfcKuujweZef2IiPbnG1Hpql+PuSVCX/7LuieLUUY= X-RZG-CLASS-ID: mo05 Message-ID: <20090520140643.GA25319@ngolde.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-Mailer: netcat 1.10 X-GPG: 0x73647cff X-Debian: PGP check passed for security officers Priority: urgent Resent-Message-ID: <w7iztNLAYjL.A.jXC.l7AFKB@liszt> Reply-To: listadmin@securityfocus.com Mail-Followup-To: bugtraq@securityfocus.com Resent-Date: Wed, 20 May 2009 14:08:37 +0000 (UTC) Resent-From: list@liszt.debian.org (Mailing List Manager) X-IMAPbase: 1176125385 9145 Status: O X-UID: 9144 Content-Length: 11560 X-Keywords:

CiscoWorks TFTP Directory Traversal Vulnerability

Cisco Security Advisory: CiscoWorks TFTP Directory Traversal Vulnerability

<!– Envelope-to: email@address Delivery-date: Wed, 20 May 2009 16:24:34 +0100 Received: from outgoing.securityfocus.com ([205.206.231.27] helo=outgoing3.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M6nek-00036X-Fh for email@address; Wed, 20 May 2009 16:24:34 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing3.securityfocus.com (Postfix) with QMQP id 5CB312374E7; Wed, 20 May 2009 09:21:26 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 18351 invoked from network); 20 May 2009 15:04:06 -0000 X-TACSUNS: Virus Scanned Sender: nobody@cisco.com Cc: psirt@cisco.com Message-id: <200905201050.cw@psirt.cisco.com> Errors-To: nobody@cisco.com Content-Type: Text/Plain; charset="us-ascii" Prevent-NonDelivery-Report: Content-Return: Prohibited Content-Transfer-Encoding: quoted-printable X-IMAPbase: 1176125385 9143 Status: O X-UID: 9142 Content-Length: 13356 X-Keywords:

Gone With the WINS – Part II, (Wed, May 20th)

Follow the Bouncing Malware: Gone With the WINS – Part II, (Wed, May 20th)

Imagine, if you will, that you’re the newest contestant on the latest reality-tv show, Idle American Apprentice to the Dancing Bachelorette Stars. Like all good reality shows (now there’s an oxymoron…), you have the opportunity to earn your way to be safe from elimination (you know, that time of the evening when the grumpy, scowling dude with the bad comb-over says You’re Fired), if you can manage to win some sort of utterly contrived daily challenge.

And, oh, what a challenge it is!

You’re teamed up with a partner, who is blindfolded, given a cell phone, and driven to your home. After being spun around a few dozen times to mess with their sense of direction (and really, who doesn’t like seeing dizzy, stressed-out people in blindfolds stumbling around in unfamiliar surroundings? Heck, that’s how the missus and I spend many a Friday evening… uh… um… nevermind…) they’re placed in some random room of your home. Using only the cell phone, you need to be the first contestant to somehow direct them to find the kitchen and make your pouty-lipped, rail-thin bachelorette a peanut-butter ‘n’ jelly sammich.

So, what do you do?

Obviously, before anyone will be slappin’ Smuckers and Skippy on bread, there’s going to need to be a whole lot o’back-and-forth on the phone– first, as you try to figure out where they are, and then as you try to tell them how to get where they need to be. Remember, they can’t see because they’re blindfolded, so you’ll need to rely on all of their other senses. You might start by asking them whether there is carpet on the floor, whether they hear the ticking of a clock… you might ask them to slowly walk around the room and to tell you what the furniture they find in the room feels like, etc… etc… The idea is, you have to start by trying to somehow figure out their location. Once you know where they are, then you can start to giving them some broad direction: First, face the couch… then turn left. Walk forward until you get to the wall, and then move along it to your left until you find the door. Go out through the door and turn left… Then, as you navigate them into the kitchen, you’ll get increasingly specific: open the third cupboard door to the left of the stove, the peanut butter is on the second shelf…

The overall flow in the challenge can be summed up by a series of big questions, roughly corresponding to: Where am I?, Where is the kitchen?, and Where is the stuff I need to make lil’ Miss Skinny a sammich? Answering each of these requires that you’ve successful answered each of the questions that preceded it.

This is a fairly useful analogy to the situation in which the malware that we’ve been looking at has found itself. Having exploited one of the WINS vulnerabilities patched in MS04-045, the malware is being executed in some pretty unfamiliar territory. Like your partner in the challenge, it’s not in a totally alien landscape: houses are houses… but knowing things about houses in general won’t get you navigating around a specific house. So it is for our chunk o’ malware: it’s missing all of the niceties that the operating system normally provides. To understand why this is so, it’s necessary for you to understand a little about how Windows programs actually work.

While there are literally millions of vastly different Windows programs available, in many ways, just like a house is a house, a program is a program. On one level, they do many different things… on another level, they do many of the same things: they display windows on the screen, they access information both from the filesystem, the peripherals, and from the network, they have clickable buttons, edit fields, drop down menus, scroll-bars, tabs, etc…-)

To make life easier for programmers and consistent for users (hey, imagine if EVERY application had it’s own unique user interface… ouch, that’s gonna leave a mark…) much of the normal, day-to-day stuff that programs do has been rolled into shared code libraries (Dynamic Link Libraries or DLLs in Windows). When a Windows program is built, all of the requests for the stuff found in the shared code libraries are relegated to a set of jumping off points called the Import Table. For example, if I write a program that displays a Do you really want to delete this file? message box (followed, no doubt, by a Do you really, REALLY want to delete this file request) the dialog box is displayed using the system function MessageBoxA(). When my program is compiled, every MessageBoxA() function call that I make in my application, actually goes to that jumping off point (which, up until the program loads, doesn’t jump off to anything…) When my program executes, the Windows Loader looks at the import table, and loads any of the shared DLL libraries that my program needs into its memory space. It then runs down through the list of imported functions that my program is using, and fixes up those jumping off points so that they point to the correct place within the DLL code in my program’s memory space.

Back to our analogy for a moment, the main application is like you… the person who knows their way around the house. The running application (i.e. you), knows where everything is, because it was there when the house was built (i.e. when the Windows Loader loaded up the application and fixed up the import table) The malicious code that we’re looking at has never been in this particular house before, and it doesn’t know where anything is… it’s stumbling around blindfolded and… well… skinning its knees on the coffee table in the living room as we speak.

In Part 1 of this little excursion, we wrapped things up just when the malcode, after first figuring out its own location (so it could decrypt itself), had figured out where the BaseAddress of kernel32.dll was located. In our analogy, this is the equivalent of you and your partner figuring out that they’re in the living room, and then successfully navigating to the kitchen. The kitchen (played by the enormously popular kernel32.dll) is where all the really useful tools are located… so now let’s see how we’re going to find them.

If you’ll recall, we had just returned from a subroutine that chained through several in-memory data structures (starting with the Process Environment Block) to find the BaseAddress of kernel32.dll, which is now safely stored in EAX. Here’s what we return to:

0000047C mov [esi], eax
0000047E push dword ptr [esi]
00000480 push 0EC0E4E8Eh
00000485 call sub_58E

Also recall that we had created a new chunk o’ stack for ourselves and had stored its location in ESI. When we returned from the previous subroutine, interestingly, the stack wasn’t completely cleaned up… normally a very bad programming practice that would cause your program to toss its digital cookies. However, remember that the malware created it’s own mini-stack and will (hopefully!) put things back the way it found it before it’s through. In any case, that first instruction is now shoving a copy of the base address of kernel32.dll into the lost stack space while the next instruction pushes a reference to that location onto the top of the stack. In programming parlance, the lost stack locations were used on the fly to create some space that our malcode will use like a .bss segment (the .bss segment in a program is a segment which contains initialized data… Extra Credit: Anyone know why it’s called .bss?)

Next, the malcode then pushes a pretty funky number (0xEC0E4E8E) onto the stack and then calls a subroutine. What the heck is that all about? S U B R O U T I N E ————————————–

Gadzooks! Now hold on just a darned minute! I hear you cry. When I signed up for this trip, you said ‘some assembly required’ but Tom, this is gettin’ ridiculous…

Tempted as I am to go all General Patton on your cowardly ass, I will instead gently reassure you that we’ll just take things one step at a time and work our way through this stuff together. We may even hold hands. So take a deep breath, let it out slowly– put on your most comfortable set of shoes, pour yourself a wine spritzer, and we’ll begin:

Remember from before, that good programming practice dictates that we save out the values in the registers that we’re going to use, before we use them… so that we can put everything back in place when we’re done. That’s what these four instructions are doing:

0000058E push ebx

0000058F push ebp

00000590 push esi

00000591 push edi

These match up nicely with four other instructions down near the end of the subroutine:

000005DF pop edi

000005E0 pop esi

000005E1 pop ebp

000005E2 pop ebx

Remember, those ones at the end need to pop out the values that we pushed onto the stack in the opposite order… because it’s a last-in-first-out (LIFO) stack. Which, coincidentally, also is the reason for the meaning behind the next instruction:

00000592 mov ebp, [esp+arg_4]

Looking up at the top of the subroutine code, we can see that our disassembler has done something a little weird. It’s created some variables for us, called arg_0 and arg_4. You see, the disassembler understands a couple of interesting things about how code is written, and it has taken that into account when it generated the disassembly in order to help us understand a little more about the code we’re looking at.

Generally, programs tend to do small chunks of stuff over and over again. Those chunks of stuff are organized by programmers into functions or subroutines. Functions take parameters (for instance, if you wrote a function to add two numbers, the parameters would be the two numbers to be added), and at the assembly language level, those parameters are passed on the stack. (Gosh, but this stack thing is useful, isn’t it?) Before we called this particular subroutine, we pushed some values onto the stack… since, at some point, the subroutine apparently uses those values (as we’re about to see…) the disassembler then makes sure we understand what’s going on by calling the two parameters (or arguments) to our attention, explicitly, at the top of the subroutine’s disassembly. The problem is this: the parameters are buried deep down in the stack… below the return location that gets pushed onto the stack when the subroutine is called, and even below the stuff that we just now pushed onto the stack– so we’re not gonna be able to just pop those suckers off and use ’em. That’s where these special offset variables up at the top of the subroutine come into play. The disassembler understands what’s going on, and does it’s best to explain it to us by referencing these as arg_0 and arg_4 wherever they are used. Unlike me, sometimes the disassembler will get things wrong… but for the most part (and especially in this case), it knows what it’s talking about.

Now, remembering that the arguments are pushed onto a LIFO stack, we know that the deeper in the stack the variable is, the earlier it was pushed on… so arg_4 corresponds to the BaseAddress of kernel32.dll that was pushed onto the stack with this statement:

0000047E push dword ptr [esi]

So, based on the instructions at 0000592, EBP now contains the Base address of kernel32.dll. Then, we see the following:

00000596 mov eax, [ebp+3Ch]

00000599 mov edx, [ebp+eax+78h]

0000059D add edx, ebp

so, EAX points to the BaseAddress of kernel32.dll (EBP) plus 60 (0x3C). EDX then points to whatever is in *that* address added to the BaseAddress of kernel32.dll plus 120 (0x78). Hmmm… let’s see if we can figure out what that means.

We’ve been talking all along about the BaseAddress of kernel32.dll like that actually meant something… but what? Well, when a dynamic link library (DLL) is loaded into the memory space of a program, what happens is that the full-blown .dll file itself is simply mapped directly into memory– lock, stock, and barrel. So, when we talk about the BaseAddress for the .dll, it is simply the beginning of that memory mapped file. So, in order to understand what’s going on here, we need to take a look at the format of a .dll file– which is simply another vile and sinister incarnation of the more general Portable Executable (PE) file format used for most Windows executables.

Every PE file begins with an ode to the past… an old DOS header that hangs around to keep Windows backwards compatible. (Yep, you can run Word 2007 in MS-DOS– don’t let anyone tell you differently. It won’t really be all that interesting… it’ll tell you that you need to run it under Windows, but don’t be fooled: it executed…) Now, deep down inside that old DOS header (called the MZ header… ’cause it begins with Mark Zbikowski’s initials…) at position 03C is a 32 bit value known as e_lfanew that tells you the offset from the beginning of the file to the PE header itself. In other words, that value tells you how many bytes of backwards compatible you need to skip to get to the real meat: the PE header. So what we’re seeing so far makes sense: EAX is loaded up with the value of e_lfanew and added to the BaseAddress (that’s then the beginning of the PE header). Then, EDX is loaded up with a value at 0x78 within the PE header itself. Let’s see what’s there…

Rolling down through the PE header to offset 0x78, we find that location occupied by a 32-bit value known as the Export Table RVA. When dealing with PE files, the idea of an RVA or Relative Virtual Address is used repeatedly. Because PE files can’t be guaranteed that they’ll be loaded at the same memory location every time, most of the references to locations within the file are expressed as offsets from the BaseAddress– a Relative Virtual Address or RVA. And, in this case, we’re seeing exactly why that’s useful… it’s going to make things a whole lot easier for us, because if we know anything at all, it’s the BaseAddress of kernel32.dll. In fact, in the very next instruction we see that we’re updating EDX (by adding kernel32.dll’s base address, found in EBP) so that it now points directly to the Export Table.

What the heck is an Export Table? Well, remember that DLL files are simply libraries of interesting, reusable functions… code to perform exactly the kind of stuff that our malware (and legitimate programs) need to perform over and over. But, for a DLL to be useful, it needs some way to tell other programs (programs that normally load the DLL at run-time) where, within itself, those interesting functions are found. The Export Table is a structure that acts sort of like the card-catalog in a library (uh… do libraries actually even have card catalogs anymore, or did I just date myself?), allowing the Windows Loader to know where the functions that the DLL makes available are found, so it can then fix up the Import Table of the program loading the DLL– which can then actually use the functions. The Export Table itself has a specific, known structure, which we’ll need to get on speaking terms with, because… well… the next three instructions look like this:

0000059F mov ecx, [edx+18h]

000005A2 mov ebx, [edx+20h]

000005A5 add ebx, ebp

In this case, we see that we’re copying the value found at offset 0x18 in the Export Table into ECX and the value found at offset 0x20 into EBX. Since this appears to be somewhat important, in a vaguely it causes the program to work sorta way, we should probably try to find out what those values represent…

At offset 0x18 in the Export Table structure is a 32 bit value that represents the number of named functions exported by the DLL, and the value at 0x20 is an RVA for the beginning of a list of those names. After the add instruction, EBX contains a the full address of that name list.

The next chunk of code:

000005A7 jecxz short loc_5DB

000005A9 dec ecx

000005AA mov esi, [ebx+ecx*4]

000005AD add esi, ebp

000005AF xor edi, edi

000005B1 cld

starts off by checking the value in ECX: if it is zero, we end up jumping off someplace else that… well… we’ll worry about later– otherwise, the value in ECX is decremented by one. Right off the bat, this gives us an idea of what is going on here: remember that ECX contained a count of the number of named functions that are exported by kernel32.dll… and so to me, it looks like we’re going to step through each of those names looking for something… like some sort of modern-day, silicon-based Diogenes.

Because the names of the functions exported by kernel32.dll aren’t all the same length, rather than store the names one after the other, which would require some fancy bookkeeping to keep track of name length, the list of function names is actually a list of RVA values that point to the beginning of each name. The names themselves are terminated by a zero, so keeping track of length is unnecessary. Each RVA is four bytes long, and so this instruction:

000005AA mov esi, [ebx+ecx*4]

is simply a way of calculating the location of the last RVA in the list and putting the result into ESI. As we decrease the value of ECX, we’ll move down through the list until ECX hits zero, where, it appears the loop will terminate. The next two instructions clear out the value of EDI (remember how XOR works?) and then clears the Direction flag so that when the next chunk o’ code begins rolling over the function name, it’s for certain going to be moving in the correct direction. (Don’t worry about it… just trust me, it’s necessary.)

Now if that little excursion into the world of faith wasn’t enough for you, the next few instructions will require you to take my word on even more stuff… ’cause explainin’ how we get from one to the other would take us WAAAAY beyond the friendly confines of this little essay. (I would never lie to you… about anything really, really important….) So, trust me… this stuff here:

000005B2 xor eax, eax

000005B4 lodsb

000005B5 cmp al, ah

000005B7 jz short loc_5C0

000005B9 ror edi, 0Dh

000005BC add edi, eax

000005BE jmp short loc_5B2

is actually the assembly language equivalent of the C function:

unsigned long hash(char *function_name)

{

while (*function_name != 0) {

hash = hash (32 – 0x0D) | hash

}

}

This function takes a function name (or really, any string) and then creates a hash value for that name. Wow, I hear you say, it makes a hash value! That’s soooo cool… But what is a hash value? A hash value is the result of a function that simply takes a large chunk o’ source data, and creates a sort of digital fingerprint– a much shorter hash value that in some weird mathematical way represents the source. Now because we’re representing a large value using a much smaller value, there is no question that each of the resulting hashes will very likely map to more than one single source (something called a hash collision) but for the purposes here, this is a quick and dirty way for our malware to find the function it wants to use, without ever having to actually have the name of the function stuffed somewhere in it’s code. Why is that important? Well, first of all, it makes reverse engineering these things all that much more difficult, but it also makes it harder for an IDS to catch the code as it flies by.

Next, we see the following code:

000005C0 cmp edi, [esp+arg_0]

000005C4 jnz short loc_5A7

This portion of the code begins by comparing the hash value that we just created against that funky number that was pushed onto the stack, as a parameter for this function… remember… 0x0EC0E4E8E… If it doesn’t match, we jump back up to the beginning of our loop, check to see if ECX is zero, decrement it, and check the next name– lather, rinse, repeat. If it does match, then we load up EBX with the value found at offset 0x24 of the Export Table (the address of which is still in EDX):

000005C6 mov ebx, [edx+24h]

000005C9 add ebx, ebp

Offset 0x24 of the Export Table contains the RVA of the beginning of the OrdinalName list. The ordinal of a function is simply its number (1, 2, 3, 4…) within the list of all functions exported by the DLL. Every exported function has an ordinal– but because every function may not have a name– some are only ever known by their ordinal. (Why? Because you can make you DLL smaller by forgoing names and using ordinals only… sarcasm and we all know that the Oompah Loompahs out in Redmond really care about bloat /sarcasm… hell, they set the default file alignment on their linker to 4096 and routinely statically link the MSVC runtime in every executable… So, of course, they’re gonna want to have a way to save a few bytes by jettisoning the damn function names… But, I digress…) Because of this, the actual location of the code must always be accessed through the ordinal list. The OrdinalName list contains the ordinal for each named exported function, in the same order that the names appear. So… if you know where you are in the list o’ names, you can simply look up the correct ordinal… In the code above, we first load EBX with the OrdinalName list’s RVA, and then add the BaseAddress of kernel32.dll to it.

000005CB mov cx, [ebx+ecx*2]

Ordinals are only 2 bytes long, and since ECX contains the current position where we found our name on the name list, it’s pretty straightforward to use that same number to get us our ordinal off of the OrdinalName list… which we conveniently load right back into ECX.

000005CF mov ebx, [edx+1Ch]

000005D2 add ebx, ebp

The FunctionAddress list itself is found at offset 0x1C in the Export Table. For each exported function, the FunctionAddress list contains the RVA of the actual function’s code… listed in ordinal order. So we load the RVA of the beginning of the FunctionAddress list into EBX and add kernel32.dll’s BaseAddress (in EBP).

000005D4 mov eax, [ebx+ecx*4]

000005D7 add eax, ebp

000005D9 jmp short loc_5DD

At this point, ECX contains our ordinal, and each of the addresses in the FunctionAddress list is 4 bytes long… so the instructions above load the RVA of the function we’re looking for into EAX and then add the BaseAddress of kernel32.dll. We then jump to some code that cleans everything up and returns from our subroutine with the information we’re looking for tucked away inside EAX. If something goes south (i.e. we get through the whole list without finding a matching hash) then the subroutine will return with EAX zeroed out.

So, what function was represented by the magic hash value we passed in? Here’s a list of some of the hash values for kernel32.dll functions and also some additional code that shows some other functions being located:

Function Name Hash

LoadLibraryA 0xEC0E4E8E

CreateProcessA 0x16B3FE72

ExitThread 0x60E0CEEF

0000047E push dword ptr [esi]

00000480 push 0EC0E4E8Eh

00000485 call sub_58E

0000048A mov [esi+4], eax

0000048D push dword ptr [esi]

0000048F push 16B3FE72h

00000494 call sub_58E

00000499 mov [esi+8], eax

0000049C push dword ptr [esi]

0000049E push 60E0CEEFh

000004A3 call sub_58E

000004A8 mov [esi+0Ch], eax

Note that when each of the calls to the sub_58E subroutine returns, the stack is again, messed up. This is done on purpose to continue to open up more pseudo-bss space in which the malware stores the location of a specific kernel32.dll function. Since ESI marks the beginning of the original stack, that is used as the reference point for accessing the addresses of the functions. At ESI+0x04, is the address of LoadLibraryA, at ESI+0x08 is the address of CreateProcessA, and at ESI+0x0C is the address of ExitThread.

Next, the malware puts one of these newly acquired functions to use:

000004AB push 3233h

000004B0 push 5F327377h

000004B5 push esp

000004B6 call dword ptr [esi+4]

000004B9 mov [esi+10h], eax

All of that pushin’ at the beginning of this section is actually shoving the name ws2_32 at the LoadLibraryA function (Go and look at an ASCII chart… and remember stuff is backwards). The additional push of ESP (LoadLibraryA only takes one parameter) is simply to again, mess up the stack and leave extra room for storing the BaseAddress of ws2_32.dll at esi+0x10 when we get back from the kernel32.dll code.

000004BC push dword ptr [esi+10h]

000004BF push 0ADF509D9h

000004C4 call sub_58E

000004C9 mov [esi+14h], eax

000004CC push dword ptr [esi+10h]

000004CF push 60AAF9ECh

000004D4 call sub_58E

000004D9 mov [esi+18h], eax

000004DC push dword ptr [esi+10h]

000004DF push 79C679E7h

000004E4 call sub_58E

000004E9 mov [esi+1Ch], eax

000004EC push dword ptr [esi+10h]

000004EF push 3BFCEDCBh

000004F4 call sub_58E

000004F9 mov [esi+20h], eax

Now, using the BaseAddress of the ws2_32.dll, the malware looks for hashes matching the following:

WSASocketA 0xADF509D9 (esi+0x14)

connect 0x60AAF9EC (esi+0x18)

closesocket 0x79C679E7 (esi+0x1C)

WSAStartup 0x3BFCEDCB (esi+0x20)

And stores them at the offsets from ESI listed above…

Ok… so, boys and girls, how was that for a wild ride? Does your brain hurt yet? Man, oh man… mine does!

Well, we made it to the kitchen, and we figured out how to find all of the tools necessary for our malware to make a sammich… In the next installment, we’ll take a look at how that sammich gets made and what it actually does.

Tom Liston – InGuardians, Inc.

Handler On Duty

Chairman – SANS WhatWorks in Virtualization and Cloud Computing Security Summit

URL: http://isc.sans.org/diary.php?storyid=6412&rss

Insufficient Authentication vulnerability in Asus notebook

RE: Insufficient Authentication vulnerability in Asus notebook

<!– Envelope-to: email@address Delivery-date: Wed, 20 May 2009 02:21:31 +0100 Received: from outgoing.securityfocus.com ([205.206.231.27] helo=outgoing3.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M6aUt-0005WA-DS for email@address; Wed, 20 May 2009 02:21:31 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing3.securityfocus.com (Postfix) with QMQP id 52EEC237B88; Tue, 19 May 2009 12:12:36 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 14846 invoked from network); 17 May 2009 16:10:20 -0000 "'Susan Bradley'" <sbradcpa@pacbell.net>, "my.security.lists@gmail.com" <my.security.lists@gmail.com> Cc: MustLive <mustlive@websecurity.com.ua>, "bugtraq@securityfocus.com" <bugtraq@securityfocus.com> Thread-Topic: Insufficient Authentication vulnerability in Asus notebook Thread-Index: AcnUzY3WGGvPYB6LTji1JdtcfuBegAAAq1rgAI3XvlA= Message-ID: <097B1E4792366344925A4B6B99C00A82932CDCA267@zaphod.home.jalojash.org> References: <008001c9d497$55238070$010000c0@ml> <4A0C27DA.1000207@pacbell.ne t> <4A0C4A03.2090809@gmail.com><4A0C7371.7000408@pacbell.net> <D6DC62EC7225DA44812A53607A9886C80128120E@SVR-AMED-MAIL02.amedisys.com> In-Reply-To: <D6DC62EC7225DA44812A53607A9886C80128120E@SVR-AMED-MAIL02.amedisys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IMAPbase: 1176125385 9140 Status: O X-UID: 9139 Content-Length: 3652 X-Keywords:

New Linux 2.6.26 packages fix several vulnerabilities

[SECURITY] [DSA 1800-1] New Linux 2.6.26 packages fix several vulnerabilities

<!– Envelope-to: email@address Delivery-date: Wed, 20 May 2009 00:36:49 +0100 Received: from outgoing.securityfocus.com ([205.206.231.27] helo=outgoing3.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M6YrZ-00040U-1W for email@address; Wed, 20 May 2009 00:36:49 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing3.securityfocus.com (Postfix) with QMQP id 2F54523795B; Tue, 19 May 2009 12:07:32 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 27007 invoked from network); 15 May 2009 19:29:11 -0000 Resent-Cc: recipient list not shown: ; Old-Return-Path: <dannf@ldl.fc.hp.com> X-Original-To: lists-debian-security-announce@liszt.debian.org Delivered-To: lists-debian-security-announce@liszt.debian.org X-Virus-Scanned: at lists.debian.org with policy bank moderated X-Spam-Flag: NO X-Spam-Score: -9.557 X-Spam-Level: X-Spam-Status: No, score=-9.557 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FOURLA=0.1, FVGT_m_MULTI_ODD=0.02, IMPRONONCABLE_1=1, IMPRONONCABLE_2=1, LDO_WHITELIST=-5, MDO_CABLE_TV3=0.5, MURPHY_DRUGS_REL8=0.02, MURPHY_WRONG_WORD1=0.1, MURPHY_WRONG_WORD2=0.2, PGPSIGNATURE=-5, PHONENUMBER=1.5, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003] autolearn=ham X-policyd-weight: using cached result; rate: -7 X-Virus-Scanned: Debian amavisd-new at ldl.fc.hp.com Message-ID: <20090515191750.GB1911@ldl.fc.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Debian: PGP check passed for security officers Priority: urgent Resent-Message-ID: <0ZkxcQQFzvK.A.q4E.AKcDKB@liszt> Reply-To: listadmin@securityfocus.com Mail-Followup-To: bugtraq@securityfocus.com Resent-Date: Fri, 15 May 2009 19:29:04 +0000 (UTC) Resent-From: list@liszt.debian.org (Mailing List Manager) X-IMAPbase: 1176125385 9130 Status: O X-UID: 9130 Content-Length: 39073 X-Keywords:

OS X CFNetwork advisory

n.runs-SA-2009.001 – OS X CFNetwork advisory

<!– Envelope-to: email@address Delivery-date: Tue, 19 May 2009 23:37:42 +0100 Received: from outgoing.securityfocus.com ([205.206.231.27] helo=outgoing3.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M6XwM-00038v-6z for email@address; Tue, 19 May 2009 23:37:42 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing3.securityfocus.com (Postfix) with QMQP id A824B23725A; Tue, 19 May 2009 12:05:47 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 1259 invoked from network); 15 May 2009 08:48:31 -0000 X-PGP-Universal: processed; by wsehliesr on Fri, 15 May 2009 10:47:24 +0100 <bugtraq@securityfocus.com> Cc: <cve@mitre.org>, <soc@us-cert.gov>, <cert@cert.org>, <vuln@secunia.com> References: In-Reply-To: Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAEqlc0sEqCZMjFiSy1tj+RPCgAAAEAAAAOn2ZlC3QNxEifjbeRIj9v0BAAAAAA==@nruns.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclgV8VyTasY80P/SvyuaocdB38PbR03y5Eg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: de X-Provags-ID: V01U2FsdGVkX19XrkE+UWt9zjPFmT4HQwOD7vq3l+yC8p9XtRe AP6y4mwk2eFAVBmneGdvbpUvV04Keav2nZTWeSb6ZI84GtpzUf kxhlblIXTqringwevR0/A== X-IMAPbase: 1176125385 9125 Status: O X-UID: 9125 Content-Length: 4275 X-Keywords:

1 kernel

rPSA-2009-0084-1 kernel

<!– Envelope-to: email@address Delivery-date: Tue, 19 May 2009 23:10:31 +0100 Received: from outgoing.securityfocus.com ([205.206.231.27] helo=outgoing3.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M6XW3-0002lQ-Hh for email@address; Tue, 19 May 2009 23:10:31 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing3.securityfocus.com (Postfix) with QMQP id E7CC4237898; Tue, 19 May 2009 12:04:42 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 6426 invoked from network); 16 May 2009 02:40:13 -0000 X-Authentication-Warning: logo.rdu.rpath.com: johnsonm set sender to rPath Update Announcements <announce-noreply@rpath.com> using -r security-announce@lists.rpath.com, update-announce@lists.rpath.com, product-announce@lists.rpath.com Cc: full-disclosure@lists.grok.org.uk, vulnwatch@vulnwatch.org, bugtraq@securityfocus.com, lwn@lwn.net Message-ID: <4a0e276e.mOi90QgHieLvGJn7%announce-noreply@rpath.com> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IMAPbase: 1176125385 9123 Status: O X-UID: 9123 Content-Length: 1684 X-Keywords:

Insufficient Authentication vulnerability in Asus notebook

RE: Insufficient Authentication vulnerability in Asus notebook

<!– Envelope-to: email@address Delivery-date: Thu, 14 May 2009 22:53:57 +0100 Received: from outgoing.securityfocus.com ([205.206.231.26] helo=outgoing2.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1M4isG-0003Nf-Si for email@address; Thu, 14 May 2009 22:53:57 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing2.securityfocus.com (Postfix) with QMQP id B23D8143795; Thu, 14 May 2009 14:49:27 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 4903 invoked from network); 14 May 2009 20:38:43 -0000 X-X-Sender: sq01@blade.ccs.yorku.ca Cc: "'Susan Bradley'" <sbradcpa@pacbell.net>, "my.security.lists@gmail.com" <my.security.lists@gmail.com>, MustLive <mustlive@websecurity.com.ua>, "bugtraq@securityfocus.com" <bugtraq@securityfocus.com> In-Reply-To: <D6DC62EC7225DA44812A53607A9886C80128120E@SVR-AMED-MAIL02.amedisys.com> Message-ID: <Pine.LNX.4.64.0905141633480.28313@blade.ccs.yorku.ca> References: <008001c9d497$55238070$010000c0@ml> <4A0C27DA.1000207@pacbell.ne t> <4A0C4A03.2090809@gmail.com><4A0C7371.7000408@pacbell.net> <D6DC62EC7225DA44812A53607A9886C80128120E@SVR-AMED-MAIL02.amedisys.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-IMAPbase: 1176125385 9096 Status: O X-UID: 9096 Content-Length: 2434 X-Keywords: