MS Cites National Security to Justify Closed Source

guacamolefoo writes: "It was recently reported in eWeek that "A senior Microsoft Corp. executive told a federal court last week that sharing information with competitors could damage national security and even threaten the U.S. war effort in Afghanistan. He later acknowledged that some Microsoft code was so flawed it could not be safely disclosed." (Emphasis added.) The follow up from Microsoft is even better: As a result of the flaws, Microsoft has asked the court to allow a "national security" carve-out from the requirement that any code or API's be made public. Microsoft has therefore taken the position that their code is so bad that it must kept secret to keep people from being killed by it. Windows - the Pinto of the 21st century."

Open source and security - some references

[dwheeler]

Ah yes, the "our APIs and code must be secret or the U.S. will crumble" defense. This is a particularly absurd claim for application programmer interfaces (APIs) - by definition, APIs are disclosed to other developers, so the only reason to "hide" them is to prevent competition. Oddly enough, the products where source code (not just the APIs) is visible have lots of quantitative evidence that they're more secure [dwheeler.com].

It's already been revealed that some attacker got into Microsoft's network. Also, CD's with Microsoft's source have been released for various reasons over time. I have no trouble believing that some "bad guys" already have the source code. So, how do the rest of us protect ourselves from these bad guys with the source code? And from the bad guys to come who don't have it yet... but will?

As noted in Secure Programming for Linux and Unix HOWTO [dwheeler.com], section 2.4.2 [dwheeler.com], closing off source code doesn't actually halt attacks anyway. Here's the quote:

It's been argued that a system without source code is more secure because, since there's less information available for an attacker, it should be harder for an attacker to find the vulnerabilities. This argument has a number of weaknesses, however, because although source code is extremely important when trying to add new capabilities to a program, attackers generally don't need source code to find a vulnerability.

First, it's important to distinguish between ``destructive'' acts and ``constructive'' acts. In the real world, it is much easier to destroy a car than to build one. In the software world, it is much easier to find and exploit a vulnerability than to add new significant new functionality to that software. Attackers have many advantages against defenders because of this difference. Software developers must try to have no security-relevant mistakes anywhere in their code, while attackers only need to find one. Developers are primarily paid to get their programs to work... attackers don't need to make the program work, they only need to find a single weakness. And as I'll describe in a moment, it takes less information to attack a program than to modify one.

Generally attackers (against both open and closed programs) start by knowing about the general kinds of security problems programs have. There's no point in hiding this information; it's already out, and in any case, defenders need that kind of information to defend themselves. Attackers then use techniques to try to find those problems; I'll group the techniques into ``dynamic'' techniques (where you run the program) and ``static'' techniques (where you examine the program's code - be it source code or machine code).

In ``dynamic'' approaches, an attacker runs the program, sending it data (often problematic data), and sees if the programs' response indicates a common vulnerability. Open and closed programs have no difference here, since the attacker isn't looking at code. Attackers may also look at the code, the ``static'' approach. For open source software, they'll probably look at the source code and search it for patterns. For closed source software, they might search the machine code (usually presented in assembly language format to simplify the task) for essentially the same patterns. They might also use tools called ``decompilers'' that turn the machine code back into source code and then search the source code for the vulnerable patterns (the same way they would search for vulnerabilities in open source software). See Flake [2001] for one discussion of how closed code can still be examined for security vulnerabilities (e.g., using disassemblers). This point is important: even if an attacker wanted to use source code to find a vulnerability, a closed source program has no advantage, because the attacker can use a disassembler to re-create the source code of the product.

Non-developers might ask ``if decompilers can create source code from machine code, then why do developers say they need source code instead of just machine code?'' The problem is that although developers don't need source code to find security problems, developers do need source code to make substantial improvements to the program. Although decompilers can turn machine code back into a ``source code'' of sorts, the resulting source code is extremely hard to modify. Typically most understandable names are lost, so instead of variables like ``grand_total'' you get ``x123123'', instead of methods like ``display_warning'' you get ``f123124'', and the code itself may have spatterings of assembly in it. Also, _ALL_ comments and design information are lost. This isn't a serious problem for finding security problems, because generally you're searching for patterns indicating vulnerabilities, not for internal variable or method names. Thus, decompilers can be useful for finding ways to attack programs, but aren't helpful for updating programs.

Thus, developers will say ``source code is vital'' (when they intend to add functionality), but the fact that the source code for closed source programs is hidden doesn't protect the program very much.

Microsoft source code is already available...

[RyanFenton]

Austria already has it. [microsoft.com]

Any U.S. University can apply for it now if they don't already have it. [microsoft.com]

Many of Microsoft's larger customers have it [com.com]

I don't see why it would be difficult for any terrorist organization to get it. How can they legitimately argue that it may possible be keep it secret at this point? If it's a national security risk to make the code available, the damage can no longer be avoided.

Ryan Fenton

Unfair to Pintos

[lrc]

Calling MS the Pinto of the 21st century is grossly unfair to Pintos. First, Pintos are a lot better than their reputation. The original 1600 pushrod motor is the same solid reliable block used in Cortinas (and most other English Fords) as well as having been raced for years in Formula Ford. The bottom end of that motor is used in Lotuses, as well as the Cosworth race engines (Formula Atlantic).

The 2 liter overhead cam motor in the Pinto is surprisingly good. When I raced a friends Capri with that motor, he said that he usually shifts between 7,000 and 8,000 RPM because it doesn't make any more power beyond that, but the motor will spin over 9,000 RPM without problems.

I've also seen Pintos win the SCCA racing class Improved Touring B, against cars like BMW 2002s.

Re:Don't pick on me! My software sucks!

[fermi's ghost]

Already happened:

USS Yorktown dead in water after divide by zero [ncl.ac.uk]

You're looking at it from the wrong side

[eddy]

Umm.. I don't think the issue is so much with poor documentation where documentation exists, I think the issue is more with non-existing documentation.

If you are looking at the whole system from the point of documentation, of course everything looks great? That's like looking at the world though a great big filter.

Instead you will have to go the other way; check all DLL/EXEs for exports, and then see if those exports are documented. Some exports aren't even done by name, but only by ordinal [gazonk.org], making them even harder to use.

I'm not a win32 guy either, so I can't give any concrete examples off hand, but I'm pretty sure this is partly where the issues lie.

You really cannot say the APIs are highly documented unless you have disassembled the code to see what it can really do, can you? Sure, there might be a hundred documented functions, but that is only impressive if there are only a hundred exports, and those exports are limited to the paramaters defined by the documentation.

How does this explain past viruses?

[cant_get_a_good_nick]

Hmmm, I don't remember that source code releases caused Nimda. Someone just probed with a long URL, caused a core dump (err, fault) realized this was from an unchecked buffer, and wrote the worm. No source needed to write the virus.

Melissa? A combination of knowing about a way too scriptable mail client, knowing that most folks don't have extensions showing (another great MSism, don't show people what they get from unknown, untrusted folks in the mail), even though most would probably click on a .vbs file anyway. Pick up a VB book, write a virus. No source needed to write the virus.

MS Word & Excel virii? Way too scriptable applications. Also from a VB book. No source needed to write the virus.

Besides, the errors need to be fixed. Secuurity through obscurity hasn't really worked so far.

Re:Hypocrits

[bmajik]

Microsoft never made the statement that "this product is bug free, and has no security concerns whatsoever".

The statement is, and always has been "we fix what we know about, if it wont break too much other stuff".

Incidentally, within some egregious time window (10 years ?) they fix it for free.

Thats the tradeoff the government willfully made when it wanted to use an off the shelf operating system, instead of doing it in house or submitting bids for a custom contract. (software that requires an ongoing support contract for security issues or _any_ issue at all)

What you're asking for would be something like an A1 system under the old pre-Common Criteria scheme... i.e. a provably correct system.

Guess how many products received A1 certs. Theres a list of some of them. It wouldn't take a long time to load the html. Even at 300bps.

Behaviors aren't consistent, etc...

[Svartalf]

For example, the GDI calls aren't the same for Win95 and WinNT- API-wise, they're the same, but they don't DO the same things when called, merely similar things. Worse, if you try to PRINT the graphic you just did, the result will differ from printer to printer under NT but be surprisingly consistent for 95 for all printers. There's tons of others in that space.

The API's declaration is consistent, but what one version of Windows DOES with the parameters may differ slightly or radically from another, supposedly identical one.

Re:They must be getting desperate...

[dbrutus]

It's been pretty clear for some time that Microsoft has backed away from its prior statements that the entire Win32 API is actually documented in those SDKs and that an ISV actually has a level playing field coding against internal MS programmers. Years ago they used to claim that there was a 'chinese wall' between the OS programmers and the App programmers and that there were no secret APIs, everything was in those $3k Universal Subscription mailings and the little guy had an even shot.

They don't do that anymore because people have reverse engineered enough of Windows and the MS apps that run on it to demonstrate conclusively that you've been fed a big fat lie. You don't have a level playing field and you never did.

This is a multi-billion dollar fraud and in large part it's what made Microsoft the uber-monopoly it is today (this was the grounds that the DoJ should have used to go after MS). The fact that you don't know that you've been shafted years after BillG and SteveB have admitted this in interviews leaves me speechless.

Kerckhoffs' Principle

[Martin Spamer]

Perhaps this Guy should have read this months (May 15, 2002) CRYPTO-GRAM by Bruce Schneier. The headline article is 'Secrecy, Security' and Obscurity' and covers the work of Auguste Kerckhoff, who in 1883, Yes 1883! demonstrated what has become know as Kerckhoffs' Principle, security by Obscurity is no security at all.

To quote Schneier: "Any system that tries to keep its algorithms secret for security reasons is quickly dismissed by the [cryptographic] community, and referred to as "snake oil" or even worse."

http://www.counterpane.com/crypto-gram.html

Re:Wrong! Power is in words, not wars!

[JimMcCusker]

This, of course, depends on what is known as Linguistic Determinism [google.com], otherwise known as the Sapir-Whorf Hypothesis [uwa.edu.au]. This has been refuted many years ago my many people, most notably Noam Chomsky. It basically boils down to the fact that you cannnot control throughts by controlling language as long as there are people who think nonlinguistically. These tend to include mathematicians, musicians, artists, designers, scientists, and others who are able to think mathematically, visually, or aurally.