7076349 2001-09-09 19:04 +0800 /98 rader/ Tonu Samuel <tonu@please.do.not.remove.this.spam.ee>
Sänt av: joel@lysator.liu.se
Importerad: 2001-09-10 08:11 av Brevbäraren
Extern mottagare: mysql@mysql.com
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <19132>
Ärende: Notice about seconds overroll - S7K bug
------------------------------------------------------------
From: Tonu Samuel <tonu@please.do.not.remove.this.spam.ee>
To: mysql@mysql.com, bugtraq@securityfocus.com
Message-ID: <1000033481.2390.5.camel@x153.internalnet>
I would like to make your attention on bug which was introduced
tonight and can affect some people who are using (var)char field to
store timestamp data.
It is not worst security bug. It affects only people who already had
bug in their code. Just now this bug become visible/exploitable.
This is not MySQL bug. This is how people use their database. Also
similar situation can be found in other software. I would like to
inform people in public list as maybe some people have to search
similar problems.
The problem:
Computers store time and date usually as integer value representing
amount of seconds from 1 January 1970. Tonight it overrolled from
999999999 to 1000000000.
Possible bug and exploit relies on fact that some people have used
character type of field to store this seconds information (we have
already such case)
example:
mysql> create table session (expire varchar(100) not null);
Query OK, 0 rows affected (0.31 sec)
mysql> insert into session values (999999997), (999999998),
(999999999), (1000000000), (1000000001); Query OK, 5 rows affected
(0.00 sec) Records: 5 Duplicates: 0 Warnings: 0
mysql>
mysql> select * from session;
+------------+
| expire |
+------------+
| 999999997 |
| 999999998 |
| 999999999 |
| 1000000000 |
| 1000000001 |
+------------+
5 rows in set (0.00 sec)
mysql>
Let's assume that this table contains values we use somewhere to
authenticate users. After user logs in, we write down session expiry
time and later we check it like this:
mysql> select count(*) from session where expire >= '1000032535';
+----------+
| count(*) |
+----------+
| 3 |
+----------+
1 row in set (0.00 sec)
mysql>
WOW, what happened? Shouldn't be 100003253 bigger than any value in
table? It worked yesterday!
In MySQL we suggested people to use quotation marks around integer
values. This can avoid many web-based attacks targeted to modify SQL
commands (more information on
http://www.mysql.com/doc/G/e/General_security.html). This is the
reason why people put quotation marks around integer expressions and
this is correct. Also automatic type casting will fix the source
problem is column data is integer or some time/date vale. But when
both column is character type and expression, they get compared as
strings. And as we know, strings get sorted in order:
1,11,2,22
but integers:
1.2.11.22
So, this is why 100003253 < 1000000000
It is possible that some web applicatons have endless expiry times now
and not only in MySQL contexts.
--
For technical support contracts, goto https://order.mysql.com/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Tonu Samuel <tonu@mysql.com>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Security Administrator
/_/ /_/\_, /___/\___\_\___/ Hong Kong, China
<___/ www.mysql.com
(7076349) /Tonu Samuel <tonu@please.do.not.remove.this.spam.ee>/(Ombruten)
Kommentar i text 7095621 av Robert Bihlmeyer <robbe@orcus.priv.at>
7095621 2001-09-12 12:05 +0200 /35 rader/ Robert Bihlmeyer <robbe@orcus.priv.at>
Sänt av: joel@lysator.liu.se
Importerad: 2001-09-12 20:55 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: Tonu Samuel <tonu@please.do.not.remove.this.spam.ee>
Mottagare: Bugtraq (import) <19180>
Kommentar till text 7076349 av Tonu Samuel <tonu@please.do.not.remove.this.spam.ee>
Ärende: Re: Notice about seconds overroll - S7K bug
------------------------------------------------------------
Tonu Samuel <tonu@please.do.not.remove.this.spam.ee> writes:
> I would like to make your attention on bug which was introduced tonight
> and can affect some people who are using (var)char field to store
> timestamp data.
Since the winnings are so slim, I hope not many people fell pray to
this bug. If you're gonna waste 5 bytes on convenience, wasting a 6th
to buy you peace at least until Unix doomsday does not seem too much.
If you were expecting speed earnings (no strtoul-ing the input) these
get pretty much zilched should you later compare the strings.
> In MySQL we suggested people to use quotation marks around integer
> values.
Which won't protect you from '; attacks, of course. So why not just
make sure that it is a real integer (ahem)? In Perl it would be as
easy as adding zero.
> This is the reason why people put quotation marks around integer
> expressions and this is correct.
Really?
> But when both column is character type and expression, they get
> compared as strings.
As is to be expected when you're lying to your software. The date
types are there for a reason.
--
Robbe
(7095621) /Robert Bihlmeyer <robbe@orcus.priv.at>/(Ombruten)
Bilaga (application/pgp-signature) i text 7095623
Kommentar i text 7109700 av Tonu Samuel <tonu@please.do.not.remove.this.spam.ee>
7095623 2001-09-12 12:05 +0200 /10 rader/ Robert Bihlmeyer <robbe@orcus.priv.at>
Bilagans filnamn: "signature.ng"
Importerad: 2001-09-12 20:55 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: Tonu Samuel <tonu@please.do.not.remove.this.spam.ee>
Mottagare: Bugtraq (import) <19181>
Bilaga (text/plain) till text 7095621
Ärende: Bilaga (signature.ng) till: Re: Notice about seconds overroll - S7K bug
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7n0ux8g21h7wYWrMRAuUPAKDIJPxZBPKVgJHZldMJWi5WFBvGtgCfX3Up
WuJt+l/FTSnQe2bYrbeOIf0=
=lbmR
-----END PGP SIGNATURE-----
(7095623) /Robert Bihlmeyer <robbe@orcus.priv.at>/--
7109700 2001-09-15 02:27 +0800 /57 rader/ Tonu Samuel <tonu@please.do.not.remove.this.spam.ee>
Sänt av: joel@lysator.liu.se
Importerad: 2001-09-14 21:35 av Brevbäraren
Extern mottagare: Robert Bihlmeyer <robbe@orcus.priv.at>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <19203>
Kommentar till text 7095621 av Robert Bihlmeyer <robbe@orcus.priv.at>
Ärende: Re: Notice about seconds overroll - S7K bug
------------------------------------------------------------
From: Tonu Samuel <tonu@please.do.not.remove.this.spam.ee>
To: Robert Bihlmeyer <robbe@orcus.priv.at>
Cc: bugtraq@securityfocus.com
Message-ID: <1000492044.1806.6.camel@x153.internalnet>
On 12 Sep 2001 12:05:13 +0200, Robert Bihlmeyer wrote:
> > In MySQL we suggested people to use quotation marks around integer
> > values.
>
> Which won't protect you from '; attacks, of course. So why not just
> make sure that it is a real integer (ahem)? In Perl it would be as
> easy as adding zero.
I do not start fighting your flame as most it was just let say
"misinformed" stuff. And I do not know what is '; attack. There are
two separate things - one is closing strings with ' or ", other thing
is semicolon.
1. Semicolon - this is not interpreted as MySQL as some special
character. Some people think that it is possible to do with it but
they are just confused. Semicolon is handled in MySQL command line
client! Because there is no ways to return multiple results to
single query, there is also no way to send two queries with single
call. No semicolon attacks.
2. ' or " can protect integers well when used properly. Assume that
there is an URL like http://something/show.php?id=10 and in PHP page
it is called like:
mysql_query("select * from table where id=".addslashes($id));
Intruder changes URL to http://something/show.php?id=10%20or%201=1%34
which changes command to: select * from table where id=10 or 1=1
I do not want go into more details as script kiddies also read this
list but this is many ways to use it. There is not much in MySQL we
can do to change this behaviour. The way you seem we suggest to avoid
attacks and you are ironic about is making it:
mysql_query("select * from table where id='".addslashes($id)."'");
which comes to:
select * from table where id='10 or 1=1'
or
select * from table where id='10\' or 1=1'
And you prorably know what happens when do atoi() call on string? I
see no possibilty to go through this protection....
--
For technical support contracts, goto https://order.mysql.com/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Tonu Samuel <tonu@mysql.com>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Security Administrator
/_/ /_/\_, /___/\___\_\___/ Hong Kong, China
<___/ www.mysql.com
(7109700) /Tonu Samuel <tonu@please.do.not.remove.this.spam.ee>/(Ombruten)