CDI Headlines Hot Spots Research Topics CDI Publications Television Radio Public Affairs Search
CDI Mission CDI Staff CDI Expertise Paid CDI Internships Support CDI
 
CDI Home
 
Nuclear Issues Home Page      

CDI Home
 
Hot Spots
 
CDI Research Topics
 
Defense Monitor
 
Weekly Defense Monitor
 
CDI Russia Weekly
 
Asia Forum
 
Video Documentaries
 
Radio Broadcasts
 
Nuclear
 
Missile Defense
 
Military Reform Project
 
Quadrennial Defense Review
 
Military Spending
 
Peacekeeping Citation Lists
 
European Defense
 
Aviation
 
Landmines
 
Child Soldiers
 
Public Affairs
 
About CDI
 
Support CDI
 
 
Nukes: A Lesson From Russia

Supporting Documentation

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