Slashdot Mirror


Open Source a National Security Threat

n3xup writes "Dan O'Dowd, CEO of Green Hills Software, suggests that open source software has the capability of being sabotaged by foreign developers and should not be used for U.S. military or security purposes. He likened Linux with a Trojan Horse- free, but in the end a lot of trouble. O'Dowd thinks that unfriendly countries will attempt to hide intentional bugs that the Open Source community will have no chance of finding."

166 of 921 comments (clear)

  1. Understand the Source Perspective by stecoop · · Score: 5, Insightful

    Understand the source perspective before you draw opinions. Green Hills is under threat from Linux due to the embedded software being integrated in more Government system. GreenHills is (was?) a large player in government based Embedded Operating Systems. I imagine you will see a similar stance by WindRiver maker of the popular Realtime Embedded OS VXWorks.

    The threat comes from the length of time on some large government projects. Some systems have been around longer than you and me. In the proprietary world, your whole project is dependent on a set of companies staying in business for 30+ years. Now with Linux, you're no longer dependent on that string; you can leverage off the community providing updates or if necessary you as the developer can make the changes. Most people fail to say this with Linux; everyone just says hey it's free and cheap. But if you really want to sell Linux, try saying that your entire project doesn't fall on another proprietary solution, we will have the source code in hand - people will listen.

    It's easy to retort GreenHills FUD by saying all changes will be baselined and a change control board will review any updates (easy enough huh).

    1. Re:Understand the Source Perspective by proj_2501 · · Score: 4, Insightful

      do we even need another comment on this story?

    2. Re:Understand the Source Perspective by danheskett · · Score: 4, Insightful

      It's easy to retort GreenHills FUD by saying all changes will be baselined and a change control board will review any updates (easy enough huh).
      Actually, not easy enough.

      Can you honestly tell me that the government is going to hire a panel of people to check in in-depth source changes on OSS projects? People who are familiar enough that they can catch an exploit that may only take 3-4 lines of code to perform?

      Let's say I knew that DoD used a certain package in gunnery firmware. Let's say a math library that would be used to make calculations to calibrate the weapon. How hard would it be to build in a small tiny bit of error that would only be useful in cases of calibration of high-tech weapons? If 3000 lines of dense mathematically rich C were checked in and a dozen lines acted in concert to create a miscalculation, how much expertise would be needed to catch that?

      I think that having experts able to review each line of code checked in and put into production defeats the whole idea of using Open Source: at that point, you might as well just hire the experts to write the code in the first place and eliminate the vector all together.

    3. Re:Understand the Source Perspective by drinkypoo · · Score: 5, Funny

      No, but that's never stopped slashdot before :)

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    4. Re:Understand the Source Perspective by torpor · · Score: 2, Interesting


      I'm a developer, working for a relatively successful hardware company in a non-U.S. land, and I have every intention of hiding all sorts of stuff in any Open Source code I may (or may not, thats freedom) contribute to! :P

      Whether what I hide will be nefarious is one thing, whether or not Easter Eggs can still exist on Open Source Island is another thing entirely ...

      --
      ; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
    5. Re:Understand the Source Perspective by Coz · · Score: 5, Insightful

      You have one set of experts write the code under an F/OSS license, another set of experts examine the code, test cases, and test results.

      Believe me, if you're talking about something like gunnery firmware, they're going to test it... the deepest fear in DoD these days is friendly fire.

      --
      I love vegetarians - some of my favorite foods are vegetarians.
    6. Re:Understand the Source Perspective by Oddly_Drac · · Score: 2, Funny

      "Embedded Operating Systems"

      Just a very brief point, but how do you fix embedded system bugs? Am I incorrect in thinking that embedded means that the OS is onchip?

      --
      Oddly Draconis
      Too cynical to live, too stubborn to die.
    7. Re:Understand the Source Perspective by Total_Wimp · · Score: 5, Insightful

      Can you honestly tell me that the government is going to hire a panel of people to check in in-depth source changes on OSS projects?

      More to the point, will they do this with closed source projects? Getting a mole into Green Hills Software, Microsoft, etc is every bit as real of a threat as getting one into any open source project. In many cases it might even be easier because of the lack of good hiring practices and oversite at small defense companies.

      TW

    8. Re:Understand the Source Perspective by tcopeland · · Score: 4, Insightful

      > How hard would it be to build in a small
      > tiny bit of error that would only be
      > useful in cases of calibration of
      > high-tech weapons?

      I think it'd be tricky, because it would break other high-precision things as well. And the other folks using the open source project would say "hey, this fellow Fred just submitted a patch. something looks odd about it. Fred, why does line 314 do a bit shift without checking the foobar?" And then the patch would be rejected.

      > If 3000 lines of dense mathematically
      > rich C were checked in

      I doubt any maintainer would accept such a patch. I don't accept patches for PMD without reading them, and if I got a 3K line patch I'd reject it out of hand.

    9. Re:Understand the Source Perspective by Anonymous Coward · · Score: 2, Interesting

      Can you honestly tell me that the government is going to hire a panel of people to check in in-depth source changes on OSS projects? People who are familiar enough that they can catch an exploit that may only take 3-4 lines of code to perform?

      The DoD? Sure, why not. Who is going to audit and check every change to a closed source, proprietory system? The developers? Why should the government trust them over a different group of developers?

    10. Re:Understand the Source Perspective by hawkeyeMI · · Score: 2, Insightful

      Two words: equipment testing

      --
      Error 404 - Sig Not Found
    11. Re:Understand the Source Perspective by Altus · · Score: 5, Interesting


      thats why you do testing and code reviews. its not like these people are downloading new kernals in the field, any code that goes into a government project requires immense testing and code review... PERIOD. I dont care who wrote it.

      if the military wanted to use open source software they would likely take the source and lock it down, producing a branch, for them that would be secured and standardized after a large review. if they wanted to bring in new functionality from the "public" branch it would mean a new verion of their "secure and approved" branch which would have to go through the same review process again.

      Its not like they dont have to do this anyway with the code they produce now... sure they arent expecting people to try an sabotage them but you can do that without intention simply by making a coding error. Testing & code review is essential to the process.

      this isnt that much differnt that what the military does with hardened versions of comercial processors... sure they lag behnind their comercial counterparts because they have to be hardend and tested heavily, but then they work, and they are able to leverage the initial design work and testing done when the hardware was being developed for comercial purposes.

      --

      "In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson

    12. Re:Understand the Source Perspective by _Sprocket_ · · Score: 2, Insightful


      Can you honestly tell me that the government is going to hire a panel of people to check in in-depth source changes on OSS projects? People who are familiar enough that they can catch an exploit that may only take 3-4 lines of code to perform?

      ...

      I think that having experts able to review each line of code checked in and put into production defeats the whole idea of using Open Source: at that point, you might as well just hire the experts to write the code in the first place and eliminate the vector all together.


      No - the Government will contract a company to do this for them. The difference is that when the contract comes up for bid, they will both have the source code involved and a better chance of finding competing contractors able to work with that code. At worse, they'll end up contracting with an outfit that is unfamiliar with the code and has to ramp-up... which isn't much different from a proprietary-based situation. Which brings us to a very important point...


      If 3000 lines of dense mathematically rich C were checked in and a dozen lines acted in concert to create a miscalculation, how much expertise would be needed to catch that?


      Are you implying that 3000 lines of proprietary code is going to go in to a system without any checks? And once that code is incorporated in to the system, that system is not going to undergo a strict battery of tests?
    13. Re:Understand the Source Perspective by GoofyBoy · · Score: 3, Insightful

      >In many cases it might even be easier because of the lack of good hiring practices and oversite at small defense companies.

      What hiring practices does Linux have?

      Defense companies have to go through a certain amount of security and background checks to win a contract.

      --
      The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
    14. Re:Understand the Source Perspective by D3 · · Score: 5, Interesting

      The NSA already produces their own version of secure Linux. It wouldn't surprise me one bit that they check that code very carefully. I doubt they just grab a copy of the RedHat ISO images and lock down the starup files.

      Also, your code would have to be integrated enough into the calculations to only mis-fire when aimed at a certain target or to mis-fire at a set percentage. If the mis-fires were too high they wouldn't buy off on the weapon.

      --
      Do really dense people warp space more than others?
    15. Re:Understand the Source Perspective by Lumpy · · Score: 4, Informative

      Let's say I knew that DoD used a certain package in gunnery firmware. Let's say a math library that would be used to make calculations to calibrate the weapon. How hard would it be to build in a small tiny bit of error that would only be useful in cases of calibration of high-tech weapons? If 3000 lines of dense mathematically rich C were checked in and a dozen lines acted in concert to create a miscalculation, how much expertise would be needed to catch that?

      so you are telling us that if they BUY the software form XYZ company they blindly accept it as perfect and simply use it without question??

      if so, then I really need to look at emigrating out of the United States because the levels of incompetence is getting insane.

      I dont care if it's free/oss or a 60bajillion dollar closed source software written by aliens from alpha centauri. if it's something you absolutely rely on, you had damn better check it completely. OSS should abide by the same rules that the other stuff does.... check it completely from beginning to end.

      --
      Do not look at laser with remaining good eye.
    16. Re:Understand the Source Perspective by kfg · · Score: 5, Informative

      Can you honestly tell me that the government is going to hire a panel of people to check in in-depth source changes on OSS projects?

      The American government actually has an entire agency whose job is to perform just such tasks.

      It's called the NSA.

      Will the NSA actually perform this function with OSS?

      They've already made their own distro.

      KFG

    17. Re:Understand the Source Perspective by Anonymous Coward · · Score: 5, Insightful

      What hiring practices does Linux have?

      Doesn't matter one jot. Gee, look, there's the source code. Every bug, hole and trojan horse, just waiting for you to find them. All you have to do is audit the code. You should be auditing the code of any product you're going to use in a sensitive enviroment anyway, wether it's closed or open source. Where's the difference?

    18. Re:Understand the Source Perspective by Zocalo · · Score: 4, Insightful
      Who needs a mole at Green Hills Software or Microsoft? The kind of software we are talking about here is highly proprietary stuff that you are not going to be able to get mail order from your local retailer. A better bet would be to target any third party libraries the vendors are using; almost no one would write their own IP stack when they can by one for a few dollars. Sooner or later you are going to get one that might have been bought from a legitimate company in the US, but was actually coded by easily bribable coders in the third world.

      If anything, I'd say the risk of getting exploits deliberately planted in code without detection are far greater in closed source applications than in OSS projects. Another lame attempt at FUD from the people behind AdTI..

      --
      UNIX? They're not even circumcised! Savages!
    19. Re:Understand the Source Perspective by Dare+nMc · · Score: 2, Insightful

      > you might as well just hire the experts to write the code in the first place and eliminate the vector all together.

      and where do they find the expert to hire in the first place? the beauty of Version controll in a OSS is that you can find exactly who programmed the code, and if you do the background check, and he is hireable, you use him, and his code. if not you have the choice of finding another expert to re-write just that section, or thourghly review his sections...

      try to find out exactly which indian contractor did that work for the closed source contractor, and trust them to tell you, oh ya we hired an extremist, but he didn't do that part of the code ;) ;)

    20. Re:Understand the Source Perspective by Atzanteol · · Score: 2, Insightful

      Perhaps, but renouncing what they say because of who they are is not exactly correct either. It's a fallacy to claim 'A' is false becuase the person saying it is 'B'.

      If a man on death row for murder tells you that murder is wrong, is he incorrect simply because of who he is?

      Sure they (Green Hills) have an agenda, and it should be noted. However, they may have a point and shouldn't be discredited out of hand.

      --
      "Ignorance more frequently begets confidence than does knowledge"

      - Charles Darwin
    21. Re:Understand the Source Perspective by demachina · · Score: 5, Insightful

      "how much expertise would be needed to catch that?"

      Uh, not much. If the weapons aren't hitting the mark on the firing range they probably wouldn't get deployed until they are fixed.

      This is probably a poor example. The danger isn't in OSS that is designed to fail. If it doesn't work it wouldn't get used. The danger is an obscure security hole that would allow infiltration.

      The key point where this guys whole argument falls apart is that proprietary software isn't any better. I'm confident Microsoft employs a small army of foreigners, and I'm not sure they would be any more reliable than OSS developers and their code gets a lot less scrutiny, and absolutely none if you are a customer getting binaries. Most big companies are putting R&D centers in India and China. How do they assure us the people they are hiring don't have ulterior motives.

      If you want to develop software critical to national security you have to develop it in a classified lab with cleared employees. Oh but wait, in spite of all the scrutiny people with get security clearances get, they also turn out to be foreign agents and do great damage. Los Alamos doesn't exactly have a stellar security record and those people get more scrutiny than anyone. The Navy's comsec and has been massively compromised in the past.

      I'd argue the opposite case from this guy. If you want secure software the best approach is to have as many people possible, both OSS and governemnt, scrutinize the source. If you find a project that is intentionally or negligently checking in compromised code black list them or give them extra scrutiny. The NSA's secure linux effort is an example of the government making sure OSS is secure and its way more likely to be that, than anything Microsoft or Green Hills is going to give them.

      On a tangent here is an interesting article on Homeland Security trying to enforce security through obscurity in the physical world. Someone walked around the DNC and took photos of all the weaknesses in their security in Boston and posted it on a list on Yahoo. Homeland security shut down the list and is collecting the names of everyone on the list and everything said. Should give you pause before joining any list in these interesting times.

      --
      @de_machina
    22. Re:Understand the Source Perspective by danheskett · · Score: 3, Insightful

      The question is though:

      Is it possible that an unknown/untrsuted person could engineer a bit of code that would pass initial scrutiny but still be dangerous?

      The answer to that is an unqualified yes, I believe. The auditors would have to audit every bit of the toolchain, the compiler and linker, and the rest of the system to be able successfully rely on the code audit.

      You should be auditing the code of any product you're going to use in a sensitive enviroment anyway, wether it's closed or open source.
      Absolutely. The point being however that's harder and you have more code to audit in the open source world. In the closed source/defense world, they rarely change things like compilers, build environments, etc. In the open source world it becomes difficult if you want to work with a compiler 6 years old, let alone 2 or 3 or 4 years old. As a test, get the latest glibc and compile it with a 3 year old copy of GCC.

      I am not saying it's a definitive answer one way or another.. just that it's hard.

    23. Re:Understand the Source Perspective by Abcd1234 · · Score: 2, Insightful

      LOL! You're telling me that you think the government will replace "defense companies [that] have to go through a certain amount of security and background checks" with unverified open source software? Please... if security matters *that* much, the government will either 1) continue to hire secure defense companies or 2) hire a secure defense company to verify the safety of any open source they use.

    24. Re:Understand the Source Perspective by passthecrackpipe · · Score: 3, Insightful

      the deepest fear in DoD these days is friendly fire.

      No it isn't - if it was, they would have burned all the patriot systems already. the biggest fear in DoD is making sure their pet contractors stay on the payroll so that they keep getting their kickbacks.

      --
      People who think they know everything are a great annoyance to those of us who do.
    25. Re:Understand the Source Perspective by Merdalors · · Score: 2
      do we even need another comment on this story?

      That's an interesting comment on the rigid orthodoxy of this forum.

      Nevertheless, always an interesting read.

      --
      Slashdot entertains. Windows pays the mortgage.
    26. Re:Understand the Source Perspective by AndroidCat · · Score: 2, Informative

      Embedded is one of those Humpty-Dumpty type words. It used to be only for firmware stuff, but now it's used to cover any kind of batch job or server app.

      --
      One line blog. I hear that they're called Twitters now.
    27. Re:Understand the Source Perspective by tomknight · · Score: 2, Insightful
      That's not the DoD's deepest fear, more the MOD's deepest fear...

      Tom.

      --
      Oh arse
    28. Re:Understand the Source Perspective by danheskett · · Score: 3, Insightful

      I think it'd be tricky It would be possible though to engineer a specific set of cases so that a less-than highly used library would produce certain results for only a single user (or a small handful of users). It could be so crafty as well. I can imagine setting things up so that when a certain "bug" I introduce is fixed the real behaviour I wanted becomes apparent. How could you prove I set out to intentionally make that error?

      Fred, why does line 314 do a bit shift without checking the foobar?" And then the patch would be rejected.
      You and I know however that over time maintainers become more and more trusting of what a submitter gives them. How long would one need to invest to get the trust of a submitter? 3 months? 6 months? What if a person contributed weekly to a project a front-company for six months.. what level of scrutiny would that patch receive?

      doubt any maintainer would accept such a patch. I don't accept patches for PMD without reading them, and if I got a 3K line patch I'd reject it out of hand.
      How long would it take for a badly intentioned person to take over as a maintainer? A year, two years?

    29. Re:Understand the Source Perspective by killmenow · · Score: 4, Insightful
      What hiring practices does Linux have?
      Peer review. I imagine Linus, Alan, Andrew, Ingo, Tigran, et. al., are more capable of: A) reviewing code submitted for inclusion in the Linux kernel; B) understanding its purpose; C) deciding who to trust to write proper code; and, D) actually committing the code into the kernel THAN ANY GOVERNMENT OFFICIAL.

      As evidenced by his desperate attacks to stave off his dwindling market share, they're obviously doing a better job than the Green Hills CEO.
    30. Re:Understand the Source Perspective by danheskett · · Score: 2, Informative

      the government trust them over a different group of developers?

      I've worked for government projects on a lower-level of security/oversight than the DoD. Here are some reasons.

      1. Background checks. Not just instant ones, ones overseen by an actual person at the DOJ.

      2. Penalty of Law. Programming logs and notes are kept to incredible detail. Every scrap of source is accounted for. If someone intentionally threw some nasties in it, well, it wouldn't take long for you to be in jail.

      3. Financial motivation. Bad software/buggy software/trojan'd software will lead to cancelled contracts. That's bad for the contractor. It also leads to strict internal guidelines and procedures. Especially in companies where 100% of the company business is Defense contracting.

      4. Trusted base. Most/many of the projects are based on trusted platforms or semi-trusted platforms. If you only have to review the changes to an exisiting system it is much more appealing than starting from scratch.


      Again, I am not saying that OSS should or shouldn't be used for certain projects. Just that it's not a no-brainer one way or the other.

    31. Re:Understand the Source Perspective by danheskett · · Score: 3, Insightful

      Peer review. I imagine Linus, Alan, Andrew, Ingo, Tigran, et. al., are more capable of:
      Except that Linus himself has said that the sheer volume of patches coming into the kernel means he barely scans the patches before accepting them. It's very difficult to tell what minor changes a small fix will have. Just ask people who have to debug problems in the kernel. It's not fun/easy/simple.

      Also, we are not just talking about the "brand name" projects. We are talking about the unsexy, not-front-page projects. The things at risk are the ones without thousands of eyes looking at it. It's the ones with just dozens, or a handful of eyes, looking at it. Projects that make up stuff in the buildchain. Projects like filesystem drivers. Projects like device drivers. Compilers. Linkers. All of them would have to be validated and audited, for each change, for each version, on each platform. A malicious patch anywhere along the way can lead to a trojan. Even code that otherwise looks good could be poisoned. A single unchecked buffer. A single small simple looking error - big consequences.

    32. Re:Understand the Source Perspective by Rei · · Score: 2, Insightful

      Yes, that is a good point, but there's another reason why this argument is bunk: Linux is written by a lot of non-Americans, but so is Windows, and essentially every other operating system developed by anyone other than the US military. The same appliess for software in general. So then, the argument needs to be: Which one is easier to audit and has better *creation time auditing*?

      The answer should be obvious.

      --
      SILENCE BLATHERING TOADIES! We are your new masters.
    33. Re:Understand the Source Perspective by danheskett · · Score: 2, Insightful

      I can imagine dozens of ways to break test cases. Like a slowly degrading precision value.. during testing it would show fine.. on the battlefield after a few days the precision would begin to drift.. drift... and drift.. it would be very hard to test for it. It would pass verification and testing without fail everytime. But after 36-48 hours of heavy real-life usuage, it would be effectively useless. Design a test system that would catch this (I'll give you more than two-words)

    34. Re:Understand the Source Perspective by Tony-A · · Score: 2, Informative

      I think it'd be tricky, because it would break other high-precision things as well.

      Run something with a known analytic solution through an artificially complicated computation to achieve the same solution. Any error means something is wrong. Somewhat like recompiling the kernel to check for strange memory errors. Too many eyes. Too many idle hands with idle computers.

      Extremely more likely to get away with it with closed source because the scrutiny is less and much more predictable. By the time an open source gets anywhere near serious, there are egos to contend with. It's open. It's shared. But there's something even stronger than the "Not Invented Here" syndrome. An indication was when OpenBSD said "Everybody patch OpenSSH." Debian said "Show us the exploit." If OpenBSD doesn't get instant credibility on a security issue, notbody else is going to get much either.

      There is an issue if the code itself is weak. With open source it will be found out and everybody will know about it. With closed source the odds favor your enemy knowing that you have no idea of.

    35. Re:Understand the Source Perspective by pestie · · Score: 2, Interesting

      How carefully do you suppose those defense contractors screen their subcontractors in India?

    36. Re:Understand the Source Perspective by duffbeer703 · · Score: 4, Interesting

      Friendly fire is a fact of life for surface based anti-aircraft weaponry. Creating a spoof-proof friend or foe anti-aircraft system is a non-trivial problem.

      That's one of the reasons why the US has always focused on fighter aircraft at the expense of anti-air artillery and SAM systems.

      --
      Conformity is the jailer of freedom and enemy of growth. -JFK
    37. Re:Understand the Source Perspective by Rei · · Score: 5, Interesting

      I think the DoD's biggest fear concerning OSS is not that the software is too insecure, but that it is *too good* for something available in the public domain. If other countries can get all of the tools they need for a weapon apart from, say, a specific 1000-line guidance or control program, and can make any changes to the tools that they need, that gives them a *major* bonus. Lets not forget how hard our government has worked to stop the export of technology in general - including software - to countries deemed "enemies".

      --
      SILENCE BLATHERING TOADIES! We are your new masters.
    38. Re:Understand the Source Perspective by GeckoX · · Score: 2, Interesting

      So that'll be the solution then, have Linus et al peer review all OSS code and problem solved?

      Just how much code do you think Linus is actually involved with? Really now. Last I checked, him especially, and most of the rest of the crew you mention, live and breath in kernal land. Think they've been over the code in every module out there? Think they know the code for Open Office inside and out? Come now.

      Bottom line, if security is _that_ important, the code will be written and maintained IN HOUSE. Period. There is just NO viable alternative to this that is as secure, and even at that level (which is how this kind of thing is done NOW), there are usually many people working on any given coding project, broken into little bitty units that aren't useful on their own, and implemented in parallel by multiple developers so that cross-checking etc can be done to reduce the possibility of a mole actually being able to do any kind of damage.

      So, the bigger question is then deciding which projects it is acceptable to use OSS for, and which are not. I am quite sure I'll be modded into oblivion for saying this, but it is the blatant truth: OSS is NOT a silver bullet. It will NOT solve all of the worlds programming problems. And it is NOT appropriate for all situations.

      --
      No Comment.
    39. Re:Understand the Source Perspective by sean.peters · · Score: 2, Informative

      The danger is an obscure security hole that would allow infiltration.

      The key point where this guys whole argument falls apart is that proprietary software isn't any better.

      IAAWSSE (I am a weapons systems safety engineer) and I can tell you there's another point where this argument falls apart. It's not like weapons systems software is accessible via the Internet - there's an "air gap" between these kind of systems and the rest of the world. So even if there are security holes in the software, it's not like J. Random Hacker is going to be able to connect to these systems to exploit them.

      While insider attacks are possible, a) the people who operate these things are fairly thoroughly checked out before they get in the military, b) generally speaking, they have a vested interest in having their systems operate properly, and c) if in spite of all that, they were still motivated to do mischief, they'd have to be signed into a military computer terminal somewhere inside the system... and chances are very high they'd be caught.

      Sean

    40. Re:Understand the Source Perspective by tcopeland · · Score: 2, Interesting

      > a less-than highly used library

      I think this is the tricky part here, though - will a little-known open source math library be used for, say, target software in a M109A6 howitzer? I think it's a bit unlikely.

      > How could you prove I set out
      > to intentionally make that error?

      The problem is that a typical open source project maintainer will not be concerned with _why_ a patch contains buggy code. Instead, he'll run the current suite of tests, they'll fail, and he'll reject the patch.

      > How long would one need to invest to
      > get the trust of a submitter?

      Of course, any system is fallible. But how long would it take for a person with bad intentions to be hired by a commercial company? Or, better yet, for a current employee to be bribed? That'd be a much faster route. And who would ever catch the hidden evil, since the code would only be readable by a select few?

      Open source processes aren't failsafe - but neither are commercial company processes.

      > How long would it take for a badly
      > intentioned person to take over as a
      > maintainer?

      Same as above, I feel.

      Incidentally, thanks for taking the time to respond to my post. This is a good issue to discuss, I think.

    41. Re:Understand the Source Perspective by Altus · · Score: 2, Interesting


      Is it possible that some known and trusted employee could make a subtle mistake that goes uncaught and results in a buffer overflow.

      the answer to that is an unqualified yes.

      military source goes through review and testing the likes of which is seen in few industries (perhaps medical/lifesupport systems... cant think of any other) this will always be the case, and infact must be the case no matter who is writing the code.

      --

      "In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson

    42. Re:Understand the Source Perspective by Sxooter · · Score: 2, Interesting

      Have you ever submitted code to Linus, Alan, et. al.? They're total code nazis. Many many patches never make it in because it's insecure / poorly indented / poorly written.

      I.e. the kernel hackers don't just toss patches at the kernel and see what sticks, they review patches very carefully. And toss out a lot of them.

      --

      --- It is not the things we do which we regret the most, but the things which we don't do.
    43. Re:Understand the Source Perspective by gilesjuk · · Score: 2, Informative

      Exactly!

      Besides, both Linux and Windows get plenty of hack attempts and plenty of holes are closed. So neither is probably that ideal for military use.

      Nothing will ever be that secure, they should take steps to make sure their systems aren't exposed to the public, private networks, no dialup numbers, no use of wifi etc..

    44. Re:Understand the Source Perspective by Total_Wimp · · Score: 2, Insightful

      Also, we are not just talking about the "brand name" projects. We are talking about the unsexy, not-front-page projects. The things at risk are the ones without thousands of eyes looking at it. It's the ones with just dozens, or a handful of eyes, looking at it. Projects that make up stuff in the buildchain. Projects like filesystem drivers. Projects like device drivers. Compilers. Linkers. All of them would have to be validated and audited, for each change, for each version, on each platform. A malicious patch anywhere along the way can lead to a trojan. Even code that otherwise looks good could be poisoned. A single unchecked buffer. A single small simple looking error - big consequences.

      But really you're talking about the same exact problem for closed sourse. In that 5-person dev team with 2 QA people in that 20-person company how closely are they checking the source for the type of stealth errors in question? Do they personally check the thousands or millions of lines of code in the build chain? Once a guy is hired, how much contact does he have with his boss? Does his boss even understand the code the "honest worker" is submitting?

      I'm NOT saying the open source is "safe." I'm saying that closed source is every bit as unsafe but with the added hinderence of much fewer people haveing the ability to even look at the source if something goes wrong.

      TW

    45. Re:Understand the Source Perspective by j1m+5n0w · · Score: 4, Insightful
      The auditors would have to audit every bit of the toolchain, the compiler and linker, and the rest of the system to be able successfully rely on the code audit.

      Even that might be insufficient. Ken Thompson showed in his '95 Turing award speech how a compiler trojan can exist even if the backdoor is not present in the compiler's source code.

      Here's the link.

    46. Re:Understand the Source Perspective by hawkeyeMI · · Score: 2, Insightful
      How much of the time that equipment is being used do you think it is in actual battle situations as opposed to practice/training. Aside from initial testing, equipment is used in a variety of places and scenarios not involving engagement with a real enemy, including war games, before being used in an actual battle.

      Aditionally, what you specified is more complex than what was originally posited, and seems more likely to be detected in code. There are a lot of other issues, but these are covered by the many other threads on this story.

      --
      Error 404 - Sig Not Found
    47. Re:Understand the Source Perspective by rascal1182 · · Score: 2, Funny

      Have you ever submitted code to Linus, Alan, et. al.? They're total code nazis.

      Exactly. We don't want any Nazis in charge of our defense systems. That's a security threat.

      --

      "Yarrgh! I be just a paintin' of a head..."
    48. Re:Understand the Source Perspective by Giggle+Stick · · Score: 3, Interesting

      I wonder if they've found any security vulnerabilities that they aren't telling the world about? They would fix it in their versions, but leave it in the main one, so that they could exploit it against enemies that are using Linux and other GNU stuff.

    49. Re:Understand the Source Perspective by Jim_Maryland · · Score: 2, Insightful

      Security organizations do not generally use the latest available releases of open or closed source software and it's generally due to the fact that the software must be reviewed. Commercial entities are more likely to keep up with frequent software updates and not perform the software audits that you find in secure organizations.

      Software is reviewed carefully before being allowed onto secured networks. Just ask anyone who works on projects where a deadline is missed due to security reviews.

    50. Re:Understand the Source Perspective by GCP · · Score: 5, Insightful

      do we even need another comment on this story?

      Yes, of course, because the fact that open source has some advantages doesn't negate the risk pointed out in the article. It just means that their are risks both ways.

      ANY piece of software that you run on a secure system has the potential of subverting the system. I think open source does create the illusion that it couldn't contain hidden malware because where could it hide in open source, right? Well, anyone who has ever seen the entries in an obfuscated C contest and wondered what that code could possibly do ought to be able to see the flaw in that argument. For that matter, anyone who has ever gone over and over HIS OWN CODE looking for a bug and not finding it ought to ask himself, what if it weren't even my own code and I didn't even know that a bug existed?

      Closed source is even worse in this respect, though, but at least we know who wrote it, right?

      Well, I think that's yet another illusion. Think disgruntled employees being paid by Bad Guys to insert a bit of code.... You may trust the company that made your software, but how can you possibly trust every one of their employees? And once it's in, since it's trusted it could be there for years.

      --
      "Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
    51. Re:Understand the Source Perspective by AbbyNormal · · Score: 2, Interesting

      Right, but wasn't the PS2 considered a military weapon by Japan (mostly for marketing) because of its image capacities? Sorry, technology is already out of the bag...its how you use it that counts.

      --
      Sig it.
    52. Re:Understand the Source Perspective by surprise_audit · · Score: 2, Insightful
      Well, I think that's yet another illusion. Think disgruntled employees being paid by Bad Guys to insert a bit of code.... You may trust the company that made your software, but how can you possibly trust every one of their employees? And once it's in, since it's trusted it could be there for years.

      And then, of course, there's the question of outsourcing to a foreign country... Who's to say that the programming companies in India (or anywhere else) don't have some disgruntled employees among them? And I don't mean disgruntled with their own bosses, so much as disgruntled at the rich western nations that take advantage of the poorer eastern nations.

      How is Open Source different from that? Oh yeah, you pay more for outsourcing...

    53. Re:Understand the Source Perspective by at_kernel_99 · · Score: 5, Insightful

      Closed source is even worse in this respect, though, but at least we know who wrote it, right?

      Well, I think that's yet another illusion. Think disgruntled employees being paid by Bad Guys to insert a bit of code.... You may trust the company that made your software, but how can you possibly trust every one of their employees? And once it's in, since it's trusted it could be there for years.

      Exactly. The author also helpfully ignores the backgrounds - often unknown by the enduser - of the developers of closed source software. I've been in this industry for 12 years and have worked in one place (out of 7) that did not have a foreign national on the team. Ethnicities have included China, Vietnam, Russia, India, Pakistan and Syria.

      The only point the author made that I could agree with would be that all software used for the military/intelligence communities should be thoroughly tested & certified to a high standard of security. I doubt there are many that would disagree with this statement. The problem is the author is hiding this valid argument beneath a layer of FUD intended solely to harm Linux & support the proprietary development model his company has chosen. He uses fear & stereotypes to paint the opposition without explaining what his company is doing that will solve the problem in a way that open source cannot.

    54. Re:Understand the Source Perspective by Dashing+Leech · · Score: 4, Informative
      Closed source is even worse in this respect...

      Absolutely. Any to anyone who cares to argue that proprietary companies are more strict in reviewing their own code, please explain the abundance of easter eggs in proprietary software.

    55. Re:Understand the Source Perspective by RoLi · · Score: 4, Insightful
      I think open source does create the illusion that it couldn't contain hidden malware because where could it hide in open source, right?

      There are numerous examples of malware (like those in Kazaa), easter-eggs (like the flight simulator in Excel and the pinball game in MS Word) and unrequested features (like Windows Product Activation) in proprietary software.

      While I agree that something similar could in theory also happen to some one-man or very small open source projects (in theory because I have never heard of any such occurence) there is absolutely no way such code could be smuggled into bigger projects like Linux, Apache, KDE or the like, there are just too many people watching.

      So if you compare exactly what the article is talking about, proprietary software has a much worse track record.

    56. Re:Understand the Source Perspective by Allen+Zadr · · Score: 2, Insightful
      Uh, remember Phil Zimmerman?

      I think geeks have been DoJ targets for some time.

      --
      Kinetic stupidity has a new brand leader: Allen Zadr.
    57. Re:Understand the Source Perspective by x0n · · Score: 2, Insightful
      LOL, come on. There's pride, and then there's hubris. It's too good to export - almost as bad a PR job as PS2s being "military grade" hardware. Pfff. Secondly, you talk like all OSS software is developed in the U.S, and is thus a possibly "controlled" export. Not true.

      In any case, the military will always offer the work out to private contractors. These contractors would not be allowed to use GPL licensed s/w anyhow, imagine: icbmguidance.sourceforge.net; no? Neither do I.

      - Oisin

      --

      PGP KeyId: 0x08D63965
    58. Re:Understand the Source Perspective by Pieroxy · · Score: 2, Insightful

      Well, I think that's yet another illusion. Think disgruntled employees being paid by Bad Guys to insert a bit of code.... You may trust the company that made your software, but how can you possibly trust every one of their employees? And once it's in, since it's trusted it could be there for years.

      It's even worse with all the offshoring going on. I mean, people from halfway around the globe write your code. There is no way in hell you can trust them with national security!

    59. Re:Understand the Source Perspective by SanityInAnarchy · · Score: 2, Insightful

      Furthermore, you have to pay for source code to proprietary software, if you can even get it at all. This forces you into an agreement with the proprietary vendor.

      If you're the government, of course you'll review the code and try to pull out dangerous things. With open source, this means hiring a bunch of programmers, and possibly one lawyer to go over the GPL. With proprietary software, this means hiring a bunch of programmers to make sure the code is clean, hiring a bunch of lawyers to make sure the license is clean, and paying for the code itself.

      Furthermore, the community will catch quite a lot of bugs that a team of 10 or 20 programmers from the NSA might never see, simply because there are more of us.

      So I would say to the author that open source is less of a threat to national security than closed, and that furthermore, open source costs less. If you want to compete, stop insulting our intelligence and start changing your business model. Maybe a support / code review company, if you're so worried about national security? "Pay us, and we'll make sure there are no easter eggs in this source"?

      --
      Don't thank God, thank a doctor!
    60. Re:Understand the Source Perspective by T-Ranger · · Score: 2, Insightful
      They may be scared of it, but they do SFA when it happens.

      Proof: "Friendly fire" incident in Afghanistan where Canadian soldiers were killed by the hands of a US Pilot. I put "friendly fire" in quotes because to me, it doesn't even qualify as that. Im prepared to accept combat deaths, even friendly fire ones. Anyway: the Canadians were on a known live fire range (and the Americans knew, even if that information didnt make it to the pilot and air controlers). The pilot reported fire, and was specificly told to hold fire. The fire was coming from a range well known to be used by friendly ground forces, including US Forces. He fired anyway, killing 4, wounding a dozen others. He claimed he was "under attack", but how a machine gun could threatin a F18 at 20,000ft, I dont know.

      Final end result: loss of 1/2 months pay for 2 months, letter of reprimand. In other words: exactly nothing.

      If the US DoD were concerned about friendly fire there would have been a minimum of 3 people, if not incarcerated, then discharged from the service. The pilot, the person (or persons) who didn't provide sufficient briefings, and the commanders for letting that happen.

  2. the rest world chooses linux for the same reasons. by beh · · Score: 4, Insightful

    Shouldn't this article immediately point back to other articles on
    how governments OUTSIDE the US are choosing open source for exactly
    the same reason (who knows what M$ + NSA put in the closed windows
    source that might hurt other nations)?

    [World Govs Choose Linux For Security & More]
    http://slashdot.org/articles/01/12/11/0132213.shtm l

  3. TCP by danormsby · · Score: 2, Funny

    Better replace that open source nasty TCP ASAP then.

    --
    Omnis amans amens
  4. remember this guy? by jabella · · Score: 5, Informative

    Remember this guy? He also wrote "Linux Security: Unfit for Retrofit" ( http://www.ghs.com/linux/unfit.html )

    This was covered by LWN back in May: http://lwn.net/Articles/83242/

    IIRC, GHS does development on embedded XP stuff? I don't remember the details...

  5. Totally! Lets OUTSOURCE instead! by mekkab · · Score: 4, Funny

    Yeah, can't trust those commie FOSS developers. Instead, lets invest in "America", lets give money to companies who develop software overseas anyway!*

    *We wanted to buy software from only American developers, but we couldn't afford it.

    --
    In the future, I would want to not be isolated from my friends in the Space Station.
  6. FUD. by garcia · · Score: 4, Insightful

    Some embedded Linux providers even outsource their development to China and Russia.

    GASP! Some XYZ providers even outsource their development to ABC and DEF (insert your favorite company and terrorist sponsoring country where necessary).

    It would be incredibly naive to believe that other countries and terrorist organizations would not exploit an easy opportunity to sabotage our military or critical infrastructure systems when we have been doing the same to them for more than 20 years!

    I think it has been proven that closed-source development doesn't help to change the possibilities that a "mole" has been planted or that a "hole" will be discovered.

    One of the greatest misconceptions about Linux is that the free availability of its source code ensures that the "many eyes" with access to it will surely find any attempt at sabotage. Yet, despite the "many eyes," new security vulnerabilities are found in Linux every week in addition to dozens of other bugs. Many of these flaws have eluded detection for years. It is ridiculous to claim that the open source process can eradicate all of the cleverly hidden intentional bugs when it can't find thousands of unintentional bugs left lying around in the source code.

    And it is ridiculous to claim that a closed development enviornment will make it any different.

    In addition, under the internationally recognized Common Criteria for IT Security Evaluation (ISO 15408), Windows has been certified to Evaluation Assurance Level 4 (EAL 4), a higher level of security than the EAL 2 that Linux has achieved.

    According to this article, obtaining EAL2 certification typically costs between $400,000 and $500,000. Looks like it is more money than security. In their infancy, why would Linux vendors decide to shell out large sums of money when the government wasn't interested in using Linux anyway?

    This whole article is FUD. He's annoyed because Linux is making leaps and bounds and will possibly affect his market-share in the lucrative Defense and Aerospace industries. At least he came out and said it on his own legs and not by paying off a third party to "investigate" the "problems" with Linux and post their results to the world.

    1. Re:FUD. by nemaispuke · · Score: 5, Informative

      In Dan O'Dowd's mentioning of Linux "only" receiving CC EAL 2 is somewhat incorrect. RedHat Enterprise Linux Advanced Server got CC EAL2, SuSe Enterprise Linux was evaluated at EAL 3+. This is roughly the equivalent of TCSEC C2, and can be deployed in a classified environment. I guess he needs to check http://niap.nist.gov/cc-scheme/vpl/vpl_assur_lvl.h tml more regularly and actually read it!

    2. Re:FUD. by imroy · · Score: 4, Informative

      Check out this link: Understanding the Windows EAL4 Evaluation

      ...EAL levels run from 1 to 7. EAL1 basically means that the vendor showed up for the meeting. EAL7 means that key parts of the system have been rigorously verified in a mathematical way. EAL4 means that the design documents were reviewed using non-challenging criteria. This is sort of like having an accounting audit where the auditor checks that all of your paperwork is there and your business practice standards are appropriate, but never actually checks that any of your numbers are correct. An EAL4 evaluation is not required to examine the software at all.

      EAL doesn't really mean much. At least, not until you get up to the higher levels. It's basically so that government departments can have a check-list requirement for any software they buy or comission.

  7. The whole idea of open source by abrotman · · Score: 2, Interesting

    Isn't that the whole idea of open source? The guys working for our government can see the source code. Either this guy is clueless or working for someone with a vested interest.

    On the flipside, what is to prevent our government from doing the same thing? If the "enemy" can insert malicious code, why can't our government?

  8. Governments should not use OS without a proper... by WiKKeSH · · Score: 3, Insightful

    Governments should not use OS without a proper security audit. Once you can verify the nature of the code, there should be no obstruction to using it.

  9. Open Source is more like a Trojan Horse... by Anonymous Coward · · Score: 2, Insightful

    ...with really big glass windows. All you need do is open your eyes to see what's inside.

  10. Um, and what about the source China has seen? by InThane · · Score: 5, Insightful

    IIRC, China has seen the source code to Microsoft Windows, whereas the U.S. government hasn't.

    I think that's a pretty large security threat right there...

    --
    InThane
  11. Terrorists in Microsoft by shobadobs · · Score: 3, Insightful

    What if a terrorist gets a job at a software company? Where's the hope of catching the bugs then? It seems to me that closed-source software is more susceptible than open-source.

    1. Re:Terrorists in Microsoft by Frank+T.+Lofaro+Jr. · · Score: 2, Insightful

      What could a terrorist at Microsoft do?

      Add bugs to Windows? ;)

      --
      Just because it CAN be done, doesn't mean it should!
  12. NSA by codepunk · · Score: 2, Interesting

    One Word NSA....If it was so bad the NSA would not have their own version.

    --


    Got Code?
  13. Hmm Microsoft VS geeks? by Turn-X+Alphonse · · Score: 2, Insightful

    Now then.. last time I checked alot of the new bugs found in Windows were revealed by geeks... the type of geeks who make open source in many cases.

    I think I'd rather put my trust in someone doing it for the pure love (hate) of (bad) software, then someone doing it for money and no love at all.

    --
    I like muppets.
  14. Don't Trust Linus! by Noksagt · · Score: 3, Funny

    The U.S. government and military will be brought to their knees by...Finland?!

  15. Come out of the cave! by polyp2000 · · Score: 4, Insightful

    Dan O'Dowd, CEO of Green Hills Software, suggests that open source software has the capability of being sabotaged by foreign developers and should not be used for U.S. military or security purposes.

    Urmm , so what operating system do you use then Dan O'Dowd? and which newspapers and websites do you read?

    You're obviously using a closed source operating system that is free of viruses, worms, holes and other security problems. What might this mystery closed source operating system that you are using that doesnt pose a threat to the nations security?

    --
    Electronic Music Made Using Linux http://soundcloud.com/polyp
  16. Re:Well, here's the obvious (imho) response. by Jim_Hawkins · · Score: 3, Interesting

    Hate to break it to you, but there are a lot of other places that would *love* to have US information than good ol' Osama. These other governments have money. They have the resources to hire someone to insert this code into any open source project.

    As for the NSA inspecting this code -- that's all well and good. But, how often do hundreds of individuals look over OpenSource code and miss a big for awhile. "Awhile" is all it takes for a foreign government to download A LOT of information that they shouldn't have.

    Contrary to popular belief, a lot of places do not like America. It's not the big lovable teddy bear that it likes to think it is. It's a great country, but it should do everything it has to do to protect itself.

  17. Groklaw destroyed this FUD...long ago by FunWithHeadlines · · Score: 4, Informative
    Huh? Where's slashdot been? Groklaw answered this FUD months ago, repeatedly and definitively.

    Truly nothing to see here, folks. Just empty FUD that has been discredited.

  18. This reminds me of an old saying by C_Kode · · Score: 4, Funny

    This should be from the "If-you-can't-with dazzle-them-brilliance-baffle-them-with-bullshit" department.

    O'Dowd thinks that unfriendly countries will attempt to hide intentional bugs that the Open Source community will have no chance of finding.

    If the source is open how can there be no chance in finding bugs or whatever else they wish to put in the source?

    This is clearly FUD to protect their market from the steam-roller known as FOSS. Security through obscurity is already proven faulty.

  19. This is an old story, and FUD anyway by Bruce+Perens · · Score: 5, Interesting
    Green Hills is a failing company that is seeing its market go to Open Source. In contrast, Wind River, which is in the same market with the same customers, embraces Linux.

    The fact is that Green Hills products are no more secure, and may well be less secure, because they don't have the "many eyes" looking at their source code. We've had trojan horse attempts in Open Source software. They get caught quickly. But even if the source is disclosed, nobody outside of their tiny company has an incentive to do productive work on the internals of a Green Hills operating system in the way that people who modify GNU/Linux do. And security audits by such a small company can't catch everything.

    The best example of this has been the Borland Interbase database. This was used for airline reservations, and had a trojan horse buried in it for 6 to 9 years while it was a proprietary product. The door could have been found by anyone who did an ASCII dump of the product, but those who did kept it secret, and probably took a lot of free flights. An Open Source coder found the door some months after the database went Open Source, and had an incentive to report it - at that point he was one of the people doing productive work on the database and only wanted it to work better and more securely.

    This "black hats" (people who are motivated for bad purposes) vs. "white hats" (good purpose) phenomenon is important to consider when you evaluate the security of Open Source. Generally the only people who would look for vulnerabilities in proprietary software, outside of its manufacturer, are looking to exploit them! This is hardly the case with Open Source.

    Thanks

    Bruce

    1. Re:This is an old story, and FUD anyway by AndroidCat · · Score: 2, Informative
      That was a nasty one:
      Any local user or remote user able to access port 3050/tcp [gds_db] can manipulate any database object on the system. This includes the ability to install trapdoors or other trojan horse software in the form of stored procedures. In addition, if the database software is running with root privileges, then any file on the server's file system can be overwritten, possibly leading to execution of arbitrary commands as root.
      I wonder where the person who coded that one is working now?
      --
      One line blog. I hear that they're called Twitters now.
  20. Closed source safer? by bigbigbison · · Score: 3, Informative

    I seem to remember a few years ago (possibly after 9/11, but I'm not sure) there was an incident where an employee of a company that has a governement contract to write software that manages government infrastructure was suspected of terrorist links and so they had to spend tonds of time seaching through the code to make sure the suspect had not programmed a back-door into the system. (I might be misremembering the details here, but that was the gist of it) it seems that closed source is a lot easier to hide things away than open source.

    --
    http://www.popularculturegaming.com -- my blog about the culture of videogame players
  21. Re:the rest world chooses linux for the same reaso by bit01 · · Score: 4, Interesting

    (who knows what M$ + NSA put in the closed windows source that might hurt other nations)?

    Cryptographic code for a start.

    ---

    It's wrong that an intellectual property creator should not be rewarded for their work.
    It's equally wrong that an IP creator should be rewarded too many times for the one piece of work, for exactly the same reasons.
    Reform IP law and stop the M$/RIAA abuse.

  22. What about outsourced closed-source? by G4from128k · · Score: 2, Informative

    If this is a security issue, then the government should definitely not buy closed source from any software company that uses any offshore (non-U.S.) programmers. Who knows what those offshore programmers are inserting into the closed code. Of course, that rules out just about every large closed source maker in the world as I'm sure most have some non-U.S. development groups.

    --
    Two wrongs don't make a right, but three lefts do.
  23. Pure FUD, indeed by krygny · · Score: 3, Interesting

    Well, he said it all, so it must be true; even though he backs it up with nothing. This is so wrong on so many levels I don't even know where to begin. His assetions are hardly worth addressing. Therefore, pure FUD.

    Ok, I'll bite just once: I doubt there is a single weapon system procured by the DoD in the last 10 years that does not have a subsatantial portion of it outsourced overseas. Most procurments now require some % of it, by contract.

    --
    Research shows that 67% of those who use the term "research shows", are just making shit up.
  24. Here's the likely scenario by nysus · · Score: 4, Funny
    Just trying to think how a secret bug could be introduced. Maybe it would go down something like this?

    Lead Programmer at Major Defense Contractor: Hey, can you install this patch by the that new Pakastani contributor for our missile control module?

    New programmer: Yeah, I looked at it. There was some weird code in there that I couldn't quite figure out. There was some one line Perl code with about 10,000 characters. Shouldn't we look at it? What does it do, exactly?

    Lead Programmer: Naw. I don't think it really matters. I don't want to look stupid because I sure can't figure Perl out. Let's just go with the release early and often policy. We'll let the users report the bugs back to us.

    --

    ---Technology will liberate us if it doesn't enslave us first.

  25. "Attempt" is right by Zocalo · · Score: 4, Informative

    Um, this was already tried last November. Not only was the exploit very subtle indeed but it was still detected and removed within 24 hours. This is about as effective a piece of FUD as AdTI's last effort, and it looks like they were so embarrassed by that one they are resorting to a new name. I'm guessing we won't be hearing from "Green Hills Software" again once they've been publically ridiculed either...

    --
    UNIX? They're not even circumcised! Savages!
  26. Well, he does have a point ... by dougmc · · Score: 5, Insightful
    What he suggests is possible. And a well hidden bug could easily escape detection by Linus and anybody else who goes over each new patch looking for stuff like this.

    And it doesn't have to be in the Linux kernel. The classic example (at least 10 years old) is to hack up gcc so that it examines the code it's compiling, and if it decides that it's compiling /bin/login to do things a little differently, inserting a back door where there was none before.

    However, while he does have a point, it's a very myopic point. Closed source software has exactly the same vulnerabilities, except for one critical difference -- only people within the company in question have a chance of detecting the problem -- the end user will never get to see the source and see if it's compromised. Granted, most open source users do not review all the source code that they use, but at least the option is there, and for the people where security is absolutely essential (like the NSA) they almost certainly use it.

    Also, for a closed source company, the problem is even worse. The backdoor (or whatever) could be introduced when the code is finally compiled for distribution, and never get checked into whatever source control system they use. So the binaries get shipped out, but NOBODY has reviewed the source code in question (except our cracker friend) and once the bug does come to light (if it ever does) the company will look at the source code and scratch it's head -- it won't even have the source code in question to look at.

  27. Open Source Outsourcing vs Commercial Outsourcing by Feneric · · Score: 2, Insightful

    Isn't the problem described much larger for commercial outsourcing? These days most software used in the U.S. is partially written outside the U.S. At least with the open source software people concerned about security can build from source and perform an inspection on the source. With commercial software, no such precautions are available.

  28. Same crap from January. by khasim · · Score: 2, Informative

    Same guy, same company, same crap

    http://developers.slashdot.org/developers/04/01/ 15 /1733237.shtml?tid=106&tid=185&tid=190

  29. Re:Well, here's the obvious (imho) response. by foidulus · · Score: 2, Interesting

    ebola isn't a very good analogy, maybe HIV is a better one. Even though ebola can spread easier than HIV, the fact that it kills it's host rather quickly means that it doesn't have nearly the number of human nfections that HIV has. A virus that kills it's host off too quickly tends not be able to spread. HIV is a better analogy, it seems to be almost 100% fatal right now, but because it takes so long for symptoms to pop up, people don't realize they have it and spread it to others.

  30. Open is Closed. by Doc+Ruby · · Score: 3, Funny

    America is locked in a life or death battle of Good vs. Evil. Any openness or flexibility is weakness, which will be immediately exploited by our enemies to destroy our way of life. Open source hippies might be having fun, but they're frittering away our hard-won tech lead. The Internet itself, invented by the Pentagon, has been taken over by pedophiles since Al Gore reinvented it during the fake Bubble. God told President Bush to have Bill Gates take over the Internet, and all software development, to protect us from the hackers, and get rid of spam.

    Freedom is Slavery.
    Ignorance is Strength.
    War is Peace.

    --

    --
    make install -not war

  31. Outsourced Proprietary Software? by rlp · · Score: 4, Interesting

    At least OSS lets the prospective user review the source code. U.S. companies are rapidly outsourcing proprietary development to foreign countries. Key infrastructure software (and firmware) is being developed in countries such as mainland China (including code used for the U.S. telecom system). Meanwhile, the U.S. military is rapidly adopting off-the-shelf components to reduce costs. But, by all means, lets ignore this, and concentrate on OSS ...

    --
    [Insert pithy quote here]
  32. Let's call him Chicken Little by tizzyD · · Score: 2, Insightful

    When you can't compete, FUD.

    The gauntlet is thrown down. I challenge this man to come up with a demonstrable "trojan horse" in an OS piece of software that cannot be found in a reasonable period of time by a security audit (the kind the government does of OS software to be used). Such fear mongering should be laughed at with, torn up, and spit upon whenever you see or hear it. It reminds me of Ridge getting up and saying, well, there's a threat around the election, but we have no evidence of it. Be scared (and vote for Bush). Yea . . . right. I didn't just fall off the turnip truck.

    Get a life, and make better products, jerk!

    --
    ...tizzyd
  33. I am continually amazed... by SuperChuck69 · · Score: 4, Insightful
    I am continually amazed that people believe open source is a good place for terrorists to hide evil, anti-government bugs...

    The cornerstone of open source is that it is OPEN SOURCE. The government is free to view and evaluate all the packages to their little, demonic hearts' content.

    If I were a terrorist, I'd think I would penetrate a closed-source house (say, Microsoft or Green Hills) and hack some little nasties into their source.

    But,, maybe that's why Dan O'Dowd isn't a very good terrorist.

    --
    :wq
  34. FUD slinging by HexRei · · Score: 2, Interesting

    O'Dowd thinks that unfriendly countries will attempt to hide intentional bugs that the Open Source community will have no chance of finding."
    mere speculation. and certainly no more valid than a PROVEN case of bugs being left inside closed code which aren't found until they're exploited.

  35. Why OSS ? by alvieboy · · Score: 2, Insightful

    I wonder if they also consider shareware and freeware as a possible threat.

    You know, it's easier to hide funcionalities in Shareware/Freeware than in OSS - you can't look at the code and observe them at one glance. I wonder if it would not be easier to spread malicious code in PaintShopPro and others.

    Al.

  36. Not Wind River by Bruce+Perens · · Score: 4, Informative
    No, so far we don't see the same from Wind River. They had the choice of FUD or joining the Free Software developers, and they chose the latter.

    Bruce

  37. Funny How Great Minds Think Alike... by EXTomar · · Score: 4, Interesting

    If you were a paranoid Iranian or North Korean computer user and look at Microsoft Windows would you think the same thing? Heck, why would a Chinese user think that MS and the NSA/CIA/alphabet soup is trying to snoop them? Because MS allows a select group to look at their source?!?

    At least with Open Source you have the source to ultimately check for yourself. Vendors like Novel, IBM, and RedHat are supposed to be actively looking at the source to make sure no one is slipping stuff in that doesn't belong but if you don't believe them you can do it yourself.

    So you have a Mr. Dan O'Dowd trying to a terrorist ghost threat into Open Source. The problem is that the source is there for you to inspect. With Microsoft the only word you have is their word that they aren't monkeying with the OS to monitor you.

    IMHO, BSD and Linux are perfect for Military and security applications. You can inspect every corner of the kernel. You can freeze on a specific version because you always have that source code. You can branch and patch as you see fit. This seems perfect for the military and security branches. With Microsoft you have to "signup" (how much money does it cost to do that?) to view the source and then what? The only proof you have is that this particular version of Windows hasn't been monkeyed with. What about the patches and hotfixes? *shrug*

    When it really boils down to it are you going to believe the source you compiled, you control yourself or Microsoft? I think Mr. O'Dowd's trust is ill placed.

  38. Issues at Hand by gmletzkojr · · Score: 5, Informative

    There are a number of issues that play a part in the Green Hills argument. First of all, let me say that I have had the experience of using Green Hills products (non-military) for the past few years now.

    First of all, coming from a company that charges *a lot* of money for an OS stands *a lot* to lose from a free OS. Therefore, GH would be expected to say that a GH product is better.

    The fact that GH source code is not open source does not mean that no one ever sees it. I have access to the entire source, and, if so inclined, could use that information to create an attack myself or provide the source to someone else. Remember, even though the company signed a release for the source, that doesn't mean that money talks more.

    GH has, up till this point, maintained a 'top dog' status in this area. In fact, when we asked for a driver for USB mass storage, the response was 'Well, where else would you get it? It is going to cost you.'

    IMHO, GH has had a bit of a mini-Microsoft status within the military embedded world. This has certainly mirrored the PC OS world - one leading OS, some neat features, but when you really look at, how many ways are there to create a GUI or an OS. Let's be honest - an OS has queues, semaphores, a file system (replaceable, in GH), etc. So we are not talking about 'rocket surgery'.

    The idea of Linux not being 'military grade' would really need to be made from an independent group. This is akin to MS saying that it has the best browser or GUI. Of course they are going to say that.

    --
    I for one welcome our new [insert main topic] overlords.
  39. Wrong Analogy by Tenebrious1 · · Score: 5, Funny

    He should liken any government using closed source software with the Trojans themselves, who took the *gift* without examining the contents.

    If the Trojan Horse were really Open Source, it would have had a list of building materials, instructions on building the horse yourself, the number of greek warriors inside, how the warriors were armed, along with several notes from the Phoenicians commenting on the dangers of the included Greeks...

    --
    -- If god wanted me to have a sig, he'd have given me a sense of humor.
  40. Ignore this at your peril by FWMiller · · Score: 4, Interesting

    I'm a long time Linux user and have been around open-source for a long time. While the source of this article is obviously questionable, I work for a Defense Contractor and I'm here to tell you, the points raised in the article have some truth to them.

    If you're selling products to the govt and those products use an operating system, the issue of being able to GUARANTEE that your code base is not and cannot be coerced is very real. Everyone has (or should have) seen the techniques used to obfuscate trojan horses by using a compiler or some other tool that makes this problem even harder.

    The problem being eluded to here is about a chain of control of a code base that can be demonstrated to satisfy a DoD or other govt customer. While no process can ever be completely secure, the real point is, if you have a choice between a system that has been developed in a closed environment where you can keep an eye on everyone involved and and open-source development, the prior development is easier to verify. You can call it FUD but this is a real issue within the govt circles and WILL limit the use of Linux in certain applications.

    --
    Frank W. Miller
  41. yeah by dfiguero · · Score: 2, Funny

    "will have no chance of finding..."

    right! because it's closed source... Only non-american programmers are smart... no one else will be able to decipher Dr. Evil's mini me bug... finally mexicans will be able to get green cards by the millions!

    muahahahahahaha muahahahahaha

    btw. I'm mexican :P

    --
    My penguin ate my sig
  42. Amusing article by u-235-sentinel · · Score: 5, Interesting

    Even if Linux were as secure as Windows, Windows is the wrong benchmark. Defense systems should be held to a higher standard.

    As secure as Windows? He's kidding .. right?

    When I worked for the AirForce, they had several instances in which systems were comprimised (desktops). Various worms came out of the blue and just hammered their network. My systems running Linux noticed it immediately. In fact I was told there was NO problem. After a few hours of watching the logs logging attacks over and over again I then noticed a general email sent out to all explaining there was a problem and instructions were provided.

    As secure as Windows? God I hope not!

    The Federal Aviation Administration (FAA) requires software that runs commercial (and many military) aircraft be approved as part of a DO-178B certification. DO-178B Level A is the highest safety standard for software design, development, documentation, and testing. It is required for any software whose failure could cause or contribute to the catastrophic loss of an aircraft.

    Several operating systems have been DO-178B Level A certified. Until Linux is certified to DO-178B Level A, our soldiers, sailors, airmen and marines should not be asked to trust their lives with it.


    If Linux isn't at this level then what is the point of the article? Linux is certified for various things in the military. Whenever I stand up a server I was asked what OS I would be running. Everyone was apprehensive it would be Windows which requires a whole heap of testing before it's allowed to run in production. As soon as I told security it was either Unix or Linux they would sigh and tell me to go ahead. Much more confidence there :-)

    --
    Has Comcast disconnected your Internet account? Same here. You can read about it at http://comcastissue.blogspot.com
  43. Re:Governments should not use OS without a proper. by tomhudson · · Score: 2, Interesting
    For example microsoft let China view it's source code.
    No, they let them view PART of their source code. Without compiling.

    Unless you have both the full source and the compiler/toolchain it was built with, a security audit is worse than useless, as you have no way of verifying your results.

    In such a case, WYSINNWYG (What You See Is Not Necessarily What You Get).

    For example: You get the full source and the toolchain. You do a build on the same platform using the same flags. Your final executable has a different md5 sum. You have to conclude that the either the source or the toolchain you received is not identical to the source that was used for the original build.

    Without everything (full source, toolchain, build scripts and flags) you cannot verify that you even hae the right source.

  44. NSA Linux by failedlogic · · Score: 2, Interesting

    Yeah, Linux is untrustworthy. Enough so that the NSA chose to develop NSA linux with its own security extensions? What I'm getting at is that the government can make its own secure OSes by using Open Source.

  45. my comment about his article by Goeland86 · · Score: 3, Informative

    this is what I posted on his article, on designnews itself, where I'm sure he will read it:

    In theory, of course, you're totally right in believing this. In practice, however, you're inescapibly wrong. First, since Linux is open source, the army implementing these linux embedded systems most likely read through the code to verify it's normal behavior and lack of serious design flaws, second, terrorists nowadays do not use computers for fear of being traced by the NSA or CIA with the net, thus preventing themselves from ever contributing code to Linux. Third and last, the linux kernel development team has now a signature follow-up on the internet, to make sure that each piece of code can be traced back to it's original author. It makes it that much easier to locate the developpers of Linux. Many of them are in countries that you failed to mention, like Japan, Australia, Finland and many other western countries that the US government trusts. Besides that, the open-source community is the best bug-tracking-solving community in the world. I believe it has happened for the webserver apache when the new version was shipped out with a security flaw less than an hour later the bug was traced in the code and a patch submitted. So, even in the case of a security flaw in the linux kernel, I believe that in less than 35 minutes the army computer specialists would be able to trace and fix the flaw. And those security flaws are precisely the reason the army orders pre-series of each equipment they will use and test them for a few months with anything that they're expected to meet in combat zone, one of them being loss of OS stability, control or even total power failure and recovery. You have only looked at the theoretical part of the problem, and propose no solution to the problems you see, therefore I consider your article a big rant against opensource, not constructive criticism, which in my opinion would be true partiotism.

    --
    ---- I am certain of only one thing : I know nothing else.
  46. Misleading the naive! by SpiritOfGrandeur · · Score: 2, Insightful

    However, this conventional wisdom is unsupported by quantitative data. In fact, the U.S. National Institute of Standards and Technology (NIST) security vulnerabilities database lists more vulnerabilities for Linux than Windows in the last ten years. In addition, under the internationally recognized Common Criteria for IT Security Evaluation (ISO 15408), Windows has been certified to Evaluation Assurance Level 4 (EAL 4), a higher level of security than the EAL 2 that Linux has achieved.

    Is this not due to the fact that only people inside M$ can check their own code, and that they will not always disclose vulnerabilities?

    Linux on the other hand almost always instantly discloses its bugs.

  47. all in the family by blooba · · Score: 5, Interesting
    both my father and i were DoD software engineers, me as a developer, and he as a tester. i do commercial stuff nowadays, and dad's retired. we both know, for a cold hard fact, that no national security- or defense-related software ever goes into production without passing the most rigorous reviews and testing, throughout its entire lifecycle. from functional descriptions, through design reviews, code walkthroughs and acceptance testing, everything is closely monitored and recorded.

    so, please explain to me again how open source terrorists are going to slip their malware under our noses?

    1. Re:all in the family by Anonymous Coward · · Score: 2, Insightful

      Because Linux has millions of lines of code. GHS's operating system has about 10k, and you get a copy of the source which you can rebuild from scratch when you buy it. And those 10k lines of source code also come pre-documented and certified.

      I've worked for defense contractors using GHS's operating system. I'd much rather read and certify just my own application code than 1M lines of Linux _plus_ my own application code.

  48. closed source by Errtu76 · · Score: 2, Insightful

    Isn't a bug inside an open source program much easier (and no doubt faster) to find than one in a 'closed' source application?

  49. I've got two words for this guy: by schon · · Score: 2, Informative
  50. Valid concern for *all* OSs by AK+Marc · · Score: 2, Interesting

    So, someone could put in bugs or backdoors in Linux? That would never happen with, say, routers from the largest router company in the world. Oh, wait. It already has. Other countries are dumping Microsoft. Why? Because it is a closed source they can not look at that may pack bugs or backdoors placed by the US company to help the US.

    Of all the valid reasons to attack open source software, I can't imagine how they can imply an unknown piece of code is more secure than a known piece of code, even if possible enemies are contributing to the open source (unless, of course, every programmer at Microsoft has been given the proper clearance for all levels the OS they are working on will be used).

  51. Lets look at this from the other direction... by Business+King · · Score: 2, Insightful

    Lets say the United States uses a contractor, that has a foreign national as part of their staff, but does not know it, and this national is in charge of building some software. The foreign national knows exactly where to place key code segments to crash the program (lets say a missle interception program) when they want too. The foreign national knows exactly what test cases are being done, and knows how to avoid them, therefore hte software looks bullet proof. The software is approved as working, and is shippped. But the U.S. Government does not know, is that one line in tens of millions, checks for an override code. Now, unless an extensive code review is done -- which is supposed to be done, but not always done -- to go over all lines as they are checked in, this bug will make it past the checks. Once the code is delivered, the chances, at lesat from what I can imagine, that it getting caught till the damage is done, is super small.

    Now, if the code was open source, it would get reviewed, and looked at constantly. Yes, again, what are the chances of someone finding that bug, but I am sure they are greater than someone trying to find a bug in closed software.... :)

    The Austrailan voting system has been open source now for a number of years, and that system has just gotten more secure over time. I think that is a prime example of something that is borderline needing to be secure, and how open source worked. I Think it can work again, and that the US. should adopt it, if our greedy companies do not get in the way first.

    By the way, the top paragraph was completely hypothetical -- no one wants CIA agents at their door.

    -A

  52. What about the H1-Bs and outsourcing by Anonymous Coward · · Score: 2, Insightful

    If this is true for open source then it is 10 fold for closed source comercial software with all the outsourcing and visa holders! At least with open source we can find these mythical backdoors. The Outsourcing and visa trends are a much greater risk to National Security than Open Source if you use this lunatics logic.

  53. Exactly the point by hol · · Score: 5, Insightful

    This is precisely why Brazil, China, and even Germany are moving towards open-source. The US Government cannot insert backdoors into this stuff that would affect anyone not wanting to be affected, unlike Microsoft stuff. Remember the NSA keys in the Windows NT crypto libraries?

    The US can continue to run Windows, be our guest, but the point is moot since much of US Government software is developed in India anyways. No back doors there, for sure.

    --
    - - - Non Caffeine Drink or Drink Error
  54. First blush by yoshi_mon · · Score: 2, Insightful

    I went to Green Hills Software page 1st. Just to see who this is.

    And I'm a little upset. Is OSN actually letting these guys astoturf on /.? Why would this get even a 2nd look by anyone? I might see the somethingawful forums laughing at this but to have a posting here?

    This whole thing smells bad. Maybe it's a slow news day but there are better anti-linux rants than what is coming from that lame ass website. Nothing to see here, move along.

    --

    Really, I know what I'm doing...Ohhhh, look at the shiny buttons!
  55. Scenario by jhaberman · · Score: 2, Interesting

    I have no idea if something like this could be possible, but just playing devils advocate here.

    Say, the software was used for target calculations for an artillery piece. For the sake of argument, say some "rogue" developer has added a bit of code that takes the coordinates from the GPS in the unit. Checks to see if they are in, say, a middle eastern country. If so, the shells, which found the target just fine in testing, are now missing the mark by 500 yards.

    Not paranoid, just askin.

    --
    He's totally creeping out the Great One, eh...
  56. Obligitory Office Space joke by smatt-man · · Score: 2, Funny

    Maybe they would introduce a bug that takes the fractions of a penny that are rounded off when computing interest in banks, deposit it into their own account? Like in Superman!

    --

    ---
    Lousy rotten karmic retribution.
  57. Oh really by TheConfusedOne · · Score: 4, Insightful

    It's possible, and HAS happened that KNOWN, and TRUSTED engineers have put bits of code that would pass initial scrutiny and still be dangerous.

    Wasn't there recently an article about a router with a backdoor shipped out in its code? How about all those darn "easter eggs" floating around in Windows and Office and other programs?

    I would challenge you to compile a new Intel C library using a Microsoft C compiler from 6 years ago too. Heck, compile glibc using an IRIX compiler from six years ago.

    You can drag out all the scenarios you want and whether it's Linux or it's *nix or BSD or Windows you're going to have the same audit challenges and not even have access to the source code without negotiating with all your suppliers.

    --
    --- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
    1. Re:Oh really by Bombcar · · Score: 3, Funny
      How about all those darn "easter eggs" floating around in Windows and Office and other programs?


      The idea of an easter egg in missle guidance software is amusing, at least.

      "Now see here, Joe, lemme show you a little trick. You fire this here missle directly at the sun and that enables the solitare game!"
    2. Re:Oh really by pchan- · · Score: 2, Interesting

      I would challenge you to compile a new Intel C library using a Microsoft C compiler from 6 years ago too. Heck, compile glibc using an IRIX compiler from six years ago.

      hmm, i don't think code using features of C99 (y'know, the latest C specification) would compile on pre-C99 compilers. i can't imagine why you find that surprising. as for glibc, it is far too dependant on gcc hacks to have a chance of compiling under any other compiler.

  58. Green Hills FUD was covered on groklaw months ago by Jayfar · · Score: 3, Interesting

    Is this a dup? I dunno, but Green Hills FUD was discussed on groklaw at great length over 3-1/2 months ago.

  59. Wait a second! by shotro · · Score: 2, Interesting

    Doesn't Microsoft outsource to other countries? I wouldn't be to surprised if Green Hills does as well. WTF? What a hypocrite. Wouldn't that be putting our security at risk considering we all know that Microsoft surely doesn't check their code as well as hackers do.

  60. Terrorists could NEVER get the source for Windows by Anita+Coney · · Score: 2, Interesting

    Microsoft has been showing its source code to governments and corporations for the last few years. China is one example. Does anyone seriously believe that a terrorist could NOT get a copy of that source?!

    Heck, what would stop a terrorist from getting someone employed at Microsoft and simply stealing the code?!

    But, then again, Windows is such an easy target for exploitation, getting the source code probably wouldn't be worth the bother. It'd be like stealing a key to a building without locks.

    --
    If someone says he and his monkey have nothing to hide, they almost certainly do.
  61. Afraid of it? Don't use it! Comm. sw is no better by otisg · · Score: 2, Insightful

    It's as simple as the subject. Open-source software is just another option. Don't like it? Buy the commerical software, or pay for its development by a trusted company or agency.
    However, governments DO use closed-source software from companies and people they do not know. Who says Microsoft is not paid by X government that, through mass-adoption of Windows and other MS applications around the planet, now has control over a laaaaaarge number of computers in all countries of this world?
    In other words, simply buying commerical software is not any more secure. What's worse, there is not way you will be able to check the sources. With OSS you have that option, and it is up to you, the user of the software, to check it or not check it.

    --
    Simpy
  62. Give the NSA and friends some credit by twem2 · · Score: 2, Insightful

    As has been said many times before:
    Closed source is no guarantee of lack of tainting. Even with security checks its perfectly possible to have a hostile programmer working on the software.

    I'd just like to put in a word for the NSA et al. They're perfectly capable of making their own decisions, and are probably far more qualified than anyone here. They know how to minimise risk using whichever development model they like...
    It is of course very possible that open source software could be written on behalf of the military. The people who keep the official version for use within the military/government will go through all code submitted with a fine tooth comb being very conservative with what patches they accept from the outside world...

    This article is basically written for politicians to try and scare politicians into banning the FOSS competition. I doubt it would work if the military and friends didn't want it that way, they will make up their own minds.

  63. Criteria for ICAT vulnerability citation by anthro398 · · Score: 4, Informative

    I was looking through the authors citations and it seems that his quote concerning the number of vulnerabilities in Linux compared to those in Windows is pretty questionable. The database, as you can see here, has one selection for Linux and many for Windows. It seems that the U.S. National Institute of Standards and Technology considers components of Windows, such as Internet Explorer not to be a part of the operating system, thus listing vulnerabilities of the compenents separate from those of the OS. At the same time, Linux vulnerabilities include Sound Blaster driver issues and problems with third party software such as Symantec Antivirus.

  64. Re:Well, here's the obvious (imho) response. by Arakonfap · · Score: 2, Insightful

    What does this have to do with OpenSource? Specifically, what problem does it present that is not shared with ANY software?

    If we're going to compare Linux and Microsoft - have you noticed all the backdoors and trojans and worms out there lately? These security holes that are being used were not (likely) put in there on purpose - they're simple mistakes. Left by coders, in a CLOSED SOURCE company. There's no need to go to open source to get bad code!

    Are you a coder? Have you participated, or ran, an open sourced project? In such a thing, you don't just accept code. You read it through, test it, and make sure it will do the job before compiling it.

    Sure, you don't do a background check on every person submitting code - but you DO make sure the code does what it needs to, and that it does not have blatent bugs in it. Atleast the code that's submitted this way gets CHECKED AND APPROVED. That's not the case in all closed source companies - they don't all review code changes!

    Has there been a background/security check on everyone that submitted code for use in NT4 SP6 that's used in high security defense systems? No. It's just not possible.

    Atleast with embedded system, that are OS, the code can be all checked because it's small enough where it's a fully solvable and testable system.

    And what does information stealing have to do with even pure source code?? Most "hacks" like that are social enginieering (email attachments, "CoOL CURSoRs! HeRE!"), etc. high security organizations use reverse firewalls to make sure nothing important is going out!

  65. Re:You can't possibly be a developer by betelgeuse-4 · · Score: 2, Insightful

    Calling coding an NP problem seems a little odd. It's not a decision problem really and some aspects are trivial whereas others may have no solution (e.g. the halting problem).

  66. Green Hills is the national security threat by It+doesn't+come+easy · · Score: 4, Insightful

    What a bizarre article.

    The statement "Yet, despite the "many eyes," new security vulnerabilities are found in Linux every week in addition to dozens of other bugs." Shouldn't one consider that the "many eyes" are the developers finding those weekly bugs? Wonder how many eyes are looking for Green Hills software bugs?

    As long as people are involved, mistakes (bugs) will be made. But saying that malicious code is more likely in a product where someone CAN examine the code verses a product where no one can is just plain stupid. There is obviously an undisclosed agenda here (might that be selling a DO-178B Level A rated real time OS, aka Integrity? Getting a lot of Linux competition, eh?).

    As to the standard DO-178B...the first 90% of the article is about security, then you mention DO-178B. DO-178B is not a security standard. DO-178B is a FAA safety related standard for software. Any software certified under DO-178B can still be full of unknown security holes. The standard may be required for software used in flight related applications but it does not mean the software is also secure.

    The level A rating doesn't even mean "most secure" as the article seems to imply. It means that if the software crashes, it will not affect other software that is running. In other words, the software is ISOLATED, not secure.

    It is amazing the things companies will say when they are losing ground to a competitor.

    --
    The NSA: The only part of the US government that actually listens.
  67. Supporting comment by Allen+Zadr · · Score: 5, Interesting
    Here's a supporting comment...

    Just as parent post suggested. Except, the govenment is already auditing open source, and customizing the Linux kernel to it's own needs... Does nobody remember NSA Secure Linux?

    --
    Kinetic stupidity has a new brand leader: Allen Zadr.
    1. Re:Supporting comment by at_kernel_99 · · Score: 4, Insightful
      Does nobody remember NSA Secure Linux?

      When one is ranting in a desperate plea to defend one's own methodology & existence, it is often helpful to ignore facts that do not support one's case.

  68. Just another security by Obscurity argument. by gurps_npc · · Score: 2, Insightful
    A lot of people are trying to defend him saying "The code could be modified by evil people who put an Evil Easter Egg in it."

    STUPID ARGUEMENT

    The code does not have to be modified by evil people. ALL CODE HAS BUGS So all code should be checked, and not just by the people that write the code. The entire point of Open Source is that LOTS of people check the code for bugs. The difference between an "Evil Easter Egg" and a "bug" is just the intent of the programmer. Open source is MORE likely to catch an "evil Easter Egg/bug" than a closed source technique. Having a Spy try to sneak one is ridiculous because the the same bug detection routine will also detect the evil easter eggs.

    But closed source DOES have one advantage over Open Source: secrecy.The problems with Open Source Defense programs are 1) "They" know exactly how good our programs are and 2) "They" can use them themselves.

    Because of these two things it is not a good idea for most Defense purposes. We want the bad guy to NOT know how good our stuff is and we do NOT want them to have the same quality stuff.

    --
    excitingthingstodo.blogspot.com
  69. If OSS is a Trojan Horse... by dstone · · Score: 2, Insightful

    ...then it's made of nice, transparent Plexiglas.

  70. and closed source propietary firms.... by zogger · · Score: 5, Insightful
    ...and defense related places DON'T hire foreign nationals or domestic nationals with perhaps a bent for the blackhat side? This never happens? And everyone in government itself is sweet and pure as the mountain streams, and would never think of doing anything...strange... for some financial remuneration off the books? This never happens either? And so called "allied and friendly" governments don't run spooks inside our establishment and sleepers inside our citizenry? And they *always* have our best interests at heart?



    Nope. Open source is still the best way to go, along with open government. When you let people hide "stuff", and when it's connected to massive political power and heaps 0 money, that's when crimes occur. The best bet is openness, bar none. It is not perfect, but it's the best design yet.

  71. Offshoring just as much of a threat by Kagato · · Score: 4, Insightful

    Sure, there is a threat in the Open Source movement. But, how is that threat compared to offshoring? I don't think they are any different. Yet, when a threat is something that enhances the bottom line, security concerns are not raised.

  72. Re:Failing company? by rumblesnort1 · · Score: 2, Interesting

    Wait a minute here - Windriver is in the RED. Their stock is dropping like a ton of bricks and their 2004 sales growth is -18.1% and is shrinking their employee base. If you would equate Windriver's adoption of linux instead of their earnings as proof of their success, you will have to understand that I respectfully disagree. Would it be probable that Windriver is embracing this technology (Linux) to gain market share and Green Hills is merely competiting with them (e.g., not a bunch of linux haters) to plant seeds of doubt with prospective Windriver customers? I understand that linux may be the victim of collateral damamge, but I fail to see Windriver going the way of market dominance (they already dominate quite a bit, just losing share) because of this choice and Green River on the fast track to Chapter 11. This may get Windriver a bit closer in the "Visionary" box in Gartner's magic quadrant, but it will be interesting to see if Linux will lower production/operating costs enough to bring profits out of the red. R

  73. The strengths of Linux count against its security by Anonymous Coward · · Score: 3, Informative

    Let me comment as one who has some background in NSA/NIST/TCSEC/CC evaluated software.

    If you bet your life or your country's safety, you want something like Evaluated software doing the protecting. And not just EAL4 level stuff like NT. Look at the common criteria and look at the definitions of what the software evaluation levels are appropriate for.

    Evaluation at a greater than EAL4 leval means that the documentation and test development each take much more time than the coding. The Evaluation itself (assuming the vendor has all his docs and tests complete) takes twice the time of the development. The Evaluation is done in a 4 tiered process with each of the 4 entities (lab, validator, tecnical approval board and vulnerability tester) having access to the source code and to the developers documentation and to the developers themselves.

    High levels of evaluation require single source development under a single set of development standards.

    Code developed, in our group, is reviewed in writing by 3 of the most senior architects of the product. Each reviewer objection or concern must be satisfied until it passes to the next reviewer.

    So that means that we can document that 7 security trained people or outside organizations have looked at any code that is declared "Evaluated".

    The object code is delivered in a trusted distribution methodology such that there is end to end verification (including while loading and while running) that the code that was developed and evaluated is the code you are running.

    Now compare the Linux method of development and distribution.

    To say that the code is Linux code is locked down and tested is to say that the barn door is locked too late in the process for the kinds of things the author of this posting is citing as potentials for happening. The emphasis must be on security over all, designed in from the begining and nothing ... not functionality or speed or compatibility ... can come before security in any design or coding task.

    Is every Linux improvement preceeded by a security review?

    Is there a security guru that can stop ship?

    Is the security guru trained in security?

    Is the security guru management supported?

    Developing and deploying secure software is a time consuming, expensive, specialty that only a very few companies attempt.

  74. You Are Being Delibrately Misleading. by HopeOS · · Score: 3, Informative

    Linus only takes patches from the people responsible for appropriate parts of the kernel. To get a patch through requires convincing those individuals -- and they do check the patches. In my experience, getting patches into the kernel is not a trivial matter, in fact it is frustratingly difficult. Futhermore, even if you succeed in getting a patch into some esoteric driver, the less mainstream it is, the less likely it will be in an active kernel.

    If the various world governments will go through the trouble to audit defense contractors' code, then they can save themselves some trouble and audit Open Source code instead; any vendor establishing from that base will require less time in audit later. If the governments do not demand an independent audit of contractors' code, then that is where you will find the weak link. With Open Source, you always have the opportunity to audit at any time, diff against previously audited sources, and compile customized code with minimal audited feature sets.

    Green Hills is saying "Trust Us! Trust Us!" Open Source is suggesting you trust what you can independently verify before your own experts' eyes.

    As for the tool chain issue, you are seriously glossing over the obvious -- all the statements you have made apply to proprietary vendors as well. The solution is simple: don't upgrade the tool chain until the changes pass inspection. This is standard operating procedure for all mission critical deployments.

    -Hope

  75. Misunderstand the Source Perspective by MarkusQ · · Score: 2, Insightful

    What this article is claiming -- and everybody seems to be ignoring -- is that open source, being a wild system with no accountability (liability) nor authority, is more prone to dangerous bugs and backdoors that closed software developers don't have to worry about. This is the key -- not that hacker X is going to put a backdoor in that won't get caught by peers, but that hacker X's identity and location are completely unknown (not true for employees of a closed software developer) and that there is nobody whose lifestyle is in jeopardy should such a backdoor be found.

    No, they aren't ignoring, they are denying it. Because it's bunk.

    1. Accountability has very little to do with preventing problems and everything with placing blame after they happen.

    2. Open source has more loci of "authority" than closed source, chained in a check-and-ballance system that greatly improves their effectiveness. And the cap stone is, I get to make an informed choice about what I run on my boxes.

    3. It isn't true that closed source developers don't have to worry about backdoors, but it may well be true that they believe that they don't. There have been many cases of backdoors in popular closed source programs (Remember "Netscape engineers are wennies"?) but can you name one backdoor that made it into a widely used open source product?

    4. As far as knowing the identity of the person who supplied a patch, this is just plain nuts. I can (and have) easily tracked down the person who wrote/submitted a patch to an open source product, and the person who accepted it--often, I can have an e-mail wigning its way to them in miuntes. But I can't recall ever learning the identity of a programmer who made a change in a closed source product, or even being offered the means to.

    -- MarkusQ
  76. Naive? by Mirkon · · Score: 2, Insightful
    ...unfriendly countries will attempt to hide intentional bugs...

    s/countries/Microsoft/g;
    --
    Glog!
  77. Re: Do we need another comment? by Anonymous Coward · · Score: 3, Interesting
    Maybe this: How has the penguin got into the US army? Let's look on the Land Warrior project:


    http://www.usatoday.com/tech/news/2002/02/07/tech- military.htm tells the first part (or may be the first and the second) of the story: The army started its own proprietary development, employing several contractors to design completly new system (of hardware and software, not only a software operating system). The development proved to be expensive and inefficient, not leading to anything usable---they got it reviewed, learned the lesson and changed their approach. They adopted and adapted mostly commertially available off the shelf parts, including the Windows operating system. Then they moved forward, up to actual tests of usable equipment.


    The next part is told at http://www.nationaldefensemagazine.org/article.cfm ?Id=1238 The new design, including Windows, failed its test. The army again learned its lesson, the whole system was redesigned, and Linux adopted for its operating system.


    The army did not take Linux out of sheer stupidity, not knowing other alternatives---the army took Linux after serious considerations of its rich and expensive experience with several other alternatives.


    Mr. O'Dowd speaks of Linux being worse than Windows, and Windows being almost as bad as Linux. Looks like his Green Hills Software was part of the firs expensive exprience of the army, first losing its contracts to Windows, and then to Linux.

  78. It's the implementation by zoloto · · Score: 2, Interesting

    but if the military found F/OSS software to be superior, then so be it. If they're worried about it coming into the hands of their enemies, the DoD's implementation does not have to go back into the public via GPL. Since the Military isn't "Public" in many aspects, I don't believe they should be bound by the GPL in the sence that any changes used and put in place inside their tanks or jets can be used in the public anyhow, it shouldn't be released.

    make sense?

    just my thoughts.

  79. Internet Explorer, anyone? by casmithva · · Score: 2, Interesting

    Unless my memory's foggy, didn't the Dept. of Homeland Security and CERT advise everyone recently to stop using closed-source Internet Explorer, developed by an American company, and switch to open-source Mozilla, an international effort for security reasons? Nah, I must've dreamt that...

  80. Rebuttal from LynuxWorks at COTS Journal by eddison_carter · · Score: 2, Informative

    The June issue had an article from GHS, and one from LynuxWorks. COTS Journal is published for developers (Systems, hardware, and software) of commerical off the shelf products, which is essentailyl a standard for military procurement where possible (You can get a computer, OS, etc, "off the shelf", but something like a sub or cruise missle is another story)

    LynuxWorks: http://www.cotsjournalonline.com/home/article.php? id=100128

    GHS: http://www.cotsjournalonline.com/home/article.php? id=100129

    --
    I always prefer to start the year off with a bang - or, to be more precise, a series of loud hums, a crackle or two, and
  81. How is this riskier than companies that outsource? by digital+photo · · Score: 3, Insightful

    I find it interesting that open source software is considered a risk because individuals from other nations are allowed to participate in the development of the code...

    How does this differ from corporations which provide software to the military who outsource their development to individuals from other nations?

    The only difference is that the OSS model involves corporations giving up some of their control over the rights of the product and corporations don't like that.

    Otherwise, the article makes assumptions of differences between OSS remote participation and outsourcing which has no material relevance.

    The idea of outsourcing being more secure because security checks are done can be argued, but even security checks fail and someone who is cleared can decide to sabotage. The problem is that once someone is vetted, they are trusted. This is actually worse than the OSS model where no matter who you are, the code is reviewed with the same level of scrutiny as anyone else's code.

    I can think of so many instances of calling support, having to provide my personal identifying information to an individual who was either not in my state or not even in the US.

    Sounds more like a double standard of judgement from the corporate viewpoint that is prejudiced against OSS projects.

  82. Linux is not a RTOS by Discoflamingo13 · · Score: 4, Informative

    What Dowd fails to mention, in all of this, is that Level A certification requires a detailed specification of requirements that the system must implement. These requirements must be covered by test cases that give full requirement coverage (or appropriate analysis) and structural coverage (for Level A, it is MC/DC statement coverage). The Open Source methodology is a long way from being a DO-178B compliant process, and rightly so - the rules for change control of a Level A-certified product are the exact opposite of the "release early, release often" method embraced by a typical open source program, because the development objectives are entirely different. This does not mean that an open source program can not be certified to Level A - it means that it requires a great deal of work on behalf of the organization submitting it for Level A compliance, first.

    DO-178B is the most rigorous safety evaluation standard in the aerospace, automotive, or defense industries. There is no difference in the DO-178B certification guidelines for verifying a closed-source vs. open-source application. The problem that both of them have to come up with is documentation of the process used to produce the product, along with design and architectural requirements for the application that can be independently verified for full MC/DC statement coverage by an independent third party. Each application must be shown to accomodate space (memory access) and time (real-time scheduling) partitioning requirements on any device it is run on.

    Most Level A OS's are a RTOS with (if you're lucky) ANSI and POSIX libraries for I/O and math. There are companies that have modified Linux for use in real-time embedded applications, but the standard Linux scheduler is not real-time, and does not perform space partitioning of application memory (which means it can be Level E, but nothing above that). If it does not affect safety-critical parameters, it doesn't have to be Level A - Levels D or E are acceptable.

  83. Choice quote of the article by wtrmute · · Score: 2, Interesting
    It would be incredibly naive to believe that other countries and terrorist organizations would not exploit an easy opportunity to sabotage our military or critical infrastructure systems when we have been doing the same to them for more than 20 years!

    Whoa, he comes out and says it like that? Man, if I were part of the Gringo-hater crowd, that'd give me fuel for years!... :-)

  84. So US-Centric by abe+ferlman · · Score: 3, Interesting

    A lot of other governments are moving away from Microsoft b/c they're pretty sure we're using Windows to spy on them.

    Unfortunately, you can't guarantee that someone looking to subvert windows in a subtle way won't be hired by (or more interestingly, license their code to) Microsoft- so with closed source you basically get the worst of all possible worlds.

    --
    microsoftword.mp3 - it doesn't care that they're not words...
  85. Reflections on Trusting Trust by sakshale · · Score: 2, Interesting
    Ken Thompson, one of the coauthors of C, said it best in his Turing Award lecture; Reflections on Trusting Trust.
    The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.
    --
    For every problem there is a solution that is simple, obvious and wrong.
  86. If this guy actually believes this, by stealth.c · · Score: 4, Insightful

    he is terminally paranoid. I understand that he has a vested interest in FUDing FOSS, but let's attack his argument for a second:

    First of all, what truly important piece of software would possibly be part of open public development? I thought this was specialized enough of a field that the only people who had any competence with what you were making were already trusted anyway. Wasn't SELinux developed *inside the NSA* before it was released?

    Secondly, assuming a vital piece of software WERE being developed publicly, someone trying to insert malicious code would have to make it past a few barriers, the first being the most complicated. He would have to: 1) Know what his deliberately inferior code would probably do in the finished product versus what a non-ciminal would want it to do. 2) Get it past the critical eye of a few other developers, 3) Slip through some kind of government screening. And all the while NOT make anyone suspicious.

    And even then the results are not guaranteed. What is your cyberterrorist counting on? I sincerely doubt that he could have snuck a back door into the code given all those hoops. I don't think the deliberate bug can be both significant and unknown at the same time. Is he hoping that his bug will cause the software to make a slight miscalculation? Whoopty shit. Whatever agency he or she is working against will be annoyed for a little while and then fix the problem.

    Even if his deliberate bug caused a catastrophic failure, it can and will be traced back to HIS contribution, and if some terrorist group stands up and says "Ha ha! Look what we did! And here's why!" (and if it's Al-Qaeda we can be almost certain of this) That man is immediately under FBI surveillance and probably arrest.

    In any case, inserting a bug would be a lot of work. A lot of work for an uncertain return, and success will mean almost inevitable detection.

    Why some terrorist would bother with this approach is beyond me. It's so much easier just to fill a truck with dynamite.

  87. US has software trojans too... by Dr_Marvin_Monroe · · Score: 4, Interesting

    Lest us not forget that WE'VE been planting trojans in software shipped overseas too. I recall a story here regarding deliberately sabotaged software shipped to some Russian pipline project. As I recall, the trojaned pipeline test software was designed to operate the pipeline at 10X normal pressure and cause an explosion...which it properly did, setting back the Russian government's energy plans.

    When other governments start using OSS, they may be freeing themselves of these US planted trojans. I believe THAT is the major fear of the US government... Not that they will fail to detect a foreign planted bug in some fighterjet, but that OUR planted bugs will be found by China/India/Pakastan/Iran/etc... This would also seem to explain our government's looking the other way with regard to the Microsoft settlement. Remember that the anti-trust settlement was made within a week or so of September 11. Remember also the "Green Lantern" project, where our government was activly looking for ways to co-opt peoples boxes.

    Software than cannont be easily trojaned creates just one more difficulty for our spy agencies. As with the gangster who was using pretty secure encryption, the government is now forced to use things like hardware keystroke loggers (meaning they have to have physical access to the unit), sneek-and-peek, you get the idea.

    The US government has an interest in keeping people using insecure systems. How easy to you think it was to open those Windows laptops captured in Afganastan? Why, the NSA had those famous "NSA-KEY" entrys to Windows!... Easy as pie. The last thing they want is for KSM and OBL to start putting strong-encrypted filesystems on their Linux laptops in Afganastan. No way to plant the backdoor!

    Expect to see a lot more of this type of FUD... The US Government has plenty of time and money to make sure that their Linux systems are safe, they just don't want others using them...

    1. Re:US has software trojans too... by Fishstick · · Score: 2, Interesting

      this one?

      http://news.zdnet.co.uk/software/0,39020381,391479 17,00.htm

      Software supplied to run a Russian pipeline was deliberately planned to go haywire, causing the biggest non-nuclear explosion the world had ever seen...

      as I recall, this wasn't a case of sabotaging legitimately acquired software for the hell of it. The CIA became aware of the Soviet's intent to steal western technology, including control software for their pipeline project, through an agent recruited by the French.

      Reagan was aware of, and approved the plan. The CIA managed to get inside the deal, and instead of stopping the transaction, sabotaged the code so that the pump speeds and valve settings would go haywire after some period of time.

      I'm certainly not excusing the sabotage that, while not causing any loss of life, caused immense damage to the Soviet economy. I won't argue wether it was justified... but the US government made it illegal for them to import certain technology. They circumvented this ban, and paid a heavy price.

      --

      There is much cruelty in the universe, John.
      Yeah, we seem to have the tour map.

  88. Re:Confused About The Logic by Oswald · · Score: 2, Funny
    What the hell have I missed here?

    The article, apparently. This point is covered. Accept his argument or refute it, but don't just re-state the question.

  89. More Green Hill FUD by infolib · · Score: 2, Interesting
    You can find what's more or less an expanded version of this article here.

    Quote: The NSA has not fixed, or even seriously tried to fix, the security problems (documented in this series of white papers) that make Linux unsafe for defense systems.

    [...] If secrecy isn't important to security, then why does Linus Torvalds keep the means of accessing the core Linux development tree a secret from all but a few people?

    Another FUD dose says

    The GPL was designed by Richard Stallman to prevent you from making a profit from distributing his software (which makes up a large part of Linux).

    --
    Any sufficiently advanced libertarian utopia is indistinguishable from government.
  90. The odds of this happening... by Godai · · Score: 3, Insightful

    ...have to be low. I mean, let's go over the steps that such an alleged terrorist would have to go thorugh to get this crucial system bug into the kernel:

    1. craft a bug that would be capable of rending someone-in-the-know root access
    2. craft the code that creates the bug in such a way that it would be accepted by Linus. This would require:
      • a plausible reason for the patch; ie. a feature addition or bug
      • the crafted 'secret bug' would have to be imbeded in such code that purports to add the alleged feature or fix the supposed bug
      • Linus (or whoever) would have to miss the bug; so it would have to be fairly subtle
    3. hope that no one detects the bug, be it by the hardware manufacturer, or anyone using the OS before the military hardware goes live in the field (or wherever)
    4. ???
    5. Profit! (Terrorize?)

    That's a pretty good obscure set of circumstances. Does it mean it can't happen? No. But contrast this with proprietary methodology wherein a coder has (usually) unrestricted access to the code base. Hmmm. Sounds more plausible there!

    Of course, the key thing to note here is that anyone who has to dredge the dread forumla that terrorism + open source == Disaster!!! is probably desperate to save his flagging business.

    --
    Wood Shavings!
    - Godai
  91. Re:The strengths of Linux count against its securi by stwrtpj · · Score: 3, Insightful
    So that means that we can document that 7 security trained people or outside organizations have looked at any code that is declared "Evaluated"...
    To say that the code is Linux code is locked down and tested is to say that the barn door is locked too late in the process for the kinds of things the author of this posting is citing as potentials for happening.

    So what's stopping the DoD from taking the source code base and doing their own testing and certification on it? Considering you claim to have had a background in this, I'm surprised you didn't think of this. This may save them some time in the long run, since they don't have to go through the effort of developing the software itself.

    If I decide to use a library or module from another developer (OSS or otherwise) in something that I am doing, I always take the time to test it to make sure it at least does what I want and is adequate for the task at hand. Now, my own projects don't require a terrible amount of security, but if they did, I would be certain to do some testing in that area as well.

    So I just don't get your point. You don't have to develop the code yourself in order to certify it if you have the full source available to you. And then once you have certified it, after making any corrections that you need on your copy of the source, then you lock THAT down. What came out of the original source base is irrelevant at this point. It only matters what you improved upon and certified.

    --
    Karma: Frotzed (mostly due to the Frobozz Magic Karma Company)
  92. closed source is MORE vulnerable by AbraCadaver · · Score: 2, Interesting

    Does anyone remember that Canadian company that was making US DOD software... and outsourcing some or most of the programming to China. I beleive that the DOD wasn't fully aware of where the work was being done until later in the game. Not that either of the parties involved had malicious intent, BUT, that in itself seemed far more vulnerable than code that EVERYone can see, and audit, and comment on.

  93. Greenhills has an ax to grind by spreading FUD by wintermute42 · · Score: 2, Insightful

    A number of postings have done an excellent job of describing why open source is not a security threat and, in fact, can be more secure because the source code itself can be audited, signed, etc...

    This is a long discussion and I may have missed it. But I have not seen a mention of why Greenhills might be motivated to make the claim that open source is a security threat.

    Greenhills sells proprietary compilers for embedded systems. They also sell real time operating system software. Their business model is under threat by open source. This is especially true in the area of real time embedded operating systems. With their compilers they can at least show that for a given embedded processor their compiler produces better code (this is not that hard to do against GNU for a number of architectures). But with real time operating systems (RTOS) they have less of an edge. Linux is becoming more and more widely adopted. Increasing numbers of people have experience with Linux.

    Greenhills, one can speculate, fears a serious erosion of their RTOS business. This business is probably bigger than their compiler business (few people make much money on compilers these days). Taking a page from Microsoft and SCO they are attacking Linux using FUD. If this also helps their compiler business ("Who knows what trojans open source compilers might generate?"), all the better.

  94. take a page from the KGB playbook by Anonymous Coward · · Score: 2, Insightful

    If I were a foreign adversary of the United States, and I wanted to exploit software to gain a strategic advantage, I would not go with F/OSS. There would be too many eyes, too many curious geeks with nothing else better to do than inspect my work, and too many other routes for my target to get source code other than what I have tainted. Rather, I would worm my way into a company selling proprietary software to government and industry. There are fewer eyes, so I would have fewer people to "manage". Influence a developer, one person in QA, and perhaps a secretary and I could have almost anything I want put in place and distributed across the planet, with the help of the DMCA to cover my tracks.

    The KGB said, go for the secretaries. The secretary holds the keys, the trust of others, and can go where s/he wishes. Monolithic organizations are vulnerable exactly because they have few internal firewalls; if you *can* get in then you become part of the trusted architecture, and then there is no mechanism to get you out.

  95. Seen on a T-Shirt by Stephen+Samuel · · Score: 2, Funny

    "My proprietary program went to the pentagon, and all I got was these silly battle plans:"

    --
    Free Software: Like love, it grows best when given away.
  96. and the vendors are moving to Linux by TheConfusedOne · · Score: 2, Insightful

    Embedded systems vendors are moving to Linux to keep up with the changing hardware and needs of their customers.

    Does this address the needs of all embedded systems users? Of course not. I can see in really high-security fields you need to have 100% control of things. The critical embedded devices in power plants come to mind in that case where you may be replacing a 10 year old device and need to ensure that you have exact compatability.

    However, these are outlying cases and will strain almost ANY OS group to satisfy. (Especially as they still need to move forward with their technology as well.)

    I would say that the OSS route in that case may actually provide you better security as long as you archive both the code and the software used to build the code (including the OS and the hardware if necessary too). If your requirements are in fact that strict then you're going to either have to have complete control of the code you're relying on or have escrow agreements that ensure you'll be able to obtain the code if your vendor happens to go out of business.

    --
    --- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
  97. Pretty obvious, but... by darnok · · Score: 2, Interesting

    if we take this guy at his word, then it's reasonable to think that non-US countries shouldn't use closed source, US-developed software because it could contain nasties as well.

    The US govt isn't everyone else's best friend at the moment, and appears to be working particularly closely with US software companies at present in terms of pushing US' interpretation of intellectual property onto much of the world. It's more than feasible that the US govt could have said "Look, software vendors, we'll push your interests out into the world, but there's a favor you can do for us in return. Here's some source code we want you to bolt into your products for overseas distribution"...

    At least FOSS gives people the opportunity to examine the source of what they're going to be running. No, most people don't bother, but with Windows, Solaris, etc. it's not even a possibility.