MySQL 5.0 information leak?

[Bernd Wurst]

--nextPart1525620.duXLNTX6Vj
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi.

I just upgraded to mysql 5.0.18 and started using all those cool new=20
features. :)

But concerning VIEWs, I think the information_schema is too verbose to=20
the user. I started creating a VIEW that searches information from=20
several tables, mangles the data and gives the user a clean table with=20
his data. So far, so good.

But I only give the user access to this VIEW, so he cannot see what's=20
done to get his data from several tables.

SHOW CREATE VIEW myview;
does (correctly) result in an error that the user is not allowed to see=20
the CREATE VIEW.

But SELECT * FROM information_schema.views; returns the full query that=20
ceates the desired VIEW.

I think of this as a security issue because I have user accounts (nss)=20
that have publicly available credentials but noone should be able to=20
see how the database really is organized.=20

What do you think of this? Bug?

cu, Bernd

=2D-=20
Windows Error 019: User error. It's not our fault. Is not! Is not!

--nextPart1525620.duXLNTX6Vj
Content-Type: application/pgp-signature

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

iQIVAwUAQ9DR7w0b18vi86Q/AQJG7w//aszB8jx7a/upqgnUWmRugZWWzxaYRnAB
m4SSCyslZUbimLgvkhzwMr2g+Ox55n7bTD7vJ6PDCiIVq3pjNP 7Qt87Dq4Yy3LF8
lvsEwaPUsIpTqnWqnB4t53ONEIEClBcehpWZVamAOKETAuM4gx PiivckAc9BUppc
jFqsCEpYuOyT83ZLL5vmp24Y4xigH5N883NrQ1WSgTHh9Ahp5C CJqKx7prYajA4k
iKDCD+GJ/oEvPhnUEjAHL57X1KMQbd3p25AKWam8+F68xKMBPgtJKG/ALZUZYMEx
A8JZfgplA/1m84SWE7Smb0TuWI4abqK6815ncSzVnI0oginKvSSTcA6XZ535 YE7O
LlE+XyqL2rrth7UsdPKO5ZiGCJ9v424LRAKYkThQ3oH8YyS2PO 3kmiOPcnuY81fp
odnnJjrirHYOvndPMALUAUoXnBwm+6yucrCbDpffEh/gNx4/wMIEMIjtYOl+jwSg
X1VGSuUW00iBToRvpMQCIbjiM/PJLUkMkOQA9wzJPt6FVQMFKdwu0Ee574GV2LaB
La/m5U37jwkcbzxjwTpcl/5TXvpBok1/9N4/uUHyah3JMW8HOlsgVv1WCLmO+/VA
NOnjz3ogY/1p4TEU3HDPyqOpkVgKRmlAyoPEXprTt1HbJvgrVwVEYtmanAtx 6D4r
n3CBsmADou8=
=eDS1
-----END PGP SIGNATURE-----

--nextPart1525620.duXLNTX6Vj--

[Burton Strauss]

Traditionally the schema for a database is NOT secure information.
Applications download this information to build queries on the fly.

The essential problem is relying on security by obscurity, "I have user
accounts (nss) that have publicly available credentials but noone [sic]
should be able to see how the database really is organized".

-----Burton

-----Original Message-----
From: Bernd Wurst [mailto:bernd@bwurst.org]
Sent: Friday, January 20, 2006 6:05 AM
To: bugtraq@securityfocus.com
Subject: MySQL 5.0 information leak?

Hi.

I just upgraded to mysql 5.0.18 and started using all those cool new
features. :)

But concerning VIEWs, I think the information_schema is too verbose to the
user. I started creating a VIEW that searches information from several
tables, mangles the data and gives the user a clean table with his data. So
far, so good.

But I only give the user access to this VIEW, so he cannot see what's done
to get his data from several tables.

SHOW CREATE VIEW myview;
does (correctly) result in an error that the user is not allowed to see the
CREATE VIEW.

But SELECT * FROM information_schema.views; returns the full query that
ceates the desired VIEW.

I think of this as a security issue because I have user accounts (nss) that
have publicly available credentials but noone should be able to see how the
database really is organized.

What do you think of this? Bug?

cu, Bernd

--
Windows Error 019: User error. It's not our fault. Is not! Is not!

[Stephen Frost]

--X4lxMjKOkkkXp99S
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Bernd Wurst (bernd@bwurst.org) wrote:
> I think of this as a security issue because I have user accounts (nss)=20
> that have publicly available credentials but noone should be able to=20
> see how the database really is organized.=20
>=20
> What do you think of this? Bug?

Probably not but the answer you seek is in the SQL specification.
Information Schema is defined there and it also defines what is allowed
to be seen and by whom. Wanting to hide the database layout from the
users of the database in this way seems quite... confused.

Thanks,

Stephen

--X4lxMjKOkkkXp99S
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFD0YDArzgMPqB3kigRAntcAJ9FvEoL9ZPgXInIDrh0C9 oWzjpYnQCeLCDK
RgS6zLodxd1NkqG7o6czKWo=
=nAfc
-----END PGP SIGNATURE-----

--X4lxMjKOkkkXp99S--

[Lance James]

Burton Strauss wrote:

>I'd get a refund on your coinage... root's password is not security by
>obscurity, it is an undisclosed piece of information. There is a big
>difference.
>
>

Now we're arguing symantics, undislosed information would also by the
MySQL information leak problem then too, as Bernd doesn't want to
disclose such information to an attacker.

>-----Burton
>
>-----Original Message-----
>From: Lance James [mailto:bugtraq@securescience.net]
>Sent: Saturday, January 21, 2006 2:09 PM
>To: Burton Strauss
>Cc: 'Bernd Wurst'; bugtraq@securityfocus.com
>Subject: Re: MySQL 5.0 information leak?
>
>Burton Strauss wrote:
>
>
>
>>Traditionally the schema for a database is NOT secure information.
>>Applications download this information to build queries on the fly.
>>
>>The essential problem is relying on security by obscurity, "I have user
>>accounts (nss) that have publicly available credentials but noone [sic]
>>should be able to see how the database really is organized".
>>
>>
>>
>>
>
>Denying the security through obscurity is not applicable could be incorrect.
>It does have it's place i.e. what's your root password?
>
>In WebAppSec, security by obscurity assists in deterring attackers, and
>buying some time. So if one can prevent full disclosure of the schema of the
>db, that can be useful combined with security in depth.
>
>my two cents.
>
>-Lance
>
>
>
>>-----Burton
>>
>>-----Original Message-----
>>From: Bernd Wurst [mailto:bernd@bwurst.org]
>>Sent: Friday, January 20, 2006 6:05 AM
>>To: bugtraq@securityfocus.com
>>Subject: MySQL 5.0 information leak?
>>
>>Hi.
>>
>>I just upgraded to mysql 5.0.18 and started using all those cool new
>>features. :)
>>
>>But concerning VIEWs, I think the information_schema is too verbose to
>>the user. I started creating a VIEW that searches information from
>>several tables, mangles the data and gives the user a clean table with
>>his data. So far, so good.
>>
>>But I only give the user access to this VIEW, so he cannot see what's
>>done to get his data from several tables.
>>
>>SHOW CREATE VIEW myview;
>>does (correctly) result in an error that the user is not allowed to see
>>the CREATE VIEW.
>>
>>But SELECT * FROM information_schema.views; returns the full query that
>>ceates the desired VIEW.
>>
>>I think of this as a security issue because I have user accounts (nss)
>>that have publicly available credentials but noone should be able to
>>see how the database really is organized.
>>
>>What do you think of this? Bug?
>>
>>cu, Bernd
>>
>>--
>>Windows Error 019: User error. It's not our fault. Is not! Is not!
>>
>>
>>
>>
>>
>>
>
>
>
>

[Johan De Meersman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5CC41A9FDC7BFAB03B9A4B31
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Burton Strauss wrote:

>Traditionally the schema for a database is NOT secure information.
>Applications download this information to build queries on the fly.
>
>The essential problem is relying on security by obscurity, "I have user
>accounts (nss) that have publicly available credentials but noone [sic]
>should be able to see how the database really is organized".
>
>

I don't agree - basic security says that no user should have more access
than he strictly needs. A user that only uses a fixed set of queries
doesn't need to see how the database is laid out - if he can, an
attacker wouldn't need to guess the names of other fields that may
contain sensitive information.

Obviously those fields should be access-restricted as well, but you
shouldn't make things easier on any front.


--
You prefer the company of the opposite sex, but are well liked by your own.
--

Public GPG key at blackhole.pca.dfn.de

GCS/IT d- s:+ a- C(+++)$ UL++++$ P+++(++++)$ L++(+++)$ !E- W+(+++)$
N+(++) o K w$ !O !M V PS(++)@ PE-(++)@ Y+ PGP++(+++) t(+) 5 X R tv--
b++(++++) DI++(++++) D++ G e++>+++++ h(+) r y+**


--------------enig5CC41A9FDC7BFAB03B9A4B31
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFD1gsHxz0AbiB4HpQRAvpTAJ9KZOS5FT2D5sl/nOvMr3qLK5NfOgCgmYG6
ZxfxLeTbf9yi1MXQPlx2FDo=
=2TR6
-----END PGP SIGNATURE-----

--------------enig5CC41A9FDC7BFAB03B9A4B31--

[Burton Strauss]

It's not semantics at all. Every password is a piece of undisclosed
information and NOBODY views that as security by obscurity. It's the corner
stone of AAA ... Something you know, something you have, something about
you.

-----Burton

-----Original Message-----
From: Lance James [mailto:bugtraq@securescience.net]
Sent: Sunday, January 22, 2006 10:48 AM
To: Burton Strauss
Cc: 'Bernd Wurst'; bugtraq@securityfocus.com
Subject: Re: MySQL 5.0 information leak?

Burton Strauss wrote:

>I'd get a refund on your coinage... root's password is not security by
>obscurity, it is an undisclosed piece of information. There is a big
>difference.
>
>

Now we're arguing symantics, undislosed information would also by the MySQL
information leak problem then too, as Bernd doesn't want to disclose such
information to an attacker.

>-----Burton
>
>-----Original Message-----
>From: Lance James [mailto:bugtraq@securescience.net]
>Sent: Saturday, January 21, 2006 2:09 PM
>To: Burton Strauss
>Cc: 'Bernd Wurst'; bugtraq@securityfocus.com
>Subject: Re: MySQL 5.0 information leak?
>
>Burton Strauss wrote:
>
>
>
>>Traditionally the schema for a database is NOT secure information.
>>Applications download this information to build queries on the fly.
>>
>>The essential problem is relying on security by obscurity, "I have
>>user accounts (nss) that have publicly available credentials but noone
>>[sic] should be able to see how the database really is organized".
>>
>>
>>
>>
>
>Denying the security through obscurity is not applicable could be
incorrect.
>It does have it's place i.e. what's your root password?
>
>In WebAppSec, security by obscurity assists in deterring attackers, and
>buying some time. So if one can prevent full disclosure of the schema
>of the db, that can be useful combined with security in depth.
>
>my two cents.
>
>-Lance
>
>
>
>>-----Burton
>>
>>-----Original Message-----
>>From: Bernd Wurst [mailto:bernd@bwurst.org]
>>Sent: Friday, January 20, 2006 6:05 AM
>>To: bugtraq@securityfocus.com
>>Subject: MySQL 5.0 information leak?
>>
>>Hi.
>>
>>I just upgraded to mysql 5.0.18 and started using all those cool new
>>features. :)
>>
>>But concerning VIEWs, I think the information_schema is too verbose to
>>the user. I started creating a VIEW that searches information from
>>several tables, mangles the data and gives the user a clean table with
>>his data. So far, so good.
>>
>>But I only give the user access to this VIEW, so he cannot see what's
>>done to get his data from several tables.
>>
>>SHOW CREATE VIEW myview;
>>does (correctly) result in an error that the user is not allowed to
>>see the CREATE VIEW.
>>
>>But SELECT * FROM information_schema.views; returns the full query
>>that ceates the desired VIEW.
>>
>>I think of this as a security issue because I have user accounts (nss)
>>that have publicly available credentials but noone should be able to
>>see how the database really is organized.
>>
>>What do you think of this? Bug?
>>
>>cu, Bernd
>>
>>--
>>Windows Error 019: User error. It's not our fault. Is not! Is not!
>>
>>
>>
>>
>>
>>
>
>
>
>

[Duncan Simpson]

Nobody has mentioned this yet, so maybe I should. Accpording to the MySQL
documentation the infromation schema is database and there is no suggestion
that the access controls do not work. You should be able to determine who has
what access to the information schema using standard grant and revoke commands.

I know my database using code has no need for the information schema, because
the queries and types of the results are both fixed in advance, albeit with
some limited variable portions. The obvious tools not working, due to lack of
access to the database schema, might slow down some crackers by a worthwhile amount.

The original poster might be well serverd by a program that does predetermined
queries, using a restricted identity for extra security, and keeps the
connection detials to itself. (I do not think obscuring the database structure
is worth much except as one of a wider set of security measures.)
--k0QLwNOi013478.1138312704/mail.simpson.demon.co.uk
Content-Type: text/plain

Duncan (-:
"software industry, the: unique industry where selling substandard goods is
legal and you can charge extra for fixing the problems."