Re: MySQL 5.0 information leak?

[Lance James <bugtraq () securescience net>]

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!
> >
> >
> >
> >
> >    
>
>
>