SUSE Security Announcement: tcpdump (SuSE-SA:2004:002)
-----BEGIN PGP SIGNED MESSAGE-----
______________________________________________________________________________
SUSE Security Announcement
Package: tcpdump
Announcement-ID: SuSE-SA:2004:002
Date: Wed Jan 14 14:00:00 MET 2004
Affected products: 8.0, 8.1, 8.2, 9.0
SuSE eMail Server III
SuSE Firewall Adminhost VPN
SuSE Linux Admin-CD for Firewall
SuSE Firewall on CD 2 - VPN
SuSE Firewall on CD 2
SuSE Linux Enterprise Server 7
SLES 8 for IBM iSeries and IBM pSeries
SuSE Linux Enterprise Server 8
SuSE Linux Desktop 1.0
SuSE Linux School Server for i386
SuSE Linux Standard Server 8
SuSE Linux Office Server
UnitedLinux 1.0
Vulnerability Type: remote DoS
Severity (1-10): 3
SUSE default package: yes
Cross References: http://www.tcpdump.org
CAN-2003-0989
Content of this advisory:
1) security vulnerability resolved: remote DoS condition in tcpdumps
ISAKMP handling
problem description, discussion, solution and upgrade information
2) pending vulnerabilities, solutions, workarounds:
- opera
- mc
- mod_gzip
- tripwire
- cvs
- gnome-filesystem
- XDM (XFree86, xf86)
- inn
- mpg321
- popper
- kdepim3
- pin
- 3ddiag
- mod_auth_shadow
3) standard appendix (further information)
______________________________________________________________________________
1) problem description, brief discussion, solution, upgrade information
Tcpdump is a well known tool for administrators to analyze network
traffic.
There is a bug in the tcpdump code responsible for handling ISAKMP
messages. This bug allows remote attackers to destroy a current
tcpdump session by tricking the tcpdump program with evil ISAKMP
messages to enter an endless loop.
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.
i386 Intel Platform:
SuSE-9.0:
ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/tcpdump-3.7.2-72.i586.rpm
a4395d7d819ea8918778f9a3b91c297c
patch rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/tcpdump-3.7.2-72.i586.patch.rpm
4eae84a6074af7c2386f9145a49f9477
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/tcpdump-3.7.2-72.src.rpm
b32b0e08e9add34b3c42599734723454
SuSE-8.2:
ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/tcpdump-3.7.1-341.i586.rpm
39c8e448e4056111444658ce93281ca3
patch rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/tcpdump-3.7.1-341.i586.patch.rpm
dfcb12acdad084fcf15508361a3018b5
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/tcpdump-3.7.1-341.src.rpm
b92c579649acc9fb19810bcc7a670d6d
SuSE-8.1:
ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/tcpdump-3.7.1-341.i586.rpm
5527a4823b041894324ae65b02e40011
patch rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/tcpdump-3.7.1-341.i586.patch.rpm
f4c933fd520dbcab98092e5a2fe8846c
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/tcpdump-3.7.1-341.src.rpm
0b118d8fe78cea0cc2405a934a77b7fd
SuSE-8.0:
ftp://ftp.suse.com/pub/suse/i386/update/8.0/n1/tcpdump-3.6.2-330.i386.rpm
d77a4e84796cc96be12c97ea19d272bb
patch rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.0/n1/tcpdump-3.6.2-330.i386.patch.rpm
74882ed085cc27c938ed5529df8040c4
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/tcpdump-3.6.2-330.src.rpm
51f39911dadd7add63e07a922840314c
Opteron x86_64 Platform:
SuSE-9.0:
ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/tcpdump-3.7.2-68.x86_64.rpm
0278d04abfe2bcffca8f45e711beebd0
patch rpm(s):
ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/tcpdump-3.7.2-68.x86_64.patch.rpm
348b217551a35a6e4f9698e92f3170c8
source rpm(s):
ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/tcpdump-3.7.2-68.src.rpm
2deb0ae848d115e00593a5639ec5b6b8
______________________________________________________________________________
2) Pending vulnerabilities in SUSE Distributions and Workarounds:
- Opera web browser
The SuSE Security Team has discovered a flaw in the Opera web browsers
X.509 certificate handling during the SSL handshake. It allows attackers
to prompt the Opera web browser with invalid certificates containing
the public key of the attacker. Thus, he can read or modify the
HTTPS traffic without notification by the user.
New packages fixing this problem will be available soon on our ftp
servers.
- mc
By using a special combination of links in archive-files it is possible
to execute arbitrary commands while mc tries to open it in its VFS.
The packages will be released soon.
- mod_gzip (apache-contrib)
The apache module mod_gzip is vulnerable to remote code execution
while running in debug-mode. We do not ship this module in debug-mode
but future versions will include the fix.
Additionally the mod_gzip code was audited to fix more possible security
related bugs.
After more testing a new apache-contrib RPM package will be released.
- tripwire
Tripwire is a file integrity checker. The tripwire version on SuSE Linux
8.2 and 9.0 do crash when a requested file does not exists.
New packages will be available soon.
- cvs
The cvs server-side can be tricked to create files in the root filesystem
of the server by requesting malformed modules. The permissions on the
root filesystem normally prevent this malfunction. Additionally the
package will include a fix for a format-string bug.
New packages will be available soon.
- gnome-filesystem
A script included in the gnome-filesystem package handles temporary
files insecurely. This script is called by YaST2 with root
privileges. The bug can be exploited locally to create or overwrite
arbitrary files in the filesystem. The bug is fixed in our current
source-tree since November 2003 but nevertheless update packages
for older SuSE Linux versions will be released soon.
- XDM (XFree86, xf86)
A missing check for failure conditions in the PAM code of XDM
can lead to local root access in conjunction with Kerberos
and alike. New packages will be released soon.
- inn
A buffer overflow in the code for handling control messages
can be exploited remotely.
New packages are available on our FTP servers.
- mpg321
A format-bug in mpg321 can be exploited (even remotely by HTTP streaming)
to execute code with the permissions of the user running mpg321 on
special MP3 files.
New packages are available on our FTP servers.
- popper
Popper handles temporary files in an insecure manner.
New packages are available on our FTP servers.
- kdepim3
It was possible to use a buffer overflow via a special crafted vcard file
to run code during generating previews. By default it was only possible
on local filesystems, but the user can enable this also for remote file
systems.
New packages are available on our FTP servers.
- pin
Pin handles local temporary files in an insecure manner which may lead
to local privilege escalation.
Thanks to Stefan Nordhausen <nordhaus at informatik.hu-berlin.de>
for reporting one of the issues.
New packages are available on our FTP servers.
- 3ddiag
Some 3ddiag scripts handle temporary files in an insecure manner.
Thanks to Stefan Nordhausen <nordhaus at informatik.hu-berlin.de>
for reporting some of the issues.
New packages will be available on our FTP servers soon.
- mod_auth_shadow (apache-contrib)
This apache module ignores account expiration dates.
The update will be released together with mod_gzip.
______________________________________________________________________________
3) 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
I've been struggling with this for hours on end! All I want to do is run an IMAP server to allow my Windows clients to access their unix email with Outlook Express. I tried the imap package but that has been modified now so that no POP3 or IMAP login is allowed with a plaintext password unless using SSL encrypted sessions. I do not want to get into the complexity of installing SSL, all boxes are behind a completely secure firewall and use CVS pserver, etc. anyway so the "security" gained by encrypting either session or passwords is completely illusory. The imapd daemon wouldn't accept encrypted passwords even when I switched the option on in my test Outlook Express mail client so I can't win either way. I tried to recompile imapd from source since the change to not allow plaintext passwords except in a TLS session is actually compiled into the server (very bad form, should be a config file option, probably with this setting as default). The source package is broken and won't compile. I tried installing the fiendishly complex cyrus-imapd but that doesn't work either, complaining about a "cannot connect to saslauthd server". Tried changing the sasl_pwcheck_method to "pwcheck" to see if that helped. Daemon won't start now complaining of db errors. I've set up qpopper to act as a pop3 client so I can now at least pick up my mail inbox from /var/spool/mail/<username> but that means I can't access other folders so (i) if users read mail on UNIX clients the mail goes into mbox and is inaccessible from Windows henceforth and more importantly (ii) users cannot use .procmailrc to sort mail into files like "spam", "suse-security-mailing-list", "cvs-logs" as these are now only accessible via unix and not Windows where people do most of their daily work. Really it's such a simple thing I want to do! Can anyone help? Thanks, Carl
On Wednesday 14 January 2004 16:15, Carl Peto wrote:
I've been struggling with this for hours on end!
All I want to do is run an IMAP server to allow my Windows clients to access their unix email with Outlook Express. I tried the imap package but that has been modified now so that no POP3 or IMAP login is allowed with a plaintext password unless using SSL encrypted sessions.
I have had the exact same problem. I DO use SSL, but the change in the imap server package breaks squirrelmail. I also am not amused by SuSE's decision to change the behaviour and by not having a way to turn this off again. However, I made a workaround by force-installing the imap version of SuSE 8.1 over the changed one which is running on SuSE 8.2. So now everytime I forget to UNselect imapd in online update my system breaks again. Very nice. I too would want a better solution. And I fully concur with you on the subject of Cyrus-imapd. Cyrus seemingly serves one single purpose, to drive sysadmins utterly crazy. ;-| I gave up early when I saw the list of prerequisites...
I do not want to get into the complexity of installing SSL, all boxes are behind a completely secure firewall and use CVS pserver, etc. anyway so the "security" gained by encrypting either session or passwords is completely illusory.
The imapd daemon wouldn't accept encrypted passwords even when I switched the option on in my test Outlook Express mail client so I can't win either way.
Installing an SSL certificate so that imapd speaks SSL too is quite simple, if you need help I can look it up for you... it is not more than 5 minutes work, however teaching all the clients that they should trust a self-signed cert sure isn't, so this may not be a viable option for you anyway.
I tried to recompile imapd from source since the change to not allow plaintext passwords except in a TLS session is actually compiled into the server (very bad form, should be a config file option, probably with this setting as default). The source package is broken and won't compile.
I tried installing the fiendishly complex cyrus-imapd but that doesn't work either, complaining about a "cannot connect to saslauthd server". Tried changing the sasl_pwcheck_method to "pwcheck" to see if that helped. Daemon won't start now complaining of db errors.
I've set up qpopper to act as a pop3 client so I can now at least pick up my mail inbox from /var/spool/mail/<username> but that means I can't access other folders so (i) if users read mail on UNIX clients the mail goes into mbox and is inaccessible from Windows henceforth and more importantly (ii) users cannot use .procmailrc to sort mail into files like "spam", "suse-security-mailing-list", "cvs-logs" as these are now only accessible via unix and not Windows where people do most of their daily work.
Really it's such a simple thing I want to do!
Can anyone help?
I am certainly willing to contribute but for now I'm stuck with the same problem as you are... Maarten
Thanks, Carl
On Wednesday 14 January 2004 16:15, Carl Peto wrote:
I've been struggling with this for hours on end!
All I want to do is run an IMAP server to allow my Windows clients to access their unix email with Outlook Express. I tried the imap package but that has been modified now so that no POP3 or IMAP login is allowed with a plaintext password unless using SSL encrypted sessions.
I have had the exact same problem. I DO use SSL, but the change in the imap server package breaks squirrelmail. I also am not amused by SuSE's decision to change the behaviour and by not having a way to turn this off again. However, I made a workaround by force-installing the imap version of SuSE 8.1 over the changed one which is running on SuSE 8.2. So now everytime I forget to UNselect imapd in online update my system breaks again. Very nice.
I too would want a better solution. And I fully concur with you on the subject of Cyrus-imapd. Cyrus seemingly serves one single purpose, to drive sysadmins utterly crazy. ;-| I gave up early when I saw the list of
Thanks Maarten,
I thought I was going mad!
I agree that a core function like this shouldn't be changed in such an
unhelpful way.
IMHO this is supposed to be why we use SuSE rather than suffering the random
decisions of package maintainers and even of IETF bodies?
I am totally unfamiliar with SSL, I've resisted it just out of laziness - I
have enough to do with being a Windows dev. and part-time linux sysadmin
anyway!
All clients will be Outlook Express but I'm guessing that SSL is more of a
shared library thing on Windows, i.e. registry settings, etc. to allow
clients to access a server with SSL where certificate is self-certified.
So anyway it's worth a go; can you give me a quick idea of how I set up SSL
on my linux box, create a certificate and then get imapd to use it?
Alternatively a well-written, simple HOWTO would be fine!
Thanks,
Carl
----- Original Message -----
From: "Maarten v d Berg"
I do not want to get into the complexity of installing SSL, all boxes
behind a completely secure firewall and use CVS pserver, etc. anyway so
"security" gained by encrypting either session or passwords is completely illusory.
The imapd daemon wouldn't accept encrypted passwords even when I switched the option on in my test Outlook Express mail client so I can't win either way.
Installing an SSL certificate so that imapd speaks SSL too is quite simple, if you need help I can look it up for you... it is not more than 5 minutes work, however teaching all the clients that they should trust a self-signed cert sure isn't, so this may not be a viable option for you anyway.
I tried to recompile imapd from source since the change to not allow plaintext passwords except in a TLS session is actually compiled into
server (very bad form, should be a config file option, probably with
are the the this
setting as default). The source package is broken and won't compile.
I tried installing the fiendishly complex cyrus-imapd but that doesn't work either, complaining about a "cannot connect to saslauthd server". Tried changing the sasl_pwcheck_method to "pwcheck" to see if that helped. Daemon won't start now complaining of db errors.
I've set up qpopper to act as a pop3 client so I can now at least pick up my mail inbox from /var/spool/mail/<username> but that means I can't access other folders so (i) if users read mail on UNIX clients the mail goes into mbox and is inaccessible from Windows henceforth and more importantly (ii) users cannot use .procmailrc to sort mail into files like "spam", "suse-security-mailing-list", "cvs-logs" as these are now only accessible via unix and not Windows where people do most of their daily work.
Really it's such a simple thing I want to do!
Can anyone help?
I am certainly willing to contribute but for now I'm stuck with the same problem as you are...
Maarten
Thanks, Carl
On Wednesday 14 January 2004 17:13, Carl Peto wrote:
Thanks Maarten,
I thought I was going mad!
I agree that a core function like this shouldn't be changed in such an unhelpful way.
IMHO this is supposed to be why we use SuSE rather than suffering the random decisions of package maintainers and even of IETF bodies?
I am totally unfamiliar with SSL, I've resisted it just out of laziness - I have enough to do with being a Windows dev. and part-time linux sysadmin anyway!
All clients will be Outlook Express but I'm guessing that SSL is more of a shared library thing on Windows, i.e. registry settings, etc. to allow clients to access a server with SSL where certificate is self-certified.
So anyway it's worth a go; can you give me a quick idea of how I set up SSL on my linux box, create a certificate and then get imapd to use it?
See http://portal.suse.com/sdb/en/2003/05/imap_ssl.html ( credit where credit is due: Thanks SuSE ! ) ;-) They talk about suse 8.2 but I verified it to work on 8.1 at least. Only, the path to the SSL dir may be different depending on your suse version. For my 8.2 box with an imap from 8.1, I had to tweak and/or move around something. I'm not sure what I had to do but you should verify that the path imapd looks for is the same one your ssl stuff is in: 'strings /usr/sbin/imapd | grep -i ssl' should tell you where imap looks. Depending on the suse version you have, your SSL dir may be /etc/ssl, /usr/ssl or /usr/share/ssl. So, make symlinks if needed... Otherwise, it was real easy (although I opted for something else than a selfsigned key, the self-signing does work fine, I used that as a test). If you don't succeed however, send me a note. Maarten
I too would want a better solution. And I fully concur with you on the subject of Cyrus-imapd. Cyrus seemingly serves one single purpose, to drive sysadmins utterly crazy. ;-| I gave up early when I saw the list of prerequisites...
I, too, couldn't figure our Cyrus. Download and compile the imapd (non-Cyrus) source yourself: http://www.washington.edu/imap/
however teaching all the clients that they should trust a self-signed cert sure isn't, so this may not be a viable option for you anyway.
Sounds like an Outlook Express issue to me. Don't blame SuSE for Microsoft's shortcomings.
Am Mittwoch, 14. Januar 2004 17:29 schrieb BarkerJr:
however teaching all the clients that they should trust a self-signed cert sure isn't, so this may not be a viable option for you anyway.
Sounds like an Outlook Express issue to me. Don't blame SuSE for Microsoft's shortcomings.
To stop the endless complaining from Outlook about a "untrusted CA", create a cert-file for your certificate authority, and import it with the Internet Explorer. Further informations: http://www.onlamp.com/pub/a/onlamp/2003/02/20/linuxhacks.html Or use Mozilla Mail, it stops complaining after one click.. Regards, Henning
I too would want a better solution. And I fully concur with you on the subject of Cyrus-imapd. Cyrus seemingly serves one single purpose, to drive sysadmins utterly crazy. ;-| I gave up early when I saw the list of prerequisites...
I, too, couldn't figure our Cyrus. Download and compile the imapd (non-Cyrus) source yourself: http://www.washington.edu/imap/
however teaching all the clients that they should trust a self-signed cert sure isn't, so this may not be a viable option for you anyway.
Sounds like an Outlook Express issue to me. Don't blame SuSE for Microsoft's shortcomings.
absolutely disagree with you. Whilst I too love to bash M$, this is nothing to do with them. It is already a huge task to educate end-users about only trusting signed certs. To then re-educate them that certain self-signed certs are safe is asking too much. Maybe you could add yourself as a trusted root CA to all clients, thus avoiding the problem? Andy
however teaching all the clients that they should trust a self-signed cert sure isn't, so this may not be a viable option for you anyway.
Sounds like an Outlook Express issue to me. Don't blame SuSE for Microsoft's shortcomings.
absolutely disagree with you. Whilst I too love to bash M$, this is nothing to do with them. It is already a huge task to educate end-users about only trusting signed certs. To then re-educate them that certain self-signed certs are safe is asking too much.
Most clients will cache the cert so that they don't have to ask you every time. Henning stated that Mozilla does. Putty does. So, that makes it an MS issue, because they don't let you cache it.
On Wednesday 14 January 2004 17:29, BarkerJr wrote:
however teaching all the clients that they should trust a self-signed cert sure isn't, so this may not be a viable option for you anyway.
Sounds like an Outlook Express issue to me. Don't blame SuSE for Microsoft's shortcomings.
To be fair, that is not what I meant. Every good client should complain about a certificate without a chain of trust. What I meant was is that there are several ways to avoid or solve this, like importing a root CA cert or telling all the clients to trust certain certificates. And my point was that without knowing how many client machines we're talking about, it is not for us to say if such a change is simple (or even feasible). But now we're on the subject, I do believe a problem lies with microsofts' implementation since I am still having great trouble to convince M$ hosts to trust my root CA. It imports fine, installs fine and works fine. Then, after the next reboot everything is gone and we get the Nag-boxes back... :-(( On the other hand I never had any trouble telling mozilla or konqueror they must henceforth trust my root CA. But windows keeps forgetting it trusts me. (To be honest, it WOULD be bad judgement for a windows box to trust me... ;-)) Maarten
2) pending vulnerabilities, solutions, workarounds: - opera
fou4s-lge -e WARNING: different version structure: opera: 7.50-0 <=> 7.23-20031119.4 : 1 Using buildtime to check again for safety ... opera 7.50-0 (7.23-20031119.4) 4788kB hm. so what about 7.50 ? that is, do newer upstream versions have it fixed? Lars Ellenberg
participants (7)
-
Andy Doran - Job Management Systems Ltd. -
BarkerJr -
Carl Peto -
Henning Westerholt -
krahmer＠suse.de -
Lars Ellenberg -
Maarten v d Berg