[UNIX] Notice about Seconds Rollover - S7K Bug (Security Vulnerability)
From: support@securiteam.comDate: 09/21/01
- Previous message: support@securiteam.com: "[UNIX] Security Vulnerability in SpeechD"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Subject: [UNIX] Notice about Seconds Rollover - S7K Bug (Security Vulnerability) Message-Id: <20010921142759.B4696138C1@mail.der-keiler.de> Date: Fri, 21 Sep 2001 16:27:59 +0200 (CEST)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
Notice about Seconds Rollover - S7K Bug (Security Vulnerability)
------------------------------------------------------------------------
SUMMARY
MySQL and other products use a timestamp standard of, the number of
seconds since the 1 January 1970. A security vulnerability occurs ever
since the 10 of September 2001 due to the fact that the number of seconds
changed from a 9 digit number to a 10 digit number. The vulnerability is
caused whenever the timestamp is compared as a string (varchar) instead of
a number (integer).
DETAILS
This security bug only affects people who already had bug in their code.
This means that the date did not cause the bug (unlike the Year 2000
problem) but rather faulty coding techniques.
This is not a MySQL bug, but rather how people use their database. In
addition, similar situation can be found in other software.
The problem:
Computers store time and date usually as integer value representing amount
of seconds from 1 January 1970. Tonight it rolled over from 999999999 to
1000000000.
Possible bug and exploit relies on fact that some people have used
character type of field to store this second's information.
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>
"What happened? Should not 100003253 be bigger than any value in table? It
worked yesterday!"
In MySQL it is suggested that people 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>
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. In addition, automatic type casting will fix the source problem
is column data is integer or some time/date vale. Nevertheless, when both
columns are character type and expression, they are compared as strings.
Moreover, as we know, strings are 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 applications have endless expiry times now
and not only in MySQL contexts.
ADDITIONAL INFORMATION
The information has been provided by
<mailto:tonu@please.do.not.remove.this.spam.ee> Tonu Samuel.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[UNIX] Security Vulnerability in SpeechD"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
