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.
Huh ? (Score:1)
More scraping the barrel for anti-MS propaganda (Score:1)
The nuclear lab should migrate to MySQL... (Score:1)
Re:What if it was a bank? (Score:1)
Of course if that happens, you can alway wait for a co-worker to burn the building down.
Did Anyone Read the Article? (Score:1)
Re:Upgrade?!? (Score:1)
Re:Cached sub-queries (Score:1)
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.
dB (Score:4)
-k
I know that.. (Score:1)
A piece of advice (Score:5)
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.
Re:HEY! (Score:2)
From the article, it doesn't say exactly what the security problem was, you can't tell for sure that it was #2.
Re:Of course it's not a bug... (Score:1)
--M$ Press Agent
--
"If you insist on using Windoze you're on your own."
It's a part of the disposal plan (Score:2)
"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'."
Sorry.
/Janne
Fieros were safe. GM was stupid! (Score:1)
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
Re:Not True (Score:1)
Re:Nuclear? (Score:4)
Because it is NEWS of the most relevant kind (Score:5)
No. The article is either pro-Microsoft spin couched as innefectual criticism or profoundly incompetently written. If you check the referenced source material [cdi.org] 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.
Quit Spreading Disinformation -MS clearly at fault (Score:5)
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.
Re:Nuh-unh (Score:1)
--
Delphis
Re:Lost record every 1000 transactions: bullshit (Score:2)
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.
Re:Nuclear? (Score:2)
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.
Re:dB (Score:2)
Sounds ideal to me. I wouldn't want any potentially crackable database containing triggers for my nuclear devices. :^P
Nuclear DB Rewrite Forced By MS (Score:2)
This was included in a list of some MS hazardous materials systems [slashdot.org] which I had in an earlier post:
http://www.nrc.gov/NRC/COMMISSION/SECYS/2000-0163s cy.html#ATTACHMENT 4 [nrc.gov].
Hey, lameness filter. This ain't that comment. Stop making me rephrase it.Re:Upgrade?!? (Score:3)
{
upgrade.sell
}
See it's much easier this way.
Reminds me of something Neal Stephenson said (Score:5)
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.
Re:What if it was a bank? (Score:2)
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
Re:What if it was a bank? (Score:2)
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
Re:What if it was a bank? (Score:3)
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
What if it was a bank? (Score:5)
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
Re:Is this news? (Score:2)
Plausable Deniability (Score:2)
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.
*(names have been changed to protect the innocent)--
I know where the nukes went... (Score:2)
Re:dB (Score:2)
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...
- - - - -
Re:This got a +5 Funny ??? (Score:2)
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.
- - - - -
Re:Lost record every 1000 transactions: bullshit (Score:2)
- - - - -
Re:Upgrade?!? (Score:2)
A little less dramatic, but a problem nonetheless.
- - - - -
Re:Lost record every 1000 transactions: bullshit (Score:2)
- - - - -
SQL Server Insecure...If you have dumb admins (Score:4)
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.
Troy
Re:What if it was a bank? (Score:4)
Looking at my dictionary... flip flip flip flip flip... ahh, here it is:
Microsoft
No, I think his grammar is OK.
Re:Scary (Score:2)
God, Denise Richards is a terrible actress....
---
Re:dB (Score:2)
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.
--
My favorite Microsoft quote. (Score:2)
I agree with the Russians: this *is* a big security hole!!
Re:Nuclear? (Score:3)
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.
you didn't read the article (Score:2)
moderators - please mod the parent accordingly
It gives new meaning to the phrase... (Score:4)
Not bullshit (Score:2)
If you have time, read the paper. [cdi.org] It explains exactly what the bug is. Any summary is necessarily imprecise; however here's an attempt: the following code works: And the following code does not work: (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.
Re:Your code sample doesn't fly (Score:2)
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.
Nuclear? (Score:2)
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.
-jRe:Nuclear? (Score:2)
I think that makes it even scarier.
-jRe:Nuclear? (Score:2)
Philosopher? (Score:2)
Since when did the matrix become a philosophy text, and Keanu Reeves a Philosopher? As bill and ted would say: EXCELLENT! ::air guitar::
Re:Scary (Score:2)
Yes, this is news (Score:2)
Re:Lost record every 1000 transactions: bullshit (Score:2)
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.
Typical. (Score:2)
This is just so typical. Certanly noone else run complex code in a database environment.
Microsoft software controls nuclear resources? (Score:4)
Re:Upgrade?!? (Score:2)
Both of them?
Re:Nuclear? (Score:3)
And just for good measure (Score:2)
Re:What if it was a bank? (Score:2)
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: www.geekaustin.org [geekaustin.org]
Re:dB (Score:2)
Re:SQL Server Insecure...If you have dumb admins (Score:2)
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.
Get a clue (Score:2)
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.
Re:Upgrade?!? (Score:2)
IF
problem
THEN
Upgrade to a newer version
ENDIF
Hacker: A criminal who breaks into computer systems
Re:dB (Score:2)
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.
Re:Lost record every 1000 transactions: bullshit (Score:2)
Re:dB (Score:2)
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.")
J
Re:Fieros were safe... - Way offtopic now (Score:2)
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.
Re:What if it was a bank? (Score:2)
-Bill
Re:What if it was a bank? (Score:2)
sabotage your enemy (Score:3)
Make them use Microsoft.
disclaimer: no offense intented
Of course it's not a bug... (Score:4)
Wait... (Score:3)
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...
Encarta Dictionary (Score:2)
Clearly, you weren't using either:
Reactors (Score:2)
How did this ever become a story (Score:4)
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.
Re:Lost record every 1000 transactions: bullshit (Score:2)
Lost record every 1000 transactions: bullshit (Score:5)
Upgrade?!? (Score:5)
---
The full scoop (Score:2)
Re:dB (Score:2)
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
Reading the articles you can see they concern the problem with closed source, not the brand itself.
Interesting (Score:2)
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.
Meltdown on Redmond (Score:2)
No, really. What scares the sh1t out of me is that someone would seriously consider AND use M$ products in a nuclear facility.
---
Re:There is no such thing as a bug (Score:2)
The computer does *exactly* what the programmer told it to do.
--
Two witches watched two watches.
Re:Upgrade?!? (Score:2)
--
Two witches watched two watches.
Re:Upgrade?!? (Score:2)
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.
Re:Cached sub-queries (Score:2)
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'
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
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
--
Convictions are more dangerous enemies of truth than lies.
Re:Because it is NEWS of the most relevant kind (Score:3)
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.
Russians conserned? (Score:2)
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.
Re:Interesting (Score:5)
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.
Mr. Gates says.... (Score:4)
"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..."
Sorta gives new meaning to... (Score:2)
Oh wait, that's the meaning it already had...
--
Re:Nuclear? (Score:3)
Is this news? (Score:5)
--
Cached sub-queries (Score:5)
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
First strike capability. (Score:5)
Spyware? (Score:2)
Scary (Score:5)
Re:Nuclear? (Score:2)
The software is not buggy... (Score:5)