Follow Slashdot stories on Twitter


Forgot your password?

Nuclear Materials System Not Buggy, Says Microsoft 224

Darkmeat writes: "Saw this on ZDNet. Looks like SQL Server was causing some problems in nuclear databases in Russia." Another similar story at Yahoo. This is a followup to this story detailing the problems.
This discussion has been archived. No new comments can be posted.

Nuclear Materials System Not Buggy, Says Microsoft

Comments Filter:
  • by Anonymous Coward
    It's not buggy, all the data is hidden in a secret directory on the windows machine, waiting for the next internet connection to be sent to microsoft :)
  • SQL Server 6.5 was superseded about three years ago. The default password for SQL Server 7 has been discussed before and is pretty much standard - how many systems force you to provide a password at install time?

  • by Anonymous Coward
    so they can be as reliable and secure as Slashdot.
  • by Anonymous Coward
    If there is anything movies have taught me, is that this would only work if you don't misplace a . in the code, and end up with $100,000 after only a day.

    Of course if that happens, you can alway wait for a co-worker to burn the building down.
  • by Anonymous Coward
    How many of you read the article? The problem was with custom software that used SQL Server. The problem was not with SQL Server itself. And the subsequent "bug" that allowed unauthorized people to get access was only when there was no password in place. If you have any piece of software that doesn't have a password, you allow unauthorized access, no surprise there. This isn't Microsoft's fault. They even offered to fix the problem. Jesus Christ, read the article before you start spewing your mindless dribble.
  • by Anonymous Coward
    Because rebooting the machine didn't work.
  • by Anonymous Coward
    (Posting anon so my company doesn't piss off MS. :) )

    My experiences with SQL Server support match with yours, though in a rather different situation-- no complex queries, and the data wasn't lost once it actually got into the DB, although that's what often failed. We had a bug where about 1/1000 statements would actually get a random character corrupted-- so, for example, your "SELECT * FROM tblWhatever" would become "SELECT * FROM tblWh#tever". We logged everything going in, and it was fine, but the error message coming out was that it couldn't find tblWh#tever, when what we logged as going into the statement was quite obviously tblWhatever.

    We went through the various reporting channels; they may have even sent someone over at some point, I can't remember. IT people at other companies claimed they'd never seen the problem; I'm guessing it was just a particular configuration. The eventual solution was, "we have this new version that probably fixes that bug, please upgrade-- and we swear, it doesn't introduce new, impossible to track down and fix bugs". We agreed-- we upgraded (to Oracle).

    The bottom line is that regardless of how many people here claim they've never seen the bug, and so on and so forth-- I KNOW SQL has bugs that aren't in the known bugs lists. And their excuse here-- "they upgraded to 7.0 and everything's happy now" rings hollow because that's what they said about 6.5. It's gonna be "all fixed" until they find the new bugs with 7.0. Denying the problems with their software won't get it fixed.
  • by Anonymous Coward on Tuesday July 24, 2001 @05:24AM (#65471)
    Of course, if the database were mySQL or PostGres , the story would have never made it on /. .

  • .. you know that .. the good people that read slashdot know that. But Joe Sixpack doesn't, ergo the knee-jerk reaction.
  • by Oestergaard ( 3005 ) on Tuesday July 24, 2001 @06:21AM (#65473) Homepage
    Read the original e-mail piece. It's long, but it's well worth the read.

    There a numerous issues in this article that are significantly "re-formulated" our left out - and that actually matters a lot in this case.

    This article gives the impression (in my oppinion) that it is disputable wether the flaws were serious at all, and it seeks to give the impression that microsoft offered help which the russians refused.

    If you read the longer original transcript, you will see that there were several other significant flaws found in 7.0 which made it unusable, and that the fix microsoft offered was "upgrade to 7.0".

    The original transcripts ends with the russians expressing their deepest concern and surprise over microsoft actually suggesting them to fiddle with numeric formats etc. in order to work around real bugs that show up in SQL server.
  • #1 is WRONG. The bug they found was in SQL Server. The software they wrote just happened to trigger it.

    From the article, it doesn't say exactly what the security problem was, you can't tell for sure that it was #2.
  • "It's not a bug, it's a feature. Russia wants to loose nuclear devices, it makes for much less cleanup and disposal on their behalf."

    --M$ Press Agent
    "If you insist on using Windoze you're on your own."
  • If it's not in the database, it doesn't exist, and will thus not need to be disposed of.

    "MS announced today that the next version of SQL Server will have a tenfold increase in its lauded 'virtual disposal' capability as compared to previous versions. 'This is a huge step forward for our environmental policy', president Bush stated, and added 'It's another example of how business takes care of environmental concerns far more effectively than government regulations can do'."


  • Fieros were among the safest cars on the road. They were amazingly good for their size in a collision. I know someone who was in a head-on collision in one and walked away without a scratch.

    And, by the time the Fiero was dropped, it was a markedly improved vehicle, definitely more desirable than the stupid Firebird.

    The real question is whether the car was dropped because of internal GM politics. The rumor is that Chevy hated it, because it threatened the Corvette.

    Jon Acheson
  • Ok - my little story does indeed reek of 'urban legend' and just 'sounds' credible (hey, it got +4 here already!) I did a more indepth research and found one Phd [] who makes a distinction between MRI as a type of NMR, but then again here [] is another site that repeats my story.

  • by ch-chuck ( 9622 ) on Tuesday July 24, 2001 @05:33AM (#65479) Homepage
    That's why medicine took the 'nuclear' out of Nuclear Magnetic Resonant Imaging - patients would freak out at the mere mention of 'nuclear' so they changed it to just MRI. It still involved the nuclei of atoms.
  • by FreeUser ( 11483 ) on Tuesday July 24, 2001 @06:55AM (#65480)
    I'm all for M$ bashing - when they deserved to be bashed (and there are plenty of areas where they deserve this). But in this case, the article is nothing more than anti-M$ propoganda.

    No. The article is either pro-Microsoft spin couched as innefectual criticism or profoundly incompetently written. If you check the referenced source material [] you'll find that, in fact, there were severe bugs related solely to Microsoft's SQL Server which have not only compromised the Russian nuclear tracking system, but even more severely compromised the American nuclear tracking system. What is worse, the Russians were wise enough to keep their manual system intact as a check, despite ridecule from their American colleagues. The United States, on the other hand, has had no manual system or check of any kind in place. Verifying the American stockpiles will cost on the order of a Billion US Dollars and will not detect any material which has already been diverted.

    Los Alamos has verified the bugs, both in the version of SQL server the Russians were using and in the version Microsoft recommended they upgrade to.

    Microsoft spin and apologist propoganda aside, this fiasco is real, has truly shocking and horrifying security implications for the entire planet, and is absolutely inexcusable. Of course, inexcusable lapses on the part of Microsoft and the quality of their proprietary products is hardly new or surprising, but it remains news so long as their shoddy products continue to dominate the market through marketing misrepresentation and public ignorance of the facts.
  • by FreeUser ( 11483 ) on Tuesday July 24, 2001 @09:10AM (#65481)
    A complete synopsis [] of the email exchange released by the Center for Defense Information reveals that the flaws in Microsoft's SQL server were serious, and seriously affected both the American and Russian systems for tracking nuclear materials.

    Nuclear material may or may not have been misplaced or diverted. What is certain, however, is that currently neither country has complete track of its materials as a direct result of the aforementioned software bugs in Microsoft's SQL server, and the cost of reinventorying the materials will cost on the order of one billion US dollars for the United States alone. Furthermore, if materials have been diverted from within the US inventory, the diversion will not be identified by the reinventorying methods available. This situation is unambiguously a result of the problems both teams have had with Microsoft's SQL server, coupled with the fact that the bugs weren't identified until the project was well underway.

    You may deny, deny, deny as much as you like, but the public record is clear and unambiguous, and, once again, the fault lies squarely on Microsoft's incompetent shoulders.
  • When WAS the last time a server installation of Linux *did* crash then, hmm?

  • And the way I've always read Bill's statement was:

    Some customers complain, but neither those customers nor the bugs they complain about matter to us.

    Of course no one complains... There's no point. MS has never been known to do anything about bug complaints but disavow and disregard them.
  • If this had been an open source database, it would have been fixed right the first time. Heck, if this had been an open source database, the DOE or the Russians could have audited the whole system from the ground up the instant they detected any problems.

    This is only a story because a closed source vendor can't keep a handle on their bugs even when they are of literally world-changing importance.

  • First of all, MySQL probably wouldnt be the best choice, as it doesnt support certain database features (e.g. transactions, triggers, etc.).

    Sounds ideal to me. I wouldn't want any potentially crackable database containing triggers for my nuclear devices. :^P

  • That might be the former NRC system. They selected Oracle when they were forced to write a new system. The old system used Microsoft FoxPro, and when FoxPro no longer existed, well...they had a little problem.

    This was included in a list of some MS hazardous materials systems [] which I had in an earlier post: cy.html#ATTACHMENT 4 [].

    This comment has been submitted already, 276663 hours , 36 minutes ago. No need to try again.
    Hey, lameness filter. This ain't that comment. Stop making me rephrase it.
  • by jmauro ( 32523 ) on Tuesday July 24, 2001 @06:44AM (#65508)
    No it's.... while( upgrade.exists() == true )

    See it's much easier this way.
  • by hey! ( 33014 ) on Tuesday July 24, 2001 @05:41AM (#65509) Homepage Journal
    From the article:

    Murchie said the bug was a minor problem in Microsoft's instructions for using the software and has been resolved. "It was not a product flaw."

    From Neal Stephenson's essay, "In the Beginning was the Command Line":

    Commercial OSes have to adopt the same official stance towards errors as Communist countries had towards poverty. For doctrinal reasons it was not possible to admit that poverty was a serious problem in Communist countries, because the whole point of Communism was to eradicate poverty. Likewise, commercial OS companies like Apple and Microsoft can't go around admitting that their software has bugs and that it crashes all the time, any more than Disney can issue press releases stating that Mickey Mouse is an actor in a suit.

    Hmm. Perhaps our Russian friends are excercising a bit of well earned scepticism.
  • Not true. Data stored on a secure server is only as secure as the clients it trusts to access/modify that data.

    If I compromised the client; created and account; and transferred money into it via that client how is the data in the server secure?

    It doesn't have to be a newbie or random client off of the street. This is BANK ROBBERY. All it takes is one.
    Charles E. Hill
  • The server doesn't trust any client. It doesn't matter where or what software it's running. Access has to be permitted through a pre-established authentication protocol, and its the end-user that is authenticated not the end-client.

    True. However, I was making the logical assumption that if I could compromise the client machine it wouldn't be anything to compromise the username/password of the teller from either packet sniffing; shoulder surfing or the little post-it note taped to the monitor. :-)
    Charles E. Hill

  • by chill ( 34294 ) on Tuesday July 24, 2001 @06:29AM (#65513) Journal
    Sorry, you're wrong.

    I was in a bank the other day asking about opening an account.

    The terminal that was being used to look everything up; open new accounts; etc. was a WINDOWS 95 machine accessing the database via a WEB BROWSER interface with JAVA.

    It also had an IP address taped to the monitor and they had limited INTERNET access (so they can show their lovely Internet Banking).
    Charles E. Hill
  • by chill ( 34294 ) on Tuesday July 24, 2001 @05:27AM (#65514) Journal
    Drops one transaction in a thousand? What if instead this was installed at a major bank -- like a Federal Reserve or a National Bank?

    A year or so of "dropping" 1 in 1,000 transactions could be quite a sum.

    Hmmm...if any banks out there are looking for SysAdmins to implement an MS SQL Server solution -- I'm available!
    Charles E. Hill
  • Yes but it does present another opportunity to point out that MS executives are habitual liars.
  • And they have denied it if where it looked like they could get away with it.

    Some time ago a friend of mine, 'mike*' who supported enough people that he had an MS rep assigned to him, was beating his head against the wall trying to solve a bug that was causing excel files to be corrupted just by opening them.

    His MS support rep kept on telling him, "nope it's a unique problem" you seem to be the only one suffering from this. What are you doing wrong. One day he found out that 'bob', a counterpart at another large company, had been dealing with the same problem for a number of months. He decided to mention this to his MS Rep.

    I was talking to Bob at OtherCorp yesterday, and...

    Oh, Bob.. Bob Plimton? I talk to him all the time! I'm his support rep too!

    So then, you know about the problems that he's been having?

    (guilty silence).

    *(names have been changed to protect the innocent)
  • As mentioned in the articles, the database didn't lose any data, it just wouldn't display it.

    How about SELECT INTO...
    How about selects done in cursors?
    How about selects that result in recirds being updated (via stored procs or application logic)?

    Also, generally speaking, if you can't see it or find it, it is lost or misplaced. Just going with the regular meanings of english words here...

    - - - - -
  • Lately it's been one stale anti-MS joke after another with a +5 "Funny" moderation.
    Surely you MS-haters must have a better sense of humor.

    Maybe the GPL is a cancer, maybe it's not. But at least it's never misplaced plutonium.

    ... there. That one's even recycled.

    - - - - -
  • Microsoft confirmed it, reproduced it, and assigned it a bug number. So... who's full of bullshit here?

    - - - - -
  • It's not that every 1,000 transactions are dropped. It's that, with odds of 1 in 1000, a select statement with an order by clause will not return all of the data.

    A little less dramatic, but a problem nonetheless.

    - - - - -
  • Why so hostile? The original report has the bug number. Other people said they have independently confirmed it. Do you own a lot of MSFT stock or something?

    - - - - -
  • Hey- I just need to speak up, I have no idea about the missing data thing, but as far as "a new security flaw that could give unauthorized people easy access"... that's bunk!

    The system password by default on install is blank, Oracle has a default password too, I think it is "CHANGE_ON_INSTALL". So if you happen to install SQL Server and not have the brains to change the default password, then you deserve everything you are about to get. Now I hate M$ just as much as the next guy, but it's a shame that these dorks have to go blaming their incompetence on other people.

  • by Zigg ( 64962 ) on Tuesday July 24, 2001 @06:13AM (#65541)

    Looking at my dictionary... flip flip flip flip flip... ahh, here it is:


    (n.) a rather large, rather monopolistic software company

    (v.) to fuck up on a rather large scale

    No, I think his grammar is OK.

  • Christmas Jones

    God, Denise Richards is a terrible actress....

  • Sure it would..

    Nuclear power, Russians, computers. It's an episode of James Bond waiting to happen.

    To claim otherwise is only to whore towards the "Anti-MS bias" moderators.
  • From the Yahoo article:
    "There wasn't, in any of the documents we had, a true security hole," Microsoft's Murchie said, adding there was a vulnerability in 7.0 if no security procedures were employed on-site.
    In other words, what the Russians said ("also had a critical security flaw that would allow easy access to the sensitive nuclear database by hackers or unauthorized personnel.") was entirely correct. Any hacker or unauthorized personnel which had (physical?) access to *ANY ONE OF* the accounting terminals, it seems, could make changes to the database at will. As well, users who ordinarily have permissions to change only small portions of the database in limited ways (and who therefore have physical access to the system by definition) can exceed their permissions at will.

    I agree with the Russians: this *is* a big security hole!!

  • by BlueUnderwear ( 73957 ) on Tuesday July 24, 2001 @06:25AM (#65546)
    > Use Linux. I do. Its great. Ditch Windows.

    And change jobs, if your current one don't let you use the OS of your choice. Despite the dot-bomb crash, the labor market for software engineers is still splendid.

  • the article is talking about a very specific scenario. others have been able to repreduce it.

    moderators - please mod the parent accordingly

  • by artemis67 ( 93453 ) on Tuesday July 24, 2001 @06:07AM (#65551)
    "Blue Screen of Death"
  • I'm replying to several posts in which you question the existence of the bug or blame the application programmers based on the fact that you have not encountered this bug.
    If you have time, read the paper. [] It explains exactly what the bug is. Any summary is necessarily imprecise; however here's an attempt: the following code works:
    SELECT @X = id FROM sysobjects

    WHERE id > 0 AND type = 'P'
    And the following code does not work:
    select @X = 0

    SELECT @X = id FROM sysobjects
    WHERE id > @X AND type = 'P'
    (I'm skipping a lot). If @X is declared decimal instead of int, the bug goes away. This was Microsoft's proposed fix.
    Personally, I don't like stored procedures much, particularly Transact SQL which is what this appears to be. In general, a heavy reliance on stored procedures frequently shows a lack of understanding of SQL and data modelling.
  • Basing code on the sysobjects table is a bad idea in general though it has its uses....Why you would code anything like this other than for some kind of database modelling tool is unclear to me.
    Since I haven't read the whole paper, I'll offer my guess: they wanted to use a built in table for their example. That way they wouldn't have to include the code to create and populate the table, which could be part of the problem. I assume that they originally found the problem on a table they had created, and managed to reproduce the problem on sysobjects for bug reporting.
    Your conclusion about stored procedures is entirely misguided.
    I'll grant that they have a legitimate role. However, I've seen them overused. I've seen them used to replace foreign key, unique, and check constraints, even to enforce typing which could have been done by declaring the column correctly. Oracle's documentation warns against the performance penalties of such misuse. I've also seen them used as substitute for JOINs, again by programmers who don't have much grasp of SQL.
    Stored procedures are dangerous because they offer a procedural cop-out to programmers from a procedural background. If you're using them correctly, great.
  • I love how the knee-jerk scariness of these things jumps exponentially when the word "nuclear" is present. I realize it's justified, ate least in this case, but I still find it amusing.

  • I think that makes it even scarier.

  • did you know that the sun is powered by NUCLEAR reactions? I say we ban solar power ;-)
  • There may, as the philosopher says, be no spoon,

    Since when did the matrix become a philosophy text, and Keanu Reeves a Philosopher? As bill and ted would say: EXCELLENT! ::air guitar::

  • Not quite. It was Christmas Jones who was de-arming the bomb and she was using her HP Jornada to interface with the bomb.
  • The headline could have been "M$'s Munchie insults Rusian governement and scientific community by Blaming the User (TM)." Sounds like news to me.
  • A good programmer checks the results of their code as well as the code itself.

    True! and a good scientist would never trust MS.

    I can't imagine using closed source programs for nuclear materials and I have not seen it either except for the most mundane additons and plotting. Some fool might be trying something more elaborate somewhere, but all software used in the US for this kind of thing has elaborate trails, proving and QC. This should serve as a wake up call to people trusting closed source junk on PC's for less critical, punn intended, applications.

  • "We heard this customer application was running some complex (software) code against 6.5 and was returning different results under different circumstances," he said. "We looked at it and offered to create a fix. No data was ever lost."

    This is just so typical. Certanly noone else run complex code in a database environment.

  • by jgerman ( 106518 ) on Tuesday July 24, 2001 @05:36AM (#65567)
    No wonder there are fireballs hitting the U.S. East coast.
  • I've used SQL Server for years...

    Both of them?

  • by ZeldorBlat ( 107799 ) on Tuesday July 24, 2001 @05:35AM (#65569)
    I love how the knee-jerk reactions to these things take an incredibly closed-minded and negative tone when the word "Microsoft" is present. If this had been an open source database, I doubt anyone on Slashdot would be so quick to jump to conclusions.
  • Just in case that wasn't enough to spook people, Yahoo threw in this old favourite just to scare people even more:
    Blair writes that a later version of software sent to the Russians -- Microsoft SQL Server 7.0 -- "not only contained the same bug (though much less virulent) but also had a critical security flaw that would allow easy access to the sensitive nuclear database by hackers or unauthorized personnel." [my emphasis, obviously]
  • eh? so? clients don't matter squatola, as long as the data store and serving mechanisms are running on something secure. I do believe he said "anything important"... Or do you expect the average newbie employee or random client off the street to waltz into the bank and be perfectly adept using OS/2, Linux, *BSD, or whatever the hell the bank uses "for real"? (yes, many banks rely on IBM software like OS/2 for internal clients, DB2 on AIX for datastore, etc.; if one bank is retarded, this does not disprove the original posters thesis)

    News for geeks in Austin: []
  • Yeah, cuz everybody knows that if only it were MySQL, a quick reboot would fix everything [].
  • This isn't an issue of changing the password. It's an issue of SQLServer 7.0 having no "Stand alone" security mode. In 6.5 you could use the "Stand alone" or "Mixed" mode. In 7.0, only mixed mode is available. The manner in which the application was designed required that it have "Stand alone" security. Of course Oracle has a password that should be changed, but Oracle is ALWAYS on "Stand alone" security.

    It wasn't so long ago that MSN's SQL servers were still set up with no password on the sa account, so apparently it's par for the course for SQL server admins to be incompetent.

  • Ah yes, the idealism of youth. No mortgage, no family to support, and a mommy & daddy who pay the bills. Enjoy it while it lasts, sonny.

    And, FYI, I do own my own company. That means instead of pointy-haired bosses, I have pointy-haired clients. It's not really any different - they still sign the checks, and if I want to get paid, I have to do what they want me to do. In many ways, you have less freedom when you own your own company than you do when you work for somebody else. You don't own the company, it owns you.

    In case you've never owned your own company, let me teach you an important saying: "The customer is always right". Even when he wants you to use Microslop software. If you want big corporations to do business with you, you have to play the game by their rules. If you start copping that holier-than-thou attitude with your customers, you are going to find yourself down at the courthouse filing for bankruptcy in very short order.

  • Probably a standard response.

    Upgrade to a newer version

    Hacker: A criminal who breaks into computer systems
  • First of all, MySQL probably wouldnt be the best choice, as it doesnt support certain database features (e.g. transactions, triggers, etc.). If the database were PostGres, the problem wouldnt have existed. And if it did, the source is there (open source, get it?) and the lab could fix it themselves or contract someone to do so.

    It goes beyond SQL Server being a Microsoft product. A database server that loses data, no matter how infrequently, is UNACCEPTABLE. How can they claim it is an enterprise level database?

    As my company's in-house open source zealot, I always look for alternatives to expensive, closed source software, but I am all for using the right tool for the job. SQL Server has some features that open source databases dont just yet, like fairly good scalability through clustering and such, but after this fiasco I dont think I would EVER trust data to SQL Server.
  • The nature of bugs (especially MS bugs) is that not everyone experiences the same bugs. Just because you haven't seen it doesn't mean others haven't. I've seen documents that crash Word on some computers and not on others, even with the same version of Word. And if it wasn't an SQL Server bug, why would changing from one version of SQL Server to another affect it? Microsoft acknowledged the bug existed but said it didn't appear at "other customer sites" (all other sites? the majority of them?), downplaying its significance. As Bill Gates said [], "There are no significant bugs in our released software that any significant number of users want fixed."
  • As mentioned in the articles, the database didn't lose any data, it just wouldn't display it. The data was there, just hidden, which sucks and all, but at least it wasn't lost.

    Not that I'm making excuses for Microsoft or SQL Server or anything, just clarifying things.

    As it happens, I'm no fan of SQL Server or Microsoft in general either. (Actually, I use nothing but PostgreSQL for my databases -- my company was actually one of the first organizations to be "Certified for use with PostgreSQL.")

  • How the hell could a Fiero with a small inline 4 be a threat to a world class sportscar. I rebuilt one of those with my friend and his brother and there was absolutely no room to icorporate a larger engine. And the price difference was about 2x.

    Chevy may have hated it, but it was not because the Fiero threatened the Corvette. They are in two different market segments. That's like the PT Cruiser threatening a Viper.

  • Technically it doesn't drop the transaction per se. It just deposits it into my bank account.


  • What?! You are asking me to appreciate the gravity of this problem by couching it in monetarial terms instead of accounting of, real, nuclear warheads? On my "list of things to get worried about", "your federally insured bank has misplaced 70 million dollars" ranks slightly below "your government has misplaced a few thermonuclear weapons".
  • by rsd ( 194962 ) on Tuesday July 24, 2001 @05:31AM (#65600) Homepage
    That's a good way to share technology and sabotage your enemy at the same time.

    Make them use Microsoft.

    disclaimer: no offense intented
  • by necrognome ( 236545 ) on Tuesday July 24, 2001 @05:57AM (#65608) Homepage

    I thought free software threatened national security and the american way of life.

    I would search my quote database for the name of the person who said "Don't throw stones in glass houses," but given that it's the 1000th transaction of the day, I'm experiencing technical difficulties...

  • Clearly, you weren't using either:

  • Is that why the reactors are all CE-ME-NT? Har har.
  • by WindowsTroll ( 243509 ) on Tuesday July 24, 2001 @05:42AM (#65613) Homepage
    In the quest to post as many articles bashing M$, the quality of the posted articles is approaching the level of the World Weekly News.

    The Headline "Nuclear Materials System Not Buggy" is misleading. When you read the article, the main two arguments for saying that M$ has buggy code are:

    1). Users of SQL Server are able to code software that can screw up the database.
    2). When you don't put a password on admin accounts, it causes a security vulnerability.

    These two assertions are true for EVERY database server, not just M$. Anyone who has write/commit privileges to database tables has the ability to screw up the database - this is not a SQL Server issue. And if you don't put passwords on your accounts, it is your own damn fault for introducing a security vulnerability.

    I'm all for M$ bashing - when they deserved to be bashed (and there are plenty of areas where they deserve this). But in this case, the article is nothing more than anti-M$ propoganda.
  • And I've written code that didn't work correctly. Then I fixed it when I audited my results. Almost all complicated software has quirks in it. Should it be fixed? Yes. Do people handling nuclear material records have a responsibility to audit their code regardless of whether bugs might exist? Also yes. A good programmer checks the results of their code as well as the code itself.
  • by Pov ( 248300 ) on Tuesday July 24, 2001 @05:41AM (#65639)
    I ran a SQL Server 6.5 database that handled 7GB of data a month and processed around 21 billion transactions on that data, then countless more on the "rolled up" summaries. We had a general ledger to reconcile with and I think we would have noticed missing records if they occured every 1000 transactions. SQL 6.5 was a pain in the ass and 7.0 is a lot better. It still has some problems, but I think these reported "bugs" are more bad programmers than bad server software.
  • by truthsearch ( 249536 ) on Tuesday July 24, 2001 @05:44AM (#65640) Homepage Journal
    I've used SQL Server for years... not because I want to, but because the company I work for prefers it. I've never seen such a problem of dropping every 1000 transactions. But there is one particular thing about this story that bugs me (no punn intended)... if the bug isn't in Microsoft's software, as they contend, then why did they tell the Russians to upgrade to a newer version to solve the problem???

  • Read the e-mail exchange between Blair and the Russians here []. Plenty of details on the problems with MS SQL server, and apparently both sides agree that this is pretty low quality software.
  • by jsse ( 254124 )
    Of course, if the database were mySQL or PostGres , the story would have never made it on /. .

    Very true. They are open source and this particular development cycle will make sure such stupid bugs not last long. I'm sure such news wouldn't make it to /. if MS follows the same cycle.

    Reading the articles you can see they concern the problem with closed source, not the brand itself.
  • to see Microsoft respond so strongly to this. They must have really gotten spooked by the press this issue was getting.

    I just hope their engineers are 100% sure that it was just isolated to that one lab in Russia. If other labs in the US encounter a similar issue AND the public finds out about it - Microsoft will be in a err, difficult position.

    I find it interesting that the Russian lab rejected Microsofts offered fix - whats that all about? I'd love to know why they did that.

  • What I really would like to see is a Nuclear Reactor on Redmond, controled by M$ products. If the product fails, it just meltsdown. I think that is the only way to make M$ products suck a little less. Considering, of course, that they could fix them in less then 24h, that is the aproximate time it would take the reactor do meltdown with the first rWin crash.

    No, really. What scares the sh1t out of me is that someone would seriously consider AND use M$ products in a nuclear facility.

  • No, bugs are exactly what he said.
    The computer does *exactly* what the programmer told it to do.

    Two witches watched two watches.
  • You might have meant it as a joke, but there *are* several instances where BOOL doesn't equal FALSE or TRUE in Windows!

    Two witches watched two watches.
  • if the bug isn't in Microsoft's software, as they contend, then why did they tell the Russians to upgrade to a newer version to solve the problem???

    They never said it wasn't a bug. They offered a workaround and said the the bug doesn't exist in the new version.

    After they decided that it would be too much work use the workaround, the Russians opted for the new version, didn't RTFM, and then went around screaming "security flaw!"

    So they had a valid complaint about the bug in SQL Server 6.5, but then showed a complete lack of knowledge of NT and SQL Server with the second flaw.

    I don't know how the first bug does in comparison to, say, Oracle databases (although I bet in several-year-old databases from them, there are a few SQL constructs you should avoid), but it is clearly a bug; and Microsoft never denied that, although in this article they denied that it affected the US Systems, which is believable - the US developers could have avoided (either deliberatly or by chance) the construct which caused the flaw, which the Russians did not.
    Convictions are more dangerous enemies of truth than lies.
  • The flaw is available in

    Basically, random errors appear in this structure:

    DECLARE @X int, @T varchar (255), @R int
    select @X = 0
    SELECT @X = id FROM sysobjects
    WHERE id > @X AND type = 'P'
    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

    The values of @X come out randomly wrong. The give a few examples of stored procedures which use that structure, and suggested workarounds.

    They all work fine on my SQL2k box (damn well hope so since they recommended an upgrade to fix it ;)... I'd be interested in what someone with a SQL6.5 box generated.
    Convictions are more dangerous enemies of truth than lies.
  • by mech9t8 ( 310197 ) on Tuesday July 24, 2001 @07:41AM (#65658)
    If you check the referenced source material you'll find that, in fact, there were severe bugs related solely to Microsoft's SQL Server which have not only compromised the Russian nuclear tracking system, but even more severely compromised the American nuclear tracking system

    Er, from your source...

    Then, in early 2000, they did something they didn't have to do: They warned the United States, believing that an analogous risk must exist in the U.S. system. Although neither Los Alamos nor the U.S. Department of Energy has publicly acknowledged the possibility that innumerable files on American nuclear materials might have disappeared, the Russian warning caused shock waves at the highest levels of the Energy Department.

    From the newer, more recent article...

    They say the bug that caused data to become invisible did exist, but was limited to one Russian facility that customized accounting software the lab had donated.

    You may dismiss the second article if you wish, but since the first article said "maybe" and had scant technical details (no reference to SQL Server, for example), and the second article was more recent and much more precise in detailing the problems, I'd take it as credible.
    Convictions are more dangerous enemies of truth than lies.
  • "At any rate, they were afraid," Blair said. "The Russians were very concerned that this posed a grave problem on the U.S. side."

    You think so? Why would the Russians be worried about United States operations? After all, we have the Microsoft database server to protect our data and nuclear weapon reserves, and the DMCA to protect our free speech.
  • by tb3 ( 313150 ) on Tuesday July 24, 2001 @06:00AM (#65660) Homepage
    Interesting, because they're 100% wrong!. Here's the original paper [] if which they describe the bug, that can be re-produced on any SQL Server 6.5 machine (the Microsoft support engineer managed to re-produce it).

    Further, Microsoft didn't offer a fix, as far as the document goes, they offered a workaround, that the russians rejected because it would mean changing about 5MB of source code.

    Check the document, it's a long read, but it certainly looks like Microsoft is lyin^H^H^H incorrect.

  • by Compulawyer ( 318018 ) on Tuesday July 24, 2001 @06:07AM (#65662)
    "There was never a bug..."

    "No nuclear materials were ever at risk..."

    "IE was not illegally 'tied' to Windows..."

    "MS is not a monopoly..."

    "Ok, if MS is a monopoly, we are a good monopoly..."

    "Consumers will benefit from Windows being able to do everything ..."

    "Consumers want us to control the world..."

    "I've been made King? Awww, shucks! You really shouldn't have..."

  • ...The Green, Glowing, Radioactive Cloud Of Death

    Oh wait, that's the meaning it already had...
  • by deaddrunk ( 443038 ) on Tuesday July 24, 2001 @05:52AM (#65669)
    When OSS becomes an effective monopoly and uses anti-competitive tactics to maintain its hold on a specific market then it, too, will become an object of hatred. Hating Microsoft is not a knee-jerk reaction for those of us who have to endure using sub-standard software every day.
  • by Anixamander ( 448308 ) on Tuesday July 24, 2001 @05:24AM (#65672) Journal
    This doesn't really seem to shed any light on the previous articles about this. Is this just another excuse to slap Microsoft around a little bit?
  • by MarkusQ ( 450076 ) on Tuesday July 24, 2001 @06:39AM (#65674) Journal
    Several people have been doubting that the SQL server bug is real, on the grounds that they would have seen it. While I don't know what the Russains found, I can report what my team discovered a few years ago on MS SQL 7.0; it sounds very like.

    It appears (we had no access to the source, so I can't do better than that) that if you have a complex select statement, with several nested sub-selects, you can get SQL Server into a state where it caches the query plan (roughly, the "compiled version") of some of the sub-queries from one execution to the next. This query plan sometimes acts as if it (incorrectly) includes information derived from other sub-queries as if it was constant. If in a subsequent use the value of these stored "constants" has changed, the where-clauses can fail, causeing the loss of rows in the result set.

    We went several rounds of reporting it to MS, bogged down on the "can you produce a simple case that exihibits the problem" phase, and wound you instituting coding guidlines to break such queries into multiple peices using temporary tables.

    Consequently I know that there are at least some bugs that are not seen by most users, and am more willing to credit this report than I was before I heard the keywords "SQL server" "complex queries" and "missing data".

    -- MarkusQ

  • by Paintthemoon ( 460937 ) on Tuesday July 24, 2001 @05:25AM (#65677) Homepage
    M$ just wants to acquire the resources to take on AOL-Time-Warner-Amazon...

  • I'm astonished that Russians trust software made by a US company to look after state secrets of this nature...
  • by Richard Bannister ( 464181 ) on Tuesday July 24, 2001 @05:25AM (#65680) Homepage
    I wonder how stable Windows CE for Nuclear Warheads(R) is. Of course we should expect a Mushroom Cloud of Death(TM) instead of a BSOD, though...
  • Well if you kick a dog everytime he comes near you, eventually he'll stay away, everyime you come near him he will run. Microsoft has put out so many bloated, inefficient, insecure programs that now it is simply assumed that any bug report on microsoft products is true (and it probably is). If it had been an open source database it would already have been completely patched a long, long, time ago. As for jumping to conclusions, Microsoft admitted there was a hole and said they patched it.....the only thing is it's Microsoft so of course we're not gonna trust them ( think of Outlook ), they said it wasn't a big deal....hmmm missing nuclear material not a big deal. I find the most scary knee-jerk thing about this article is the fact that a Microsoft (security through obscurity...yeah like win 2000 and IIS and Outlook and NT 4.* and below) product is being used to keep track of incredibley dangerous NUCLEAR MATERIAL. Don't you think that given MS's historic bad security and laziness in the area of good fast patches, having their product keep track of nuclear materials is scary to say the least?
  • by TechnoVooDooDaddy ( 470187 ) on Tuesday July 24, 2001 @05:30AM (#65687) Homepage
    "It's operating as intended", Bill Gates chuckles to himself as he closes the view port on his ever growing stockpile of weapons-grade nuclear material.

Houston, Tranquillity Base here. The Eagle has landed. -- Neil Armstrong