NNTP-HTTP-Gate (war: KRISIS-list und cl.gruppen.krisis)
roby leemann
^^^^^^^^^^^
genau deswegen ist es aber noch nicht brauchbar und sehr wahrscheinlich
auch bei comlink noch nicht im einsatz.
name und email-adresse soll nicht beim posten editierbar sein, die va-
riablen sollten nach einer authentifizierung aus einer (mysql-)datenbank
geholt werden.
werde ich gelegentlich basteln.
ciao
roby
Fname.Lname
> schau mal bei http://awpc.ch/news/cl-netz/
> vorbei.
Gefällt mir gut.
--
/rgb
Ralf Barkow
zum Thema "Re: NNTP-HTTP-Gate (war: KRISIS-list und cl.gruppen.krisis)":
rl> name und email-adresse soll nicht beim posten editierbar sein, die va-
rl> riablen sollten nach einer authentifizierung aus einer (mysql-)datenbank
rl> geholt werden.
Apropos MySQL; Viktor Fougstedt <vik...@DTEK.CHALMERS.SE> meinte am
11.01.00 in der BUGTRAQ mailing list -- wenn ich schon dabei bin: Siehe
auch kr...@KOEHNTOPP.DE (Kristian Koehntopp) zum Betreff: PHP3 safe_mode
and popen() -- zum Thema "Serious bug in MySQL password handling.":
While installing MySQL 3.22.29 and testing it out, I discovered a
very serious bug in it's handling of the GRANT statement.
I have decided to post this message at this time although a fixed
distribution is not yet available at mysql.com. The reason for this is
that the subject has been discussed on the MySQL mailing list, and
that the cat is therefore already out of the bag. Many crackers out
there are already aware of implications and how to exploit this bug. A
temporary solution is suggested in this post, and a patch from TCX is
attached at the bottom.
Affected:
Known: MySQL 3.22.27, 3.22.29, 3.23.8
Suspected: All MySQL versions since 3.22.11.
Impact:
Anyone with access to a running MySQL and GRANT privilege for any
database or table in it, can change any MySQL-password he wishes,
including the MySQL superuser's.
Implications:
If the malicious user has access to run processes on the machine where
MySQL is running, he can hijack the entire database. If he does not
have such access, he can DOS the server by setting the MySQL
superuser's password to a random string.
The 'test'-users installed by MySQL's install scripts have GRANT
privileges for any database whose name begins with 'test', and can
therefore be used to exploit this bug. The 'test' accounts by default
have no passwords set, and no restrictions on where connects can come
from.
This makes all default-configured MySQL very vulnerable (anyone on the
net can change your MySQL superuser password). Be aware, however, that
_any_ user with a GRANT privilege (no matter on which database) in
your MySQL installation can exploit this bug. You may be vulnerable
even if you've removed the 'test' users.
Story:
I contacted the MySQL mailing list and reported this bug (the MySQL
mailing list is the official place to report bugs). The first person
from mysql.com I had a discussion with, said that this was the way it
was supposed to work. GRANT privileges were, according to him, by
definition global (even GRANTs for a single database were apparently
global) and implied the possibility to change anyone's password. I
almost bought his story and started thinking about changing to another
RDBMS.
Fortunately, Monty at TCX Datakonsult AB (the company that originally
wrote MySQL) acknowledged that it was a real and serious bug. No one
without UPDATE privilige on the mysql.user table should be able to set
anyone's password. A fix has been made, and new releases will be
available for download very soon.
Recommendation:
It is STRONGLY RECOMMENDED that anyone running MySQL 3.22.11 or later
UPGRADE to the new versions as soon as they are available at
www.mysql.com and it's mirrors.
While waiting for the new versions to arrive, or for opportunity to
install them
1) Revoke _all_ GRANT privileges from _all_ users in your MySQL system
except root@localhost. This includes GRANTs in the mysql.db table.
2) Confirm that your root@localhost password has not been altered.
For those of you using source distributions, I have received a patch
for the problem from TCX. It is attached at the bottom of this
message.
Details:
The bug is that the GRANT statement does not properly check privileges
when you give it an IDENTIFIED BY-clause. You can therefore GRANT
someone (including the MySQL superuser) a privilege you yourself
possess, and set her/his password at the same time using IDENTIFIED BY.
Which privilege you pass on does not matter. It is the side-effect
of the IDENTIFIED BY that does the magic. This can be exploited
regardless of your other permissions. You only need the GRANT
privilege for _any_ table or database to exploit this bug.
For someone having login access to the machine running MySQL,
hijacking the database is trivial once the MySQL superuser password
has been changed using the above method. For someone without login
access, changing the superuser password can be a simple way of
DOS:ing, or of extortion.
In the default setup, MySQL prohibits access to the superuser account
from any other hosts than localhost. Sites that allow superusers to
connect from the net may be vulnerable to hijacking from malicious
users without local access.
Since the password-less 'test'-accounts created by MySQL installation
scripts have GRANT privileges for any database whose name begins with
'test', they can be used to exploit this bug. Very nasty.
Exploit:
I will post an exploit as soon as the patched versions are available
(which should be tomorrow). The Kiddiez should be forced to do at
least _some_ work themselves. :-)
/Viktor...
[patch etc. gelöscht; /rgb]
--
/rgb