mSQL.remote.txt

`Date: Mon, 15 Feb 1999 04:56:24 -0500  
From: Dave G. <[email protected]>  
To: [email protected]  
Subject: KSR[T] Advisory #10: mSQL ServerStats  
  
KSR[T] Security Advisories  
http://www.ksrt.org  
[email protected]  
  
---  
  
KSR[T] Advisory #010  
Date: Feb. 15, 1999  
ID #: msql-info-010  
  
Affected Program: mSQL (Mini SQL) 2.0.6 and below  
  
Operating System(s): UNIX (Not vendor specific)  
  
Summary: Remote attackers could potentially gain read and/or  
access to databases by retrieving authentication  
information that is displayed in the response to a  
remote statistics query.  
  
Problem Description: mSQL is a database engine (available from  
http://www.hughes.com.au) that supports a subset of  
the ANSI SQL query specifications. If remote  
access is enabled (as of 2.0.4.1 remote access is  
disabled by default) a remote user can retrieve  
sensitive information.  
  
By sending a ServerStats request, a remote attacker  
can view the following information about the msqld  
process:  
  
1. The connection table  
This table is a 'finger' like display of users  
connected to the server, which databases they  
are accessing, what hosts they are accessing  
the server from, and other less critical  
pieces of information.  
  
Since mSQL uses either host based and/or user  
based authentication, this table reveals all  
of the necessary components to access a  
particular database. This is only true if a  
user is accessing a database at the time of a  
query.  
  
2. The server version  
This allows an attacker to determine if a  
machine is running a vulnerable version of  
mSQL.  
  
3. The current and maximum number of connections  
These two pieces of information can be used to  
launch an efficient denial of service attack.  
  
4. The user name and user id of the msqld process  
These two pieces of information provide  
information about the underlying operating  
system.  
  
  
Compromise: If host based access control is disabled, a  
remote attacker can use the user names listed in  
the connection table to access databases. If host  
based access control is enabled, a remote attacker  
could launch a more complex attack (like DNS cache  
poisoning) to access mSQL databases.  
  
Notes: We would like to thank David J. Hughes and Window  
Snyder for their assistance with this advisory.  
  
Patch/Fix: The latest version of mSQL (2.0.7) scheduled for  
release on February 15th, 1999 has disabled remote  
statistics gathering.  
  
----------------------------------------------------------------------------------  
  
Date: Mon, 15 Feb 1999 13:10:44 -0800  
From: John W. Temples <[email protected]>  
To: [email protected]  
Subject: Re: KSR[T] Advisory #10: mSQL ServerStats  
  
On Mon, 15 Feb 1999, Dave G. wrote:  
  
> Compromise: If host based access control is disabled, a  
> remote attacker can use the user names listed in  
> the connection table to access databases. If host  
> based access control is enabled, a remote attacker  
> could launch a more complex attack (like DNS cache  
> poisoning) to access mSQL databases.  
  
This is hardly news; mSQL's access control is extremely weak.  
ServerStats probably makes it easier to get into an mSQL database, but  
if remote access is enabled, you simply need to know an authorized  
username (say, "root") to log into the database -- there are no  
passwords. And you don't even need a username to perform DoS attacks,  
since mSQL is a single-threaded server -- just telnet to mSQL's port  
and sit there. As far as I can see, the only thing that's changed  
since I posted about this in September, 1997, is that remote access is  
now disabled by default.  
  
--  
John W. Temples, III || Providing the first public access Internet  
Gulfnet Kuwait || site in the Arabian Gulf region  
  
----------------------------------------------------------------------------------  
  
Date: Mon, 15 Feb 1999 16:37:31 -0500  
From: Dave G. <[email protected]>  
To: [email protected]  
Subject: Re: KSR[T] Advisory #10: mSQL ServerStats  
  
On Mon, 15 Feb 1999, John W. Temples wrote:  
  
> On Mon, 15 Feb 1999, Dave G. wrote:  
>  
> > Compromise: If host based access control is disabled, a  
> > remote attacker can use the user names listed in  
> > the connection table to access databases. If host  
> > based access control is enabled, a remote attacker  
> > could launch a more complex attack (like DNS cache  
> > poisoning) to access mSQL databases.  
>  
> This is hardly news; mSQL's access control is extremely weak.  
> ServerStats probably makes it easier to get into an mSQL database, but  
> if remote access is enabled, you simply need to know an authorized  
> username (say, "root") to log into the database -- there are no  
> passwords.  
  
I disagree. This is news :-)  
  
There is no probably about this. If you can issue a ServerStats request  
on an mSQL server that is in use, you _will_ find all of the  
authentication credentials necessary to access mSQL databases. Your post  
basically pointed out that if you have the authentication credentials  
or can guess them, you can access mSQL databases. Ours states that you  
_can_ get them right from the server.  
  
Your post ( http://geek-girl.com/bugtraq/1997_3/0460.html ), discusses  
three things:  
  
1) default configuration is insecure  
2) User based authentication is insufficient ( especially on multi-user  
machines)  
3) Host based authentication does one way DNS lookups based on IP  
address which is trivial to bypass.  
  
> And you don't even need a username to perform DoS attacks,  
> since mSQL is a single-threaded server -- just telnet to mSQL's port  
> and sit there. As far as I can see, the only thing that's changed  
> since I posted about this in September, 1997, is that remote access is  
> now disabled by default.  
>  
  
The advisory never states you need a user name for a denial of service  
attack. And while it does show that other pieces of information could be  
used to assist in a DOS attack, they aren't necessary to launch one.  
  
Dave G.  
<[email protected]>  
http://www.ksrt.org  
  
----------------------------------------------------------------------------------  
  
Date: Mon, 15 Feb 1999 13:53:03 -0800  
From: John W. Temples <[email protected]>  
To: [email protected]  
Subject: Re: KSR[T] Advisory #10: mSQL ServerStats  
  
On Mon, 15 Feb 1999, Dave G. wrote:  
  
> There is no probably about this. If you can issue a ServerStats request  
> on an mSQL server that is in use, you _will_ find all of the  
> authentication credentials necessary to access mSQL databases. Your post  
> basically pointed out that if you have the authentication credentials  
> or can guess them, you can access mSQL databases. Ours states that you  
> _can_ get them right from the server.  
  
What isn't news is the fact that allowing remote access to an mSQL  
database is extremely unwise. Unauthorized access and DoS attacks are  
far too simple to achieve. Adding or removing ServerStats access  
doesn't change this.  
  
--  
John W. Temples, III || Providing the first public access Internet  
Gulfnet Kuwait || site in the Arabian Gulf region  
  
----------------------------------------------------------------------------------  
  
Date: Thu, 18 Feb 1999 15:32:20 -0800  
From: John W. Temples <[email protected]>  
To: [email protected]  
Subject: Re: mSQL vulnerability.  
  
On Wed, 17 Feb 1999, Christofer C. Bell wrote:  
  
> I'd like to point out that mSQL by default (all versions) DO NOT have  
> hosts based access control enabled.  
  
This was noted in Bugtraq long ago, but isn't entirely true with recent  
versions.  
  
Remote access is disabled by default going back to at least version  
2.0.4.1. There are new "Remote_Access" and "Local_Access" keywords in  
msql.conf, set by default to False and True, respectively, in the  
included sample file. These keywords take precedence over the "access"  
keyword in msql.acl.  
  
What hasn't changed in recent versions is that all databases have  
unrestricted local access by default. I still believe it would be wise  
for mSQL to ship with a default msql.acl file that denies all access.  
  
--  
John W. Temples, III || Providing the first public access Internet  
Gulfnet Kuwait || site in the Arabian Gulf region  
  
----------------------------------------------------------------------------------  
  
Date: Wed, 17 Feb 1999 10:00:29 -0600  
From: Christofer C. Bell <[email protected]>  
Reply-To: [email protected]  
To: [email protected]  
Subject: mSQL vulnerability.  
  
I'd like to point out that mSQL by default (all versions) DO NOT have  
hosts based access control enabled. Note that when you start the msql2d  
process for the first time, you see this message:  
  
Mini SQL Version 2.0.7 Copyright (c) 1993-94 David J. Hughes Copyright (c)  
1995-99 Hughes Technologies Pty Ltd. All rights reserved.  
  
Loading configuration from '/usr/local/Hughes/msql.conf'.  
Server process reconfigured to accept 200 connections.  
Server running as user 'msql'.  
Server mode is Read/Write.  
  
Warning : No ACL file. Using global read/write access.  
  
The "Warning:" is the important part. Even if you use the provided  
msql.acl.sample file as your acl file, the permissions are as follows:  
  
database=test  
read=bambi,-root  
write=root  
host=*  
access=local,remote  
option=rfc931  
  
database=minerva  
read=*  
write=minerva  
access=local  
  
This sets up some form of access restrictions on databases 'test' and  
'minerva' but not on any databases YOU create. Please make sure to edit  
this file and use host based security.  
  
--  
Christofer C. Bell Systems Analyst  
OSSC - Systems Management email: [email protected]  
Sprint Communications phone: 913-534-2535  
  
`