Fwd: [RHSA-2003:093-01] Updated MySQL packages fix vulnerabilities

[Phillip Hofmeister]

Someone recently posted a concern relating to this RedHat Security
Advisory.

[EMAIL PROTECTED]:~$ ls -l /etc/mysql/
total 8
-rw---1 root root  146 Dec 17 09:19 debian.cnf
-rw-r--r--1 root root 1962 Jan  2 15:43 my.cnf
[EMAIL PROTECTED]:~$


Debian's better file management avoids this bug since the mysql user
cannot write to the mysqld configuration file.  I don't suspect there
will be a DSA for this bug because it is mitigated by Debian. 


Take Care,

-- 
Phillip Hofmeister
Network Administrator/Systems Engineer
IP3 Inc.
http://www.ip3security.com

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import
--
Excuse #154: SCSI's too wide. 



- Forwarded message from [EMAIL PROTECTED] -

From: [EMAIL PROTECTED]
Subject: [RHSA-2003:093-01] Updated MySQL packages fix vulnerabilities
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Date: Tue, 29 Apr 2003 14:59 -0400
X-Spam-Status: No, bogofilter
Delivery-date: Tue, 29 Apr 2003 15:29:05 -0400
X-Razor-Warning: NONE.

-
   Red Hat Security Advisory

Synopsis:  Updated MySQL packages fix vulnerabilities
Advisory ID:   RHSA-2003:093-01
Issue date:2003-04-29
Updated on:2003-04-29
Product:   Red Hat Linux
Keywords:  
Cross references:  
Obsoletes: RHSA-2002:288
CVE Names: CAN-2003-0073 CAN-2003-0150
-

1. Topic:

Updated MySQL server packages fix both a double-free security
vulnerability and a root exploit security vulnerability.

2. Relevant releases/architectures:

Red Hat Linux 7.1 - i386
Red Hat Linux 7.2 - i386, ia64
Red Hat Linux 7.3 - i386
Red Hat Linux 8.0 - i386

3. Problem description:

MySQL is a multi-user, multi-threaded SQL database server.

A double-free vulnerability in mysqld, for MySQL before version 3.23.55,
allows attackers with MySQL access to cause a denial of service (crash) by
creating a carefully crafted client application. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name
CAN-2003-0073 to this issue.

MySQL 3.23.55 and earlier creates world-writable files and allows mysql
users to gain root privileges by using the "SELECT * INFO OUTFILE" operator
to overwrite a configuration file and cause mysql to run as root upon
restart. The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CAN-2003-0150 to this issue.

All users are advised to upgrade to MySQL 3.23.56 contained within this
errata which is not vulnerable to these issues.

In addition to the security fixes, these erratum packages contain a
thread safe client library (libmysqlclient_r).

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

Please note that this update is available via Red Hat Network.  To use Red
Hat Network, launch the Red Hat Update Agent with the following command:

up2date

This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system.

5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info):

85898 - double-free vulnerability in mysqld < 3.23.55
85971 - possible root exploit in mysqld startup
77662 - mysql RPM's do not provide a thread safe library

6. RPMs required:

Red Hat Linux 7.1:

SRPMS:
ftp://updates.redhat.com/7.1/en/os/SRPMS/mysql-3.23.56-1.71.src.rpm

i386:
ftp://updates.redhat.com/7.1/en/os/i386/mysql-3.23.56-1.71.i386.rpm
ftp://updates.redhat.com/7.1/en/os/i386/mysql-server-3.23.56-1.71.i386.rpm
ftp://updates.redhat.com/7.1/en/os/i386/mysql-devel-3.23.56-1.71.i386.rpm

Red Hat Linux 7.2:

SRPMS:
ftp://updates.redhat.com/7.2/en/os/SRPMS/mysql-3.23.56-1.72.src.rpm

i386:
ftp://updates.redhat.com/7.2/en/os/i386/mysql-3.23.56-1.72.i386.rpm
ftp://updates.redhat.com/7.2/en/os/i386/mysql-server-3.23.56-1.72.i386.rpm
ftp://updates.redhat.com/7.2/en/os/i386/mysql-devel-3.23.56-1.72.i386.rpm

ia64:
ftp://updates.redhat.com/7.2/en/os/ia64/mysql-3.23.56-1.72.ia64.rpm
ftp://updates.redhat.com/7.2/en/os/ia64/mysql-server-3.23.56-1.72.ia64.rpm
ftp://updates.redhat.com/7.2/en/os/ia64/mysql-devel-3.23.56-1.72.ia64.rpm

Red Hat Linux 7.3:

SRPMS:
ftp://updates.redhat.com/7.3/en/os/SRPMS/mysql-3.23.56-1.73.src.rpm

i386:
ftp://updates.redhat.com/7.3/en/os/i386/mysql-3.23.56-1.73.i386.rpm
ftp://updates.redhat.com/7.3/en/os/i386/mysql-server-3.23.56-1.73.i386.rpm
ftp://updates.redhat.com/7.3/en/os/i386/mysql-devel-3.23.56-1.73.i386.rpm

Red Hat Linux 8.0:

SRPMS:
ftp://updates.redhat.com/8.0/en/os/SRPMS/mysql-3.23.56-1.80.src.rpm

i386:
ftp://updates.redhat.com/8.0/en/os/i386/mysql-3.23.56-1.80.i386.rpm
ftp://updates.redhat.com/8.0/en/os/i386/mysql-server-3.23.56-1.80.i386.rpm
ftp://updates.redhat.com/8.0/en/os/i386/mysql-devel-3.23.56-1.80.i386.rpm



7. Verification:

MD5 s

Re: mysql update for Woody?

[Carl Fink]

On Tue, Apr 29, 2003 at 04:29:54PM -0500, Drew Scott Daniels wrote:
> Are you referring to
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=173337 (more info in
> DSA 212) or something else?

Something else. 

> Where did you get the information that said mysql was vulnerable?

Several places, for one:

http://www.linuxsecurity.com/advisories/trustix_advisory-2990.html

If you look at mysql.com, their own release notes show several
vulnerabilities fixed since the last Debian update.
-- 
Carl Fink   [EMAIL PROTECTED]
Manager, Dueling Modems Computer Forum

Security with clusters

[Ricardo Sousa]

Hi.
Lately i am doing some works about Clusters (especially beowulf), and i
start to consider putting it (to really know how it works) in my
network.
All the stuff about DSM (Distributed Shared Memory), and making the OS
to distinguish the user from system processes among other things make me
though: and about security?
Because of lack of computers, i (*think*) will put my gateway and the
other machine act as client/server cluster (respectively).
What security risks can/will i pass?

Thanks in advantage,
Ricardo

PPTPD

[Sean McAvoy]

Hello,
I was wondering if there was any more info on status of a DSA for PPTPD
(poptop)?




-Sean

Re: mysql update for Woody?

[Drew Scott Daniels]

Are you referring to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=173337 (more info in
DSA 212) or something else?

Where did you get the information that said mysql was vulnerable?

http://www.securityfocus.com/cgi-bin/sfonline/vulns.pl and some security
scanners sometimes doesn't update their DB to say that special Debian
version numbers are not affected. In fact it seems 6374 hasn't been
updated. Can someone send an e-mail to [EMAIL PROTECTED] telling
them which BIDs DSA 212 fixes?

 Drew Daniels

Proposed guidelines and procedure for "Team to patch vulnerabilities"

[Drew Scott Daniels]

As promissed in
http://lists.debian.org/debian-security/2003/debian-security-200304/msg00373.html
I've written a rough plan...

Bugs get filed using appropriate procedure then... The "team to patch
vulnerabilities" finds the bugs and starts its procedure... I still need
to work on the procedure, and I'm thinking up a better name for the team.
Perhaps "Debian Vulnerability Patch Team" or alike... I imagine most
people on this team won't be Debian Developers or else they'd be on the
Debian Security Team so some effort in naming is needed not to overlap or
take away from their efforts...

It occures to me that many may be interested in joining this "team" just
for ego, resume fodder, 1337ness... To make sure this doesn't interfere
with anything I won't be putting together a roster. If I do give credit it
will based upon information available to me such as valuable contributions
to the BTS, the Security Team, maintainer(s) and/or mailing lists. I don't
keep any metrics on how much I've helped out and I regard this as time
consuming and perhaps a waste of time. I don't expect to do it for others,
but it'd be nice if someone did it for me. I also don't think it would
hurt for people to keep track of their own contributions, and how helpful
they were... if you want me to acknowledge it you'll have to give
references to what you've done. I may also dispute various metrics... I
don't want to see time wasted on flames though (hopefully not flames by
me, I don't intend to flame, and I don't like flame-bate).

-
Some guidelines:
New security bugs should follow proper procedure. Read
http://www.debian.org/security/faq and note that whenever a new security
bug is found send an e-mail to [EMAIL PROTECTED] If it's public
knowledge or an extremely low risk and/or low hazard vulnerability then
maybe file a bug in the BTS and set "Tags: security"... Some co-ordination
between vendors and upstream(s) may be nessisary before vulnerabilities
should be made public. Be careful not to file bugs that are not in Debian
packages [1].

The BTS should be proprly used. Read through the documentation at
http://www.debian.org/Bugs/ Please use the Tags as much as possible
(security, potato, woody, sarge, sid, patch...). Please check if stable
(now woody) oldstable (now potato), unstable (aka sid) and Testing (now
sarge) could be affected. Don't assume that it is or isn't based upon its
version number alone [2].

Give maintainers and the security team time to fix bugs. The security
team's timeline *might* be directed by their policy(?) [3] to issue a DSA,
fix or not, within one week. Maintainers *may* be given "a few days" to
respond before people should bother writing a patch, and after a patch is
submitted it is recomended to "wait a few more days" for a responce [4].
After the wait is up talk to a Developer about doing an NMU [5] or do one
if you are a Debian Developer.


[1] Debian "stable" sometimes has security patches backported from newer
version numbers. Also there may be differences in the Debian version (that
should only be in the Debian diff file) and upstream (which should be the
same as the orig source). Security scanner false positives should be filed
if and when they occure (Eg, nessusd).

[2] In additon to [1], sometimes vulnerabilities are only introduced in
later versions. Check the differences in the source code if you can (it'll
need to be done eventualy), and try to exploit yourself if an exploit is
possible/available.

[3] http://lists.debian.org/debian-devel/1999/debian-devel-199908/msg01933.html

[4] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu-when

[5] Acording to
http://lists.debian.org/debian-mentors/2003/debian-mentors-200304/msg00392.html
debian-mentors@lists.debian.org might be the best place to request an NMU,
but for example, an apache NMU request might go to debian-apache. Another
good example is requesting an NMU of a package like libdb in debian-perl
as a libdb RC bug affects perl. Note NMU's usualy don't get seen for at
least 7 days after uploaded. Is there a way for non-dd (non Debian
Developers) to check incomming/delayed?
-


Some Resources:
http://qa.debian.org/bts-security.html lists bugs in the BTS that are
tagged security.
http://packages.qa.debian.org
http://bugs.debian.org
The Debian archive (it's a bit confusing to me still). It has source for
all distributions that have the package (except maybe some non-free). Note
that potato didn't use the pool directory structure.
http://www.steve.org.uk/Debian/ is one example of a security audit that
this team might help support

3rd party security information sources:
http://www.securityfocus.org especialy under BIDs
http://packetstormsecurity.nl and it's many mirrors
CERT, other advisory places (like mitre or iss), vendors like Mandrake,
SUSE, RedHat...

For human help with patches:
Upstream (see the copyright and files in the source, other bugs, a search
engine...)
Maintainers
[EMAIL PROTECTED] (they're overworked so do

mysql update for Woody?

[Carl Fink]

I'm administering a server that runs mysql as the back end. When will
patches to cover the recently-discovered security problems be released?

Thanks.
-- 
Carl Fink  [EMAIL PROTECTED]
I-Con Internet Liason and Postmaster

Re: Secure remote syslogging?

[Sven . Riedel]

On Tue, Apr 29, 2003 at 10:54:51PM +1000, Sam Couter wrote:
> Stefan Neufeind <[EMAIL PROTECTED]> wrote:
> > what is the best way to remotely syslog? In
> 
> Use a dedicated machine. Cut the 'transmit' pair in the CAT5 cable.
> syslog is UDP, which is only one-way, so it doesn't need to transmit.
> 
> Obviously you'll have no remote access to the syslog server, but neither
> will an attacker.

That solution seems rather harsh. Another way (without syslog, granted)
would be setting up a dedicated machine to do stealth logging. Somewhat
less intense on the hardware penetration part ;)

Regs,
Sven



-- 
Sven Riedel  [EMAIL PROTECTED]
Osteroeder Str. 6 / App. 13  [EMAIL PROTECTED]
38678 Clausthal  "Python is merely Perl for those who
  prefer Pascal to C" (anon)

Re[2]: Port forwarding wrong after days

[Kay-Michael Voit]

-BEGIN PGP SIGNED MESSAGE-
Hash: MD5

>> I've search for something like this, but did not find anything. How do
>> I flush it?

RK> It would have been the NAT table anyway (my
RK> mistake). You flush it with iptables -F -t nat.
RK> The reboot done the job, so it must be something
RK> else. You should ask on debian-firewall.

Oh, yes, that did I do, too. I thought about other kinds of tables. If
I didn't,
iptables -L -t nat|grep 192.168.0.10 (which I wrote about)
should have given a result, shouldn't it?

- --
Public Key erhältlich auf den PGP-Keyservern, sowie mit weiteren Informationen 
auf http:\\www.voits.net.
Fingerprint: 9b482c5c41800ef0f6c8b01ae4df20ac

-BEGIN PGP SIGNATURE-
Version: 2.6

iQEVAwUAPq6Fcp9LInC1Fu5pAQHAcAf/RciN2qKBMaReiuckge+NFw1hlQqqJnKk
5xiZiI1kdabWCGSuROkBFTwJ3az3v9991L+/dE58Zanhp3pebQu/Kg15kQlMfbSl
gmypOR9D0OfwSCY66CUoxKQrk+Y+8+qCX0BBfAKLDOSBBRxNEFjBMfXcmw5ZLGHU
xw/y4cBnl4L045W4L7RK5hUHTxjLwvu2OBB/PnAHE0bivt5eXPZy566nujPaqjNP
fcHw0PtcJ5AmLGPMGmU1/5KPO+38eLsu5EvYJPKEYp3W/dNBdHPD1xyY+BEMIqHh
ML4CeaoAR+aKVnl2xjxNAfVRHNmIfIRoRkmzJwcNJmo7MU1ZuODl5A==
=LjUZ
-END PGP SIGNATURE-

Re: [despammed] Re: Secure remote syslogging?

[Ed McMan]

Tuesday, April 29, 2003, 8:54:51 AM, Sam Couter (Sam) wrote:

Sam> Stefan Neufeind <[EMAIL PROTECTED]> wrote:
>> what is the best way to remotely syslog? In

Sam> Use a dedicated machine. Cut the 'transmit' pair in the CAT5 cable.
Sam> syslog is UDP, which is only one-way, so it doesn't need to transmit.

Wouldn't the machine still need to transmit some things, namely arp?

--
| Eddie J Schwartz <[EMAIL PROTECTED]|m00.net]> |
|  AIM: Uncaring Eyes ICQ: 35576339 YHOO: edmcman2   |
|  "We Trills have an expression -- at forty, you|
|  think you know everything. At four hundred you|
|  realize you know nothing." - Dax, Startrek DS9|
--

Re: Secure remote syslogging?

[Sam Couter]

Stefan Neufeind <[EMAIL PROTECTED]> wrote:
> what is the best way to remotely syslog? In

Use a dedicated machine. Cut the 'transmit' pair in the CAT5 cable.
syslog is UDP, which is only one-way, so it doesn't need to transmit.

Obviously you'll have no remote access to the syslog server, but neither
will an attacker.

Or, print each syslog message as it's received. Your attacker will have
to work the printer hard enough to set it on fire to destroy your logs.

http://www.techimo.com/photo/showphoto.php?photo=3067

> I make it secure that there can't exist any log-entries somebody 
> "faked" into our remote-syslog-file?

You can't really authenticate a syslog entry, they carry no
authentication information. Try this:
logger -p kern.crit Kernel panic\!

You'll just have to work out somehow which messages are real and which
are fake.
-- 
Sam "Eddie" Couter  |  mailto:[EMAIL PROTECTED]
Debian Developer|  mailto:[EMAIL PROTECTED]
|  jabber:[EMAIL PROTECTED]
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C


pgpe0wKLIRUgf.pgp
Description: PGP signature

Re: Port forwarding wrong after days

[Rolf Kutz]

* Quoting Kay-Michael Voit ([EMAIL PROTECTED]):

> Then I stopped trying But now, without changing anything, it
> works. As anyone an explanation for this behavior?

Did you flush the conntracktable?

- rk

Port forwarding wrong after days

[Kay-Michael Voit]

-BEGIN PGP SIGNED MESSAGE-
Hash: MD5

Hi,
I'm running a small router and firewall at home.
eth0 -> LAN
eth1 -> access point -> WLAN
eth2 -> WAN
On a client im running a donkeyclient, so I had to forward port (it
works without, but then you get a so called "low id" with result in
worse download speed)
I used these rules (now, before the same with another ip):

#eDonkey
  $IPTABLES -t nat -A PREROUTING -p tcp --dport 4661 -i $EXTIF -j DNAT --to 
192.168.2.10:4661
  $IPTABLES -t nat -A PREROUTING -p tcp --dport 4662 -i $EXTIF -j DNAT --to 
192.168.2.10:4662
  $IPTABLES -t nat -A PREROUTING -p udp --dport 4665 -i $EXTIF -j DNAT --to 
192.168.2.10:4665
  $IPTABLES -t nat -A PREROUTING -p udp --dport 4672 -i $EXTIF -j DNAT --to 
192.168.2.10:4672
  $IPTABLES -A MYFORWARD -p tcp -d 192.168.2.10 --dport 4661 -i $EXTIF -j 
ACCEPT
  $IPTABLES -A MYFORWARD -p tcp -d 192.168.2.10 --dport 4662 -i $EXTIF -j 
ACCEPT
  $IPTABLES -A MYFORWARD -p udp -d 192.168.2.10 --dport 4665 -i $EXTIF -j 
ACCEPT
  $IPTABLES -A MYFORWARD -p udp -d 192.168.2.10 --dport 4672 -i $EXTIF -j 
ACCEPT

A few weeks ago I changed the client from LAN to WLAN, and it's IP
changes from 192.168.0.10 to 192.168.2.10. But after days, the LOG
rules in my forward chains still logged connection attempts to
192.168.0.10, and I had a low ID on my WLAN-client.
BTW, there where no rules left, I tried
 iptables -L|grep 192.168.0.10 and
 iptables -t nat -L|grep 192.168.0.10

Then I stopped trying But now, without changing anything, it
works. As anyone an explanation for this behavior?



- --
Public Key erhältlich auf den PGP-Keyservern, sowie mit weiteren Informationen 
auf http:\\www.voits.net.
Fingerprint: 9b482c5c41800ef0f6c8b01ae4df20ac

-BEGIN PGP SIGNATURE-
Version: 2.6

iQEVAwUAPq5ijJ9LInC1Fu5pAQHN/QgAiaxFwzTjY120jLDggtFdzGreaN1+zmwc
o2+UMaSoTLH5nVxtunZOMiJVGeMqayLpjunQQhhwWmNvujKA3+EsgIOevzpo/U0u
DRqjp7Z5L14H06eGB75GP6FBCjJmiMmCeyww4qxxCizfOZ0OuY2bdXKwCA28Hc6d
j6mSZjrLLKPGhAwMtRgt9visobD9/2RTrtZLrxdvcgjfauXw+PUJNnUjiP3qbCF6
b1lU1fm8MN0oHbUmJAtGGtIb39FPRo0RQf6SXW/RYZ1NGiilcza3H28Z4ZMnzeue
yI1BRsFJIJB3TO75XZ4SAQAjfM5195TFMa7YvBhBwbKs9hX5uLB5BA==
=TJqp
-END PGP SIGNATURE-