German Government: Stop Using Internet Explorer
mashable.com
mashable.com
One incident still boggles my mind. A friend of mind attended a security conference last year with a corporate IT manager who had been insisting that IE is the better choice from a security model standpoint. One after another speaker stood up and presented a paper or a speech or a lecture or a round-table all saying essentially the same thing:
The security of networked systems is only as good as it's weakest link, and IE has consistently been the weakest link for years. Even with hundreds of security patches since XP was released, it's still such a threat to the network that it's irresponsible to continue using it. Not one presenter used it anymore. They continued that enterprise IT should not only be recommending other browsers, they should be enforcing other browsers as part of their security policy and disabling IE as much as possible on all systems under their control. It was damning.
After we got back to the office, he sent out a corporate wide email reminding everyone that browsers other than IE are vulnerabilities to the network and won't be tolerated.
I understand that a government would be hard-pressed to suggest that a nation forgo using an OS that is so deeply embedded in many organizations' and people's day-to-day operation, but even a brief acknowledgement of what is the underlying problem (worldwide deployment of an out-of-date operating system inextricably and systemically intertwined with the function of an abhorrently insecure electronic portal to the entire world of internet-enabled machines [I'm referring here to Internet Explorer]) would really help the much-needed movement to spread awareness of the more secure, cheaper alternatives (I'm referring here to Linux-based systems).
In any case, it's always great to see organizations with clout holding Microsoft publicly accountable for its indiscretions.
* Training virtually all of their developers on secure coding
* Modifying their core libraries to avoid dangerous idioms
* Spending tens of thousands of dollars per product per release on external security testing
* Slowing down dev cycles with "SDL" measures like threat modeling and code review
* Holding off releases to audit for new bug classes
I'm not saying that Microsoft ships perfect software, because what I'm saying is that it's impossible to ship perfect software.
When you write it in C/C++, anyway.
(I think Microsoft has almost solved this problem, though, with their heavy investment in the CLR and languages like F# on top of the CLR. Even C# is fine, compared to C or C++. You can still write insecure software in managed languages, but it will be because of a careless design, not forgetting to tack a "\0" on the end of a block of memory.)
(If you were writing your web applications in C, you'd have to worry about memory corruption problems AND cross-site request forgeries.)
That is simply not true.
It may be very difficult, it may be insanely expensive and it may require an immense effort to thoroughly inspect the whole stack that is under the software (down to the hardware level, that is, with some attention on how external events may influence the hardware) but no. It's not impossible to ship perfect software, specially if you restrict the definition of "perfect" as doing what it's supposed to do, no more and no less.
What I was thinking was the bold statement that doing something right (or perfectly right) is impossible and its widespread use as an excuse for not even trying. A software developer must aim for perfect software, even if shipping it is not always economically viable. The fact end-users have been beaten into submission and now tolerate having to restart their computers after software crashes or to redo calculations because the results were absurd the first time is not relevant to this discussion. If they tolerate less than correctness, we shouldn't. The current security problems we have are entirely fault of people who regard immediate profit as more important than long-term quality.
And I take exception with anyone who suggests this is how things should be.
Both failed to ship code free of game-over security flaws.
I find your point about "tolerating" failure to be irrelevant to the real world at best. At worst, it's just fatuous.
I've shipped hundreds of thousands of lines of code, and I've led projects to review millions of lines more: chipset to JVM, embedded to desktop, open source and proprietary. It is a point of pride with us: we always find things.
You think you're being respectful of users when you chant "don't tolerate failure". What you're really doing is being disrespectful of computer science. All evidence available to us suggests that it is practically impossible to ship code --- or at least, real-world code --- without security flaws.
Is secure software an impossible goal? Not for computer scientists. For instance, a Stanford team build a system for evaluating code for flaws based on abstract analysis. That project became Coverity, a commercial product for scanning source code for flaws. They compete with a larger company called Fortify, in a hundred million dollar market for static code analysis.
Projects like Stanford Checker, or the OS and runtime hardening work being done in countless labs, have a chance of advancing the state of the art to where you think it really is now. A line developer on a browser project has no such chance.
What you have to do, on the other hand, to back up your bold statement that developing perfect software is impossible, is to prove it impossible.
Good luck.
You could, if you had given it 5 seconds more thought, chosen examples that were hard to falsify (even if they weren't based on any experience of your own). You might have suggested "weapons guidance" and "space shuttle life support". You wouldn't be right, except to the extent that those systems have virtually no attack surface, but at least your message board argument would be viable.
I am not against security reviews. Quite the contrary. What I am saying is that you made a very impressive statement you can't possibly prove. There is software that does exactly what it's intended to do with no side effects, no bugs and that lives in a spacesecurity flaws are non-existant.
You fail to understand not all software is as complex as, say, a JVM. I am pretty sure you would haves hard time finding a flaw in, just to make a very simple example, the code that runs my coffee machine or that calculates my car's mileage. A security expert that claims it's impossible to write perfect software is nothing but arrogant and self-serving.
So, if you want to say it's impossible to have perfect software, please, prove it.
I don't care about your relative inexperience in software security. I care about the disrespect to computer science; the utter certainty that your comments betray that an unsolved problem that implicates vast swaths of terrain in CS is in fact solved, and could be put into practice if only every software practitioner would behave in some unspecified and abstract way that Ricardo Banffy has determined for them.
You claim shipping perfect software is an impossibility. I would find it entertaining to hear you trying to prove this. Unfortunately, you are avoiding that burden.
I took a stand against the pernicious impact baseless affirmations like yours have on attitudes throughout our industry. They imply it's OK to write something faulty and then debug it into shippable form. And then ship it. This is not the way it should be done.
I would be OK if you said shipping software that does (only) what it's supposed to do was "horribly difficult", "prohibitively expensive" or something on these lines. You equate perfection to invulnerability to external attacks, narrowing this "perfection" to fit into your expertise.
I "specify" no "abstract way" for software builders other than to have faith, at least until it's proven it's impossible to do our job right, that perfection is achievable and we should try really hard to get to it, something you seem to disagree with.
So, again, please prove our efforts are futile so we can finally shed our hopes and follow your lead.
That said, the very fact that a browser is not super-sandboxed in the first place is frightening, and IE has a huge amount of integration compared to other browsers. Mayhaps that's why it's been such a problem?
The only browser that is "super sandboxed" is Chrome, and nobody knows how effective the process security model in Chrome is going to end up being. The actual vulnerability appears to be a basic object lifespan problem in DOM handling code; in other words, this could happen to any browser.
After Chrome, the browser with the next most involved security model is IE with DEP, and, in fact, when DEP is enabled, the exploit doesn't work (that's no guarantee that it could never work, though).
(Uh, and it’s one of those government offices still in Bonn. Just around the corner, for massive 5km amounts of just around the corner.)
On the other hand they have the power to intercept and analyze the complete data- and phone communication without anonymization. They of course use it not only to find malware and security risks, as was intended in the bill, but to provide 'suspicious' data to the police and intelligence services (http://www.golem.de/0901/64639.html).
We also have data retention for all communication data for six months and have planned a nice censorship infrastructure to block domains (against child pornography for now), not unlike Australia or China.
But at least IE has only 40% market share... (http://www.browser-statistik.de/)
In any case, this vulnerability looks remarkably straightforward. You could conceive of the fuzzer that might have found it. It would be an extremely clever fuzzer, but not an unprecedented one.
&utm_content=Google+Reader