MYsql Help usingPutty

[sajid]

Salams all

ive downloaded Putty to access the SSH terminal to my site

what im trying to do is create databases via putty..

but when i login i get the following mesage:

ERROR 1045: Access denied for user: 'user@localhost' (Using password: NO)

once im logged in i type in "mysql"

and the above message appears

anyone has any ideas????

help!!!

ws
sajid

[Qurratulain]

Salaam
Maybe not of much help but on Linux it worked like u had to create an administrator account with a password since I think ur not using any,then login with that ID and password, after that type ./mysql if u want to run it on Linux I donno what OS system ur using.
Just a little maybe not of much help:o

[baba]

Originally posted by sajid
Salams all

ive downloaded Putty to access the SSH terminal to my site

what im trying to do is create databases via putty..

but when i login i get the following mesage:

ERROR 1045: Access denied for user: 'user@localhost' (Using password: NO)

once im logged in i type in "mysql"

and the above message appears

anyone has any ideas????

help!!!

ws
sajid You need a separate login for the mySQL server. Say your mySQL username is 'cat' and your password is 'monkey', you'd type this to get in:

mysql -ucat -pmonkey

If you're root user, then change 'cat' to 'root'.

Hope that helps,

[obsidian]

Advisory 04/2002
Multiple MySQL vulnerabilities

Release Date: 2002/12/12
Author: Stefan Esser [s.esser@ematters.de]
Application: MySQL <= 3.23.53a, <= 4.0.5a
Severity: Several vulnerabilities within (lib)MySQL could allow (remote) compromise of client and/or server.
Risk: Medium to Critical
Reference: http://security.e-matters.de/advisories/042002.html
Last Modified: 2002/12/13

Overview

We have discovered two flaws within the MySQL server that can be used by any MySQL user to crash the server. Furthermore one of the flaws can be used to bypass the MySQL password check or to execute arbitrary code with the privileges of the user running mysqld.

We have also discovered an arbitrary size heap overflow within the mysql client library and another vulnerability that allows to write '\0' to any memory address. Both flaws could allow DOS attacks against or arbitrary code execution within anything linked against libmysqlclient.

Details

While auditing the MySQL sourcetree we discovered several bugs within the MySQL client and server that are listed below:

+++ SERVER +++ COM_TABLE_DUMP - Signed Integer Vulnerability

When handling the COM_TABLE_DUMP package MySQL < 4.x takes two chars from the packet, casts them directly to unsigned integers and uses them as length parameters for memcpy. Obviously negative values within the chars will turn into very big unsigned numbers. Because this is a heap to heap copy operation and there is no memory allocating function within the SIGSEGV handler we strongly believe this bug can only be used for denial of service attacks. Depending on the packet mysqld will directly crash or hang in an endless loop of segmentation faults. This was tested against Windows, Linux and FreeBSD systems.

+++ SERVER +++ COM_CHANGE_USER - Password Length Vulnerability

In February 2000 Robert van der Meulen discovered a flaw within the main password authentication system of MySQL: The MySQL challenge response algorithm creates an expected response with exactly the length of the response provided by the client. So if the client sends only a one char response MySQL will check only one byte. But this means it is possible to give the correct response with only 32 tries (because the charset is only 32 chars big). When this bug was fixed in 2000 the MySQL authors simply added a check in the server that the response must be 8 chars long. However they forgot to add this check to the COM_CHANGE_USER command, too. So it is still possible for an attacker with a valid mysql-account to compromise the other accounts that are allowed to login from the same host. For a local user this means he can break into the mysql root account and so compromise all databases. This is especially dangerous in a shared environment or if the root user is allowed to login from other hosts than localhost. While the attacker can supply a one byte response to break into the other accounts he can also send an oversized one. If the response is longer than 16 chars the internal created expected answer overflows a stack buffer. If the response is long enough it is possible to overwrite the saved instruction pointer with bytes that are generated by the random number generator of the password verification algorithm. While this sounds hard or impossible to exploit, we successfully exploited this bug on our linux machines. Due to the fact that mysql restarts on crash you have unlimited tries. Because of the limited set of characters generated by the random number generator we strongly believe that this bug is not exploitable on Windows, because it is not possible to overwrite the instruction pointer with valid controllable addresses.

+++ CLIENT +++ libmysqlclient read_rows Overflow

When the MySQL client library receives answer rows from the server it wants to copy the answers into another buffer. Therefore it loops through the returned fields and copies them to the other location. This is done without actually checking if the stored field sizes are within the destination buffer boundaries. Additionally there is also a terminating '\0' added to the end of all fields without checking for enough space within the destination buffer. Due to the fact that this bug gets already triggered by a simple SELECT query anything that is linked against libmysql is potentially vulnerable. Due to the nature of this bug it is trivial to use it as denial of service attack against the client applications (A negative fieldsize will do the job). If it possible to use this overflow to execute code on the client system is different from application to application. It depends mainly on the fact if malloc() overflows are exploitable on that particular system and if the application allows enough control over the heap structure by triggering different execution paths.

+++ CLIENT +++ libmysqlclient read_one_row Byte Overwrittes

When the MySQL client library fetchs one row from the MySQL server it loops through the fields to remember pointers to the field values. The field sizes are trusted and not checked against out of boundary conditions. After remembering the pointer the previous field gets zero terminated. A malformed packet can supply any field size and so overwrite some arbitrary memory address with a '\0'. An invalid address will of course crash the client. Because the address that is written to is arbitrary (maybe hard to supply because it must be supplied as delta) all clients that make use of fetching the answer row by row are most probably vulnerable to arbitrary code execution exploits.

Finally it must be mentioned that an attacker can of course use a combination of the described attacks to break into a system or to get access to privileges he normaly does not own. f.e. it is possible for a local user to crash the server with the COM_TABLE_DUMP bug (if he cannot takeover the root account with the COM_CHANGE_USER bug) and then bind a fake server to the MySQL port 3306. And with a fake server he can exploit the libmysqlclient overflow. Another scenario would be an attacker that tries to exploit his favourite mod_scripting language to takeover the webserver by connecting to an external fake server...

[baba]

The best thing to do is to block all incoming connections to port 3306 at your firewall, except for trusted IPs.

[obsidian]

Sure, though my boxes don't run this, I posted if after seeing this thread...

[baba]

Thanks for posting it bro. We run mySQL at all the Ummah servers, though outside access to the mySQL port is usually blocked at the firewall.

[obsidian]

Thanks for posting it bro. We run mySQL at all the Ummah servers

My pleasure :)

I thought you ran MySQL at ummah, that was the real reason I
posted it.

Just a concerned brother...

[baba]

You thought the forum ran on Postgre? Or even Oracle? :D :D

[obsidian]

You thought the forum ran on Postgre? Or even Oracle?

Nope, I knew you ran MySQL as I have seen errors (sometimes! :p) when trying to get onto the discussion forums.

I haven't seen any errors since you guys upgraded your servers...

I run Oracle at work...

[baba]

We moved the forum to a dedicated server of it's own. Poor Ummah.com was overloaded. :D

[obsidian]

We moved the forum to a dedicated server of it's own. Poor Ummah.com was overloaded

I am sure it is/was with the "Lets make a long thread" and "I am bored" discussions :D

I hope the new one fares better - Inshallah

[wizard]

I dont know about the other vulneribility, but the change user vulneribility has been taken care of in the newer versions of mysql.