July 13, 2001
NOTE FROM BRUCE BLAIR:
In the interest of national security, research and media
accuracy, and disclosure, the following reports, memos,
and other exchanges among the principals involved in
the MPC&A problems summarized in the Blair op-ed (“Nukes:
A Lesson From Russia” in Washington Post, July 11, 2001,
p. A19) are posted below. As an aside, the Russians
with whom I have spoken conclude that the Microsoft
server problems outlined below also reside in innumerable
applications and could well adversely affect millions
of users around the world in all public, government,
and commercial sectors.
I have not posted some sensitive and confidential
material given to me during email exchanges or interviews.
Additional information derived from this material
will be posted at a later date.
[The following synopsis of the problem is useful.
BBlair]
From: Alexander N. Rumyantsev <anr@electronics.kiae.ru
<mailto:anr@electronics.kiae.ru>>
Subject: Your request dated September 11, 2000
Date: September 14, 2000
Attn: Dr. Bruce G. Blair
President
Center for Defense Information
Dear Dr. Blair,
I got your E-mail with request to provide some information
related to problems we are experiencing with Microsoft
software. Due to my business schedule I was not able
to answer it until now. Let me be reasonably brief.
1) Since 1994 'Kurchatov Institute' Russian Research
Center (KI) as well as a number of research and industrial
enterprises of Russian nuclear complex have been cooperating
with the U.S. Department of Energy (DOE) National
Labs in the area of strengthening nuclear material
physical protection, control and accounting (MPC&A)
in Russia. This program of cooperation, initially
known as 'Lab-to-Lab MPC&A cooperation program' brought
unprecedented positive results in this very sensitive
area on national security concern within relatively
short period of time. Its implementation has lead
to significant improvement of MPC&A systems at a number
of key enterprises of Russian nuclear complex and
increase nuclear material security in Russia. I may
add that it is hard to overestimate an importance
of this timely program for national security of Russia
and United States as well as for international security.
2) Among the most important factors influencing
the overall security of nuclear material in Russia
one is a development and implementation of modern
computerized nuclear material accounting systems (CMAS)
to be installed and put into operation at Russian
nuclear enterprises possessing weapon-usable material.
3) Due to relative novelty of this task for many
Russian nuclear enterprises still utilizing an obsolete
manual book-keeping accounting systems, the U.S. DOE
Los Alamos National Laboratory (LANL) considered as
a leader in modern CMAS architecture and technology,
proposed Russian partners to implement approaches,
technologies and software, which were developed or
selected by LANL in a course of development of so-called
'Local Area Nuclear Material Accounting System' (LANMAS),
assigned to become a standardized CMAS for the U.S.
DOE enterprises and National Labs with utilization
of Client-Server architecture and highly integrated
Microsoft software products.
4) The 'backbone' of any CMAS is a Database Management
System (DBMS). Because CMAS are systems of national
security and secrecy concerns, and due to expected
long life span for accounting data in such CMAS (counted
by tens of years), selection of the most appropriate
DBMS is a very difficult and controversial issue.
KI had significant experience in dealing with DBMS
of various manufacturers. However, in a course of
selection DBMS for KI site-wide CMAS decision was
made to follow on LANL recommendations and to implement
Microsoft SQL Server DBMS as a 'backbone' for KI CMAS.
We considered LANL practical experience in LANMAS
development as a proof of SQL Server reliability.
5) KI became the very first and still unique Russian
nuclear enterprise which has managed to develop, to
security certify and to put into trial mode of operation
with confidential accounting data the KI site-wide
CMAS (named KI-MACS). It happened in 1998. By the
end of 1999 the KI-MACS system was installed at a
number of Russian nuclear enterprises including 6
Russian Navy fresh fuel storage sites, Murmansk Shipping
Company managing a fleet of Russian nuclear ice-breakers,
and at the Mining and Chemical Combine (Zheleznogosrk
city, former Krasnoyarsk-26).
6) However, KI-MACS operations was terminated
in February, 2000 due to detection of very specific
software flaw in Microsoft SQL Server in version 6.5.
This software flaw is generating erroneous results
without any diagnostics in a course of such operations
with the Database which request to perform certain
sorting (ordering) of records in record sets selected
from the Database. Investigation of this software
flaw conducted in cooperation with LANL, lead
to conclusion that appearance of this software flaw
depends on format and amount of data selected from
the Database and on a type of hardware platform used.
Immediate consequences of appearance of this software
flaw is a violation of data integrity in the Database.
Following on consequences are 'disappearing' nuclear
material accounting data from an inventory. Such
'disappearing' may be detected for sure by manual
verification of the Database against source accounting
documents. No other technology is available.
7) Unfortunately, this software flaw was detected
in both 'International' version of SQL Server v. 6.5
KI is using, and 'original' U.S. version. Microsoft
did confirm a presence of such software flaw first
detected by KI.
8) SQL Server in version 7.0 which was recommended
by Microsoft for substitution of version 6.5, is considered
as not having the same type of software flaw. However,
at the end of July, 2000 KI has managed to detect
a severe software flaw in version 7.0 a presence of
which was confirmed by Microsoft. This flaw relates
to Database data protection features and under certain
conditions permits to get non-authorized access
to the Database.
9) The said above means that both Russian and
American sides has a very specific problem in CMAS
operating software of Microsoft production.
10) Working with LANL, KI has developed so-called
'pragmatic' approach to overcome this problem. At
the moment KI is completing development of a specific
technology and software which should provide detection
of yet discovered Microsoft software flaws and prevent
violation of data integrity and data security in CMAS
Databases developed with SQL Server in both versions
6.5 and 7.0. Upon completion this technology and sample
software will be provided to LANL for distribution
between the U.S. DOE sites concerned and will be provided
to Russian enterprises utilizing Microsoft SQL Server
DBMS. It is to be considered as a voluntary contribution
of KI into area of U.S.-Russia cooperation in MPC&A.
11) Relatively poor quality of Microsoft SQL Server
has created very serious problems in development and
implementation of CMAS. As for Russian side, such
quality of Microsoft software has delayed implementation
of CMAS for at least one year not saying about financial
and moral losses KI suffers. However, I believe, working
together we are capable to overcome this problem.
12) The best we are waiting from the Microsoft,
is to eliminate a source of detected SQL Server software
flaws, to provide all U.S. DOE and Russian nuclear
enterprises by error free copies of SQL Server and
to develop some mechanism of interaction with customers
which will provide reasonable assurance that such
systems of national security and secrecy concern as
CMASs will be 'privileged' customers of Microsoft.
Concluding my brief presentation of this very specific
problem to you, I would like to ask you:
- to consider this problem as a problem of political
concern related to very sensitive area of cooperation
between the U.S and Russia, and
- to take care about dissemination of this information
due to threat of misunderstanding by people who are
not well familiar with specifics of problems created
by Microsoft software in nuclear material control
and accounting.
Unfortunately, due to my business schedule I am
not able to come to St. Petersburg on September 20-24,
2000 to meet with you. In case of any questions, please,
do not hesitate to contact me.
Sincerely,
Alexander N. Rumyantsev, Ph.D.
KI Coordinator for MC&A Programs
Deputy director
Scientific and Technological Complex 'Electronics'
'Kurchatov Institute' Russian Research Center
7-(095)-196-9982 (voice), 7-(095)-196-4963 (fax)
[Alexander Rumyantsev was the lead investigator
for the following report that was sent by Kurchatov
to Los Alamos in February 2001. A short excerpted
version below is followed by the full report. Bblair]
KI RRC
Report No. 210.06-01/1
November 15, 2000
|
|
APPROVED BY: |
| |
Vice-president |
| |
'Kurchatov Institute' RRC |
| |
|
| |
N.N. Ponomarev-Stepnoy |
ADDITIONAL PROVISION FOR
DATA INTEGRITY AND DATA SECURITY
IN MICROSOFT SQL SERVER DATABASES
FOR CRUCIAL APPLICATIONS
|
Agreed by: |
Prepared by: |
|
Director |
Deputy director |
|
STC 'Electronics' |
STC 'Electronics' |
|
'Kurchatov Institute' RRC |
'Kurchatov Institute' RRC |
|
G.V.Yakovlev |
A.N.Rumyantsev |
ACKNOWLEDGMENTS
This report is based on results of intensive research,
development and testing works performed by staff of
the Division of Information Systems of the Scientific
and Technological Complex 'Electronics' of the ’Kurchatov
Institute’ Russian Research Center. Alexey V. Evstropov,
Dimitry M. Artamonov, Olga A. Kamaeva, Tatiana A.
Kamaeva, Andrey V. Korolev, Anatoly M. Pankratiev
are to be especially noted. Valuable contribution
to evaluation of detected MS SQL Server data integrity
and data security problems was brought by staff of
the U.S DOE Los Alamos National Laboratory including
S. Peter Gary, Benny J. Martinez, Harry Mac Forehand,
Jr., and by Barry Siskind from the U.S. DOE Brookhaven
National Laboratory. Deep gratitude is expressed to
all of them.
Trial operation of the KI-MACS at KI RRC was very
positive until September-October, 1999 when KI RRC
staff engaged into PIT activities began to report
about some failures and strange functioning KI-MACS
software. KI-MACS designers were unable to detect
reasons for such troubles due to very random nature
of such events - no systematic failures were detected.
Intensive additional testing of KI-MACS application
software core residing on the Server did not detect
sources for reported failures in KI-MACS application
software. However, results of especially developed
tests aimed onto verification of SQL Server 6.5 performance
did confirm the most worse expectations: treating
relatively large record sets from the Database the
Microsoft SQL Server in version 6.5 is capable to
produce on a random basis absolutely unpredictable
results leading to corruption of original accounting
data in the Database in a course of following on treatment.
By February 16, 2000 a source of this troubles
was detected. Especially developed tests did confirm
that a source of random errors is an error in execution
of the ‘SELECT’ with ‘ORDER BY’ (sorting by) statement
by the Microsoft SQL Server in version 6.5, and such
error is not provided by any SQL Server diagnostic.
Evaluated mean value for frequency of appearance the
said error is about 1.0e-03 per execution of ‘SELECT’
with ‘ORDER BY’ statement. Frequency of appearance
of such error depends on format of data used as a
search criteria in ‘WHERE’ clause of ‘SELECT’ statement,
amount of data being satisfying search criteria and
type of hardware platform. Highest failure rate was
detected for platforms with CPU frequency below 200
Mh and above 400 Mh. Additional tests were developed
in order to detect a systematic appearance of this
SQL Server 6.5 software flaw. These tests were constructed
in a such way that a presence of a flaw in the SQL
Server 6.5 has been proved for sure. Microsoft
did confirm a presence of this software flaw. This
flaw has been filed by Microsoft as flaw No. SRX000403600845.
Based on available information the problem has not
been resolved yet (November 2000). Microsoft have
proposed to substitute SQL Server in version 6.5 by
version 7.0 in which KI RRC developed tests transferred
to Microsoft, did not detect such problem.
Due to discovered and proved SQL Server 6.5 software
flaw all operations of KI-MACS system at KI RRC as
well as at Russian Navy sites, Murmansk Shipping Company,
and Mining and Chemical Combine at Zhelesnogorsk,
were suspended. Immediate consequence of this software
flow is that over the time of operation a computerized
material inventory in the Database is decreasing.
Because of nature of this software flaw leading to
undiagnosed corruption of original data in SQL Server
Databases, all accounting data accumulated in the
Databases were subject for manual verification against
source accounting documents.
In a course of transition of KI-MACS application
software core from version 6.5 to 7.0 and intensive
testing of the modified KI-MACS, at the end of
July, 2000 one more flaw has been detected in the
SQL Server 7.0. This flaw has been recognized by the
Microsoft and filed as flaw No. SRX000727603512.
Principal modifications introduced by the Microsoft
in SQL Server 7.0 which are relating to the data security
and data protection in a Database, and presence of
the said flaw, are considered as creating a direct
threat to data security and data protection in
the SQL Server 7.0 Databases.
FULL REPORT FOLLOWS:
KI RRC Report No. 210.06-01/1
November 15, 2000
APPROVED BY:
Vice-president
'Kurchatov Institute' RRC
N.N. Ponomarev-Stepnoy |
|
ADDITIONAL PROVISION FOR
DATA INTEGRITY AND DATA SECURITY
IN MICROSOFT SQL SERVER DATABASES
FOR CRUCIAL APPLICATIONS
| Agreed by: |
Prepared by: |
| Director |
Deputy director |
| STC 'Electronics' |
STC 'Electronics' |
| 'Kurchatov Institute' RRC |
'Kurchatov Institute' RRC |
| G.V.Yakovlev |
A.N.Rumyantsev |
MOSCOW
2000
ABSTRACT
This reports has been prepared for implementation
in collaborative efforts of the United States of America
and the Russian Federation aiming to improve and strengthen
a control of and accounting for nuclear material.
It summarizes an experience and know-how gained by
specialists of the ’Kurchatov Institute’ Russian Research
Center in an area of design and development of ‘near-real-time’
computerized nuclear material accounting systems with
implementation of Client-Server architecture and Microsoft
software products including MS Windows NT v. 4.0,
MS SQL Server in v. 6.5 and 7.0, MS Visual Basic v.
4.0 and 5.0, and MS Visual C++ v. 4.0. This report
is intended to assist system designers and software
specialists of both countries in providing the highest
possible level of data integrity and data security
in Databases of the computerized nuclear material
accounting systems in spite of presence of software
flaws in mentioned versions of SQL Server.
| CONTENT |
Page
|
| ABSTRACT
|
2
|
| ACKNOWLEDGMENTS
|
4
|
| PREAMBULE
|
5
|
| 1.
DATA INTEGRITY |
7
|
| 1.1.
Problem |
7
|
| 1.2.
Possible Solution of the Problem |
8
|
| 1.2.1.
Selection of record set in one-by-one sequence
without cursors |
9
|
| 1.2.2.
Selection of record set in one-by-one sequence
with cursors |
10
|
| 1.2.3.
Handling Transactions |
12
|
| 1.2.4.
Number of Cursors |
12
|
2.
SOME COMPATIBILITY PROBLEMS FOR SQL SERVER 6.5
AND
7.0 |
12
|
| 2.1.
Problems |
12
|
| 2.2.
DATALENGTH() function |
12
|
| 2.3.
System Tables |
13
|
| 2.4.
Cursor Declarations |
14
|
| 2.5.
Temporary Tables |
14
|
| 3.
DATA SECURITY |
14
|
| 3.1.
Problem |
14
|
| 3.2.
Possible Solution of the Problem |
15
|
| 4.
CONCLUDING REMARKS 16 |
|
ACKNOWLEDGMENTS
This report is based on results of intensive research,
development and testing works performed by staff of
the Division of Information Systems of the Scientific
and Technological Complex 'Electronics' of the ’Kurchatov
Institute’ Russian Research Center. Alexey V. Evstropov,
Dimitry M. Artamonov, Olga A. Kamaeva, Tatiana A.
Kamaeva, Andrey V. Korolev, Anatoly M. Pankratiev
are to be especially noted. Valuable contribution
to evaluation of detected MS SQL Server data integrity
and data security problems was brought by staff of
the U.S DOE Los Alamos National Laboratory including
S. Peter Gary, Benny J. Martinez, Harry Mac Forehand,
Jr., and by Barry Siskind from the U.S. DOE Brookhaven
National Laboratory. Deep gratitude is expressed to
all of them.
PREAMBULE
Since August 1994 in cooperation with the U.S. Department
of Energy (DOE) Los Alamos National Laboratory (LANL)
and within the frameworks of cooperative U.S.-R.F.
Lab-to-Lab program on improvement of material protection,
control and accounting (MPC&A) systems, the ‘Kurchatov
Institute‘ Russian Research Center (KI RRC) has been
developing and implementing a site-wide computerized
nuclear material accounting system with the aim to
improve nuclear material accountability and increase
a level of nuclear material security. Such computerized
systems related to national security issues are considered
as systems of ‘crucial assignment’. They must be developed
as extremely reliable man-machine systems. Key factors
determining system reliability are quality of operating
software environment created by Operating System (OS),
Database Management System (DBMS) and Programming
Systems (PS), and quality of functionally oriented
Application Software Packages (ASP) be assigned to
perform required system functionality.
With financial and intellectual support from the U.S.
DOE and its National Laboratories the KI RRC has developed
and, since 1998, has implemented a site-wide computerized
nuclear material accounting system. Implementation
of this system (named KI-MACS) has permitted to begin
with the very first in the history of Russian nuclear
complex an initial Physical Inventory Taking (PIT)
for all nuclear materials located at facilities of
the KI RRC. The KI-MACS system is the very first and
still unique Russian made system, which has been security
certified in Russian Federation to deal with classified
nuclear material accounting data. Due to unique functionality
the KI-MACS system was selected as a standardized
system for Russian Navy nuclear reactor fuel, for
the Murmansk Shipping Company managing the Russian
Arctic fleet of nuclear ice-breakers, and as a standardized
core of computerized accounting systems for a number
of enterprises managed by the Ministry of atomic energy
of Russian Federation. By the fall of 1999 the KI-MACS
system has been installed at 6 Russian Navy sites,
at the Murmansk Shipping Company and at the Mining
and Chemical Combine at Zhelesnogorsk.
The KI-MACS system is a hardware and software complex
which is based on implementation of PCs in a local
secure network with Client-Server architecture, and
which is performing near-real time material accounting.
The KI-MACS system is fully integrated with various
nuclear material measurement and bar code systems.
The operating software environment has been configured
by the operating system Microsoft Windows NT in version
4.0, Database Management System (DBMS) Microsoft SQL
Server in version 6.5, Microsoft Visual Basic in version
4.0 and Microsoft Visual C++ in version 4.0. The source
code of KI-MACS security certified application software
core residing on the Server and providing KI-MACS
functionality as well as information security, contains
5,296,975 characters of Transact SQL source code.
This software includes a source code of 709 Stored
Procedures, 20 Views, 145 Permissions, 77 Database
Tables.
Selection of the Microsoft software products mentioned
above and forming a ‘backbone’ of the KI-MACS, was
made with taking into consideration a positive experience
accumulated by the U.S. DOE Los Alamos National Laboratory
(LANL) and significant progress achieved by LANL and
other U.S. DOE enterprises in development and implementation
of the Local Area Network Material Accountability
System (LANMAS) being assigned as an unified and standardized
nuclear material accounting system for the U.S. DOE
National Laboratories and enterprises. The KI-MACS
system is based on utilization the same operating
software environment as the LANMAS and was designed
to cover practically all expected material control,
accounting and reporting needs for the most typical
enterprises of the Russian nuclear complex.
Trial operation of the KI-MACS at KI RRC was very
positive until September-October, 1999 when KI RRC
staff engaged into PIT activities began to report
about some failures and strange functioning KI-MACS
software. KI-MACS designers were unable to detect
reasons for such troubles due to very random nature
of such events - no systematic failures were detected.
Intensive additional testing of KI-MACS application
software core residing on the Server did not detect
sources for reported failures in KI-MACS application
software. However, results of especially developed
tests aimed onto verification of SQL Server 6.5 performance
did confirm the most worse expectations: treating
relatively large record sets from the Database the
Microsoft SQL Server in version 6.5 is capable to
produce on a random basis absolutely unpredictable
results leading to corruption of original accounting
data in the Database in a course of following on treatment.
By February 16, 2000 a source of this troubles was
detected. Especially developed tests did confirm that
a source of random errors is an error in execution
of the ‘SELECT’ with ‘ORDER BY’ (sorting by) statement
by the Microsoft SQL Server in version 6.5, and such
error is not provided by any SQL Server diagnostic.
Evaluated mean value for frequency of appearance the
said error is about 1.0e-03 per execution of ‘SELECT’
with ‘ORDER BY’ statement. Frequency of appearance
of such error depends on format of data used as a
search criteria in ‘WHERE’ clause of ‘SELECT’ statement,
amount of data being satisfying search criteria and
type of hardware platform. Highest failure rate was
detected for platforms with CPU frequency below 200
Mh and above 400 Mh. Additional tests were developed
in order to detect a systematic appearance of this
SQL Server 6.5 software flaw. These tests were constructed
in a such way that a presence of a flaw in the SQL
Server 6.5 has been proved for sure. Microsoft did
confirm a presence of this software flaw. This flaw
has been filed by Microsoft as flaw No. SRX000403600845.
Based on available information the problem has not
been resolved yet (November 2000). Microsoft have
proposed to substitute SQL Server in version 6.5 by
version 7.0 in which KI RRC developed tests transferred
to Microsoft, did not detect such problem.
Due to discovered and proved SQL Server 6.5 software
flaw all operations of KI-MACS system at KI RRC as
well as at Russian Navy sites, Murmansk Shipping Company,
and Mining and Chemical Combine at Zhelesnogorsk,
were suspended. Immediate consequence of this software
flow is that over the time of operation a computerized
material inventory in the Database is decreasing.
Because of nature of this software flaw leading to
undiagnosed corruption of original data in SQL Server
Databases, all accounting data accumulated in the
Databases were subject for manual verification against
source accounting documents.
In a course of transition of KI-MACS application software
core from version 6.5 to 7.0 and intensive testing
of the modified KI-MACS, at the end of July, 2000
one more flaw has been detected in the SQL Server
7.0. This flaw has been recognized by the Microsoft
and filed as flaw No. SRX000727603512. Principal modifications
introduced by the Microsoft in SQL Server 7.0 which
are relating to the data security and data protection
in a Database, and presence of the said flaw, are
considered as creating a direct threat to data security
and data protection in the SQL Server 7.0 Databases.
More over, a presence of the same problem in treatment
of ‘SELECT’ with ‘ORDER BY’ statements was detected
in SQL Server v. 7.0 by modified KI-MACS software
in which additional data integrity checks were incorporated.
However, evaluated mean value for frequency of appearance
the said error is about ten times less (1.0e-04) in
comparison with SQL Server v. 6.5.
In spite of significant differences between SQL Server
v. 6.5 and 7.0, a decision was made to modify KI-MACS
application software core in a such way which should
provide complete insensitivity of the KI-MACS to the
SQL Server version - either 6.5 or 7.0, - and practical
elimination of negative consequences of software flaws
in both version of SQL Server on data integrity and
data security in SQL Server application Databases.
The following sections of this report are presenting
approaches, technology and software assigned to achieve
the stated goals.
1.
DATA INTEGRITY PROVISION
1.1. Problem
In relational Databases with data relationship of
(1:N) and (M:N) type the most important requirement
to the Database Management System (DBMS) is to provide
assurance that all data satisfying certain criteria
of relationship are properly treated. It means that
if ‘N’ records in a specific table of relational Database
are subject for treatment due to relationship with
some record in some relational table, all of them
must be retrieved by DBMS from the Database for certain
treatment to be performed by application software.
If in stead of required ‘N’ records only ‘X’ are retrieved
(and ‘X’ <> ‘N’), and no warning diagnostics is provided
by DBMS, the Database integrity is destroyed and such
Database is out of meaningful utilization.
The following simplified test developed by KI RRC
in Transact SQL, is proving an existence of this problem
in MS SQL Server v.6.5. A table used for this test
is system table ‘sysobjects’ which contains a list
of references to stored procedures used as application
software for the Database. This list contains a number
of records with internally generated numeric 'id'
from minimal ‘Nmin’ to maximal ‘Nmax’ and 'type' which
equals 'P' (‘procedure’ type).
The
task is to get the record of 'P' type with the lowest
'id' value which is Nmin. Trivial solution of this
task is to find all records with 'type' = 'P' and
'id' exceeding some value which is less 'Nmin' and
then to sort them out in descending order. The very
first record in the sorted resulting list (results
set) will be with 'id' = 'Nmax' - with the highest
'id' value. The very last record in the same list
will be with 'id' = 'Nmin' - the lowest 'id' value.
By definition of SQL, an unique SELECT statement of
local variable assignment type which looks like ‘SELECT
@X = id’ where @X is a local variable, must return
as a result of treatment of the generated list (results
set) a value of 'id' which corresponds to 'id' of
the very last record in the results set. And this
assignment must be performed after completion of preparation
of the results set containing all records which meet
the WHERE clause and are sorted out in a prescribed
sequence. The prescribed sequence is the most simple
one - along numbers of ‘integer’ type.
The following test sample is confirming that the very
last record in the results set is used for assignment
of a value to the local variable:
1) Sample test 1.
DECLARE @X int, @T varchar (255), @R int
SELECT @X = id FROM sysobjects
WHERE id > 0 AND type = 'P'
ORDER BY id DESC
select @R = @@ROWCOUNT
/*** COMMENT: Printing our resulting value of @X and
@R ***/
select @T = 'Resulting value of @X = ' + convert(varchar,
@X)
PRINT @T
select @T = 'Number of records in data set @R = '
+ convert(varchar, @R)
PRINT @T
GO
It has to be expected that exactly the same result
would be obtained if in the WHERE in stead of statement
'id > 0' one is using any local variable with assigned
value which equals zero (0), for instance, using the
statement 'id > @X' where @X equals 0.
It means that exactly the same result must be obtained
by executing the following statements:
2) Sample test 2.
DECLARE @X int, @T varchar (255), @R int
select @X = 0
SELECT @X = id FROM sysobjects
WHERE id > @X AND type = 'P'
ORDER BY id DESC
select @R = @@ROWCOUNT
/*** COMMENT: Printing our resulting value of @X and
@R ***/
select @T = 'Resulting value of @X = ' + convert(varchar,
@X)
PRINT @T
select @T = 'Number of records in data set @R = '
+ convert(varchar, @R)
PRINT @T
GO
Executing this test 2, one can see that nothing similar
to expected result is performed in that case in practice.
This is the error in SQL Server 6.5.
However, if @X has a format which differs from ‘integer’,
for instance, such as ‘decimal(20,0)’, one can get
correct results running the following script:
3) Sample test 3.
DECLARE @X decimal(20,0), @T varchar (255), @R int
select @X = 0
SELECT @X = id FROM sysobjects
WHERE id > @X AND type = 'P'
ORDER BY id DESC
select @R = @@ROWCOUNT
/*** COMMENT: Printing our resulting value of @X and
@R***/
select @T = 'Resulting value of @X = ' + convert(varchar,
@X)
PRINT @T
select @T = 'Number of records in data set @R = '
+ convert(varchar, @R)
PRINT @T
GO
In all tests 1, 2, 3 number of records in resulting
data set is the same but values of @X are correct
in tests 1 and 3 only.
More sophisticated tests conducted by KI RRC did confirm
that execution of ‘SELECT’ with ‘ORDER BY’ statements
by SQL Server v.6.5 ‘randomly’ fails depending upon
format of data used in both SELECT and WHERE parts
of statements, number of records in resulting data
sets, and type of hardware used - CPU frequency, RAM
volume and type of HDD used. Minimal size of data
set with detected problems in execution of such statements
was 5 records. Maximal size of data set achieved in
a course of tests for detection these problems was
about 100 ths. records. This flaw was detected with
the highest frequency on PC with CPU 100-200 Mh and
400-500 Mh with RAM 32-64 Mb.
Evaluated mean value to get erroneous results in selection
of data sets satisfying certain search criteria is
about 0.001 per execution of a single ‘SELECT with
ORDER BY’ statement.
1.2.
Possible Solution of the Problem
The following are proposals by implementation of those
one can decrease or even eliminate an influence of
SQL Server v.6.5 flaw on data integrity in the Database.
All of them are based on examination of SQL Server
performance by check a number of records in resulting
data set before real treatment and after. Their structure
depends on techniques used for record selection -
either without cursors or with cursors. All examples
are presented for ‘sysobjects’ table in SQL Server
Database for demonstration of technology only.
1.2.1. Selection of record set in one-by-one sequence
without cursors
In
stead of construction:
DECLARE @X int, @T varchar (255), @R int
select @X = 0
select @R = 0
GET_NEXT:
SELECT @X = id FROM sysobjects
WHERE id > @X AND type = 'P'
ORDER BY id DESC
IF @@ROWCOUNT <> 0
BEGIN
select @R = @R + 1
GOTO GET_NEXT
END
/*** COMMENT: Printing our resulting value of @R***/
select @T = 'Number of treated records in data set
@R = ' + convert(varchar, @R)
PRINT @T
GO
the following is recommended:
DECLARE @X int, @Y int, @T varchar (255), @R int,
@RC int, @R_Expected int
select @X = 0
SELECT @X = id FROM sysobjects
WHERE id > @X AND type = 'P'
select @R_Expected = @@ROWCOUNT
select @X = 0
select @R = 0
GET_NEXT:
SELECT @Y = id FROM sysobjects
WHERE id > @X AND type = 'P'
ORDER BY id DESC
select @RC = @@ROWCOUNT, @X = @Y
IF @RC <> 0
BEGIN
select @R = @R + 1
GOTO GET_NEXT
END
/*** COMMENT: Comparison expected and real number
of records in data set ***/
IF @R <> @R_Expected
BEGIN
select @T = ‘Error in number of records treated: Expected
= ‘ +
convert(varchar, @R_Expected) + ‘ # Treated = ‘ +
convert(varchar, @R)
PRINT @T
RETURN
END
ELSE
BEGIN
/*** COMMENT: Printing our resulting value of @R***/
select @T = 'Number of treated records in data set @R = ' + convert(varchar, @R)
PRINT @T
END
GO
Running both tests one can see a difference in results.
1.2.2. Selection of record set in one-by-one sequence
with cursors
In
stead of construction:
DECLARE @X int, @T varchar (255), @R int,
@Fetch_Status int, @Fetch_Number int
select @X = 0
DECLARE
Record_List SCROLL CURSOR FOR
SELECT id FROM sysobjects WHERE id > @X AND type =
'P'
ORDER BY id ASC
select @R = 0
/*** Open CURSOR and define Number of Records ***/
OPEN Record_List
NEXT_RECORD:
FETCH NEXT FROM Record_List INTO @X
select @Fetch_Status = @@fetch_status
IF @Fetch_Status = 0
BEGIN
select @R = @R + 1
GOTO NEXT_RECORD
END
select @T = 'Case 1: Number of records selected and
treated is ' + convert(varchar, @R)
PRINT @T
CLOSE Record_List
DEALLOCATE Record_List
GO
the following is recommended:
DECLARE @X int, @Y int, @T varchar (255), @R int,
@R_Expected int,
@Fetch_Status int, @Fetch_Number int
select @X = 0
/** Define number of records by direct search **/
SELECT @Y = id FROM sysobjects WHERE id > @X AND type
= 'P'
select @R_Expected = @@ROWCOUNT
DECLARE
Record_List SCROLL CURSOR FOR
SELECT id FROM sysobjects WHERE id > @X AND type =
'P'
ORDER BY id ASC
select @R = 0
/*** Open CURSOR and define Number of Records ***/
OPEN Record_List
select @Fetch_Number = @@CURSOR_ROWS /** Number of
Rows in the Record Set **/
IF @Fetch_Number <> @R_Expected
BEGIN
select @T = 'Error: number in data set is ' +
convert(varchar, @Fetch_Number) +
', but expected number is ' + convert(varchar, @R_Expected)
PRINT @T
GOTO EXIT_OUT
END
NEXT_RECORD:
FETCH NEXT FROM Record_List INTO @Y
select @Fetch_Status = @@fetch_status
IF @Fetch_Status = 0
BEGIN
select @R = @R + 1
GOTO NEXT_RECORD
END
IF @R <> @R_Expected
BEGIN
select @T = 'Error: number of records selected is
' + convert(varchar, @R) +
', but expected number is ' + convert(varchar, @R_Expected)
PRINT @T
GOTO EXIT_OUT
END
select @T = 'Case 2: Number of records selected and
treated is ' + convert(varchar, @R)
PRINT @T
PRINT '### Happy End ###'
EXIT_OUT:
CLOSE Record_List
DEALLOCATE Record_List
GO
It has to be noted that implementation of function
COUNT(*) for determining a number of records in a
set satisfying certain search criteria stated in WHERE
part of SELECT statement, is not recommended. Direct
use of @@ROWCOUNT global variable is considered as
more reliable solution. Modified KI-MACS application
software core in which the said above additional check
capabilities were incorporated, is periodically detecting
the same ‘SELECT with ORDER BY’ problems in SQL Server
v.7.0. However, a frequency of appearance of such
problem is about 10 times less - about 0.0001 per
single execution of such statement on PC’s used at
KI RRC for computerized material accounting system.
1.2.3. Handling Transactions
Implementation of the proposed Transact SQL constructions
require to organize transaction handling mechanisms
in a such way that all modifications of data sets
selected by implementation of ‘SELECT’ with ‘ORDER
BY’ statements should be located within the same transaction.
In case of detection of discrepancies between expected
and real number of treated records the whole transaction
should be rolled back and execution of the task should
be repeated. Corresponding restart functionality is
to be provided in both application software and data
structures.
1.2.4. Number of Cursors
Base on lessons learned a number of cursors be opened
for treatment of data sets forming a single logical
transaction, should not exceed one.
2. SOME COMPATIBILITY PROBLEMS FOR SQL SERVER 6.5
AND 7.0
2.1. Problems
Due
to innovations introduced by Microsoft in SQL Server
v. 7.0, this software product is only partially compatible
with previous SQL Server v. 6.5. Detailed description
of many incompatibilities is presented in accompanying
SQL Server v. 7.0 document ‘Microsoft SQL Server.
Introduction. SQL Server, including OLAP Services’.
Many of innovations are very positive such as elimination
of needs to perform manual fragmentation and management
of a disk space. Remarkable is a short note on page
15 of the said above document: ‘Earlier versions of
SQL Server employed no more than one index per table
in a query’ as a reminder to Database designers that
increase of a number of indexed data elements (column
names) for a table in previous versions of SQL Server
was practically meaningless from point of view of
increasing SQL Server productivity. Documentation
for SQL Server 6.0 and 6.5 does not mentioned this
peculiarity of ‘earlier’ versions.
However, there are a number of additional compatibility
problems which are not covered by the said above document.
Some of them are presented below.
2.2. DATALENGTH() function
No problems in use of DATALENGTH(‘string’) function
for definition of length for variable length string
of varchar() type were detected for SQL Server v.
6.5.
However, using this function in SQL Server v. 7.0
one have to be prepared to deal with erroneous results
- real length is sometimes less than defined by the
function, - if the string in question is passed as
a parameter through a number (two and more) of sequential
calls to procedures.
For instance, if data treatment process is organized
as presented below - stored procedure ‘SubA’ assigns
certain value to variable length string @Text and
define its length @L, then calls stored procedure
‘SubB’, which in turn calls stored procedure ‘SubC’
where a length of @Text is defined once more:
/*** Body of stored procedure ‘SubA’ ***/
DECLARE @Text varchar(255), @L int, ...
Select @Text = ‘........’ /*** Some text of certain
length is to be stated here ***/
Select @L = DATALENGTH(@Text) /*** Initial length
is defined ***/
...
EXEC SubB ..., @Text, @L, ...
/*** Body of stored procedure ‘SubB’ ***/
CREATE PROCEDURE SubB ..., @Text varchar(255), @L
int, ...
.....
EXEC SubC ..., @Text, @L, ...
/*** Body of stored procedure ‘SubC’ ***/
CREATE PROCEDURE SubC ..., @Text varchar(255), @L
int, ...
AS
DECLARE
@New_L int
...
select @New_L = DATALENGTH(@Text)
IF @New_L <> @L
BEGIN
PRINT ‘Length of @Text has been changed’
RETURN
END.
than sometimes one can get a message ‘Length of @Text
has been changed’
If definition of real length of variable length string
is crucial for application software, the most reliable
solution for this problem is to put at the end of
string in a course of its development some special
symbol like ‘#’, and than to define the real length
by direct search for this symbol and calculating its
position in the string.
2.3.
System Tables
Due to implementation of ‘unicode’ format for a number
of columns in system tables such as ‘sysusers’ and
‘syslogins’, which may be used for user’ identification
instead of statements like that:
SELECT sysusers.uid “UserID”,
sysusers.name “UserName”,
sysusers.suid “LoginID”,
ISNULL(master.dbo.syslogins.name, ‘ ‘) “LoginName”
FROM sysusers, master.dbo.syslogins
WHERE sysusers.suid > 0 AND master.dbo.syslogins.suid
= sysusers.suid
the following is recommended for both SQL Server v.
6.5 and 7.0:
SELECT sysusers.uid "UserID",
convert(varchar(128),sysusers.name) "UserName",
sysusers.suid "LoginID",
convert(varchar(128), ISNULL(master.dbo.syslogins.name,''))
"LoginName"
FROM sysusers, master.dbo.syslogins
WHERE sysusers.suid > 0 AND master.dbo.syslogins.suid
= sysusers.suid
2.4. Cursor Declarations
In SQL Server v. 6.5 an assignment of certain value
to a variable used in ‘SELECT’ statement for a ‘CURSOR’
may be performed after declaration of the ‘CURSOR’
but before opening cursor by ‘OPEN’ statement.
In SQL Server v. 7.0 all assignments for all variables
used in ‘SELECT’ of ‘CURSOR’ statement must be performed
before declaration of the ‘CURSOR’.
2.5. Temporary Tables
Local temporary tables created by statements like
‘CREATE TABLE #Test’ are supposed to belong to the
stored procedure which creates it, and to be dropped
at the end of execution of the stored procedure in
which they have been created. Dropping is initiated
either by execution of statement like ‘DROP TABLE
#Test’ or by exit from the stored procedure where
temporary table was created.
However, if a number of end-users requesting services
provided by the same set of stored procedures in which
temporary tables are created, used and then dropped,
exceeds one then sometimes some of the temporary tables
are not dropped thus preventing creation of temporary
tables with the same name by the same concurrently
used stored procedures. This software flaw has been
detected in both SQL Server v. 6.5 and 7.0. However,
in SQL Server v. 7.0 frequency of such event is higher
in comparison with SQL Server v. 6.5.
It is recommended NOT to use any temporary tables
and substitute them by ordinary tables in which currently
used stored procedure create (add) and, at the end
of execution, delete all records (rows) this procedure
is required. As a key for such record set some user
ID may be used providing unique identification for
records to be created and then deleted from the table
for a given user in the call to the given stored procedures.
3.
DATA SECURITY PROVISION
3.1. Problem
SQL
Server v.6.5 is provided by two different data security
mechanisms - so-called ‘integrated security’ in which
all end-user authentication is performed by Windows
NT authentication mechanism with following on utilization
of ‘trusted connection’ with SQL Server, and so-called
‘standard security’ which provides additional to and
relatively independent from Windows NT authentication
capabilities for Database end-users. In case of implementation
of ‘standard security’ the end-user authentication
scheme presents an ‘AND’-type logic of end-user authentication:
Windows NT AND SQL Server. The third authentication
scheme for SQL Server 6.5 - so-called ‘mixed security’,
- is performing end-user authentication with use of
‘OR’ logic - if there is no explicitly stated utilization
of ‘standard security’ an end-user is practically
free to select either Windows NT authentication only,
or to perform one more Login with password for SQL
Server. It is a reason not to account for the ‘mixed
security’ as for the third end-user authentication
mechanism. Implementation of ‘standard security’ be
supplemented by corresponding administrative measures
as well as end-user identification and check mechanism
incorporated into SQL Server application software,
was considered as sufficient to provide data security
required in case of treatment of highly confidential
nuclear material accounting data.
However, SQL Server v. 7.0 has no ‘standard security’
capabilities. In addition to that SQL Server v.7.0
has a very specific software flaw detected in its
Login mechanism by KI RRC tests. It has been learned
that if System Administrator (SA) has no password
(blank field) in SQL Server 7.0, then everybody may
come as SA with all SA rights if one calls, for instance,
the 'SQL Query Analyzer', then select 'Use SQL Server
authentication' and type in the field 'Login Name'
the combination of symbols 'SA;' - letters S and A
followed by semicolon. In this case one will get successful
'Login'. In means that SQL Server 7.0 can not properly
identify a difference between user names 'SA' and
'SA;' as Windows NT does. Nothing similar has been
detected in SQL Server 6.5. From point of view of
data security it may mean that certain combinations
of symbols in 'Login name' are reserved for unauthorized
access to the Database with SA rights to deal with
data. As it was mentioned above, this flaw has been
filed by Microsoft.
The most important feature of data security mechanism
is an ability to provide for sure unique identification
for any end-user. Any end-user who are trying to interact
with the Database, must be uniquely identified. Introduction
into SQL Server v.7.0 a built-in System Administrator
Group, the members of which may act under the same
‘SA’ Login name and under the same System and Database
ID’s leads to direct violation of the most important
rule to be observed in data security policy - absolute
requirement to provide unique identification of end-user
trying to interact with the Database.
3.2. Possible Solution of the Problem
Solution of this problem equally applicable for both
SQL Server v.6.5 and 7.0 has been developed and incorporated
into KI-MACS software in the current version 5.0.
The most important details of this mechanism are presented
in the KI-MACS documentation ’KI-MACS. Guidelines
for information security’.
This document is a part of KI-MACS documentation and
may be provided in a course of KI-MACS installation
at the site.
3. CONCLUDING REMARKS
Due to detection of MS SQL Server software flaws preventing
continuation of trial operations of KI-MACS at KI
RRC as well as at a number of Russian nuclear enterprises,
KI-MACS designers and programmers have modified the
KI-MACS application software core residing on a Database
Servers. Basic provisions for performed modifications
are presented in this report.
Modified version of KI-MACS application software core
in v. 5.0. includes over 800 Transact SQL stored procedures,
140 relational tables, 19 views and 170 permissions
to execute stored procedures by 10 end-user functionally
different application interfaces residing on Workstations
and developed with use of Visual Basic v.4.0 and 5.0,
and Visual C++, v.4.0. Length of Transact SQL source
code exceeds 6,5 mln bytes. After completion of intensive
testing, the modified KI-MACS software was transferred
in November, 2000 for additional data security certification
to the Russian State Technical Commission under the
President of Russian Federation.
Among many lessons learned in a course of evaluation
of reasons and consequences of events happened with
KI-MACS, one should be especially noted. Taking into
consideration basic provisions of probabilistic risk
evaluation approach, it may be stated that the most
probable source of detected operating software problems
is the so-called ‘common fault failure’ - implementation
of functionally different and very complex operating
software products produced by the same manufacturer
(Microsoft) with probable utilization of not declared
functionality of these products, first of all, in
operating system Windows NT. Any software product
sooner or later becomes obsolete and needs to be substituted
by advanced products. In a course of follow on development
of next generation of computerized nuclear material
accounting systems much more care should be taken
about selection of software products forming an operating
environment for such systems of national and international
security concern.
END OF REPORT
[The following emails
involving Kurchatov, Los Alamos, Microsoft and other
parties illuminate various aspects of the problem
and the reactions of various people/organizations.
BBlair]
A. From Rumyanstev to CP
(July 25, 2000):
Please, consider this E-mail is a continuation of
the previous one (dated July 24, 2000) with preservation
of section numbering: 6) In a course of the 41-st
INMM Annual Meeting (July 17-21, 2000, New Orleans,
Louisiana) I was requested by both Peter Gary (LANL)
and Parker O'Shell (DOE HQ, who is supervising all
U.S. DOE National Lab activities related to cooperation
with Kurchatov Institute and this week is visiting
Kurchatov Institute) to have a meeting with two representatives
of General Accounting Office (GAO). The first
one was Julie Hirshen (she is a Senior Evaluator,
GAO San Francisco Office, Tel: (415) 904-2290, Fax:
(415) 904-2111, E-mail: hirshenj.sfro@gao.gov <mailto:hirshenj.sfro@gao.gov>).
The second one was a young gentlemen from the GAO
Washington Office but, unfortunately, at the moment
I am not able to find his ID card. Meeting occurred
on July 18, 2000 (afternoon) with presence of both
GAO representatives, Peter Gary and Parker O'Shell.
It lasted for about 3 hours. Both GAO representatives
had been informed about a problem in Microsoft SQL
Server software but were eager to learn it from the
first hands. I told them the story with explanation
of inevitable consequences for a computerized material
inventory due to detected SQL Server software flaw
- the inventory is always decreasing over a time due
to random appearance of such flaw. Both made a
lot of hand writings. Peter Gary and Parker O'Shell
helped me in explanation of the most complex issues
when my professional jargon created some difficulties
in understanding for GAO representatives. I was not
asked about your involvement in that case but as I
understood, GAO representatives were informed about.
No conclusion or final statement was made by them.
They just collected facts and opinions. They are going
to visit Kurchatov in September, 2000 as members of
GAO team evaluating Kurchatov performance in contracts
with the U.S.DOE National Labs.
7) Peter Gary (LANL) who is the US leader in
the Joint US/Kurchatov Project Team, told me he is
still keeping money (about $40,000) he requested form
DOE HQ in March, 2000 in order to finance Kurchatov
staff efforts to overcome the SQL Server problem and
to restore KI-MACS functionality. In spite of
our current financial difficulties I refused this
proposal in March, 2000 because of two reasons: a)
it is not reasonable to ask DOE to pay for overcoming
a problem developed by poor quality Microsoft software
product, and, the most important, b) proposed funding
is insignificantly small in comparison with moral
and financial losses for Kurchatov and, by the way,
for the U.S. DOE. We have managed to develop and implement
a specific technology for verification of data and
application software integrity in the SQL Server Database,
for detecting SQL Server flaws, and to modify KI-MACS
application software in a such way that at present
the KI-MASC system safely operates (test data only)
on both SQL Server in versions 6.5 and 7.0. These
works were financed by Kurchatov only. However, during
the said INMM meeting Peter Gary asked me to reconsider
my previous 'NO' to his proposal. He is eager to provide
Kurchatov by the said above $40K in a form of LANL-KI
contract which may be titled as 'Development and implementation
of data integrity verification technologies for SQL
Server Databases used in a computerized material accounting
systems'. I told him it must be carefully evaluated
and I will inform him about Kurchatov answer later
on. Today I have discussed this issue with Nicolay
Nicolaevich and I was told to present this case to
you and ask your advice. My evaluation is as follows:
a) proposed $40K is a tiny fraction of a real
cost for 'know-how' on providing data integrity verification
technology for SQL Server Databases we are possessing,
b) it may be interpreted as a 'bribe' from LANL
and the U.S. DOE with the aim to keep 'mouth closed',
and c) an overall scale of moral and financial losses
due to discovered software problem as well as imaginary
or real threats to national and international security
is far exceeding proposed $40K. What is your opinion
about this case and your advice on how Kurchatov has
to act?
With best regards,
Alexander
B. From Rumyantsev to CP (July 31, 2000):
1) Since my last E-mail (July 25, 2000) a number
of events related to the Microsoft SQL Server story
happened. However, all of them are connected with
the newest SQL Server in version 7.0. Attachment to
this E-mail contains copies of my E-mail to Los Alamos
(July 26, 2000) and Los Alamos response (July 28,
2000) provided by a copy of E-mail from Microsoft
to LANL.
2) A new and very specific flaw in SQL Server
7.0 has been recently detected by Kurchatov. Microsoft
has confirmed a presence of the flaw and filed it
under Ref. No. SRX000727603512 (see attached copies
of E-mails).
3) To my opinion such flaw is much more dangerous
than the previously detected flaw in 'ORDER BY' statements.
The last one in both SQL Server 6.5 and 7.0 is corrupting
data in the Database. But, once learned about it,
we have developed a specific data integrity verification
technology which permits us to run safely our KI-MACS
system on both SQL Server 6.5 and 7.0. However, the
first one is an evidence of very specific and dangerous
gaps in the SQL Server 7.0 data security and data
protection mechanisms.
4) In order to evaluate it, let me describe some
important SQL Server data security and data protection
features. The so-called 'System Administrator' (SA)
in SQL Server is an unique person who has all rights
to do everything in the Database. No data security
and data protection mechanism exists in SQL Server
against actions of SA. It means that access to a Database
as SA must be checked and verified by all means possible.
Any user including all Database users, who is not
SA, must not be provided by even theoretical opportunities
to simulate SA.
5) In SQL Server 6.5 three schemes for user authentication
(except SA) are used: 'Trusted connection', 'Mixed
security' and 'Standard security'. 'Trusted connection'
means that any registered Windows NT user is considered
as SQL Server user. 'Mixed security' means that both
Windows NT and SQL Server authentication schemes are
applied and user is free to select one of them to
access a Database. 'Standard security' uses SQL Server's
own login validation process for all connections.
To log in to a SQL Server 6.5, each user must provide
a valid and unique login ID and password. Implementation
of 'Standard security' means that in order to perform
unauthorized access to a Database an intruder must
simulate both Windows NT AND (let me underline it)
SQL Server 6.5 login ID and passwords. A probability
for intruder to succeed is a product of probability
to simulate Windows NT login ID and password, and
probability to simulate SQL Server 6.5 login ID and
password. In our computerized nuclear material accounting
KI-MACS system which has been security certified in
Russia to deal with up to 'Top Secret' data, the only
'Standard security' is implemented.
6) In SQL Server 7.0 some 'enhancements' in data
security and data protection have been introduced.
As it is said in the documentation on SQL Server 7.0
'The security architecture is better integrated with
Windows NT and provides increased flexibility' (see
'Microsoft SQL Server. Introduction' , p. 28). In
stead of three data security modes the only two have
been left in version 7.0 but were modified: 'Windows
NT Authentication Mode' which looks like the 'Trusted
connection', and 'Mixed Mode' which looks like 'Mixed
security' in SQL Server 6.5. When we discussed
this issue with LANL (March-April, 2000), a Microsoft
specialist on request by LANL explained in written
(I have a copy of this explanation done as E-mail
to LANL) that SQL Server 7.0 'Mixed Mode' in version
7.0 is practically the same as a 'Standard security'
in version 6.5. We have checked it. It is not true.
My evaluation of the case described in my E-mail to
LANL as of July 26, 2000 (see Attachment) is different
- 'From point of view of data security it may mean
that certain combinations of symbols in 'Login Name'
are reserved by Microsoft for unauthorized access
to the Database with SA rights to deal with data.'
7) Thus we have very specific situation:
a) SQL Server 6.5 contains a flaw recognized by
the Microsoft; until now the Microsoft has not been
able to find a source of this flaw which corrupting
data in the Database thus preventing use of 6.5 in
industrial applications without implementation of
a specific data integrity verification technology
we have developed; however, the data security and
data protection mechanisms in 6.5 are sufficient to
implement 6.5 for treatment of highly classified data
as it was proved by independent evaluation performed
by Russian Gostechcommission which provided us by
security certificate for our KI-MACS system be operated
with SQL Server 6.5; AND
b) SQL Server 7.0 being considered by the Microsoft
as 'error free' at least in relation to simplified
tests for 'ORDER BY' statements developed by Kurchatov
Institute and provided to the Microsoft through LANL,
contains a flaw being recognized by Microsoft; presence
of the said flaw practically eliminates ANY data security
in SQL Server 7.0 Databases; everybody who runs SQL
Server 7.0, must know about such problem we recently
managed to detect and prove.
8) I believe you can evaluate presented above. I
recall that in accordance with the U.S. Presidential
Directive No. PDD-63 dated May 22, 1998 (with reference
to the Russian newspaper 'Independent Military Survey',
No. 24, 2000) the U.S | 
