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. governmental agencies as well as private companies must take care about providing the most secure conditions for storage and treatment of data considered significant for national security. It is hard to believe that nobody in Microsoft is familiar with this document. I believe the U.S. DOE (as LANL a week ago) is unaware about the problem described above. 9) To-day we discovered one more problem in data security provided by SQL Server 7.0, which relates to possibility for intruders to simulate SA access over networks. I sent E-mail to LANL asking to evaluate the case and ask Microsoft. My guess is either it is a result of our ignorance about SQL Server 7.0 security functionality (I can not exclude such option), or this is an additional flaw being incorporated into the so-called International version of SQL Server 7.0 we are using, or it is one more Microsoft flaw in both International and original versions. Let us wait with this additional case until completing evaluation of this flaw by LANL and Microsoft. However, this additional case may or may not add some details to the picture presented above without changing the picture as a whole. I will keep you informed. With best regards, Alexander ATTACHMENTS: the said above copies of E-mails: /******* First E-mail from Kurchatov to LANL *******/ To: bjmartinez@lanl.gov Cc: pgary@lanl.gov , hforehand@lanl.gov Forehand, Jr.>, siskind@bnl.gov From: anr@electronics.kiae.ru Subject: SQL Server 7.0 - two more problems Date: July 26, 2000 Benny, In addition to previously detected problems in providing information security for the KI-MACS system due to differences in information security mechanism for SQL Server 7.0 and SQL Server 6.5, the following is to be noted: 1) We learned that under specific conditions the stored procedure execution permission checks in SQL Server 7.0 do not work properly and they allow access when access is forbidden. Fortunately, it was recently detected by Microsoft and you may get a fix from the WEB-site of the Microsoft 'Product Support Service' dated July 07, 2000 under the title: 'FIX: Temporary Stored Procedures in SA Owned Databases may Bypass Permission Checks When You Run Stored Procedures'. We were lucky to detect it in a course of on-going security certification of KI-MACS system and pleased to get timely response from Microsoft. 2) We learned that if SA has no password (blank field) in SQL Server 7.0, then everybody may come as System Administrator (SA) with all SA rights if you call, 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. You will get successful 'Login'. In means that SQL Server 7.0 can not properly identify a difference between user names 'SA' and 'SA;'. Nothing similar is detected in SQL Server 6.5. As it happened in February, 2000, my first guess is this occurs in International version of SQL Server 7.0 we are using. 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. May I ask you to check presented in section 2) with original version of SQL Server 7.0 and ask Chad Mattox from Microsoft (MCSE, SQL Support Professional, (704) 582-8961, E-mail: chadmat@microsoft.com ) to evaluate this case. Thank you, Alexander /******* LANL Response to Kurchatov *******/ From: Benny J. Martinez mailto:bjmartinez@lanl.gov>> To: 'Alexander Rumyantsev' mailto:anr@electronics.kiae.ru>> Cc: Peter Gary mailto:pgary@lanl.gov>>; Mac Forehand mailto:hforehand@lanl.gov>>; Barry Siskind mailto:siskind@bnl.gov>> Subject: FW: Email for Case SRX000727603512 Date: Friday, July 28, 2000 7:49 PM Alexander, Microsoft has confirmed that SQL Server 7.0 strips out the ";" anywhere in the LoginID. SQL Server 6.5 does not allow ";" in the LoginID and notified you if entered it. It is still unclear what Microsoft is going to do about it. I will keep you posted. Benny -------------------------------------------------------------------------------------------- -----Original Message----- From: Rand Boyd [SMTP:randb@MICROSOFT.com] Sent: Friday, July 28, 2000 9:22 AM To: 'bjmartinez@lanl.gov' Subject: Email for Case SRX000727603512 ******* The following is an email for an incident from Microsoft Corp. ******* So that your reply is added to the case, please forward your ******* response to email address COMPMAIL@MICROSOFT.COM ******* and place your text after the keyword MESSAGE: below. ******* Please delete all other text above & below the keywords ******* CASE_ID_NUM: SRnnn & MESSAGE: . ******* Thank you. CASE_ID_NUM: SRX000727603512 MESSAGE: ********************** The message for you follows ************************ Benny, Per our conversation: It appears that the ";" in "sa:" is being stripped off before the login id gets sent to SQL Server. I do not know if it is occurring in the application or in the ODBC layer. My thinking is the ODBC layer. I am not sure if this is expected behavior or not. Books on line indicates that any character except and "\" can be used in a login id. However SQL Server 6.5 does not allow a ";" in the login id. So I am not sure where the real problem lies. Either way a ";" cannot be used in a login id. We are interested in any feedback you might have about the service you received on this incident. You can send feedback to Microsoft Management at mailto:managers@Microsoft.com?subject=DSSQLFB_Feedback&body=Rue %20Moody <mailto:managers@Microsoft.com?subject=DSSQLFB_Feedback&body=Rue %20Moody> or directly to my manager, Rue Moody, at ruem@Microsoft.com . If you don't use the enclosed mailto, make sure the keyword DSSQLFB_Feedback is in the title or body of messages sent to managers@microsoft.com <> . This will assure your message is routed quickly and accurately. Sincerely, Rand Boyd (469) 775-7272 ***********************************************************************   C. From Rumyantsev to CP (Aug. 3, 2000): 1) We got Microsoft response about our recent 'discovery'. All relevant E-mails -TO- and -FROM- are in the annex to this E-mail. I will not repeat conclusions presented there. 2) The most important general conclusion is that SQL Server 7.0 provides potentially less secure environment than 6.5. In other words, in stead of explicit two information security barriers in 6.5 (Windows NT user authentication be managed by Windows NT domain administrator (DA) and independent SQL Server user authentication be managed by SQL Server Database System Administrator (SA) - 'two man rule' to be strictly observed in information systems of security and secrecy concern), created by means of so-called 'Standard Security', the SQL Server 7.0 provides the only one barrier be managed by DA. SA may still manage low level users of SQL Server who are not users with administrative privileges in Windows NT. However, without sufficient knowledge about these SQL Server 7.0 features and without additional efforts, the SA is practically helpless to prevent an intrusion into the Database for such Windows NT users who, by the way, by default are acting under 'SA' ID which provides a 'cover' for unauthorized access. 3) Because DOE sites which (if any) are implementing SQL Server 7.0 to run LANMAS or similar systems, may have no idea about such information security features in SQL Server 7.0 and a presence of a flaw the KI has detected and Microsoft confirmed, I believe this is a time to inform them about the whole picture as it is. Due to timely discovery of the said security features in version 7.0, Kurchatov and other Russian nuclear sites utilizing SQL Server, are in relative information safety. I have no idea how it looks from the DOE point of view. But at least DOE is to be aware about. 4) It seems to me we have an almost complete picture for the Russian side. We have to modify KI-MACS system making it insensitive to detected and not yet detected Microsoft flaws and information security gaps in SQL Server, to perform additional Russian state security certification and to introduce KI-MACS into operations at all sites where it has been or will be installed. Now we know how to do it, and where Microsoft 'traps' are located. Kurchatov may help others to overcome the problem. 5) Recently I was told by some officials from the Russian State Technical Commission (GosTechCommission) under the President of RF (GosTechCommission is the highest Russian State Agency responsible for information security in Russia), who are involved in the on-going additional security certification of KI-MACS system, that the whole story looks like an intentional action of the Microsoft against national security of both the U.S. and R.F. I told them I believe it is not. However, this story is a very sad story for both sides. 6) In a course of INMM Annual Meeting in New Orleans I was told by representatives of Nuclear Assurance Corporation (NAC International), which is operating the Nuclear Materials Management and Safeguards System (NMMSS) for the DOE and NRC, that its current version is based on FoxPro Database Management System (DBMS) (to my opinion - very obsolete but sufficiently reliable). Based on results of evaluation the NAC has recently completed, the next generation of NMMSS will be developed on the Oracle DBMS but not on Microsoft SQL Server. 7) I believe the story is coming to the 'Happy End'. But I have no idea that 'Happy End' means except restoration of KI-MACS functionality and operating status we are doing. No additional discoveries of flaws and gaps in Microsoft SQL Server to be expected every day, can change the picture - selection of the Microsoft SQL Server as a backbone for computerized nuclear material accounting systems was a big error for both sides. But we have to overcome this problem with positive results as both sides managed to overcome much more significant problems in the past creating their nuclear potentials. With best regards, Alexander ANNEX E-MAIL COPY No. 1 ################## To: bjmartinez@lanl.gov Cc: pgary@lanl.gov , hforehand@lanl.gov , siskind@bnl.gov From: anr@electronics.kiae.ru Subject: SQL Server 7.0 - two more problems to the previously detected Date: July 31, 2000 Benny, Thank you for evaluation of SQL Server 7.0 problems indicated in my E-mail dated July 26, 2000 and transferring copy of the Microsoft response. Microsoft response is disappointing. However, there are two more problems in addition to the previously detected (numbering scheme continues the previous one in my E-mail as of July 26, 2000): 3) We learned that if SA has no password (blank field) in SQL Server 7.0, then everybody may come as System Administrator (SA) with all SA rights if you call, 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 blank field (in stead of semicolon as it was used in test (2) presented in my previous E-mail). You will get successful 'Login'. In means that SQL Server 7.0 can not properly identify a difference between user names 'SA', 'SA;' and 'SA '. Nothing similar is detected in SQL Server 6.5. 4) We learned that even in case when SA has valid password (non-blank field) in SQL Server 7.0, then everybody may come in stead of System Administrator (SA) with all SA rights. To do so, you have to be registered as an authorized Windows NT user of a domain consisting the domain Windows NT Server (domain controller) and a number of Client Computers (Workstations) with an authorized access to any of them. Each Workstation contains SQL Server 7.0 with corresponding Database. Then you should call from the given Workstation the 'SQL Query Analyzer' for any Database residing on any other Workstation (in which you are not registered as a SQL Server user), then select 'Use SQL Server authentication' and clear up all symbols from both fields 'Login Name' and 'Password' (it means there are no any data entered in these fields - no login ID and no password). Pressing 'OK' you will get successful 'Login'. Then you may do everything like SA and under SA ID. To verify this you may run a query like presented below: DECLARE @UID int, @Text varchar(255) select @UID = USER_ID() select @Text = 'This is ID under which you are registered: ' + convert(varchar, @UID) PRINT @Text The result is that the user not being authorized to deal with the Database has been identified as SA with @UID = 1 and provided by all SA rights to deal with data. We got these frustrating results in our Navy training class where we are running 10 SQL Server 7.0 Databases. Nothing similar has been detected in SQL Server 6.5 we used for the same training facility with the same number of Databases. May I ask you to check presented in section 3) and 4) with original version of SQL Server 7.0 and ask somebody from Microsoft to evaluate these cases? Thank you, Alexander E-MAIL COPY No. 2 ################## From: Benny J. Martinez mailto:bjmartinez@lanl.gov>> To: 'Alexander Rumyantsev' mailto:anr@electronics.kiae.ru>> Cc: 'Peter Gary' mailto:pgary@lanl.gov>>; 'Mac Forehand' mailto:hforehand@lanl.gov>>; 'Barry Siskind' mailto:siskind@bnl.gov>> Subject: FW: Email for Case SRX000727603512 Date: Tuesday, August 01, 2000 11:44 PM Alexander, Here is Microsoft's response, can you give me any more information on the second part? Benny ------------------------------------------------------------------------- -----Original Message----- From: Rand Boyd [SMTP:randb@MICROSOFT.com] Sent: Tuesday, August 01, 2000 9:52 AM To: 'bjmartinez@lanl.gov' Subject: RE: Email for Case SRX000727603512 This first scenario does not surprise me. ODBC strips off trailing spaces so the space after sa does not get passed to SQL Server. This is no different than 6.5 except that the tools in 6.5 used DB-Library and not ODBC. It is true that if sa has no password everyone who is aware of the sa account can connect as sa. That is why the sa password should be changed immediately after installation. The second scenario I have not seen and will have to try an repro it to comment on it. When you say "authorized access to any of them" what type of access are we talking about? Are they an administrator or user? If they are an administrator then they have sa privilege with SQL Server by default as a member of the builtin\admininstrators group. This group did not exist in 6.5. Also if the login id and password boxes are left blank the client utilities default to NT authentication. This is also the way 6.5 worked. Rand E-MAIL COPY No. 3 ################## To: bjmartinez@lanl.gov Cc: pgary@lanl.gov , hforehand@lanl.gov , siskind@bnl.gov From: anr@electronics.kiae.ru Subject: Re: FW: Email for Case SRX000727603512 Date: August 02, 2000 Benny, Thank you for E-mail dated August 01, 2000. More information about the second part is presented in an annex to this E-mail. I ask you to provide the annex to the Microsoft. The main conclusion from evaluations of the previously presented problems with SQL Server 7.0 is as follows: moving from SQL Server 6.5 to 7.0 and trying to provide KI-MACS operations on both, KI must redesign its own data security mechanism incorporated into KI-MACS system in order to restore an ability to track and control the activities of individual users by means of SQL Server built-in functions. This is a precondition for information security certification of KI-MACS system with SQL Server 7.0. An additional conclusion is to be made: present Microsoft policy on providing information data security is just opposite to the current Russian information security regulations and trends in their developments. Thank you, Alexander ANNEX <> -----Original Message----- From: Rand Boyd [SMTP:randb@MICROSOFT.com] Sent: Tuesday, August 01, 2000 9:52 AM To: 'bjmartinez@lanl.gov' Subject: RE: Email for Case SRX000727603512 <> This first scenario does not surprise me. ODBC strips off trailing spaces so the space after 'SA' does not get passed to SQL Server. This is no different than 6.5 except that the tools in 6.5 used DB-Library and not ODBC. <>Such comment does surprise me. As it is stated in documentation (see, for instance, 'Microsoft SQL Server. Introduction', p.28) the 'SQL Server 7.0 includes an enhanced security architecture that is better integrated with Windows NT and provides increased flexibility'. It would mean that at least the same rules are applied for entering Login names and passwords in both Windows NT and SQL Server 7.0 - just for better integration. It is not. For Windows NT user authentication an user must provide ALL symbols in his (her) Login name as well as in password. Windows NT does distinguish such Login names as 'ANR' (three symbols), 'ANR ' (four symbols with the blank as the last, fourth, symbol) and 'ANR;'. The same level of check is provided in SQL Server 6.5, for instance, in ISQL/w. Conclusion: Microsoft statement 'This is no different than 6.5 except that the tools in 6.5 used DB-Library and not ODBC' is not correct. From point of view of data security there is a principal difference in results of using either DB-Library or ODBC. Reality is that SQL Server 7.0 may have 'increased flexibility' but does have decreased Login protection features in comparison with SQL Server 6.5. From point of view of Russian data security regulations such explicit decreasing of a level of Login protection features can not be explained as an 'innocent' error. Rather it may be interpreted as an intentional action. What are arguments for such action? It is unclear. <> It is true that if 'SA' has no password everyone who is aware of the 'SA' account can connect as 'SA'. That is why the 'SA' password should be changed immediately after installation. <> Completely agree. <> The second scenario I have not seen and will have to try an repro it to comment on it. When you say "authorized access to any of them" what type of access are we talking about? Are they an administrator or user? If they are an administrator then they have 'SA' privilege with SQL Server by default as a member of the builtin\admininstrators group. This group did not exist in 6.5. <> Thank you for questions and considerations. The case has been resolved. It helped us to prove two theorems: 1) All users being provided by administrative rights in Windows NT group or groups, are acting under the same USER_ID() = 1 (means 'SA') in SQL Server 7.0. Thus an ability to track and control the activities of individual users by means of SQL Server built-in functions has been practically lost in SQL Server 7.0. 2) SQL Server 7.0 documentation on mixed security mode contains contradicting statements: a) 'Mixed Mode (means) (Windows NT Authentication and SQL Server Authentication), and b) 'Mixed Mode allows users to connect using Windows NT Authentication or SQL Server Authentication' (see SQL Server Books Online, Authentication). First statement presents a logic of 'AND' type. The second one presents a logic of 'OR' type. However, from point of view of data security there is a principal difference between both. In reality the logic 'OR' is used with all expected negative consequences. It was unexpected. <> Also if the login id and password boxes are left blank the client utilities default to NT authentication. This is also the way 6.5 worked. <> It is not correct. In case of Standard Security for SQL Server 6.5 blank fields do not allow to perform successful Login. /*WWWWWWW End of Annex WWWWWWW*/ ************************************************************************ D. From Rumyantsev to Los Alamos (Aug. 7, 2000): To: pgary@lanl.gov Cc: PARKER.O'SHELL@hq.doe.gov , bjmartinez@lanl.gov , hforehand@lanl.gov , siskind@bnl.gov , Charles@Peterson.net , aslesar@USA.net , niknik@kiae.ru , vks@electronics.kiae.ru From: anr@electronics.kiae.ru Subject: Re: Draft SOW: 03492-00-99-35; Task Order 002, Modification 8 Date: August 07, 2000 Peter, Kurchatov management have considered a scale of problem in computerized nuclear material accounting systems for both US DOE and RF nuclear sites, created by flaws and inconsistencies in Microsoft SQL Server 6.5 and 7.0, which were recently detected and proved by Kurchatov. At the same time Kurchatov management have considered the proposed new LANL task 03492-00-99-35; Task Order 002, Modification 8, directed onto development of data verification and data integrity technology for large SQL Server Databases. Conclusions and proposals are as follows: - taking into consideration a scale of practical implementation of Microsoft SQL Server in computerized nuclear material accounting systems at both US DOE nuclear sites (relatively large scale of implementation) and RF nuclear sites (relatively small scale of implementation) the most significant potential damage has been brought to the US side; - in order to minimize a scale of moral and financial losses and potential threat to national security of the US side, the Kurchatov shall provide to the US DOE the SQL Server Database data verification and data integrity technology and 'know-how' which have been developed by Kurchatov in a period February-July, 2000 on a cost-free basis as a voluntary contribution of the Kurchatov into collaborative US-RF efforts to enhance safety and security of nuclear materials; - providing such technology and 'know-how' the Kurchatov hopes that the US DOE will take all necessary and reasonable steps in order to resolve this specific problem with the Microsoft. I would like to ask you to evaluate these conclusions and proposals and inform me about. Alexander D. Message above forwarded to HQ DOE top officials, who were briefed on the problem in person in August 2000: To: Baker Ken at DOE cc: internet: "sherry.fitzgerald@hq-doe.gov ", 08/07/00 slesar 02:25 PM Subject: Kurchatov will give SQL Server information to DOE Ken, You will see that Kurchatov is doing everything possible to get DOE to find a fix for the Microsoft problem. Email from Kurchatov to Peter Gary at LANL "Taking into consideration a scale of practical implementation of Microsoft SQL Server in computerized nuclear material accounting systems at both US DOE nuclear sites (relatively large scale of implementation) and RF nuclear sites (relatively small scale of implementation) the most significant potential damage has been brought to the US side; - in order to minimize a scale of moral and financial losses and potential threat to national security of the US side, the Kurchatov shall provide to the US DOE the SQL Server Database data verification and data integrity technology and 'know-how' which have been developed by Kurchatov in a period February-July, 2000 on a cost-free basis as a voluntary contribution of the Kurchatov into collaborative US-RF efforts to enhance safety and security of nuclear materials; - providing such technology and 'know-how' the Kurchatov hopes that the US DOE will take all necessary and reasonable steps in order to resolve this specific problem with the Microsoft." **************** E. Points of Contact and Cooperation in Doe/Los Alamos: Points of contact in DOE 1. S. Peter Gary, LANL, Head of US DOE-KI Joint Project Team, E-mail: pgary@lanl.gov ; Mail Stop D466, Los Alamos National Laboratory, Los Alamos, NM 87545, Phone: 505-667-3807, Fax: 505-665-7395, 2. Harry M. (Mac) Forehand, Jr., LANL, Project Leader for US DOE-KI MC&A activities related to Russian Federation Navy and Murmansk Shipping Company, E-mail: hforehand@lanl.gov 3. Benny J. Martinez, LANL, Leading Specialist in LANMAS system and MS SQL Server, E-mail: bjmartinez@lanl.gov . Benny J. Martinez has been provided with all KI developed SQL Server tests. He had performed the initial evaluation of the problem and, on KI request, contacted Microsoft with evidences of the software problem; Benny J. Martinez has provided KI by information on Microsoft responses, confirming presence of the Microsoft bug. 4. Barry Siskind, BNL, Leading Specialists in development and implementation of physical inventory procedures for nuclear material, E-mail: siskind@bnl.gov 5. At headquarters it was Ken Baker, Sherry Fitzgerald and Mary Sullivan the General Counsel. E. Miscel. emails From: Benny J. Martinez mailto:bjmartinez@lanl.gov>> To: mailto:chadmat@microsoft.com>> Cc: 'Alexander Rumyantsev' mailto:anr@electronics.kiae.ru>>; Peter Gary mailto:pgary@lanl.gov>>; Mac Forehand mailto:hforehand@lanl.gov>> Subject: SQL Server SRX000403600845 Date: Monday, April 03, 2000 8:11 PM Chad, An application based on Windows NT 4.0 and SQL Server 6.5 has been developed by a Russian organization. Certain stored procedures have produced results that are inaccurate. I am trying to determine where the error is or what options are available to correct the problem. Note! The SQL script has been executed on an International Version of SQL Server 6.5 and a US version of SQL Server 6.5 with the same incorrect results. The SQL Script has also been executed on SQL Server 7.0 with correct results. If you need any additional information please let me know. I would also appreciate any information on how my Russian colleagues may get direct support for Microsoft products in the future. Benny Martinez The following is the SQL script that reproduces the problem of incorrect results sets in SQL Server 6.5: /*** TEST for CONFIRMATION of detected MS Transact SQL ERROR ***/ /*** KI-MACS Library of Stored Procedures is used - version 1.4.1 and above */ /*** Detected and documented for the first time 1998.05.07 - May 07, 1998 - AR*/ /*** There are different results of the same query - depending upon use of variable ***/ /*** On my request the Microsoft was informed about by Los Alamos Nat.Lab. in Sept.1998 -AR ***/ DECLARE @OID_MIN int, @OID int, @ROWCOUNT int, @Text varchar(255) /*** First Trial: @OID_MIN is used in both 'SELECT' and 'WHERE' ***/ /*** RESULT is 12 Records ONLY - In stead of 634 ***/ select @Text = 'First trial with the same parameter @OID_MIN in the SELECT and WHERE statements' PRINT @Text select @OID_MIN = 0 DO_NEXT_1: SELECT @OID_MIN = id FROM sysobjects WHERE id > @OID_MIN AND type = 'P' ORDER BY id DESC select @ROWCOUNT = @@ROWCOUNT select @Text = '@ROW = ' + CONVERT(varchar, @ROWCOUNT) + ' # OID_MIN = ' + CONVERT(varchar, @OID_MIN) PRINT @Text IF @ROWCOUNT <> 0 GOTO DO_NEXT_1 /*** Second Trial: @OID_MIN is used in 'WHERE' only ***/ /*** RESULT is 634 Records - It is correct result ***/ select @Text = 'Second trial with the different parameters in the SELECT and WHERE statements' PRINT @Text select @OID_MIN = 0 DO_NEXT_2: SELECT @OID = id FROM sysobjects WHERE id > @OID_MIN AND type = 'P' ORDER BY id DESC select @ROWCOUNT = @@ROWCOUNT select @OID_MIN = @OID /*** Assignment of New Min Value for 'WHERE' **/ select @Text = '@ROW = ' + CONVERT(varchar, @ROWCOUNT) + ' # OID_MIN = ' + CONVERT(varchar, @OID_MIN) PRINT @Text IF @ROWCOUNT <> 0 GOTO DO_NEXT_2 RETURN GO E-MAIL COPY No. 2 ################## From: Benny J. Martinez mailto:bjmartinez@lanl.gov>> To: 'Chad Mattox' mailto:chadmat@microsoft.com>> Cc: 'Alexander Rumyantsev' mailto:anr@electronics.kiae.ru>>; 'Peter Gary' mailto:pgary@lanl.gov>>; 'Mac Forehand' mailto:hforehand@lanl.gov>> Subject: RE: SQL Server SRX000403600845 Date: Tuesday, April 04, 2000 12:01 AM Chad, I am looking for both a workaround and a long term solution that will be compatible with future versions of SQL Server. We do not want to have to go back and change anything if we upgrade to SQL Server 7.0. I will pass this on to my Russian colleagues to determine what impact this workaround may have on their stored procedures. Thanks for the update. Benny --------------------------------------------------------- -----Original Message----- From: Chad Mattox [SMTP:chadmat@microsoft.com] Sent: Monday, April 03, 2000 12:31 PM To: 'bjmartinez@lanl.gov' Subject: RE: SQL Server SRX000403600845 Benny, I have been working with this query, and I am not yet sure why we are seeing this behavior. Are you just looking for a workaround? I have gotten the query to work properly if you make OID_MIN decimal(28,0) rather than int. (Decimal(28,0) means a number that can have 28 digits, and 0 digits after the decimal). I will continue looking into this. I have not yet been able to find a bug that matches this. If you have any questions please let me know. Chad Mattox E-MAIL COPY No. 3 ################## From: Benny J. Martinez mailto:bjmartinez@lanl.gov>> To: 'Alexander Rumyantsev' mailto:anr@electronics.kiae.ru>> Cc: 'Peter Gary' mailto:pgary@lanl.gov>>; 'Mac Forehand' mailto:hforehand@lanl.gov>> Subject: SQL Server error Date: Tuesday, April 04, 2000 10:40 PM Dear Alexander, I have been communicating with a Microsoft System Engineer (Chad) who has requested additional information. He has verified with his supervisor that SQL Server 6.5 does not retrieve a correct recordset based on your query. He has performed numerous tests on other tables and has not been able to duplicate the problem with other than the sysobjects table, he is concerned that indexes or other attributes of the table influence the selection process. He would like to have a user generated table which exhibits this same problem to further study the problem. Do you have a script that generates a table and associated attributes that you can send me that exhibits this same problem or can you generate a simple test table that exhibits the same problem. Currently the only work around as mentioned earlier is make OID_MIN decimal(28,0) rather than int. (Decimal(28,0) means a number that can have 28 digits, and 0 digits after the decimal). The Microsoft System Engineer said he would continue to research the problem but had found no similar reported problems. Sincerely, Benny E-MAIL COPY No. 4 ################## From: Benny J. Martinez mailto:bjmartinez@lanl.gov>> To: 'Chad Mattox' mailto:chadmat@microsoft.com>> Cc: 'Alexander Rumyantsev' mailto:anr@electronics.kiae.ru>>; 'Peter Gary' mailto:pgary@lanl.gov>>; 'Mac Forehand' mailto:hforehand@lanl.gov>>; 'Joel Lewis' mailto:lewisjc@ornl.gov>> Subject: RE: SRX000403600845 Date: Wednesday, April 19, 2000 3:19 AM Chad, I am currently waiting for feedback from the Russian facility to find out if the workaround was used and fixed the problem. I will get back with you as soon as I can. Benny ------------------------- -----Original Message----- From: Chad Mattox [SMTP:chadmat@microsoft.com] Sent: Tuesday, April 18, 2000 4:46 PM To: 'bjmartinez@lanl.gov' Subject: SRX000403600845 Benny, I just wanted to touch base with you again on this issue. Is the decimal(28,0) workaround going to work for you? I need to know if this is going to suffice, or if we need to continue working on it? I have filed a bug on this issue, so you will not be charged if you would like to close the case. Please let me know. Thanks, Chad Mattox, MCSE SQL Support Professional (704) 582-8961 chadmat@microsoft.comE-MAIL COPY No. 5 ################## From: Benny J. Martinez mailto:bjmartinez@lanl.gov>> To: 'Alexander Rumyantsev' mailto:anr@electronics.kiae.ru>> Cc: 'Peter Gary' mailto:pgary@lanl.gov>>; 'Mac Forehand' mailto:hforehand@lanl.gov>>; 'Barry Siskind' mailto:siskind@bnl.gov>> Subject: FW: SRX000403600845 Date: Thursday, April 27, 2000 5:39 PM -----Original Message----- From: Chad Mattox [SMTP:chadmat@microsoft.com] Sent: Wednesday, April 26, 2000 2:05 PM To: 'bjmartinez@lanl.gov' Cc: Edith Yakutis Subject: RE: SRX000403600845 Benny, I do not want to archive this case if you (or your customers) are not satisfied. This is a bug in our software as I have stated before. The workaround I suggested was just that, it was a suggestion. If it will not work, we can pursue other alternatives. However, it is unlikely that it can be avoided without some changes in their code. As for Standard Security in SQL 7.0 it no longer exists in that you cannot only have SQL Server Authentication. You can still set security to mixed mode, and just not create any NT Logins, which is the same thing as having 'standard security'. Please let me know if you would like to pursue other alternatives? Regards, Chad Mattox, MCSE SQL Support Professional (704) 582-8961 chadmat@microsoft.com-----Original Message----- From: Benny J. Martinez [] Sent: Wednesday, April 26, 2000 9:54 AM To: Chad Mattox Subject: RE: SRX000403600845 Chad, The Russians have stated that the workaround is not acceptable and are currently evaluating SQL Server 7.0. RussianComments: "My staff is near completion of all tests we planned for MS SQL Server in version 6.5 in order to develop and test out the most reliable solutions of discovered problems permitting us to be sure that we are capable either to provide diagnostics of discovered MS bugs of the same nature having RANDOM (let me underline it) appearance, or to eliminate calls to 'ORDER BY' statements by introduction of less vulnerable but more expensive (in terms of computer resources) logical schemes for data treatment. 'Workarounds' which were proposed by MS staff (such as use of decimal(28,0) rather than integer) are not applicable at all. Either MS is capable to detect a source of the problem we managed to prove as a SYSTEMATIC error by implementing integers and utilizing SQL Server system tables, or MS is not capable to understand that is going on with its own products which fail to perform in accordance with documentation. I am not going to resolve MS SQL problems by playing around data formats which means a complete redesign of KI-MACS application software core (over 5 Mb of source code in Transact SQL). By the way, I was astonished to learn that MS staff is seriously proposing such stupid advises as change of data formats to avoid MS SQL Server SYSTEM problems. Is it MS style of conducting business? If so, we have to be prepared to deal with permanent troubles for the rest of our life." "Due to significant changes introduced into MS SQL Server in version 7.0 in comparison with version 6.5 and limited compatibility between both versions we are looking for one more problem: in version 7.0 the so-called 'standard security no longer exists' (see MS 'Microsoft SQL Server. Introduction' (p. 177). It means that one of 'backbones' of the KI-MACS internal information security system which provided KI-MACS Russian State security certification has been undermined. I have had very intensive discussions with staff from SISC. We have been requested to develop a number of additional security tests confirming ability of KI-MACS information security system to perform its functions in spite of MS 'innovations'." Chad, go ahead and archive the case and I will wait to see if funding to upgrade to SQL Server 7.0 is available and the Russians are willing to use it. Thanks, Benny ------------------------------------------------------------------------------------------------- -----Original Message----- From: Chad Mattox [SMTP:chadmat@microsoft.com] Sent: Tuesday, April 25, 2000 3:46 PM To: 'bjmartinez@lanl.gov' Subject: SRX000403600845 Benny, This case has been idle for some time. I really need to know if the workaround provided is going to work for you. If you anticipate this taking more time to find out, we can archive the case, and reopen it in the event that more work needs to be done on it. Please let me know. Thanks, Chad Mattox, MCSE SQL Support Professional (704) 582-8961 chadmat@microsoft.com : bblair@mail   Printer-Friendly Versions: Rich Text Format    Plain Text

BACK TO TOP    NUCLEAR FACTS AND FIGURES    CDI ISSUE AREAS    CDI HOME