|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- application/octet-stream attachment: Readme.exe
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] SUSE Security Announcement: libpng (SUSE-SA:2004:023)
From: Thomas Biege (thomas
suse.de)
Date: Wed Aug 04 2004 - 10:12:26 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----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/rpm/src/libpng-1.2.5-191.src.rpm
16dde1bf26f8c9c006ccad4779d138d7
SUSE Linux 8.1:
ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/libpng-1.2.4-115.i586.rpm
88dc17c0edccfcd65fea3539379de370
patch rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/libpng-1.2.4-115.i586.patch.rpm
24d8632e5454e46ce4623c5a672a3d5d
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/libpng-1.2.4-115.src.rpm
e3086525ee914ddc5dc0c7da7ab96a25
SUSE Linux 8.0:
ftp://ftp.suse.com/pub/suse/i386/update/8.0/gra1/libpng-2.1.0.12-169.i386.rpm
09b22a2fab61b1018ce73e2965777123
patch rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.0/gra1/libpng-2.1.0.12-169.i386.patch.rpm
097de7e1c11106390128b6996041fe3c
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/libpng-2.1.0.12-169.src.rpm
9e1da14f139fc4dcf481cdf836397da7
x86-64 Platform:
SUSE Linux 9.1:
ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/libpng-1.2.5-182.7.x86_64.rpm
c6c0f425059cf94803952530f0e9ba02
patch rpm(s):
ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/libpng-1.2.5-182.7.x86_64.patch.rpm
01814d5c445560c6bcca0f1d9221e5be
source rpm(s):
ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/libpng-1.2.5-182.7.src.rpm
27c4236b2ca11a760b3028c5058db7cf
SUSE Linux 9.0:
ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/libpng-1.2.5-191.x86_64.rpm
5e8c7dcfe20c386150c4129bb549569f
patch rpm(s):
ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/libpng-1.2.5-191.x86_64.patch.rpm
4fc9a5a29f5c813b32b9dee230250b17
source rpm(s):
ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/libpng-1.2.5-191.src.rpm
526c0048344f1aa467903b1a8bce3506
______________________________________________________________________________
5) Pending vulnerabilities in SUSE Distributions and Workarounds:
- mod_ssl
A remotely exploitable format string bug has been found in the
logging function of mod_ssl.
New packages are available at our FTP servers.
- lha
A source code review of lha was conducted by the SuSE Security-Team
to fix all possible buffer overflows.
New packages are available at our FTP servers.
- gfxboot/bootsplash-theme-SuSE/bootsplash-theme-SuSE-Home
A bug in gfxboot on SUSE LINUX 9.1 caused the lilo boot password
to be shown in cleartext while typing.
The standard boot loader is grub.
New packages are available at our FTP servers.
- liby2util
File names of patch files are no longer passed to gpg via the
system() call. Since those file names are not protected by a digital
signature, an attacker could previously manage to implant shell
code.
New packages are available at our FTP servers.
- pure-ftpd
This update fixes a possible DoS attack because of a bug in the
accept_client function handling the setup of new connections.
New packages are available at our FTP servers.
- neon
This update adds a missing filter for control characters.
New packages are available at our FTP servers.
- pavuk
This update fixes several buffer overflows in pavuk's digest
authentication support. Thanks to Matthew Murphy for reporting
this issue to us.
New packages are available at our FTP servers.
- sox
Several buffer overflows in the 'sox' and 'play' have been fixed that
can be exploited by playing specially crafted .wav files. (CAN-2004-0557)
New packages are available at our FTP servers.
- gaim
The SuSE Security Team discovers various remotely exploitable buffer
overflows in the MSN-protocol parsing functions of gaim. The only
affected product is SUSE LINUX 9.1.
New packages will be available soon. (CAN-2004-0500)
- kernel
Paul Starzetz from iSEC informed us about a race condition in the 64bit
file offset handling code of the kernel.
New kernels for SUSE LINUX Enterprise Server 9 are available from
the maintenance-web. The updates for the SUSE LINUX 9.1 kernels are
available from our FTP servers.
Kernel update packages for older SUSE LINUX distributions will be
available in the next few days and will be announced with a dedicated
advisory.
______________________________________________________________________________
6) standard appendix: authenticity verification, additional information
- Package authenticity verification:
SUSE update packages are available on many mirror ftp servers all over
the world. While this service is being considered valuable and important
to the free and open source software community, many users wish to be
sure about the origin of the package and its content before installing
the package. There are two verification methods that can be used
independently from each other to prove the authenticity of a downloaded
file or rpm package:
1) md5sums as provided in the (cryptographically signed) announcement.
2) using the internal gpg signatures of the rpm package.
1) execute the command
md5sum <name-of-the-file.rpm>
after you downloaded the file from a SUSE ftp server or its mirrors.
Then, compare the resulting md5sum with the one that is listed in the
announcement. Since the announcement containing the checksums is
cryptographically signed (usually using the key securitysuse.de),
the checksums show proof of the authenticity of the package.
We disrecommend to subscribe to security lists which cause the
email message containing the announcement to be modified so that
the signature does not match after transport through the mailing
list software.
Downsides: You must be able to verify the authenticity of the
announcement in the first place. If RPM packages are being rebuilt
and a new version of a package is published on the ftp server, all
md5 sums for the files are useless.
2) rpm package signatures provide an easy way to verify the authenticity
of an rpm package. Use the command
rpm -v --checksig <file.rpm>
to verify the signature of the package, where <file.rpm> is the
filename of the rpm package that you have downloaded. Of course,
package authenticity verification can only target an un-installed rpm
package file.
Prerequisites:
a) gpg is installed
b) The package is signed using a certain key. The public part of this
key must be installed by the gpg program in the directory
~/.gnupg/ under the user's home directory who performs the
signature verification (usually root). You can import the key
that is used by SUSE in rpm packages for SUSE Linux by saving
this announcement to a file ("announcement.txt") and
running the command (do "su -" to be root):
gpg --batch; gpg < announcement.txt | gpg --import
SUSE Linux distributions version 7.1 and thereafter install the
key "buildsuse.de" upon installation or upgrade, provided that
the package gpg is installed. The file containing the public key
is placed at the top-level directory of the first CD (pubring.gpg)
and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de .
- SUSE runs two security mailing lists to which any interested party may
subscribe:
suse-securitysuse.com
- general/linux/SUSE security discussion.
All SUSE security announcements are sent to this list.
To subscribe, send an email to
<suse-security-subscribesuse.com>.
suse-security-announcesuse.com
- SUSE's announce-only mailing list.
Only SUSE's security announcements are sent to this list.
To subscribe, send an email to
<suse-security-announce-subscribesuse.com>.
For general information or the frequently asked questions (faq)
send mail to:
<suse-security-infosuse.com> or
<suse-security-faqsuse.com> respectively.
=====================================================================
SUSE's security contact is <securitysuse.com> or <securitysuse.de>.
The <securitysuse.de> public key is listed below.
=====================================================================
______________________________________________________________________________
The information in this advisory may be distributed or reproduced,
provided that the advisory is not modified in any way. In particular,
it is desired that the clear-text signature shows proof of the
authenticity of the text.
SUSE Linux AG makes no warranties of any kind whatsoever with respect
to the information contained in this security advisory.
Type Bits/KeyID Date User ID
pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team <securitysuse.de>
pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <buildsuse.de>
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
mQGiBDnu9IERBACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff
4JctBsgs47tjmiI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0d
M+HFrruCgBlWt6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcO
QliHu8jwRQHxlRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrK
XBUX+K7u4ifrZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBE
D3+D2t1V/f8l0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUd
G5sRA/9ovnc1krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NM
CC3Kj9aZHfA+ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoE
myW/xC1sBbDkDUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNr
YWdlIFNpZ25pbmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkD
wmcABAsKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6d
NfnwI2PAsgCgjH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCe
QOMQAAqrpNzOAKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNe
LZa/qM2JARUDBRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3t
XXaJJp9pHMa4fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBU
D9i579uifklLsnr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ3
0kNLWVXWATMnsnT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot
1ZPtB0lniw+/xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpW
cRgdn2DUVMmpU661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0E
ExECAB0FAjxqqTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1f
AJ9dR7saz2KPNwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0E
Oe70khAIAISR0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/
HZnh3TwhBIw1FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44h
t5h+6HMBzoFCMAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPT
tGzcAi2jVl9hl3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM
523AMgpPQtsKm9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q
2Y+GqZ+yAvNWjRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8
QnSs0wwPg3xEullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWaw
JxRLKH6Zjo/FaKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ
1sj2xYdB1xO0ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCH
ORrNjq9pYWlrxsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1
wwylxadmmJaJHzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQY
EQIADAUCOe70kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol
0JdGwACeKTttgeVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAK
CRCoTtronIAKyofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3co
SPihn1+OBNyZAQ0DNuEtBAAAAQgAoCRcd7SVZEFcumffyEwfLTcXQjhKzOahzxpo
omuF+HIyU4AGq+SU8sTZ/1SsjhdzzrSAfv1lETACA+3SmLr5KV40Us1w0UC64cwt
A46xowVq1vMlH2Lib+V/qr3b1hE67nMHjysECVx9Ob4gFuKNoR2eqnAaJvjnAT8J
/LoUC20EdCHUqn6v+M9t/WZgC+WNR8cq69uDy3YQhDP/nIan6fm2uf2kSV9A7ZxE
GrwsWl/WX5Q/sQqMWaU6r4az98X3z90/cN+eJJ3vwtA+rm+nxEvyev+jaLuOQBDf
ebh/XA4FZ35xmi+spdiVeJH4F/ubaGlmj7+wDOF3suYAPSXT2QAFEbQlU3VTRSBT
ZWN1cml0eSBUZWFtIDxzZWN1cml0eUBzdXNlLmRlPokBFQMFEDbhLUfkWLKHsco8
RQEBVw4H/1vIdiOLX/7hdzYaG9crQVIk3QwaB5eBbjvLEMvuCZHiY2COUg5QdmPQ
8SlWNZ6k4nu1BLcv2g/pymPUWP9fG4tuSnlUJDrWGm3nhyhAC9iudP2u1YQY37Gb
B6NPVaZiYMnEb4QYFcqv5c/r2ghSXUTYk7etd6SW6WCOpEqizhx1cqDKNZnsI/1X
11pFcO2N7rc6byDBJ1T+cK+F1Ehan9XBt/shryJmv04nli5CXQMEbiqYYMOu8iaA
8AWRgXPCWqhyGhcVD3LRhUJXjUOdH4ZiHCXaoF3zVPxpeGKEQY8iBrDeDyB3wHmj
qY9WCX6cmogGQRgYG6yJqDalLqrDOdmJARUDBRA24S0Ed7LmAD0l09kBAW04B/4p
WH3f1vQn3i6/+SmDjGzUu2GWGq6Fsdwo2hVM2ym6CILeow/K9JfhdwGvY8LRxWRL
hn09j2IJ9P7H1Yz3qDf10AX6V7YILHtchKT1dcngCkTLmDgC4rs1iAAl3f089sRG
BafGPGKv2DQjHfR1LfRtbf0P7c09Tkej1MP8HtQMW9hPkBYeXcwbCjdrVGFOzqx+
AvvJDdT6a+oyRMTFlvmZ83UV5pgoyimgjhWnM1V4bFBYjPrtWMkdXJSUXbR6Q7Pi
RZWCzGRzwbaxqpl3rK/YTCphOLwEMB27B4/fcqtBzgoMOiaZA0M5fFoo54KgRIh0
zinsSx2OrWgvSiLEXXYKiEYEEBECAAYFAjseYcMACgkQnkDjEAAKq6ROVACgjhDM
/3KM+iFjs5QXsnd4oFPOnbkAnjYGa1J3em+bmV2aiCdYXdOuGn4ZiQCVAwUQN7c7
whaQN/7O/JIVAQEB+QP/cYblSAmPXxSFiaHWB+MiUNw8B6ozBLK0QcMQ2YcL6+Vl
D+nSZP20+Ja2nfiKjnibCv5ss83yXoHkYk2Rsa8foz6Y7tHwuPiccvqnIC/c9Cvz
dbIsdxpfsi0qWPfvX/jLMpXqqnPjdIZErgxpwujas1n9016PuXA8K3MJwVjCqSKI
RgQQEQIABgUCOhpCpAAKCRDHUqoysN/3gCt7AJ9adNQMbmA1iSYcbhtgvx9ByLPI
DgCfZ5Wj+f7cnYpFZI6GkAyyczG09sE=
=LRKC
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iQEVAwUBQRD6oHey5gA9JdPZAQH0sQf/Y8TYYttWr44JA29vuduY6dZg4HkCujEh
tMjOLSxJ2MfvLkbY5dGdjpwx5ih4it57jt0IeWfcjQ3CeQOA/3z6xRYwlQ0QgzXD
YOaGdq1W30FDBfphZUvBvBrWbzJpETFEcb36PEMSncedpx4a7Hmz3GbDiAPoMMke
/ykL9NG5ooSvmf09LreXPl5xD+mbT9qxX0Mw0nSixmyMKTJBnqub+Sa03lnmq0Ud
c+R5UaG9ncB3MZfLK4YlZVygpIPn6+ezoEQ4KUvI91ESNdvoqozHNhf//37TzRLL
noVNSAouV1R1aEeFGxjtHVatnlWdv/NTekxW5rcs2ENQ1bDT/TPVQw==
=ossK
-----END PGP SIGNATURE-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] [ GLSA 200408-02 ] Courier: Cross-site scripting vulnerability in SqWebMail
From: Thierry Carrez (koongentoo.org)
Date: Wed Aug 04 2004 - 10:51:04 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----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
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.
License
=======
Copyright 2004 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).
The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.
http://creativecommons.org/licenses/by-sa/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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
RE: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap
From: Todd Towles (toddtowlesbrookshires.com)
Date: Wed Aug 04 2004 - 10:19:31 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com] On Behalf Of David Maynor
Sent: Tuesday, August 03, 2004 6:15 PM
To: Day Jay
Cc: full-disclosurelists.netsys.com
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 <d4yj4yyahoo.com> 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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
RE: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap
From: Todd Towles (toddtowlesbrookshires.com)
Date: Wed Aug 04 2004 - 10:17:34 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I think he is just mad because he can't drink yet.
-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com] On Behalf Of Martin
Mkrtchian
Sent: Tuesday, August 03, 2004 5:35 PM
To: Day Jay
Cc: full-disclosurelists.netsys.com
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 <d4yj4yyahoo.com> 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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap
From: Exibar (exibarthelair.com)
Date: Wed Aug 04 2004 - 10:54:00 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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" <dotsecuregmail.com>
To: "Day Jay" <d4yj4yyahoo.com>
Cc: <full-disclosurelists.netsys.com>
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 <d4yj4yyahoo.com> 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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap
From: Micah McNelly (micahstyle.net)
Date: Wed Aug 04 2004 - 11:17:04 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] [OpenPKG-SA-2004.035] OpenPKG Security Advisory (png)
From: OpenPKG (openpkgopenpkg.org)
Date: Wed Aug 04 2004 - 10:12:21 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
________________________________________________________________________
OpenPKG Security Advisory The OpenPKG Project
http://www.openpkg.org/security.html http://www.openpkg.org
openpkg-securityopenpkg.org openpkgopenpkg.org
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 "<prefix>/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).
$ ftp ftp.openpkg.org
ftp> bin
ftp> cd release/2.1/UPD
ftp> get png-1.2.5-2.1.1.src.rpm
ftp> bye
$ <prefix>/bin/openpkg rpm -v --checksig png-1.2.5-2.1.1.src.rpm
$ <prefix>/bin/openpkg rpm --rebuild png-1.2.5-2.1.1.src.rpm
$ su -
# <prefix>/bin/openpkg rpm -Fvh <prefix>/RPM/PKG/png-1.2.5-2.1.1.*.rpm
Additionally, we recommend that you rebuild and reinstall
all dependent packages (see above), if any, too [5][6].
________________________________________________________________________
References:
[1] http://www.libpng.org/pub/png/
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0597
[3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0598
[4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0599
[5] http://www.openpkg.org/tutorial.html#regular-source
[6] http://www.openpkg.org/tutorial.html#regular-binary
[7] ftp://ftp.openpkg.org/release/2.1/UPD/png-1.2.5-2.1.1.src.rpm
[8] ftp://ftp.openpkg.org/release/2.0/UPD/png-1.2.5-2.0.3.src.rpm
[9] ftp://ftp.openpkg.org/release/2.1/UPD/
[10] ftp://ftp.openpkg.org/release/2.0/UPD/
[11] http://www.openpkg.org/security.html#signature
________________________________________________________________________
For security reasons, this advisory was digitally signed with the
OpenPGP public key "OpenPKG <openpkgopenpkg.org>" (ID 63C4CB9F) of the
OpenPKG project which you can retrieve from http://pgp.openpkg.org and
hkp://pgp.openpkg.org. Follow the instructions on http://pgp.openpkg.org/
for details on how to verify the integrity of this advisory.
________________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Comment: OpenPKG <openpkgopenpkg.org>
iD8DBQFBEPzJgHWT4GPEy58RAqObAJ9P2rR/N8nfXDmOQEBb5rcUdMvUNwCfTaY3
vHQGjayhxr3KyVQ5PqVgG7A=
=svpv
-----END PGP SIGNATURE-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] IFH-ADV-31340 Cmd.exe allow local (and sometimes remote) command execution
From: Jeremiah Cornelius (jeremiahnur.net)
Date: Wed Aug 04 2004 - 11:40:58 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 " <infohackinghush.com>
To: <full-disclosurelists.netsys.com>
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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: FW: [Full-Disclosure] Question for DNS pros
From: John Hall (j.hallf5.com)
Date: Wed Aug 04 2004 - 13:49:50 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: FW: [Full-Disclosure] Question for DNS pros
From: John Hall (j.hallf5.com)
Date: Wed Aug 04 2004 - 14:03:50 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: FW: [Full-Disclosure] Question for DNS pros
From: John Hall (j.hallf5.com)
Date: Wed Aug 04 2004 - 13:23:53 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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;
>
><John Hall>
>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.
></John Hall>
>
>
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 10000 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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] MDKSA-2004:079 - Updated libpng packages fix multiple vulnerabilities
From: Mandrake Linux Security Team (securitylinux-mandrake.com)
Date: Wed Aug 04 2004 - 14:46:02 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----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 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)
iD8DBQFBETz6mqjQ0CJFipgRAvFmAKCcUjBy2p3bE5PXyz632vO7913KSgCfQg6n
2U1ygm+s21s2MMZP+5eBG8I=
=zRaM
-----END PGP SIGNATURE-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] RE: Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap
From: Shagghie (shagghiegmx.net)
Date: Wed Aug 04 2004 - 15:19:28 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
RE: [Full-Disclosure] Tipping Point IPS systems
From: Keifer, Trey (Trey.Keiferfishnetsecurity.com)
Date: Wed Aug 04 2004 - 15:24:30 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 <http://www.fishnetsecurity.com/>
_____
From: Ryan Sumida [mailto:rsumidacsulb.edu]
Sent: Tuesday, August 03, 2004 3:46 PM
To: full-disclosurelists.netsys.com
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 entities
other 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.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap
Valdis.Kletnieksvt.edu
Date: Wed Aug 04 2004 - 15:37:00 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, 04 Aug 2004 09:17:04 PDT, Micah McNelly <micahstyle.net> 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? ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iD8DBQFBEUjscC3lWbTT17ARAihrAJ46GhK0+SSgrh0h20P5AUYsjYRR/ACbBhaw
xqTtSIGHBYUy0QEi4G2ge20=
=d72+
-----END PGP SIGNATURE-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Clear text password exposure in Datakey's tokens and smartcards
From: Toomas Soome (Toomas.Soomemicrolink.ee)
Date: Wed Aug 04 2004 - 15:11:48 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap
From: Micah McNelly (micahstyle.net)
Date: Wed Aug 04 2004 - 15:55:20 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Valdis.Kletnieksvt.edu wrote:
>On Wed, 04 Aug 2004 09:17:04 PDT, Micah McNelly <micahstyle.net> 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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: FW: [Full-Disclosure] Question for DNS pros
From: Gary E. Miller (gemrellim.com)
Date: Wed Aug 04 2004 - 16:34:10 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----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
gemrellim.com 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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Linux kernel file offset pointer races
From: Andrew Farmer (andfarmteknovis.com)
Date: Wed Aug 04 2004 - 17:42:13 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 <ihaquerisec.pl>
> 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFBEWZFPa6RRaKl0ScRAsFMAJ0YAP4Km01AQvEnHFjnB3DhW4vk1gCdHUUJ
fhc4YknA93Wx9k+VW8IAdNU=
=iyc6
-----END PGP SIGNATURE-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: FW: [Full-Disclosure] Question for DNS pros
From: Nils Ketelsen (nilsdruecke.strg-alt-entf.org)
Date: Wed Aug 04 2004 - 15:58:05 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
RE: [Full-Disclosure] Tipping Point IPS systems
From: Jeremiah Cornelius (jeremiahnur.net)
Date: Wed Aug 04 2004 - 17:30:42 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Los Alamos. Their problem seems to be with "removable media".
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.
_____
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com] On Behalf Of Keifer, Trey
Sent: Wednesday, August 04, 2004 1:25 PM
To: full-disclosurelists.netsys.com
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/> http://www.fishnetsecurity.com
_____
From: Ryan Sumida [mailto:rsumidacsulb.edu]
Sent: Tuesday, August 03, 2004 3:46 PM
To: full-disclosurelists.netsys.com
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 entities
other 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.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- application/x-pkcs7-signature attachment: smime.p7s
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] [SECURITY] [DSA 536-1] New libpng, libpng3 packages fix multiple vulnerabilities
debian-security-announcelists.debian.org
Date: Wed Aug 04 2004 - 21:10:24 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- --------------------------------------------------------------------------
Debian Security Advisory DSA 536-1 securitydebian.org
http://www.debian.org/security/ Matt Zimmerman
August 4th, 2004 http://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: 271760 3602ac433e9acb291264ac4631466b1b
http://security.debian.org/pool/updates/main/libp/libpng3/libpng-dev_1.2.1-1.1.woody.7_ia64.deb
Size/MD5 checksum: 278832 f40345e28c0a8090e3d5cc0da0c47c83
http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1-1.1.woody.7_ia64.deb
Size/MD5 checksum: 151492 b4cf01f0f5a4584a9cc91d37059e3a18
HP Precision architecture:
http://security.debian.org/pool/updates/main/libp/libpng/libpng2_1.0.12-3.woody.7_hppa.deb
Size/MD5 checksum: 128592 c290efcf7bca64a59b95df9bd40ea7c4
http://security.debian.org/pool/updates/main/libp/libpng/libpng2-dev_1.0.12-3.woody.7_hppa.deb
Size/MD5 checksum: 262498 bba030d36b2453f50fc5f8dd502193db
http://security.debian.org/pool/updates/main/libp/libpng3/libpng-dev_1.2.1-1.1.woody.7_hppa.deb
Size/MD5 checksum: 269714 97f2cc65b004d72d2f736c444a5eca02
http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1-1.1.woody.7_hppa.deb
Size/MD5 checksum: 132710 ad103af06ba1fd04bfc820a7c9469a04
Motorola 680x0 architecture:
http://security.debian.org/pool/updates/main/libp/libpng/libpng2_1.0.12-3.woody.7_m68k.deb
Size/MD5 checksum: 103914 0397515db7b83fe0788c11878ff2f6fe
http://security.debian.org/pool/updates/main/libp/libpng/libpng2-dev_1.0.12-3.woody.7_m68k.deb
Size/MD5 checksum: 220716 eedf1c5c86848604fffc678e2522047e
http://security.debian.org/pool/updates/main/libp/libpng3/libpng-dev_1.2.1-1.1.woody.7_m68k.deb
Size/MD5 checksum: 226396 825cf323e0b2a20d7059b41ac50b5ffe
http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1-1.1.woody.7_m68k.deb
Size/MD5 checksum: 106862 c9426ed19e5cf9d5ffa3f4e5ad9575ba
Big endian MIPS architecture:
http://security.debian.org/pool/updates/main/libp/libpng/libpng2_1.0.12-3.woody.7_mips.deb
Size/MD5 checksum: 108912 f28b7b28829c5eccfc1879bf24f30d01
http://security.debian.org/pool/updates/main/libp/libpng/libpng2-dev_1.0.12-3.woody.7_mips.deb
Size/MD5 checksum: 240572 aa9f0be614c9b9e83035927bca2780a0
http://security.debian.org/pool/updates/main/libp/libpng3/libpng-dev_1.2.1-1.1.woody.7_mips.deb
Size/MD5 checksum: 247046 950eb986e2da18540cac6871fa724ec8
http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1-1.1.woody.7_mips.deb
Size/MD5 checksum: 112238 45ba391f6604228a5712b3933cd7918d
Little endian MIPS architecture:
http://security.debian.org/pool/updates/main/libp/libpng/libpng2_1.0.12-3.woody.7_mipsel.deb
Size/MD5 checksum: 108792 e1c23a58af661142d961b2cb9067a8ad
http://security.debian.org/pool/updates/main/libp/libpng/libpng2-dev_1.0.12-3.woody.7_mipsel.deb
Size/MD5 checksum: 240484 205b79c80e9d5a90ba39ce297ca7ccf9
http://security.debian.org/pool/updates/main/libp/libpng3/libpng-dev_1.2.1-1.1.woody.7_mipsel.deb
Size/MD5 checksum: 247000 d7fab207f6240fa1c8cca2b626543910
http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1-1.1.woody.7_mipsel.deb
Size/MD5 checksum: 112174 60c7d64b2256f05f8eb132b8e386731e
PowerPC architecture:
http://security.debian.org/pool/updates/main/libp/libpng/libpng2_1.0.12-3.woody.7_powerpc.deb
Size/MD5 checksum: 110254 ed1c9f3cb6cfc64467ae83251beb8b2d
http://security.debian.org/pool/updates/main/libp/libpng/libpng2-dev_1.0.12-3.woody.7_powerpc.deb
Size/MD5 checksum: 234680 a728d61a234b60b14d6876c0d7d460b5
http://security.debian.org/pool/updates/main/libp/libpng3/libpng-dev_1.2.1-1.1.woody.7_powerpc.deb
Size/MD5 checksum: 240742 ae4b57d50f8f6e8f88f18fdfde81c9a8
http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1-1.1.woody.7_powerpc.deb
Size/MD5 checksum: 113340 3014018db3169c617d958b71fa0e119d
IBM S/390 architecture:
http://security.debian.org/pool/updates/main/libp/libpng/libpng2_1.0.12-3.woody.7_s390.deb
Size/MD5 checksum: 110286 1ba753d363eb45b3b768ae26ce19f9dc
http://security.debian.org/pool/updates/main/libp/libpng/libpng2-dev_1.0.12-3.woody.7_s390.deb
Size/MD5 checksum: 229436 8ca7796466613d780a3442d831544bf9
http://security.debian.org/pool/updates/main/libp/libpng3/libpng-dev_1.2.1-1.1.woody.7_s390.deb
Size/MD5 checksum: 235056 dcfc35ced743c453935dea5f4c6e8b92
http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1-1.1.woody.7_s390.deb
Size/MD5 checksum: 113376 2a42876c22f968ae435382110d27741c
Sun Sparc architecture:
http://security.debian.org/pool/updates/main/libp/libpng/libpng2_1.0.12-3.woody.7_sparc.deb
Size/MD5 checksum: 110312 f5db28252e4072d07f34da1b57bb2656
http://security.debian.org/pool/updates/main/libp/libpng/libpng2-dev_1.0.12-3.woody.7_sparc.deb
Size/MD5 checksum: 232132 32be4f2a4f7215f3760ac6ce7c222ab9
http://security.debian.org/pool/updates/main/libp/libpng3/libpng-dev_1.2.1-1.1.woody.7_sparc.deb
Size/MD5 checksum: 237786 2d36e99aab38db959088a646bbf9455b
http://security.debian.org/pool/updates/main/libp/libpng3/libpng3_1.2.1-1.1.woody.7_sparc.deb
Size/MD5 checksum: 113744 d67df8af224bbcb817c7cb004ece5bf7
These files will probably be moved into the stable distribution on
its next revision.
- ---------------------------------------------------------------------------------
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main
Mailing list: debian-security-announcelists.debian.org
Package info: `apt-cache show <pkg>' and http://packages.debian.org/<pkg>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFBEZb5ArxCt0PiXR4RAmUfAJ4sqTIviuQbDq3Z/OihWgW3R+X9IACdHPeV
ZYzTM1+5xJbhNlRCOnSvfrQ=
=q7t4
-----END PGP SIGNATURE-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] CNN: Los Alamos suspends 19 for security leak (Was: Tipping Point IPS systems
From: Andrew J Caines (A.J.Caineshalplant.com)
Date: Wed Aug 04 2004 - 20:56:24 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeremiah Cornelius <jeremiahnur.net> 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 A.J.Caineshalplant.com |
| "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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Linux kernel file offset pointer races
From: Pavel Kankovsky (peakargo.troja.mff.cuni.cz)
Date: Thu Aug 05 2004 - 02:07:38 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, 4 Aug 2004, Andrew Farmer wrote:
> 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.
The kernel code shown is from arch/i386/kernel/mtrr.c in 2.4. 2.6 is
different but the race between read()/write() and llseek() (or even
other read()/write() on the same fd (*)) is still possible. I don't know
whether it is exploitable on 2.6 but afaik it violates POSIX (see my post
to LKML: http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.0/0925.html)
ergo it should be fixed.
(*) write()-write() race on the same inode using generic_file_write() is
not possible because they are serialized by inode->i_sem.
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] Small (but useful) utility
From: M. Mohr (m.mohrlaposte.net)
Date: Thu Aug 05 2004 - 03:07:53 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
When I couldn't find a decent file wiping utility on my own
machine, I decided to write one. Yes, I did search the net
and came up with a few... but they seem to be poorly written
and overly complicated. So, in just 64 lines, I wrote one
that would be useful for me, that would work well, and that is
simple enough to understand.
What has this to do with full-disclosure, you might ask?
Everything! Call me paranoid, but if/when the feds come
a-knocking, I want to be able to execute a single command that
will securely delete non-encrypted data on my hard disk. i.e.
all the 0-day exploits, the leaked Microsoft and Half-Life
source code, and the porn from Hitler's bunker.
You might want to name this program something inconspicuous
(like 'index') and place it in /sbin, then add something like
the following to rc.local:
sleep 300 && screen -d -m find /home/foo -type f | xargs
/sbin/index
Just make sure to resume the screen as root within 5 minutes
of system boot time :)
Depending on your paranoia, you may want to change the PASSES
define, which controls how many times the file is overwritten.
Keep in mind that my program will overwrite your file 3 times
for each increment of PASSES (once with zeroes, once with
ones, and once with random data). For example, the default
setting (2) will overwrite your file 6 times.
With that in mind, a setting of 2 - 3 should be plenty. I
tested this program with a 500 mb file, which took 52 seconds
to complete on my system (using the source code attached).
The same file with PASSES defined as 15 took at least 4 and a
half minutes (well... I killed it just after 4:45 because it
was taking too long :P).
On to licensing: I release this code under the GPL. A credit
to me (the original author) would be appreciated (but is not
required) in any derivative work.
You can send any questions or comments to me. The source
should compile cleanly on Linux and likely other Unices,
however it will almost certainly not work on Windows without
modifications.
Accédez au courrier électronique de La Poste : www.laposte.net ;
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- application/x-tar attachment: wipe.c.gz
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap
From: Nick FitzGerald (nickvirus-l.demon.co.uk)
Date: Thu Aug 05 2004 - 04:09:02 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Exibar wrote:
> Of course there are Feds at DefCon.... how else would we be able to play
> Spot the Fed without the Feds? :-)
Well, given the horrific false-positive rate at previous events, I
doubt Defcon would need any actual feds to have a "successful" game of
"Spot the Feds"...
Regards,
Nick FitzGerald
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] Opera: Location, Location, Location
From: GreyMagic Software (securitygreymagic.com)
Date: Thu Aug 05 2004 - 06:16:52 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
GreyMagic Security Advisory GM#008-OP
=====================================
By GreyMagic Software, 05 Aug 2004.
Available in HTML format at
http://www.greymagic.com/security/advisories/gm008-op/.
Topic: Location, Location, Location.
Discovery date: 19 Jul 2004.
Affected applications:
======================
Opera 7.53 and prior on Windows, Linux and Mac.
Introduction:
=============
On 04-Feb-2003 GreyMagic released an advisory [1] concerning Opera's
security model in v7.0. The advisory depicted several flaws in Opera's
model, one of them allowed for an attacker to overwrite native and custom
functions in a victim window. When the victim web-page executed such
function, the attacker's code executed with the victim's privileges.
Opera tried to prevent such scenarios in Opera 7.01, by blocking
write-access to objects on the victim window.
[1] http://www.greymagic.com/security/advisories/gm002-op/
Discussion:
===========
Unfortunately, Opera failed to block write-access to the often-used
"location" object.
By overwriting methods in this object, an attacker can gain immediate script
access to any web-page that uses one of these methods. This includes both
web-pages in foreign domains and the victim's local file system.
The impacts of this vulnerability include:
* Read-access to files on the victim's file system
* Read-access to lists of files and folders on the victim's file system
* Read-access to emails written or received by M2, Opera's mail program
* Cookie theft
* URL spoofing (phishing)
* Track user browsing history
* Much more...
Several methods are candidates for such attacks: assign(), replace(),
valueOf() and toString(). The first two would be triggered only when the
victim explicitly calls them. The latter ones would be called in many
implicit cases, including:
* str+=location;
* decodeURI(location);
* location*7;
* location+"";
And many others...
In order to gain access to the "file://" protocol, and hence to the entire
file-system, an attacker needs to know of an HTML file in the victim's file
system that actually makes a call to a method in the location object. Such
file was included in virtually all Windows Operating Systems, it is named
"CiAdmin.htm" and it can be found in a very predictable path -
%SystemRoot%/Help/.
Exploit:
========
To exploit this vulnerability an attacker can use a simple <iframe>,
pointing to the victim web-page, and inject the malicious code into its
window. Here's an oversimplified example:
<iframe></iframe>
<script type="text/javascript">
onload=function () {
var oVictim=frames[0];
oVictim.location.href="file://localhost/c:/winnt/help/ciadmin.htm";
oVictim.location.replace=function () {
oVictim.alert("We now have full file system access using
"+location.href);
}
}
</script>
This code demonstrates how the vulnerability works, but it is not likely to
succeed in exploiting it by itself. This happens because the malicious code
must be injected in the time-gap between page initiation and page script
execution. This leaves a very narrow window for an attacker to inject code,
but with a bit of scripting this window of opportunity can easily be found.
The demonstrations below use simple brute-force and retry mechanisms to
inject our code successfully.
Demonstration:
==============
GreyMagic prepared two proof-of-concept demonstrations of this
vulnerability, they are available at
http://www.greymagic.com/security/advisories/gm008-op/.
Solution:
=========
GreyMagic informed Opera of the vulnerability on 22-Jul-2004. A new version
(7.54) was officially released on 05-Aug-2004 to address this flaw.
Tested on:
==========
Opera 7.52.
Opera 7.53.
Disclaimer:
===========
The information in this advisory and any of its demonstrations is provided
"as is" without warranty of any kind.
GreyMagic Software is not liable for any direct or indirect damages caused
as a result of using the information or demonstrations provided in any part
of this advisory.
- Copyright © 2004 GreyMagic Software.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Small (but useful) utility
From: Dave Horsfall (davehorsfall.org)
Date: Thu Aug 05 2004 - 05:44:36 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, 5 Aug 2004, M. Mohr wrote:
> When I couldn't find a decent file wiping utility on my own
> machine, I decided to write one. Yes, I did search the net
> and came up with a few... but they seem to be poorly written
> and overly complicated. So, in just 64 lines, I wrote one
> that would be useful for me, that would work well, and that is
> simple enough to understand.
You have failed to take the effects of caching (memory and disk) into
account. This is probably why the others are "overly complicated."
-- Dave
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] [ GLSA 200408-04 ] PuTTY: Pre-authentication arbitrary code execution
From: Sune Kloppenborg Jeppesen (jaervoszgentoo.org)
Date: Thu Aug 05 2004 - 07:09:13 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200408-04
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: Normal
Title: PuTTY: Pre-authentication arbitrary code execution
Date: August 05, 2004
Bugs: #59383
ID: 200408-04
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Synopsis
========
PuTTY contains a vulnerability allowing a SSH server to execute
arbitrary code on the connecting client.
Background
==========
PuTTY is a free implementation of Telnet and SSH for Win32 and Unix
platforms, along with an xterm terminal emulator.
Affected packages
=================
-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 net-misc/putty <= 0.54 >= 0.55
Description
===========
PuTTY contains a vulnerability allowing a malicious server to execute
arbitrary code on the connecting client before host key verification.
Impact
======
When connecting to a server using the SSH2 protocol an attacker is able
to execute arbitrary code with the permissions of the user running
PuTTY by sending specially crafted packets to the client during the
authentication process but before host key verification.
Workaround
==========
There is no known workaround at this time. All users are encouraged to
upgrade to the latest available version of PuTTY.
Resolution
==========
All PuTTY users should upgrade to the latest version:
# emerge sync
# emerge -pv ">=net-misc/putty-0.55"
# emerge ">=net-misc/putty-0.55"
References
==========
[ 1 ] PuTTY ChangeLog
http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.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-04.xml
Concerns?
=========
Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.
License
=======
Copyright 2004 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).
The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.
http://creativecommons.org/licenses/by-sa/1.0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBEiNpzKC5hMHO6rkRAqqfAKCAlxPnzBfJ396cnyBBeWsMi+sQKwCfRlP2
MVDuAX5vjBz5sMu1sCBvI6A=
=sog4
-----END PGP SIGNATURE-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Clear text password exposure in Datakey's tokens and smartcards
From: Kevin Sheldrake (kevelectriccat.co.uk)
Date: Thu Aug 05 2004 - 05:39:18 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Surely if the user is entering a passphrase then the same problem exists -
that of effectively eavesdropping that communication from the keyboard?
Ignoring the initial expense for a moment, wouldn't it have made a lot of
sense to include the keypad actually on the cards? Obviously, card
readers would need to be contructed such that the keypad part of the card
would be exposed during use. The keypad security could then rely on the
tamper resistant properties of the rest of the card.
From a costs perspective, I would guess that the actual per-card cost
increase would be minimal if hundreds of millions of these cards were
produced.
Kev
> 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
>
>
--
Kevin Sheldrake MEng MIEE CEng CISSP
Electric Cat (Bournemouth) Ltd
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] [ GLSA 200408-03 ] libpng: Numerous vulnerabilities
From: Sune Kloppenborg Jeppesen (jaervoszgentoo.org)
Date: Thu Aug 05 2004 - 06:57:56 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200408-03
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: Normal
Title: libpng: Numerous vulnerabilities
Date: August 05, 2004
Bugs: #59424
ID: 200408-03
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Synopsis
========
libpng contains numerous vulnerabilities potentially allowing an
attacker to perform a Denial of Service attack or even execute
arbitrary code.
Background
==========
libpng is a standard library used to process PNG (Portable Network
Graphics) images. It is used by several other programs, including web
browsers and potentially server processes.
Affected packages
=================
-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 media-libs/libpng <= 1.2.5-r7 >= 1.2.5-r8
Description
===========
libpng contains numerous vulnerabilities including null pointer
dereference errors and boundary errors in various functions.
Impact
======
An attacker could exploit these vulnerabilities to cause programs
linked against the library to crash or execute arbitrary code with the
permissions of the user running the vulnerable program, which could be
the root user.
Workaround
==========
There is no known workaround at this time. All users are encouraged to
upgrade to the latest available version.
Resolution
==========
All libpng users should upgrade to the latest stable version:
# emerge sync
# emerge -pv ">=media-libs/libpng-1.2.5-r8"
# emerge ">=media-libs/libpng-1.2.5-r8"
You should also run revdep-rebuild to rebuild any packages that depend
on older versions of libpng :
# revdep-rebuild
References
==========
[ 1 ] CAN-2004-0597
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0597
[ 2 ] CAN-2004-0598
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0598
[ 3 ] CAN-2004-0599
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0599
Availability
============
This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:
http://security.gentoo.org/glsa/glsa-200408-03.xml
Concerns?
=========
Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.
License
=======
Copyright 2004 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).
The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.
http://creativecommons.org/licenses/by-sa/1.0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBEiDEzKC5hMHO6rkRArWQAJ9tGcHpudcqkfWyvi041+B9ticNDwCff+6c
gV6Jd15qu3lxxWneLJn1Ev4=
=WtCw
-----END PGP SIGNATURE-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] Re: Tipping Point IPS systems
From: Richard Johnson (rdumpriver.com)
Date: Thu Aug 05 2004 - 07:55:35 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
In article
<8CFE45BE48312B48940923D31F91BF1F0A2C0ADDoh18ex06.reyrey.com>,
"Forbes, Robert" <Robert_Forbesreyrey.com> wrote:
> 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.
Tipping Point UnityOne Intrusion Prevention Systems (augh, -hate- that
IPS jargon, it's a transparent firewall with packet inspection :-) can
keep up with real-world traffic levels at large academic sites. As we
all move to 10gig networking, though...
Netscreen (now Juniper) IDP systems can keep up with most present
levels too, very likely at a lower price. Of course, they're not going
to do 10gig filtering yet, either.
In my view, the higher Tipping Point price mainly buys you a much more
mature and focused signature/detect development process than you get
(yet?) with the somewhat newer Netscreen and other competitive
offerings. That may well be worth it to you if your staffing is like
ours.
Richard
--
My mailbox. My property. My personal space. My rules. Deal with it.
http://www.river.com/users/share/cluetrain/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Clear text password exposure in Datakey's tokens and smartcards
From: Lee Dilkie (lee_dilkiemitel.com)
Date: Thu Aug 05 2004 - 08:03:03 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Toomas Soome wrote:
> 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
Perhaps I'm missing something here. As far as I can tell, no keys
located on the card were compromised, only the PIN was. Since this is a
two factor authentication system, possession of the PIN is of little
value without possession of the token itself.
Am I missing the point here?
regards,
-lee
--
__|__
------(_)------
"You can't be a real country unless you have a BEER and an airline. It
helps if you have some kind of a football team, or some nuclear weapons,
but at the very least you need a BEER."
--Frank Zappa
__|__
------(_)------
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
RE: [Full-Disclosure] Defcon spelled half backwards is Fedcon and you dumfucks walked into a trap
From: Todd Towles (toddtowlesbrookshires.com)
Date: Thu Aug 05 2004 - 08:44:52 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Well, it doesn't better if they are Feds, they look like one. That is what
counts..lol
-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com] On Behalf Of Nick FitzGerald
Sent: Thursday, August 05, 2004 4:09 AM
To: full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] Defcon spelled half backwards is Fedcon and
you dumfucks walked into a trap
Exibar wrote:
> Of course there are Feds at DefCon.... how else would we be able to play
> Spot the Fed without the Feds? :-)
Well, given the horrific false-positive rate at previous events, I
doubt Defcon would need any actual feds to have a "successful" game of
"Spot the Feds"...
Regards,
Nick FitzGerald
_______________________________________________
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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] PDAs under attack: Brador is the first WinCE backdoor
From: Feher Tamas (etomcatfreemail.hu)
Date: Thu Aug 05 2004 - 09:16:08 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
http://www.kaspersky.com/news?id=151142122
PDAs under attack
Kaspersky Labs has detected Backdoor.WinCE.Brador.a, the first
backdoor for PDAs running under PocketPC (based on Windows CE).
Brador is a classic Trojan backdoor program: it opens the infected
machine for remote administration. Brador is 5632 bytes in size and it
infects handhelds running Pocket PC.
After the backdoor is launched, it creates an svchost.exe file in the
Windows autorun folder, thus maintaining full control over the system
every time the handheld is turned on.
Brador then identifies the machine's IP address and sends it to the
author, informing him that the handheld is in the Internet and the
backdoor is active. Finally, Brador opens port 44299 and awaits further
commands.
Brador is created to allow the master full control over the infected PDA
via the port that the Trojan opens. Brador is programmed to upload
and download files and execute a series of further commands. Like all
backdoors, Brador cannot spread by itself: it can only arrive as an email
attachment, be downloaded from the Internet or uploaded along with
other data from a desktop.
"We were certain that a viable malicious program for PDAs would
appear soon after the first proof of concept viruses emerged for mobile
phones and Windows Mobile", commented Eugene Kaspersky, Head of
Anti-Virus Research at Kaspersky Labs, "WinCE.Brador.a is a full-scale
malicious program ready to go: unlike proof of concept malware, Brador
has a complete set of destructive functions typical for backdoors."
According to information received by the Kaspersky Virus Lab, Brador
was probably written by a Russian virus coder. The Trojan was
attached to an email with a Russian sender address and Russian text
inside.
Interestingly enough, the author is offering to sell the client part for the
Trojan to all interested parties, which means that there is a real chance
that the backdoor may be bought by somebody who will use it
commercially (bot network creation, for instance). Virus writers are
turning professional with a vengeance.
"PDA users face a real danger and we can be sure that the computer
underground will snatch at the chance to attack PDAs and mobile
phones in the nearest future," added Eugene Kaspersky, "malware
development for mobiles is passing through the same stages as
malware for desktops: we will probably see a serious outbreak of
viruses for handhelds sometime soon."
Kaspersky Labs has already updated the antivirus databases with
protection against Brador. A detailed description of Brador is available
in the Kaspersky Virus Encyclopedia. See:
http://www.viruslist.com/eng/viruslist.html?id=1984055
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] Re:
From: Schonef (schonefuni-muenster.de)
Date: Thu Aug 05 2004 - 15:59:38 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]